- User Since
- Aug 28 2017, 11:01 AM (153 w, 2 d)
Fri, Jul 31
Hello, I have a twice-daily auto-bisecting multi-stage cron job running on Fedora 32 (x86-64) that has identified this commit as failing my first stage test (release + no asserts). Is this expected? Can we get a quick fix or revert this?
Wed, Jul 22
I have a multi-stage, auto-git-bisecting bot that has identifying this commit as the source of a regression on Fedora 32 (x86-64). This commit broke my first stage test (release, no asserts). Might a quick fix happen or do we need to revert this?
Tue, Jul 14
Sun, Jul 12
Hello. I have an auto-bisecting multi-stage bot that is failing on two after this change. Can we please revert this or commit a quick fix?
Jul 4 2020
What compilers was this tested on? This seems to be failing on clang 10 (Fedora 32 x86-64). Can we revert this or commit a quick fix?
Jul 3 2020
Jun 27 2020
Jun 26 2020
Now that my core concern is addressed (moving clang's default module cache out of /tmp), I don't have the time to push for this deprecation. Sorry.
Jun 23 2020
Moved clang specific changes to: https://reviews.llvm.org/D82362
Jun 22 2020
- Respect Darwin and XDG cache directories.
- Drop atypical reverse DNS in the path.
- Make clang more robust if the default module path cannot be determined.
Sure, we can honor XDG_CACHE_DIR. Maybe as a followup, somebody can wire up Darwin's cache directory (which is retrievable via a BSD specific confstr() API with _CS_DARWIN_USER_CACHE_DIR). I'm not sure about other platforms.
Unless I'm missing something, consolidating this logic into LLVM's CMakeLists.txt will break stand alone builds of sub-projects and external projects that depend on this logic.
Jun 21 2020
“N/300” implies that you’re not building all of llvm, clang, etc otherwise thousands of files would build.
Naive build output is one line per file (plus output).
Jun 20 2020
Jun 3 2020
May 30 2020
May 29 2020
This change breaks building on Fedora 32 with clang-10 (as shipped by Fedora). Can we revert this or commit a quick fix?
May 18 2020
May 16 2020
May 15 2020
I'm going to abandon this change for now. The problem is that the MS extensions are not as pervasive through the language as I wanted. For example, I'd really like them to work on aggregate types. This would allow all of the pointers to said types to not need annotation, unlike the current MS model.
May 14 2020
May 13 2020
May 12 2020
May 10 2020
May 9 2020
May 8 2020
This is failing stage two testing on my Fedora 32 (x86-64) Linux box. Can we please revert this or commit a quick fix?
Great. Thanks. As a friendly reminder, you’ll need to configure the first stage to use libcxx and also have clang to prefer libcxx, otherwise lld will just use whatever CMake autodetects/decides.
Hello, git bisect of a private stage two builder identified this commit as breaking lld's test suite. Can we either revert this or commit a quick fix to the regular expressions in lld's test suite?
FAIL: lld :: ELF/vs-diagnostics-duplicate-split.s (63239 of 63760) ******************** TEST 'lld :: ELF/vs-diagnostics-duplicate-split.s' FAILED ******************** Script: -- : 'RUN: at line 2'; /tmp/_update_lc/t/bin/llvm-mc -filetype=obj -triple=x86_64 /home/dave/s/lp/lld/test/ELF/vs-diagnostics-duplicate-split.s -o /tmp/_update_lc/t/tools/lld/test/ELF/Output/vs-diagnostics-duplicate-split.s.tmp.o : 'RUN: at line 3'; not /tmp/_update_lc/t/bin/ld.lld --vs-diagnostics --shared /tmp/_update_lc/t/tools/lld/test/ELF/Output/vs-diagnostics-duplicate-split.s.tmp.o /tmp/_update_lc/t/tools/lld/test/ELF/Output/vs-diagnostics-duplicate-split.s.tmp.o -o /dev/null 2>&1 | /tmp/_update_lc/t/bin/FileCheck /home/dave/s/lp/lld/test/ELF/vs-diagnostics-duplicate-split.s -- Exit Code: 1
May 7 2020
Hi @ldionne – I've looked a few more tests that use lit's ALLOW_RETRIES feature. I don't think this is a straightforward scenario. While the flawed assumptions are often the same, the fixes are not. Do you want 46 Phab requests? Personally speaking, this seems like one of those cases where the cost of code review discourages bug fixes. If I create decent enough commit messages, would you be open to post-commit review for these test fixes? After all, the tests are already buggy, and we can always revert back to the known buggy version that we have today.
May 6 2020
Ran through git clang-format to fix formatting issues that predate these fixes.
Fixed two more tests as an example of how to fix the other thread tests.
Hi @ldionne – Ya, it looks like a lot of those tests need fixing. The "tolerance" goal is within them is fundamentally flawed. These tests are not testing "real time" APIs where one can hopefully reason about precise timing. These APIs are best-effort APIs and on a slow and/or heavily loaded machine, best-effort can get really slow. I don't have the time to fix all of the tests but here is the gist of what needs fixing is twofold:
May 5 2020
Ran the patch through clang-format and then manually fixed style problems that clang-format did not fix.
Apr 29 2020
Apr 28 2020
Apr 27 2020
Apr 26 2020
Rather than wholly reverting this, I committed a fix: 665471907a5c072c6653a38c35f35e5d54cef220
Apr 25 2020
This breaks building libclang on Fedora 32 with clang 10.0 and lld 10.0. Do you mind if I revert this tomorrow if a quick fix cannot be found? Here is the relevant diagnostics:
Apr 23 2020
Apr 22 2020
Apr 16 2020
Apr 15 2020
FYI – This is generating new warnings with top-of-tree clang. That being said, the warning itself might be faulty:
/usr/local/include/llvm/ADT/STLExtras.h:115:58: warning: HTML tag 'i' requires an end tag [-Wdocumentation-html] /// * To access the type of an argument: Traits::arg_t<i> ~^~ 1 warning generated.
Apr 5 2020
Mar 29 2020
Feb 14 2020
I'm abandoning this due to lack of time and the problem being more involved than I thought.
Feb 11 2020
Feb 9 2020
Hi @MaskRay – I was just looking at the source history. I didn't test the old way. As it turns out there isn't a regression, but just some unexplained code in the current clang option parsing. And the -disable-O0-optnone is a useful hint. Thanks! I've been hacking on clang and trying to get the normal inliner pass to run at -O0, but with no luck so far.
Hi @lebedev.ri – Before I add a small new test file, is there an existing one that you know of that would be good to extend?
Jan 31 2020
Jan 30 2020
This breaks the test suite when built "Release" without assertions enabled (Fedora 31 on x86_64). Can we please revert this?
FAIL: libc++ :: std/con:q:qtainers/sequences/array/array.creation/to_array.fail.cpp (53333 of 61086)
- TEST 'libc++ :: std/containers/sequences/array/array.creation/to_array.fail.cpp' FAILED ****
Command: ['/usr/bin/clang++', '-o', '/dev/null', '-x', 'c++', '/home/dave/s/lp/libcxx/test/std/containers/sequences/array/array.creation/to_array.fail.cpp', '-c', '-v', '-ftemplate-depth=270', '-fsyntax-only', '-Xclang', '-verify', '-Xclang', '-verify-ignore-unexpected=note', '-ferror-limit=1024', '-Werror=thread-safety', '-std=c++2a', '-include', '/home/dave/s/lp/libcxx/test/support/nasty_macros.h', '-nostdinc++', '-I/home/dave/s/lp/libcxx/include', '-I/tmp/_update_lc/r/projects/libcxx/include/c++build', '-DSTDC_FORMAT_MACROS', '-DSTDC_LIMIT_MACROS', '-D__STDC_CONSTANT_MACROS', '-I/home/dave/s/lp/libcxx/test/support', '-DLIBCXX_FILESYSTEM_STATIC_TEST_ROOT="/home/dave/s/lp/libcxx/test/std/input.output/filesystems/Inputs/static_test_env"', '-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT="/tmp/_update_lc/r/projects/libcxx/test/filesystem/Output/dynamic_env"', '-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_HELPER="/usr/bin/python /home/dave/s/lp/libcxx/test/support/filesystem_dynamic_test_helper.py"', '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall', '-Wextra', '-Werror', '-Wuser-defined-warnings', '-Wshadow', '-Wno-unused-command-line-argument', '-Wno-attributes', '-Wno-pessimizing-move', '-Wno-c++11-extensions', '-Wno-user-defined-literals', '-Wno-noexcept-type', '-Wsign-compare', '-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', '-Wno-error=user-defined-warnings', '-c']
Exit Code: 1
clang version 9.0.0 (Fedora 9.0.0-1.fc31)
Thread model: posix
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/9
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
"/usr/bin/clang-9" -cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -disable-free -disable-llvm-verifier -discard-value-names -main-file-name to_array.fail.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -v -nostdinc++ -resource-dir /usr/lib64/clang/9.0.0 -include /home/dave/s/lp/libcxx/test/support/nasty_macros.h -I /home/dave/s/lp/libcxx/include -I /tmp/_update_lc/r/projects/libcxx/include/c++build -D STDC_FORMAT_MACROS -D STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -I /home/dave/s/lp/libcxx/test/support -D "LIBCXX_FILESYSTEM_STATIC_TEST_ROOT=\"/home/dave/s/lp/libcxx/test/std/input.output/filesystems/Inputs/static_test_env\"" -D "LIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT=\"/tmp/_update_lc/r/projects/libcxx/test/filesystem/Output/dynamic_env\"" -D "LIBCXX_FILESYSTEM_DYNAMIC_TEST_HELPER=\"/usr/bin/python /home/dave/s/lp/libcxx/test/support/filesystem_dynamic_test_helper.py\"" -D _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -internal-isystem /usr/local/include -internal-isystem /usr/lib64/clang/9.0.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -Werror=thread-safety -Wall -Wextra -Werror -Wuser-defined-warnings -Wshadow -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-error=user-defined-warnings -std=c++2a -fdeprecated-macro -fdebug-compilation-dir /tmp/_update_lc/r -ftemplate-depth 270 -ferror-limit 1024 -fmessage-length 0 -fno-implicit-modules -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -verify -verify-ignore-unexpected=note -faddrsig -x c++ /home/dave/s/lp/libcxx/test/std/containers/sequences/array/array.creation/to_array.fail.cpp
clang -cc1 version 9.0.0 based upon LLVM 9.0.0 default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
End of search list.
error: 'error' diagnostics expected but not seen:
File /home/dave/s/lp/libcxx/test/std/containers/sequences/array/array.creation/to_array.fail.cpp Line 20: here File /home/dave/s/lp/libcxx/test/std/containers/sequences/array/array.creation/to_array.fail.cpp Line 25: here File /home/dave/s/lp/libcxx/test/std/containers/sequences/array/array.creation/to_array.fail.cpp Line 30: here
error: 'error' diagnostics seen but not expected:
File /home/dave/s/lp/libcxx/include/array Line 499: static_assert failed due to requirement '!is_array_v<char >' "[array.creation]/1: to_array does not accept multidimensional arrays." File /home/dave/s/lp/libcxx/include/array Line 502: static_assert failed due to requirement 'is_constructible_v<char , char (&)>' "[array.creation]/1: to_array requires copy constructible elements." File /home/dave/s/lp/libcxx/include/array Line 487: cannot initialize an array element of type 'char' with an lvalue of type 'char ' File /home/dave/s/lp/libcxx/include/array Line 487: cannot initialize an array element of type 'char' with an lvalue of type 'char ' File /home/dave/s/lp/libcxx/include/array Line 487: cannot initialize an array element of type 'char' with an lvalue of type 'char ' File /home/dave/s/lp/libcxx/include/array Line 487: suggest braces around initialization of subobject File /home/dave/s/lp/libcxx/include/array Line 502: static_assert failed due to requirement 'is_constructible_v<MoveOnly, MoveOnly &>' "[array.creation]/1: to_array requires copy constructible elements." File /home/dave/s/lp/libcxx/include/array Line 487: calling a private constructor of class 'MoveOnly' File /home/dave/s/lp/libcxx/include/array Line 514: static_assert failed due to requirement 'is_move_constructible_v<const MoveOnly>' "[array.creation]/4: to_array requires move constructible elements." Line 493: calling a private constructor of class 'MoveOnly'
13 errors generated.
Jan 24 2020
The bots are probably green because libcxx tests against the installed compiler, not the just built compiler. Also, I'm fairly confident at this point that either no bots are testing libcxx against top-of-tree clang, or nobody is paying attention to the bots that do.
I understand not wanting to have trivial dependencies on IR for values like this, but what about creating llvm/Support/InternalLimits.h to hold values like this, and then *either* have llvm::Value::MaximumAlignment derive from the constant in the new file, or static_assert that the internal limit constant equals llvm::Value::MaximumAlignment?
Jan 22 2020
Ping. Feedback would be appreciated. Thanks
Jan 18 2020
Jan 15 2020
This should in theory be fixed by D70447.