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 <mse...@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:
struct QScriptValueImpl * new_data; <<cleanup_point <<< Unknown tree: expr_stmt (void) (new_data = TARGET_EXPR <D.2456, operator new [] (SAVE_EXPR <(sizetype) ((struct Buffer *) this)->m_capacity> <= 2305843009213693950 ? (long unsigned int) (SAVE_EXPR <(sizetype) ((struct Buffer *) this)->m_capacity> * 4) : (long unsigned int) __cxa_throw_bad_array_new_length ())>;, try Note the test against capacity. Yet on arm-none-eabi we have: (void) (new_data = TARGET_EXPR <D.4742, operator new [] ((unsigned int) NON_LVALUE_EXPR <SAVE_EXPR <(sizetype) ((struct Buffer *) this)->m_capacity>>)>;, try This is important because after inlining the test that you see in the x86 version is guarded by a test (of the same object) for < 0. Naturally no object can satisfy both of those conditions. It may be easier to see it in the .gimple dump. For x86_64: QScript::Buffer<QScriptValueImpl>::reserve (struct Buffer * const this, int x) { void * D.2456; long unsigned int iftmp.0; sizetype D.2481; struct QScriptValueImpl * retval.1; struct QScriptValueImpl * D.2457; struct QScriptValueImpl * D.2458; long int D.2459; struct QScriptValueImpl * new_data; _1 = this->m_capacity; D.2481 = (sizetype) _1; if (D.2481 <= 2305843009213693950) goto <D.2482>; else goto <D.2483>; <D.2482>: iftmp.0 = D.2481 * 4; goto <D.2484>; <D.2483>: __cxa_throw_bad_array_new_length (); <D.2484>: D.2456 = operator new [] (iftmp.0); In contrast on arm we have the following: QScript::Buffer<QScriptValueImpl>::reserve (struct Buffer * const this, int x) { void * D.4742; sizetype D.4769; struct QScriptValueImpl * retval.0; struct QScriptValueImpl * D.4743; struct QScriptValueImpl * D.4744; int D.4745; struct QScriptValueImpl * new_data; _1 = this->m_capacity; D.4769 = (sizetype) _1; D.4742 = operator new [] (D.4769); This feels like something the front-end is doing to me. jeff