Committed as obvious after regression testing.
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:e2947cfa2d1d4da13bb298b4f36cd745b007d88d
commit r10-6060-ge2947cfa2d1d4da13bb298b4f36cd745b007d88d
Author: Jerry DeLisle
Date: Fri Jan 17 19:36:03 2020 -0800
This one looks OK Thomas
Cheers,
Jerry
On 12/22/19 7:28 AM, Thomas Koenig wrote:
Hello world,
here is an update for the fix for PR 92961, which also takes care
of the second test case in the PR (included in the first one).
The patch itself should be clear enough - make sure that there
is a
On 12/29/19 2:16 AM, Thomas Koenig wrote:
Am 19.12.19 um 08:23 schrieb Thomas Koenig:
Regression-tested. OK for trunk?
Ping?
This looks good Thomas,
Thanks for patch,
Jerry
Between Holidays and being short on people that understand this, I would
say commit it unless Jakub objects.
(When in doubt, make a decision and move forward principle, assuming one
is not stupid,)
Cheers,
Jerry
On 12/29/19 2:27 PM, Tobias Burnus wrote:
On 12/16/19 9:06 AM, Tobias Burnus
yet and I propose we commit the patch
here and address any DEC stuff as a follow up. (I will be looking at the
DEC stuff in the next few days.)
OK for trunk?
Regards,
Jerry
diff --git a/gcc/testsuite/gfortran.dg/fmt_zero_width.f90 b/gcc/testsuite/gfortran.dg/fmt_zero_width.f90
index 640b6735c65
On 12/31/19 2:17 AM, Thomas Koenig wrote:
Hi Jerry,
OK for trunk?
Looks good. I also think that your approach that DEC stuff should
be checked later is good. If it passes the testsuite, that's good
enough for a commit.
Thanks for the patch!
Regards
Thomas
Committed r279828
... ;-) Used to ICE previously.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
This one is OK Harald.
Thanks,
Jerry
email.
Regardless, both good to go.
Thanks,
Jerry
on x86_64-pc-linux-gnu. OK for mainline?
As this fixes a regression since 8-release, I plan to backport
to all active branches.
Thanks,
Harald
OK for Mainline and backport
Thanks Harald
Jerry
This patch committed as obvious after regression testing and auditing
the code. New test case added.
Author: jvdelisle
Date: Wed Jul 4 18:08:16 2018
New Revision: 262416
URL: https://gcc.gnu.org/viewcvs?rev=262416&root=gcc&view=rev
Log:
2018-07-04 Jerry DeLisle
PR fortr
,
under Linux, gfortran.dg does not link in pthreads, so the
tests would not be executed in parallel, and some of them
would fail.
So, here is the final version. I would really like to get this
into trunk, and out of the way, so Nicolas and I can focus on
other things.
So, OK?
OK, Go for it.
Jerry
We can work on the gfortran.dg incantations as a
follow-on effort. (maybe a separate PR for it)
Jerry
ing. Which linux are you using?
I will try it here as well.
Jerry
On 07/15/2018 11:46 AM, Rainer Orth wrote:
Hi Jerry,
Hmm, interesting. Which linux are you using?
Fedora 27.
Rainer
Works for me. Fedora 28. Do not know for other OS's
Jerry
Hello all,
Attached patch fixes this and adds a test case. The "$" edit descriptor
was being completely ignored when next_record_w is processed. Fixed by
adding a simple check.
OK for trunk and backport to 10 since it is simple enough?
Regards,
Jerry
libgfortran: Do not emit end
On 2/7/21 9:07 AM, Thomas Koenig wrote:
Hi Jerry,
OK for trunk and backport to 10 since it is simple enough?
OK for trunk.
Because this is a user-visible change (even if we did the wrong
thing before) I don't feel that we should backport (but I am
open to suggestions otherwise).
The attached patch is another provided from Steve Kargle in the PR report.
I have created a test case and regression tested the result.
OK for trunk?
Regards,
Jerry
libgfortran: Fix PR95647 by changing the interfaces of operators .eq.
and .ne.
The FE converts the old school .eq. to
How do I get permissions set so that I can change status of bug reports
and assign to myself. My permissions got dissolved during some
evolution in the last year.
also
The master branch has been updated by Jerry DeLisle:
https://gcc.gnu.org/g:0631e008adc759cc801d0d034224ee6b4bcf31aa
commit
an object type is found to not be declared already,
an error is issued.
One new test case added and one modified to pass.
Regression tested.
OK for trunk?
Regards,
Jerry
fortran: Object types should be declared before use in NAMELIST.
gcc/fortran/ChangeLog:
PR fortran/98686
On 2/19/21 8:00 AM, Tobias Burnus wrote:
In this example, the formal argument is a derived type
and not a class – hence, there is an ICE.
OK for the trunk?
This is OK, could you also check 89219 and 81499 and see if these are
the same or similar.
Much appreciated.
Jerry
?
Yes OK, thanks for patch.
Jerry
Hi Harald, Looks Good to Me.
OK
Thanks
On 2/22/21 1:14 PM, Harald Anlauf via Fortran wrote:
Dear all,
when simplifying the RESHAPE intrinsic we lost the string length when
the resulting array had size zero. The attached patch sets the resulting
length from the source.
Regtested on x86_64-pc
Yes OK got mainline.
On 3/3/21 3:45 AM, Tobias Burnus wrote:
Rather obvious change – don't apply replacement multiple times.
OK for mainline?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Tho
Yes, OK, however, have you been able to test performance. I am only
curious. There was a test program we used back when this code was first
implemented in bugzilla. I do not remember the PR number off hand.
Jerry
On 2/23/21 1:46 PM, Harald Anlauf via Fortran wrote:
Dear all,
under certain
OK, thanks Dominique for spotting this.
On 3/4/21 9:02 AM, Tobias Burnus wrote:
Dominique found an issue ("regression") with this patch – and a testcase
omission.
The previous patch mishandled the noncommitted testcase of PR57871 – or
in other words: It did not promote 1.0_4 or 1.0_8 – as only
?
Jerry
2019-11-01 Jerry DeLisle
PR fortran/90374
* io.c (check_format): Allow zero width for D, E, EN, and ES
specifiers as default and when -std=F2018 is given. Retain
existing errors when using the -fdec family of flags.
2019-11-01 Jerry DeLisle
IBUTE_UNUSED from get_file's 'reason' as it
is used in the linemap_add call.
And I have moved the OpenMP/OpenACC comment before if openmp/openacc condition,
where in my opinion it belongs to.
OK for the trunk?
Tobias
Yes, OK, thanks for patch.
Jerry
it as soon as I include in the
test case.
Regards,
Jerry
2020-01-12 Jerry DeLisle
PR libfortran/90374
* io/format.c (parse_format_list): Zero width not allowed with
FMT_D.
* io/write_float.def (build_float_string): Include range of
higher exponent values that require w
ntrinsic.c (gfc_conv_intrinsic_size): Use CLASS data
attributes for CLASS arrays for generation of runtime error.
gcc/testsuite/ChangeLog:
PR fortran/100602
* gfortran.dg/pointer_check_14.f90: New test.
Yes, OK for both, thanks
Jerry
* trans-array.c (gfc_conv_ss_startstride): Do not call check for
presence of a dummy argument when a symbol actually refers to a
non-dummy.
gcc/testsuite/ChangeLog:
PR fortran/100656
* gfortran.dg/bounds_check_22.f90: New test.
Yes, OK on both. Thanks
Jerry
LGTM, OK for trunk and back ports.
On 5/4/21 11:34 AM, Harald Anlauf via Fortran wrote:
PING!
---
Dear Fortranners,
Gerhard found a case where the mismatch of actual and formal argument lead
to an ICE instead of the relevant warning. Furthermore, the special case
of character argument avoide
ranch.
Objections?
Thanks,
Harald
Looks good to me. I think backport is OK as well.
Jerry -
On 3/1/24 11:24 AM, rep.dot@gmail.com wrote:
Hi Jerry and Steve,
On 29 February 2024 19:28:19 CET, Jerry D wrote:
On 2/29/24 10:13 AM, Steve Kargl wrote:
On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote:
On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote:
And, just for my own
On 3/5/24 1:51 PM, Harald Anlauf wrote:
Hi Jerry,
on further thought, do we sanitize 'child_iomsg'?
We pass it to snprintf as format.
Wouldn't a strncpy be sufficient?
Harald
Just to be safe I will bump char message[IOMSG_LEN] to char
message[IOMSG_LEN + 1]
This is like
On 3/6/24 9:13 AM, Harald Anlauf wrote:
Hi Jerry,
can you please replace the user message in e.g. your new testcase
pr105456-wf.f90 by say:
piomsg="The users message containing % and %% and %s and other stuff"
This behaves as expected with Intel, but dies horribly with gfortran
Hi all,
There has been a bit of discussio on which way to go on this.
I took a look today and this trivial patch gives the behavior concluded
on Fortran Discourse. See the bugzilla for all the relevant information.
Regresion tested on x86-64.
I will do the appropriate changelog.
OK for trun
this fix survives broader testing, I would like to backport.
Thanks,
Harald
P.S.: while trying to extend coverage of conforming code, I had
much fun also with other compilers (e.g. NAG panicking...)
OK, for trunk and we will see how it survives for a bit before back port.
Jerry -
incorrect separator as long as there is
at least one space in front of it.
New test case included. Regression tested on X86-64.
OK for trunk? Backport to 13 after some time.
Regards,
Jerrycommit 7d1a958d6b099ea88b6c51649baf5dbd5e598909
Author: Jerry DeLisle
Date: Wed Apr 3 18:07:30 2024
On 4/4/24 2:31 AM, Tobias Burnus wrote:
Hi Jerry,
Jerry D wrote:
The attached log entry and patch (git show) fixes this issue by adding
logic to handle spaces in eat_separators. One or more spaces by
themselves are a valid separator. So in this case we look at the
character following the
On 4/4/24 2:31 AM, Tobias Burnus wrote:
Hi Jerry,
--- snip ---
The patch looks mostly like I would expect, except for decimal='point'
and a ';' which is *not* preceded by a space.
Thanks for working on it.
Regarding the 'except' case:
--- snip ---
i.e. f
On 4/4/24 2:41 PM, Tobias Burnus wrote:
Hi Jerry,
I think for the current testcases, I like the patch – the question is
only what's about:
',3' as input for 'comma' (or '.3' as input for 'point')
For 'point' – 0.3 is read an
On 4/5/24 10:47 AM, Jerry D wrote:
On 4/4/24 2:41 PM, Tobias Burnus wrote:
Hi Jerry,
I think for the current testcases, I like the patch – the question is
only what's about:
',3' as input for 'comma' (or '.3' as input for 'point')
For &
On 4/8/24 2:53 AM, Tobias Burnus wrote:
Jerry D wrote:
See attached updated patch.
It turned rather quickly out that this patch – committed as
r14-9822-g93adf88cc6744a – caused regressions.
Namely, real-world code use tab(s) as separator instead of spaces.
[For instance, PR114304 which
cc/fortran
PR fortran/114535
* resolve.cc (resolve_symbol): Remove last chunk that checked
for finalization of unreferenced symbols.
gcc/testsuite/
PR fortran/114535
* gfortran.dg/pr114535d.f90: New test.
* gfortran.dg/pr114535iv.f90: Additional source.
Yes, OK Paul. Don't feel bad. It wasn't Tabs. LOL
Jerry
On 1/30/24 12:36 PM, Harald Anlauf wrote:
Hi Jerry,
Am 30.01.24 um 19:15 schrieb Jerry D:
The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float
patch looks OK.
Thanks,
Jerry
The attached patch fixes this PR by properly adjusting some variables
When using stream io. See log below. New test case included.
Regression tested on x86_64.
OK for trunk and backport?
Regards,
Jerry
ChangeLog:
libgfortran: Adjust bytes_left and pos for access="STREAM".
The attached patch fixes the X editing.
Fairly self explanatory. I created the patch a few years back.
Regression tested on x86_64 and new test case.
OK for trunk?
Regards,
Jerrydiff --git a/gcc/testsuite/gfortran.dg/pr99210.f90 b/gcc/testsuite/gfortran.dg/pr99210.f90
new file mode 100644
inde
Pushed as simple and obvious.
Regards,
Jerry
commit 8221201cc59870579b9dc451b173f94b8d8b0993 (HEAD -> master,
origin/master, origin/HEAD)
Author: Steve Kargl
Date: Wed Feb 14 14:40:16 2024 -0800
Fortran: namelist-object-name renaming.
PR fortran/105847
gcc/fort
. Another temporarily disabled test was
re-enabled.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Yes OK for mainline.
Thanks,
Jerry
The attached patch fixes this one. Se the ChangeLog below for explanation.
OK for trunk?
I think simple enough to backport to 13 as well.
Regards,
Jerry
Author: Jerry DeLisle
Date: Fri Feb 16 17:06:37 2024 -0800
libgfortran: Fix namelist read.
PR libgfortran/107068
Hello,
I posted the attached patch in bugzilla some time ago. This includes a
new test case. The patch adds additional checks in key places to catch
eroneous use of semicolons
Regression tested on x86_64,
OK for trunk and later backport to 13?
Jerrydiff --git a/gcc/testsuite/gfortran.dg/pr1
Steve,
I looked it over and looks reasonable. I will try to apply it next few
days and test here. If OK, I will commit.
Jerry
On 2/21/24 12:28 PM, Harald Anlauf wrote:
On 2/21/24 20:41, Jerry D wrote:
On 2/21/24 10:30 AM, Steve Kargl wrote:
I have attached a patch to PR114024, see
https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html
The patch contains a new testcase and passes regression
testing on
WRITE or unformatted
READ/WRITE until I get some feedback on the approach. If this approach
is OK I would like to commit and then do a separate patch for the cases
I just mentioned.
Feedback appreciated. Regression tested on x86_64. OK for trunk?
Jerry
Author: Jerry DeLisle
Date: Thu Feb 22
On 2/25/24 12:34 PM, Harald Anlauf wrote:
Hi Jerry,
On 2/22/24 20:11, Jerry D wrote:
Hi all,
The attached fix adds a check for an error condition from a UDDTIO
procedure in the case where there is no actual underlying error, but the
user defines an error by setting the iostat variable
. OK for mainline?
And a backport to 13-branch after some delay?
Thanks,
Harald
Yes, simple enough. OK.
Thanks,
Jerry
On 2/27/24 1:00 PM, Harald Anlauf wrote:
Dear all,
the attached patch fixes invalid Fortran in testcase
gfortran.dg/pr101026.f, which might prohibit progress
in fixing pr111781. (Note that the testcase was for a
tree-optimizer issue, not the Fortran frontend.)
OK for mainline?
Will commit wit
in
the library.
Regressions tested on x86_64.
OK for trunk?
Regards,
Jerry
commit 640991bd6b83df4197b2eaec63d1e0e695e48b75
Author: Jerry DeLisle
Date: Wed Feb 28 20:51:06 2024 -0800
Fortran: Add user defined error messages for UDTIO.
The defines IOMSG_LEN and MSGLEN were redundant
On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote:
On Wed, 28 Feb 2024 21:29:06 -0800
Jerry D wrote:
The attached patch adds the error checks similar to the first patch
previously committed.
I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I
consolidated this to one define in
today
if I can. Paul is unavailable for a few weeks. Harald can chime in.
Do you have commit rights for gcc?
Your efforts are appreciated.
Regards,
Jerry
On 1/20/24 11:08 AM, Jerry D wrote:
On 1/20/24 10:46 AM, Alexander Westbrooks wrote:
Hello and Happy New Year!
I wanted to follow up on this patch I made to address PR82943 for
GFortran. Has anyone had a chance to review it?
Thanks,
Alexander Westbrooks
Inserting myself in here just a
On 1/20/24 12:08 PM, Harald Anlauf wrote:
Am 20.01.24 um 20:08 schrieb Jerry D:
On 1/20/24 10:46 AM, Alexander Westbrooks wrote:
Hello and Happy New Year!
I wanted to follow up on this patch I made to address PR82943 for
GFortran. Has anyone had a chance to review it?
Thanks,
Alexander
apologize for the clutter, but we might as well get rid of it
now.
Two existing test cases needed to be adjusted and I am adding one new
test case to capture the changes in our testsuite.
Regression tested on X86_64.
OK for trunk? Do we need to backport this?
Regards,
Jerry
Author: Jerry
The following has been committed per discussion in the subject PR.
commit 95b70545331764c85079a1d0e1e19b605bda1456 (HEAD -> master,
origin/master, origin/HEAD)
Author: Jerry DeLisle
Date: Wed Dec 13 19:04:50 2023 -0800
fortran: Add degree based trig functions for F2023
Committed as simple and obvious. Initial patch thanks to Steve.
When using git gcc-commit-mklog how does one add in the coauthor?
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:add995ec117d756e61d207041cd32f937c1a1cd9
commit r14-6986
then, if no fallout, 13 at your discretion.
Regards,
Jerry
.
Thanks,
Harald
OK and thanks for patch.
Jerry
Ok and thanks.
On Fri, Aug 9, 2024, 7:33 AM Andre Vehreschild wrote:
> Ping!
>
> And the last ping in the series. I have a "bigger" patch in the queue and
> want
> the pending ones done beforehand.
>
> Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
>
> - Andre
>
> On Mon, 22 J
On 8/19/24 4:43 AM, Andre Vehreschild wrote:
Hi all,
another ping on this patch.
Regtests ok on x86_64-pc-linux-gnu on updated master. Ok for mainline?
Regards,
Andre
Looks OK to go ahead Andre.
Thanks,
Jerry
On Fri, 9 Aug 2024 16:29:08 +0200
Andre Vehreschild wrote:
Ping
On 8/20/24 5:35 AM, Andre Vehreschild wrote:
Hi all,
pinging this patch.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
Your approach looks reasonable so I think OK to push.
Thanks,
Jerry
On 6/18/24 10:20 AM, Steve Kargl wrote:
On Tue, Jun 18, 2024 at 09:13:23AM +0200, Gerald Pfeifer wrote:
The original subsite has disappeared and we couldn't find it elsewhere.
https://github.com/gklimowicz/FCVS
gklimowicz is a flang developer and member of J3.
FWIW my copy of the tests st
. If I
have some more time today I will try to come up with something.
OK for mainline?
Jerry
commit e6fa9d84cf126630c9ea744aabec6d7715087310 (HEAD -> master)
Author: Jerry DeLisle
Date: Sun Jul 21 19:19:00 2024 -0700
Fortran: Suppress wrong End Of File error with user defined
On 7/22/24 8:13 AM, Jerry D wrote:
Hi all,
The attached patch fixes this by avoiding looking for and avoiding the
EOF condition in the parent READ after returning from the child IO process.
I could not think of a simple test case yet since the problem occurred
only when redirecting the
I plan to push this soon to hopefully fix some test breakage on some
architetures. It is simple and obvious. I did not get any feedback on
this and I do not have access to the machines in question.
Regression tested on linux-x86-64.
Regards,
Jerry
commit
Hi all,
Doing some catchup here. I plan to commit the following shortly. This is
one of Steve's patches posted on bugzilla.
I have created a new test case.
Regression tested on linux x86-64.
git show:
commit 4d4549937b789afe4037c2f8f80dfc2285504a1e (HEAD -> master)
Author: Steve Kargl
Date
mentioned so I used the CHECK_INTERFACES name for the macro.
Regression tested on linux-x86_64. No new test cases.
OK for mainline? Backport?
Regards,
Jerry
Author: Jerry DeLisle
Date: Tue Aug 6 12:47:30 2024 -0700
Fortran: Eliminate error prone translations.
PR fortran/109105
d the possibility that that function
need not appear at the top level of a module, but could be a contained
function.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
OK for mainline. Thanks.
Jerry
On 01/18/2016 11:01 AM, Jerry DeLisle wrote:
> This patch follows the suggestion Jakub made in the PR and is very
> straightforward.
>
The patch is simple enough. I will commit to trunk shortly if I hear from no
one.
Regards,
Jerry
> With the patch, an abort is given on actua
On 01/23/2016 04:26 AM, Thomas Koenig wrote:
> Hi Toon,
>
>> However, today I *did* run the test harness with your modification:
>
> ...
>
> Thanks for the testing!
>
> So, what do people think? Is the patch OK for trunk?
>
> Regards
>
> Thomas
>
Yes, OK.
Jerry
om
>> show_backtrace(). This avoids a
>> segmentation fault when threads are active.
>>
>> This fixes the failure of gfortran.dg/backtrace_1.f90 on hpux.
>>
>> Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
>>
>> Okay for trunk?
>>
OK,
Jerry
Ha all,
The attached patch with new test cases fixes these by replacing gcc_assert and
updating the error message depending on whether resolving an initialization
expression or not.
Regression tested on x86-64.
OK for trunk?
Jerry
2016-01-23 Jerry DeLisle
PR fortran/69397
analysis required namespace.
>
> Bootstrapped and regtested ok on x86_64-linux-gnu/F23.
>
> Ok for trunk and gcc-5-branch, respectively?
>
OK and thanks for fixes. Much appreciated?
Jerry
Hi All,
Attached patch adds diagnostics to catch this.
Test case included. Regression tested on x86-64
OK for trunk?
Regards,
Jerry
PS Want to get this one out of the way so I can do the new namelist regression
with DELIM=NONE.
2016-02-06 Jerry DeLisle
PR fortran/50555
The attached patch reverts the guilty code. We were trying to honor delim=NONE
on namelist reads which is invalid.
Test cases updated. Regression tested on x86-64.
OK for trunk and back port in about a week?
Regards,
Jerry
2016-02-09 Jerry DeLisle
PR libgfortran/69668
* io
sage.
>
> Whoever wants to take it...
>
I will commit this under the simple rules as soon as I get the namelist
regression fix committed on trunk.
Thanks Harald
Jerry
On 02/09/2016 06:45 PM, Jerry DeLisle wrote:
> The attached patch reverts the guilty code. We were trying to honor delim=NONE
> on namelist reads which is invalid.
>
> Test cases updated. Regression tested on x86-64.
>
> OK for trunk and back port in about a week?
>
No
On 02/11/2016 10:38 AM, Janne Blomqvist wrote:
> On Wed, Feb 10, 2016 at 4:45 AM, Jerry DeLisle wrote:
>> The attached patch reverts the guilty code. We were trying to honor
>> delim=NONE
>> on namelist reads which is invalid.
>>
>> Test cases updated. Regressi
on is through making sure what we read in matches
what we wrote out to the test scratch file
Regression tested on x86_64-Linux. OK for trunk? any thoughts on back porting
to 5 since it fixes a potentially bad pointer problem in push_char4?
Regards,
Jerry
2016-02-15 Jerry DeLisle
PR l
On 02/16/2016 12:06 AM, Christophe Lyon wrote:
> On 15 February 2016 at 23:16, Janne Blomqvist
> wrote:
>> On Mon, Feb 15, 2016 at 11:45 PM, Jerry DeLisle
>> wrote:
>>> The title of the PR should be "Mishandling of namelist comments" or
>>> "
On 02/16/2016 05:17 AM, Dominique d'Humières wrote:
> Hi Jerry,
>
>> Thanks for review. Committed to trunk r233436.
>
> The test gfortran.dg/read_bang4.f90 fails on x86_64-apple-darwin15:
>
> a.out(15552,0x7fff7b2e3000) malloc: *** error for object 0x7fb472804c00:
(15,*,iostat=ios) str1, str2
> close(15)
> end program
>
> valgrind shows a lot of errors before and after the commit.
>
> Dominique
>
>> Le 16 févr. 2016 à 18:58, Jerry DeLisle a écrit :
>>
>> Up until now we have not had a test case like this for kind
On 02/16/2016 05:37 PM, Jerry DeLisle wrote:
> See patch to fix this below.
>
Committed on trunk, r233500 after regression testing, -fsanitize=address
testing, and valgrind testing.
Jerry
giving the correct item number
(always zero) so I realized the item_count was not being incremented for each
object. So fixed this as well.
Regression tested on x86-64-Linux. One new test case and one modified.
OK for trunk? Not strictly a regression, but simple enough.
Jerry
2016-02-22 Jerry
The ice on this one is actually in libcpp but I don't want to mess around in
that area. Not sure why we were only doing a warning here.
I plan to commit the following to trunk with a ChangeLog entry under the simple
and obvious rule.
Let me no if any objections.
Jerry
diff --git
This patch from Steve on c.l.f
Fixes the segfault from attempting a string compare where there is no string
yet.
Regression tested on x86-64. New test case.
OK for trunk.
Regards,
Jerry
2016-02-24 Jerry DeLisle
Steven G. Kargl
PR fortran/69110
* io.c
On 02/27/2016 01:12 PM, Tom de Vries wrote:
> On 25-02-16 01:54, Jerry DeLisle wrote:
>> This patch from Steve on c.l.f
>>
>> Fixes the segfault from attempting a string compare where there is no string
>> yet.
>>
>> Regression tested on x86-64. New test
;> * gfortran.dg/realloc_on_assign_26.f90: New test case.
>
>
Fix spelling in ChangeLog of "...callback" and OK
Jerry
t;> * dump-parse-tree.c (show_code_node): Print association
>> list of a block if present. Handle EXEC_END_BLOCK.
>
>
Yes, OK
Jerry
out and can be fixed at 6.2 or 6.3. It is the open
nature of our software and the user feedback that makes this all work. (also we
know Fortran is not release critical)
I tested with my own OOP code which is an adaptation of Metcalf's linked anylist
and it works fine. Thats the best I can do and it is fairly complex code. I
can send it to you if you would like to have it in your test pile.
Regards,
Jerry
1 - 100 of 766 matches
Mail list logo
