public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "mikael at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90 Date: Mon, 27 Jul 2015 18:45:00 -0000 [thread overview] Message-ID: <bug-64921-4-p5AaAfOR7u@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-64921-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 Mikael Morin <mikael at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikael at gcc dot gnu.org --- Comment #20 from Mikael Morin <mikael at gcc dot gnu.org> --- (In reply to Richard Biener from comment #19) > So the question is whether the frontend emits the correct test against zero: > > offset = offset * byte_stride; > D.3466 = (void *) array->data; > D.3467 = D.3466; > D.3465 = 8; > D.3469 = 8; > __builtin_memcpy ((void *) &transfer.4, (void *) > &D.3467, (unsigned long) MAX_EXPR <MIN_EXPR <D.3469, D.3465>, 0>); > ptr2 = (struct t4 *) (transfer.4 + offset); > if (ptr2 != 0B) > { > { > integer(kind=4) stat.5; > > if (ptr2->k == 0B) > > to me it looks like if we really want to test transfer.4 (array->data) > against > zero. transfer.4 + offset calculates the address of an element of an array. I believe that if that code is executed, array.data is non-zero, and of course array.data + offset as well. I think the the test should check for ptr2%j's nullness before deallocating ptr2%j, instead of testing ptr2. With a patch like this: diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c index 218973d..1ff7437 100644 --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -967,7 +967,7 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp, cond->block->expr1->ts.kind = gfc_default_logical_kind; cond->block->expr1->value.function.isym = gfc_intrinsic_function_by_id (GFC_ISYM_ASSOCIATED); cond->block->expr1->value.function.actual = gfc_get_actual_arglist (); - cond->block->expr1->value.function.actual->expr = gfc_copy_expr (expr); + cond->block->expr1->value.function.actual->expr = gfc_copy_expr (e); cond->block->expr1->value.function.actual->next = gfc_get_actual_arglist (); cond->block->next = dealloc; Unfortunately, it doesn't seem to fix the problem.
next prev parent reply other threads:[~2015-07-27 18:45 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com 2015-02-03 16:03 ` [Bug rtl-optimization/64921] " jakub at gcc dot gnu.org 2015-02-03 17:22 ` hjl.tools at gmail dot com 2015-02-03 17:32 ` [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 hjl.tools at gmail dot com 2015-02-03 21:30 ` pault at gcc dot gnu.org 2015-02-04 3:00 ` ramana at gcc dot gnu.org 2015-02-04 18:21 ` pault at gcc dot gnu.org 2015-02-04 18:31 ` hjl.tools at gmail dot com 2015-02-04 19:00 ` dominiq at lps dot ens.fr 2015-02-04 19:03 ` dominiq at lps dot ens.fr 2015-02-09 0:07 ` pinskia at gcc dot gnu.org 2015-02-09 10:00 ` rguenth at gcc dot gnu.org 2015-02-09 14:26 ` rguenth at gcc dot gnu.org 2015-02-16 13:40 ` dominiq at lps dot ens.fr 2015-02-16 13:48 ` [Bug fortran/64921] " dominiq at lps dot ens.fr 2015-04-27 12:26 ` [Bug fortran/64921] [4.9/5/6 " mathewc at nag dot co.uk 2015-06-26 20:04 ` jakub at gcc dot gnu.org 2015-06-26 20:34 ` jakub at gcc dot gnu.org 2015-07-07 15:29 ` ktkachov at gcc dot gnu.org 2015-07-25 13:31 ` ubizjak at gmail dot com 2015-07-25 15:13 ` ubizjak at gmail dot com 2015-07-27 7:57 ` rguenth at gcc dot gnu.org 2015-07-27 18:45 ` mikael at gcc dot gnu.org [this message] 2015-07-27 19:44 ` rguenther at suse dot de 2015-07-28 12:07 ` mikael at gcc dot gnu.org 2015-07-28 12:31 ` rguenther at suse dot de 2015-07-28 12:43 ` ubizjak at gmail dot com 2015-08-05 15:42 ` mikael at gcc dot gnu.org 2015-08-05 16:42 ` mikael at gcc dot gnu.org 2015-08-05 17:04 ` mikael at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-64921-4-p5AaAfOR7u@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).