[Bug c++/66943] New: GCC warns of Unknown Pragma for OpenMP, even though it support it.

[Bug c++/66943] New: GCC warns of Unknown Pragma for OpenMP, even though it support it.

[noloader at gmail dot com]

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

            Bug ID: 66943
           Summary: GCC warns of Unknown Pragma for OpenMP, even though it
                    support it.
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: noloader at gmail dot com
  Target Milestone: ---

The following source code results in a slew of Unknown Pragma messages. The
problem is, GCC supports OpenMP. GCC responds properly to -fopenmp, and even
defines _OPENMP when it encounters -fopenmp.

This is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431, and
managing warnings with pragmas when using -Wall. The relation to 53431 is: I
can't seem to get "pragma GCC diagnostic" to work to ignore the warnings when
-Wall is in effect.

// Defines GCC_DIAGNOSTIC_AWARE if GCC 4.7 or above.
#define GCC_DIAGNOSTIC_AWARE 1

#if GCC_DIAGNOSTIC_AWARE
# pragma GCC diagnostic ignored "-Wunknown-pragmas"
#endif

...
Integer ModularRoot(const Integer &a, const Integer &dp, const Integer &dq,
                    const Integer &p, const Integer &q, const Integer &u)
{
    Integer p2, q2;
    #pragma omp parallel
        #pragma omp sections
        {
            #pragma omp section
                p2 = ModularExponentiation((a % p), dp, p);
            #pragma omp section
                q2 = ModularExponentiation((a % q), dq, q);
        }
    return CRT(p2, p, q2, q, u);
}
...

**********

To duplicate:

    git clone https://github.com/weidai11/cryptopp.git cryptopp-warn
    cd cryptopp-warn
    export CXXFLAGS="-g2 -O3 -DNDEBUG -Wall"
    make

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[noloader at gmail dot com]

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

--- Comment #1 from Jeffrey Walton <noloader at gmail dot com> ---
I've experienced this issue on Cygwin i386 and x86_64 running GCC 4.8.1; Fedora
21 and 22, i386 and x86_64 running GCC 4.9 and 5.1, and a few others.

So it appears to be a widespread issue, and not an isolated case.

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[noloader at gmail dot com]

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

--- Comment #2 from Jeffrey Walton <noloader at gmail dot com> ---
My bad... Here's the error message:

g++ -DNDEBUG -g2 -O3 -Wall -march=native -pipe -c nbtheory.cpp
nbtheory.cpp:655:0: warning: ignoring #pragma omp parallel [-Wunknown-pragmas]
  #pragma omp parallel
 ^
nbtheory.cpp:656:0: warning: ignoring #pragma omp sections [-Wunknown-pragmas]
   #pragma omp sections
 ^
...

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The warning is correct though, maybe it should add a message about needing
-fopenmp to have them to be known.

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[noloader at gmail dot com]

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

--- Comment #4 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Andrew Pinski from comment #3)
> The warning is correct though, maybe it should add a message about needing
> -fopenmp to have them to be known.

>From a dumb user's point of view (folks like me): that behavior squashes a lot
of the benefit of cross-platform sources and using parallel tasks.

I think the OpenMP folks feel about the same. From
http://openmp.org/wp/openmp-specifications/ and
http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf:

    Each directive starts with #pragma omp. The remainder of the
    directive follows the conventions of the C and C++ standards
    for compiler directives. In particular, white space can be
    used before and after the #, and sometimes white space must
    be used to separate the words in a directive. Preprocessing
    tokens following the #pragma omp are subject to macro
    replacement. 

There's no expectation that a conforming compiler will issue a warning for
#pragma omp when -fopenmp is not in effect. In fact, I can't find authority to
issue a warning from a conforming compiler.

I think it would be much better to always accept `#pragma omp` *if* the
compiler supports OpenMP, regardless of the status of `-fopenmp`. Conversely,
if the compiler does not support OpenMP, then always issue an unknown pragma
warning (modulo expected behavior of the diagnostic).

Speaking from experience, OpenBSD and Cygwin get into an odd area where they
advertise support for OpenMP by accepting -fopenmp and defining _OPENMP, but
then fail to compile the program. But I think that's a different issue.

(For what its worth, I understand the compiler writers are always right. They
are demi-gods in my little corner of the universe :)

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jeffrey Walton from comment #4)
> (For what its worth, I understand the compiler writers are always right.
> They are demi-gods in my little corner of the universe :)

You can also be a compiler writer:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

For what is worth, I understand the point by Andrew that without -fopenmp, the
#pragmas are effectively ignored, thus the warning seems useful. Perhaps it
would be more useful a specific -Wopenmp-pragmas  that says:

 warning: ignoring '#pragma omp parallel' without '-fopenmp' [-Wopenmp-pragmas]

But it seems more important to fix PR53431, if someone has time for that.

The zero-column ":0" in the diagnostic is also a bug.
>From gcc-bugs-return-492820-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 20 10:03:32 2015
Return-Path: <gcc-bugs-return-492820-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 62121 invoked by alias); 20 Jul 2015 10:03:30 -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 61964 invoked by uid 48); 20 Jul 2015 10:03:21 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
Date: Mon, 20 Jul 2015 10:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
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-64986-4-CO8kypFAvy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64986-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64986-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-SW-Source: 2015-07/txt/msg01710.txt.bz2
Content-length: 290

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

--- Comment #10 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Mikael Morin from comment #9)
> The components are deallocated after the containing object.
> Draft patch:

Yes, this fixes the testsuite failure for me.
>From gcc-bugs-return-492821-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 20 10:26:13 2015
Return-Path: <gcc-bugs-return-492821-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9191 invoked by alias); 20 Jul 2015 10:26:13 -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 9131 invoked by uid 48); 20 Jul 2015 10:26:08 -0000
From: "vekumar at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65952] [AArch64] Will not vectorize storing induction of pointer addresses for LP64
Date: Mon, 20 Jul 2015 10:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vekumar at gcc dot gnu.org
X-Bugzilla-Status: NEW
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: cc
Message-ID: <bug-65952-4-huxuQ6nhf6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65952-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65952-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/msg01711.txt.bz2
Content-length: 5179

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

vekumar at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vekumar at gcc dot gnu.org

--- Comment #9 from vekumar at gcc dot gnu.org ---
As per Richards, suggestion I added a pattern in vector recog.
This seems to vectorize the this PR.

However I need some help on the following

(1)How do I check the shift amount and also care about type/signedness.  There
could be different shift amounts allowed in the target architecture when
looking for power 2 constants.

(2)Should I need to check if target architecture supports vectorized shifts
before converting the pattern?

---Patch---
diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index f034635..995c9b2 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-patterns.c
@@ -76,6 +76,10 @@ static gimple vect_recog_vector_vector_shift_pattern
(vec<gimple> *,
                                                      tree *, tree *);
 static gimple vect_recog_divmod_pattern (vec<gimple> *,
                                         tree *, tree *);
+
+static gimple vect_recog_multconst_pattern (vec<gimple> *,
+                                         tree *, tree *);
+
 static gimple vect_recog_mixed_size_cond_pattern (vec<gimple> *,
                                                  tree *, tree *);
 static gimple vect_recog_bool_pattern (vec<gimple> *, tree *, tree *);
@@ -90,6 +94,7 @@ static vect_recog_func_ptr
vect_vect_recog_func_ptrs[NUM_PATTERNS] = {
        vect_recog_rotate_pattern,
        vect_recog_vector_vector_shift_pattern,
        vect_recog_divmod_pattern,
+        vect_recog_multconst_pattern,
        vect_recog_mixed_size_cond_pattern,
        vect_recog_bool_pattern};

@@ -2147,6 +2152,90 @@ vect_recog_vector_vector_shift_pattern (vec<gimple>
*stmts,
   return pattern_stmt;
 }

+static gimple
+vect_recog_multconst_pattern (vec<gimple> *stmts,
+                           tree *type_in, tree *type_out)
+{
+  gimple last_stmt = stmts->pop ();
+  tree oprnd0, oprnd1, vectype, itype, cond;
+  gimple pattern_stmt, def_stmt;
+  enum tree_code rhs_code;
+  stmt_vec_info stmt_vinfo = vinfo_for_stmt (last_stmt);
+  loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_vinfo);
+  bb_vec_info bb_vinfo = STMT_VINFO_BB_VINFO (stmt_vinfo);
+  optab optab;
+  tree q;
+  int dummy_int, prec;
+  stmt_vec_info def_stmt_vinfo;
+
+  if (!is_gimple_assign (last_stmt))
+    return NULL;
+
+  rhs_code = gimple_assign_rhs_code (last_stmt);
+  switch (rhs_code)
+    {
+    case MULT_EXPR:
+      break;
+    default:
+      return NULL;
+    }
+
+  if (STMT_VINFO_IN_PATTERN_P (stmt_vinfo))
+    return NULL;
+
+  oprnd0 = gimple_assign_rhs1 (last_stmt);
+  oprnd1 = gimple_assign_rhs2 (last_stmt);
+  itype = TREE_TYPE (oprnd0);
+  if (TREE_CODE (oprnd0) != SSA_NAME
+      || TREE_CODE (oprnd1) != INTEGER_CST
+      || TREE_CODE (itype) != INTEGER_TYPE
+      || TYPE_PRECISION (itype) != GET_MODE_PRECISION (TYPE_MODE (itype)))
+    return NULL;
+  vectype = get_vectype_for_scalar_type (itype);
+  if (vectype == NULL_TREE)
+    return NULL;
+
+  /* If the target can handle vectorized division or modulo natively,
+     don't attempt to optimize this.  */
+  optab = optab_for_tree_code (rhs_code, vectype, optab_default);
+  if (optab != unknown_optab)
+    {
+      machine_mode vec_mode = TYPE_MODE (vectype);
+      int icode = (int) optab_handler (optab, vec_mode);
+      if (icode != CODE_FOR_nothing)
+        return NULL;
+    }
+
+  prec = TYPE_PRECISION (itype);
+  if (integer_pow2p (oprnd1))
+    {
+      /*if (TYPE_UNSIGNED (itype) || tree_int_cst_sgn (oprnd1) != 1)
+        return NULL;
+     */
+
+      /* Pattern detected.  */
+      if (dump_enabled_p ())
+        dump_printf_loc (MSG_NOTE, vect_location,
+                         "vect_recog_multconst_pattern: detected:\n");
+
+          tree shift;
+
+          shift = build_int_cst (itype, tree_log2 (oprnd1));
+          pattern_stmt
+            = gimple_build_assign (vect_recog_temp_ssa_var (itype, NULL),
+                                   LSHIFT_EXPR, oprnd0, shift);
+      if (dump_enabled_p ())
+        dump_gimple_stmt_loc (MSG_NOTE, vect_location, TDF_SLIM, pattern_stmt,
+                              0);
+
+     stmts->safe_push (last_stmt);
+
+      *type_in = vectype;
+      *type_out = vectype;
+      return pattern_stmt;
+   }
+    return NULL;
+}
 /* Detect a signed division by a constant that wouldn't be
    otherwise vectorized:

diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h
index 48c1f8d..833fe4b 100644
--- a/gcc/tree-vectorizer.h
+++ b/gcc/tree-vectorizer.h
@@ -1131,7 +1131,7 @@ extern void vect_slp_transform_bb (basic_block);
    Additional pattern recognition functions can (and will) be added
    in the future.  */
 typedef gimple (* vect_recog_func_ptr) (vec<gimple> *, tree *, tree *);
-#define NUM_PATTERNS 12
+#define NUM_PATTERNS 13
 void vect_pattern_recog (loop_vec_info, bb_vec_info);

 /* In tree-vectorizer.c.  */
---Patch ---

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[noloader at gmail dot com]

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

--- Comment #6 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #5)
> ...
> For what is worth, I understand the point by Andrew that without -fopenmp,
> the #pragmas are effectively ignored, thus the warning seems useful. Perhaps
> it would be more useful a specific -Wopenmp-pragmas  that says:
> 

Maybe it could be in effect with `-Wextra`?

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 :(
>From gcc-bugs-return-492824-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 20 10:43:00 2015
Return-Path: <gcc-bugs-return-492824-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21106 invoked by alias); 20 Jul 2015 10:43:00 -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 21061 invoked by uid 48); 20 Jul 2015 10:42:56 -0000
From: "jiwang at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63304] Aarch64 pc-relative load offset out of range
Date: Mon, 20 Jul 2015 10:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: assemble-failure
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jiwang at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P5
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-63304-4-2x6XgKHQpE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63304-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/msg01714.txt.bz2
Content-length: 821

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

Jiong Wang <jiwang at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jiwang at gcc dot gnu.org

--- Comment #16 from Jiong Wang <jiwang at gcc dot gnu.org> ---
Have done a quick look at this, basic ideas to fix this:

  * generate a special pattern which initialize literal pool start address.
  * implement TARGET_MACHINE_DEPENDENT_REORG to calculate whehter the
    pc-relative literal load is within range.
  * output final insruction sequences which initializing literal pool start
    address based on the result from reorg pass analysis. Use movk/z, adrp +
add,
    single adr for different distance.

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[manu at gcc dot gnu.org]

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).