This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/18022] problem with structure and calling a function


------- 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 strides in bytes, not elements.
<tobi_s> yes, i wanted to evade the second option
...
<pbrook> Right. The alignment of a derived type is the maximum alignment of all
of its components. However the alignment of one component does not effect the
alignment of other components within the same parent.
<pbrook> so type t; integer(2) :: a; integer(1) :: b, c; end type;    would
still be 4 bytes.
<tobi_s> so either we use byte-sized strides or we rule out packed structures
<pbrook> Yep, pretty much.
...
<pbrook> tobi_s: byte strides might not be so bad once we build
multi-dimensional arrays properly.
...
<pbrook> Anyhow, I think the solution is to make p => v(:)%c ICE/Sorry, and
postpone it until we get round to using ARRAY_REFS properly for multi-d arrays.

IOW, fixing the underlying bug is out-of-reach.  The original bug can be fixed
by forcing the function result via a temporary as Paul's patch does.  I'll have
to think about the correct check, though.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18022


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]