This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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]

Re: [Bug fortran/32732] [Bind C] Character scalars are passed as arrays


hi Steve,

i am able to see similar output from debug_tree on my x86 linux box, so that's a starting point. i've modified the code in generate_local_decl to use some of the code from my old set_tree_decl_type_code and it seems to eliminate the references to array_type in the debug_tree output. i've regtested the changes on x86/linux with no new failures, but i have not done a full bootstrap.

could you add the following three lines after the line you mentioned from generate_local_decl:

DECL_BY_REFERENCE (sym->backend_decl) = 0;
DECL_ARG_TYPE (sym->backend_decl) = TREE_TYPE (sym->backend_decl);
DECL_MODE (sym->backend_decl) =
TYPE_MODE (TREE_TYPE (sym->backend_decl));


would you mind trying this out and letting me know if it fixes the problem. as i mentioned, it seems to remove any references to an array_type from the debug_tree output on my x86 linux box.

thanks.
Chris



On Thu, 26 Jul 2007, Steve Ellcey wrote:

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



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