This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Bug fortran/32732] [Bind C] Character scalars are passed as arrays
- From: Steve Ellcey <sje at cup dot hp dot com>
- To: burnus at net-b dot de
- Cc: fortran at gcc dot gnu dot org, crickett at lanl dot gov
- Date: Thu, 26 Jul 2007 11:59:51 -0700 (PDT)
- Subject: Re: [Bug fortran/32732] [Bind C] Character scalars are passed as arrays
> > I will look more into the char issue and see if I can get some more data on what is happening.
> >
> Thanks and good look. These are all "abort()" failures and no
> segmentation faults, are they?
>
> Tobias
So I am hitting the new code in generate_local_decl where we do:
TREE_TYPE (sym->backend_decl) = unsigned_char_type_node;
But I don't think this type change is enough to fix the problem. If I
do a debug_tree of sym->backend_decl after this statement I get:
<parm_decl 7d6cc270 my_char
type <integer_type 7d6d8150 char public unsigned string-flag QI
size <integer_cst 7d6c5208 constant invariant 8>
unit size <integer_cst 7d6c5230 constant invariant 1>
align 8 symtab 0 alias set -1 canonical type 7d6d8150 precision 8 min <integer_cst 7d6c5258 0> max <integer_cst 7d6c5280 255>
pointer_to_this <pointer_type 7d6e0690>>
readonly used QI file x.f90 line 6 size <integer_cst 7d6c5208 8> unit size <integer_cst 7d6c5230 1>
align 8 context <function_decl 7d76dc30 param_test> initial <array_type 7d76e1c0>
arg-type <array_type 7d76e1c0 type <integer_type 7d6d8150 char>
string-flag QI size <integer_cst 7d6c5208 8> unit size <integer_cst 7d6c5230 1>
align 8 symtab 0 alias set -1 canonical type 7d76e1c0
domain <integer_type 7d76e150 type <integer_type 7d6d8310 int4>
SI
size <integer_cst 7d6c5438 constant invariant 32>
unit size <integer_cst 7d6c5140 constant invariant 4>
align 32 symtab 0 alias set -1 canonical type 7d76e150 precision 32 min <integer_cst 7d6c58e8 1> max <integer_cst 7d6c58e8 1>>> chain <parm_decl 7d6cc208 _my_char>>
I still see an array_type in there though I am not sure exactly what it
is refering too. I think it refers to the alignment of the parameter,
the generated code is doing a 56 bit right shift (in a 64 bit register)
of the parameter before using it and that is what causes the failure.
It should not be doing any shifting.
Steve Ellcey
sje@cup.hp.com