Re: ARMv8, GCC 4.9 and necessary code optimized away?

[Jeffrey Walton <noloader at gmail dot com>]

On Wed, Jun 1, 2016 at 3:32 AM, Andrew Haley <aph@redhat.com> wrote:
> On 31/05/16 21:37, Jeffrey Walton wrote:
>>> Like Florian said, 'w' is not being used so the compiler may optimise the
>>> whole sequence away.
>>
>> I'm pretty sure this is another instance of a language defect. The
>> C/C++ language does not allow us to properly express ourselves, and
>> the result is the removal of critical code.
>
> The problem here is that GCC knows that the CRC instructions have
> no side effects beyond their operands.  So GCC doesn't generate
> the instructions.

That's presuming some things that miss the mark in this case.

I'm still sorting it out in my mind, but ... Computer programs are
code and data. Most of the time optimizers are correct in guessing
that an unused result is dead and the accompanying code is dead. One
of the most fundamental problems seems to be: why is all this guessing
going on?

A memset to zeroize sensitive data in memory has both code and data.
It needs to survive.

An statement to test for the presence of an instruction is only code.
It needs to survive.

A set of statements to flush cpu cache lines has both code and data.
It needs to survive.

In all the cases, the C/C++ language does not allow me to express the
code and sometimes the data needs to survive. I should be able to take
the guess work out of the equation for special cases.

>> This is at least the third or fourth time. The one prior to this
>> resulted in CVE-2016-3995.
>
> Of course GCC deletes dead code.  That's one of the most basic
> optimizations.

The C/C++ committee acknowledged optimizations vis-Ã-vis the
__restrict keyword. Now they need to give me the tools I need to tame
the optimizer to avoid bad guesses so I don't have to resort to stupid
volatile tricks.

At best, volatile is an abuse under GCC
(http://www.airs.com/blog/archives/154). At worst, its fragile and
going to break in the future as GCC analysis gets better. And its only
going to get trickier as link-time optimizations are added to the mix.

> In your case I'd just use the result as an input operand into an
> asm.

Then I loose the portability of C/C++ and intrinsics. I'm trying to
increase portability and reduce maintenance, not turn it on its head
:)

Also, the inline assembler is not the easiest to work with, and its
another can can of worms I prefer not to open. I'm still confounded by
how difficult it is to use extended asm to save some registers,
calculate a result, save the result and then pop the registers. I
still can't figure out how to do it (the pain point is: save the
result and then pop the registers).

For completeness, I don't blame GCC. I blame the C/C++ committee for
not giving us what we need.

Jeff