public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libgomp/66714] ICE in loc_list_from_tree with -g Date: Tue, 21 Jul 2015 22:47:00 -0000 [thread overview] Message-ID: <bug-66714-4-z6chlsqZa2@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-66714-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714 --- Comment #21 from vries at gcc dot gnu.org --- (In reply to cesar from comment #20) > Created attachment 36030 [details] > replace block vars fix > > Tom, thanks for your detailed analysis and reduced test case. As you > suspected, replace_block_vars_by_duplicates isn't updating the > DECL_VALUE_EXPR properly. Yeah, and AFAIU Michaels analysis ( https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01037.html ) he agrees that that is the problem. > That function is setting the value expr to be the > original decl, not the new offloaded copy. My patch teaches it how to use an > offloaded copy. > Cool. > All of the value exprs we're interested in for openacc are INDIRECT_REFs and > I think that holds true for openmp too. Fortran cray pointers caused some > minor problems because those get represented by a INDIRECT_REF to a > CONVERT_EXPR as you in the patch. > > --- a/gcc/tree-cfg.c > +++ a/gcc/tree-cfg.c > @@ -6916,7 +6916,29 @@ replace_block_vars_by_duplicates (tree block, hash_map<tree, tree> *vars_map, > { > if (TREE_CODE (*tp) == VAR_DECL && DECL_HAS_VALUE_EXPR_P (*tp)) > { > - SET_DECL_VALUE_EXPR (t, DECL_VALUE_EXPR (*tp)); > + tree x = DECL_VALUE_EXPR (*tp); > + > + if (TREE_CODE (x) == INDIRECT_REF) > + { > + tree expr = TREE_OPERAND (x, 0); > + tree decl; > + > + if (CONVERT_EXPR_CODE_P (TREE_CODE (expr))) > + decl = TREE_OPERAND (expr, 0); > + else > + decl = expr; > + > + replace_by_duplicate_decl (&decl, vars_map, to_context); > + > + if (CONVERT_EXPR_CODE_P (TREE_CODE (expr))) > + expr = build1 (TREE_CODE (expr), TREE_TYPE (expr), decl); > + else > + expr = decl; > + > + x = build_simple_mem_ref (expr); > + } How about + else + gcc_unreachable (); ? That makes sure you run into all the unhandled cases. > I tested this patch in gomp-4_0-branch libgomp and everything appears to > work. Does this issue present in trunk too? Yep, this PR was originally filed as gomp-4_0-branch PR but, I changed it to trunk PR at comment 13. >From gcc-bugs-return-492976-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 21 23:21:57 2015 Return-Path: <gcc-bugs-return-492976-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 29032 invoked by alias); 21 Jul 2015 23:21:57 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 28984 invoked by uid 48); 21 Jul 2015 23:21:53 -0000 From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/20397] improve diagnostic for 'is inaccessible' error Date: Tue, 21 Jul 2015 23:21:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 3.4.2 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: REOPENED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-20397-4-l9rePV0mwV@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-20397-4@http.gcc.gnu.org/bugzilla/> References: <bug-20397-4@http.gcc.gnu.org/bugzilla/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-07/txt/msg01866.txt.bz2 Content-length: 1240 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20397 --- Comment #19 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Manuel López-Ibáñez from comment #18) > (In reply to Jonathan Wakely from comment #17) > > FWIW for the original testcase G++ now says: > > > > a.cc:9:8: error: ‘class A A::A’ is inaccessible within this context > > int c(A *a) { return 7; } > > ^ > > Probably we are treating 'A::A' as a type defined in A. This seems wrong. Not really, 'A' is the name of a type, and it is declared in A (as the injected class name). > Perhaps enforce_access could use basetype_path to explain why it is > inaccessible in the same way as Clang does. > > In my ideal world, it would say: > > error: ‘class A’ is inaccessible within this context > int c(A *a) { return 7; } > ^ > note: constrained by implicitly private inheritance here > class B : A { > ^ I don't like "constrained by implicitly private inheritance", the term "constrained" is used in other contexts in C++ but not related to access control. I think it would be better to say that name lookup found 'A' in the base class A, where it is inaccessible. >From gcc-bugs-return-492977-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 21 23:25:07 2015 Return-Path: <gcc-bugs-return-492977-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 34768 invoked by alias); 21 Jul 2015 23:25:07 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 34727 invoked by uid 48); 21 Jul 2015 23:25:02 -0000 From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/66963] __builtin_constant_p and __builtin_choose_expr do not agree on what is a constexpr with -O2 Date: Tue, 21 Jul 2015 23:25:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 5.1.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pinskia at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-66963-4-YyNCgiQYEB@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-66963-4@http.gcc.gnu.org/bugzilla/> References: <bug-66963-4@http.gcc.gnu.org/bugzilla/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-07/txt/msg01867.txt.bz2 Content-length: 242 https://gcc.gnu.org/bugzilla/show_bug.cgi?idf963 --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- I thought this is documented somewhere but __builtin_choose_expr only really accept constant literals and not constexprs.
next prev parent reply other threads:[~2015-07-21 22:47 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-06-30 22:17 [Bug debug/66714] New: gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE vries at gcc dot gnu.org 2015-07-02 11:11 ` [Bug debug/66714] " vries at gcc dot gnu.org 2015-07-02 11:21 ` vries at gcc dot gnu.org 2015-07-02 11:26 ` vries at gcc dot gnu.org 2015-07-02 11:32 ` vries at gcc dot gnu.org 2015-07-02 11:35 ` vries at gcc dot gnu.org 2015-07-02 11:39 ` vries at gcc dot gnu.org 2015-07-02 11:46 ` vries at gcc dot gnu.org 2015-07-02 11:58 ` vries at gcc dot gnu.org 2015-07-02 12:00 ` vries at gcc dot gnu.org 2015-07-04 8:26 ` vries at gcc dot gnu.org 2015-07-04 8:34 ` [Bug debug/66714] ICE in loc_list_from_tree with -g vries at gcc dot gnu.org 2015-07-06 7:44 ` vries at gcc dot gnu.org 2015-07-06 7:50 ` vries at gcc dot gnu.org 2015-07-06 7:56 ` [Bug libgomp/66714] " vries at gcc dot gnu.org 2015-07-06 9:34 ` vries at gcc dot gnu.org 2015-07-06 9:35 ` vries at gcc dot gnu.org 2015-07-09 11:12 ` vries at gcc dot gnu.org 2015-07-21 22:27 ` cesar at gcc dot gnu.org 2015-07-21 22:47 ` vries at gcc dot gnu.org [this message] 2015-07-22 2:15 ` cesar at gcc dot gnu.org 2015-07-22 23:36 ` cesar at gcc dot gnu.org 2015-07-24 14:39 ` cesar at gcc dot gnu.org 2015-07-27 14:29 ` cesar 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-66714-4-z6chlsqZa2@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).