public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Richard Biener <rguenther@suse.de>,
	Martin Sebor <msebor@gmail.com>,
	gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] c-family, v2: Improve MEM_REF printing for diagnostics [PR98597]
Date: Fri, 15 Jan 2021 09:58:44 +0100	[thread overview]
Message-ID: <20210115085844.GF1034503@tucnak> (raw)
In-Reply-To: <20210114182636.GZ1034503@tucnak>

On Thu, Jan 14, 2021 at 07:26:36PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Is this ok for trunk if it passes bootstrap/regtest?

So, x86_64-linux bootstrap unfortunately broke due to the -march=i486
changes, but at least i686-linux bootstrap succeeded and shows 2
regressions.

One is on g++.dg/gomp/allocate-2.C, which used to print:
allocate-2.C:9:36: error: user defined reduction not found for ‘s’
but now prints:
allocate-2.C:9:36: error: user defined reduction not found for ‘*&s’
because of -O0 and therefore -fno-strict-aliasing.
The problem is that for !flag_strict_aliasing get_deref_alias_set returns 0
and so the:
&& get_deref_alias_set (TREE_OPERAND (e, 1)) == get_alias_set (op)
check fails.  So, shall the code use
&& (!flag_no_strict_aliasing
    || get_deref_alias_set (TREE_OPERAND (e, 1)) == get_alias_set (op))
instead, or
get_alias_set (TREE_TYPE (TREE_TYPE (TREE_OPERAND (e, 1))))
== get_alias_set (op)
?
The other is on gcc.dg/gomp/_Atomic-3.c test, where we used to print
_Atomic-3.c:22:34: error: ‘_Atomic’ ‘k’ in ‘reduction’ clause
but now print
_Atomic-3.c:22:34: error: ‘_Atomic’ ‘*(_Atomic int (*)[4])(&k[0])’ in ‘reduction’ clause
Apparently in this case the C FE considers the two _Atomic int [4] types
incompatible, one is created through
c_build_qualified_type (type=<array_type 0x7fffea186a80>, type_quals=8, orig_qual_type=<tree 0x0>, orig_qual_indirect=1)
on an int [4] type, i.e. adding _Atomic qualifier to an unqualified array
type, and the other is created through
build_array_type (elt_type=<integer_type 0x7fffea186540 int>, index_type=<integer_type 0x7fffea186498>, typeless_storage=false)
i.e. creating an array with _Atomic int elements.
That seems like a C FE bug to me.

Anyway, I can fix or workaround that by:
--- gcc/c/c-typeck.c.jj	2021-01-04 10:25:49.651111329 +0100
+++ gcc/c/c-typeck.c	2021-01-15 09:53:29.590611264 +0100
@@ -13979,7 +13979,9 @@ c_finish_omp_clauses (tree clauses, enum
 	      size = size_binop (MINUS_EXPR, size, size_one_node);
 	      size = save_expr (size);
 	      tree index_type = build_index_type (size);
-	      tree atype = build_array_type (type, index_type);
+	      tree atype = build_array_type (TYPE_MAIN_VARIANT (type),
+					     index_type);
+	      atype = c_build_qualified_type (atype, TYPE_QUALS (type));
 	      tree ptype = build_pointer_type (type);
 	      if (TREE_CODE (TREE_TYPE (t)) == ARRAY_TYPE)
 		t = build_fold_addr_expr (t);
and then we're back to the above allocate-2.C issue, i.e. at -O0
we still print *&k rather than k.

And another question is if in case we punted because of the TBAA check
we shouldn't just force printing the access type, so never print
*&k but print instead *(access type)&k.

	Jakub


  reply	other threads:[~2021-01-15  8:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-13 19:11 [PATCH] c-family: " Jakub Jelinek
2021-01-14  7:43 ` Richard Biener
2021-01-14  8:28   ` Jakub Jelinek
2021-01-14  8:34     ` Jakub Jelinek
2021-01-14 10:05       ` Richard Biener
2021-01-14 10:09         ` Jakub Jelinek
2021-01-14 10:17           ` Richard Biener
2021-01-14 17:49   ` Martin Sebor
2021-01-14 18:26     ` [PATCH] c-family, v2: " Jakub Jelinek
2021-01-15  8:58       ` Jakub Jelinek [this message]
2021-01-15 10:46         ` Richard Biener
2021-01-15 10:43       ` Richard Biener

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=20210115085844.GF1034503@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=msebor@gmail.com \
    --cc=rguenther@suse.de \
    /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).