[Bug c++/64531] `casting between pointer-to-function and pointer-to-object` is still a warning instead of error with `-pedantic -pedantic-errors`

["harald at gigawatt dot nl" <gcc-bugzilla@gcc.gnu.org>]

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

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #2 from Harald van Dijk <harald at gigawatt dot nl> ---
It's already been fixed.

$ g++-4.8.4 -pedantic -pedantic-errors -c test.cc
test.cc: In function ‘int main()’:
test.cc:1:33: error: ISO C++ forbids casting between pointer-to-function and
pointer-to-object [-Werror=pedantic]
 int main() { (void(*)())(void *)0; }
                                 ^
cc1plus: some warnings being treated as errors

But the comments in PR 60850 note that this may have been a bad idea (at least
a bad idea for a release branch).
>From gcc-bugs-return-478144-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 23 09:17:03 2015
Return-Path: <gcc-bugs-return-478144-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12034 invoked by alias); 23 Feb 2015 09:17:03 -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 11498 invoked by uid 55); 23 Feb 2015 09:16:58 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/65084] Lack of type narrowing/widening inhibits good vectorization
Date: Mon, 23 Feb 2015 10:00: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: NEW
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-65084-4-xVHreOZV6N@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65084-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65084-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-02/txt/msg02474.txt.bz2
Content-length: 1394

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

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 20 Feb 2015, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?ide084
>
> --- Comment #5 from Jeffrey A. Law <law at redhat dot com> --- Some of
> the stuff you're doing in that patch matches what I was poking at as
> well (for a different BZ).  There's clearly much room for improvement
> here and if we weren't in stage4, I'd be pushing harder on expanding
> what these patterns do now rather than waiting.

Note that for aggressive narrowing (which eventually makes sense for
early GIMPLE) and for widening (which makes sense towards RTL expansion
with the targets word_mode / PROMOTE_MODE in mind) having a separate
pass that deals with the actual transform step (but re-using the
matching from the match.pd code) makes sense - triggering the transform
from forwprop via fold_stmt creates garbage that can confuse single-use
tests (yeah, it's on my list of things to investigate on whether we can
improve here in a somewhat generic way for GCC 6).

As in this bugs summary - what are the cases where vectorization
is bad because of the lack of widening?

> I'm already of the mind that we're going to want to factor some of that
> type testing so we're not repeating it in a half-dozen patterns.

Yeah, that makes sense.