https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841
--- Comment #4 from Jerry DeLisle ---
I will commit this:
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 3ca23493..753dc5ad 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -3732,7 +3732,7 @@ check_symbol_not_point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841
--- Comment #5 from Jerry DeLisle ---
Author: jvdelisle
Date: Sat Mar 4 03:13:34 2017
New Revision: 245891
URL: https://gcc.gnu.org/viewcvs?rev=245891&root=gcc&view=rev
Log:
2017-03-03 Jerry DeLisle
PR fortran/79841
* openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #11 from Jerry DeLisle ---
Created attachment 40885
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40885&action=edit
A preliminary patch. Any and all testing greatly appreciated.
I am regression testing this now. I wanted to ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #12 from Jerry DeLisle ---
Here is a modified test case where I test the iotype and if its is NAMELIST, I
format the output to what would be expected. Since there is no user defined
namelist read, it just uses default reading of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670
--- Comment #2 from Jerry DeLisle ---
Preliminary patch given in PR78854
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79930
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79930
--- Comment #6 from Jerry DeLisle ---
Thanks Thomas, somehow I thought we would have built the temporary to do this.
(Well actully we do, but after the frontend passes)
Now we get:
$ gfc -O2 tp_array.f90
$ time ./a.out
This code variant uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79484
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79484
--- Comment #3 from Jerry DeLisle ---
Using LOC is not the right way to do these things. You should use bind(c) on
the fortran side.
I think you can google help with this.
Power8 systems are less forgiving then others. I dont get any errors on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #13 from Jerry DeLisle ---
Author: jvdelisle
Date: Sat Mar 11 14:49:57 2017
New Revision: 246070
URL: https://gcc.gnu.org/viewcvs?rev=246070&root=gcc&view=rev
Log:
2017-03-11 Jerry DeLisle
PR libgfortran/78854
* i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #7 from Jerry DeLisle ---
This is interesting.
If I use:
read( unit=s, fmt='(DT)', iostat=istat, iomsg=imsg ) foo
then we do not lose the first character. However, the loop in the dtio
procedure does not exit.
So I inserted in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #14 from Jerry DeLisle ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
Bug 78661 depends on bug 78854, which changed state.
Bug 78854 Summary: [F03] DTIO namelist output not working on internal unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #23 from Jerry DeLisle ---
(In reply to janus from comment #22)
> (In reply to janus from comment #21)
> > The testcase seems to be working properly by now, but unfortunately the
> > patch breaks dtio_25.f90 (execution test), i.e. the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #24 from Jerry DeLisle ---
I dont think the parent is suppose to emit the Object name. What if there are
multiple comments?
should be:
I dont think the parent is suppose to emit the Object name. What if there are
multiple components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
--- Comment #6 from Jerry DeLisle ---
(In reply to Walt Brainerd from comment #1)
> Forgot to add:
>
> Pls see F08 std 9.6.3(7) 2nd bullet
I see:
BULLET: If a list item of derived type in a formatted input/output statement is
not processed by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
--- Comment #8 from Jerry DeLisle ---
(In reply to Walt Brainerd from comment #7)
> I took "not processed by" to mean that there is no DT edit descriptor
> corresponding to it.
>
> But I see how this might be interpreted otherwise.
>
> Intel ag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #9 from Jerry DeLisle -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #26 from Jerry DeLisle ---
(In reply to janus from comment #25)
> (In reply to Jerry DeLisle from comment #24)
> > I dont think the parent is suppose to emit the Object name. What if there
> > are multiple components?
>
> Huh, I'm no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382
--- Comment #9 from Jerry DeLisle ---
Can this be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #27 from Jerry DeLisle ---
With the patch applied and the following test case:
MODULE m
IMPLICIT NONE
TYPE :: t
integer :: j
CHARACTER :: c
integer :: k
CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499
--- Comment #8 from Jerry DeLisle ---
I will take care of it. Thanks Nicolas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499
--- Comment #10 from Jerry DeLisle ---
Very good question, maybe we do:
if (p)
gfc_release_symbol (p);
I will try it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499
--- Comment #11 from Jerry DeLisle ---
Always helps to double check. The three original test cases do not ICE on
trunk and gfc_release_symbol is already NULL guarded internally. I would not
chase this further on trunk for the first three cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841
--- Comment #8 from Jerry DeLisle ---
(In reply to Roland Illig from comment #6)
> Could you perhaps make all 6 messages in that function follow the same
> syntax?
Will do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841
--- Comment #9 from Jerry DeLisle ---
Author: jvdelisle
Date: Fri Mar 17 18:21:08 2017
New Revision: 246241
URL: https://gcc.gnu.org/viewcvs?rev=246241&root=gcc&view=rev
Log:
2017-03-17 Jerry DeLisle
PR fortran/79841
* openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841
--- Comment #10 from Jerry DeLisle ---
Fixed on trunk
Can this be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573
--- Comment #7 from Jerry DeLisle ---
intrinsic.c contains a similar error message:
if (!gfc_check_intrinsic_standard (isym, &symstd, false, loc)
&& !sym->attr.artificial)
{
if (sym->attr.proc == PROC_UNKNOWN && warn_intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #9 from Jerry DeLisle ---
Created attachment 41014
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41014&action=edit
Preliminay Patch
Here is a preliminary patch. I have spent a lot of time looking at the DTIO
problem case as we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #10 from Jerry DeLisle ---
The test cases I have been working on uses:
read( unit=s, fmt='(dt)', iostat=istat, iomsg=imsg, pad='yes' ) foo
versus:
read( unit=s, fmt=*, iostat=istat, iomsg=imsg, pad='yes' ) foo
With fmt=*, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #11 from Jerry DeLisle ---
I finally figured out what is happening.
The parent READ begins with eating any leading spaces. If a non-space character
is found, rather than seek backward (which can't be done with some units) we
unget t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #12 from Jerry DeLisle ---
Another issue:
In the case with file I/O if the child procedure consumes the EOR character,
upon return, the parent is also wanting to complete the EOR the check for EOR
and hits EOF.
Lets see what I get f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #13 from Jerry DeLisle ---
Author: jvdelisle
Date: Sat Mar 25 18:48:01 2017
New Revision: 246478
URL: https://gcc.gnu.org/viewcvs?rev=246478&root=gcc&view=rev
Log:
2017-03-25 Jerry DeLisle
PR libgfortran/78881
* i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670
--- Comment #3 from Jerry DeLisle ---
With latest patches on trunk, I get this:
$ ./a.out
Got ' '
Got '='
At line 72 of file pr78670.f03
Fortran runtime error: End of file
A minor problem with the test case is
IF (ch /= '') THEN
should be
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670
Jerry DeLisle changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
Depends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670
--- Comment #6 from Jerry DeLisle ---
(In reply to janus from comment #5)
> (In reply to Jerry DeLisle from comment #4)
> > Janus, the fix for this bug depends on your patch for pr78661. I would like
> > to incorporate yours into the solution to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
Jerry DeLisle changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78793
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670
--- Comment #7 from Jerry DeLisle ---
Good news, I have this sorted out and working now with Janus patch for the
namelist write portion.
We were calling the child procedure too early in nml_get_obj_data when we
should have called it in nml_read_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #18 from Jerry DeLisle ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #17)
>
> ro@colima 27 >
> LD_LIBRARY_PATH=../../../sparc-sun-solaris2.12/sparcv9/libgfortran/.libs
> ./dtio_26.exe
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #20 from Jerry DeLisle ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #19)
> [...]
>
> Here's the output I get:
>
> 63
>
> 65
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670
Bug 78670 depends on bug 78661, which changed state.
Bug 78661 Summary: [OOP] Namelist output missing object designator under DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670
--- Comment #8 from Jerry DeLisle ---
Author: jvdelisle
Date: Wed Mar 29 21:37:45 2017
New Revision: 246576
URL: https://gcc.gnu.org/viewcvs?rev=246576&root=gcc&view=rev
Log:
2017-03-29 Jerry DeLisle
PR libgfortran/78670
* io
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80305
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jvdelisle at gcc dot gnu.org
Target Milestone: ---
The following test case shows the wrong behavior. I am pretty sure this is
frontend related. Notice that derived types work OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #24 from Jerry DeLisle ---
(In reply to Christophe Lyon from comment #23)
> (In reply to Jiong Wang from comment #22)
> > (In reply to Rainer Orth from comment #15)
> > > The new testcase FAILs on 64-bit Solaris/SPARC:
> >
> > + AArc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #26 from Jerry DeLisle ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #25)
--- snip ---
>
> Btw., I happened to notice that this "int * length" (and many more
> instances throughout the file and probably all of libgfortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59910
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59910
--- Comment #9 from Jerry DeLisle ---
(In reply to Dominique d'Humieres from comment #8)
> > > It does for me provided the patch is applied at the proper location:
> > >
> > > @@ -2657,6 +2657,12 @@ gfc_match_structure_constructor (gfc_sym
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80388
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
Assignee: unassigned at gcc dot gnu.org
Reporter: jvdelisle at gcc dot gnu.org
Target Milestone: ---
program vincenty
implicit none
integer, parameter :: wp = selected_real_kind (18) ! Working Precision
real(wp), parameter :: f = 1.0_wp/298.257223563_wp
real(wp), parameter :: pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82372
--- Comment #1 from Jerry DeLisle ---
Another, reduced:
program vincenty
implicit none
integer, parameter :: wp = selected_real_kind (18) ! Working Precision
real(wp), parameter :: f = 1.0_wp/298.257223563_wp
real(wp) :: tmp
tmp = 1.0 − f
en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82372
--- Comment #2 from Jerry DeLisle ---
$ cat bug1.f90
program vincenty
implicit none
real, parameter :: f = .2345
real :: tmp
tmp = 1.0 − f
end program
$ gfc49 bug1.f90
bug1.f90:7:
tmp = 1.0 \xE2\x88\x92 f
1
Error: Unclassifiable statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82007
--- Comment #5 from Jerry DeLisle ---
The ice is because we are not handling the case where the expreesion is type
function vs character expression or character constant. I am thinking we need
to simplify the expression before trying to use it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81499
--- Comment #2 from Jerry DeLisle ---
Just doing a quick scan here. Has anuone tried allocating the dtv1...4 before
the I/O calls. I think i can see where th einternal runtime is trying to pass
interal pointers to the DTIO procedures and an unal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81937
--- Comment #2 from Jerry DeLisle ---
Added Thomas to cc since he is peeking at I/O things I think.
at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
Severity|enhancement |normal
--- Comment #5 from Jerry DeLisle ---
I think originally this was an enhancement becasue we were focused on F95 back
in 2009, now we are going for 2015 stuff so this one is higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40196
--- Comment #6 from Jerry DeLisle ---
This works:
type tp(dim)
integer, KIND :: dim = 3
real :: dist(dim)
end type tp
type(tp) :: t(5)
print *, t%dist(2)
print *, t
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #11 from Jerry DeLisle ---
Thanks for getting this profile. I agree, delete_root is to be looked at. Was
this profile on trunk? Can you also post one for gcc6 or earlier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #14 from Jerry DeLisle ---
The real issue is that to support DTIO with internal units I had to actually
use a gfc_unit structure. Before DTIO we never did this. At the time of doing
DTIO I did not have a 'better idea' since by the na
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #15 from Jerry DeLisle ---
For my own baseline:
gcc6: real 0m6.948s
gcc7: real 0m9.906s
gcc8: real 0m10.415s
I backported removal of the caching mentioned in comment #14 to gcc7. The two
should be identical except t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410
--- Comment #30 from Jerry DeLisle ---
(In reply to Dominique d'Humieres from comment #28)
--- snip ---
> BTW what is the best expression in English "already is" or "is already", the
> later being easier to parse for French readers.
"is already"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #20 from Jerry DeLisle ---
(In reply to Thomas Koenig from comment #19)
> Created attachment 42320 [details]
> patch which failes with dtio_14 and dtio_15, among others
>
> Well, this one doesn't work yet.
Do you want to continue wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57096
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57096
--- Comment #11 from Jerry DeLisle ---
(In reply to janus from comment #8)
> (In reply to Jerry DeLisle from comment #7)
> > Let's close this one.
>
> Please don't. I still see the wrong output with gfortran 7.2.
>
> Dominique, did you consider
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57096
--- Comment #14 from Jerry DeLisle ---
The reduced test case with gfortran 7.2.1 O get:
$ ./test
1 1
0 1
and the original:
$ ./test
gA%next(): 0
gA%next(): 0
gA%next():
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57096
--- Comment #15 from Jerry DeLisle ---
(In reply to Dominique d'Humieres from comment #6)
> I get
>
> gA%next(): 2
> gA%next(): 4
> gA%next(): 6
>
> gAp%next(): 2
> gAp%next(): 4
> gAp%nex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81938
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81938
--- Comment #7 from Jerry DeLisle ---
Author: jvdelisle
Date: Fri Oct 27 17:50:22 2017
New Revision: 254163
URL: https://gcc.gnu.org/viewcvs?rev=254163&root=gcc&view=rev
Log:
2017-10-27 Jerry DeLisle
Rimvydas (RJ)
PR libg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81938
--- Comment #8 from Jerry DeLisle ---
Author: jvdelisle
Date: Fri Oct 27 18:51:35 2017
New Revision: 254169
URL: https://gcc.gnu.org/viewcvs?rev=254169&root=gcc&view=rev
Log:
2017-10-27 Jerry DeLisle
Rimvydas (RJ)
Backpor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81938
--- Comment #9 from Jerry DeLisle ---
I think this can be closed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #15 from Jerry DeLisle ---
(In reply to Paul Thomas from comment #14)
> PS If I remove the STAT= from the allocate, the code runs just fine in DEV
> mode.
>
> Paul
I have not looke at this one. Have you tried with valgrind or saniti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82866
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865
--- Comment #4 from Jerry DeLisle ---
I would be OK with a hard error. If so, we need to think about any other
similir situations with other modern fortran features. Then we get into a game
of chasing more rabits. Perhaps best to document and jus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #23 from Jerry DeLisle ---
Well, instrumenting a little bit I see that delete_root is getting called many
many many times. So, every call to newunit_alloc is assigning a new unit number
which is getting added to the treap and never re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
--- Comment #33 from Jerry DeLisle ---
(In reply to Janne Blomqvist from comment #32)
> Interestingly, Linux 4.14 contains a way to avoid a context switch to a
> threadpool in case the data is already in the page cache:
> https://kernelnewbies.or
||jvdelisle at gcc dot gnu.org
--- Comment #4 from Jerry DeLisle ---
(In reply to Dominique d'Humieres from comment #3)
> > > Could you please provide the file(s) needed to generate
> > > local_field_module.mod?
> >
> > I suspect the source code in qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #24 from Jerry DeLisle ---
After a minor test tweak.
$ gfc -static pr78549.f
$ time ./a.out
real0m24.049s
user0m22.941s
sys 0m0.962s
$ gfc6 -static pr78549.f
$ time ./a.out
real0m22.838s
user0m22.718s
sys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83057
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #25 from Jerry DeLisle ---
Author: jvdelisle
Date: Tue Nov 21 02:17:11 2017
New Revision: 254982
URL: https://gcc.gnu.org/viewcvs?rev=254982&root=gcc&view=rev
Log:
2017-11-20 Jerry DeLisle
PR libgfortran/78549
* i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #26 from Jerry DeLisle ---
Author: jvdelisle
Date: Thu Nov 23 17:19:18 2017
New Revision: 255108
URL: https://gcc.gnu.org/viewcvs?rev=255108&root=gcc&view=rev
Log:
2017-11-23 Jerry DeLisle
Backport from trunk
PR l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #27 from Jerry DeLisle ---
This should be fixed now fairly well. At this point there are not a lot of
major issues in our own libgfortran library. I will leave this bug report open
for a while if any issues arise.
Here is my latest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83152
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
||2017-11-26
CC||jvdelisle at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jerry DeLisle ---
I will look into
801 - 900 of 2295 matches
Mail list logo
