public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenther at suse dot de" <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 19:44:00 -0000 [thread overview] Message-ID: <bug-64921-4-qw26QXSs05@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 --- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> --- On July 27, 2015 8:45:41 PM GMT+02:00, "mikael at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> wrote: >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. Yes but if transfer.4 is null then transfer.4 + offset does not have to be. Transfer.4 _is_ null in the case we segfault. So the guard us clearly wrong. >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 19:44 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 2015-07-27 19:44 ` rguenther at suse dot de [this message] 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-qw26QXSs05@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).