[Bug c++/67582] New: typeof(*p) * fails when p is void *

[Bug c++/67582] New: typeof(*p) * fails when p is void *

[vegard.nossum at gmail dot com]

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

            Bug ID: 67582
           Summary: typeof(*p) * fails when p is void *
           Product: gcc
           Version: 4.8.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4

$ cat voidptr 
void foo(void *p)
{
        typeof(*p) *x;
}

I'd expect this to work as if 'x' was declared 'void *x' (which is legal). It
works in C, but not in C++:

$ gcc -x c -c - < voidptr && echo success
success

$ gcc -x c++ -c - < voidptr
<stdin>: In function ‘int foo(void*)’:
<stdin>:3:10: error: ‘void*’ is not a pointer-to-object type
<stdin>:3:15: error: invalid type in declaration before ‘;’ token
>From gcc-bugs-return-497226-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 15 09:21:45 2015
Return-Path: <gcc-bugs-return-497226-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 96726 invoked by alias); 15 Sep 2015 09:21:44 -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 96633 invoked by uid 48); 15 Sep 2015 09:21:40 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/67470] [5/6 Regression] ICE at -O3 on x86_64-linux-gnu in compute_live_loop_exits, at tree-ssa-loop-manip.c:235
Date: Tue, 15 Sep 2015 09:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67470-4-Z9ZJTeSSZw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67470-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67470-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-09/txt/msg01204.txt.bz2
Content-length: 676

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg470

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
g_40 = PHI <0B(9), &a(6)>
  invariant up to level 1, cost 21.

pretmp_42 = g_40 == 0B;
  invariant up to level 1, cost 22.

but we're only moving pretmp_42, not g_40.  The PHI is controlled by
if (f_16(D) != 0).  But when applying stmt movement we are faced with
g_40 = PHI <0B(9), &a(6)> turned into

<bb 11>:
# g_40 = PHI <0B(26), &a(21), &a(22), 0B(25)>

whoops.  That's because predicated store-motion already messed up the
CFG without ensuring we have forwarder blocks that at least preserve
the existing PHI node structure.

This is a latent issue.

[Bug c++/67582] typeof(*p) * fails when p is void *

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
You can't dereference a void*, so why do you expect to be able to get the type
of an invalid expression?

[Bug c++/67582] typeof(*p) * fails when p is void *

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(If it works in C I would suggest that's a bug in the C compiler, but that's
for the C front end maintainers to decide)

[Bug c++/67582] typeof(*p) * fails when p is void *

[vegard.nossum at gmail dot com]

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

--- Comment #3 from Vegard Nossum <vegard.nossum at gmail dot com> ---
(In reply to Jonathan Wakely from comment #1)
> You can't dereference a void*, so why do you expect to be able to get the
> type of an invalid expression?

I was under the impression that the expression was not actually evaluated, but
that only the *type* of the expression was evaluated.

For example, I would also expect this to work even though x has not been
initialised (which should otherwise be UB when dereferenced):

int *x;
typeof(*x) y;

Similarly, I would also expect the usual

#define ARRAY_SIZE(x) (sizeof(x) / sizeof(*x))

to return 0 when passed a zero-length array. Or is that invalid too?

[Bug c++/67582] typeof(*p) * fails when p is void *

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Vegard Nossum from comment #3)
> (In reply to Jonathan Wakely from comment #1)
> > You can't dereference a void*, so why do you expect to be able to get the
> > type of an invalid expression?
> 
> I was under the impression that the expression was not actually evaluated,
> but that only the *type* of the expression was evaluated.

But *p is not a valid expression, so you might as well ask for
typeof(this is nonsense and not valid C++).

You also can't ask for sizeof(*p) for a void pointer.

[Bug c++/67582] typeof(*p) * fails when p is void *

[vegard.nossum at gmail dot com]

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

--- Comment #5 from Vegard Nossum <vegard.nossum at gmail dot com> ---
(In reply to Jonathan Wakely from comment #4)
> But *p is not a valid expression, so you might as well ask for
> typeof(this is nonsense and not valid C++).
> 
> You also can't ask for sizeof(*p) for a void pointer.

The following bits from the standard draft seem to support what you say:

[basic.compound].3 "The type of a pointer to void or a pointer to an object
type is called an object pointer type. [ Note: A pointer to void does not have
a pointer-to-object type, however, because void is not an object type. — end
note ]"

[expr.unary.op].1 "The unary * operator performs indirection: the expression to
which it is applied shall be a pointer to an object type, or a pointer to a
function type and the result is an lvalue referring to the object or function
to which the expression points."
>From gcc-bugs-return-497260-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 15 14:10:58 2015
Return-Path: <gcc-bugs-return-497260-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 104513 invoked by alias); 15 Sep 2015 14:10:58 -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 103549 invoked by uid 55); 15 Sep 2015 14:10:50 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/67470] [5 Regression] ICE at -O3 on x86_64-linux-gnu in compute_live_loop_exits, at tree-ssa-loop-manip.c:235
Date: Tue, 15 Sep 2015 14:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_known_to_work short_desc
Message-ID: <bug-67470-4-x7dbFAlWVi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67470-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67470-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-09/txt/msg01238.txt.bz2
Content-length: 682

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg470

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |6.0
            Summary|[5/6 Regression] ICE at -O3 |[5 Regression] ICE at -O3
                   |on x86_64-linux-gnu in      |on x86_64-linux-gnu in
                   |compute_live_loop_exits, at |compute_live_loop_exits, at
                   |tree-ssa-loop-manip.c:235   |tree-ssa-loop-manip.c:235

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.