User Details
- User Since
- Feb 9 2017, 1:53 PM (276 w, 1 d)
- Roles
- Administrator
Yesterday
Thu, May 26
Sorry for the delay, I though this was merged already. LGTM.
I'm curious what is your system configuration where this patch actually allows for detection of devtoolset? I noticed that if clang and gcc are both installed to /usr/, then driver will pick the gcc in /usr/ over the one in /opt/rh/.../
Wed, May 25
This
Mon, May 23
Thu, May 19
Updated documentation in BitCodeFormat.rst.
@tejohnson Are you OK with this change?
Update comments and documentation.
Wed, May 18
Tue, May 17
Add documentation about the change.
This was committed to the release/14.x branch: 2e7e14177186dc417a49dbf88493dabde0572e22
Mon, May 16
Thu, May 12
Wed, May 11
Tue, May 10
Mon, May 9
This looks OK to me.
Thu, Apr 28
@jyknight You commented here that -fembed-bitcode was not intended for LTO, but the llvm documentation says the .llvmbc section is useful for LTO. Do you have any more background on the history of the .llvmbc section and do you think the gold plugin should try to use it for LTO?
This seems like a good compromise +1.
I think for now what I'll do for now is just update D124405 to list libunwind as a required sub-directory for lld stand-alone builds. This will get me unblocked and make it possible to set up the CI.
Apr 27 2022
@lebedev.ri are you still working on this or should someone else commandeer the revision?
Apr 25 2022
Apr 22 2022
Remove debug message.
@aaron.ballman There's some people that can't build in debug mode at all because there machine is not powerful enough. For me, this is enough to disqualify it from being the default, because it's creating a barrier of entry for new users/developers.
The target audience for the default configuration should be people who are new to the project, it could be users or it could be developers. It also could be people with very little experience programming or building from code from source. We want to keep the barrier for entry as low as possible for this group of people. We can have the best documentation or have verbose error messages to help guide them in the right direction, but the best way to communicate to new users about how to build the project is to have a sensible default configuration.
Apr 21 2022
I disagree about erroring out when CMAKE_BUILD_TYPE is undefined. We want to make the build easy for new users, so I think it's important that the default build (cmake with no arguments) just works.
Apr 20 2022
Address review comments.
Apr 18 2022
LGTM.
I will try to be more specific:
@lebedev.ri This commit message is not appropriate. Please change it in before committing to the repo and also update this review with something else.
Apr 14 2022
Ok, so maybe my concerns about testing overhead are not that legitimate. That's just something I've heard mentioned in the past. However, I still think this should be fixed in buildkite. It's seems much more sustainable to just bump the timeout in buildkite rather than having to go through the code and split tests every time they get too long. It sounds like the maintainers have been contacted about this, but haven't responded?
Is there some reason we can't use the c++11 regex library for this?
Apr 13 2022
Apr 12 2022
Hi, I think this change caused the llvm-clang-win-x-aarch64-release builder to fail. I'm seeing the following error in the logs which seems to be related to this change:
Can't we add a timeout exception for this test in buildkite? Splitting the file in two actually increases the runtime, due to the overhead of setting up each test.
Apr 11 2022
This looks good, thank you.
Apr 6 2022
Can you elaborate more on the problem this is solving? Also, what are the user visible changes? Will check-all and check-clang run the same set of tests as before?
Apr 4 2022
Apr 1 2022
@mstorsjo Ok, so is this patch no longer needed?
Why is i686-pc-windows-msvc is correct triple?
Mar 30 2022
LGTM.
Reference correct repository for the workflow definitions.
Mar 29 2022
Mar 28 2022
Mar 25 2022
The reason I used a minimal check string is because if the warning text changes at all, then the test becomes useless (this is the downside of using -NOT). I wonder if there is another way to test this that might be robust? If not, then I think this change is fine.
Mar 24 2022
Mar 23 2022
Mar 22 2022
@XiaodongLoong You may be interested in the toolchain integration test suite which has multi-project tests like this.
Mar 21 2022
Fedora recently banned RUNPATH, so packages built with clang and -fopenmp are rejected by the build system with this change. Can you elaborate more about the intended use case that this change will fix? Is it just meant for when libomp.so is installed outside of /usr/lib64 ?
Mar 18 2022
Mar 17 2022
Would it be easier just to package the cmake directory in a separate tarball?
Mar 15 2022
@xbolva00 I've removed your comment due to inappropriate language and tone. Please find a more constructive way to communicate your point.