[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
https://bugs.llvm.org/show_bug.cgi?id=33008
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
following:
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
/tmp/conftest.mtiJyc.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 10.247.28.122
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.
Kleckner:
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.
Teresa:
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
silently.
--
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