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.


  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: link
Be 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).