This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [committed] prune warning from test output to avoid arm-none-eabi failure (PR 83303)
On 12/06/2017 03:58 PM, Jeff Law wrote:
On 12/06/2017 12:41 PM, Jeff Law wrote:
On 12/06/2017 12:27 PM, Martin Sebor wrote:
For reference, I committed r255450 to avoid the test failure
reported on the arm-none-eabi target. The warning is valid
but unrelated to the purpose of the test so I pruned it from
its output.
Martin
Index: gcc/testsuite/ChangeLog
===================================================================
--- gcc/testsuite/ChangeLog (revision 255449)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -9,6 +9,9 @@
2017-12-06 Martin Sebor <msebor@redhat.com>
+ PR testsuite/83303
+ * g++.dg/opt/new1.C: Prune warning from test output.
The path to the erroneous behavior should be caught and eliminated by
DOM. That's the whole point behind one of the recent changes.
Instead we need to figure out why it wasn't caught on arm-none-eabi.
Martin, can you look into why on x86_64 the initial code we generate for
QScript::Buffer<T>::reserve looks like this:
There's a difference between the underlying type and size of
the QScript::Type enum in the ABIs. On arm-non-eabi the size
of its underlying type is 1. On arm-linux-gnueabi and x86_64
the size is 4. The C++ front end only inserts a length check
for the new expression when the element size is more than 1.
This is to avoid unsigned wrapping when computing the number
of bytes to allocate, as N * sizeof (T). With the arm-non-eabi
cross compiler the warning disappears when the size of the enum
is more than 1. Similarly, changing the size of the enum is
changed to 1 makes the warning appear on arm-linux-gnueabi as
well as a native x86_64 compiler.
I think this confirms that the test is not useful to validate
the range work (it's meant to verify the absence of an ICE)
and warnings emitted for it aren't necessarily reliable
indicators one way or the other. As I said in the PR, I think
issuing a warning for the test would actually be helpful given
that the code will unavoidably abort at runtime.
This feels like something the front-end is doing to me.
Yes, the C++ front end has conspired with the ABI to bite us
both.
Martin