[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

["q.gcc@rsn-tech.co.uk" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #11 from steveren <q.gcc@rsn-tech.co.uk> ---
(In reply to Manuel López-Ibáñez from comment #10)
> (In reply to steveren from comment #6)
> > Seems the consensus is that it's not contrary to Standard, but it's agreed
> > to be confusing and undesirable by everyone except the gcc maintainers :-)
> 
> Not sure how you reached such conclusion, but it clearly misinterprets
> reality, otherwise this PR would be closed as INVALID already.

Ok, my apologies. However, this bug /was/ closed as invalid before being
reopened, and my own report was closed as invalid before being marked as a dupe
of this one, so it's not entirely clear that there's a general feeling of a
real problem that needs to be addressed.

> I'm pretty sure if you submitted a patch making the behavior of all pragmas 
> consistent with comment #9,

But I don't /want/ behaviour consistent with #9 (ie, warning that the usage is
invalid), I want the usage to be valid /and/ sensible - ie, the same as other
compilers. I suspect that's more difficult...

Don't get me wrong - I'm not whingeing that other people should solve my
problems for me without being prepared to get involved myself, but if this is
WAD in the eyes of the majority, then I'll live with it sooner than create my
own fork!

So assuming it's not actually beyond somebody completely unfamiliar with the
innards of gcc, what would be the response to a patch which changed #pragma
message from 'statement' to 'not-a-statement'?
>From gcc-bugs-return-464655-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 22 14:08:16 2014
Return-Path: <gcc-bugs-return-464655-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13906 invoked by alias); 22 Oct 2014 14:08:16 -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 13612 invoked by uid 48); 22 Oct 2014 14:08:12 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63609] incompatibility with C++11 standard on 14.5.6.2 Partial ordering of function templates
Date: Wed, 22 Oct 2014 14:09: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: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
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: bug_status cf_reconfirmed_on everconfirmed bug_severity
Message-ID: <bug-63609-4-OcBLNvpxVt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63609-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63609-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: 2014-10/txt/msg01676.txt.bz2
Content-length: 729

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-10-22
     Ever confirmed|0                           |1
           Severity|blocker                     |normal

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Please don't set severity=blocker just because you think it's quite important
to you. We're not going to block a GCC release for this issue, especially since
it's been present in several releases already!