This reverts commit daa6d7b2.

It breaks valid code like https://reviews.llvm.org/D123909#3461716

WG14 has elected to remove support for K&R C functions in C2x. The
feature was introduced into C89 already deprecated, so after this long
of a deprecation period, the committee has made an empty parameter list
mean the same thing in C as it means in C++: the function accepts no
arguments exactly as if the function were written with (void) as the
parameter list.

This patch implements WG14 N2841 No function declarators without
prototypes (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2841.htm)
and WG14 N2432 Remove support for function definitions with identifier
lists (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2432.pdf).

It also adds The -fno-knr-functions command line option to opt into
this behavior in other language modes.

Differential Revision: https://reviews.llvm.org/D123955

This reverts commit 9f075c3d

.
The broken build has alreasy been fixed in D124012, so reland it now.
Signed-off-by: Jun Zhang <jun@junz.org>

Set LBOUND() constant folding for parentheses expr. as ones

Array bounds should not propagate throught omitted bounds specifications or
temporary variables - fix constant folding in case of Parentheses<T> expression
by explicitly returning array of ones (or scalar in case of DIM=).

Add set of tests for (x) bounds checks (w/ and w/o 'parameter' arrays)

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm.org/D123838

Previously constant folding uses 'dim' without checks which leads to ICE if we
do not have DIM= parameter. And for inputs without DIM= we need to form an
array of rank size with computed bounds instead of single value.

Add additional PackageConstant function to simplify 'if (dim)' handling since we
need to distinguish between scalar initialization in case of DIM= argument and
rank=1 array.

Also add a few more tests with 'parameter' type to verify folding for constant
arrays.

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm.org/D123237

Ensure that the expressions associated with terminators are associated with a
value. Otherwise, we can generate degenerate flow conditions, where both
branches share the same condition.

Differential Revision: https://reviews.llvm.org/D123858

This patch changes the member of `FrameworkCacheEntry` from `const DirectoryEntry *` to `Optional<DirectoryEntryRef>` in order to remove uses of the deprecated `DirectoryEntry::getName()`.

Reviewed By: bnbarham

Differential Revision: https://reviews.llvm.org/D123854

This patch removes use of the deprecated `DirectoryEntry::getName()` from `FrontendAction::BeginSourceFile()`.

Reviewed By: bnbarham

Differential Revision: https://reviews.llvm.org/D123853

This patch removes uses of the deprecated `DirectoryEntry::getName()` from `HeaderSearch::load*()` functions by using `DirectoryEntryRef` instead.

Note that we bail out in one case and use the also deprecated `FileEntry::getLastRef()`. That's to prevent this patch from growing, and is addressed in a follow-up.

Reviewed By: bnbarham

Differential Revision: https://reviews.llvm.org/D123771

We can process the long shuffles (working across several actual
vector registers) in the best way if we take the actual register
represantion into account. We can build more correct representation of
register shuffles, improve number of recognised buildvector sequences.
Also, same function can be used to improve the cost model for the
shuffles. in future patches.

Part of D100486

Differential Revision: https://reviews.llvm.org/D115653

This should address the issue in:
https://lab.llvm.org/buildbot/#/builders/77/builds/16683

We're making a recursive call here and everything in the function
assumes we're looking at scalars. This would be violated if we
looked through a bitcast from vectors.

Reviewed By: spatel

Differential Revision: https://reviews.llvm.org/D124015

Reviewed By: spatel

Differential Revision: https://reviews.llvm.org/D124016

if c is divisible by (1 << ShAmtC), we can fold this pattern:
lshr (mul nuw x, c), ShAmtC -> mul nuw x, (c >> ShAmtC)

https://alive2.llvm.org/ce/z/ox4wAt

Fix https://github.com/llvm/llvm-project/issues/54824

Reviewed By: spatel, lebedev.ri, craig.topper

Differential Revision: https://reviews.llvm.org/D123453

This should address the issue found in:
https://lab.llvm.org/buildbot/#/builders/215/builds/4610

This should address the issues found by:
https://lab.llvm.org/buildbot/#/builders/105/builds/24292

This was last touched 13 years ago in
https://github.com/llvm/llvm-project/commit/7a1095f243e393d40ed9b9cee17fd091a13f2947
and is no longer being maintained.

This should address build failures found in:

https://lab.llvm.org/buildbot/#/builders/217/builds/3610
https://lab.llvm.org/buildbot/#/builders/215/builds/4609
https://lab.llvm.org/buildbot/#/builders/68/builds/31012

This reverts commit be0905a3.
This patch broke build addressed in https://github.com/llvm/llvm-project/issues/54968


Signed-off-by: Jun Zhang <jun@junz.org>

Fixes a crash introduced in D123737 where LastNonComment would be null.

Reviewed By: curdeius

Differential Revision: https://reviews.llvm.org/D124036

POSIX locking and unlocking functions flockfile and funlockfile have
also been added. The locking is not recursive yet. A future patch will
make the underlying lock a recursive lock.

Reviewed By: lntue

Differential Revision: https://reviews.llvm.org/D123986

As a project, Clang has gotten negative public feedback about our lack
of communicating changes to users. There are comments on places like
Hacker News or Reddit where users have (rightfully) been confused as to
what changes happen in a given release, leading to misinformation like
Clang not adding support for C++20 features:
https://news.ycombinator.com/item?id=28761464.

This documents the expectation that changes which impact users should
have release notes, and it's normal for code reviewers to ask an author
to add a release note for a given change.

This addresses: https://github.com/llvm/llvm-project/issues/54965

RFC: https://discourse.llvm.org/t/rfc-update-developer-policy-on-release-notes/61856

Differential Revision: https://reviews.llvm.org/D123957

Rename classes Assemble -> Assembler, Link -> Linker,
for consistency with names other toolchains use.

Reviewed By: lntue

Differential Revision: https://reviews.llvm.org/D123923

C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never previously
declared. The resulting function would be globally declared as
extern int func(); -- a function without a prototype which accepts zero
or more arguments.

C99 removed support for this questionable feature due to severe
security concerns. However, there was no deprecation period; C89 had
the feature, C99 didn't. So Clang (and GCC) both supported the
functionality as an extension in C99 and later modes.

C2x no longer supports that function signature as it now requires all
functions to have a prototype, and given the known security issues with
the feature, continuing to support it as an extension is not tenable.

This patch changes the diagnostic behavior for the
-Wimplicit-function-declaration warning group depending on the language
mode in effect. We continue to warn by default in C89 mode (due to the
feature being dangerous to use). However, because this feature will not
be supported in C2x mode, we've diagnosed it as being invalid for so
long, the security concerns with the feature, and the trivial
workaround for users (declare the function), we now default the
extension warning to an error in C99-C17 mode. This still gives users
an easy workaround if they are extensively using the extension in those
modes (they can disable the warning or use -Wno-error to downgrade the
error), but the new diagnostic makes it more clear that this feature is
not supported and should be avoided. In C2x mode, we no longer allow an
implicit function to be defined and treat the situation the same as any
other lookup failure.

Differential Revision: https://reviews.llvm.org/D122983

This is not expected to have a functional difference as discussed in the
post-commit comments for 8a9c70fc. All of the motivating tests for
the older fold still optimize as expected because other code can infer
the 'nuw'.

This was tracking global state only used by the AsmPrinter, which can
store its own module global state.

Fixes https://github.com/llvm/llvm-project/issues/51423.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D113499

This is x86 specific, and adds statefulness to
MachineModuleInfo. Instead of explicitly tracking this, infer if we
need to declare the symbol based on the reference previously inserted.

This produces a small change in the output due to the move from
AsmPrinter::doFinalization to X86's emitEndOfAsmFile. This will now be
moved relative to other end of file fields, which I'm assuming doesn't
matter (e.g. the __morestack_addr declaration is now after the
.note.GNU-split-stack part)

This also produces another small change in code if the module happened
to define/declare __morestack_addr, but I assume that's invalid and
doesn't really matter.

Fixes https://github.com/llvm/llvm-project/issues/51118.

Reviewed By: Sockke

Differential Revision: https://reviews.llvm.org/D115124

Fixes https://github.com/llvm/llvm-project/issues/50962.

Reviewed By: whisperity, aaron.ballman

Differential Revision: https://reviews.llvm.org/D114292

This is used to emit one field in doFinalization for the module. We
can accumulate this when emitting all individual functions directly in
the AsmPrinter, rather than accumulating additional state in
MachineModuleInfo.

Move the special case behavior predicate into MachineFrameInfo to
share it. This now promotes it to generic behavior. I'm assuming this
is fine because no other target implements adjustForSegmentedStacks,
or has tests using the split-stack attribute.

Differential Revision: https://reviews.llvm.org/D123617

BlockIsSimpleEnoughToThreadThrough() already checks that the phi
(and all other instructions) are not used outside the block, so
this one-use check is not necessary for legality. I also don't
see any reason why it would be necessary for profitability (in
fact, those extra uses will be replaced with constants, which
should be generally profitable).