This adds the `vgetq_lane` and `vsetq_lane` families, to copy between
a scalar and a specified lane of a vector.
One of the new `vgetq_lane` intrinsics returns a `float16_t`, which
causes a compile error if `%clang_cc1` doesn't get the option
`-fallow-half-arguments-and-returns`. The driver passes that option to
cc1 already, but I've had to edit all the explicit cc1 command lines
in the existing MVE intrinsics tests.
A couple of fixes are included for the code I wrote up front in
MveEmitter to support lane-index immediates (and which nothing has
tested until now): the type was wrong (`uint32_t` instead of `int`)
and the range was off by one.
I've also added a method of bypassing the default promotion to `i32`
that is done by the MveEmitter code generation: it's sensible to
promote short scalars like `i16` to `i32` if they're going to be
passed to custom IR intrinsics representing a machine instruction
operating on GPRs, but not if they're going to be passed to standard
IR operations like `insertelement` which expect the exact type.
Reviewers: ostannard, MarkMurrayARM, dmgreen
Reviewed By: dmgreen
Subscribers: kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70188
This patch is a follow-up for commit 4e2ce228ae
[BPF] Add preserve_access_index attribute for record definition
to restrict attribute for C only. A new test case is added
to check for this restriction.
Additional code polishing is done based on
Aaron Ballman's suggestion in https://reviews.llvm.org/D69759/new/.
Differential Revision: https://reviews.llvm.org/D70257
This is a resubmission for the previous reverted commit
9434360401 with the same subject. This commit fixed the
segfault issue and addressed additional review comments.
This patch introduced a new bpf specific attribute which can
be added to struct or union definition. For example,
struct s { ... } __attribute__((preserve_access_index));
union u { ... } __attribute__((preserve_access_index));
The goal is to simplify user codes for cases
where preserve access index happens for certain struct/union,
so user does not need to use clang __builtin_preserve_access_index
for every members.
The attribute has no effect if -g is not specified.
When the attribute is specified and -g is specified, any member
access defined by that structure or union, including array subscript
access and inner records, will be preserved through
__builtin_preserve_{array,struct,union}_access_index()
IR intrinsics, which will enable relocation generation
in bpf backend.
The following is an example to illustrate the usage:
-bash-4.4$ cat t.c
#define __reloc__ __attribute__((preserve_access_index))
struct s1 {
int c;
} __reloc__;
struct s2 {
union {
struct s1 b[3];
};
} __reloc__;
struct s3 {
struct s2 a;
} __reloc__;
int test(struct s3 *arg) {
return arg->a.b[2].c;
}
-bash-4.4$ clang -target bpf -g -S -O2 t.c
A relocation with access string "0:0:0:0:2:0" will be generated
representing access offset of arg->a.b[2].c.
forward declaration with attribute is also handled properly such
that the attribute is copied and populated in real record definition.
Differential Revision: https://reviews.llvm.org/D69759
Some warnings in -Wtautological-compare subgroups are DefaultIgnore.
Adding this group to -Wmost, which is part of -Wall, will aid in their
discoverability.
Differential Revision: https://reviews.llvm.org/D69292
This patch introduced a new bpf specific attribute which can
be added to struct or union definition. For example,
struct s { ... } __attribute__((preserve_access_index));
union u { ... } __attribute__((preserve_access_index));
The goal is to simplify user codes for cases
where preserve access index happens for certain struct/union,
so user does not need to use clang __builtin_preserve_access_index
for every members.
The attribute has no effect if -g is not specified.
When the attribute is specified and -g is specified, any member
access defined by that structure or union, including array subscript
access and inner records, will be preserved through
__builtin_preserve_{array,struct,union}_access_index()
IR intrinsics, which will enable relocation generation
in bpf backend.
The following is an example to illustrate the usage:
-bash-4.4$ cat t.c
#define __reloc__ __attribute__((preserve_access_index))
struct s1 {
int c;
} __reloc__;
struct s2 {
union {
struct s1 b[3];
};
} __reloc__;
struct s3 {
struct s2 a;
} __reloc__;
int test(struct s3 *arg) {
return arg->a.b[2].c;
}
-bash-4.4$ clang -target bpf -g -S -O2 t.c
A relocation with access string "0:0:0:0:2:0" will be generated
representing access offset of arg->a.b[2].c.
forward declaration with attribute is also handled properly such
that the attribute is copied and populated in real record definition.
Differential Revision: https://reviews.llvm.org/D69759
While here, wordsmith the error a bit. Now clang says:
error: filter expression has non-integral type 'Foo'
Fixes PR43779
Reviewers: amccarth
Differential Revision: https://reviews.llvm.org/D69969
This patch adds two new families of intrinsics, both of which are
memory accesses taking a vector of locations to load from / store to.
The vldrq_gather_base / vstrq_scatter_base intrinsics take a vector of
base addresses, and an immediate offset to be added consistently to
each one. vldrq_gather_offset / vstrq_scatter_offset take a scalar
base address, and a vector of offsets to add to it. The
'shifted_offset' variants also multiply each offset by the element
size type, so that the vector is effectively of array indices.
At the IR level, these operations are represented by a single set of
four IR intrinsics: {gather,scatter} × {base,offset}. The other
details (signed/unsigned, shift, and memory element size as opposed to
vector element size) are all specified by IR intrinsic polymorphism
and immediate operands, because that made the selection job easier
than making a huge family of similarly named intrinsics.
I considered using the standard IR representations such as
llvm.masked.gather, but they're not a good fit. In order to use
llvm.masked.gather to represent a gather_offset load with element size
smaller than a pointer, you'd have to expand the <8 x i16> vector of
offsets into an <8 x i16*> vector of pointers, which would be split up
during legalization, so you'd spend most of your time undoing the mess
it had made. Also, ISel support for llvm.masked.gather would be easy
enough in a trivial way (you can expand it into a gather-base load
with a zero immediate offset), but instruction-selecting lots of
fiddly idioms back into all the _other_ MVE load instructions would be
much more work. So I think dedicated IR intrinsics are the more
sensible approach, at least for the moment.
On the clang tablegen side, I've added two new features to the
Tablegen source accepted by MveEmitter: a 'CopyKind' type node for
defining a type that varies with the parameter type (it lets you ask
for an unsigned integer type of the same width as the parameter), and
an 'unsignedflag' value node for passing an immediate IR operand which
is 0 for a signed integer type or 1 for an unsigned one. That lets me
write each kind of intrinsic just once and get all its subtypes and
immediate arguments generated automatically.
Also I've tweaked the handling of pointer-typed values in the code
generation part of MveEmitter: they're generated as Address rather
than Value (i.e. including an alignment) so that they can be given to
the ordinary IR load and store operations, but I'd omitted the code to
convert them back to Value when they're going to be used as an
argument to an IR intrinsic.
On the MC side, I've enhanced MVEVectorVTInfo so that it can tell you
not only the full assembly-language suffix for a given vector type
(like 's32' or 'u16') but also the numeric-only one used by store
instructions (just '32' or '16').
Reviewers: dmgreen
Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69791
Summary:
This is a follow up on https://reviews.llvm.org/D61634
This patch is simpler and only adds the no_builtin attribute.
Reviewers: tejohnson, courbet, theraven, t.p.northover, jdoerfert
Subscribers: mgrang, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68028
This is a re-submit after it got reverted in https://reviews.llvm.org/rGbd8791610948 since the breakage doesn't seem to come from this patch.
Summary:
This is a follow up on https://reviews.llvm.org/D61634
This patch is simpler and only adds the no_builtin attribute.
Reviewers: tejohnson, courbet, theraven, t.p.northover, jdoerfert
Subscribers: mgrang, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68028
See also: D67515
- For the given call expression we would end up repeatedly
trying to transform the same expression over and over again
- Fix is to keep the old TransformCache when checking for ambiguity
Differential Revision: https://reviews.llvm.org/D69060
This allows you to declare a function with a name of your choice (say
`foo`), but have clang treat it as if it were a builtin function (say
`__builtin_foo`), by writing
static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_foo)))
int foo(args);
I'm intending to use this for the ACLE intrinsics for MVE, which have
to be polymorphic on their argument types and also need to be
implemented by builtins. To avoid having to implement the polymorphism
with several layers of nested _Generic and make error reporting
hideous, I want to make all the user-facing intrinsics correspond
directly to clang builtins, so that after clang resolves
__attribute__((overloadable)) polymorphism it's already holding the
right BuiltinID for the intrinsic it selected.
However, this commit itself just introduces the new attribute, and
doesn't use it for anything.
To avoid unanticipated side effects if this attribute is used to make
aliases to other builtins, there's a restriction mechanism: only
(BuiltinID, alias) pairs that are approved by the function
ArmMveAliasValid() will be permitted. At present, that function
doesn't permit anything, because the Tablegen that will generate its
list of valid pairs isn't yet implemented. So the only test of this
facility is one that checks that an unapproved builtin _can't_ be
aliased.
Reviewers: dmgreen, miyuki, ostannard
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67159
Taking a value and the bitwise-or it with a non-zero constant will always
result in a non-zero value. In a boolean context, this is always true.
if (x | 0x4) {} // always true, intended '&'
This patch creates a new warning group -Wtautological-bitwise-compare for this
warning. It also moves in the existing tautological bitwise comparisons into
this group. A few other changes were needed to the CFGBuilder so that all bool
contexts would be checked. The warnings in -Wtautological-bitwise-compare will
be off by default due to using the CFG.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=42666
Differential Revision: https://reviews.llvm.org/D66046
llvm-svn: 375318
__builtin_assume_aligned takes a size_t which is a 32 bit int on
hexagon. Thus, the constant gets converted to a 32 bit value, resulting
in 0 not being a power of 2. This patch changes the constant being
passed to 2**30 so that it fails, but doesnt exceed 30 bits.
llvm-svn: 374569
The behavior from the original patch has changed, since we're no longer
allowing LLVM to just ignore the alignment. Instead, we're just
assuming the maximum possible alignment.
Differential Revision: https://reviews.llvm.org/D68824
llvm-svn: 374562
The test fails on Windows, with
error: 'warning' diagnostics expected but not seen:
File builtin-assume-aligned.c Line 62: requested alignment
must be 268435456 bytes or smaller; assumption ignored
error: 'warning' diagnostics seen but not expected:
File builtin-assume-aligned.c Line 62: requested alignment
must be 8192 bytes or smaller; assumption ignored
llvm-svn: 374456
Code to handle __builtin_assume_aligned was allowing larger values, but
would convert this to unsigned along the way. This patch removes the
EmitAssumeAligned overloads that take unsigned to do away with this
problem.
Additionally, it adds a warning that values greater than 1 <<29 are
ignored by LLVM.
Differential Revision: https://reviews.llvm.org/D68824
llvm-svn: 374450
I noticed that compiling on Windows with -fno-ms-compatibility had the
side effect of defining __GNUC__, along with __GNUG__, __GXX_RTTI__, and
a number of other macros for GCC compatibility. This is undesirable and
causes Chromium to do things like mix __attribute__ and __declspec,
which doesn't work. We should have a positive language option to enable
GCC compatibility features so that we can experiment with
-fno-ms-compatibility on Windows. This change adds -fgnuc-version= to be
that option.
My issue aside, users have, for a long time, reported that __GNUC__
doesn't match their expectations in one way or another. We have
encouraged users to migrate code away from this macro, but new code
continues to be written assuming a GCC-only environment. There's really
nothing we can do to stop that. By adding this flag, we can allow them
to choose their own adventure with __GNUC__.
This overlaps a bit with the "GNUMode" language option from -std=gnu*.
The gnu language mode tends to enable non-conforming behaviors that we'd
rather not enable by default, but the we want to set things like
__GXX_RTTI__ by default, so I've kept these separate.
Helps address PR42817
Reviewed By: hans, nickdesaulniers, MaskRay
Differential Revision: https://reviews.llvm.org/D68055
llvm-svn: 374449
Summary:
Character buffers are sometimes used to represent a pool of memory that
contains non-character objects, due to them being synonymous with a stream of
bytes on almost all modern architectures. Often, when interacting with hardware
devices, byte buffers are therefore used as an intermediary and so we can end
Character buffers are sometimes used to represent a pool of memory that
contains non-character objects, due to them being synonymous with a stream of
bytes on almost all modern architectures. Often, when interacting with hardware
devices, byte buffers are therefore used as an intermediary and so we can end
up generating lots of false-positives.
Moreover, due to the ability of character pointers to alias non-character
pointers, the strict aliasing violations that would generally be implied by the
calculations caught by the warning (if the calculation itself is in fact
correct) do not apply here, and so although the length calculation may be
wrong, that is the only possible issue.
Reviewers: rsmith, xbolva00, thakis
Reviewed By: xbolva00, thakis
Subscribers: thakis, lebedev.ri, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68526
llvm-svn: 374035
The warnings now in -Wformat-type-confusion don't align with how we interpret
'pedantic' in clang, and don't belong in -pedantic.
Differential revision: https://reviews.llvm.org/D67775
llvm-svn: 373774
Extracted from D63082. GCC has this warning under -Wint-in-bool-context, but as noted in the D63082's review, we should put it under TautologicalConstantCompare.
llvm-svn: 372531
Commit c15aa241f8 ("[CLANG][BPF] change __builtin_preserve_access_index()
signature") changed the builtin function signature to
PointerT __builtin_preserve_access_index(PointerT ptr)
with a pointer type as the argument/return type, where argument and
return types must be the same.
There is really no reason for this constraint. The builtin just
presented a code region so that IR builtins
__builtin_{array, struct, union}_preserve_access_index
can be applied.
This patch removed the pointer type restriction to permit any
argument type as long as it is permitted by the compiler.
Differential Revision: https://reviews.llvm.org/D67883
llvm-svn: 372516
-Wtautological-overlap-compare and self-comparison from -Wtautological-compare
relay on detecting the same operand in different locations. Previously, each
warning had it's own operand checker. Now, both are merged together into
one function that each can call. The function also now looks through member
access and array accesses.
Differential Revision: https://reviews.llvm.org/D66045
llvm-svn: 372453
Allow this warning to detect a larger number of constant values, including
negative numbers, and handle non-int types better.
Differential Revision: https://reviews.llvm.org/D66044
llvm-svn: 372448
The clang intrinsic __builtin_preserve_access_index() currently
has signature:
const void * __builtin_preserve_access_index(const void * ptr)
This may cause compiler warning when:
- parameter type is "volatile void *" or "const volatile void *", or
- the assign-to type of the intrinsic does not have "const" qualifier.
Further, this signature does not allow dereference of the
builtin result pointer as it is a "const void *" type, which
adds extra step for the user to do type casting.
Let us change the signature to:
PointerT __builtin_preserve_access_index(PointerT ptr)
such that the result and argument types are the same.
With this, directly dereferencing the builtin return value
becomes possible.
Differential Revision: https://reviews.llvm.org/D67734
llvm-svn: 372294
Also, add a diagnostic under -Wformat for printing a boolean value as a
character.
rdar://54579473
Differential revision: https://reviews.llvm.org/D66856
llvm-svn: 372247
Also, add a diagnostic group, -Wobjc-signed-char-bool, to control all these
related diagnostics.
rdar://51954400
Differential revision: https://reviews.llvm.org/D67559
llvm-svn: 372183
Summary:
This fixes a bug introduced in D62648, where Clang could infinite loop
if it became stuck on a single TypoCorrection when it was supposed to
be testing ambiguous corrections. Although not a common case, it could
happen if there are multiple possible corrections with the same edit
distance.
The fix is simply to wipe the TypoExpr from the `TransformCache` so that
the call to `TransformTypoExpr` doesn't use the `CachedEntry`.
Reviewers: rsmith
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67515
llvm-svn: 371859
levels:
-- none: no lax vector conversions [new GCC default]
-- integer: only conversions between integer vectors [old GCC default]
-- all: all conversions between same-size vectors [Clang default]
For now, Clang still defaults to "all" mode, but per my proposal on
cfe-dev (2019-04-10) the default will be changed to "integer" as soon as
that doesn't break lots of testcases. (Eventually I'd like to change the
default to "none" to match GCC and general sanity.)
Following GCC's behavior, the driver flag -flax-vector-conversions is
translated to -flax-vector-conversions=integer.
This reinstates r371805, reverted in r371813, with an additional fix for
lldb.
llvm-svn: 371817
levels:
-- none: no lax vector conversions [new GCC default]
-- integer: only conversions between integer vectors [old GCC default]
-- all: all conversions between same-size vectors [Clang default]
For now, Clang still defaults to "all" mode, but per my proposal on
cfe-dev (2019-04-10) the default will be changed to "integer" as soon as
that doesn't break lots of testcases. (Eventually I'd like to change the
default to "none" to match GCC and general sanity.)
Following GCC's behavior, the driver flag -flax-vector-conversions is
translated to -flax-vector-conversions=integer.
llvm-svn: 371805
Summary:
The first NFC change is to replace a getCXXABI().isMicrosoft() check
with getTriple().isWindowsMSVCEnvironment(). This code takes effect in
non-C++ compilations, so it doesn't make sense to check the C++ ABI. In
the MS ABI, enums are always considered to be "complete" because the
underlying type of an unfixed enum will always be 'int'. This behavior
was moved from -fms-compatibility to MS ABI back in r249656.
The second change is functional, and it downgrades an error to a warning
when the MS ABI is used rather than only under -fms-compatibility. The
reasoning is that it's unreasonable for the following code to reject the
following code for all MS ABI targets with -fno-ms-compatibility:
enum Foo { Foo_Val = 0xDEADBEEF };
This is valid code for any other target, but in the MS ABI, Foo_Val just
happens to be negative. With this change, clang emits a
-Wmicrosoft-enum-value warning on this code, but compiles it without
error.
Fixes PR38478
Reviewers: hans, rsmith, STL_MSFT
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67304
llvm-svn: 371581
constant-folding mode regardless of the original evaluation mode.
In order for this to be correct, we need to track whether we're checking
for a potential constant expression or checking for undefined behavior
separately from the evaluation mode enum, since we don't want to clobber
those states when entering constant-folding mode.
llvm-svn: 371557
Current for SAE instructions we only allow _MM_FROUND_CUR_DIRECTION(bit 2) or _MM_FROUND_NO_EXC(bit 3) to be used as the immediate passed to the inrinsics. But these instructions don't perform rounding so _MM_FROUND_CUR_DIRECTION is just sort of a default placeholder when you don't want to suppress exceptions. Using _MM_FROUND_NO_EXC by itself is really bit equivalent to (_MM_FROUND_NO_EXC | _MM_FROUND_TO_NEAREST_INT) since _MM_FROUND_TO_NEAREST_INT is 0. Since we aren't rounding on these instructions we should also accept (_MM_FROUND_CUR_DIRECTION | _MM_FROUND_NO_EXC) as equivalent to (_MM_FROUND_NO_EXC). icc allows this, but gcc does not.
Differential Revision: https://reviews.llvm.org/D67289
llvm-svn: 371430
Previously, -Wsizeof-pointer-div failed to catch:
const int *r;
sizeof(r) / sizeof(int);
Now fixed.
Also introduced -Wsizeof-array-div which catches bugs like:
sizeof(r) / sizeof(short);
(Array element type does not match type of sizeof operand).
llvm-svn: 371222
A number of inline assembly constraints are currently supported by LLVM, but rejected as invalid by Clang:
Target independent constraints:
s: An integer constant, but allowing only relocatable values
ARM specific constraints:
j: An immediate integer between 0 and 65535 (valid for MOVW)
x: A 32, 64, or 128-bit floating-point/SIMD register: s0-s15, d0-d7, or q0-q3
N: An immediate integer between 0 and 31 (Thumb1 only)
O: An immediate integer which is a multiple of 4 between -508 and 508. (Thumb1 only)
This patch adds support to Clang for the missing constraints along with some checks to ensure that the constraints are used with the correct target and Thumb mode, and that immediates are within valid ranges (at least where possible). The constraints are already implemented in LLVM, but just a couple of minor corrections to checks (V8M Baseline includes MOVW so should work with 'j', 'N' and 'O' shouldn't be valid in Thumb2) so that Clang and LLVM are in line with each other and the documentation.
Differential Revision: https://reviews.llvm.org/D65863
Change-Id: I18076619e319bac35fbb60f590c069145c9d9a0a
llvm-svn: 371079
Summary:
The assertion happens when compiling with -Wdocumentation with variable declaration to a typedefed function pointer. I not too familiar with the ObjC syntax but first two tests assert without this patch.
Fixes https://bugs.llvm.org/show_bug.cgi?id=42844
Reviewers: gribozavr
Reviewed By: gribozavr
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66706
llvm-svn: 370677
initializers.
This has some interesting interactions with our existing extensions to
support C99 designated initializers as an extension in C++. Those are
resolved as follows:
* We continue to permit the full breadth of C99 designated initializers
in C++, with the exception that we disallow a partial overwrite of an
initializer with a non-trivially-destructible type. (Full overwrite
is OK, because we won't run the first initializer at all.)
* The C99 extensions are disallowed in SFINAE contexts and during
overload resolution, where they could change the meaning of valid
programs.
* C++20 disallows reordering of initializers. We only check for that for
the simple cases that the C++20 rules permit (designators of the form
'.field_name =' and continue to allow reordering in other cases).
It would be nice to improve this behavior in future.
* All C99 designated initializer extensions produce a warning by
default in C++20 mode. People are going to learn the C++ rules based
on what Clang diagnoses, so it's important we diagnose these properly
by default.
* In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and
so still diagnose C99 extensions as described above. We continue to
accept designated C++20-compatible initializers in C++ <= 17 silently
by default (but naturally still reject under -pedantic-errors).
This is not a complete implementation of P0329R4. In particular, that
paper introduces new non-C99-compatible syntax { .field { init } }, and
we do not support that yet.
This is based on a previous patch by Don Hinton, though I've made
substantial changes when addressing the above interactions.
Differential Revision: https://reviews.llvm.org/D59754
llvm-svn: 370544
list, rather than recursively checking multiple lists in C.
This simplification is in preparation for making InitListChecker
maintain more state that's specific to the explicit initializer list,
particularly when handling designated initialization.
llvm-svn: 370418
We're building the CFG from bottom to top, so when the return-value expression
has a non-trivial CFG on its own, we need to continue building from the entry
to the return-value expression CFG rather than from the block to which
we've just appended the return statement.
Fixes a false positive warning "control may reach end of non-void function".
llvm-svn: 370406
Based on @davezarzycki remarks in D64696 improved the wording of the warning
message.
Differential Revision: https://reviews.llvm.org/D66700
Patch by Mark de Wever.
llvm-svn: 369873
Summary:
As Typo Resolution can create new TypoExprs while resolving typos,
it is necessary to recurse through the expression to search for more
typos.
This should fix the assertion failure in `clang::Sema::~Sema()`:
`DelayedTypos.empty() && "Uncorrected typos!"`
Notes:
- In case some TypoExprs are created but thrown away, Sema
now has a Vector that is used to keep track of newly created
typos.
- For expressions with multiple typos, we only give suggestions
if we are able to resolve all typos in the expression
- This patch is similar to D37521 except that it does not eagerly
commit to a correction for the first typo in the expression.
Instead, it will search for corrections which fix all of the
typos in the expression.
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62648
llvm-svn: 369427
...so that at least a preceding \param etc. that lacks a description gets a
-Wdocumentation warning (instead of erroneously treating the \retval ... text as
its paragraph).
Differential Revision: https://reviews.llvm.org/D66350
llvm-svn: 369345
This gives library implementers a way to use standards-based attributes that do not conflict with user-defined macros of the same name. Attributes in C2x require this behavior normatively (C2x 6.7.11p4), but there's no reason to not have the same behavior in C++, especially given that such attributes may be used by a C library consumed by a C++ compilation.
llvm-svn: 369033
Momchil Velikov