From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6037 invoked by alias); 21 Jul 2015 22:47:01 -0000 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 Received: (qmail 5997 invoked by uid 48); 21 Jul 2015 22:46:54 -0000 From: "vries at gcc dot 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libgomp X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: ice-on-valid-code, openacc, openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: vries 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: In-Reply-To: References: 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/msg01865.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D66714 --- Comment #21 from vries at gcc dot gnu.org --- (In reply to cesar from comment #20) > Created attachment 36030 [details] > replace block vars fix >=20 > 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 t= hat 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.=20 >=20 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.=20 >=20 > --- a/gcc/tree-cfg.c=09 > +++ a/gcc/tree-cfg.c=09 > @@ -6916,7 +6916,29 @@ replace_block_vars_by_duplicates (tree block, hash= _map *vars_map, > { > if (TREE_CODE (*tp) =3D=3D VAR_DECL && DECL_HAS_VALUE_EXPR_P (*tp)) > { > - SET_DECL_VALUE_EXPR (t, DECL_VALUE_EXPR (*tp)); > + tree x =3D DECL_VALUE_EXPR (*tp); > + > + if (TREE_CODE (x) =3D=3D INDIRECT_REF) > + { > + tree expr =3D TREE_OPERAND (x, 0); > + tree decl; > + > + if (CONVERT_EXPR_CODE_P (TREE_CODE (expr))) > + decl =3D TREE_OPERAND (expr, 0); > + else > + decl =3D expr; > + > + replace_by_duplicate_decl (&decl, vars_map, to_context); > + > + if (CONVERT_EXPR_CODE_P (TREE_CODE (expr))) > + expr =3D build1 (TREE_CODE (expr), TREE_TYPE (expr), decl); > + else > + expr =3D decl; > + > + x =3D build_simple_mem_ref (expr); > + } How about=20 + 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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=3D20397 --- Comment #19 from Jonathan Wakely --- (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez from comment #18) > (In reply to Jonathan Wakely from comment #17) > > FWIW for the original testcase G++ now says: > >=20 > > a.cc:9:8: error: =E2=80=98class A A::A=E2=80=99 is inaccessible within = this context > > int c(A *a) { return 7; } > > ^ >=20 > Probably we are treating 'A::A' as a type defined in A. This seems wrong= .=20 Not really, 'A' is the name of a type, and it is declared in A (as the inje= cted class name). > Perhaps enforce_access could use basetype_path to explain why it is > inaccessible in the same way as Clang does. >=20 > In my ideal world, it would say: >=20 > error: =E2=80=98class A=E2=80=99 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 cl= ass 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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?id=66963 --- Comment #1 from Andrew Pinski --- I thought this is documented somewhere but __builtin_choose_expr only really accept constant literals and not constexprs.