[llvm-bugs] [Bug 27449] New: Retire the non-deterministic ASTFileSignature

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27449

            Bug ID: 27449
           Summary: Retire the non-deterministic ASTFileSignature
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Modules
          Assignee: unassignedclangbugs at nondot.org
          Reporter: aprantl at apple.com
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org
    Classification: Unclassified

Implicitly-built modules currently contain a random 32-bit ASTFileSignature.
This makes clang modules nondeterministic which is generally undesirable.

ASTReader has a comment that explains how we arrived at the status quo nicely:

    // For implicit modules we output a signature that we can use to ensure
    // duplicate module builds don't collide in the cache as their output order
    // is non-deterministic.
    // FIXME: Remove this when output is deterministic.
    if (Context.getLangOpts().ImplicitModules) {
      Signature = getSignature();
      RecordData::value_type Record[] = {Signature};
      Stream.EmitRecord(SIGNATURE, Record);
    }


  static ASTFileSignature getSignature() {
    while (1) {
      if (ASTFileSignature S = llvm::sys::Process::GetRandomNumber())
        return S;
      // Rely on GetRandomNumber to eventually return non-zero...
    }
  }

The existence of test/Modules/stress1.cpp seems to indicate that we were able
to remove all(?) sources of nondeterminism in the mean time, so we should be
able to retire this hack.

A minor complication is that module debug info currently uses the module
signature as the DWO_id to uniquely identify a module, but we should be able to
replace this by an actual hash of the serialized AST (which won't be
deterministic until after the ASTFileSignature is removed).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160421/5dac202b/attachment.html>