[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields

[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields

[tom at atoptech dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170

--- Comment #12 from Tom Geocaris <tom at atoptech dot com> 2013-01-04 17:32:22 UTC ---
Is there any resolution to this issue? We need to move to a more recent version
of gcc, but are still stuck at gcc 4.2.4. 

I looked at gcc 4.7.2 but behavior is the same and I don't see an option to
suppress these warnings.

[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170

--- Comment #13 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-01-04 17:53:00 UTC ---
(In reply to comment #12)
> Is there any resolution to this issue? We need to move to a more recent version
> of gcc, but are still stuck at gcc 4.2.4. 

I think the best option would be to have a GCC extension for casting bit-field
types (int:2) so they can be used to silence false positives. But this may be
rejected by the C/C++ FE maintainers, so unless you get their approval, I
wouldn't try to pursue it.

The second best option, and probably easier to implement, is to have a new
option -Wconversion-bitfields that gives the Wconversion warning for bitfields
and use that to control the warning code like:

      if (unsafe_conversion_p (type, expr, true))
    warning_at (loc, TYPE_IS_BITFIELD(type) ? OPT_Wconversion_bitfield :
OPT_Wconversion,
            "conversion to %qT alters %qT constant value",
            type, expr_type);
      return;

I don't even know if TYPE_IS_BITFIELD exists or there is an equivalent API.

Personally, I have no free time to work on this, so someone else will have to
do it. I can give some hints on what you would need to do to implement it if
someone is interested and needs guidance.

[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields

[egall at gwmail dot gwu.edu]

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

Eric Gallager <egall at gwmail dot gwu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egall at gwmail dot gwu.edu

--- Comment #14 from Eric Gallager <egall at gwmail dot gwu.edu> ---
(In reply to Jeng-Liang Tsai from comment #10)
> Would it be possible for gcc to provide a -Wbitfield-conversion flag in new
> releases and make 39170 an enhancement (preferably high priority)?

Just an FYI, there's a proposal to add a -Wbitfield-conversion flag that does
something slightly different than the behavior described in this issue; for
reference, see: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00723.html
I'd be fine with it doing either the behavior in that patch, or the behavior
from this issue...

[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields

[manu at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic

--- Comment #15 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Eric Gallager from comment #14)
> Just an FYI, there's a proposal to add a -Wbitfield-conversion flag that
> does something slightly different than the behavior described in this issue;
> for reference, see: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00723.html
> I'd be fine with it doing either the behavior in that patch, or the behavior
> from this issue...

I think the two behaviors are orthogonal. People still need an option that
refines -Wconversion and allows silencing it for bit-fields. I will prefer if
this option is called -Wbitfield-conversion and the other proposal is called
something else (-Wbitfield-promotion ? -Wbitfield-shift ?).

But whoever does the implementation work, will decide the name.
>From gcc-bugs-return-479613-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 06 20:36:03 2015
Return-Path: <gcc-bugs-return-479613-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 119046 invoked by alias); 6 Mar 2015 20:36:02 -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 118962 invoked by uid 48); 6 Mar 2015 20:35:57 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
Date: Fri, 06 Mar 2015 20:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64467-4-c0XJ8QLDUP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64467-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64467-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-03/txt/msg00757.txt.bz2
Content-length: 1010

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

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I suggest we just do this and get on with our lives:

index 8f71910..62d3740 100644
--- a/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc
+++ b/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc
@@ -54,11 +54,7 @@ test01()
   VERIFY(!t.isctype('_', t.lookup_classname(range(digit))));
   VERIFY( t.isctype(' ', t.lookup_classname(range(blank))));
   VERIFY( t.isctype('\t', t.lookup_classname(range(blank))));
-#if defined (NEWLINE_IN_CLASS_BLANK)
-  /* On some targets, '\n' is in class 'blank'.
-     See https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00059.html.  */
-  VERIFY( t.isctype('\n', t.lookup_classname(range(blank))));
-#else
+#if !defined (NEWLINE_IN_CLASS_BLANK)
   VERIFY(!t.isctype('\n', t.lookup_classname(range(blank))));
 #endif
   VERIFY( t.isctype('t', t.lookup_classname(range(upper), true)));


(and that file still has DOS line-endings at the top of it)

[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |in-gcc at baka dot org

--- Comment #22 from Eric Gallager <egallager at gcc dot gnu.org> ---
*** Bug 95213 has been marked as a duplicate of this bug. ***

[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields

[manu at gcc dot gnu dot org]

------- Comment #11 from manu at gcc dot gnu dot org  2010-03-06 12:18 -------
(In reply to comment #10)
> However, with so many lines of legacy code out there using bit-filed that have
> been proven to work, it doesn't make sense to revisit/modify them.  Would it be
> possible for gcc to provide a -Wbitfield-conversion flag in new releases and
> make 39170 an enhancement (preferably high priority)?

Seriously, I am not the "maintainer" of GCC diagnostics or even Wconversion.
Anyone can contribute!

Yes, it may be possible to provide such an option. I am not against such an
option and even if I were I cannot stop you from implementing it and getting it
approved by GCC maintainers. I don't know how much work it would be to
implement it, and out of kindness I might invest some of my free time to try to
do it for GCC 4.6. But even if I might try, that won't happen before summer
almost for sure, and then GCC 4.6 won't be available before late next year.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-03-06 12:18:44
               date|                            |
            Summary|cannot silence -Wconversion |provide an option to silence
                   |warnings for bit-fields     |-Wconversion warnings for
                   |                            |bit-fields


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170