public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.
Date: Mon, 20 Jul 2015 10:44:00 -0000	[thread overview]
Message-ID: <bug-66943-4-yfaGWmV9jF@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-66943-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jeffrey Walton from comment #6)
> Maybe it could be in effect with `-Wextra`?

That would just move the problem somewhere else instead of fixing it. Many
people do compile with -Wall -Wextra (like GCC itself).

> Enabling Unknown Pragma warnings for #pragma omp under -Wall when the
> compiler supports it, coupled with the inability to manage warnings with
> 'pragma GCC diagnostic` (Bug #53431), means we just turned OFF -Wall. We are
> moving in the wrong direction :(

You could always use -Wall -Wno-unknown-pragmas, but yes, fixing PR53431 seems
the key here. I hope someone finds time to do that before GCC 6 closes for
development.
>From gcc-bugs-return-492826-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 20 11:06:06 2015
Return-Path: <gcc-bugs-return-492826-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 49241 invoked by alias); 20 Jul 2015 11:06:06 -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 49188 invoked by uid 48); 20 Jul 2015 11:06:01 -0000
From: "noloader at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.
Date: Mon, 20 Jul 2015 11:06: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.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: noloader at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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-66943-4-sutureQjDM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66943-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66943-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-07/txt/msg01716.txt.bz2
Content-length: 1917

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

--- Comment #8 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Jeffrey Walton from comment #6)
> > Maybe it could be in effect with `-Wextra`?
>
> That would just move the problem somewhere else instead of fixing it. Many
> people do compile with -Wall -Wextra (like GCC itself).

Yeah, but it works for me :) But more seriously, I understand what you are
saying. When I have the luxury of a new project, I use -Wall -Wextra
-Wconversion.

>
> > Enabling Unknown Pragma warnings for #pragma omp under -Wall when the
> > compiler supports it, coupled with the inability to manage warnings with
> > 'pragma GCC diagnostic` (Bug #53431), means we just turned OFF -Wall. We are
> > moving in the wrong direction :(
>
> You could always use -Wall -Wno-unknown-pragmas, but yes, fixing PR53431
> seems the key here. I hope someone finds time to do that before GCC 6 closes
> for development.

-Wno-unknown-pragmas is just one of many we need. Others appear to include
-Wunused-variable, -Wunused-value and -Wunused-function. And we are no longer
managing the warnings in the source code through a GCC diagnostic block;
rather, we are polluting the command line.

We produce a library, so we not only pollute our command line, we polute the
user's command line. That's after the user complains about it because GCC
diagnostic block don't "just work".

Does GCC have a Bounty program? If so, I'd be happy to make a donation. I'd
even solicit a for grants because `-Wall` and managing warnings is *that*
important. I feel awful that we yanked it for GCC.

On the good side, our sources are cross-compiler and cross-platform, So we are
effectively using -Wall for MSVC, Clang and ICC. But others don't have that
luxury. For example, the Asterisk project uses trampolines, so the code does
not compile under Clang (and it could never compile under MSVC).


      parent reply	other threads:[~2015-07-20 10:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-20  8:00 [Bug c++/66943] New: " noloader at gmail dot com
2015-07-20  8:09 ` [Bug c++/66943] " noloader at gmail dot com
2015-07-20  8:09 ` noloader at gmail dot com
2015-07-20  8:36 ` pinskia at gcc dot gnu.org
2015-07-20  9:14 ` noloader at gmail dot com
2015-07-20  9:58 ` manu at gcc dot gnu.org
2015-07-20 10:36 ` noloader at gmail dot com
2015-07-20 10:44 ` manu at gcc dot gnu.org [this message]

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=bug-66943-4-yfaGWmV9jF@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).