--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-08-24 00:24
---
I will delete the test tonight shortly. Will add a new one later
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28813
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-08-24 01:11
---
Subject: Bug 28813
Author: jvdelisle
Date: Thu Aug 24 01:10:55 2006
New Revision: 116368
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116368
Log:
2006-08-23 Jerry DeLisle <[EMAI
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-08-25 17:09
---
On x86-64 linux:
(gdb) set args ' as free form.
.file ""
In file :598
use ModelParams
1
Error: The derived type 'p' at (1) is of type 'pp', w
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-08-26 21:27
---
With latest svn update and full bootstrap with Martins case above on
i686-linux-pc-gnu:
(gdb) r
Starting program: /home/jerry/bin/f951 ' as free form.
.file ""
Program received
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-08-28 05:14
---
Subject: Bug 28354
Author: jvdelisle
Date: Mon Aug 28 05:14:05 2006
New Revision: 116502
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116502
Log:
2006-08-27 Jerry DeLisle <[EMAI
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-08-28 05:17
---
Subject: Bug 28354
Author: jvdelisle
Date: Mon Aug 28 05:17:09 2006
New Revision: 116503
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116503
Log:
2006-08-27 Jerry DeLisle <[EMAI
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-08-28 05:18
---
Fixed on 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-08-31 05:28
---
Setting the parameter n=65535, the program appears to execute correctly.
However, the pr28914.f90.003t.original file is 706800 bytes long and embedded
with a very large static declaration of the array. As if it
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-09-01 17:37
---
I think this should just be closed and leave gfortran as is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23889
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-09-01 19:14
---
Current gfortran is handling this correctly
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-09-01 19:16
---
I am looking into this a little. setWunused is called which calls SetWextras.
Just a little tweaking we need to do here I think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25403
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-09-01 19:34
---
oops disregard that last comment. Typed in the wrong box.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25403
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-09-02 19:24
---
I tested the provisional patch on i686-linux-pc-gnu.
Had to set tmp_loopvar = NULL when declared to avoid warning message on
possibly uninitialized variable.
Fixes the test case in this PR. Regression testsd
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-09-03 03:44
---
Just an added note. Compile time for large values of n is very long. Many
seconds. For n - 2000
$ time gfc pr28914.f90
real1m5.009s
user1m3.896s
sys 0m0.048s
This is on 3.2 gigahertz machine
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28947
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-09-04 19:33
---
The proposed change in comment #8 appears to give several testsuite failures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28914
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-09-04 23:11
---
Well I confirmed this is not on cygwin. Now I have to build a mingw version.
Sorry this is taking so long.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-09-09 01:17
---
Please upgarde to at least 4.1 version of gfortran. This compiles fine for me
with latest gfortran 4.2. 100's of bugs have been fixed since 4.0 series.
--
jvdelisle at gcc dot gnu dot org ch
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-09-10 04:18
---
Apatch for this bug has been submitted to the fortran list for approval.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-09-10 04:53
---
Subject: Bug 28914
Author: jvdelisle
Date: Sun Sep 10 04:53:18 2006
New Revision: 116808
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116808
Log:
2006-09-09 Paul Thomas <[EMAI
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-09-10 04:58
---
Subject: Bug 28914
Author: jvdelisle
Date: Sun Sep 10 04:58:29 2006
New Revision: 116809
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116809
Log:
2006-09-09 Jerry DeLisle <[EMAI
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-09-10 05:05
---
This bug is related to slow compile found in test case for PR28914 with large
array size. Constructor related.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-09-10 05:07
---
Fixed on 4.2 only, Follow PR20923 for long compile time issues.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-09-11 01:34
---
Another example showing this is not specific to DATA statements, but is related
to parsing the initilizer.
program FOO
character*20 Y /'Abcdef'/ garbage
end program FOO
$ gfc pr27954.f90
In file p
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-09-11 01:40
---
I can coax a segfault out of this:
program FOO
character*20 Y /'Abcdef'/ 0
print *, Y
end program FOO
$ gfc pr27954.f90
In file pr27954.f90:2
character*20 Y /'Abcdef'/ 0
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-09-13 00:21
---
Thanks for taking the time to figure this out. I just have not had the time to
get setup to investigate. I am unassigning myself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
y: Consecutive STREAM I/O file positions mixed up
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jvdelisle a
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-09-14 01:21
---
Assembly output which does not work because it is using the same block of
memory for the st_parameter_dt structure for both WRITEs, the file position
pointer is in this structure, but not set before the calls
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-09-15 13:16
---
Subject: Bug 29053
Author: jvdelisle
Date: Fri Sep 15 13:16:15 2006
New Revision: 116970
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116970
Log:
2006-09-14 Jerry DeLisle <[EMAI
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-09-15 13:32
---
Subject: Bug 29053
Author: jvdelisle
Date: Fri Sep 15 13:32:12 2006
New Revision: 116971
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116971
Log:
2006-09-15 Jerry DeLisle <[EMAI
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-09-15 13:33
---
Fixed on 4.2, will not go to 4.1.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-09-15 13:35
---
Fixed on 4.2, will not go to 4.1
*** This bug has been marked as a duplicate of 29053 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-09-15 13:35
---
*** Bug 28747 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29053
With little or no delay between calls to secnds the wrong result is given:
secnds.f:
character*20 dum1, dum2, dum3
real t1, t2
real dat1, dat2
real dt
integer i, j, values(8)
dt = 40e-3
t1 = secnds (0.0)
call date_and_time (dum1, dum2, dum3, values)
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-09-15 15:51
---
Patch to fix this:
Index: intrinsics/date_and_time.c
===
*** intrinsics/date_and_time.c (revision 116941)
--- intrinsics/date_and_time.c (working
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-09-15 16:04
---
Subject: Bug 29099
Author: jvdelisle
Date: Fri Sep 15 16:03:52 2006
New Revision: 116975
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116975
Log:
2006-09-15 Jerry DeLisle <[EMAI
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-09-15 16:08
---
Subject: Bug 29099
Author: jvdelisle
Date: Fri Sep 15 16:07:53 2006
New Revision: 116976
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116976
Log:
2006-09-15 Jerry DeLisle <[EMAI
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-09-15 16:08
---
Fixed on 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-09-16 01:28
---
Confirmed: As can be seen here. We are allocating, but not freeing pstr.6
{
char[1:D.960] * pstr.6;
int4 D.960;
int4 D.959;
char[1:_input] & D.958;
static struct _jump_struct jumptable
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-09-17 20:14
---
Problem is not in library side.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-09-20 03:48
---
I think this is fixed. If I increase the size of the parameter I get the
expected error message.
program kk
implicit none
integer, parameter :: N=65535, M=N/2-1
real, dimension(N,N):: input
call
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-09-20 04:47
---
Confirmed
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #26 from jvdelisle at gcc dot gnu dot org 2006-09-25 05:53
---
Paul,
OK here too. i686-linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-09-27 00:55
---
The only solutions to this problem I see is to either:
1. close this bug and leave the test case deleted or
2. write a C function to query for disk space and if enough available, proceed
with the test.
I am
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-09-27 01:26
---
Can you provide a small working example of what you are trying to do?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29240
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-09-28 22:39
---
Closing, test not needed.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-09-28 22:40
---
I have this one fixed and will combine it with the pathes for 19260 and 19262.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19261
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-09-28 23:23
---
Please note that with formatted stream I/O we implicitly write a /n or /r/n in
the next_record_w () function in transfer.c depending on the system. I think
this meets the intent.
Now an issue I see is what if
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-09-28 23:36
---
Another thought occurs to me. With formatted stream I/O the newline is handled
automatically for the user. However, there is nothing to say someone would not
want to use unformatted stream I/O to write human
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-09-30 21:09
---
I will see if I can spot something here. Jack, I will need your help testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-09-30 21:36
---
Valgrind shows tight as a drum on i686-linux. Do you have something equivalent
to valgrind for Darwin PPC?
I am not seeing anything obvious in the code. On i686 the call at line 496 is
to atoi(). Your system
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-09-30 21:53
---
Jack, I would forward this one to Apple.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jvdelisle at gcc dot gnu dot org
GCC host triplet: linux-ppc, darwin-ppc, linux-x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29313
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-10-01 23:50
---
>From the gfortran list:
Reviewing my buildlog of gcc trunk on Darwin PPC, I noticed
we have the warning...
/sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/g
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2006-10-02 04:15
---
alloc_comps0929.diff tests OK for me on i686-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-03 02:17
---
Yes, make sure you do a complete clean rebuild. You may also need this for the
PR29327.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29317
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-03 03:58
---
Subject: Bug 19260
Author: jvdelisle
Date: Tue Oct 3 03:58:20 2006
New Revision: 117384
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117384
Log:
2006-10-02 Jerry DeLisle <[EMAIL PROTECTE
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-03 03:58
---
Subject: Bug 19262
Author: jvdelisle
Date: Tue Oct 3 03:58:20 2006
New Revision: 117384
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117384
Log:
2006-10-02 Jerry DeLisle <[EMAIL PROTECTE
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-10-03 04:10
---
Subject: Bug 19260
Author: jvdelisle
Date: Tue Oct 3 04:09:49 2006
New Revision: 117385
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117385
Log:
2006-10-02 Jerry DeLisle <[EMAI
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-10-03 04:10
---
Subject: Bug 19262
Author: jvdelisle
Date: Tue Oct 3 04:09:49 2006
New Revision: 117385
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117385
Log:
2006-10-02 Jerry DeLisle <[EMAI
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-10-03 04:11
---
Fixed on 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-10-03 04:12
---
Fixed on 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-10-04 05:28
---
OK, I confess I sen a note to Richard Maine to doble check on this. Brooks has
it absolutely right. So, I will see what I can come up with for you. If its a
requirement of the standard, it is not an
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-10-04 06:28
---
Oops. This is F2003 issue and therfore an enhancement relative to F95.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-10-09 03:07
---
Created an attachment (id=12398)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12398&action=view)
Preliminaey patch for STREAM formatted read.
There is a related problem with formatted stre
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-09 03:38
---
I expect the test case streamio_4.f90 to fail with the preliminary patch. I
have not completed the formatted stream write portion. What I need confirmed
is that when reading that the file is being positioned
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-10-13 01:41
---
Note: I believe it may be necessary to explicitly inject a '\r' when a '\n' is
embedded in a string. I am not quite set up to test this yet here. So I would
much appreciate if some one
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-10-13 16:24
---
Not specific to Suze, Confirmed on i686-linux. Interesting bug.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-10-14 15:06
---
Subject: Bug 19261
Author: jvdelisle
Date: Sat Oct 14 15:06:34 2006
New Revision: 117733
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117733
Log:
2006-10-14 Jerry DeLisle <[EMAI
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-10-14 15:16
---
Fixed on svn trunk. Note: Could not get a test case to work properly with the
dejagnu machinery.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-10-14 15:38
---
Paul, should this be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-10-14 19:37
---
Oh, It was comment 11 that threw me off. Thats why I asked. Let me think
about takingthis on before I do so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-10-18 04:04
---
Subject: Bug 29277
Author: jvdelisle
Date: Wed Oct 18 04:04:07 2006
New Revision: 117846
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117846
Log:
2006-10-17 Jerry DeLisle <[EMAI
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-10-18 04:08
---
Subject: Bug 29277
Author: jvdelisle
Date: Wed Oct 18 04:08:30 2006
New Revision: 117847
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117847
Log:
2006-10-17 Jerry DeLisle <[EMAI
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-10-18 06:03
---
There is one final patch to go before closing this PR. I am testing it now and
developing a test case. This is the part that converts LF to CR-LF for
FORMATTED STREAM IO on those systems that #define HAVE_CRLF
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-10-18 23:13
---
Subject: Bug 29277
Author: jvdelisle
Date: Wed Oct 18 23:13:33 2006
New Revision: 117866
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117866
Log:
2006-10-18 Jerry DeLisle <[EMAI
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-10-18 23:23
---
Fixed on 4.2.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:24
---
I believe this is a duplicate of PR18923. What I am finding is that under some
error conditions, we end up with empty symbols. When gfc resolve is executed
we are bumping into this arror because the sym->n
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:26
---
*** This bug has been marked as a duplicate of 27954 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:26
---
*** Bug 18923 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:54
---
Another test case with similar error:
program friend
character*20 y, x 0
data y /'abcdef'/, x /'jbnhjk'/ o
print *, "basketcase"
end program friend
$ gfc pr27954.f90
In f
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2006-10-20 14:27
---
This does not fix it, but I think the idea is in the right direction. There
are multiple error return paths like this that are not cleaning up enough.
This explains why making variations on the test case gives
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2006-10-20 14:33
---
Correction: The patch in #16 fixes the case in #11. However I have several
other variations on this that are taking a different error path.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-10-20 16:25
---
To make you feel better. I have found the other spots. Those are fixed as
well and regression tested AOK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-21 00:16
---
I will see what I can figure out here now.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-01-26 03:37
---
I can reproduce this on non-darwin machine. Erik you were going to suggest a
patch? If you want, I will review this for you. I wonder if this is related
to changes I made to allow large iolengths, ie 64-bit
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-01-26 06:19
---
Can this PR be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30411
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-01-26 16:11
---
I understand Erik's concern. -malign-double makes a significant performance
difference on some of these machines and is commonly used.
The surest way to handle this is to put compute intensive code in sep
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-01-26 17:25
---
Subject: Bug 30481
Author: jvdelisle
Date: Fri Jan 26 17:25:06 2007
New Revision: 121207
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121207
Log:
2007-01-26 Jerry DeLisle <[EMAI
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-01-26 17:25
---
Subject: Bug 30532
Author: jvdelisle
Date: Fri Jan 26 17:25:06 2007
New Revision: 121207
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121207
Log:
2007-01-26 Jerry DeLisle <[EMAI
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-01-26 17:28
---
Subject: Bug 30481
Author: jvdelisle
Date: Fri Jan 26 17:28:07 2007
New Revision: 121208
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121208
Log:
2007-01-26 Jerry DeLisle <[EMAI
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-01-26 17:28
---
Subject: Bug 30532
Author: jvdelisle
Date: Fri Jan 26 17:28:07 2007
New Revision: 121208
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121208
Log:
2007-01-26 Jerry DeLisle <[EMAI
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-01-26 17:29
---
Fised on 4.2 and 4.3
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-01-26 17:30
---
Fixed on 4.2 and 4.3
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-01-27 21:51
---
I recall some time ago working on the patch that enabled this feature.
I agree this is probably platform specific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-01-28 22:15
---
In the spirit of Paul's suggestion. I will try this one.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-01-30 14:36
---
Paul's preliminary patch for pr30284 fixes this bug. The library side still
shows a potential problem, but we don't hit it with the test cases here because
we are only reading one record.
Here i
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-01-30 23:24
---
Un-assigning myself. Don't have time to delve into the deeper problem here
which may require changes to array descriptors. After brief exchange with Paul
off list.
--
jvdelisle at gcc dot gnu dot org ch
601 - 700 of 3058 matches
Mail list logo
