[llvm-bugs] [Bug 46392] New: Diagnostic message (error) related to ThinLTO caching needs to be downgraded to a remark

[via llvm-bugs]

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

            Bug ID: 46392
           Summary: Diagnostic message (error) related to ThinLTO caching
                    needs to be downgraded to a remark
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: lto
          Assignee: unassignedbugs at nondot.org
          Reporter: katya.romanova at sony.com
                CC: llvm-bugs at lists.llvm.org

There are diagnostic messages related to ThinLTO caching (in the file
"llvm/lib/LTO/ThinLTOCodeGenerator.cpp") that contain the word "error", but
they are really just notices/remarks for users, and they don't cause a build
failure. The word "error" appearing can be confusing to users, and may even
cause deeper problems.

In a certain situation we encounter a ThinLTO build error which included LTO
cache diagnostic message of the form:
error: can't link or copy from cached entry '<a>' to '<b>'
User's build system might be designed to interpret any error messages (even a
benign error message as the one above) reported by the compiler as a build
failure, thus causing the build to fail "needlessly". In short, the term
"error" in this diagnostic is misleading at best, and may be causing build
systems to fail at worst. 

We would like to downgrade this "error" message to a diagnostic remark.


The code that produces this diagnostic (containing the word "error") is in the
following method, in the file "llvm/lib/LTO/ThinLTOCodeGenerator.cpp":

/// Write out the generated object file, either from CacheEntryPath or from
/// OutputBuffer, preferring hard-link when possible.
/// Returns the path to the generated file in SavedObjectsDirectoryPath.
std::string
ThinLTOCodeGenerator::writeGeneratedObject(int count, StringRef CacheEntryPath,
                                           const MemoryBuffer &OutputBuffer) {
  auto ArchName = TMBuilder.TheTriple.getArchName();
  SmallString<128> OutputPath(SavedObjectsDirectoryPath);
  llvm::sys::path::append(OutputPath,
                          Twine(count) + "." + ArchName + ".thinlto.o");
  OutputPath.c_str(); // Ensure the string is null terminated.
  if (sys::fs::exists(OutputPath))
    sys::fs::remove(OutputPath);

  // We don't return a memory buffer to the linker, just a list of files.
  if (!CacheEntryPath.empty()) {
    // Cache is enabled, hard-link the entry (or copy if hard-link fails).
    auto Err = sys::fs::create_hard_link(CacheEntryPath, OutputPath);
    if (!Err)
      return std::string(OutputPath.str());
    // Hard linking failed, try to copy.
    Err = sys::fs::copy_file(CacheEntryPath, OutputPath);
    if (!Err)
      return std::string(OutputPath.str());
    // Copy failed (could be because the CacheEntry was removed from the cache
    // in the meantime by another process), fall back and try to write down the
    // buffer to the output.
    errs() << "error: can't link or copy from cached entry '" << CacheEntryPath
           << "' to '" << OutputPath << "'\n";
  }
  // No cache entry, just write out the buffer.
  std::error_code Err;
  raw_fd_ostream OS(OutputPath, Err, sys::fs::OF_None);
  if (Err)
    report_fatal_error("Can't open output '" + OutputPath + "'\n");
  OS << OutputBuffer.getBuffer();
  return std::string(OutputPath.str());
}

As can be seen in the above code, if the copying from the cache fails, we just
fall back and write a previously loaded cache entry (stored in OutputBuffer)
into a file (OutputPath). The recovery happens gracefully and continues without
an error. 
    errs() << "remark: can't link or copy from cached entry '" <<
CacheEntryPath
           << "' to '" << OutputPath << "'\n";

-- 
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/20200618/b01662bf/attachment.html>