This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/66099] _Pragma diagnostic 'ignored' in macro with strict-overflow not suppressing warning fully with -Werror
- From: "manu at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 03 Jun 2015 08:53:42 +0000
- Subject: [Bug c++/66099] _Pragma diagnostic 'ignored' in macro with strict-overflow not suppressing warning fully with -Werror
- Auto-submitted: auto-generated
- References: <bug-66099-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66099
Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-06-03
CC| |manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> ---
This is because the location of the warning is given at 21:19, which is not
within the range affected by the #pragmas. Whether the warning should be given
at the macro definition point or at the expansion point is a matter of debate
(there are at least two PRs open about this, but I don't remember the numbers).
Differences between C and C++ are spurious and may lead to the pragmas applying
or not:
cc1:
/home/manuel/test2/pr66099.cc:21:3: error: assuming signed overflow does not
occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]
TESTING(i + 4 < i);
^
cc1plus:
/home/manuel/test2/pr66099.cc:21:19: error: assuming signed overflow does not
occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]
TESTING(i + 4 < i);
^
Someone would need to track the locations in GDB and understand why they
diverge. Unfortunately, this is not something that usual devs will spend time
on given the amount of other things waiting to be fixed. If this is important
to you, I would recommend to try to figure out the reason yourself. Once the
problem is clear, it is far more likely that a GCC dev will produce a patch and
fix it.