--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-05-25 17:43
---
Closing. Added the following comment to transfer.c:
/* Master function for unformatted writes. NOTE: For kind=10 the size is 16
bytes on 64 bit machines. The unused bytes are not initialized and never
us
--- Comment #7 from jb at gcc dot gnu dot org 2007-05-22 06:52 ---
(In reply to comment #6)
> The following simplistic patch solves this problem. Sometimes I think we get
> overzealous with definitions and fancy configury. We all know the size is 10
> bytes and 12 works.
No. The non-p
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-05-22 05:01
---
The following simplistic patch solves this problem. Sometimes I think we get
overzealous with definitions and fancy configury. We all know the size is 10
bytes and 12 works.
This works:
Index: size_from_kind.c
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-20 16:55
---
Actually, there are two separate build subdirectories created under the arch
directory in the objdir. So on systems like mine, two separate libraries are
built.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from jb at gcc dot gnu dot org 2007-05-20 09:50 ---
(In reply to comment #3)
> I see. With that in mind, I think the patch for PR31915 that went in as
> r124741
> is incorrect (and I share some of the blame since I approved it). We should
> use
> the size argument the fr
--- Comment #3 from jb at gcc dot gnu dot org 2007-05-20 09:46 ---
I see. With that in mind, I think the patch for PR31915 that went in as r124741
is incorrect (and I share some of the blame since I approved it). We should use
the size argument the frontend provides to the unformatted_(r
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-05-19 22:39
---
On x86-64 using -m32 the size being passed to unformatted_write is 12. Its
aligning to nearest 32-bit boundary. Without -m32 size comes in at 16.
Both are long double which has different size on 32 vs 64 bit ma
--- Comment #1 from jb at gcc dot gnu dot org 2007-05-18 20:07 ---
Seems to work fine on i686-pc-linux-gnu. I would have guessed it to be
something related to padding, but it's weird that it's not seen in 32-bit mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31933