--- Comment #9 from mcvick_e at iname dot com 2009-06-16 16:24 ---
Similar behavior has been seen against version 4.3.2.
Using the __attribute__ mechanism in the past has forced the hand of the
alignment issue most all of the time. I say most all of the time because we
have uncovered
--- Comment #10 from mcvick_e at iname dot com 2009-06-16 16:30 ---
The __attribute__ mechanism works in 4.0.1, but was broken in the 4.3 series.
I wanted to clarify this as I think it's an important hint as to the root cause
of the problem. In 4.0.1, packing and aligning worked via
--- Comment #12 from mcvick_e at iname dot com 2009-06-16 16:55 ---
Can you be a bit more succinct here? Because the comment just made sounds like
a bunch of foo foo stuff made up to ignore a genuine bug in the compiler.
Type byte has a byte alignment.
Type short has a 16-bit
--- Comment #8 from mcvick_e at iname dot com 2006-08-22 16:42 ---
To try to be more helpful here, after doing a large amount of investigation
into the signature of this problem, it's been observed that the GNU compiler
simply defines (or appears to define) a bitfield (regardless
ReportedBy: mcvick_e at iname dot com
GCC build triplet: powerpc-eabi
GCC host triplet: x86_64-redhat-linux
GCC target triplet: powerpc-unknown-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
--- Comment #3 from mcvick_e at iname dot com 2006-08-17 22:17 ---
Are you telling me that if I put two of those structures side by side in memory
that GNU will mis-align them even though I pass the flag -mstrict-align? That
couldn't possibly be since the align flag states to use
--- Comment #5 from mcvick_e at iname dot com 2006-08-17 22:28 ---
Additional information, if you insist on having an ABI then please go to this
link and look at pages 3-8 and 3-9. It states that bitfields have the same
alignment restrictions as their base types (int for int) (short
--- Comment #6 from mcvick_e at iname dot com 2006-08-17 22:35 ---
The spec also has multiple examples of big versus little endian layouts and how
they map in memory and what their alignment is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
--- Comment #7 from mcvick_e at iname dot com 2006-08-18 00:03 ---
(In reply to comment #4)
-mstrict-align does not do what you think it does. What it does is say the
alignment requirements for loads/stores cannot be violated.
That's fine for the -mstrict-align, however as I stated
--- Additional Comments From mcvick_e at iname dot com 2005-08-24 15:44
---
Here is a short program that duplicates the problem.
-- test.cc
struct foo {
char bar1;
char bar2;
char bar3;
};
class bar2 {
private:
static foo
: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mcvick_e at iname dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target
--- Additional Comments From mcvick_e at iname dot com 2005-08-23 21:44
---
I should also mention that the target processor for this is the 603, not 603e
or otherwise. Even compiling with the -mtune=603 and -mcpu=603 gives the same
output. And those old processors do not handle mis
--- Additional Comments From mcvick_e at iname dot com 2005-08-23 22:24
---
The data access exception is incorrect in this sense. The software developer
had updated the status of this issue and states that this causes a Machine
Check exception to occur on our current hardware
--- Additional Comments From mcvick_e at iname dot com 2005-08-23 23:47
---
Our Hardware engineers came back to us informing us as to why this _may_ be an
issue. The hardware has a memory bus arbiter ASIC that does not handle mis-
aligned references for 2-byte accesses ending on 1
--- Additional Comments From mcvick_e at iname dot com 2005-08-24 00:20
---
Unfortunately this still appears to be some sort of bug. The solution given
with the -mstrict-align worked for the test case, but in the specific case
here, still fails. Attached is the output of the link
--- Additional Comments From mcvick_e at iname dot com 2005-08-24 02:57
---
I understand this frustration. The source code is proprietary material so I
cannot post it. However we are working on developing a sample case to
demonstrate what is happening.
--
http://gcc.gnu.org
16 matches
Mail list logo
