--- Comment #22 from cvs-commit at gcc dot gnu dot org 2005-10-23 06:59
---
Subject: Bug 18022
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-23 06:59:18
Modified files:
gcc/fortran: trans-expr.c iresolve.c ChangeLog
--- Comment #23 from cvs-commit at gcc dot gnu dot org 2005-10-23 15:46
---
Subject: Bug 18022
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-23 15:46:10
Modified files:
gcc/fortran: trans-expr.c
--- Comment #24 from pault at gcc dot gnu dot org 2005-10-23 16:25 ---
Fixed on mainline and 4.0
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18022
--- Comment #21 from pault at gcc dot gnu dot org 2005-10-13 04:48 ---
I have posted another, better patch to the list:
http://gcc.gnu.org/ml/fortran/2005-10/msg00271.html
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18022
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-08-03
10:01 ---
Tobi,
We should agree the condition by which the call to gfc_trans_arrayfunc_assign
is bypassed and get this one out of the way. The original, posted to the list,
had:
expr1-symtree-n.sym-ts.type ==
--- Additional Comments From tobi at gcc dot gnu dot org 2005-07-10 16:58
---
I had an IRC conversation with Paul Brook about this. Here's what we concluded:
pbrook There are two solutions. (a) Align all components of derived types to
component size boundaries. (b) Express pointer
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-10
17:22 ---
Subject: Re: problem with structure and calling a function
tobi at gcc dot gnu dot org wrote:
IOW, fixing the underlying bug is out-of-reach. The original bug can be fixed
by forcing the function result
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-10
17:25 ---
Subject: Re: problem with structure and calling a function
I notice that I did not change the comment - I though that it was a
waste of time to clean it up!
Paul T
--
--- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-07-10 17:37 ---
Subject: Re: problem with structure and calling a function
paulthomas2 at wanadoo dot fr wrote:
--- 2213,2226
tree tmp;
stmtblock_t block;
stmtblock_t body;
!
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-10
17:52 ---
Subject: Re: problem with structure and calling a function
I should probably have said why I don't like this: this will probably not work
with derived types which have a component of the same type as is
--- Additional Comments From tobi at gcc dot gnu dot org 2005-07-09 11:34
---
Adding Paul to the CC list.
Paul, I don't understand how the optimisation
brought about by the call to gfc_trans_arrayfunc_assign is simply not
applicable in this case. Can you elaborate?
What I fail to
--- Additional Comments From tobi at gcc dot gnu dot org 2005-07-09 11:39
---
Ah, ok, I guess I understand the problem now. Not going via a temporary would
still be possible if we were able to setup an array descriptor which points to
the right elements of the structure.
--
--- Additional Comments From tobi at gcc dot gnu dot org 2005-07-09 11:47
---
For the record, in the testcase Paul posted together with his patch
http://gcc.gnu.org/ml/fortran/2005-07/msg00098.html, we call foo as follows:
struct array1_real4 parm.11;
struct array1_mytype
--- Additional Comments From tobi at gcc dot gnu dot org 2005-07-09 11:52
---
Oh, and there's a third option which is probably awkward and very pessimizing:
instead of assuming REAL*4 sized objects in the array, the callee could read the
size from the array desriptor, and skip fields
--- Additional Comments From tobi at gcc dot gnu dot org 2005-07-09 12:04
---
The real bug is in gfc_conv_expr_descriptor, as proven by the following
testcase, which doesn't exercise the codepath you're modifying, but the parts
Paul's patch makes us evade:
[EMAIL PROTECTED] tests]$ cat
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-09
13:00 ---
(In reply to comment #9)
Oh, and there's a third option which is probably awkward and very pessimizing:
instead of assuming REAL*4 sized objects in the array, the callee could read
the
size from the
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-09
13:14 ---
The real bug is in gfc_conv_expr_descriptor, as proven by the following
testcase, which doesn't exercise the codepath you're modifying, but the parts
Paul's patch makes us evade:
I think that your
--- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-07-09 15:06 ---
Subject: Re: problem with structure and calling a function
paulthomas2 at wanadoo dot fr wrote:
I think that your pointer example is another bug. Whether it should be
considered
--- Additional Comments From tobi at gcc dot gnu dot org 2005-07-09 17:45
---
(In reply to comment #13)
Sorry, the code I posted for illustration had a typo:
Say,
type a
real*8 :: x
integer*1 :: i
end type
type(a), target :: v(50)
real, pointer :: p(:)
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-08
09:37 ---
(In reply to comment #1)
This looks like it's a dupe of 15553
*** This bug has been marked as a duplicate of 15553 ***
This is not correct - 15553 has been resolved.
The present bug comes about because
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-08
13:01 ---
(In reply to comment #3)
I answered my own question about the purpose of gfc_trans_arrayfunc_assign.
I have written a patch that distinguishes the case of components of derived
types and skips this call.
--- Additional Comments From gruel at astro dot ufl dot edu 2005-07-08
13:34 ---
Subject: Re: problem with structure and calling a function
paulthomas2 at wanadoo dot fr wrote:
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-08
09:37 ---
(In reply to
--
What|Removed |Added
CC||tobi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18022
--- Additional Comments From gruel at astro dot ufl dot edu 2005-07-05
14:51 ---
the problem is still there with the actual version of gfortran. The result is
totally incoherent. I don't know for the bug 15553 but this one is still
present.
--
What|Removed
--- Additional Comments From tobi at gcc dot gnu dot org 2004-10-21 19:27 ---
This looks like it's a dupe of 15553
*** This bug has been marked as a duplicate of 15553 ***
--
What|Removed |Added
26 matches
Mail list logo
