- User Since
- Nov 20 2018, 10:54 AM (79 w, 6 d)
Fri, May 29
Wed, May 27
+1 for good messages.
Tue, May 26
Hi David, what *is* the runtime behavior of llvm_unreachable in a program compiled with RELEASE?
Mon, May 18
Mon, May 11
Fri, May 8
Wed, May 6
Mon, May 4
Extracting these into a separate library shouldn't be too difficult
Apr 30 2020
This change adds a build dependency on clang.
The original goal was to add [[maybe_unused]]. Thus, this change needs a corresponding update to Compiler.h to add [[maybe_unused]]. I'm ok with you addressing that issue as a separate commit.
Reminder, flang should follow the well-established naming conventions when creating external names for "f77" entities. There's nothing in this proposal that blocks that; this is just an fyi.
Apr 28 2020
type in the commit message: esle the frontend name is hard-coded to "flang", use that to
Apr 27 2020
Apr 25 2020
The recommendation is to use LLVM_ATTRIBUTE_UNUSED directly.
Please preserve the original code in this change for non-windows systems.
Apr 24 2020
Apr 23 2020
Apr 22 2020
I'm asking about the case where "(content().size() >= buf_->getBufferSize())" is false.
Please make sure LLVM_ENABLE_WERROR, LLVM_ENABLE_PEDANTIC, etc work for out-of-tree builds.
Please add a test case to cover "if we have spare memory"
Apr 21 2020
Apr 20 2020
Do you mean whole Flang or this particular case?
Are you able to wrap the original code in such a way that it doesn't fail under VC++?
LLVM_ATTRIBUTE_UNUSED seems like the right path.
If Windows, are we able to make this change conditional on Windows? Are we able to fix the warnings instead?
Please give an example of system where this is a problem.
Apr 17 2020
Yes, @clementval, I understood your comment, and it got me thinking about the structure of the compiler's evaluation of OpenMP semantics. Looking at the code, I believe the assert at line 6517 will trigger if the collapse value is greater than the loop nest. Unfortunately the check for collapse(n) cannot be moved earlier to the structure checker because symbols have not yet been resolved so 'n' cannot be evaluated. I've talked with @ichoyjx about keeping the symbol resolution here but moving the association of attributes to semantics, at which time all of the required information can be available.
Apr 15 2020
This change doesn't preserve the meaning of currentFenv_. I don't know if currentFenv_ (or originalFenv_) are still useful.
In all cases, the compiler must check that the expression used in collapse is positive. Seems like overkill to create a new expr parser to catch a subset of this check.
What is the motivation for this change? Is there a positive change that could be made instead, that would achieve the same goal and preserve the functionality of this code?
Yes, _mm_setcsr seems portable across x86_64 systems. It's fine. Is there an already-existing llvm API that is similar? (I don't know.)