public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* c/8357: Wrong RTL code for attribute(packed) field access on Sparc
@ 2002-10-25 10:56 Laurent Voisin
0 siblings, 0 replies; 2+ messages in thread
From: Laurent Voisin @ 2002-10-25 10:56 UTC (permalink / raw)
To: gcc-gnats; +Cc: Richard Henderson, Jürgen Keil
>Number: 8357
>Category: c
>Synopsis: Wrong RTL code for attribute(packed) field access on Sparc
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: unassigned
>State: open
>Class: wrong-code
>Submitter-Id: net
>Arrival-Date: Fri Oct 25 10:56:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: Laurent Voisin
>Release: 3.2
>Organization:
ClearSy System Engineering
>Environment:
System: SunOS prvb 5.6 Generic_105181-19 sun4u sparc SUNW,Ultra-5_10
Architecture: sun4
host: sparc-sun-solaris2.6
build: sparc-sun-solaris2.6
target: sparc-sun-solaris2.6
configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls
>Description:
When emitting the RTL code for the assignment of the example,
GCC considers that the field is aligned on a 32 bit boundary.
However, depending on the value of the index, the field can be
aligned only on a 16 bit boundary. This will then produce a
SIGBUS at run-time.
The wrong RTL instruction is near the end of the "yy.c.00.rtl"
file and looks like:
(insn 22 20 23 (set (mem/s/j:SI (plus:SI (reg/f:SI 111)
(const_int -16 [0xfffffff0])) [0 <variable>.taille+0 S4 A32])
(const_int 0 [0x0])) -1 (nil)
(nil))
I would expect two instructions working on half-words and an
alignment of A16 instead of A32.
A workaround would be to make the variable global (so that its
alignment is 16 bits), but that doesn't work for a recursive
function.
The call to `highest_pow2_factor_for_type()' has been introduced
when correcting PR c++/6212.
This bug might be the same as in PR c/7847.
>How-To-Repeat:
Run "gcc -dr -S yy.c" on the attached file.
>Fix:
I had a look to the GCC code. I expect this bug to be due to the
call to `highest_pow2_factor_for_type()' in expand_assignment(),
file "expr.c", line 3711.
Actually, the alignment permitted by the offset is correctly
computed as 16 bit. But the alignment of `TREE_TYPE (to)' is
32 bits. Then, the `highest_pow2_factor_for_type()' function
returns 4 bytes.
So there are two possibility : either the call to
`highest_pow2_factor_for_type()' is wrong, or its first
parameter is wrong, that is `TREE_TYPE (to)'.
Also, it seems odd that `to', which is a COMPONENT_REF, has a
32 bit alignment in its type, although its first operand has a
16 bit alignment. The tree for `to' looks like:
<component_ref 548bd0
type <integer_type 54c380 int SI
size <integer_cst 548270 constant 32>
unit size <integer_cst 548318 constant 4>
align 32 symtab 0 alias set -1 precision 32 min <...> max <...>
pointer_to_this <pointer_type 556540>>
arg 0 <array_ref 548ba0
type <record_type 575f80 type_0 BLK
size <integer_cst 549818 constant 48>
unit size <integer_cst 55a768 constant 6>
user align 16 symtab 0 alias set -1 fields <field_decl 575ea0 taille>
So, maybe the bug lies in the computation of the type of the
COMPONENT_REF (that type actually is the plain "int" type).
That, would explain the bug somehow. I had a look to
the `build_component_ref' function and it just makes the
COMPONENT_REF type the same as the FIELD_DECL type (same
tree node pointer).
I'm willing to contribute a patch. However, I'm missing some
essential information concerning the way alignments are
coded inside GCC. I would be glad if I could have a discussion
with a GCC guru on this point or have a pointer to some
documentation, besides the code.
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: c/8357: Wrong RTL code for attribute(packed) field access on Sparc
@ 2002-10-25 11:00 davem
0 siblings, 0 replies; 2+ messages in thread
From: davem @ 2002-10-25 11:00 UTC (permalink / raw)
To: Laurent.Voisin, gcc-bugs, gcc-prs, nobody
Synopsis: Wrong RTL code for attribute(packed) field access on Sparc
State-Changed-From-To: open->closed
State-Changed-By: davem
State-Changed-When: Fri Oct 25 11:00:05 2002
State-Changed-Why:
duplicate of 7847
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8357
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-10-25 18:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-25 10:56 c/8357: Wrong RTL code for attribute(packed) field access on Sparc Laurent Voisin
2002-10-25 11:00 davem
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).