[llvm-bugs] [Bug 33008] New: clang fails if /proc/cpuinfo cannot be read

via llvm-bugs llvm-bugs at lists.llvm.org
Thu May 11 13:00:54 PDT 2017


            Bug ID: 33008
           Summary: clang fails if /proc/cpuinfo cannot be read
           Product: clang
           Version: 4.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: MillerHenry at johndeere.com
                CC: llvm-bugs at lists.llvm.org

when using clang 4.0 in a chroot builds fail because the file /proc/cpuinfo
does not exist. 

This is common setup when using icecream where you see errors like the
 0:05.57 checking for the target C compiler... /usr/bin/clang
 0:05.69 checking whether the target C compiler can be used... yes
 0:05.69 checking the target C compiler version... 4.0.0
 0:14.61 checking the target C compiler works... no
 0:14.61 DEBUG: Creating `/tmp/conftest.mtiJyc.c` with content:
 0:14.61 DEBUG: |
 0:14.61 DEBUG: | int
 0:14.61 DEBUG: | main(void)
 0:14.61 DEBUG: | {
 0:14.61 DEBUG: |
 0:14.61 DEBUG: |   ;
 0:14.61 DEBUG: |   return 0;
 0:14.61 DEBUG: | }
 0:14.61 DEBUG: Executing: `/usr/bin/icecc /usr/bin/clang -std=gnu99 -c
 0:14.61 DEBUG: The command returned non-zero exit status 105.
 0:14.61 DEBUG: Its error output was:
 0:14.61 DEBUG: | Can't read /proc/cpuinfo: No such file or directory
 0:14.61 DEBUG: | ICECC[6490] 10:54:26: Compiled on
 0:14.61 ERROR: Failed compiling a simple C source with the target C compiler

>From what I can tell this came in from: https://reviews.llvm.org/D25564.  

This seems like an LLVM bug. I'd rather LLVM didn't look in /proc, but I can't
find an alternative. In any case, we shouldn't print to stderr for a successful
build. Silently falling back to std::thread::hardware_concurrency() seems fine,
which is what the code does.

Agreed, we should at least return -1 if we can't find /proc/cpuinfo (which will
result in fallback to std::thread::hardware_concurrency()). The question I have
is whether it should be silent or not - my understanding was that this file
should exist in x86_64 Linux.

But I am also wondering how you hit this, since reading through the github
thread you linked indicated that this is not LTO or ThinLTO. Oh, I see now
where it is being used to initialize the value of an option...if this is a file
that will not always exist for Linux x86_64 then it needs to fall back

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/20170511/a14591f2/attachment.html>

More information about the llvm-bugs mailing list