Almost all attributes currently marked `Undocumented` are user-facing
attributes which _ought_ to be documented, but nobody has written it
yet. This change ensures that we at least acknowledge that these
attributes exist in the documentation, even if we have no description
of their semantics.
A new category, `InternalOnly` has been added for those few attributes
which are not user-facing, and should remain omitted from the docs.
For certain cases (such as for the double subtype of AGenType), the
OpenCLBuiltinFileEmitterBase would not emit the extension #if-guard.
Fix that by looking at the extension of the actual type instead of the
argument type (which could be a GenType that does not carry any
extension information).
Instead of assuming there is an HTML file for each diagnostics, consider
the HTML files only when they exist, individually of each other.
After generating the reference data, running
python /scripts/SATest.py build --projects simbody
was resulting in this error:
File "/scripts/CmpRuns.py", line 250, in read_single_file
assert len(d['HTMLDiagnostics_files']) == 1
KeyError: 'HTMLDiagnostics_files'
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D126197
Solve build issues occurring when running `docker build`.
Fix the version of cmake-data to solve the following issue:
The following packages have unmet dependencies:
cmake : Depends: cmake-data (= 3.20.5-0kitware1) but 3.23.1-0kitware1ubuntu18.04.1 is to be installed
Install libjpeg to solve this issue when installing Python
requirements:
The headers or library files could not be found for jpeg,
a required dependency when compiling Pillow from source.
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D126196
For backwards compatiblity, we emit only a warning instead of an error if the
attribute is one of the existing type attributes that we have historically
allowed to "slide" to the `DeclSpec` just as if it had been specified in GNU
syntax. (We will call these "legacy type attributes" below.)
The high-level changes that achieve this are:
- We introduce a new field `Declarator::DeclarationAttrs` (with appropriate
accessors) to store C++11 attributes occurring in the attribute-specifier-seq
at the beginning of a simple-declaration (and other similar declarations).
Previously, these attributes were placed on the `DeclSpec`, which made it
impossible to reconstruct later on whether the attributes had in fact been
placed on the decl-specifier-seq or ahead of the declaration.
- In the parser, we propgate declaration attributes and decl-specifier-seq
attributes separately until we can place them in
`Declarator::DeclarationAttrs` or `DeclSpec::Attrs`, respectively.
- In `ProcessDeclAttributes()`, in addition to processing declarator attributes,
we now also process the attributes from `Declarator::DeclarationAttrs` (except
if they are legacy type attributes).
- In `ConvertDeclSpecToType()`, in addition to processing `DeclSpec` attributes,
we also process any legacy type attributes that occur in
`Declarator::DeclarationAttrs` (and emit a warning).
- We make `ProcessDeclAttribute` emit an error if it sees any non-declaration
attributes in C++11 syntax, except in the following cases:
- If it is being called for attributes on a `DeclSpec` or `DeclaratorChunk`
- If the attribute is a legacy type attribute (in which case we only emit
a warning)
The standard justifies treating attributes at the beginning of a
simple-declaration and attributes after a declarator-id the same. Here are some
relevant parts of the standard:
- The attribute-specifier-seq at the beginning of a simple-declaration
"appertains to each of the entities declared by the declarators of the
init-declarator-list" (https://eel.is/c++draft/dcl.dcl#dcl.pre-3)
- "In the declaration for an entity, attributes appertaining to that entity can
appear at the start of the declaration and after the declarator-id for that
declaration." (https://eel.is/c++draft/dcl.dcl#dcl.pre-note-2)
- "The optional attribute-specifier-seq following a declarator-id appertains to
the entity that is declared."
(https://eel.is/c++draft/dcl.dcl#dcl.meaning.general-1)
The standard contains similar wording to that for a simple-declaration in other
similar types of declarations, for example:
- "The optional attribute-specifier-seq in a parameter-declaration appertains to
the parameter." (https://eel.is/c++draft/dcl.fct#3)
- "The optional attribute-specifier-seq in an exception-declaration appertains
to the parameter of the catch clause" (https://eel.is/c++draft/except.pre#1)
The new behavior is tested both on the newly added type attribute
`annotate_type`, for which we emit errors, and for the legacy type attribute
`address_space` (chosen somewhat randomly from the various legacy type
attributes), for which we emit warnings.
Depends On D111548
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D126061
Building on D126796, this commit adds the infrastructure for being able
to print out descriptions of what each warning does.
Differential Revision: https://reviews.llvm.org/D126832
Copy hmaptool using the paths for CURRENT_TOOLS_DIR, so
everything goes in the right place in case llvm is included
from a top level CMakeLists.txt.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: stephenneuendorffer
Differential Revision: https://reviews.llvm.org/D126308
As discussed on the review, this change breaks the standalone
clang build. When building against an installed LLVM, the
LLVM_TOOLS_BINARY_DIR cmake variable points to the location of
the installed LLVM tools, not to the cmake build directory. This
means that we would end up trying to move hmaptool into something
like /usr/bin as part of the normal build, while this should only
be happening when running an install target.
This reverts commit bf1ab1f0eb.
This patch does the same thing as D125886 did.
- Use `Overloaded` rather than `Mangled`.
- Use `Prototype` or `Desc` rather than `Seq`, it's not just a string
sequence.
Reviewed By: fakepaper56
Differential Revision: https://reviews.llvm.org/D126634
D126308 broke building clang standalone, as LLVM_UTILS_INSTALL_DIR is
not exported.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D126671
Install hmaptool using the LLVM specific variables, so
everything goes in the right place in case llvm is included
from a top level CMakeLists.txt.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: stephenneuendorffer
Differential Revision: https://reviews.llvm.org/D126308
- Use `Overloaded` rather than `Mangled`.
- Use `Prototype` or `Desc` rather than `Seq`, it's not just a string sequence.
- `Prototype` for those PrototypeDescriptor will used to evaluate as argument type.
- `Desc` for those PrototypeDescriptor will used to evaluate as part of function name.
Reviewed By: khchen
Differential Revision: https://reviews.llvm.org/D125886
This patch is preparation for D111617, use class/struct/enum rather than char/StringRef to present internal information as possible, that provide more compact way to store those info and also easier to serialize/deserialize.
And also that improve readability of the code, e.g. "v" vs TypeProfile::Vector.
Reviewed By: khchen
Differential Revision: https://reviews.llvm.org/D124730
We add a new clang library called `clangSupport` for putting those utils which can be used in clang table-gen and other clang component.
We tried to put that into `llvm/Support`, but actually those stuffs only used in clang* and clang-tblgen, so I think that might be better to create `clang/Support`
* clang will used that in https://reviews.llvm.org/D111617.
Reviewed By: khchen, MaskRay, aaron.ballman
Differential Revision: https://reviews.llvm.org/D121984
It turns out all checkers explicitly mention the `Documentation<>`.
It makes sense to demand this, so emit a fatal tablegen error if such
happens.
Reviewed By: martong, Szelethus
Differential Revision: https://reviews.llvm.org/D122244
HLSL has a language feature called Semantics which get attached to
declarations like attributes and are used in a variety of ways.
One example of semantic use is here with the `SV_GroupIndex` semantic
which, when applied to an input for a compute shader is pre-populated
by the driver with a flattened thread index.
Differential Revision: https://reviews.llvm.org/D122699
# Conflicts:
# clang/include/clang/Basic/Attr.td
# clang/include/clang/Basic/AttrDocs.td
Reland Note: We've resolve the circular dependency issue on llvm/lib/Support and
llvm/TableGen.
Differential Revision: https://reviews.llvm.org/D121984
CLANG_TOOLS_DIR holds the the current bin/ directory, maybe with a %(build_mode)
placeholder. It is used to add the just-built binaries to $PATH for lit tests.
In most cases it equals LLVM_TOOLS_DIR, which is used for the same purpose.
But for a standalone build of clang, CLANG_TOOLS_DIR points at the build tree
and LLVM_TOOLS_DIR points at the provided LLVM binaries.
Currently CLANG_TOOLS_DIR is set in clang/test/, clang-tools-extra/test/, and
other things always built with clang. This is a few cryptic lines of CMake in
each place. Meanwhile LLVM_TOOLS_DIR is provided by configure_site_lit_cfg().
This patch moves CLANG_TOOLS_DIR to configure_site_lit_cfg() and renames it:
- there's nothing clang-specific about the value
- it will also replace LLD_TOOLS_DIR, LLDB_TOOLS_DIR etc (not in this patch)
It also defines CURRENT_LIBS_DIR. While I removed the last usage of
CLANG_LIBS_DIR in e4cab4e24d, there are LLD_LIBS_DIR usages etc that
may be live, and I'd like to mechanically update them in a followup patch.
Differential Revision: https://reviews.llvm.org/D121763
1. Rename nomask as unmasked to keep with the terminology in the spec.
2. Merge UnMaskpolicy and Maskedpolicy arguments into one in RVVBuiltin class.
3. Rename HasAutoDef as HasBuiltinAlias.
4. Move header definition code into one class.
Reviewed By: rogfer01
Differential Revision: https://reviews.llvm.org/D120870
Ensure that the TypeExtension of an `ImageType` is also taken into
account when generating `OpenCLBuiltins.inc`.
This aligns the handling of the `write_only image3d_t` type for
`-fdeclare-opencl-builtins` with opencl-c.h with respect to the
`cl_khr_3d_image_writes` extension.
Since the `write_only image3d_t` type is not available when the
extension is disabled, this commit does not add a test to
`SemaOpenCL/fdeclare-opencl-builtins.cl`.
Currently we allow half types in vectors if the scalar Zfh extension
is enabled. This behavior is not inline with the vector spec. For f32
and f64 types, the Zve32f, Zve64f, Zve64d, and V explicitly control
the availablity of floating point types in vectors.
In order to make our compiler compliant, we either need to remove all support
for half in vectors or we need an extension to control it.
Draft spec here https://github.com/riscv/riscv-v-spec/pull/780
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D121345
This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.
Differential Revision: https://reviews.llvm.org/D119918
Our "strings" were actually bytes, which made verbose dumping fail.
Decode them so they actually become strings.
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D118005
It was complaining about too many values to unpack, since our struct
unpack format string specified six members, but we only had five
variables to unpack to. The sixth value is the max value length, but
it's not used in dumping, so we can ignore it.
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D118004
Until now, any types that had TypeExtensions attached to them were not
guarded with those extensions. Extend the OpenCLBuiltinFileEmitter
such that all required extensions are emitted for the types of a
builtin function.
The `clang-tblgen -gen-clang-opencl-builtin-tests` emitter will now
produce e.g.:
#if defined(cl_khr_fp16) && defined(cl_khr_fp64)
half8 test11802_convert_half8_rtp(double8 arg1) {
return convert_half8_rtp(arg1);
}
#endif // TypeExtension
Differential Revision: https://reviews.llvm.org/D120262
The goal is support tail and mask policy in RVV builtins.
We focus on IR part first.
The nomask vector Multiply-Add need a policy operand
because merge value could not be undef.
Reviewed By: monkchiang
Differential Revision: https://reviews.llvm.org/D119727
Until now, overloads with a 64-bit atomic type argument were always
made available with `-fdeclare-opencl-builtins`. Ensure these
overloads are only available when both the `cl_khr_int64_base_atomics`
and `cl_khr_int64_extended_atomics` extensions have been enabled, as
required by the OpenCL specification.
Differential Revision: https://reviews.llvm.org/D119858
To make uses of the deprecated constructor easier to spot, and to
ensure that no new uses are introduced, rename it to
Address::deprecated().
While doing the rename, I've filled in element types in cases
where it was relatively obvious, but we're still left with 135
calls to the deprecated constructor.