|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| ... |  | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary: cl::HideUnrelatedOptions allows tools to hide all options not part of a specific OptionCategory. This is the common use case for cl::getRegisteredOptions, which should be deprecated in the future because it exposes implementation details of command line parsing.
Reviewers: dexonsmith
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D7109
llvm-svn: 226741 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This workaround was to provide unique call sites to ensure LLVM's inline
debug info handling would properly unique two calls to the same function
on the same line. Instead, this has now been fixed in LLVM (r226736) and
the workaround here can be removed.
Originally committed in r176895, but this isn't a straight revert due to
all the changes since then. I just searched for anything ForcedColumn*
related and removed them.
We could test this - but it didn't strike me as terribly valuable once
we're no longer adding this workaround everything just works as expected
& it's no longer a special case to test for.
llvm-svn: 226738 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This attribute implies indicates that the function musttail calls
another function and returns whatever it returns. The return type of the
thunk is meaningless, as the thunk can dynamically call different
functions with different return types. So long as the callers bitcast
the thunk with the correct type, behavior is well defined.
This attribute was necessary to fix PR20944, where the indirect call
combiner noticed that the thunk returned void and replaced the results
of the indirect call instruction with undef.
Over-the-shoulder reviewed by David Majnemer.
llvm-svn: 226707 | 
| | 
| 
| 
| | llvm-svn: 226698 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Fix isTriviallyCopyableType for arrays. An array of type T is trivially copyable
if T is trivially copyable.
Patch by Agustín Bergé!
llvm-svn: 226696 | 
| | 
| 
| 
| | llvm-svn: 226685 | 
| | 
| 
| 
| | llvm-svn: 226680 | 
| | 
| 
| 
| 
| 
| | Discovered by the awesome test case and ASAN.
llvm-svn: 226678 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The improved completion in call context now works with:
 - Functions.
 - Member functions.
 - Constructors.
 - New expressions.
 - Function call expressions.
 - Template variants of the previous.
There are still rough edges to be fixed:
 - Provide support for optional parameters.         (fix known)
 - Provide support for member initializers.         (fix known)
 - Provide support for variadic template functions. (fix unknown)
 - Others?
llvm-svn: 226670 | 
| | 
| 
| 
| | llvm-svn: 226662 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | We didn't consider any alignment attributes on an EnumDecl when
calculating alignment.
While we are here, ignore alignment specifications on typedef types if
one is used as the underlying type.  Otherwise, weird things happen:
enum Y : int;
Y y;
typedef int __attribute__((aligned(64))) u;
enum Y : u {};
What is the alignment of 'Y'?  It would be more consistent with the
overall design of enums with fixed underlying types to consider the
underlying type's UnqualifiedDesugaredType.
This fixes PR22279.
llvm-svn: 226653 | 
| | 
| 
| 
| 
| 
| | This reverts commit r226626.  err_after_alias is, in fact, reachable.
llvm-svn: 226633 | 
| | 
| 
| 
| 
| 
| 
| | They can be emitted by multiple translation units and thus belong in a
COMDAT group.
llvm-svn: 226630 | 
| | 
| 
| 
| 
| 
| | A guard variable in a COMDAT'd function should also be in a COMDAT.
llvm-svn: 226629 | 
| | 
| 
| 
| | llvm-svn: 226628 | 
| | 
| 
| 
| 
| 
| 
| | Examples this would have catched are now handled by the attribute
verification code.
llvm-svn: 226626 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | be corrected.
This fixes PR22250, which exposed the bug where if there's more than one
TypoExpr in the arguments, once one failed to be corrected none of the
TypoExprs after it would be handled at all thanks to an early return.
llvm-svn: 226624 | 
| | 
| 
| 
| 
| 
| 
| | In a few places we didn't check that Category->getClassInterface() was
not null before using it.
llvm-svn: 226605 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This code adds the -mstack-probe-size command line option and implements the /Gs
compiler switch for clang-cl.
This should fix http://llvm.org/bugs/show_bug.cgi?id=21896
Patch by Andrew H!
Differential Revision: http://reviews.llvm.org/D6685
llvm-svn: 226601 | 
| | 
| 
| 
| 
| 
| 
| | property-dot syntax on 'super' with no super
class. Patch by Jason Haslam.
llvm-svn: 226578 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Before:
  const char *x =
      "hello llvm";
After:
  const char *x = "hello llvm";
This fixes llvm.org/PR22245.
Patch by Bill Meltsner, thank you!
llvm-svn: 226564 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The test was fixed after a discussion with the revision author: the check
pattern was made more flexible as the "%call" part is not what we actually want
to check strictly there.
The original patch description:
===
Introduce SPIR calling conventions.
This implements Section 3.7 from the SPIR 1.2 spec:
    SPIR kernels should use "spir_kernel" calling convention.
    Non-kernel functions use "spir_func" calling convention. All
    other calling conventions are disallowed.
The patch works only for OpenCL source. Any other uses will need
to ensure that kernels are assigned the spir_kernel calling
convention correctly.
===
llvm-svn: 226561 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Here's the fail log from our internal setup:
===
  .../tools/clang/clang -cc1 -internal-isystem .../tools/clang/staging/include -nostdsysteminc .../tools/clang/test/CodeGenOpenCL/spir-calling-conv.cl -triple spir-unknown-unknown -emit-llvm -o -
  FileCheck .../tools/clang/test/CodeGenOpenCL/spir-calling-conv.cl
.../tools/clang/test/CodeGenOpenCL/spir-calling-conv.cl:11:12: error: expected string not found in input
 // CHECK: %call = tail call spir_func i32 @get_dummy_id(i32 0)
           ^
<stdin>:6:52: note: scanning from here
define spir_kernel void @foo(i32 addrspace(1)* %A) #0 {
                                                   ^
<stdin>:7:2: note: possible intended match here
 %1 = tail call spir_func i32 @get_dummy_id(i32 0) #2
 ^
===
Here's a failure on a public CI server:
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/1183/
llvm-svn: 226558 | 
| | 
| 
| 
| | llvm-svn: 226552 | 
| | 
| 
| 
| 
| 
| 
| | This patch allows to use predetermined shared variables in private clauses in
parallel or tasks regions.
llvm-svn: 226549 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This implements Section 3.7 from the SPIR 1.2 spec:
    SPIR kernels should use "spir_kernel" calling convention.
    Non-kernel functions use "spir_func" calling convention. All
    other calling conventions are disallowed.
The patch works only for OpenCL source. Any other uses will need
to ensure that kernels are assigned the spir_kernel calling
convention correctly.
llvm-svn: 226548 | 
| | 
| 
| 
| 
| 
| | `MDNode::getTemporary()` returns a `unique_ptr<>` as of r226504.
llvm-svn: 226505 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Analogous to AVX2, these need to be implemented as macros to properly
propagate the immediate index operand.
Part of <rdar://problem/17688758>
llvm-svn: 226496 | 
| | 
| 
| 
| 
| 
| | with a DW_OP_deref instead.
llvm-svn: 226474 | 
| | 
| 
| 
| | llvm-svn: 226465 | 
| | 
| 
| 
| 
| 
| 
| 
| | Crashing input:
  /\
  / comment
llvm-svn: 226454 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Previously crashing input:
  void f(
  #if A
      );
  #else
  #endif
llvm-svn: 226451 | 
| | 
| 
| 
| 
| 
| | Input "a<," made clang-format crash.
llvm-svn: 226450 | 
| | 
| 
| 
| | llvm-svn: 226449 | 
| | 
| 
| 
| | llvm-svn: 226448 | 
| | 
| 
| 
| | llvm-svn: 226447 | 
| | 
| 
| 
| 
| 
| 
| | This assert would trigger on:
  #d , = }
llvm-svn: 226446 | 
| | 
| 
| 
| 
| 
| 
| | It shouldn't have been removed, the code which replaced it didn't cover
this case.
llvm-svn: 226442 | 
| | 
| 
| 
| | llvm-svn: 226441 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Things that are OK:
  extern int var1 __attribute((alias("v1")));
  static int var2 __attribute((alias("v2")));
Things that are not OK:
  int var3 __attribute((alias("v3")));
  extern int var4 __attribute((alias("v4"))) = 4;
We choose to accpet:
  struct S { static int var5 __attribute((alias("v5"))); };
  This code causes assertion failues in GCC 4.8 and ICC 13.0.1, we have
  no reason to reject it.
This partially fixes PR22217.
llvm-svn: 226436 | 
| | 
| 
| 
| 
| 
| 
| | The copyprivate clause must not be used with the nowait clause in single
directive.
llvm-svn: 226429 | 
| | 
| 
| 
| 
| 
| | Warn on inaccessible direct base
llvm-svn: 226423 | 
| | 
| 
| 
| 
| 
| | buitins.
llvm-svn: 226422 | 
| | 
| 
| 
| 
| 
| | comparison immediate. This requires converting to a macro in the header file.
llvm-svn: 226421 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | If an unscoped enum is used as a nested name specifier and the language dialect
is not C++ 11, issue an extension warning.
This fixes PR16951.
Differential Revision: http://reviews.llvm.org/D6389
llvm-svn: 226413 | 
| | 
| 
| 
| 
| 
| | Code review suggestion by Eric Christopher.
llvm-svn: 226395 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | expression
Just as r225956 did for scalar expressions (CGExprScalar::Visit), do the
same for complex expressions.
llvm-svn: 226390 | 
| | 
| 
| 
| 
| 
| | behavior change.
llvm-svn: 226389 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | expression
Just as r225956 did for scalar expressions (CGExprScalar::Visit), do the
same for aggregate expressions.
llvm-svn: 226388 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | initializers from in class non-static data members are explicitly attributed to the desired line.
The code setting the debug location being removed here was accidentally
leaking a location into the call to the non-static data member's ctor
call. Without it the call had no location and could cause assertion
failures if it was inlined. Now that it has a location (and a correct
one at that) this code should hopefully be no longer needed.
It's possible of course that other parts of the debug info are also
relying on the debug locations being set here to leak to where they're
needed - so we might see the same assertions again & will have to
investigate what the dependence was/is. But the chances are good that
any of those are debug info line table quality bugs we've just not found
yet anyway - so it'll be good to flush them out.
llvm-svn: 226383 |