OPEN statements can be used to change some, but not all, attributes
of units that have already been opened. The I/O runtime library
wasn't allowing ENCODING= to be changed. Every other Fortran compiler
permits this usage, and it's safe and useful, so allow it.
(Otherwise there's no good way to ensure that the preconnected
unit 6 is in UTF-8 mode.)
Differential Revision: https://reviews.llvm.org/D154379
We intentionally process NAMELIST groups in a scope after having
resolved all of the names in that scope. This means that a name
whose first appearance in a scope is in the NAMELIST group resolves
to a local object, if any, rather than to any host associated object.
The standard is unclear on this point, and there is no clear
precedent in other compilers.
This patch doesn't implement this choice -- that was done long ago --
but just documents the behavior in Extensions.md.
Differential Revision: https://reviews.llvm.org/D154375
The code that folds the intrinsic function HYPOT was neglecting to
warn the programmer about overflow when it occurs.
Differential Revision: https://reviews.llvm.org/D154371
We already have LLDB_DEPRECATED which is used to mark methods as
deprecated with a message and an alternative to use instead. This is
expresses an intent of "We recognize this functionality is useful but
there are some pitfalls with the interface we have exposed."
In other cases, there are no "alternative" methods to use and the code should be
refactored to avoid using a method entirely. For example,
`SBValue::Cast` should be avoided in favor of using the expression
evaluator to perform a cast. There isn't a mechanical solution, the
recommendation is to instead refactor your code.
This commit renames the existing `LLDB_DEPRECATED` to
`LLDB_DEPRECATED_FIXME`, and adds a `LLDB_DEPRECATED` macro to cover the
second scenario.
Differential Revision: https://reviews.llvm.org/D153928
I'm not convinced that it makes sense for the paths to be ConstStrings. We're
going to be putting them into FileSpecs (which are backed by
ConstStrings, for now) but otherwise there's no need to store them as
ConstStrings upfront.
Differential Revision: https://reviews.llvm.org/D153827
Add a document that summarizes Fortran 202X's upcoming
features and their urgency for implementation.
Differential Revision: https://reviews.llvm.org/D153916
Before we ended up not calling the specialized AAType::isImpliedByIR but
the generic IRAttribute::isImpliedByIR in the IRAttribute::initialize
function.
In a follow up we will reuse the logic in MemoryEffectsBase to merge
AAMemoryLocation and AAMemoryBehavior without duplicating all the bit
fiddling code already available in MemoryEffectsBase.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D153305
Instead of just returning a raw `const char *`, I think llvm::StringRef
would make more sense. Most of the time that we use the return value of
`GetProcessPluginName` we're passing it to `CreateProcess` which takes a
StringRef anyway.
Differential Revision: https://reviews.llvm.org/D153825
Actual argument expressions must be evaluated before the invocation
of the sequence of per-element calls of an impure elemental subprogram.
Otherwise, the side effects of the calls may affect the input for
the consequent elements.
The proposed changes are described by Jean in D154174.
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D154263
Update trip count of test in
pr56319-vector-exit-cond-optimization-epilogue-vectorization.ll to
make sure epilogue vectorization will still trigger after D154261,
checking for the original issue.
Move the original test to limit-vf-by-tripcount.ll for testing new
functionality of D154261.
This patch lowers allocatables and pointers named in "private" OpenMP clause.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148570
Index accessing checks are not performed for aliases
of `std::array`, as only `std::array` itself seems to be checked.
This patch aims to extend it for aliases such as:
`using MyArray = std::array<int, 10>;`
Reviewed By: PiotrZSL
Differential Revision: https://reviews.llvm.org/D154297
Victor Zverovich pointed out[1] that printf takes the field width and
precision arguments before the value to be printed whereas std::print
takes the value first (unless positional arguments are used.) Many of
the test cases in use-std-print.cpp were incorrect.
Teach the check to rotate the arguments when required to correct
this. Correct the test cases and add more.
[1] https://github.com/fmtlib/fmt/pull/3515#issuecomment-1615259893
Reviewed By: PiotrZSL
Differential Revision: https://reviews.llvm.org/D154283
This doesn't really use fast comparison or string uniqueness. In fact,
all of the current callers pass an empty string for type_name. The only
reason I don't remove it is because it looks like it is used downstream
for swift.
Differential Revision: https://reviews.llvm.org/D153810
2/3 of the ConstStrings in this class were just to be able to log
something. Putting something in the StringPool just to log it doesn't
make a lot of sense, so let's remove them.
The remaining use is for `RegisterPersistentDecl` which is fine for now.
Differential Revision: https://reviews.llvm.org/D153905
The soon-to-be-published next revision of the ISO Fortran language standard
contains a couple of breaking changes to previous specifications that may cause
existing programs to silently change their behavior.
For the change that introduces automatic reallocation of deferred length
allocatable character scalar variables when they appear as the targets
of internal WRITE statements, as IOMSG=/ERRMSG= variables, as outputs
of INQUIRE specifiers, or as INTENT(OUT) arguments to intrinsic
procedures, this patch adds an optional portability warning.
Differential Revision: https://reviews.llvm.org/D154242
There are existing implementations for `scf.for`, `scf.forall` and `affine.for`. This revision adds an interface method to the `LoopLikeOpInterface`.
* `scf.forall` now implements the `LoopLikeOpInterface`.
* The implementations of `scf.for` and `scf.forall` become interface method implementations. `affine.for` remains as is for the moment. (The implementation of `promoteIfSingleIteration` depepends on helper functions from `MLIRAffineAnalysis`, which cannot be used from `MLIRAffineDialect`, where the interface is currently implemented.)
* More efficient implementations of `promoteIfSingleIteration`. In particular, the `scf.forall` operation now inlines operations instead of cloning them. This also preserves handles when used from the transform dialect.
Differential Revision: https://reviews.llvm.org/D154343
This is a prep patch for D150388. Treating rddsp and wrdsp as copy
instructions was causing test failures as we tried using isCopyInstr()
hook to query target-specific copy instructions for LiveRangeSplitting.
As suggested, removing 'isMoveReg = 1' from wrdsp and rddsp so they
aren't considered simple copy-like instructions for the moment.
Reviewed By: sdardis
Differential Revision: https://reviews.llvm.org/D151181
This also does some cleanups, I am happy to undo them (or send as
separate patches):
- Change the early exit to stop only once we hit an expansion inside the
main file, to make sure we keep following the nested expansions.
- Add more tests to cover all the cases mentioned in the implementation
- Drop the adjustments for prev/next tokens. We do the final checks
based on the expansion locations anyway, so any intermediate mapping
was a no-op.
Differential Revision: https://reviews.llvm.org/D154335
This patch simply adds a cmake install line for omp_lib.h that was
previously missing, to put it alongisde omp_lib.mod so it can be found
by the driver.
In the case of partially mapped structs, libomptarget sometimes adds
padding to device allocations to ensure they are aligned properly.
However, without this patch, it considers that padding to be mapped to
the host, which can cause presence checks (e.g.,
`omp_target_is_present` or a `present` modifier) to misbehave for
unmapped parts of the struct. This patch keeps the padding but treats
it as unmapped. See the new test case for examples.
Reviewed By: grokos, jdoerfert
Differential Revision: https://reviews.llvm.org/D149685
This reverts commit 92a9c30c61da7f973d55cd84fade424159b9cac9.
This has caused a test failure in the 2nd stage of Linaro's
Arm 32 bit buildbots.
LLVM::simplified-template-names.s
7: error: Simplified template DW_AT_name could not be reconstituted:
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
8: original: f3<unsigned char, (unsigned char)'\x00'>
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
9: reconstituted: f3<unsigned char, (unsigned char)'\x7f'>
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I suspect a load/store is slightly off.
If someone encounters issues due to this patch (e.g. they are using
that test format out-of-tree), please reach out on the review and
we'll figure out a way forward.
Differential Revision: https://reviews.llvm.org/D153534
I made sure they all had some expected-error output in them. Many of
these tests would be better implemented as a positive test using SFINAE,
but this is beyond the scope of this patch.
Differential Revision: https://reviews.llvm.org/D153980
Those were found while trying to enable configurations like no-threads
and no-localization with Clang modules enabled.
Differential Revision: https://reviews.llvm.org/D153977
Similar to the existing _mm_load1_pd/_mm_loaddup_pd and broadcast vector loads, these intrinsic should ensure the loads are unaligned and not assume type alignment
Fixes#62325
A very old commit (9422dd64f870dd33) changed the signature of this function in a
number of ways. This patch aims to improve it:
1. Reword the documentation, which still mentions old parameters that no longer
exist, and to elaborate upon the behavior of this function.
2. Remove the unnecessary parameter `op_addr_idx`. This parameter is odd in a
couple of ways: we never use it with a value that is non-zero, and the matching
`Update_DW_OP_addr` function doesn't use a similar parameter. We also document
that this new behavior. If we ever decide to handle multiple "DW_OP_addr", we
can introduce the complexity again.
Differential Revision: https://reviews.llvm.org/D154265
D68678 added a test that ensures an Apple accelerator lookup is done
efficiently. Since these tables are not used for DWARF 5, we should decorate the
test appropriately.
Differential Revision: https://reviews.llvm.org/D154268
Add new --emit-symbol-graph=<DIR> option which generates ExtractAPI symbol
graph information of .c/.m files on regular compilation job and put them in
the provided "DIR" directory.
Reviewed By: dang
Differential Revision: https://reviews.llvm.org/D152356
Identify multidimensional array indices in subcomponents and
convert them from column-major to row-major ordering.
This fixes codegen for fircg.ext_array_coor, fircg.ext_embox and,
possibly, fircg.ext_rebox.
Fixes https://github.com/llvm/llvm-project/issues/62038
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D154214
This fixes github issue #57117: If the "QualifierAlignment"
option of clang-format is set to anything else but "Leave", the
"QualifierAlignmentFixer" pass gets enabled. This pass scales
quadratically with the number of preprocessor branches, i.e.
with the number of elements in TokenAnalyzer::UnwrappedLines.
The reason is that QualifierAlignmentFixer::process() generates
the UnwrappedLines, but then QualifierAlignmentFixer::analyze()
calls LeftRightQualifierAlignmentFixer::process() several times
(once for each qualifier) which again each time generates the
UnwrappedLines.
This commit gets rid of this double loop by registering the
individual LeftRightQualifierAlignmentFixer passes directly in
the top most container of passes (local variable "Passes" in
reformat()).
With this change, the original example in the github issue #57117
now takes only around 3s instead of >300s to format.
Since QualifierAlignmentFixer::analyze() got deleted, we also
no longer have the code with the NonNoOpFixes. This causes
replacements that end up not changing anything to appear in the
list of final replacements. There is a unit test to check that
this does not happen: QualifierFixerTest.NoOpQualifierReplacements.
However, it got broken at some point in time. So this commit
fixes the test. To keep the behavior that no no-op replacements
should appear from the qualifier fixer, the corresponding code
from QualifierAlignmentFixer::analyze() was moved to the top
reformat() function. Thus, is now done for **every** replacement
of every formatting pass. If no-op replacements are a problem
for the qualifier fixer, then it seems to be a good idea to
filter them out always.
See
https://github.com/llvm/llvm-project/issues/57117#issuecomment-1546716934
for some more details.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D153228
In the revision https://reviews.llvm.org/D138990 was enabled select
optimize pass for AArch64.
We were doing some benchmarking on the Neoverse V1 and were
experimenting with select optimize heuristics. We found out that there
are some additional profitable transformations to predictable branches
(with prediction rate > 75% according to Agner Fog's rule of thumb) can
be done by base heuristic from SelectOptimize pass or by
optimizeSelectInst form CodeGenPrepare pass. But they are blocked on the
Neoverse V1, since PredictableSelectIsExpensive feature is not set for
that subtarget.
Note that to achieve this results we also changed predictable branch
threshold from 99% to 75%
Looks like it makes sense to add this feature to all targets where was
enabled select optimize pass in the https://reviews.llvm.org/D138990.
Reviewed By: dmgreen
Differential Revision: https://reviews.llvm.org/D143162
