[csmith-dev] testing C++11 struct rules

[Arthur O'Dwyer]

On Tue, May 15, 2012 at 7:27 AM, John Regehr <regehr at cs.utah.edu> wrote:
>
> You know, I'm not sure that compiler-introduced races in local structs are
> that big of a deal.  I'm also not sure that compiler developers would even
> fix those!  Realistically, shared variables that matter for races are going
> to be globals.

Personally, I doubt that compiler-introduced races in *global* structs
are that big of a deal, either. I have no idea what the Committee's
rationale for the change was (not that I've researched it); but has
anyone *ever* seen a program bug caused by the previously permissible
"load-mask-store" idiom?  And if anyone ever did see such a bug in
C89/C99 code, they'd have fixed it by reading the Standard, going "oh,
I see what I'm doing wrong," and making the offending struct volatile
in their own code.

[...]
> But I doubt we'll ever work on volatile locals since the major issue with
> volatile bugs is convincing people to fix them, not finding them.

Acknowledged. :)  Do you think it'll be easier to convince people that
C'12 struct accesses matter *more* than local volatiles, though?  I
think with local volatiles you could say "This bug was exposed with
local volatiles, but tomorrow it might affect global volatiles."  With
C'12 struct accesses, the only people who'll care are those few going
for 100% C'12 compliance at all costs.  (Is GCC or Clang likely to
pursue 100% compliance?  Has CompCert even caught up to C99 yet?)

> However, I do intend to get back to volatile testing at some point.  So far
> we never looked at the values stored into volatiles, nor checked that the
> values loaded are paid attention to by the compiler,

Ooh. I never even thought of that as a potential issue, but you're
totally right.

> nor have we looked for
> illegal reordering of volatile accesses.  None of this is particularly
> tricky, it will just take a bit of time to get it all going.

If the access-summary-testing approach turns C'12 struct bugs into
low-hanging fruit, then by all means, go ahead. But otherwise IMHO you
should drop it for now and go back to those volatile bugs. A compiler
bug that caused the wrong value to be "read" out of a volatile would
be a Big Deal, if you managed to find one.

-Arthur