This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/33759] Unequal character lengths in MERGE intrinsic not detected at run time
- From: "pault at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 13 Nov 2007 12:46:38 -0000
- Subject: [Bug fortran/33759] Unequal character lengths in MERGE intrinsic not detected at run time
- References: <bug-33759-12313@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #10 from pault at gcc dot gnu dot org 2007-11-13 12:46 -------
(In reply to comment #9)
> > This patch is OK.
> Yes indeed, I have applied it a long time ago.
As I found out minutes after I posted this note - thanks!
> I have only pointed to the last bug on transfer I know of.
> > It is only at the default logical length that it fails!
The optimizer is doing something horrible to the code in
transfer_simplify_4.f90; I have CC'd Andrew in the hope that he can shed some
light on it:
As an experiment, I tried the following patch to circumvent the mashing up of
the logical by BUILT_IN_MEMCPY when transferring between LOGICAL and INTEGER:
Index: gcc/fortran/trans-intrinsic.c
===================================================================
*** gcc/fortran/trans-intrinsic.c (révision 130095)
--- gcc/fortran/trans-intrinsic.c (copie de travail)
*************** gfc_conv_intrinsic_transfer (gfc_se * se
*** 3277,3282 ****
--- 3277,3291 ----
se->expr = ptr;
se->string_length = argse.string_length;
}
+ else if (expr->value.function.actual->expr->ts.kind == expr->ts.kind
+ && ((expr->value.function.actual->expr->ts.type == BT_LOGICAL
+ && expr->ts.type == BT_INTEGER)
+ || (expr->value.function.actual->expr->ts.type == BT_INTEGER
+ && expr->ts.type == BT_LOGICAL)))
+ {
+ ptr = convert (build_pointer_type (type), ptr);
+ se->expr = build_fold_indirect_ref (ptr);
+ }
else
{
tree moldsize;
The example in comment #6 now works at any level of optimization, even without
the PRINT statement (the reason why I mention this will be apparent in a
moment).
transfer_simplify_4.f90 itself fails in the third block, at -O2 and higher,
whereas it failed at all levels of optimization withhout the patch.
a = transfer(ip1, .true.)
i = transfer(a, 0)
if (i .ne. ip1) call abort ()
Adding a PRINT *, a; or a PRINT *, i; anywhere in the program allows it to work
at any level of optimization. This is true, even if the PRINT replaces one of
the call abort's.
I have looked to see what the i/o might be doing but cannot understand it at
all.
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pinskia at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33759