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
