This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [gfortran] Fix PR 19543: Type mismatch when building logicalconstants


Roger Sayle wrote:
> On Fri, 21 Jan 2005, [ISO-8859-1] Tobias Schlüter wrote:
> 
>>Supposing this is indeed a middle-end bug, would it be a good idea to
>>submit my patch anyway, so that the hypothetical middle-end hacker will
>>not have to patch his Fortran compiler to get a clear view of this
>>issue?
> 
> 
> My initial guess is that somewhere in the middle-end is assuming
> that the front-end creates only a single type for BOOLEAN_TYPE and
> that this is the same as the front-end's (default) boolean_type_node.
> I believe gfortran is unique in being the only GCC front-end to
> have multiple precision variants of BOOLEAN_TYPE.
> 
> But I'm also confused by the strange self-referencing "loop" in
> gfortran/trans-types.c, where gfc_build_logical_type can return
> boolean_type_node, but boolean_type_node is (indirectly) initialized
> by calling gfc_build_logical_type!?  Could someone check that I'm
> not missing something in gfc_init_types.

Indeed you're right, something is fishy there.  It looks like this fact is
hidden due to an ordering problem between the frontend and the middleend:
in build_common_tree_nodes() in tree.c we have:
  /* Define a boolean type.  This type only represents boolean values but
     may be larger than char depending on the value of BOOL_TYPE_SIZE.
     Front ends which want to override this size (i.e. Java) can redefine
     boolean_type_node before calling build_common_tree_nodes_2.  */
  boolean_type_node = make_unsigned_type (BOOL_TYPE_SIZE);
  TREE_SET_CODE (boolean_type_node, BOOLEAN_TYPE);
  TYPE_MAX_VALUE (boolean_type_node) = build_int_cst (boolean_type_node, 1);
  TYPE_PRECISION (boolean_type_node) = 1;
and in init_decl_processing() in f95-lang.c we have
  /* Build common tree nodes. char_type_node is unsigned because we
     only use it for actual characters, not for INTEGER(1). Also, we
     want double_type_node to actually have double precision.  */
  build_common_tree_nodes (false, false);
  set_sizetype (long_unsigned_type_node);
  build_common_tree_nodes_2 (0);

  /* Set up F95 type nodes.  */
  gfc_init_kinds ();
  gfc_init_types ();
where init_types overrides boolean_type_node.  AFAICT those two types match,
but this might be a problem nonetheless.  Simply not setting
boolean_type_node, boolean_true_node and boolean_false_node in
gfc_init_types(), as appended to this mail might be the right thing.

This is untested, because I'm getting a bootstrap comparison failure.

- Tobi

2005-01-22  Tobias Schl"uter  <tobias.schlueter@physik.uni-muenchen.de>

	* trans-types.c (gfc_init_types): Don't initialize boolean_type_node,
	boolean_true_node and boolean_false_node.

Index: trans-types.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/fortran/trans-types.c,v
retrieving revision 1.36
diff -u -p -r1.36 trans-types.c
--- trans-types.c       16 Jan 2005 16:48:16 -0000      1.36
+++ trans-types.c       22 Jan 2005 11:55:53 -0000
@@ -533,10 +533,6 @@ gfc_init_types (void)

   size_type_node = gfc_array_index_type;

-  boolean_type_node = gfc_get_logical_type (gfc_default_logical_kind);
-  boolean_true_node = build_int_cst (boolean_type_node, 1);
-  boolean_false_node = build_int_cst (boolean_type_node, 0);
-
   /* ??? Shouldn't this be based on gfc_index_integer_kind or so?  */
   gfc_charlen_type_node = gfc_get_int_type (4);
 }


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