https://github.com/boomanaiden154 updated
https://github.com/llvm/llvm-project/pull/97785
>From 38325cbf03e5013056dfc1b7939ec7c9738f9fe2 Mon Sep 17 00:00:00 2001
From: Aiden Grossman
Date: Sat, 19 Aug 2023 13:37:21 -0700
Subject: [PATCH 1/2] [clang][X86] Add __cpuidex function to cpuid.h
MSVC
https://github.com/boomanaiden154 closed
https://github.com/llvm/llvm-project/pull/97785
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
boomanaiden154 wrote:
Were these found manually or using some automated tooling? Based on the Rust
PR, it seems like these were found by just manually going through the results
from a regex?
https://github.com/llvm/llvm-project/pull/91854
___
cfe-com
boomanaiden154 wrote:
> That PR is 3 months old? What are the odds or the timeline of it getting
> merged?
Probably whenever the author gets back to reviewers. There might be a couple
rounds of review before things get pushed through, but patches for two
subprojects have landed already.
The
boomanaiden154 wrote:
In what configuration are you seeing these errors?
I believe most of the issues got resolved by this morning (PST) for the
buildbots.
https://github.com/llvm/llvm-project/pull/97129
___
cfe-commits mailing list
cfe-commits@lists
https://github.com/boomanaiden154 requested changes to this pull request.
The documentation build workflow is not really the correct place to put this.
Also, why can't we just run the python script as part of building the docs
instead of committing the result of the script to the repository?
h
@@ -34,8 +34,12 @@ config.test_format = lit.formats.ShTest(use_lit_shell == "0")
config.substitutions.append( ('%clang_cpp_skip_driver', ' %s %s %s ' %
(cc1_wrapper, config.clang, sysroot_flags)))
config.substitutions.append( ('%clang_cpp', ' %s --driver-mode=g++ %s ' %
(confi
@@ -0,0 +1,2 @@
+RUN: %cmake -G %cmake_generator -B %t -S %llvm_src_dir
-DCMAKE_C_COMPILER=%clang -DCMAKE_CXX_COMPILER=%clang
-DCMAKE_CXX_FLAGS="--driver-mode=g++" -DCMAKE_BUILD_TYPE=Release
boomanaiden154 wrote:
Why the `--driver-mode=g++` flag here?
https://
https://github.com/boomanaiden154 commented:
This looks very interesting!
Thanks for taking the time to collect all the numbers. It definitely seems like
collecting proper profiles for BOLT is something that we want to do, at least
for the CI compiler, given the numbers here.
I'm assuming you
https://github.com/boomanaiden154 edited
https://github.com/llvm/llvm-project/pull/111625
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
boomanaiden154 wrote:
> That's an excellent question, maybe @owenca will know! I should have asked in
> https://github.com/llvm/llvm-project/pull/96804#discussion_r1718407404; what
> I did instead was try to reason out an explanation based on what I could see,
> and I came up with two theories
@@ -0,0 +1,2 @@
+RUN: %cmake -G %cmake_generator -B %t -S %llvm_src_dir
-DCMAKE_C_COMPILER=%clang -DCMAKE_CXX_COMPILER=%clang
-DCMAKE_CXX_FLAGS="--driver-mode=g++" -DCMAKE_BUILD_TYPE=Release
boomanaiden154 wrote:
Ah, makes sense. Seems reasonable enough to me!
https://github.com/boomanaiden154 approved this pull request.
LGTM.
Adding this to the default perf training I think makes quite a bit of sense
given the numbers reported. Not sure what thoughts others have on that though.
https://github.com/llvm/llvm-project/pull/111625
__
@@ -6,13 +6,23 @@
#include
+#if defined(__cplusplus) && (__cplusplus >= 201103L)
+constexpr bool match_m128(__m128 v, float x, float y, float z, float w) {
+ return v[0] == x && v[1] == y && v[2] == z && v[3] == w;
+}
+#define TEST_CONSTEXPR(...) static_assert(__VA_ARGS__)
https://github.com/boomanaiden154 approved this pull request.
This seems reasonable enough modulo refactoring test macros to a common spot if
reasonable.
This is certainly a lot cleaner than throwing all the constant expression tests
at the end of the file.
https://github.com/llvm/llvm-projec
boomanaiden154 wrote:
> Because only part of the doc is generated by dump_format_style.py.
It should still be possible to only include the non-generated parts in the repo
and then modify the script to add all the generated components on afterwards as
a build step? Not sure if I'm missing somet
https://github.com/boomanaiden154 edited
https://github.com/llvm/llvm-project/pull/112578
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
boomanaiden154 wrote:
> True, however for libc++ the benefits are smaller because we run only libc++
> specific job in the BuildKite job. I've never had trouble with figuring out
> what part of a job has caused failures. Either way, like I said I'm fine with
> the patch, it seems like an impro
boomanaiden154 wrote:
> I'd rather not do that. Commenting on the PR should be done very rarely,
> especially for CI failures, since it clutters the PR and Github already has a
> builtin system for presenting CI failures.
I think this is something that needs to be discussed further when we act
https://github.com/boomanaiden154 edited
https://github.com/llvm/llvm-project/pull/113447
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,328 @@
+# Script to parse many JUnit XML result files and send a report to the
buildkite
+# agent as an annotation.
+#
+# To run the unittests:
+# python3 -m unittest discover -p generate_test_report.py
+
+import argparse
+import unittest
+from io import StringIO
+from
@@ -0,0 +1,328 @@
+# Script to parse many JUnit XML result files and send a report to the
buildkite
+# agent as an annotation.
+#
+# To run the unittests:
+# python3 -m unittest discover -p generate_test_report.py
+
+import argparse
+import unittest
+from io import StringIO
+from
https://github.com/boomanaiden154 commented:
Two minor comments. Script otherwise seems reasonable enough to me.
https://github.com/llvm/llvm-project/pull/113447
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
@@ -143,8 +143,17 @@ if (LLVM_ENABLE_SPHINX)
gen_rst_file_from_td(DiagnosticsReference.rst -gen-diag-docs
../include/clang/Basic/Diagnostic.td "${docs_targets}")
gen_rst_file_from_td(ClangCommandLineReference.rst -gen-opt-docs
../include/clang/Driver/ClangOptionDocs.td
@@ -143,8 +143,17 @@ if (LLVM_ENABLE_SPHINX)
gen_rst_file_from_td(DiagnosticsReference.rst -gen-diag-docs
../include/clang/Basic/Diagnostic.td "${docs_targets}")
gen_rst_file_from_td(ClangCommandLineReference.rst -gen-opt-docs
../include/clang/Driver/ClangOptionDocs.td
boomanaiden154 wrote:
> can we have clang-format-style-options rebuilt only when it's outdated, i.e.
> only if at least one of the following has been updated?
We can, but it requires more changes that I'm not sure are worth doing given
that this step takes essentially zero time compared to reg
boomanaiden154 wrote:
> I'm not concerned about how much time it takes to run. I want to add it to
> clangFormat's dependencies if it doesn't run every time I do ninja
> FormatTests.
I've updated the patch so that we only rerun the python script if the
dependencies change. I've added a `.temp
https://github.com/boomanaiden154 approved this pull request.
LGTM, assuming precommit CI passes.
https://github.com/llvm/llvm-project/pull/110384
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
boomanaiden154 wrote:
#113739 should fix this problem by just adding the options as part of the build
and omitting them from the documentation source.
https://github.com/llvm/llvm-project/pull/111513
___
cfe-commits mailing list
cfe-commits@lists.llvm
boomanaiden154 wrote:
> I'd personally like a solution that doesn't remove the
> ClangFormatStyleOptions.rst from the review
Could we just test that the output looks as expected? I think it would be
pretty easy to write a lit test that asserts all of the output is as expected.
That would then
https://github.com/boomanaiden154 created
https://github.com/llvm/llvm-project/pull/118154
This patch adds a lit test to clang format to ensure that the
ClangFormatStyleOptions doc page has been updated appropriately. The test just
runs the automatic update script and diffs the outputs to ensu
boomanaiden154 wrote:
> Whenever I review a pull request that has edited Format.h, I always fetch the
> PR and run the python script to ensure that the generated rst file matches
> the one in git. I don't think there's a way around that.
Thinking about this a bit more, I think we can probably
boomanaiden154 wrote:
> That and to also ensure that the edited Format.h doesn't break the python
> script.
Makes sense. #118154 would cover that too.
> If we are to leave the generated part of the rst file in the repo,
> https://github.com/llvm/llvm-project/pull/111513 would satisfy my
> re
https://github.com/boomanaiden154 ready_for_review
https://github.com/llvm/llvm-project/pull/118154
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/boomanaiden154 closed
https://github.com/llvm/llvm-project/pull/113739
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
boomanaiden154 wrote:
Closing in favor of #111513 / #118154.
https://github.com/llvm/llvm-project/pull/113739
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
boomanaiden154 wrote:
> Hm, or it's not related to the testcase, but it happens every time we build
> now due to
> https://github.com/llvm/llvm-project/commit/6bec1806c9cc90f6e72fc04698f4221c86c5f95e
That's more likely to be due to #111513. That got reverted. If it's still an
issue here, let
https://github.com/boomanaiden154 approved this pull request.
Is the cleanup just running `black`? Would be better committed separately in my
opinion. Either way, LGTM for both the cleanup and the test change.
https://github.com/llvm/llvm-project/pull/119666
https://github.com/boomanaiden154 closed
https://github.com/llvm/llvm-project/pull/118154
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/boomanaiden154 approved this pull request.
Changes to `__cpuidex_conflict.c` LGTM. I will put that on my TODO list.
https://github.com/llvm/llvm-project/pull/121839
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://list
@@ -1818,8 +1819,21 @@ void Preprocessor::ExpandBuiltinMacro(Token &Tok) {
// usual allocation and deallocation functions. Required by libc++
return 201802;
default:
+// We may get here because of aux builtins which may not be
+
https://github.com/boomanaiden154 closed
https://github.com/llvm/llvm-project/pull/130522
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/boomanaiden154 created
https://github.com/llvm/llvm-project/pull/130522
This patch makes the assertion (that is currently in a comment) that validates
that names mangled by clang can be demangled by LLVM actually compile/work.
There were some minor issues that needed to be f
101 - 143 of 143 matches
Mail list logo
