From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20954 invoked by alias); 13 Nov 2007 12:46:49 -0000 Received: (qmail 20911 invoked by uid 48); 13 Nov 2007 12:46:38 -0000 Date: Tue, 13 Nov 2007 12:46:00 -0000 Message-ID: <20071113124638.20910.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/33759] Unequal character lengths in MERGE intrinsic not detected at run time In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "pault at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg01169.txt.bz2 ------- 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