--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-24
21:26 ---
(In reply to comment #4)
> as a note: UNPACK also has issues with as scalar mask, maybe also with memory
> allocation
I have just submitted a patch for the memory allocation issue.
A scalar ma
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-24
21:55 ---
This has been fixed on mainline, still outstanding in 4.0
--
What|Removed |Added
Known
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-24
22:23 ---
The fix in 4.0 was incomplete, it is complete now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-24
22:40 ---
For 4-byte complex, an option is to check the alignment at runtime.
If the complex is aligned on an 8-byte boundary, it should be
perfectly OK to call the 8-byte-integer routines.
The check could be done
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-26
09:41 ---
A scalar mask is invalid for unpack, so the error message
is correct.
The memory allocation issue has been fixed for 4.0 and mainline.
Closing this bug.
--
What|Removed
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-29
12:40 ---
Configuring with --enable-maintainer-mode fails:
/home/ig25/gcc-4.0-bin/gcc/xgcc -B/home/ig25/gcc-4.0-bin/gcc/
-B/home/ig25/i686-pc-linux-gnu/bin/ -B/home/ig25/i686-pc-linux-gnu/lib/ -isystem
/home/ig25
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-29
19:32 ---
To be more precise, on i686-pc-linux-gnu, I created an empty directory, cd'd
into it, and then ran
../gcc-4.0/configure --prefix=$HOME --enable-maintainer-mode
--enable-languages=c,f95
make bootstrap
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-02
07:56 ---
Created an attachment (id=9011)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9011&action=view)
Proposed patch
This patch fixes the problems noted by Steve Kargl (wrong
types for floatin
--
What|Removed |Added
CC||tkoenig at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21881
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-02
15:49 ---
Created an attachment (id=9014)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9014&action=view)
Proposed patch
--
What|Removed
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21912
: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-06
20:22 ---
This is also a runtime error in 4.0 now.
I am changing the subject to reflect my preference that this
should be caught at compile time.
Thomas
--
What|Removed |Added
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-07
20:53 ---
Fixed in 4.1, waiting for 4.0 to reopen.
--
What|Removed |Added
Summary|matmul
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-08
18:59 ---
Slightly reduced testcase:
$ cat 21480.f90
program reshape_bug
implicit none
complex :: a(2), b(2)
a = (/(1.0, -1.0), (2.0, -2.0)/)
write(*,*) 'from'
write(*,*) a
b=reshape(a, shape(
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org |org
URL|
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-09
19:46 ---
Fixed in 4.1, waiting for 4.0 to reopen.
--
What|Removed |Added
Known to fail
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-11
20:19 ---
Fixed in 4.1, waiting for 4.0 to reopen.
--
What|Removed |Added
Known to fail
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-11
20:46 ---
>From the .t02.original file:
real4 C.476 = 1.0e+0;
struct array1_real4 atmp.0;
atmp.0.dtype = 281;
atmp.0.data = 0B;
atmp.0.offset = 0;
atmp.0.dim[0].stride
uct: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot
nedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22046
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-13
14:52 ---
Reduced testcase:
program matmul_1
integer, parameter:: N = 5
integer, parameter:: T = 4
real(kind=T), dimension(:,:), allocatable
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-13
19:49 ---
(In reply to comment #5)
> Although, unlike Steve, I am sure I'm not allowed to ok this patch, I would
> really like to see it go in too. alpha-linux really is an interesting platform
> for r
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-15
13:01 ---
This was the result of another patch that I had been trying.
I had regenerated the source file, but with the wrong timestamp
(so it wasn't recompiled, and the object file was still around,
out of
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-15
15:59 ---
Even ifort does not support this cleanly.
Look at this:
$ cat size2.f90
program main
real, dimension(:), allocatable :: a
print *,size(a)
allocate (a(5))
print *,size(a)
deallocate (a)
print
: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22124
th subrecords (Intel
style)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libfortran
AssignedTo: tkoenig at gcc dot gnu dot org
ReportedBy: tkoenig at gc
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-10-25 20:11 ---
(In reply to comment #1)
> Thomas,
>
> Have you written Adrain about his plans concerning his patch?
Not yet (I tried CC'ing him with this, but apparently this doesn't work).
IIRC (and Adrian
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-10-25 20:39 ---
This is not a maxloc bug per se. Look at this:
$ cat a9.f90
INTEGER :: K(3)=1
INTEGER, PARAMETER :: J(3)=2
write (6,*) J<1
END
$ gfortran -fdump-tree-original a9.f90
$ ./a.out
F
Output should be
F F F
inst
tial unformatted reads shouldn't succeed
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
Repo
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-10-28 18:11 ---
Uh, I forgot the actual output from the program:
$ gfortran partial.f90
$ ./a.out
ab
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29627
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-10-28 21:24 ---
Created an attachment (id=12504)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12504&action=view)
preliminary patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29627
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-10-29 11:49 ---
Created an attachment (id=12506)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12506&action=view)
updated patch
In the previous patch, I had ommitted one test too many
(the one for EOF). Here'
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-10-29 11:59 ---
(In reply to comment #3)
Hi Jerry,
> Now
> that we are in 4.3 this is a good time to do some cleanup. Overall, the
> prelminary patch approach looks good, but I have not tested yet.
There's anothe
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-10-31 20:58 ---
Subject: Bug 29627
Author: tkoenig
Date: Tue Oct 31 20:58:26 2006
New Revision: 118341
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118341
Log:
2006-10-31 Thomas Koenig <[EMAIL PROTECTED]&g
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-11-01 10:17 ---
Fixed on trunk.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Summary
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-11-03 11:22 ---
Subject: Bug 29627
Author: tkoenig
Date: Fri Nov 3 11:22:27 2006
New Revision: 118453
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118453
Log:
2006-11-03 Thomas Koenig <[EMAIL PROTECTED]&g
--- Comment #9 from tkoenig at gcc dot gnu dot org 2006-11-03 11:30 ---
Fixed on 4.2 too; will need to regtest for backporting
to 4.1.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from tkoenig at gcc dot gnu dot org 2006-11-04 14:04
---
Subject: Bug 29627
Author: tkoenig
Date: Sat Nov 4 14:04:27 2006
New Revision: 118480
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118480
Log:
2006-11-04 Thomas Koenig <[EMAIL PROTECTED]&g
--- Comment #11 from tkoenig at gcc dot gnu dot org 2006-11-04 14:05
---
Fixed on 4.1 as well, after regression-testing.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-11-05 21:31 ---
I don't know why I assigned this to myself. Brooks has
already fixed this.
Unassigning myself.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-11-05 21:48 ---
Created an attachment (id=12550)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12550&action=view)
Patch for reading only
This is a partial patch, for reading only.
I have taken the approach that we
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-11-09 20:43 ---
Created an attachment (id=12581)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12581&action=view)
patch for reading and backspace
Here's the next installment of the patch, which seems to work
OK f
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-11-11 11:18 ---
Related (and maybe more relevant):
INTENT(OUT) variables become undefined on subroutine
or function entry. We should be able to warn if
they are used:
subroutine foo(a,b)
real, intent(out) :: a
real, intent
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-11-13 19:11 ---
Created an attachment (id=12609)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12609&action=view)
newest version
Here's the newest version of the patch, which does
reading and backspace, plus defa
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-11-15 21:05 ---
(In reply to comment #7)
> Unfortunately, there was one thinko in the approach I took
> with reading. Even for subrecords, we need to be
> able to spot if we exceed recl.
>
> Back to the drawing boa
--- Comment #9 from tkoenig at gcc dot gnu dot org 2006-11-19 20:42 ---
Created an attachment (id=12646)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12646&action=view)
Latest update
Here's the latest update of the patch, for reading, writing and
backspace.
In orde
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-11-22 20:48 ---
(In reply to comment #0)
> The following example should give an EOR error.
This is one of the things that the programmer has to
get right, a processor may do anything (including
silently ignoring the error,
--- Comment #20 from tkoenig at gcc dot gnu dot org 2006-11-25 22:58
---
Created an attachment (id=12691)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12691&action=view)
Latest update
Here's the latest update.
This is fairly complete, but still lacks testing on e
--- Comment #22 from tkoenig at gcc dot gnu dot org 2006-11-26 20:39
---
Created an attachment (id=12696)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12696&action=view)
Serious attempt
Hi folks,
here is a serious attempt at the patch. Jerry, if
you could give it a sp
--- Comment #23 from tkoenig at gcc dot gnu dot org 2006-11-26 20:43
---
Created an attachment (id=12697)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12697&action=view)
Test case
Here's a test case for reading and writing with
a restricted subrecord length.
--- Comment #26 from tkoenig at gcc dot gnu dot org 2006-11-27 20:43
---
(In reply to comment #24)
> Subject: Re: implement unformatted files with subrecords
> (Intel style)
>
> I have reviewed the patch and I have one minor comment. I suggest that the
> continued
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-11-28 22:23 ---
(In reply to comment #0)
> See http://gcc.gnu.org/ml/fortran/2006-11/msg00708.html
> Reported by Chris Talley.
>
> Tested with current 4.3 and also with 4.1.
>
> Testcase, see URL; essential part
--- Comment #28 from tkoenig at gcc dot gnu dot org 2006-11-29 22:12
---
(In reply to comment #27)
Hi Jerry,
> The program fails on x86-64-freebsd and never completes the first write. It
> just keeps going, and going, and going This is a target specific issue.
> My
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-11-30 22:57 ---
bb is used uninitialized in this program, so
the program can do anything (including
starting world war III). Assuming that
non-initialized variables are set to zero
was part of a lot of legacy codes. g77
supported
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-11-30 22:57 ---
*** Bug 30029 has been marked as a duplicate of this bug. ***
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #32 from tkoenig at gcc dot gnu dot org 2006-12-01 21:04
---
Subject: Bug 29568
Author: tkoenig
Date: Fri Dec 1 21:04:38 2006
New Revision: 119412
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119412
Log:
2006-12-01 Thomas Koenig <[EMAIL PROTECTED]&g
--- Comment #33 from tkoenig at gcc dot gnu dot org 2006-12-01 21:18
---
Fixed on trunk.
I'll be waiting for some time for any regressions before
backporting to 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-12-02 21:56 ---
g77 gets this right:
$ cat eor2.f
program eor
WRITE(1) 1
REWIND(1)
READ(1,ERR=10) I,J,K
print *,"no error"
stop
10 print *,"error value"
end
$ g
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
OtherBugsDependingO 19292
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30056
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-12-03 13:59 ---
I forgot to assign this to myself. I'll do this
together with PR 30009.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-12-03 14:06 ---
(In reply to comment #6)
> For
>READ(1,ERR=10) J ! Read beyond EOF
> there are two possible implementations one finds:
> ifort: forrtl: severe (24): end-of-file during read
Really? With ifor
--- Comment #9 from tkoenig at gcc dot gnu dot org 2006-12-03 18:56 ---
I've looked at the F 2003 standard, and at least there
the wording is clear:
9.10:
# An end-of-file condition occurs in the following cases:
#
# (1) When an endfile record is encountered during reading of a
--- Comment #10 from tkoenig at gcc dot gnu dot org 2006-12-03 21:02
---
Created an attachment (id=12734)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12734&action=view)
first attempt at a patch
This should fix this PR, and PR 30056 as well.
--
http://gcc.gnu.org/b
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-12-06 19:26 ---
Subject: Bug 30056
Author: tkoenig
Date: Wed Dec 6 19:25:44 2006
New Revision: 119592
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119592
Log:
2006-12-06 Thomas Koenig <[EMAIL PROTECTED]&g
--- Comment #13 from tkoenig at gcc dot gnu dot org 2006-12-06 19:26
---
Subject: Bug 30009
Author: tkoenig
Date: Wed Dec 6 19:25:44 2006
New Revision: 119592
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119592
Log:
2006-12-06 Thomas Koenig <[EMAIL PROTECTED]&g
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-12-08 21:05 ---
Hi Tobias,
could write this into a test case for gfortran.dg?
If it broke once, we should at make sure it doesn't break again.
Thomas
--
tkoenig at gcc dot gnu dot org changed:
What|Re
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-12-08 22:54 ---
(In reply to comment #1)
>if (TYPE_PRECISION (gfc_array_index_type) == 32)
> {
>if (allocatable_array)
> - allocate = gfor_fndecl_allocate_array;
> +
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-12-08 23:35 ---
I forgot
integer, allocatable :: a(:)
integer, pointer :: b(:)
:-)
> allocate(a(4))
> ! This should set the stat code and change the size.
> allocate(a(3),stat=i)
> if (i == 0) call
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-12-09 19:03 ---
(In reply to comment #7)
> I guess it may work to only change
>
> void allocate (void **, size_t, int *)
> to
>
> void *allocate (void *, size_t, int *)
> and use it like
> de
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-12-13 21:12 ---
(In reply to comment #3)
> CC: some more libgfortran/io experienced persons.
>
> There seems to go something wrong when one uses
> format = "(1X,a,'xyz')"
> write(*,fmt=trim(
--- Comment #36 from tkoenig at gcc dot gnu dot org 2006-12-13 21:37
---
Fixed for trunk and 4.2. Will not backport to 4.1.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-12-15 21:14 ---
For writing, I think this fails because we
- write a bogus record marker with value 0
- write out the data
- write out the trailing record marker
- seek to the first record marker
- write out its value
- seek past
--- Comment #15 from tkoenig at gcc dot gnu dot org 2006-12-15 22:26
---
I have had a look at this for 4.1, and the effort
to backport this patch and the one for PR 30056 will
be fairly large.
Because 4.1 has neither stream I/O nor the subrecod
patch, fixing would require a
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-12-16 08:16 ---
As discussed on PR 30009, this is to costly to fix
for 4.1 and risks breaking things. I'm unassigning
myself in case anybody wants to tackle it.
--
tkoenig at gcc dot gnu dot org changed:
--- Comment #17 from tkoenig at gcc dot gnu dot org 2006-12-16 08:18
---
I'm leaving this open for now, but
unassigning myself. If anybody wants
to tackle this for 4.1, feel free.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30009
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-12-16 11:44 ---
(In reply to comment #1)
> These seeks actually translate to OS calls, which of course fails
> for pipes.
We could get by for writing if we
- eliminated the seeks as long as we don't actually go past
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30288
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-12-26 12:15 ---
(In reply to comment #1)
>
> Index: gcc/fortran/scanner.c
> ===
> --- gcc/fortran/scanner.c (Revision 120144)
> +++ gcc/fo
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-12-28 21:20 ---
Confirmed, the crash is within the library:
$ gfortran -g xzero_size_array.f90
$ gdb ./a.out
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-12-28 21:22 ---
This is deep regression country; in the time
I have to devote to this, I couldn't work it out.
Unassigning myself (for now).
--
tkoenig at gcc dot gnu dot org changed:
What|Re
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-12-28 21:39 ---
Additional data points:
Reading/writing unformatted sequential doesn't work with g77
(fails with an error message on open), and it fails with ifort 8
for records longer than 2**18 bytes (ifort's default b
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-12-29 09:50 ---
I'll do this.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-12-29 09:51 ---
(In reply to comment #5)
> I will work at it.
Thanks, I'll be happy to assist with discussions and review.
(Those who can, fix; those who can't, review :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-12-30 13:16 ---
Subject: Bug 30321
Author: tkoenig
Date: Sat Dec 30 13:16:36 2006
New Revision: 120287
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120287
Log:
2006-12-30 Thomas Koenig <[EMAIL PROTECTED]&g
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-01-01 15:17 ---
(In reply to comment #7)
> I have formatted named pipe I/O working, at least for the equivalent test
> cases
> given here.
Great!
If you want me to, I'll be willing to test your patch.
Thoma
--- Comment #10 from tkoenig at gcc dot gnu dot org 2007-01-02 22:08
---
(In reply to comment #9)
> Preliminary patch for formatted only.
Looks pretty good, at least the tests pass.
> Index: io/unix.c
> ===
nedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30398
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-01-06 22:07 ---
(In reply to comment #0)
> The compiler should be able to detect that s and c
> are not aliased, so a call to memcpy instead of memmove
> could be issued.
Or, even better, the memmove/memcpy could be
--- Comment #14 from tkoenig at gcc dot gnu dot org 2007-01-06 22:26
---
Another difficult case is:
program main
character(len=4) c
c = 'ab '
write (10) trim(c)
end program main
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
roduct: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-01-07 11:04 ---
Actualy, there aren't, I was confused.
Sorry :-)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-01-07 22:33 ---
This would definitely be useful.
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from tkoenig at gcc dot gnu dot org 2007-01-08 07:45
---
I was just looking at the gfc_simplify_transfer function, and
it appears it isn't called for the original test program.
Any idea why?
--
tkoenig at gcc dot gnu dot org changed:
What|Re
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-01-09 20:44 ---
Yep.
I'll have a look.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-01-09 21:30 ---
Created an attachment (id=12873)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12873&action=view)
patch (currently regtesting)
This fixes the test case. It's currently in regression t
1401 - 1500 of 1518 matches
Mail list logo
