From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id C7C2A393D01F; Tue,  1 Dec 2020 07:42:21 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C7C2A393D01F
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: =?UTF-8?B?W0J1ZyBjLzk3MTcyXSBbMTEgUmVncmVzc2lvbl0gSUNFOiB0cmVl?=
 =?UTF-8?B?IGNvZGUg4oCYc3NhX25hbWXigJkgaXMgbm90IHN1cHBvcnRlZCBpbiBMVE8g?=
 =?UTF-8?B?c3RyZWFtcyBzaW5jZSByMTEtMzMwMy1nNjQ1MGYwNzM4OGY5ZmU1Nw==?=
Date: Tue, 01 Dec 2020 07:42:21 +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: 11.0
X-Bugzilla-Keywords: ice-on-valid-code, lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-97172-4-NbVgUpJTcy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-97172-4@http.gcc.gnu.org/bugzilla/>
References: <bug-97172-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-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2020 07:42:21 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97172

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well - you're the first to add nontrivial (non-constant) trees to attribute=
s.=20
In GIMPLE all effects are supposed to be reflected in the IL and thus things
like
variable TYPE_SIZE or TYPE_MIN/MAX_VALUE are actually gimplified with code
generated during that inserted at the respective DECL_EXPR (which is where
gimplification is triggered from for the types).

Honestly I am not sure what you think you can do with arbitrary expressions
in an attribute down the GIMPLE pipeline given there's no connection to
actual variable values.  That said, the idea of sticking this additional
information in attributes in form of some random plain tree expressions
doesn't work.  You'd have to sanitize them at least if, say, expressions
based purely on other formal function arguments is what you are after.

That would for example be done by unsharing the expressions without locatio=
ns
which you could try.  But for example the PR97133 case,

    attributes <tree_list 0x7fffea94d8e8
        purpose <identifier_node 0x7fffea937910 arg spec>
        value <tree_list 0x7fffea94d898
            value <string_cst 0x7fffea936860 constant "[$]\000">
            chain <tree_list 0x7fffea94d870
                value <eq_expr 0x7fffea94d758 type <integer_type 0x7fffea81=
05e8
int>
                    side-effects
                    arg:0 <c_maybe_const_expr 0x7fffea94d730 type <pointer_=
type
0x7fffea930c78>
                        side-effects
                        arg:0 <compound_expr 0x7fffea94d708 type <void_type
0x7fffea810f18 void>
                            side-effects arg:1 <bind_expr 0x7fffea949330>>
                        arg:1 <compound_literal_expr 0x7fffea936780 type
<pointer_type 0x7fffea930c78>
                            side-effects arg:0 <decl_expr 0x7fffea936760>>>
                    arg:1 <integer_cst 0x7fffea94f030 constant 0>

certainly is missing constant evaluation (I can bet whatever is supposed
to consume the access attributes gives up on the above anyway).
C_MAYBE_CONST_EXPR is a frontend specific tree code and thus it shouldn't
even survive GENERICization.

So I would stronly suggest to revisit the way you try to record "every
information for accesses" for GCC 12 and for GCC 11 restrict the information
to CONSTANT_CLASS_P trees.=