[clang] [llvm] [AMDGPU][WIP] Extend readlane, writelane and readfirstlane intrinsic lowering for generic types (PR #89217)

[Diana Picus via cfe-commits]

@@ -342,6 +342,22 @@ def AMDGPUfdot2_impl : SDNode<"AMDGPUISD::FDOT2",
 
 def AMDGPUperm_impl : SDNode<"AMDGPUISD::PERM", AMDGPUDTIntTernaryOp, []>;
 
+def AMDGPUReadfirstlaneOp : SDTypeProfile<1, 1, [
+  SDTCisSameAs<0, 1>
+]>;
+
+def AMDGPUReadlaneOp : SDTypeProfile<1, 2, [
+  SDTCisSameAs<0, 1>, SDTCisInt<2>
+]>;
+
+def AMDGPUDWritelaneOp : SDTypeProfile<1, 3, [
+  SDTCisSameAs<1, 1>, SDTCisInt<2>, SDTCisSameAs<0, 3>,

rovka wrote:

<0,1>

https://github.com/llvm/llvm-project/pull/89217
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 26041e1 - Update link job for flang on windows

[Diana Picus via cfe-commits]

Author: Diana Picus
Date: 2022-06-20T07:25:10Z
New Revision: 26041e17006cf30e9c2d06706fe6bd3fa818e356

URL: 
https://github.com/llvm/llvm-project/commit/26041e17006cf30e9c2d06706fe6bd3fa818e356
DIFF: 
https://github.com/llvm/llvm-project/commit/26041e17006cf30e9c2d06706fe6bd3fa818e356.diff

LOG: Update link job for flang on windows

When linking a Fortran program, we need to add the runtime libraries to
the command line. This is exactly what we do for Linux/Darwin, but the
MSVC interface is slightly different (e.g. -libpath instead of -L).

We also remove oldnames and libcmt, since they're not needed at the
moment and they bring in more dependencies.

We also pass `/subsystem:console` to the linker so it can figure out the
right entry point. This is only needed for MSVC's `link.exe`. For LLD it
is redundant but doesn't hurt.

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

Co-authored-by: Markus Mützel 

Added: 


Modified: 
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/lib/Driver/ToolChains/CommonArgs.h
clang/lib/Driver/ToolChains/Darwin.cpp
clang/lib/Driver/ToolChains/Gnu.cpp
clang/lib/Driver/ToolChains/MSVC.cpp
clang/lib/Driver/ToolChains/MinGW.cpp
flang/test/Driver/linker-flags.f90

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index e2437e5787fd7..d297b808b567f 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -739,15 +739,28 @@ bool tools::addOpenMPRuntime(ArgStringList , 
const ToolChain ,
   return true;
 }
 
-void tools::addFortranRuntimeLibs(llvm::opt::ArgStringList ) {
-  CmdArgs.push_back("-lFortran_main");
-  CmdArgs.push_back("-lFortranRuntime");
-  CmdArgs.push_back("-lFortranDecimal");
+void tools::addFortranRuntimeLibs(const ToolChain ,
+  llvm::opt::ArgStringList ) {
+  if (TC.getTriple().isKnownWindowsMSVCEnvironment()) {
+CmdArgs.push_back("Fortran_main.lib");
+CmdArgs.push_back("FortranRuntime.lib");
+CmdArgs.push_back("FortranDecimal.lib");
+  } else {
+CmdArgs.push_back("-lFortran_main");
+CmdArgs.push_back("-lFortranRuntime");
+CmdArgs.push_back("-lFortranDecimal");
+  }
 }
 
 void tools::addFortranRuntimeLibraryPath(const ToolChain ,
  const llvm::opt::ArgList ,
  ArgStringList ) {
+  // NOTE: Generating executables by Flang is considered an "experimental"
+  // feature and hence this is guarded with a command line option.
+  // TODO: Make this work unconditionally once Flang is mature enough.
+  if (!Args.hasArg(options::OPT_flang_experimental_exec))
+return;
+
   // Default to the /../lib directory. This works fine on the
   // platforms that we have tested so far. We will probably have to re-fine
   // this in the future. In particular, on some platforms, we may need to use
@@ -755,7 +768,10 @@ void tools::addFortranRuntimeLibraryPath(const ToolChain 
,
   SmallString<256> DefaultLibPath =
   llvm::sys::path::parent_path(TC.getDriver().Dir);
   llvm::sys::path::append(DefaultLibPath, "lib");
-  CmdArgs.push_back(Args.MakeArgString("-L" + DefaultLibPath));
+  if (TC.getTriple().isKnownWindowsMSVCEnvironment())
+CmdArgs.push_back(Args.MakeArgString("-libpath:" + DefaultLibPath));
+  else
+CmdArgs.push_back(Args.MakeArgString("-L" + DefaultLibPath));
 }
 
 static void addSanitizerRuntime(const ToolChain , const ArgList ,

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.h 
b/clang/lib/Driver/ToolChains/CommonArgs.h
index 3052cbf1a3c38..8e62af70ff7f7 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.h
+++ b/clang/lib/Driver/ToolChains/CommonArgs.h
@@ -121,7 +121,8 @@ bool addOpenMPRuntime(llvm::opt::ArgStringList , 
const ToolChain ,
   bool IsOffloadingHost = false, bool GompNeedsRT = false);
 
 /// Adds Fortran runtime libraries to \p CmdArgs.
-void addFortranRuntimeLibs(llvm::opt::ArgStringList );
+void addFortranRuntimeLibs(const ToolChain ,
+   llvm::opt::ArgStringList );
 
 /// Adds the path for the Fortran runtime libraries to \p CmdArgs.
 void addFortranRuntimeLibraryPath(const ToolChain ,

diff  --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index 5d98a6497827f..0a8a9c6eb6ff0 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -637,14 +637,9 @@ void darwin::Linker::ConstructJob(Compilation , const 
JobAction ,
 
   // Additional linker set-up and flags for Fortran. This is required in order
   // to generate executables.
-  //
-  // NOTE: Generating executables by Flang is considered an "experimental"
-  // feature and hence this is guarded with a command line option.
-  // TODO: Make this work unconditionally once Flang is mature 

Re: [llvm-dev] Zorg migration to GitHub/monorepo

[Diana Picus via cfe-commits]

Hi Galina,

On Tue, 29 Oct 2019 at 04:42, Galina Kistanova  wrote:
>
> Hello Nemanja,
>
> > a commit to a project that shouldn't trigger builds on a libcxx bot (i.e. 
> > the change was in llvm).
>
> With all due respect, this does not sound right.
> I'm not sure how changes in a code a particular bot builds and tests
> should not trigger builds. In many cases this will lead to false blame
> lists, which is very annoying for developers, and hurt a quality of a
> bot. Could somebody elaborate a valid use case for this, please? If
> this is what Diana meant, of course.

Yes, this is what I meant. In the past, we only triggered builds for
commits to libcxx, libcxxabi and libunwind. E.g.
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux/builds/1048

So I actually thought the bots were building without checking out
llvm. I now realize I was wrong and they did pull and build llvm as
well, so I guess the previous behaviour was buggy. Thanks for helping
us clarify this issue!

Cheers,
Diana

> > I have a somewhat orthogonal but related question. In the past, commits to 
> > compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has this 
> > behaviour been rectified with the move to github?
>
> Before the move we had a set of schedulers with manually specified
> list of projects to listen and assigned per group of bots. This was an
> error prone as people were adding bots without realizing that a group
> they add a bot to does not listen for a changes in some of the
> projects that particular bot depends on. You have mentioned an example
> of such issues.
>
> Now we use the dependency list for each of the monorepo-ready build
> factory (depends_on_projects param) to figure out what changes should
> trigger a build, as well as to configure the "-DLLVM_ENABLE_PROJECTS="
> cmake arg. The dependency list could be redefined per builder, if for
> any reason a build factory default doesn't work well. All the
> schedulers are configured automatically and every bot is served with
> changes to any and all projects it claims a dependency on. This should
> give a better and transparent way to define and track what would and
> what would not trigger a build. This is the idea at least. Some work
> remains to be done as not all of the build factories let redefine the
> dependency list yet, not all set "-DLLVM_ENABLE_PROJECTS=" properly,
> and such.
>
> Thanks
>
> Galina
>
> On Mon, Oct 28, 2019 at 5:09 PM Nemanja Ivanovic
>  wrote:
> >
> > I think what she is referring to was that the build seemed to be triggered 
> > by a commit to a project that shouldn't trigger builds on a libcxx bot 
> > (i.e. the change was in llvm).
> >
> > I have a somewhat orthogonal but related question. In the past, commits to 
> > compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has this 
> > behaviour been rectified with the move to github? I am really sorry if you 
> > already answered this question and I just missed it.
> >
> > On Mon, Oct 28, 2019 at 2:37 PM Galina Kistanova via llvm-dev 
> >  wrote:
> >>
> >> Hi Diana,
> >>
> >> It is not clear from your description of what is the problem. Could
> >> you elaborate, please?
> >>
> >> I have looked at the build history closer and see that this build
> >> configuration depends on libcxx, libcxxabi, libunwind, llvm projects,
> >> and changes to any of these would trigger a build. Depending on a bot
> >> performance, patches could be grouped to a longer blame list. To me,
> >> this is exactly how it supposedly should be. Are you missing any
> >> particular changes in libcxx, libcxxabi,or libunwind project which
> >> should trigger a build but they didn't? If so, could you point me to
> >> such change, please?
> >>
> >> Thanks
> >>
> >> Galina
> >>
> >>
> >>
> >> On Mon, Oct 28, 2019 at 5:16 AM Diana Picus  wrote:
> >> >
> >> > Hi Galina,
> >> >
> >> > It seems that our libcxx bots are now triggering builds for any changes 
> >> > to llvm:
> >> > http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434
> >> >
> >> > Should I file a bug report for this?
> >> >
> >> > Thanks,
> >> > Diana
> >> >
> >> > On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits
> >> >  wrote:
> >> > >
> >> > > Hello everyone,
> >> > >
> >> > > The staging master is ready to accept bots from the list I have sent 
> >> > > yesterday. Don't wait too long.
> >> > >
> >> > > The master has been updated and works with both SVN and Github 
> >> > > monorepo now.
> >> > >
> >> > > The following builders are already listening for changes in monorepo 
> >> > > and building monorepo. More are coming.
> >> > >
> >> > > * clang-sphinx-docs
> >> > > * clang-tools-sphinx-docs
> >> > > * clang-x86_64-linux-abi-test
> >> > > * clang-lld-x86_64-2stage
> >> > > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian
> >> > > * libcxx-sphinx-docs
> >> > > * libunwind-sphinx-docs
> >> > > * lld-sphinx-docs
> >> > > * lld-x86_64-darwin13
> >> > > * 

Re: Zorg migration to GitHub/monorepo

[Diana Picus via cfe-commits]

Hi Galina,

It seems that our libcxx bots are now triggering builds for any changes to llvm:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434

Should I file a bug report for this?

Thanks,
Diana

On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits
 wrote:
>
> Hello everyone,
>
> The staging master is ready to accept bots from the list I have sent 
> yesterday. Don't wait too long.
>
> The master has been updated and works with both SVN and Github monorepo now.
>
> The following builders are already listening for changes in monorepo and 
> building monorepo. More are coming.
>
> * clang-sphinx-docs
> * clang-tools-sphinx-docs
> * clang-x86_64-linux-abi-test
> * clang-lld-x86_64-2stage
> * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian
> * libcxx-sphinx-docs
> * libunwind-sphinx-docs
> * lld-sphinx-docs
> * lld-x86_64-darwin13
> * lld-x86_64-ubuntu-fast
> * lldb-sphinx-docs
> * llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
> * llvm-clang-x86_64-win-fast <<-- ?
> * llvm-sphinx-docs
> * clang-x86_64-debian-fast
> * libcxx-libcxxabi-libunwind-x86_64-linux-debian
> * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian
> * libcxx-libcxxabi-x86_64-linux-debian
> * libcxx-libcxxabi-x86_64-linux-debian-noexceptions
>
> A friendly reminder. If your bots are using one of these build factories, you 
> would need either update your build configurations to use one of the 
> currently supported build factories, or port that factory to work with github 
> and monorepo.
>
> * LLVMBuilder (3 bots)
> * PollyBuilder (3 bots)
> * LLDBBuilder (6 bots)
> * SanitizerBuilder (10 bots)
> * CUDATestsuiteBuilder (1 bot) - depends on ClangBuilder.getClangBuildFactory
> * AOSPBuilder (1 bot) - depends on PollyBuilder
> * AnnotatedBuilder (2 bots)
> * OpenMPBuilder (2 bots)
> * FuchsiaBuilder (1 bot)
>
> Thanks
>
> Galina
>
>
> On Fri, Oct 18, 2019 at 12:05 AM Galina Kistanova  
> wrote:
>>
>> Hello build bot owners!
>>
>> The staging master is ready. Please feel free to use it to make sure your 
>> bots would work well with the monorepo and github.
>>
>> The following builders could be configured to build monorepo:
>>
>> * clang-atom-d525-fedora-rel
>> * clang-native-arm-lnt-perf
>> * clang-cmake-armv7-lnt
>> * clang-cmake-armv7-selfhost-neon
>> * clang-cmake-armv7-quick
>> * clang-cmake-armv7-global-isel
>> * clang-cmake-armv7-selfhost
>> * clang-cmake-aarch64-quick
>> * clang-cmake-aarch64-lld
>> * clang-cmake-aarch64-global-isel
>> * clang-ppc64be-linux-lnt
>> * clang-ppc64be-linux-multistage
>> * clang-ppc64le-linux-lnt
>> * clang-ppc64le-linux-multistage
>> * clang-ppc64be-linux
>> * clang-ppc64le-linux
>> * clang-s390x-linux
>> * clang-s390x-linux-multistage
>> * clang-s390x-linux-lnt
>> * clang-hexagon-elf
>> * clang-cmake-x86_64-avx2-linux
>> * clang-cmake-x86_64-avx2-linux-perf
>> * clang-cmake-x86_64-sde-avx512-linux
>> * clang-solaris11-amd64
>> * clang-x64-ninja-win7
>> * clang-solaris11-sparcv9
>> * clang-cmake-armv7-full
>> * clang-cmake-thumbv7-full-sh
>> * clang-cmake-armv8-lld
>> * clang-cmake-aarch64-full
>> * clang-armv7-linux-build-cache
>> * clang-aarch64-linux-build-cache
>> * libcxx-libcxxabi-x86_64-linux-debian
>> * libcxx-libcxxabi-x86_64-linux-debian-noexceptions
>> * libcxx-libcxxabi-libunwind-x86_64-linux-debian
>> * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian
>> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03
>> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11
>> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14
>> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17
>> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a
>> * libcxx-libcxxabi-x86_64-linux-ubuntu-32bit
>> * libcxx-libcxxabi-x86_64-linux-ubuntu-asan
>> * libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan
>> * libcxx-libcxxabi-x86_64-linux-ubuntu-msan
>> * libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu
>> * libcxx-libcxxabi-x86_64-linux-ubuntu-tsan
>> * libcxx-libcxxabi-x86_64-linux-ubuntu-gcc5-cxx11
>> * libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-latest-std
>> * libcxx-libcxxabi-libunwind-armv7-linux
>> * libcxx-libcxxabi-libunwind-armv8-linux
>> * libcxx-libcxxabi-libunwind-armv7-linux-noexceptions
>> * libcxx-libcxxabi-libunwind-armv8-linux-noexceptions
>> * libcxx-libcxxabi-libunwind-aarch64-linux
>> * libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions
>> * ppc64le-lld-multistage-test
>>
>> These builders are already on the staging master. So, please ping me if you 
>> would like to configure any of them to work with monorepo:
>>
>> * clang-freebsd11-amd64
>>
>> These builders have been already tested and could be reconfigured without 
>> staging as soon as public master is ready:
>>
>> * llvm-sphinx-docs
>> * clang-sphinx-docs
>> * clang-tools-sphinx-docs
>> * lld-sphinx-docs
>> * lldb-sphinx-docs
>> * libcxx-sphinx-docs
>> * libunwind-sphinx-docs
>> * clang-x86_64-debian-fast
>> * libcxx-libcxxabi-x86_64-linux-debian
>> * libcxx-libcxxabi-x86_64-linux-debian-noexceptions
>> * 

Re: [PATCH] D53137: Scalable vector core instruction support + size queries

[Diana Picus via cfe-commits]

Hi Graham,

It seems you forgot to push the last round of fixes. Just saying :)

Cheers,
Diana

On Tue, 8 Oct 2019 at 16:01, Graham Hunter via Phabricator
 wrote:
>
> huntergr added a comment.
>
> Hmm, forgot to add the last round of minor fixes before committing. Sorry 
> about that, will push them as well.
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D53137/new/
>
> https://reviews.llvm.org/D53137
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [llvm-dev] Attention bot owners

[Diana Picus via cfe-commits]

Hi Galina,

Thanks for the heads up.

On Fri, 11 Oct 2019 at 21:09, Galina Kistanova via llvm-dev
 wrote:
>
> Hello all bots owners,
>
> As all of you know we move to github monorepo very soon now.
> We are actively working on the buildbot to prepare a solution to switch from 
> SVN to github when time comes.
>
> It would require some activity on your bots.
>
> At this point it is clear that you would need to
>
> * Make sure you have reasonably recent version of git installed and in the 
> system path for the buildbot account,

What qualifies as reasonably recent? Does git 2.7.4 suffice?

Thanks,
Diana

> * Once the transition to github is done, you would need to remove the old 
> source code and build directory. This could be done later assuming you have 
> enough room on that hard drive for two sets of the source and build files.
>
> Thanks
>
> Galina
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r369591 - [LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)

[Diana Picus via cfe-commits]

Hi Matthias,

It seems this is breaking some of our AArch64 bots:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/19691
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-global-isel/builds/12022

You probably didn't notice it because something else also failed in
that build and then the bots just remained red.
I haven't looked into too much detail, but AFAICT this is only
happening with gcc-7 (our other AArch64 bots which run clang-6 seem to
be ok with it). Is this a problem with the compiler or with the code?

Thanks,
Diana

On Thu, 22 Aug 2019 at 00:07, Matthias Gehre via cfe-commits
 wrote:
>
> Author: mgehre
> Date: Wed Aug 21 15:08:59 2019
> New Revision: 369591
>
> URL: http://llvm.org/viewvc/llvm-project?rev=369591=rev
> Log:
> [LifetimeAnalysis] Support more STL idioms (template forward declaration and 
> DependentNameType)
>
> Summary:
> This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ 
> (the typedef for iterator
> on the template is a DependentNameType - we can only put the gsl::Pointer 
> attribute
> on the underlaying record after instantiation)
>
> inference of gsl::Pointer on std::vector::iterator with libc++ (the class was 
> forward-declared,
> we added the gsl::Pointer on the canonical decl (the forward decl), and later 
> when the
> template was instantiated, there was no attribute on the definition so it was 
> not instantiated).
>
> and a duplicate gsl::Pointer on some class with libstdc++ (we first added an 
> attribute to
> a incomplete instantiation, and then another was copied from the template 
> definition
> when the instantiation was completed).
>
> We now add the attributes to all redeclarations to fix thos issues and make 
> their usage easier.
>
> Reviewers: gribozavr
>
> Subscribers: Szelethus, xazax.hun, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D66179
>
> Added:
> cfe/trunk/unittests/Sema/GslOwnerPointerInference.cpp
> Modified:
> cfe/trunk/lib/Sema/SemaAttr.cpp
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/lib/Sema/SemaInit.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
> cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer-std.cpp
> cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer.cpp
> cfe/trunk/unittests/Sema/CMakeLists.txt
>
> Modified: cfe/trunk/lib/Sema/SemaAttr.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaAttr.cpp?rev=369591=369590=369591=diff
> ==
> --- cfe/trunk/lib/Sema/SemaAttr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaAttr.cpp Wed Aug 21 15:08:59 2019
> @@ -88,13 +88,11 @@ void Sema::AddMsStructLayoutForRecord(Re
>  template 
>  static void addGslOwnerPointerAttributeIfNotExisting(ASTContext ,
>   CXXRecordDecl *Record) {
> -  CXXRecordDecl *Canonical = Record->getCanonicalDecl();
> -  if (Canonical->hasAttr() || Canonical->hasAttr())
> +  if (Record->hasAttr() || Record->hasAttr())
>  return;
>
> -  Canonical->addAttr(::new (Context) Attribute(SourceRange{}, Context,
> -   /*DerefType*/ nullptr,
> -   /*Spelling=*/0));
> +  for (Decl *Redecl : Record->redecls())
> +Redecl->addAttr(Attribute::CreateImplicit(Context, 
> /*DerefType=*/nullptr));
>  }
>
>  void Sema::inferGslPointerAttribute(NamedDecl *ND,
> @@ -189,8 +187,7 @@ void Sema::inferGslOwnerPointerAttribute
>
>// Handle classes that directly appear in std namespace.
>if (Record->isInStdNamespace()) {
> -CXXRecordDecl *Canonical = Record->getCanonicalDecl();
> -if (Canonical->hasAttr() || Canonical->hasAttr())
> +if (Record->hasAttr() || Record->hasAttr())
>return;
>
>  if (StdOwners.count(Record->getName()))
>
> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=369591=369590=369591=diff
> ==
> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Wed Aug 21 15:08:59 2019
> @@ -4592,9 +4592,11 @@ static void handleLifetimeCategoryAttr(S
>}
>return;
>  }
> -D->addAttr(::new (S.Context)
> -   OwnerAttr(AL.getRange(), S.Context, DerefTypeLoc,
> - AL.getAttributeSpellingListIndex()));
> +for (Decl *Redecl : D->redecls()) {
> +  Redecl->addAttr(::new (S.Context)
> +  OwnerAttr(AL.getRange(), S.Context, DerefTypeLoc,
> +AL.getAttributeSpellingListIndex()));
> +}
>} else {
>  if (checkAttrMutualExclusion(S, D, AL))
>return;
> @@ -4609,9 +4611,11 @@ static void handleLifetimeCategoryAttr(S
>}
>return;
>  }
> -D->addAttr(::new (S.Context)
> 

Re: [clang-tools-extra] r349496 - [clangd] BackgroundIndex rebuilds symbol index periodically.

[Diana Picus via cfe-commits]

Thanks, Ilya!

On Mon, 7 Jan 2019 at 12:22, Ilya Biryukov  wrote:
>
> Temporarily disabled the test in r350512.
>
> On Mon, Jan 7, 2019 at 10:54 AM Diana Picus  wrote:
>>
>> Hi Eric,
>>
>> This is still failing intermittently on AArch64 in spite of your and
>> Ilya's timeout increases. Could you please revert and rework this
>> test?
>>
>> Thanks,
>> Diana
>>
>> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/5872
>> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/5878
>> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/5879
>>
>> On Tue, 18 Dec 2018 at 16:42, Eric Liu via cfe-commits
>>  wrote:
>> >
>> > Author: ioeric
>> > Date: Tue Dec 18 07:39:33 2018
>> > New Revision: 349496
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=349496=rev
>> > Log:
>> > [clangd] BackgroundIndex rebuilds symbol index periodically.
>> >
>> > Summary:
>> > Currently, background index rebuilds symbol index on every indexed file,
>> > which can be inefficient. This patch makes it only rebuild symbol index 
>> > periodically.
>> > As the rebuild no longer happens too often, we could also build more 
>> > efficient
>> > dex index.
>> >
>> > Reviewers: ilya-biryukov, kadircet
>> >
>> > Reviewed By: kadircet
>> >
>> > Subscribers: dblaikie, MaskRay, jkorous, arphaman, jfb, cfe-commits
>> >
>> > Differential Revision: https://reviews.llvm.org/D55770
>> >
>> > Modified:
>> > clang-tools-extra/trunk/clangd/ClangdServer.cpp
>> > clang-tools-extra/trunk/clangd/ClangdServer.h
>> > clang-tools-extra/trunk/clangd/index/Background.cpp
>> > clang-tools-extra/trunk/clangd/index/Background.h
>> > clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
>> > clang-tools-extra/trunk/test/clangd/background-index.test
>> > clang-tools-extra/trunk/unittests/clangd/BackgroundIndexTests.cpp
>> >
>> > Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
>> > URL: 
>> > http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.cpp?rev=349496=349495=349496=diff
>> > ==
>> > --- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
>> > +++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Tue Dec 18 07:39:33 
>> > 2018
>> > @@ -139,7 +139,8 @@ ClangdServer::ClangdServer(const GlobalC
>> >if (Opts.BackgroundIndex) {
>> >  BackgroundIdx = llvm::make_unique(
>> >  Context::current().clone(), ResourceDir, FSProvider, CDB,
>> > -BackgroundIndexStorage::createDiskBackedStorageFactory());
>> > +BackgroundIndexStorage::createDiskBackedStorageFactory(),
>> > +Opts.BackgroundIndexRebuildPeriodMs);
>> >  AddIndex(BackgroundIdx.get());
>> >}
>> >if (DynamicIdx)
>> >
>> > Modified: clang-tools-extra/trunk/clangd/ClangdServer.h
>> > URL: 
>> > http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.h?rev=349496=349495=349496=diff
>> > ==
>> > --- clang-tools-extra/trunk/clangd/ClangdServer.h (original)
>> > +++ clang-tools-extra/trunk/clangd/ClangdServer.h Tue Dec 18 07:39:33 2018
>> > @@ -85,6 +85,10 @@ public:
>> >  /// If true, ClangdServer automatically indexes files in the current 
>> > project
>> >  /// on background threads. The index is stored in the project root.
>> >  bool BackgroundIndex = false;
>> > +/// If set to non-zero, the background index rebuilds the symbol index
>> > +/// periodically every BuildIndexPeriodMs milliseconds; otherwise, the
>> > +/// symbol index will be updated for each indexed file.
>> > +size_t BackgroundIndexRebuildPeriodMs = 0;
>> >
>> >  /// If set, use this index to augment code completion results.
>> >  SymbolIndex *StaticIndex = nullptr;
>> >
>> > Modified: clang-tools-extra/trunk/clangd/index/Background.cpp
>> > URL: 
>> > http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/Background.cpp?rev=349496=349495=349496=diff
>> > ==
>> > --- clang-tools-extra/trunk/clangd/index/Background.cpp (original)
>> > +++ clang-tools-extra/trunk/clangd/index/Background.cpp Tue Dec 18 
>> > 07:39:33 2018
>> > @@ -27,11 +27,13 @@
>> >  #include "llvm/ADT/StringRef.h"
>> >  #include "llvm/Support/SHA1.h"
>> >
>> > +#include 
>> >  #include 
>> >  #include 
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >
>> >  using namespace llvm;
>> >  namespace clang {
>> > @@ -125,10 +127,13 @@ createFileFilter(const llvm::StringMap> >  BackgroundIndex::BackgroundIndex(
>> >  Context BackgroundContext, StringRef ResourceDir,
>> >  const FileSystemProvider , const GlobalCompilationDatabase 
>> > ,
>> > -BackgroundIndexStorage::Factory IndexStorageFactory, size_t 
>> > ThreadPoolSize)
>> > +BackgroundIndexStorage::Factory IndexStorageFactory,
>> > +size_t 

Re: [clang-tools-extra] r349496 - [clangd] BackgroundIndex rebuilds symbol index periodically.

[Diana Picus via cfe-commits]

Hi Eric,

This is still failing intermittently on AArch64 in spite of your and
Ilya's timeout increases. Could you please revert and rework this
test?

Thanks,
Diana

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/5872
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/5878
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/5879

On Tue, 18 Dec 2018 at 16:42, Eric Liu via cfe-commits
 wrote:
>
> Author: ioeric
> Date: Tue Dec 18 07:39:33 2018
> New Revision: 349496
>
> URL: http://llvm.org/viewvc/llvm-project?rev=349496=rev
> Log:
> [clangd] BackgroundIndex rebuilds symbol index periodically.
>
> Summary:
> Currently, background index rebuilds symbol index on every indexed file,
> which can be inefficient. This patch makes it only rebuild symbol index 
> periodically.
> As the rebuild no longer happens too often, we could also build more efficient
> dex index.
>
> Reviewers: ilya-biryukov, kadircet
>
> Reviewed By: kadircet
>
> Subscribers: dblaikie, MaskRay, jkorous, arphaman, jfb, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D55770
>
> Modified:
> clang-tools-extra/trunk/clangd/ClangdServer.cpp
> clang-tools-extra/trunk/clangd/ClangdServer.h
> clang-tools-extra/trunk/clangd/index/Background.cpp
> clang-tools-extra/trunk/clangd/index/Background.h
> clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
> clang-tools-extra/trunk/test/clangd/background-index.test
> clang-tools-extra/trunk/unittests/clangd/BackgroundIndexTests.cpp
>
> Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.cpp?rev=349496=349495=349496=diff
> ==
> --- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
> +++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Tue Dec 18 07:39:33 2018
> @@ -139,7 +139,8 @@ ClangdServer::ClangdServer(const GlobalC
>if (Opts.BackgroundIndex) {
>  BackgroundIdx = llvm::make_unique(
>  Context::current().clone(), ResourceDir, FSProvider, CDB,
> -BackgroundIndexStorage::createDiskBackedStorageFactory());
> +BackgroundIndexStorage::createDiskBackedStorageFactory(),
> +Opts.BackgroundIndexRebuildPeriodMs);
>  AddIndex(BackgroundIdx.get());
>}
>if (DynamicIdx)
>
> Modified: clang-tools-extra/trunk/clangd/ClangdServer.h
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.h?rev=349496=349495=349496=diff
> ==
> --- clang-tools-extra/trunk/clangd/ClangdServer.h (original)
> +++ clang-tools-extra/trunk/clangd/ClangdServer.h Tue Dec 18 07:39:33 2018
> @@ -85,6 +85,10 @@ public:
>  /// If true, ClangdServer automatically indexes files in the current 
> project
>  /// on background threads. The index is stored in the project root.
>  bool BackgroundIndex = false;
> +/// If set to non-zero, the background index rebuilds the symbol index
> +/// periodically every BuildIndexPeriodMs milliseconds; otherwise, the
> +/// symbol index will be updated for each indexed file.
> +size_t BackgroundIndexRebuildPeriodMs = 0;
>
>  /// If set, use this index to augment code completion results.
>  SymbolIndex *StaticIndex = nullptr;
>
> Modified: clang-tools-extra/trunk/clangd/index/Background.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/Background.cpp?rev=349496=349495=349496=diff
> ==
> --- clang-tools-extra/trunk/clangd/index/Background.cpp (original)
> +++ clang-tools-extra/trunk/clangd/index/Background.cpp Tue Dec 18 07:39:33 
> 2018
> @@ -27,11 +27,13 @@
>  #include "llvm/ADT/StringRef.h"
>  #include "llvm/Support/SHA1.h"
>
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>
>  using namespace llvm;
>  namespace clang {
> @@ -125,10 +127,13 @@ createFileFilter(const llvm::StringMap  BackgroundIndex::BackgroundIndex(
>  Context BackgroundContext, StringRef ResourceDir,
>  const FileSystemProvider , const GlobalCompilationDatabase 
> ,
> -BackgroundIndexStorage::Factory IndexStorageFactory, size_t 
> ThreadPoolSize)
> +BackgroundIndexStorage::Factory IndexStorageFactory,
> +size_t BuildIndexPeriodMs, size_t ThreadPoolSize)
>  : SwapIndex(make_unique()), ResourceDir(ResourceDir),
>FSProvider(FSProvider), CDB(CDB),
>BackgroundContext(std::move(BackgroundContext)),
> +  BuildIndexPeriodMs(BuildIndexPeriodMs),
> +  SymbolsUpdatedSinceLastIndex(false),
>IndexStorageFactory(std::move(IndexStorageFactory)),
>CommandsChanged(
>CDB.watch([&](const std::vector ) {
> @@ -138,6 +143,11 @@ BackgroundIndex::BackgroundIndex(
>

Re: [clang-tools-extra] r312134 - [clang-tidy] Improve hicpp-exception-baseclass to handle generic code better

[Diana Picus via cfe-commits]

On 30 August 2017 at 18:29, Jonas Toth  wrote:
> Hi Diana,
>
> i will investigate this issue. Can i see from somewhere, what email my
> buildbot uses?

I actually don't know if you can check anywhere, but in principle it
should be the same address that the commit email came from (i.e. this
one, that we're using to talk).

> To fix the break I created a new Patch https://reviews.llvm.org/D37301
>
> What is the right thing now, wait for review or just commit it and that
> review would occur on the commit?

Aaron explained this up-thread much more clearly than I would, thanks Aaron! :)

> Thank you for your help and patience.
>
>
> Regard Jonas
>
>
>
> Am 30.08.2017 um 18:25 schrieb Diana Picus:
>>
>> Hi Jonas,
>>
>> Usually the buildbots send emails when you're in the commit range. I'm
>> surprised that you haven't received anything. Are you sure you don't
>> have some mail filters that are catching them and sending them
>> somewhere unexpected?
>>
>> In any case, you can see a live-but-slow buildbot status here:
>> http://lab.llvm.org:8011/console
>> I usually keep an eye on that when I commit something.
>>
>> We also have the #llvm and #llvm-build channels where the buildbots
>> post reports of failed builds and who is in the commit range, so you
>> should see those unless you're specifically ignoring the
>> llvmbb-llvm-build, bb9-chapuni, bb-pgr and green-dragon-bot users.
>>
>> Hope that helps,
>> Diana
>>
>> On 30 August 2017 at 18:16, Jonas Toth  wrote:
>>>
>>> Hello Diana,
>>>
>>> you are right, i did not commit anything earlier, I am really new to the
>>> process, these were my first commits.
>>>
>>> I am sorry that i broke the bots, i thought i would get an automatic
>>> mail,
>>> when they find a problem and i was in the commit range. Is there anything
>>> automated to find out such issues? I feel a little overwhelmed with this
>>> big
>>> amount of builders.
>>>
>>> Sorry again, I will look into it.
>>>
>>> Regard, Jonas
>>>
>>>
>>>
>>> Am 30.08.2017 um 18:12 schrieb Diana Picus:

 Hi Jonas,

 I haven't seen any commit from you (*) fixing the buildbot failures
 caused by your previous commit (r312122). This has been keeping
 several bots red for quite a while:
 http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/10590
 http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/6845
 etc etc

 It's customary to keep an eye on the buildbots and either revert or
 fix such problems as soon as possible. It's particularly inappropriate
 to commit something else on top before dealing with the bot failures.

 For the record, Alex has been trying to help you on IRC in #llvm:
 "alexlorenz: jonas_toth: btw, char is not signed by default (it's
 platform-specific), so you should use 'signed char' in your clang-tidy
 test to fix the bot failures"

 Please be more careful with the buildbots in the future.

 Thanks,
 Diana

 (*) My apologies if I missed it, but I really don't see anything in
 cfe-commits nor in the situation of the bots to reflect that.

 On 30 August 2017 at 17:59, Jonas Toth via cfe-commits
  wrote:
>
> Author: jonastoth
> Date: Wed Aug 30 08:59:01 2017
> New Revision: 312134
>
> URL: http://llvm.org/viewvc/llvm-project?rev=312134=rev
> Log:
> [clang-tidy] Improve hicpp-exception-baseclass to handle generic code
> better
>
> Summary:
> This patch is a followup to the first revision D36583, that had
> problems
> with
> generic code and its diagnostic messages, which were found by
> @lebedev.ri
>
> Reviewers: alexfh, aaron.ballman, lebedev.ri, hokein
>
> Reviewed By: aaron.ballman, lebedev.ri
>
> Subscribers: klimek, sbenza, cfe-commits, JDevlieghere, lebedev.ri,
> xazax.hun
>
> Differential Revision: https://reviews.llvm.org/D37060
>
> Modified:
>
> clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
>
> clang-tools-extra/trunk/test/clang-tidy/hicpp-exception-baseclass.cpp
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
> URL:
>
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp?rev=312134=312133=312134=diff
>
>
> ==
> ---
> clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
> (original)
> +++
> clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
> Wed Aug 30 08:59:01 2017
> @@ -11,8 +11,6 @@
>#include "clang/AST/ASTContext.h"
>#include "clang/ASTMatchers/ASTMatchFinder.h"
>
> -#include 
> -
>using namespace clang::ast_matchers;
>
>namespace 

Re: [clang-tools-extra] r312134 - [clang-tidy] Improve hicpp-exception-baseclass to handle generic code better

[Diana Picus via cfe-commits]

Hi Jonas,

Usually the buildbots send emails when you're in the commit range. I'm
surprised that you haven't received anything. Are you sure you don't
have some mail filters that are catching them and sending them
somewhere unexpected?

In any case, you can see a live-but-slow buildbot status here:
http://lab.llvm.org:8011/console
I usually keep an eye on that when I commit something.

We also have the #llvm and #llvm-build channels where the buildbots
post reports of failed builds and who is in the commit range, so you
should see those unless you're specifically ignoring the
llvmbb-llvm-build, bb9-chapuni, bb-pgr and green-dragon-bot users.

Hope that helps,
Diana

On 30 August 2017 at 18:16, Jonas Toth  wrote:
> Hello Diana,
>
> you are right, i did not commit anything earlier, I am really new to the
> process, these were my first commits.
>
> I am sorry that i broke the bots, i thought i would get an automatic mail,
> when they find a problem and i was in the commit range. Is there anything
> automated to find out such issues? I feel a little overwhelmed with this big
> amount of builders.
>
> Sorry again, I will look into it.
>
> Regard, Jonas
>
>
>
> Am 30.08.2017 um 18:12 schrieb Diana Picus:
>>
>> Hi Jonas,
>>
>> I haven't seen any commit from you (*) fixing the buildbot failures
>> caused by your previous commit (r312122). This has been keeping
>> several bots red for quite a while:
>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/10590
>> http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/6845
>> etc etc
>>
>> It's customary to keep an eye on the buildbots and either revert or
>> fix such problems as soon as possible. It's particularly inappropriate
>> to commit something else on top before dealing with the bot failures.
>>
>> For the record, Alex has been trying to help you on IRC in #llvm:
>> "alexlorenz: jonas_toth: btw, char is not signed by default (it's
>> platform-specific), so you should use 'signed char' in your clang-tidy
>> test to fix the bot failures"
>>
>> Please be more careful with the buildbots in the future.
>>
>> Thanks,
>> Diana
>>
>> (*) My apologies if I missed it, but I really don't see anything in
>> cfe-commits nor in the situation of the bots to reflect that.
>>
>> On 30 August 2017 at 17:59, Jonas Toth via cfe-commits
>>  wrote:
>>>
>>> Author: jonastoth
>>> Date: Wed Aug 30 08:59:01 2017
>>> New Revision: 312134
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=312134=rev
>>> Log:
>>> [clang-tidy] Improve hicpp-exception-baseclass to handle generic code
>>> better
>>>
>>> Summary:
>>> This patch is a followup to the first revision D36583, that had problems
>>> with
>>> generic code and its diagnostic messages, which were found by @lebedev.ri
>>>
>>> Reviewers: alexfh, aaron.ballman, lebedev.ri, hokein
>>>
>>> Reviewed By: aaron.ballman, lebedev.ri
>>>
>>> Subscribers: klimek, sbenza, cfe-commits, JDevlieghere, lebedev.ri,
>>> xazax.hun
>>>
>>> Differential Revision: https://reviews.llvm.org/D37060
>>>
>>> Modified:
>>>  clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
>>>
>>> clang-tools-extra/trunk/test/clang-tidy/hicpp-exception-baseclass.cpp
>>>
>>> Modified:
>>> clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp?rev=312134=312133=312134=diff
>>>
>>> ==
>>> --- clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
>>> (original)
>>> +++ clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
>>> Wed Aug 30 08:59:01 2017
>>> @@ -11,8 +11,6 @@
>>>   #include "clang/AST/ASTContext.h"
>>>   #include "clang/ASTMatchers/ASTMatchFinder.h"
>>>
>>> -#include 
>>> -
>>>   using namespace clang::ast_matchers;
>>>
>>>   namespace clang {
>>> @@ -24,20 +22,23 @@ void ExceptionBaseclassCheck::registerMa
>>>   return;
>>>
>>> Finder->addMatcher(
>>> -  cxxThrowExpr(
>>> -  allOf(
>>> -  has(expr(unless(hasType(cxxRecordDecl(
>>> -  isSameOrDerivedFrom(hasName("std::exception"))),
>>> -  eachOf(has(expr(hasType(namedDecl().bind("decl",
>>> anything(
>>> +
>>> cxxThrowExpr(allOf(has(expr(unless(hasType(qualType(hasCanonicalType(
>>> +
>>> hasDeclaration(cxxRecordDecl(isSameOrDerivedFrom(
>>> + hasName("std::exception")),
>>> +
>>> has(expr(unless(cxxUnresolvedConstructExpr(,
>>> +
>>> eachOf(has(expr(hasType(namedDecl().bind("decl",
>>> +anything(
>>> .bind("bad_throw"),
>>> this);
>>>   }
>>>
>>>   void ExceptionBaseclassCheck::check(const MatchFinder::MatchResult
>>> ) {
>>> const auto *BadThrow =
>>> Result.Nodes.getNodeAs("bad_throw");
>>> -  

Re: [clang-tools-extra] r312134 - [clang-tidy] Improve hicpp-exception-baseclass to handle generic code better

[Diana Picus via cfe-commits]

Hi Jonas,

I haven't seen any commit from you (*) fixing the buildbot failures
caused by your previous commit (r312122). This has been keeping
several bots red for quite a while:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/10590
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/6845
etc etc

It's customary to keep an eye on the buildbots and either revert or
fix such problems as soon as possible. It's particularly inappropriate
to commit something else on top before dealing with the bot failures.

For the record, Alex has been trying to help you on IRC in #llvm:
"alexlorenz: jonas_toth: btw, char is not signed by default (it's
platform-specific), so you should use 'signed char' in your clang-tidy
test to fix the bot failures"

Please be more careful with the buildbots in the future.

Thanks,
Diana

(*) My apologies if I missed it, but I really don't see anything in
cfe-commits nor in the situation of the bots to reflect that.

On 30 August 2017 at 17:59, Jonas Toth via cfe-commits
 wrote:
> Author: jonastoth
> Date: Wed Aug 30 08:59:01 2017
> New Revision: 312134
>
> URL: http://llvm.org/viewvc/llvm-project?rev=312134=rev
> Log:
> [clang-tidy] Improve hicpp-exception-baseclass to handle generic code better
>
> Summary:
> This patch is a followup to the first revision D36583, that had problems with
> generic code and its diagnostic messages, which were found by @lebedev.ri
>
> Reviewers: alexfh, aaron.ballman, lebedev.ri, hokein
>
> Reviewed By: aaron.ballman, lebedev.ri
>
> Subscribers: klimek, sbenza, cfe-commits, JDevlieghere, lebedev.ri, xazax.hun
>
> Differential Revision: https://reviews.llvm.org/D37060
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
> clang-tools-extra/trunk/test/clang-tidy/hicpp-exception-baseclass.cpp
>
> Modified: clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp?rev=312134=312133=312134=diff
> ==
> --- clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp 
> (original)
> +++ clang-tools-extra/trunk/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp Wed 
> Aug 30 08:59:01 2017
> @@ -11,8 +11,6 @@
>  #include "clang/AST/ASTContext.h"
>  #include "clang/ASTMatchers/ASTMatchFinder.h"
>
> -#include 
> -
>  using namespace clang::ast_matchers;
>
>  namespace clang {
> @@ -24,20 +22,23 @@ void ExceptionBaseclassCheck::registerMa
>  return;
>
>Finder->addMatcher(
> -  cxxThrowExpr(
> -  allOf(
> -  has(expr(unless(hasType(cxxRecordDecl(
> -  isSameOrDerivedFrom(hasName("std::exception"))),
> -  eachOf(has(expr(hasType(namedDecl().bind("decl", 
> anything(
> +  cxxThrowExpr(allOf(has(expr(unless(hasType(qualType(hasCanonicalType(
> + 
> hasDeclaration(cxxRecordDecl(isSameOrDerivedFrom(
> + hasName("std::exception")),
> + has(expr(unless(cxxUnresolvedConstructExpr(,
> + eachOf(has(expr(hasType(namedDecl().bind("decl",
> +anything(
>.bind("bad_throw"),
>this);
>  }
>
>  void ExceptionBaseclassCheck::check(const MatchFinder::MatchResult ) {
>const auto *BadThrow = Result.Nodes.getNodeAs("bad_throw");
> -  diag(BadThrow->getLocStart(),
> -   "throwing an exception whose type is not derived from 
> 'std::exception'")
> -  << BadThrow->getSourceRange();
> +
> +  diag(BadThrow->getSubExpr()->getLocStart(), "throwing an exception whose "
> +  "type %0 is not derived from "
> +  "'std::exception'")
> +  << BadThrow->getSubExpr()->getType() << BadThrow->getSourceRange();
>
>const auto *TypeDecl = Result.Nodes.getNodeAs("decl");
>if (TypeDecl != nullptr)
>
> Modified: 
> clang-tools-extra/trunk/test/clang-tidy/hicpp-exception-baseclass.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/hicpp-exception-baseclass.cpp?rev=312134=312133=312134=diff
> ==
> --- clang-tools-extra/trunk/test/clang-tidy/hicpp-exception-baseclass.cpp 
> (original)
> +++ clang-tools-extra/trunk/test/clang-tidy/hicpp-exception-baseclass.cpp Wed 
> Aug 30 08:59:01 2017
> @@ -5,38 +5,175 @@ class exception {};
>  } // namespace std
>
>  class derived_exception : public std::exception {};
> +class deep_hierarchy : public derived_exception {};
>  class non_derived_exception {};
> +class terrible_idea : public non_derived_exception, public derived_exception 
> {};
> +
> +// FIXME: More complicated kinds of inheritance should be checked 

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

Ugh, I'm not sure that last email made it through.

Here's the IR with -Xclang -disable-llvm-passes, at r310400 and r310401:
https://goo.gl/4n84SR
https://goo.gl/gxhxp9

The diff between them is small enough so I don't think there's much
point in reducing it further.
Hope that helps.

On 15 August 2017 at 17:51, Diana Picus <diana.pi...@linaro.org> wrote:
> Actually, I'm not sure I need to reduce it, the diff between the IR
> with -Xclang -no-llvm-passes is pretty small for the version
> with/without the patch. See attached. I hope this helps, it does look
> like a problem with va_arg handling.
>
> Sorry again that this is going so slowly...
>
> On 15 August 2017 at 16:52, Diana Picus <diana.pi...@linaro.org> wrote:
>> On 15 August 2017 at 01:25, Richard Smith <rich...@metafoo.co.uk> wrote:
>>> On 14 August 2017 at 03:27, Diana Picus via cfe-commits
>>> <cfe-commits@lists.llvm.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Strangely enough, it turns out that if I run
>>>> Asan-armhf-with-calls-Noinst-Test on the command line it fails,
>>>> although it doesn't fail when run with lit.
>>>
>>>
>>> Looks like the crash is within the "use_colors == true" portion of
>>> ColoredPrintf, so this would make sense if running the test within lit turns
>>> off color support (perhaps because the output is not a terminal).
>>>
>>
>> That's a good catch, it seems if I run it with --gtest-color=no it
>> still passes, but prints some garbage at the end:
>> [ PASSED ] 97 tests.
>> YOU HAVE -1094542056 DISABLED F]�뀼��_8�pGD2
>>
>>
>>>>
>>>> I've attached the stack
>>>> trace from gdb. It looks like some trouble passing down va_arg
>>>> parameters, but I haven't looked into too much details. The segfault
>>>> happens when we try to do a   ldrb   r3, [r0, r1], with r1 set to 0 by
>>>> the current function and r0 passed down from the caller. I'm not sure
>>>> if this is the exact same problem as the other tests, but feel free to
>>>> have a look at that code.
>>>
>>>
>>> Have you tried running Asan-armhf-with-calls-Noinst-Test on the command line
>>> without this patch applied? (It's possible that this is a pre-existing bug
>>> in ARM varargs call lowering, and is unrelated to the bug we're trying to
>>> track down. This code path performs an unrelated varargs call between a
>>> va_start / va_end pair, which seems like quite a rare situation, and I could
>>> easily believe there's something wrong with our lowering that allows some
>>> portion of the outer va_list state to be clobbered in that scenario.)
>>>
>>
>> It seems to work without the patch. I'm currently trying to reduce
>> Asan-armhf-with-calls-Test and I'll get back to you with the IR or
>> assembly files (whichever makes any difference).
>>
>>>> Meanwhile, I've removed some clutter from Asan-armhf-with-calls-Test
>>>> (which is the original failure that we were seeing) and left only one
>>>> failing test that seemed small enough. I'll try to look at the
>>>> disassembly before/after the patch and maybe even run valgrind on it
>>>> (running it on the original binary naturally takes forever).
>>>>
>>>> Let me know if there's anything else I could try. I can also send you
>>>> disassembly or even LLVM IR for the Asan-armhf-with-calls-Noinst-Test
>>>> if you think it helps.
>>>>
>>>> Cheers,
>>>> Diana
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

On 15 August 2017 at 01:25, Richard Smith <rich...@metafoo.co.uk> wrote:
> On 14 August 2017 at 03:27, Diana Picus via cfe-commits
> <cfe-commits@lists.llvm.org> wrote:
>>
>> Hi,
>>
>> Strangely enough, it turns out that if I run
>> Asan-armhf-with-calls-Noinst-Test on the command line it fails,
>> although it doesn't fail when run with lit.
>
>
> Looks like the crash is within the "use_colors == true" portion of
> ColoredPrintf, so this would make sense if running the test within lit turns
> off color support (perhaps because the output is not a terminal).
>

That's a good catch, it seems if I run it with --gtest-color=no it
still passes, but prints some garbage at the end:
[ PASSED ] 97 tests.
YOU HAVE -1094542056 DISABLED F]�뀼��_8�pGD2


>>
>> I've attached the stack
>> trace from gdb. It looks like some trouble passing down va_arg
>> parameters, but I haven't looked into too much details. The segfault
>> happens when we try to do a   ldrb   r3, [r0, r1], with r1 set to 0 by
>> the current function and r0 passed down from the caller. I'm not sure
>> if this is the exact same problem as the other tests, but feel free to
>> have a look at that code.
>
>
> Have you tried running Asan-armhf-with-calls-Noinst-Test on the command line
> without this patch applied? (It's possible that this is a pre-existing bug
> in ARM varargs call lowering, and is unrelated to the bug we're trying to
> track down. This code path performs an unrelated varargs call between a
> va_start / va_end pair, which seems like quite a rare situation, and I could
> easily believe there's something wrong with our lowering that allows some
> portion of the outer va_list state to be clobbered in that scenario.)
>

It seems to work without the patch. I'm currently trying to reduce
Asan-armhf-with-calls-Test and I'll get back to you with the IR or
assembly files (whichever makes any difference).

>> Meanwhile, I've removed some clutter from Asan-armhf-with-calls-Test
>> (which is the original failure that we were seeing) and left only one
>> failing test that seemed small enough. I'll try to look at the
>> disassembly before/after the patch and maybe even run valgrind on it
>> (running it on the original binary naturally takes forever).
>>
>> Let me know if there's anything else I could try. I can also send you
>> disassembly or even LLVM IR for the Asan-armhf-with-calls-Noinst-Test
>> if you think it helps.
>>
>> Cheers,
>> Diana
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

p as well.
>>>>>>
>>>>>>> Cheers,
>>>>>>> Diana
>>>>>>>
>>>>>>> On 11 August 2017 at 15:34, Diana Picus <diana.pi...@linaro.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Well, these are ASAN tests, I'm not sure how that would interact
>>>>>>>> with
>>>>>>>> Valgrind.
>>>>>>>> Anyway, I'll try to reproduce the environment, I'm guessing it would
>>>>>>>> be best to catch this in gdb so I can actually see what's going on.
>>>>>>>>
>>>>>>>> On 11 August 2017 at 15:21, Vassil Vassilev <v.g.vassi...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> That's really strange. It looks like some random behavior. Did you
>>>>>>>>> run
>>>>>>>>> some memory checker like valgrind?
>>>>>>>>>
>>>>>>>>> Do the environment provided by the test runner and yours match?
>>>>>>>>>
>>>>>>>>> Sent from my phone. Please excuse my brevity.
>>>>>>>>>
>>>>>>>>>> On 11 Aug 2017, at 15:58, Diana Picus <diana.pi...@linaro.org>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi again,
>>>>>>>>>>
>>>>>>>>>> I finally got the debug build, but unfortunately the stack traces
>>>>>>>>>> that
>>>>>>>>>> the tests print look the same. My suspicion is that this is
>>>>>>>>>> because
>>>>>>>>>> the addresses printed by the tests are funny (i.e. odd numbers
>>>>>>>>>> instead
>>>>>>>>>> of divisible by 4). I tried to follow those addresses in an
>>>>>>>>>> objdump
>>>>>>>>>> of
>>>>>>>>>> the executable, but I didn't have much success since most of them
>>>>>>>>>> weren't really pointing to call instructions.
>>>>>>>>>>
>>>>>>>>>> When I try to run the tests manually in the shell or in gdb, they
>>>>>>>>>> pass.
>>>>>>>>>>
>>>>>>>>>> I'm not sure what else to try. Thoughts?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Diana
>>>>>>>>>>
>>>>>>>>>>> On 11 August 2017 at 11:14, Diana Picus <diana.pi...@linaro.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>> Hi guys,
>>>>>>>>>>>
>>>>>>>>>>> I'm SO sorry about the delays. I've been having all sorts of
>>>>>>>>>>> trouble
>>>>>>>>>>> getting that debug build on the board (from ld running out of
>>>>>>>>>>> memory
>>>>>>>>>>> to the board just crashing on me, in which case I need to ask
>>>>>>>>>>> someone
>>>>>>>>>>> else to reboot it because I can't power cycle it remotely). I can
>>>>>>>>>>> assure you this is one of my top priorities, I'll get those stack
>>>>>>>>>>> traces as soon as I can.
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your patience and sorry again,
>>>>>>>>>>> Diana
>>>>>>>>>>>
>>>>>>>>>>>> On 10 August 2017 at 22:55, Richard Smith
>>>>>>>>>>>> <rich...@metafoo.co.uk>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> Any news on this? We want this change in Clang 5, so the sooner
>>>>>>>>>>>> we
>>>>>>>>>>>> can
>>>>>>>>>>>> understand and fix this regression the better...
>>>>>>>>>>>>
>>>>>>>>>>>> On 10 August 2017 at 01:28, Diana Picus via cf

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

gt;>>> disassembly or even LLVM IR for the Asan-armhf-with-calls-Noinst-Test
>>>>>> if you think it helps.
>>>>>
>>>>>disassembly and LLVM will greatly help as well.
>>>>>
>>>>>> Cheers,
>>>>>> Diana
>>>>>>
>>>>>> On 11 August 2017 at 15:34, Diana Picus <diana.pi...@linaro.org> wrote:
>>>>>>>
>>>>>>> Well, these are ASAN tests, I'm not sure how that would interact with
>>>>>>> Valgrind.
>>>>>>> Anyway, I'll try to reproduce the environment, I'm guessing it would
>>>>>>> be best to catch this in gdb so I can actually see what's going on.
>>>>>>>
>>>>>>> On 11 August 2017 at 15:21, Vassil Vassilev <v.g.vassi...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> That's really strange. It looks like some random behavior. Did you
>>>>>>>> run
>>>>>>>> some memory checker like valgrind?
>>>>>>>>
>>>>>>>> Do the environment provided by the test runner and yours match?
>>>>>>>>
>>>>>>>> Sent from my phone. Please excuse my brevity.
>>>>>>>>
>>>>>>>>> On 11 Aug 2017, at 15:58, Diana Picus <diana.pi...@linaro.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi again,
>>>>>>>>>
>>>>>>>>> I finally got the debug build, but unfortunately the stack traces
>>>>>>>>> that
>>>>>>>>> the tests print look the same. My suspicion is that this is because
>>>>>>>>> the addresses printed by the tests are funny (i.e. odd numbers
>>>>>>>>> instead
>>>>>>>>> of divisible by 4). I tried to follow those addresses in an objdump
>>>>>>>>> of
>>>>>>>>> the executable, but I didn't have much success since most of them
>>>>>>>>> weren't really pointing to call instructions.
>>>>>>>>>
>>>>>>>>> When I try to run the tests manually in the shell or in gdb, they
>>>>>>>>> pass.
>>>>>>>>>
>>>>>>>>> I'm not sure what else to try. Thoughts?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Diana
>>>>>>>>>
>>>>>>>>>> On 11 August 2017 at 11:14, Diana Picus <diana.pi...@linaro.org>
>>>>>>>>>> wrote:
>>>>>>>>>> Hi guys,
>>>>>>>>>>
>>>>>>>>>> I'm SO sorry about the delays. I've been having all sorts of
>>>>>>>>>> trouble
>>>>>>>>>> getting that debug build on the board (from ld running out of
>>>>>>>>>> memory
>>>>>>>>>> to the board just crashing on me, in which case I need to ask
>>>>>>>>>> someone
>>>>>>>>>> else to reboot it because I can't power cycle it remotely). I can
>>>>>>>>>> assure you this is one of my top priorities, I'll get those stack
>>>>>>>>>> traces as soon as I can.
>>>>>>>>>>
>>>>>>>>>> Thanks for your patience and sorry again,
>>>>>>>>>> Diana
>>>>>>>>>>
>>>>>>>>>>> On 10 August 2017 at 22:55, Richard Smith <rich...@metafoo.co.uk>
>>>>>>>>>>> wrote:
>>>>>>>>>>> Any news on this? We want this change in Clang 5, so the sooner we
>>>>>>>>>>> can
>>>>>>>>>>> understand and fix this regression the better...
>>>>>>>>>>>
>>>>>>>>>>> On 10 August 2017 at 01:28, Diana Picus via cfe-commits
>>>>>>>>>>> <cfe-commits@lists.llvm.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Vassil,
>>>>>>>>>>>>
>>>>>>>>>&g

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

>>>>>>>> On 11 Aug 2017, at 15:58, Diana Picus <diana.pi...@linaro.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi again,
>>>>>>>>
>>>>>>>> I finally got the debug build, but unfortunately the stack traces
>>>>>>>> that
>>>>>>>> the tests print look the same. My suspicion is that this is because
>>>>>>>> the addresses printed by the tests are funny (i.e. odd numbers
>>>>>>>> instead
>>>>>>>> of divisible by 4). I tried to follow those addresses in an objdump
>>>>>>>> of
>>>>>>>> the executable, but I didn't have much success since most of them
>>>>>>>> weren't really pointing to call instructions.
>>>>>>>>
>>>>>>>> When I try to run the tests manually in the shell or in gdb, they
>>>>>>>> pass.
>>>>>>>>
>>>>>>>> I'm not sure what else to try. Thoughts?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Diana
>>>>>>>>
>>>>>>>>> On 11 August 2017 at 11:14, Diana Picus <diana.pi...@linaro.org>
>>>>>>>>> wrote:
>>>>>>>>> Hi guys,
>>>>>>>>>
>>>>>>>>> I'm SO sorry about the delays. I've been having all sorts of
>>>>>>>>> trouble
>>>>>>>>> getting that debug build on the board (from ld running out of
>>>>>>>>> memory
>>>>>>>>> to the board just crashing on me, in which case I need to ask
>>>>>>>>> someone
>>>>>>>>> else to reboot it because I can't power cycle it remotely). I can
>>>>>>>>> assure you this is one of my top priorities, I'll get those stack
>>>>>>>>> traces as soon as I can.
>>>>>>>>>
>>>>>>>>> Thanks for your patience and sorry again,
>>>>>>>>> Diana
>>>>>>>>>
>>>>>>>>>> On 10 August 2017 at 22:55, Richard Smith <rich...@metafoo.co.uk>
>>>>>>>>>> wrote:
>>>>>>>>>> Any news on this? We want this change in Clang 5, so the sooner we
>>>>>>>>>> can
>>>>>>>>>> understand and fix this regression the better...
>>>>>>>>>>
>>>>>>>>>> On 10 August 2017 at 01:28, Diana Picus via cfe-commits
>>>>>>>>>> <cfe-commits@lists.llvm.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Vassil,
>>>>>>>>>>>
>>>>>>>>>>> My build is in progress, but since it's a full build it's
>>>>>>>>>>> probably
>>>>>>>>>>> going to take another couple of hours to complete. I'll let you
>>>>>>>>>>> know
>>>>>>>>>>> when it's done.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Diana
>>>>>>>>>>>
>>>>>>>>>>> On 10 August 2017 at 10:09, Vassil Vassilev
>>>>>>>>>>> <v.g.vassi...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> It looks like I can not reproduce it on osx (non-arm)... :(
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 09/08/17 22:54, Diana Picus wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Reverting this also fixed the selfhost bots:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/2142
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

Also if you want the disassembly for the whole test executable (with
just that test in it):
https://goo.gl/pjULbN

It's 177MB though.

On 14 August 2017 at 14:04, Diana Picus <diana.pi...@linaro.org> wrote:
> See attached.
>
> On 14 August 2017 at 13:30, Vassil Vassilev <v.g.vassi...@gmail.com> wrote:
>> On 14/08/17 11:27, Diana Picus wrote:
>>>
>>> Hi,
>>>
>>> Strangely enough, it turns out that if I run
>>> Asan-armhf-with-calls-Noinst-Test on the command line it fails,
>>> although it doesn't fail when run with lit. I've attached the stack
>>> trace from gdb. It looks like some trouble passing down va_arg
>>> parameters, but I haven't looked into too much details. The segfault
>>> happens when we try to do a   ldrb   r3, [r0, r1], with r1 set to 0 by
>>> the current function and r0 passed down from the caller. I'm not sure
>>> if this is the exact same problem as the other tests, but feel free to
>>> have a look at that code.
>>>
>>> Meanwhile, I've removed some clutter from Asan-armhf-with-calls-Test
>>> (which is the original failure that we were seeing) and left only one
>>> failing test that seemed small enough. I'll try to look at the
>>> disassembly before/after the patch and maybe even run valgrind on it
>>> (running it on the original binary naturally takes forever).
>>>
>>> Let me know if there's anything else I could try. I can also send you
>>> disassembly or even LLVM IR for the Asan-armhf-with-calls-Noinst-Test
>>> if you think it helps.
>>
>>   disassembly and LLVM will greatly help as well.
>>
>>>
>>> Cheers,
>>> Diana
>>>
>>> On 11 August 2017 at 15:34, Diana Picus <diana.pi...@linaro.org> wrote:
>>>>
>>>> Well, these are ASAN tests, I'm not sure how that would interact with
>>>> Valgrind.
>>>> Anyway, I'll try to reproduce the environment, I'm guessing it would
>>>> be best to catch this in gdb so I can actually see what's going on.
>>>>
>>>> On 11 August 2017 at 15:21, Vassil Vassilev <v.g.vassi...@gmail.com>
>>>> wrote:
>>>>>
>>>>> That's really strange. It looks like some random behavior. Did you run
>>>>> some memory checker like valgrind?
>>>>>
>>>>> Do the environment provided by the test runner and yours match?
>>>>>
>>>>> Sent from my phone. Please excuse my brevity.
>>>>>
>>>>>> On 11 Aug 2017, at 15:58, Diana Picus <diana.pi...@linaro.org> wrote:
>>>>>>
>>>>>> Hi again,
>>>>>>
>>>>>> I finally got the debug build, but unfortunately the stack traces that
>>>>>> the tests print look the same. My suspicion is that this is because
>>>>>> the addresses printed by the tests are funny (i.e. odd numbers instead
>>>>>> of divisible by 4). I tried to follow those addresses in an objdump of
>>>>>> the executable, but I didn't have much success since most of them
>>>>>> weren't really pointing to call instructions.
>>>>>>
>>>>>> When I try to run the tests manually in the shell or in gdb, they pass.
>>>>>>
>>>>>> I'm not sure what else to try. Thoughts?
>>>>>>
>>>>>> Thanks,
>>>>>> Diana
>>>>>>
>>>>>>> On 11 August 2017 at 11:14, Diana Picus <diana.pi...@linaro.org>
>>>>>>> wrote:
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> I'm SO sorry about the delays. I've been having all sorts of trouble
>>>>>>> getting that debug build on the board (from ld running out of memory
>>>>>>> to the board just crashing on me, in which case I need to ask someone
>>>>>>> else to reboot it because I can't power cycle it remotely). I can
>>>>>>> assure you this is one of my top priorities, I'll get those stack
>>>>>>> traces as soon as I can.
>>>>>>>
>>>>>>> Thanks for your patience and sorry again,
>>>>>>> Diana
>>>>>>>
>>>>>>>> On 10 August 2017 at 22:55, Richard Smith <rich...@metafoo.co.uk>
>>>>>>>> wrote:
>>>>>>>> Any news on this? We want this change in Clang 5, so the sooner we
>>&

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

Hi,

Strangely enough, it turns out that if I run
Asan-armhf-with-calls-Noinst-Test on the command line it fails,
although it doesn't fail when run with lit. I've attached the stack
trace from gdb. It looks like some trouble passing down va_arg
parameters, but I haven't looked into too much details. The segfault
happens when we try to do a   ldrb   r3, [r0, r1], with r1 set to 0 by
the current function and r0 passed down from the caller. I'm not sure
if this is the exact same problem as the other tests, but feel free to
have a look at that code.

Meanwhile, I've removed some clutter from Asan-armhf-with-calls-Test
(which is the original failure that we were seeing) and left only one
failing test that seemed small enough. I'll try to look at the
disassembly before/after the patch and maybe even run valgrind on it
(running it on the original binary naturally takes forever).

Let me know if there's anything else I could try. I can also send you
disassembly or even LLVM IR for the Asan-armhf-with-calls-Noinst-Test
if you think it helps.

Cheers,
Diana

On 11 August 2017 at 15:34, Diana Picus <diana.pi...@linaro.org> wrote:
> Well, these are ASAN tests, I'm not sure how that would interact with 
> Valgrind.
> Anyway, I'll try to reproduce the environment, I'm guessing it would
> be best to catch this in gdb so I can actually see what's going on.
>
> On 11 August 2017 at 15:21, Vassil Vassilev <v.g.vassi...@gmail.com> wrote:
>> That's really strange. It looks like some random behavior. Did you run some 
>> memory checker like valgrind?
>>
>> Do the environment provided by the test runner and yours match?
>>
>> Sent from my phone. Please excuse my brevity.
>>
>>> On 11 Aug 2017, at 15:58, Diana Picus <diana.pi...@linaro.org> wrote:
>>>
>>> Hi again,
>>>
>>> I finally got the debug build, but unfortunately the stack traces that
>>> the tests print look the same. My suspicion is that this is because
>>> the addresses printed by the tests are funny (i.e. odd numbers instead
>>> of divisible by 4). I tried to follow those addresses in an objdump of
>>> the executable, but I didn't have much success since most of them
>>> weren't really pointing to call instructions.
>>>
>>> When I try to run the tests manually in the shell or in gdb, they pass.
>>>
>>> I'm not sure what else to try. Thoughts?
>>>
>>> Thanks,
>>> Diana
>>>
>>>> On 11 August 2017 at 11:14, Diana Picus <diana.pi...@linaro.org> wrote:
>>>> Hi guys,
>>>>
>>>> I'm SO sorry about the delays. I've been having all sorts of trouble
>>>> getting that debug build on the board (from ld running out of memory
>>>> to the board just crashing on me, in which case I need to ask someone
>>>> else to reboot it because I can't power cycle it remotely). I can
>>>> assure you this is one of my top priorities, I'll get those stack
>>>> traces as soon as I can.
>>>>
>>>> Thanks for your patience and sorry again,
>>>> Diana
>>>>
>>>>> On 10 August 2017 at 22:55, Richard Smith <rich...@metafoo.co.uk> wrote:
>>>>> Any news on this? We want this change in Clang 5, so the sooner we can
>>>>> understand and fix this regression the better...
>>>>>
>>>>> On 10 August 2017 at 01:28, Diana Picus via cfe-commits
>>>>> <cfe-commits@lists.llvm.org> wrote:
>>>>>>
>>>>>> Hi Vassil,
>>>>>>
>>>>>> My build is in progress, but since it's a full build it's probably
>>>>>> going to take another couple of hours to complete. I'll let you know
>>>>>> when it's done.
>>>>>>
>>>>>> Thanks,
>>>>>> Diana
>>>>>>
>>>>>> On 10 August 2017 at 10:09, Vassil Vassilev <v.g.vassi...@gmail.com>
>>>>>> wrote:
>>>>>>> It looks like I can not reproduce it on osx (non-arm)... :(
>>>>>>>> On 09/08/17 22:54, Diana Picus wrote:
>>>>>>>>
>>>>>>>> Reverting this also fixed the selfhost bots:
>>>>>>>>
>>>>>>>>
>>>>>>>> http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/2142
>>>>>>>>
>>>>>>>>
>>>>>>>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/2309
>>>>>>>>
>>>>>>>>
>>&g

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

Well, these are ASAN tests, I'm not sure how that would interact with Valgrind.
Anyway, I'll try to reproduce the environment, I'm guessing it would
be best to catch this in gdb so I can actually see what's going on.

On 11 August 2017 at 15:21, Vassil Vassilev <v.g.vassi...@gmail.com> wrote:
> That's really strange. It looks like some random behavior. Did you run some 
> memory checker like valgrind?
>
> Do the environment provided by the test runner and yours match?
>
> Sent from my phone. Please excuse my brevity.
>
>> On 11 Aug 2017, at 15:58, Diana Picus <diana.pi...@linaro.org> wrote:
>>
>> Hi again,
>>
>> I finally got the debug build, but unfortunately the stack traces that
>> the tests print look the same. My suspicion is that this is because
>> the addresses printed by the tests are funny (i.e. odd numbers instead
>> of divisible by 4). I tried to follow those addresses in an objdump of
>> the executable, but I didn't have much success since most of them
>> weren't really pointing to call instructions.
>>
>> When I try to run the tests manually in the shell or in gdb, they pass.
>>
>> I'm not sure what else to try. Thoughts?
>>
>> Thanks,
>> Diana
>>
>>> On 11 August 2017 at 11:14, Diana Picus <diana.pi...@linaro.org> wrote:
>>> Hi guys,
>>>
>>> I'm SO sorry about the delays. I've been having all sorts of trouble
>>> getting that debug build on the board (from ld running out of memory
>>> to the board just crashing on me, in which case I need to ask someone
>>> else to reboot it because I can't power cycle it remotely). I can
>>> assure you this is one of my top priorities, I'll get those stack
>>> traces as soon as I can.
>>>
>>> Thanks for your patience and sorry again,
>>> Diana
>>>
>>>> On 10 August 2017 at 22:55, Richard Smith <rich...@metafoo.co.uk> wrote:
>>>> Any news on this? We want this change in Clang 5, so the sooner we can
>>>> understand and fix this regression the better...
>>>>
>>>> On 10 August 2017 at 01:28, Diana Picus via cfe-commits
>>>> <cfe-commits@lists.llvm.org> wrote:
>>>>>
>>>>> Hi Vassil,
>>>>>
>>>>> My build is in progress, but since it's a full build it's probably
>>>>> going to take another couple of hours to complete. I'll let you know
>>>>> when it's done.
>>>>>
>>>>> Thanks,
>>>>> Diana
>>>>>
>>>>> On 10 August 2017 at 10:09, Vassil Vassilev <v.g.vassi...@gmail.com>
>>>>> wrote:
>>>>>> It looks like I can not reproduce it on osx (non-arm)... :(
>>>>>>> On 09/08/17 22:54, Diana Picus wrote:
>>>>>>>
>>>>>>> Reverting this also fixed the selfhost bots:
>>>>>>>
>>>>>>>
>>>>>>> http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/2142
>>>>>>>
>>>>>>>
>>>>>>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/2309
>>>>>>>
>>>>>>>
>>>>>>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon/builds/1819
>>>>>>>
>>>>>>> I'm afraid the logs for those look even less helpful.
>>>>>>>
>>>>>>>> On 9 August 2017 at 16:17, Diana Picus <diana.pi...@linaro.org> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> See attached. FWIW, when I ran this on a very similar machine, I got
>>>>>>>> 194 failures, all of which went away after reverting. So there might
>>>>>>>> be something fishy going on.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Diana
>>>>>>>>
>>>>>>>> On 9 August 2017 at 15:02, Vassil Vassilev <v.g.vassi...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Diana,
>>>>>>>>>
>>>>>>>>>   It seems the service is down. Could you send us the details of the
>>>>>>>>> failures (incl stack traces if any)
>>>>>>>>>
>>>>>>>>> Many thanks,
>>>>>>>>> Vassil
&

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

Hi again,

I finally got the debug build, but unfortunately the stack traces that
the tests print look the same. My suspicion is that this is because
the addresses printed by the tests are funny (i.e. odd numbers instead
of divisible by 4). I tried to follow those addresses in an objdump of
the executable, but I didn't have much success since most of them
weren't really pointing to call instructions.

When I try to run the tests manually in the shell or in gdb, they pass.

I'm not sure what else to try. Thoughts?

Thanks,
Diana

On 11 August 2017 at 11:14, Diana Picus <diana.pi...@linaro.org> wrote:
> Hi guys,
>
> I'm SO sorry about the delays. I've been having all sorts of trouble
> getting that debug build on the board (from ld running out of memory
> to the board just crashing on me, in which case I need to ask someone
> else to reboot it because I can't power cycle it remotely). I can
> assure you this is one of my top priorities, I'll get those stack
> traces as soon as I can.
>
> Thanks for your patience and sorry again,
> Diana
>
> On 10 August 2017 at 22:55, Richard Smith <rich...@metafoo.co.uk> wrote:
>> Any news on this? We want this change in Clang 5, so the sooner we can
>> understand and fix this regression the better...
>>
>> On 10 August 2017 at 01:28, Diana Picus via cfe-commits
>> <cfe-commits@lists.llvm.org> wrote:
>>>
>>> Hi Vassil,
>>>
>>> My build is in progress, but since it's a full build it's probably
>>> going to take another couple of hours to complete. I'll let you know
>>> when it's done.
>>>
>>> Thanks,
>>> Diana
>>>
>>> On 10 August 2017 at 10:09, Vassil Vassilev <v.g.vassi...@gmail.com>
>>> wrote:
>>> > It looks like I can not reproduce it on osx (non-arm)... :(
>>> > On 09/08/17 22:54, Diana Picus wrote:
>>> >>
>>> >> Reverting this also fixed the selfhost bots:
>>> >>
>>> >>
>>> >> http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/2142
>>> >>
>>> >>
>>> >> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/2309
>>> >>
>>> >>
>>> >> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon/builds/1819
>>> >>
>>> >> I'm afraid the logs for those look even less helpful.
>>> >>
>>> >> On 9 August 2017 at 16:17, Diana Picus <diana.pi...@linaro.org> wrote:
>>> >>>
>>> >>> Hi,
>>> >>>
>>> >>> See attached. FWIW, when I ran this on a very similar machine, I got
>>> >>> 194 failures, all of which went away after reverting. So there might
>>> >>> be something fishy going on.
>>> >>>
>>> >>> Regards,
>>> >>> Diana
>>> >>>
>>> >>> On 9 August 2017 at 15:02, Vassil Vassilev <v.g.vassi...@gmail.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> Hi Diana,
>>> >>>>
>>> >>>>It seems the service is down. Could you send us the details of the
>>> >>>> failures (incl stack traces if any)
>>> >>>>
>>> >>>> Many thanks,
>>> >>>> Vassil
>>> >>>>
>>> >>>> On 09/08/17 15:27, Diana Picus via cfe-commits wrote:
>>> >>>>>
>>> >>>>> Hi Richard,
>>> >>>>>
>>> >>>>> I'm sorry but I've reverted this in r310464 because it was breaking
>>> >>>>> some ASAN tests on this bot:
>>> >>>>>
>>> >>>>>
>>> >>>>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/9452
>>> >>>>>
>>> >>>>> Please let me know if I can help debug this.
>>> >>>>>
>>> >>>>> Cheers,
>>> >>>>> Diana
>>> >>>>>
>>> >>>>> On 8 August 2017 at 21:14, Richard Smith via cfe-commits
>>> >>>>> <cfe-commits@lists.llvm.org> wrote:
>>> >>>>>>
>>> >>>>>> I forgot to say:
>>> >>>>>>
>>> >>>>>> Based on a patch by Vassil Vassilev, which was based on a patch by
>>> >>>>>> Bernd
>>> >>>>&g

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

Hi guys,

I'm SO sorry about the delays. I've been having all sorts of trouble
getting that debug build on the board (from ld running out of memory
to the board just crashing on me, in which case I need to ask someone
else to reboot it because I can't power cycle it remotely). I can
assure you this is one of my top priorities, I'll get those stack
traces as soon as I can.

Thanks for your patience and sorry again,
Diana

On 10 August 2017 at 22:55, Richard Smith <rich...@metafoo.co.uk> wrote:
> Any news on this? We want this change in Clang 5, so the sooner we can
> understand and fix this regression the better...
>
> On 10 August 2017 at 01:28, Diana Picus via cfe-commits
> <cfe-commits@lists.llvm.org> wrote:
>>
>> Hi Vassil,
>>
>> My build is in progress, but since it's a full build it's probably
>> going to take another couple of hours to complete. I'll let you know
>> when it's done.
>>
>> Thanks,
>> Diana
>>
>> On 10 August 2017 at 10:09, Vassil Vassilev <v.g.vassi...@gmail.com>
>> wrote:
>> > It looks like I can not reproduce it on osx (non-arm)... :(
>> > On 09/08/17 22:54, Diana Picus wrote:
>> >>
>> >> Reverting this also fixed the selfhost bots:
>> >>
>> >>
>> >> http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/2142
>> >>
>> >>
>> >> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/2309
>> >>
>> >>
>> >> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon/builds/1819
>> >>
>> >> I'm afraid the logs for those look even less helpful.
>> >>
>> >> On 9 August 2017 at 16:17, Diana Picus <diana.pi...@linaro.org> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> See attached. FWIW, when I ran this on a very similar machine, I got
>> >>> 194 failures, all of which went away after reverting. So there might
>> >>> be something fishy going on.
>> >>>
>> >>> Regards,
>> >>> Diana
>> >>>
>> >>> On 9 August 2017 at 15:02, Vassil Vassilev <v.g.vassi...@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> Hi Diana,
>> >>>>
>> >>>>It seems the service is down. Could you send us the details of the
>> >>>> failures (incl stack traces if any)
>> >>>>
>> >>>> Many thanks,
>> >>>> Vassil
>> >>>>
>> >>>> On 09/08/17 15:27, Diana Picus via cfe-commits wrote:
>> >>>>>
>> >>>>> Hi Richard,
>> >>>>>
>> >>>>> I'm sorry but I've reverted this in r310464 because it was breaking
>> >>>>> some ASAN tests on this bot:
>> >>>>>
>> >>>>>
>> >>>>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/9452
>> >>>>>
>> >>>>> Please let me know if I can help debug this.
>> >>>>>
>> >>>>> Cheers,
>> >>>>> Diana
>> >>>>>
>> >>>>> On 8 August 2017 at 21:14, Richard Smith via cfe-commits
>> >>>>> <cfe-commits@lists.llvm.org> wrote:
>> >>>>>>
>> >>>>>> I forgot to say:
>> >>>>>>
>> >>>>>> Based on a patch by Vassil Vassilev, which was based on a patch by
>> >>>>>> Bernd
>> >>>>>> Schmidt, which was based on a patch by Reid Kleckner.
>> >>>>>>
>> >>>>>> On 8 August 2017 at 12:12, Richard Smith via cfe-commits
>> >>>>>> <cfe-commits@lists.llvm.org> wrote:
>> >>>>>>>
>> >>>>>>> Author: rsmith
>> >>>>>>> Date: Tue Aug  8 12:12:28 2017
>> >>>>>>> New Revision: 310401
>> >>>>>>>
>> >>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=310401=rev
>> >>>>>>> Log:
>> >>>>>>> PR19668, PR23034: Fix handling of move constructors and deleted
>> >>>>>>> copy
>> >>>>>>> constructors when deciding whether classes should be passed
>> >>>>>>> indirectly.
>> >>>>>>&g

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

Hi Vassil,

My build is in progress, but since it's a full build it's probably
going to take another couple of hours to complete. I'll let you know
when it's done.

Thanks,
Diana

On 10 August 2017 at 10:09, Vassil Vassilev <v.g.vassi...@gmail.com> wrote:
> It looks like I can not reproduce it on osx (non-arm)... :(
> On 09/08/17 22:54, Diana Picus wrote:
>>
>> Reverting this also fixed the selfhost bots:
>>
>> http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/2142
>>
>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/2309
>>
>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon/builds/1819
>>
>> I'm afraid the logs for those look even less helpful.
>>
>> On 9 August 2017 at 16:17, Diana Picus <diana.pi...@linaro.org> wrote:
>>>
>>> Hi,
>>>
>>> See attached. FWIW, when I ran this on a very similar machine, I got
>>> 194 failures, all of which went away after reverting. So there might
>>> be something fishy going on.
>>>
>>> Regards,
>>> Diana
>>>
>>> On 9 August 2017 at 15:02, Vassil Vassilev <v.g.vassi...@gmail.com>
>>> wrote:
>>>>
>>>> Hi Diana,
>>>>
>>>>It seems the service is down. Could you send us the details of the
>>>> failures (incl stack traces if any)
>>>>
>>>> Many thanks,
>>>> Vassil
>>>>
>>>> On 09/08/17 15:27, Diana Picus via cfe-commits wrote:
>>>>>
>>>>> Hi Richard,
>>>>>
>>>>> I'm sorry but I've reverted this in r310464 because it was breaking
>>>>> some ASAN tests on this bot:
>>>>>
>>>>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/9452
>>>>>
>>>>> Please let me know if I can help debug this.
>>>>>
>>>>> Cheers,
>>>>> Diana
>>>>>
>>>>> On 8 August 2017 at 21:14, Richard Smith via cfe-commits
>>>>> <cfe-commits@lists.llvm.org> wrote:
>>>>>>
>>>>>> I forgot to say:
>>>>>>
>>>>>> Based on a patch by Vassil Vassilev, which was based on a patch by
>>>>>> Bernd
>>>>>> Schmidt, which was based on a patch by Reid Kleckner.
>>>>>>
>>>>>> On 8 August 2017 at 12:12, Richard Smith via cfe-commits
>>>>>> <cfe-commits@lists.llvm.org> wrote:
>>>>>>>
>>>>>>> Author: rsmith
>>>>>>> Date: Tue Aug  8 12:12:28 2017
>>>>>>> New Revision: 310401
>>>>>>>
>>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=310401=rev
>>>>>>> Log:
>>>>>>> PR19668, PR23034: Fix handling of move constructors and deleted copy
>>>>>>> constructors when deciding whether classes should be passed
>>>>>>> indirectly.
>>>>>>>
>>>>>>> This fixes ABI differences between Clang and GCC:
>>>>>>>
>>>>>>>* Previously, Clang ignored the move constructor when making this
>>>>>>>  determination. It now takes the move constructor into account,
>>>>>>> per
>>>>>>>  https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change
>>>>>>> may
>>>>>>>  seem recent, but the ABI change was agreed on the Itanium C++
>>>>>>> ABI
>>>>>>>  list a long time ago).
>>>>>>>
>>>>>>>* Previously, Clang's behavior when the copy constructor was
>>>>>>> deleted
>>>>>>>  was unstable -- depending on whether the lazy declaration of the
>>>>>>>  copy constructor had been triggered, you might get different
>>>>>>> behavior.
>>>>>>>  We now eagerly declare the copy constructor whenever its
>>>>>>> deletedness
>>>>>>>  is unclear, and ignore deleted copy/move constructors when
>>>>>>> looking
>>>>>>> for
>>>>>>>  a trivial such constructor.
>>>>>>>
>>>>>>> This also fixes an ABI difference between Clang and MSVC:
>>>>>>>
>>>>>>>* If the copy constructor would be

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

Reverting this also fixed the selfhost bots:
http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/2142
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/2309
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon/builds/1819

I'm afraid the logs for those look even less helpful.

On 9 August 2017 at 16:17, Diana Picus <diana.pi...@linaro.org> wrote:
> Hi,
>
> See attached. FWIW, when I ran this on a very similar machine, I got
> 194 failures, all of which went away after reverting. So there might
> be something fishy going on.
>
> Regards,
> Diana
>
> On 9 August 2017 at 15:02, Vassil Vassilev <v.g.vassi...@gmail.com> wrote:
>> Hi Diana,
>>
>>   It seems the service is down. Could you send us the details of the
>> failures (incl stack traces if any)
>>
>> Many thanks,
>> Vassil
>>
>> On 09/08/17 15:27, Diana Picus via cfe-commits wrote:
>>>
>>> Hi Richard,
>>>
>>> I'm sorry but I've reverted this in r310464 because it was breaking
>>> some ASAN tests on this bot:
>>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/9452
>>>
>>> Please let me know if I can help debug this.
>>>
>>> Cheers,
>>> Diana
>>>
>>> On 8 August 2017 at 21:14, Richard Smith via cfe-commits
>>> <cfe-commits@lists.llvm.org> wrote:
>>>>
>>>> I forgot to say:
>>>>
>>>> Based on a patch by Vassil Vassilev, which was based on a patch by Bernd
>>>> Schmidt, which was based on a patch by Reid Kleckner.
>>>>
>>>> On 8 August 2017 at 12:12, Richard Smith via cfe-commits
>>>> <cfe-commits@lists.llvm.org> wrote:
>>>>>
>>>>> Author: rsmith
>>>>> Date: Tue Aug  8 12:12:28 2017
>>>>> New Revision: 310401
>>>>>
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=310401=rev
>>>>> Log:
>>>>> PR19668, PR23034: Fix handling of move constructors and deleted copy
>>>>> constructors when deciding whether classes should be passed indirectly.
>>>>>
>>>>> This fixes ABI differences between Clang and GCC:
>>>>>
>>>>>   * Previously, Clang ignored the move constructor when making this
>>>>> determination. It now takes the move constructor into account, per
>>>>> https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may
>>>>> seem recent, but the ABI change was agreed on the Itanium C++ ABI
>>>>> list a long time ago).
>>>>>
>>>>>   * Previously, Clang's behavior when the copy constructor was deleted
>>>>> was unstable -- depending on whether the lazy declaration of the
>>>>> copy constructor had been triggered, you might get different
>>>>> behavior.
>>>>> We now eagerly declare the copy constructor whenever its deletedness
>>>>> is unclear, and ignore deleted copy/move constructors when looking
>>>>> for
>>>>> a trivial such constructor.
>>>>>
>>>>> This also fixes an ABI difference between Clang and MSVC:
>>>>>
>>>>>   * If the copy constructor would be implicitly deleted (but has not
>>>>> been
>>>>> lazily declared yet), for instance because the class has an rvalue
>>>>> reference member, we would pass it directly. We now pass such a
>>>>> class
>>>>> indirectly, matching MSVC.
>>>>>
>>>>> Modified:
>>>>>  cfe/trunk/include/clang/AST/DeclCXX.h
>>>>>  cfe/trunk/lib/AST/ASTImporter.cpp
>>>>>  cfe/trunk/lib/AST/DeclCXX.cpp
>>>>>  cfe/trunk/lib/CodeGen/CGCXXABI.cpp
>>>>>  cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>>>>>  cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
>>>>>  cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>>>>>  cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>>>>>  cfe/trunk/lib/Serialization/ASTWriter.cpp
>>>>>  cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp
>>>>>  cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
>>>>>
>>>>> Modified: cfe/trunk/include/clang/AST/DeclCXX.h
>>>>> URL:
>>>>>
>>>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

Hi Richard,

I'm sorry but I've reverted this in r310464 because it was breaking
some ASAN tests on this bot:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/9452

Please let me know if I can help debug this.

Cheers,
Diana

On 8 August 2017 at 21:14, Richard Smith via cfe-commits
 wrote:
> I forgot to say:
>
> Based on a patch by Vassil Vassilev, which was based on a patch by Bernd
> Schmidt, which was based on a patch by Reid Kleckner.
>
> On 8 August 2017 at 12:12, Richard Smith via cfe-commits
>  wrote:
>>
>> Author: rsmith
>> Date: Tue Aug  8 12:12:28 2017
>> New Revision: 310401
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=310401=rev
>> Log:
>> PR19668, PR23034: Fix handling of move constructors and deleted copy
>> constructors when deciding whether classes should be passed indirectly.
>>
>> This fixes ABI differences between Clang and GCC:
>>
>>  * Previously, Clang ignored the move constructor when making this
>>determination. It now takes the move constructor into account, per
>>https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may
>>seem recent, but the ABI change was agreed on the Itanium C++ ABI
>>list a long time ago).
>>
>>  * Previously, Clang's behavior when the copy constructor was deleted
>>was unstable -- depending on whether the lazy declaration of the
>>copy constructor had been triggered, you might get different behavior.
>>We now eagerly declare the copy constructor whenever its deletedness
>>is unclear, and ignore deleted copy/move constructors when looking for
>>a trivial such constructor.
>>
>> This also fixes an ABI difference between Clang and MSVC:
>>
>>  * If the copy constructor would be implicitly deleted (but has not been
>>lazily declared yet), for instance because the class has an rvalue
>>reference member, we would pass it directly. We now pass such a class
>>indirectly, matching MSVC.
>>
>> Modified:
>> cfe/trunk/include/clang/AST/DeclCXX.h
>> cfe/trunk/lib/AST/ASTImporter.cpp
>> cfe/trunk/lib/AST/DeclCXX.cpp
>> cfe/trunk/lib/CodeGen/CGCXXABI.cpp
>> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>> cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
>> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>> cfe/trunk/lib/Serialization/ASTWriter.cpp
>> cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp
>> cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
>>
>> Modified: cfe/trunk/include/clang/AST/DeclCXX.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=310401=310400=310401=diff
>>
>> ==
>> --- cfe/trunk/include/clang/AST/DeclCXX.h (original)
>> +++ cfe/trunk/include/clang/AST/DeclCXX.h Tue Aug  8 12:12:28 2017
>> @@ -375,6 +375,7 @@ class CXXRecordDecl : public RecordDecl
>>  /// \brief These flags are \c true if a defaulted corresponding
>> special
>>  /// member can't be fully analyzed without performing overload
>> resolution.
>>  /// @{
>> +unsigned NeedOverloadResolutionForCopyConstructor : 1;
>>  unsigned NeedOverloadResolutionForMoveConstructor : 1;
>>  unsigned NeedOverloadResolutionForMoveAssignment : 1;
>>  unsigned NeedOverloadResolutionForDestructor : 1;
>> @@ -383,6 +384,7 @@ class CXXRecordDecl : public RecordDecl
>>  /// \brief These flags are \c true if an implicit defaulted
>> corresponding
>>  /// special member would be defined as deleted.
>>  /// @{
>> +unsigned DefaultedCopyConstructorIsDeleted : 1;
>>  unsigned DefaultedMoveConstructorIsDeleted : 1;
>>  unsigned DefaultedMoveAssignmentIsDeleted : 1;
>>  unsigned DefaultedDestructorIsDeleted : 1;
>> @@ -415,6 +417,12 @@ class CXXRecordDecl : public RecordDecl
>>  /// constructor.
>>  unsigned HasDefaultedDefaultConstructor : 1;
>>
>> +/// \brief True if this class can be passed in a
>> non-address-preserving
>> +/// fashion (such as in registers) according to the C++ language
>> rules.
>> +/// This does not imply anything about how the ABI in use will
>> actually
>> +/// pass an object of this class.
>> +unsigned CanPassInRegisters : 1;
>> +
>>  /// \brief True if a defaulted default constructor for this class
>> would
>>  /// be constexpr.
>>  unsigned DefaultedDefaultConstructorIsConstexpr : 1;
>> @@ -811,18 +819,50 @@ public:
>>  return data().FirstFriend.isValid();
>>}
>>
>> +  /// \brief \c true if a defaulted copy constructor for this class would
>> be
>> +  /// deleted.
>> +  bool defaultedCopyConstructorIsDeleted() const {
>> +assert((!needsOverloadResolutionForCopyConstructor() ||
>> +(data().DeclaredSpecialMembers & SMF_CopyConstructor)) &&
>> +   "this property has not yet been computed by Sema");
>> +return 

r310464 - Revert "PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly."

[Diana Picus via cfe-commits]

Author: rovka
Date: Wed Aug  9 05:22:25 2017
New Revision: 310464

URL: http://llvm.org/viewvc/llvm-project?rev=310464=rev
Log:
Revert "PR19668, PR23034: Fix handling of move constructors and deleted copy 
constructors when deciding whether classes should be passed indirectly."

This reverts commit r310401 because it seems to have broken some ARM
bot(s).

Modified:
cfe/trunk/include/clang/AST/DeclCXX.h
cfe/trunk/lib/AST/ASTImporter.cpp
cfe/trunk/lib/AST/DeclCXX.cpp
cfe/trunk/lib/CodeGen/CGCXXABI.cpp
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp
cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp

Modified: cfe/trunk/include/clang/AST/DeclCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=310464=310463=310464=diff
==
--- cfe/trunk/include/clang/AST/DeclCXX.h (original)
+++ cfe/trunk/include/clang/AST/DeclCXX.h Wed Aug  9 05:22:25 2017
@@ -375,7 +375,6 @@ class CXXRecordDecl : public RecordDecl
 /// \brief These flags are \c true if a defaulted corresponding special
 /// member can't be fully analyzed without performing overload resolution.
 /// @{
-unsigned NeedOverloadResolutionForCopyConstructor : 1;
 unsigned NeedOverloadResolutionForMoveConstructor : 1;
 unsigned NeedOverloadResolutionForMoveAssignment : 1;
 unsigned NeedOverloadResolutionForDestructor : 1;
@@ -384,7 +383,6 @@ class CXXRecordDecl : public RecordDecl
 /// \brief These flags are \c true if an implicit defaulted corresponding
 /// special member would be defined as deleted.
 /// @{
-unsigned DefaultedCopyConstructorIsDeleted : 1;
 unsigned DefaultedMoveConstructorIsDeleted : 1;
 unsigned DefaultedMoveAssignmentIsDeleted : 1;
 unsigned DefaultedDestructorIsDeleted : 1;
@@ -417,12 +415,6 @@ class CXXRecordDecl : public RecordDecl
 /// constructor.
 unsigned HasDefaultedDefaultConstructor : 1;
 
-/// \brief True if this class can be passed in a non-address-preserving
-/// fashion (such as in registers) according to the C++ language rules.
-/// This does not imply anything about how the ABI in use will actually
-/// pass an object of this class.
-unsigned CanPassInRegisters : 1;
-
 /// \brief True if a defaulted default constructor for this class would
 /// be constexpr.
 unsigned DefaultedDefaultConstructorIsConstexpr : 1;
@@ -819,50 +811,18 @@ public:
 return data().FirstFriend.isValid();
   }
 
-  /// \brief \c true if a defaulted copy constructor for this class would be
-  /// deleted.
-  bool defaultedCopyConstructorIsDeleted() const {
-assert((!needsOverloadResolutionForCopyConstructor() ||
-(data().DeclaredSpecialMembers & SMF_CopyConstructor)) &&
-   "this property has not yet been computed by Sema");
-return data().DefaultedCopyConstructorIsDeleted;
-  }
-
-  /// \brief \c true if a defaulted move constructor for this class would be
-  /// deleted.
-  bool defaultedMoveConstructorIsDeleted() const {
-assert((!needsOverloadResolutionForMoveConstructor() ||
-(data().DeclaredSpecialMembers & SMF_MoveConstructor)) &&
-   "this property has not yet been computed by Sema");
-return data().DefaultedMoveConstructorIsDeleted;
-  }
-
-  /// \brief \c true if a defaulted destructor for this class would be deleted.
-  bool defaultedDestructorIsDeleted() const {
-return !data().DefaultedDestructorIsDeleted;
-  }
-
-  /// \brief \c true if we know for sure that this class has a single,
-  /// accessible, unambiguous copy constructor that is not deleted.
-  bool hasSimpleCopyConstructor() const {
-return !hasUserDeclaredCopyConstructor() &&
-   !data().DefaultedCopyConstructorIsDeleted;
-  }
-
   /// \brief \c true if we know for sure that this class has a single,
   /// accessible, unambiguous move constructor that is not deleted.
   bool hasSimpleMoveConstructor() const {
 return !hasUserDeclaredMoveConstructor() && hasMoveConstructor() &&
!data().DefaultedMoveConstructorIsDeleted;
   }
-
   /// \brief \c true if we know for sure that this class has a single,
   /// accessible, unambiguous move assignment operator that is not deleted.
   bool hasSimpleMoveAssignment() const {
 return !hasUserDeclaredMoveAssignment() && hasMoveAssignment() &&
!data().DefaultedMoveAssignmentIsDeleted;
   }
-
   /// \brief \c true if we know for sure that this class has an accessible
   /// destructor that is not deleted.
   bool hasSimpleDestructor() const {
@@ -918,16 +878,7 @@ public:
   /// \brief Determine whether we need to eagerly declare a defaulted copy
   /// constructor for this class.
   

Re: r305239 - Revert r301742 which made ExprConstant checking apply to all full-exprs.

[Diana Picus via cfe-commits]

Hi,

I reverted r305287, since the bots were red for a very long time. More
bots with the same error:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/7727
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/5503
http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/9097

Cheers,
Diana

On 13 June 2017 at 07:12, NAKAMURA Takumi via cfe-commits
 wrote:
> It triggered a test failure for targeting i686 (seems also for arm)
> See also; http://bb.pgr.jp/builders/test-clang-i686-linux-RA/builds/3566
>
> On Tue, Jun 13, 2017 at 6:59 AM Nick Lewycky via cfe-commits
>  wrote:
>>
>> Author: nicholas
>> Date: Mon Jun 12 16:59:18 2017
>> New Revision: 305239
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=305239=rev
>> Log:
>> Revert r301742 which made ExprConstant checking apply to all full-exprs.
>>
>> This patch also exposed pre-existing bugs in clang, see PR32864 and
>> PR33140#c3 .
>>
>> Modified:
>> cfe/trunk/include/clang/Sema/Sema.h
>> cfe/trunk/lib/AST/ExprConstant.cpp
>> cfe/trunk/lib/Sema/SemaChecking.cpp
>>
>> cfe/trunk/test/OpenMP/distribute_parallel_for_simd_aligned_messages.cpp
>> cfe/trunk/test/OpenMP/distribute_simd_aligned_messages.cpp
>> cfe/trunk/test/OpenMP/for_simd_aligned_messages.cpp
>> cfe/trunk/test/OpenMP/parallel_for_simd_aligned_messages.cpp
>> cfe/trunk/test/OpenMP/simd_aligned_messages.cpp
>> cfe/trunk/test/OpenMP/target_parallel_for_simd_aligned_messages.cpp
>> cfe/trunk/test/OpenMP/target_simd_aligned_messages.cpp
>>
>> cfe/trunk/test/OpenMP/target_teams_distribute_parallel_for_simd_aligned_messages.cpp
>>
>> cfe/trunk/test/OpenMP/target_teams_distribute_simd_aligned_messages.cpp
>> cfe/trunk/test/OpenMP/taskloop_simd_aligned_messages.cpp
>>
>> cfe/trunk/test/OpenMP/teams_distribute_parallel_for_simd_aligned_messages.cpp
>> cfe/trunk/test/OpenMP/teams_distribute_simd_aligned_messages.cpp
>> cfe/trunk/test/Sema/integer-overflow.c
>>
>> Modified: cfe/trunk/include/clang/Sema/Sema.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=305239=305238=305239=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Sema/Sema.h (original)
>> +++ cfe/trunk/include/clang/Sema/Sema.h Mon Jun 12 16:59:18 2017
>> @@ -10273,6 +10273,7 @@ private:
>>void CheckFloatComparison(SourceLocation Loc, Expr* LHS, Expr* RHS);
>>void CheckImplicitConversions(Expr *E, SourceLocation CC =
>> SourceLocation());
>>void CheckBoolLikeConversion(Expr *E, SourceLocation CC);
>> +  void CheckForIntOverflow(Expr *E);
>>void CheckUnsequencedOperations(Expr *E);
>>
>>/// \brief Perform semantic checks on a completed expression. This will
>> either
>>
>> Modified: cfe/trunk/lib/AST/ExprConstant.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=305239=305238=305239=diff
>>
>> ==
>> --- cfe/trunk/lib/AST/ExprConstant.cpp (original)
>> +++ cfe/trunk/lib/AST/ExprConstant.cpp Mon Jun 12 16:59:18 2017
>> @@ -6226,10 +6226,6 @@ bool RecordExprEvaluator::VisitInitListE
>>  // the initializer list.
>>  ImplicitValueInitExpr VIE(HaveInit ? Info.Ctx.IntTy :
>> Field->getType());
>>  const Expr *Init = HaveInit ? E->getInit(ElementNo++) : 
>> -if (Init->isValueDependent()) {
>> -  Success = false;
>> -  continue;
>> -}
>>
>>  // Temporarily override This, in case there's a CXXDefaultInitExpr in
>> here.
>>  ThisOverrideRAII ThisOverride(*Info.CurrentCall, ,
>> @@ -9940,8 +9936,7 @@ static bool EvaluateAsRValue(EvalInfo 
>>  }
>>
>>  static bool FastEvaluateAsRValue(const Expr *Exp, Expr::EvalResult
>> ,
>> - const ASTContext , bool ,
>> - bool IsCheckingForOverflow) {
>> + const ASTContext , bool ) {
>>// Fast-path evaluations of integer literals, since we sometimes see
>> files
>>// containing vast quantities of these.
>>if (const IntegerLiteral *L = dyn_cast(Exp)) {
>> @@ -9962,7 +9957,7 @@ static bool FastEvaluateAsRValue(const E
>>// performance problems. Only do so in C++11 for now.
>>if (Exp->isRValue() && (Exp->getType()->isArrayType() ||
>>Exp->getType()->isRecordType()) &&
>> -  !Ctx.getLangOpts().CPlusPlus11 && !IsCheckingForOverflow) {
>> +  !Ctx.getLangOpts().CPlusPlus11) {
>>  IsConst = false;
>>  return true;
>>}
>> @@ -9977,7 +9972,7 @@ static bool FastEvaluateAsRValue(const E
>>  /// will be applied to the result.
>>  bool Expr::EvaluateAsRValue(EvalResult , const ASTContext )
>> const {
>>bool IsConst;
>> -  if (FastEvaluateAsRValue(this, Result, Ctx, IsConst, false))
>> +  if (FastEvaluateAsRValue(this, Result, Ctx, IsConst))
>>  return 

r305287 - Revert "Revert r301742 which made ExprConstant checking apply to all full-exprs."

[Diana Picus via cfe-commits]

Author: rovka
Date: Tue Jun 13 07:50:06 2017
New Revision: 305287

URL: http://llvm.org/viewvc/llvm-project?rev=305287=rev
Log:
Revert "Revert r301742 which made ExprConstant checking apply to all 
full-exprs."

This reverts commit r305239 because it broke the buildbots (the
diag-flags.cpp test is failing).

Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/lib/Sema/SemaChecking.cpp
cfe/trunk/test/OpenMP/distribute_parallel_for_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/distribute_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/for_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/parallel_for_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/target_parallel_for_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/target_simd_aligned_messages.cpp

cfe/trunk/test/OpenMP/target_teams_distribute_parallel_for_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/target_teams_distribute_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/taskloop_simd_aligned_messages.cpp

cfe/trunk/test/OpenMP/teams_distribute_parallel_for_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/teams_distribute_simd_aligned_messages.cpp
cfe/trunk/test/Sema/integer-overflow.c

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=305287=305286=305287=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Tue Jun 13 07:50:06 2017
@@ -10273,7 +10273,6 @@ private:
   void CheckFloatComparison(SourceLocation Loc, Expr* LHS, Expr* RHS);
   void CheckImplicitConversions(Expr *E, SourceLocation CC = SourceLocation());
   void CheckBoolLikeConversion(Expr *E, SourceLocation CC);
-  void CheckForIntOverflow(Expr *E);
   void CheckUnsequencedOperations(Expr *E);
 
   /// \brief Perform semantic checks on a completed expression. This will 
either

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=305287=305286=305287=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Tue Jun 13 07:50:06 2017
@@ -6226,6 +6226,10 @@ bool RecordExprEvaluator::VisitInitListE
 // the initializer list.
 ImplicitValueInitExpr VIE(HaveInit ? Info.Ctx.IntTy : Field->getType());
 const Expr *Init = HaveInit ? E->getInit(ElementNo++) : 
+if (Init->isValueDependent()) {
+  Success = false;
+  continue;
+}
 
 // Temporarily override This, in case there's a CXXDefaultInitExpr in here.
 ThisOverrideRAII ThisOverride(*Info.CurrentCall, ,
@@ -9936,7 +9940,8 @@ static bool EvaluateAsRValue(EvalInfo 
 }
 
 static bool FastEvaluateAsRValue(const Expr *Exp, Expr::EvalResult ,
- const ASTContext , bool ) {
+ const ASTContext , bool ,
+ bool IsCheckingForOverflow) {
   // Fast-path evaluations of integer literals, since we sometimes see files
   // containing vast quantities of these.
   if (const IntegerLiteral *L = dyn_cast(Exp)) {
@@ -9957,7 +9962,7 @@ static bool FastEvaluateAsRValue(const E
   // performance problems. Only do so in C++11 for now.
   if (Exp->isRValue() && (Exp->getType()->isArrayType() ||
   Exp->getType()->isRecordType()) &&
-  !Ctx.getLangOpts().CPlusPlus11) {
+  !Ctx.getLangOpts().CPlusPlus11 && !IsCheckingForOverflow) {
 IsConst = false;
 return true;
   }
@@ -9972,7 +9977,7 @@ static bool FastEvaluateAsRValue(const E
 /// will be applied to the result.
 bool Expr::EvaluateAsRValue(EvalResult , const ASTContext ) const {
   bool IsConst;
-  if (FastEvaluateAsRValue(this, Result, Ctx, IsConst))
+  if (FastEvaluateAsRValue(this, Result, Ctx, IsConst, false))
 return IsConst;
   
   EvalInfo Info(Ctx, Result, EvalInfo::EM_IgnoreSideEffects);
@@ -10097,7 +10102,7 @@ APSInt Expr::EvaluateKnownConstInt(const
 void Expr::EvaluateForOverflow(const ASTContext ) const {
   bool IsConst;
   EvalResult EvalResult;
-  if (!FastEvaluateAsRValue(this, EvalResult, Ctx, IsConst)) {
+  if (!FastEvaluateAsRValue(this, EvalResult, Ctx, IsConst, true)) {
 EvalInfo Info(Ctx, EvalResult, EvalInfo::EM_EvaluateForOverflow);
 (void)::EvaluateAsRValue(Info, this, EvalResult.Val);
   }

Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=305287=305286=305287=diff
==
--- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
+++ cfe/trunk/lib/Sema/SemaChecking.cpp Tue Jun 13 07:50:06 2017
@@ -9935,28 +9935,6 @@ void 

r304211 - Fixup r304205 - Require PowerPC target

[Diana Picus via cfe-commits]

Author: rovka
Date: Tue May 30 09:05:33 2017
New Revision: 304211

URL: http://llvm.org/viewvc/llvm-project?rev=304211=rev
Log:
Fixup r304205 - Require PowerPC target

Modified:
cfe/trunk/test/CodeGen/altivec-ct.c

Modified: cfe/trunk/test/CodeGen/altivec-ct.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/altivec-ct.c?rev=304211=304210=304211=diff
==
--- cfe/trunk/test/CodeGen/altivec-ct.c (original)
+++ cfe/trunk/test/CodeGen/altivec-ct.c Tue May 30 09:05:33 2017
@@ -1,6 +1,8 @@
 // RUN: %clang_cc1 -triple powerpc64le-linux-gnu -S -O0 -o - %s 
-target-feature +altivec -target-feature +vsx | FileCheck %s 
-check-prefix=CHECK -check-prefix=VSX
 // RUN: %clang_cc1 -triple powerpc-linux-gnu -S -O0 -o - %s -target-feature 
+altivec -target-feature -vsx | FileCheck %s
 
+// REQUIRES: powerpc-registered-target
+
 #include 
 
 // CHECK-LABEL: test1


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r304201 - [ARM] Fix Neon vector type alignment to 64-bit

[Diana Picus via cfe-commits]

Hi Javed,

I think this broke the bots:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7620

Can you have a look, or revert?

Thanks,
Diana

On 30 May 2017 at 12:12, Javed Absar via cfe-commits
 wrote:
> Author: javed.absar
> Date: Tue May 30 05:12:15 2017
> New Revision: 304201
>
> URL: http://llvm.org/viewvc/llvm-project?rev=304201=rev
> Log:
> [ARM] Fix Neon vector type alignment to 64-bit
>
> The maximum alignment for ARM NEON data types should be 64-bits as specified
> in ARM procedure call standard document Sec. A.2 Notes.
> This patch fixes it from its current larger natural default values, except
> for Android (so as not to break existing ABI).
> Reviewed by: Stephen Hines, Renato Golin.
> Differential Revision: https://reviews.llvm.org/D33205
>
>
> Modified:
> cfe/trunk/lib/Basic/Targets.cpp
> cfe/trunk/test/CodeGen/arm-abi-vector.c
> cfe/trunk/test/CodeGen/arm-neon-misc.c
> cfe/trunk/test/CodeGen/arm-swiftcall.c
> cfe/trunk/test/CodeGen/armv7k-abi.c
>
> Modified: cfe/trunk/lib/Basic/Targets.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=304201=304200=304201=diff
> ==
> --- cfe/trunk/lib/Basic/Targets.cpp (original)
> +++ cfe/trunk/lib/Basic/Targets.cpp Tue May 30 05:12:15 2017
> @@ -5382,6 +5382,11 @@ public:
>  // ARM has atomics up to 8 bytes
>  setAtomic();
>
> +if (Triple.getEnvironment() == llvm::Triple::Android)
> +  MaxVectorAlign = 128; // don't break existing Android ABI
> +else
> +  MaxVectorAlign = 64; // AAPCS
> +
>  // Do force alignment of members that follow zero length bitfields.  If
>  // the alignment of the zero-length bitfield is greater than the member
>  // that follows it, `bar', `bar' will be aligned as the  type of the
>
> Modified: cfe/trunk/test/CodeGen/arm-abi-vector.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-abi-vector.c?rev=304201=304200=304201=diff
> ==
> --- cfe/trunk/test/CodeGen/arm-abi-vector.c (original)
> +++ cfe/trunk/test/CodeGen/arm-abi-vector.c Tue May 30 05:12:15 2017
> @@ -133,20 +133,20 @@ double test_5c(__char5 *in) {
>
>  double varargs_vec_9c(int fixed, ...) {
>  // CHECK: varargs_vec_9c
> -// CHECK: [[VAR:%.*]] = alloca <9 x i8>, align 16
> +// CHECK: [[VAR:%.*]] = alloca <9 x i8>, align 8
>  // CHECK: [[ALIGN:%.*]] = and i32 {{%.*}}, -8
>  // CHECK: [[AP_ALIGN:%.*]] = inttoptr i32 [[ALIGN]] to i8*
>  // CHECK: [[AP_NEXT:%.*]] = getelementptr inbounds i8, i8* [[AP_ALIGN]], i32 
> 16
>  // CHECK: [[AP_CAST:%.*]] = bitcast i8* [[AP_ALIGN]] to <9 x i8>*
>  // CHECK: [[T0:%.*]] = load <9 x i8>, <9 x i8>* [[AP_CAST]], align 8
> -// CHECK: store <9 x i8> [[T0]], <9 x i8>* [[VAR]], align 16
> +// CHECK: store <9 x i8> [[T0]], <9 x i8>* [[VAR]], align 8
>  // APCS-GNU: varargs_vec_9c
> -// APCS-GNU: [[VAR:%.*]] = alloca <9 x i8>, align 16
> +// APCS-GNU: [[VAR:%.*]] = alloca <9 x i8>, align 8
>  // APCS-GNU: [[AP:%.*]] = load i8*,
>  // APCS-GNU: [[AP_NEXT:%.*]] = getelementptr inbounds i8, i8* [[AP]], i32 16
>  // APCS-GNU: [[AP_CAST:%.*]] = bitcast i8* [[AP]] to <9 x i8>*
>  // APCS-GNU: [[VEC:%.*]] = load <9 x i8>, <9 x i8>* [[AP_CAST]], align 4
> -// APCS-GNU: store <9 x i8> [[VEC]], <9 x i8>* [[VAR]], align 16
> +// APCS-GNU: store <9 x i8> [[VEC]], <9 x i8>* [[VAR]], align 8
>  // ANDROID: varargs_vec_9c
>  // ANDROID: [[VAR:%.*]] = alloca <9 x i8>, align 16
>  // ANDROID: [[ALIGN:%.*]] = and i32 {{%.*}}, -8
> @@ -246,15 +246,15 @@ double test_3s(__short3 *in) {
>
>  double varargs_vec_5s(int fixed, ...) {
>  // CHECK: varargs_vec_5s
> -// CHECK: [[VAR_ALIGN:%.*]] = alloca <5 x i16>, align 16
> +// CHECK: [[VAR_ALIGN:%.*]] = alloca <5 x i16>, align 8
>  // CHECK: [[ALIGN:%.*]] = and i32 {{%.*}}, -8
>  // CHECK: [[AP_ALIGN:%.*]] = inttoptr i32 [[ALIGN]] to i8*
>  // CHECK: [[AP_NEXT:%.*]] = getelementptr inbounds i8, i8* [[AP_ALIGN]], i32 
> 16
>  // CHECK: [[AP_CAST:%.*]] = bitcast i8* [[AP_ALIGN]] to <5 x i16>*
>  // CHECK: [[VEC:%.*]] = load <5 x i16>, <5 x i16>* [[AP_CAST]], align 8
> -// CHECK: store <5 x i16> [[VEC]], <5 x i16>* [[VAR_ALIGN]], align 16
> +// CHECK: store <5 x i16> [[VEC]], <5 x i16>* [[VAR_ALIGN]], align 8
>  // APCS-GNU: varargs_vec_5s
> -// APCS-GNU: [[VAR:%.*]] = alloca <5 x i16>, align 16
> +// APCS-GNU: [[VAR:%.*]] = alloca <5 x i16>, align 8
>  // APCS-GNU: [[AP:%.*]] = load i8*,
>  // APCS-GNU: [[AP_NEXT:%.*]] = getelementptr inbounds i8, i8* [[AP]], i32 16
>  // APCS-GNU: [[AP_CAST:%.*]] = bitcast i8* [[AP]] to <5 x i16>*
>
> Modified: cfe/trunk/test/CodeGen/arm-neon-misc.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-neon-misc.c?rev=304201=304200=304201=diff
> ==
> --- 

Re: r302750 - PR22877: When constructing an array via a constructor with a default argument

[Diana Picus via cfe-commits]

On 11 May 2017 at 21:14, Richard Smith  wrote:
> Thanks for the revert, fixed up and recommitted in r302817.
>
> Any idea why not a single buildbot sent me any email about this? :( (A
> couple of them were red at the previous change too, but some of them were
> not (eg. clang-cmake-armv7-a15).

Hm, I have no idea... @Renato, thoughts?

>
> On 11 May 2017 at 01:28, Diana Picus  wrote:
>>
>> Hexagon too:
>> http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/7916
>>
>> On 11 May 2017 at 10:27, Diana Picus  wrote:
>> > Hi Richard,
>> >
>> > I reverted this and its fixup in r302776 since some of the ARM bots
>> > were still broken:
>> > http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6969
>> > http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/6959
>> > http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/6717
>> >
>> > http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/1518
>> >
>> > Sorry,
>> > Diana
>> >
>> > On 11 May 2017 at 02:17, Richard Smith via cfe-commits
>> >  wrote:
>> >> Author: rsmith
>> >> Date: Wed May 10 19:17:17 2017
>> >> New Revision: 302750
>> >>
>> >> URL: http://llvm.org/viewvc/llvm-project?rev=302750=rev
>> >> Log:
>> >> PR22877: When constructing an array via a constructor with a default
>> >> argument
>> >> in list-initialization, run cleanups for the default argument after
>> >> each
>> >> iteration of the initialization loop.
>> >>
>> >> We previously only ran the destructor for any temporary once, at the
>> >> end of the
>> >> complete loop, rather than once per iteration!
>> >>
>> >> Added:
>> >> cfe/trunk/test/CodeGenCXX/array-default-argument.cpp
>> >> Modified:
>> >> cfe/trunk/lib/CodeGen/CGExprAgg.cpp
>> >>
>> >> Modified: cfe/trunk/lib/CodeGen/CGExprAgg.cpp
>> >> URL:
>> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprAgg.cpp?rev=302750=302749=302750=diff
>> >>
>> >> ==
>> >> --- cfe/trunk/lib/CodeGen/CGExprAgg.cpp (original)
>> >> +++ cfe/trunk/lib/CodeGen/CGExprAgg.cpp Wed May 10 19:17:17 2017
>> >> @@ -512,12 +512,20 @@ void AggExprEmitter::EmitArrayInit(Addre
>> >>  currentElement->addIncoming(element, entryBB);
>> >>
>> >>  // Emit the actual filler expression.
>> >> -LValue elementLV =
>> >> -  CGF.MakeAddrLValue(Address(currentElement, elementAlign),
>> >> elementType);
>> >> -if (filler)
>> >> -  EmitInitializationToLValue(filler, elementLV);
>> >> -else
>> >> -  EmitNullInitializationToLValue(elementLV);
>> >> +{
>> >> +  // C++1z [class.temporary]p5:
>> >> +  //   when a default constructor is called to initialize an
>> >> element of
>> >> +  //   an array with no corresponding initializer [...] the
>> >> destruction of
>> >> +  //   every temporary created in a default argument is sequenced
>> >> before
>> >> +  //   the construction of the next array element, if any
>> >> +  CodeGenFunction::RunCleanupsScope CleanupsScope(CGF);
>> >> +  LValue elementLV =
>> >> +CGF.MakeAddrLValue(Address(currentElement, elementAlign),
>> >> elementType);
>> >> +  if (filler)
>> >> +EmitInitializationToLValue(filler, elementLV);
>> >> +  else
>> >> +EmitNullInitializationToLValue(elementLV);
>> >> +}
>> >>
>> >>  // Move on to the next element.
>> >>  llvm::Value *nextElement =
>> >>
>> >> Added: cfe/trunk/test/CodeGenCXX/array-default-argument.cpp
>> >> URL:
>> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/array-default-argument.cpp?rev=302750=auto
>> >>
>> >> ==
>> >> --- cfe/trunk/test/CodeGenCXX/array-default-argument.cpp (added)
>> >> +++ cfe/trunk/test/CodeGenCXX/array-default-argument.cpp Wed May 10
>> >> 19:17:17 2017
>> >> @@ -0,0 +1,36 @@
>> >> +// RUN: %clang_cc1 -emit-llvm -o - %s -triple %itanium_abi_triple |
>> >> FileCheck %s
>> >> +// RUN: %clang_cc1 -emit-llvm -o - %s -triple %itanium_abi_triple
>> >> -fexceptions -fcxx-exceptions | FileCheck %s --check-prefix=CHECK
>> >> --check-prefix=CHECK-EH
>> >> +
>> >> +struct A {
>> >> +  A();
>> >> +  ~A();
>> >> +};
>> >> +
>> >> +struct B {
>> >> +  B(A = A());
>> >> +  ~B();
>> >> +};
>> >> +
>> >> +void f();
>> >> +// CHECK-LABEL: define void @_Z1gv()
>> >> +void g() {
>> >> +  // CHECK: br label %[[LOOP:.*]]
>> >> +
>> >> +  // [[LOOP]]:
>> >> +  // CHECK: {{call|invoke}} void @_ZN1AC1Ev([[TEMPORARY:.*]])
>> >> +  // CHECK-EH:  unwind label %[[PARTIAL_ARRAY_LPAD:.*]]
>> >> +  // CHECK: {{call|invoke}} void @_ZN1BC1E1A({{.*}}, [[TEMPORARY]])
>> >> +  // CHECK-EH:  unwind label %[[A_AND_PARTIAL_ARRAY_LPAD:.*]]
>> >> +  // CHECK: {{call|invoke}} void @_ZN1AD1Ev([[TEMPORARY]])
>> >> +  // CHECK-EH:  unwind label %[[PARTIAL_ARRAY_LPAD]]
>> >> +  // 

Re: r302750 - PR22877: When constructing an array via a constructor with a default argument

[Diana Picus via cfe-commits]

Hexagon too:
http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/7916

On 11 May 2017 at 10:27, Diana Picus  wrote:
> Hi Richard,
>
> I reverted this and its fixup in r302776 since some of the ARM bots
> were still broken:
> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6969
> http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/6959
> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/6717
> http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/1518
>
> Sorry,
> Diana
>
> On 11 May 2017 at 02:17, Richard Smith via cfe-commits
>  wrote:
>> Author: rsmith
>> Date: Wed May 10 19:17:17 2017
>> New Revision: 302750
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=302750=rev
>> Log:
>> PR22877: When constructing an array via a constructor with a default argument
>> in list-initialization, run cleanups for the default argument after each
>> iteration of the initialization loop.
>>
>> We previously only ran the destructor for any temporary once, at the end of 
>> the
>> complete loop, rather than once per iteration!
>>
>> Added:
>> cfe/trunk/test/CodeGenCXX/array-default-argument.cpp
>> Modified:
>> cfe/trunk/lib/CodeGen/CGExprAgg.cpp
>>
>> Modified: cfe/trunk/lib/CodeGen/CGExprAgg.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprAgg.cpp?rev=302750=302749=302750=diff
>> ==
>> --- cfe/trunk/lib/CodeGen/CGExprAgg.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGExprAgg.cpp Wed May 10 19:17:17 2017
>> @@ -512,12 +512,20 @@ void AggExprEmitter::EmitArrayInit(Addre
>>  currentElement->addIncoming(element, entryBB);
>>
>>  // Emit the actual filler expression.
>> -LValue elementLV =
>> -  CGF.MakeAddrLValue(Address(currentElement, elementAlign), 
>> elementType);
>> -if (filler)
>> -  EmitInitializationToLValue(filler, elementLV);
>> -else
>> -  EmitNullInitializationToLValue(elementLV);
>> +{
>> +  // C++1z [class.temporary]p5:
>> +  //   when a default constructor is called to initialize an element of
>> +  //   an array with no corresponding initializer [...] the destruction 
>> of
>> +  //   every temporary created in a default argument is sequenced before
>> +  //   the construction of the next array element, if any
>> +  CodeGenFunction::RunCleanupsScope CleanupsScope(CGF);
>> +  LValue elementLV =
>> +CGF.MakeAddrLValue(Address(currentElement, elementAlign), 
>> elementType);
>> +  if (filler)
>> +EmitInitializationToLValue(filler, elementLV);
>> +  else
>> +EmitNullInitializationToLValue(elementLV);
>> +}
>>
>>  // Move on to the next element.
>>  llvm::Value *nextElement =
>>
>> Added: cfe/trunk/test/CodeGenCXX/array-default-argument.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/array-default-argument.cpp?rev=302750=auto
>> ==
>> --- cfe/trunk/test/CodeGenCXX/array-default-argument.cpp (added)
>> +++ cfe/trunk/test/CodeGenCXX/array-default-argument.cpp Wed May 10 19:17:17 
>> 2017
>> @@ -0,0 +1,36 @@
>> +// RUN: %clang_cc1 -emit-llvm -o - %s -triple %itanium_abi_triple | 
>> FileCheck %s
>> +// RUN: %clang_cc1 -emit-llvm -o - %s -triple %itanium_abi_triple 
>> -fexceptions -fcxx-exceptions | FileCheck %s --check-prefix=CHECK 
>> --check-prefix=CHECK-EH
>> +
>> +struct A {
>> +  A();
>> +  ~A();
>> +};
>> +
>> +struct B {
>> +  B(A = A());
>> +  ~B();
>> +};
>> +
>> +void f();
>> +// CHECK-LABEL: define void @_Z1gv()
>> +void g() {
>> +  // CHECK: br label %[[LOOP:.*]]
>> +
>> +  // [[LOOP]]:
>> +  // CHECK: {{call|invoke}} void @_ZN1AC1Ev([[TEMPORARY:.*]])
>> +  // CHECK-EH:  unwind label %[[PARTIAL_ARRAY_LPAD:.*]]
>> +  // CHECK: {{call|invoke}} void @_ZN1BC1E1A({{.*}}, [[TEMPORARY]])
>> +  // CHECK-EH:  unwind label %[[A_AND_PARTIAL_ARRAY_LPAD:.*]]
>> +  // CHECK: {{call|invoke}} void @_ZN1AD1Ev([[TEMPORARY]])
>> +  // CHECK-EH:  unwind label %[[PARTIAL_ARRAY_LPAD]]
>> +  // CHECK: getelementptr {{.*}}, i{{[0-9]*}} 1
>> +  // CHECK: icmp eq
>> +  // CHECK: br i1 {{.*}} label %[[LOOP]]
>> +  B b[5];
>> +
>> +  // CHECK: {{call|invoke}} void @_Z1fv()
>> +  f();
>> +
>> +  // CHECK-NOT: @_ZN1AD1Ev(
>> +  // CHECK: {{call|invoke}} void @_ZN1BD1Ev(
>> +}
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r302750 - PR22877: When constructing an array via a constructor with a default argument

[Diana Picus via cfe-commits]

Hi Richard,

I reverted this and its fixup in r302776 since some of the ARM bots
were still broken:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6969
http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/6959
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/6717
http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/1518

Sorry,
Diana

On 11 May 2017 at 02:17, Richard Smith via cfe-commits
 wrote:
> Author: rsmith
> Date: Wed May 10 19:17:17 2017
> New Revision: 302750
>
> URL: http://llvm.org/viewvc/llvm-project?rev=302750=rev
> Log:
> PR22877: When constructing an array via a constructor with a default argument
> in list-initialization, run cleanups for the default argument after each
> iteration of the initialization loop.
>
> We previously only ran the destructor for any temporary once, at the end of 
> the
> complete loop, rather than once per iteration!
>
> Added:
> cfe/trunk/test/CodeGenCXX/array-default-argument.cpp
> Modified:
> cfe/trunk/lib/CodeGen/CGExprAgg.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGExprAgg.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprAgg.cpp?rev=302750=302749=302750=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGExprAgg.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGExprAgg.cpp Wed May 10 19:17:17 2017
> @@ -512,12 +512,20 @@ void AggExprEmitter::EmitArrayInit(Addre
>  currentElement->addIncoming(element, entryBB);
>
>  // Emit the actual filler expression.
> -LValue elementLV =
> -  CGF.MakeAddrLValue(Address(currentElement, elementAlign), elementType);
> -if (filler)
> -  EmitInitializationToLValue(filler, elementLV);
> -else
> -  EmitNullInitializationToLValue(elementLV);
> +{
> +  // C++1z [class.temporary]p5:
> +  //   when a default constructor is called to initialize an element of
> +  //   an array with no corresponding initializer [...] the destruction 
> of
> +  //   every temporary created in a default argument is sequenced before
> +  //   the construction of the next array element, if any
> +  CodeGenFunction::RunCleanupsScope CleanupsScope(CGF);
> +  LValue elementLV =
> +CGF.MakeAddrLValue(Address(currentElement, elementAlign), 
> elementType);
> +  if (filler)
> +EmitInitializationToLValue(filler, elementLV);
> +  else
> +EmitNullInitializationToLValue(elementLV);
> +}
>
>  // Move on to the next element.
>  llvm::Value *nextElement =
>
> Added: cfe/trunk/test/CodeGenCXX/array-default-argument.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/array-default-argument.cpp?rev=302750=auto
> ==
> --- cfe/trunk/test/CodeGenCXX/array-default-argument.cpp (added)
> +++ cfe/trunk/test/CodeGenCXX/array-default-argument.cpp Wed May 10 19:17:17 
> 2017
> @@ -0,0 +1,36 @@
> +// RUN: %clang_cc1 -emit-llvm -o - %s -triple %itanium_abi_triple | 
> FileCheck %s
> +// RUN: %clang_cc1 -emit-llvm -o - %s -triple %itanium_abi_triple 
> -fexceptions -fcxx-exceptions | FileCheck %s --check-prefix=CHECK 
> --check-prefix=CHECK-EH
> +
> +struct A {
> +  A();
> +  ~A();
> +};
> +
> +struct B {
> +  B(A = A());
> +  ~B();
> +};
> +
> +void f();
> +// CHECK-LABEL: define void @_Z1gv()
> +void g() {
> +  // CHECK: br label %[[LOOP:.*]]
> +
> +  // [[LOOP]]:
> +  // CHECK: {{call|invoke}} void @_ZN1AC1Ev([[TEMPORARY:.*]])
> +  // CHECK-EH:  unwind label %[[PARTIAL_ARRAY_LPAD:.*]]
> +  // CHECK: {{call|invoke}} void @_ZN1BC1E1A({{.*}}, [[TEMPORARY]])
> +  // CHECK-EH:  unwind label %[[A_AND_PARTIAL_ARRAY_LPAD:.*]]
> +  // CHECK: {{call|invoke}} void @_ZN1AD1Ev([[TEMPORARY]])
> +  // CHECK-EH:  unwind label %[[PARTIAL_ARRAY_LPAD]]
> +  // CHECK: getelementptr {{.*}}, i{{[0-9]*}} 1
> +  // CHECK: icmp eq
> +  // CHECK: br i1 {{.*}} label %[[LOOP]]
> +  B b[5];
> +
> +  // CHECK: {{call|invoke}} void @_Z1fv()
> +  f();
> +
> +  // CHECK-NOT: @_ZN1AD1Ev(
> +  // CHECK: {{call|invoke}} void @_ZN1BD1Ev(
> +}
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r302776 - Revert "PR22877: When constructing an array via a constructor with a default argument in list-initialization, run cleanups for the default argument after each iteration of the initialization

[Diana Picus via cfe-commits]

Author: rovka
Date: Thu May 11 03:10:41 2017
New Revision: 302776

URL: http://llvm.org/viewvc/llvm-project?rev=302776=rev
Log:
Revert "PR22877: When constructing an array via a constructor with a default 
argument in list-initialization, run cleanups for the default argument after 
each iteration of the initialization loop."

Revert "clang/test/CodeGenCXX/array-default-argument.cpp: Satisfy targets that 
have x86_thiscallcc."

This reverts commit r302750 and its fixup r302757 because the test is
still breaking on some of the ARM bots.

array-default-argument.cpp:20:12: error: expected string not found in input
 // CHECK: {{call|invoke}}[[THISCALL:( x86_thiscallcc)?]] void 
@_ZN1AC1Ev([[TEMPORARY:.*]])
   ^
:18:1: note: scanning from here
arrayctor.loop: ; preds = %arrayctor.loop, %entry
^
:28:2: note: possible intended match here
 call void @_Z1fv()
 ^

--

Removed:
cfe/trunk/test/CodeGenCXX/array-default-argument.cpp
Modified:
cfe/trunk/lib/CodeGen/CGExprAgg.cpp

Modified: cfe/trunk/lib/CodeGen/CGExprAgg.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprAgg.cpp?rev=302776=302775=302776=diff
==
--- cfe/trunk/lib/CodeGen/CGExprAgg.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExprAgg.cpp Thu May 11 03:10:41 2017
@@ -512,20 +512,12 @@ void AggExprEmitter::EmitArrayInit(Addre
 currentElement->addIncoming(element, entryBB);
 
 // Emit the actual filler expression.
-{
-  // C++1z [class.temporary]p5:
-  //   when a default constructor is called to initialize an element of
-  //   an array with no corresponding initializer [...] the destruction of
-  //   every temporary created in a default argument is sequenced before
-  //   the construction of the next array element, if any
-  CodeGenFunction::RunCleanupsScope CleanupsScope(CGF);
-  LValue elementLV =
-CGF.MakeAddrLValue(Address(currentElement, elementAlign), elementType);
-  if (filler)
-EmitInitializationToLValue(filler, elementLV);
-  else
-EmitNullInitializationToLValue(elementLV);
-}
+LValue elementLV =
+  CGF.MakeAddrLValue(Address(currentElement, elementAlign), elementType);
+if (filler)
+  EmitInitializationToLValue(filler, elementLV);
+else
+  EmitNullInitializationToLValue(elementLV);
 
 // Move on to the next element.
 llvm::Value *nextElement =

Removed: cfe/trunk/test/CodeGenCXX/array-default-argument.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/array-default-argument.cpp?rev=302775=auto
==
--- cfe/trunk/test/CodeGenCXX/array-default-argument.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/array-default-argument.cpp (removed)
@@ -1,36 +0,0 @@
-// RUN: %clang_cc1 -emit-llvm -o - %s -triple %itanium_abi_triple | FileCheck 
%s
-// RUN: %clang_cc1 -emit-llvm -o - %s -triple %itanium_abi_triple -fexceptions 
-fcxx-exceptions | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-EH
-
-struct A {
-  A();
-  ~A();
-};
-
-struct B {
-  B(A = A());
-  ~B();
-};
-
-void f();
-// CHECK-LABEL: define void @_Z1gv()
-void g() {
-  // CHECK: br label %[[LOOP:.*]]
-
-  // [[LOOP]]:
-  // CHECK: {{call|invoke}}[[THISCALL:( x86_thiscallcc)?]] void 
@_ZN1AC1Ev([[TEMPORARY:.*]])
-  // CHECK-EH:  unwind label %[[PARTIAL_ARRAY_LPAD:.*]]
-  // CHECK: {{call|invoke}}[[THISCALL]] void @_ZN1BC1E1A({{.*}}, [[TEMPORARY]])
-  // CHECK-EH:  unwind label %[[A_AND_PARTIAL_ARRAY_LPAD:.*]]
-  // CHECK: {{call|invoke}}[[THISCALL]] void @_ZN1AD1Ev([[TEMPORARY]])
-  // CHECK-EH:  unwind label %[[PARTIAL_ARRAY_LPAD]]
-  // CHECK: getelementptr {{.*}}, i{{[0-9]*}} 1
-  // CHECK: icmp eq
-  // CHECK: br i1 {{.*}} label %[[LOOP]]
-  B b[5];
-
-  // CHECK: {{call|invoke}} void @_Z1fv()
-  f();
-
-  // CHECK-NOT: @_ZN1AD1Ev(
-  // CHECK: {{call|invoke}}[[THISCALL]] void @_ZN1BD1Ev(
-}


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r294177 - [AVR] Allow specifying the CPU on the command line

[Diana Picus via cfe-commits]

Hi Dylan,

I reverted this in r294180 because I think it broke some of the
buildbots. See for example
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/3599
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/2271

Sorry,
Diana

On 6 February 2017 at 10:07, Dylan McKay via cfe-commits
 wrote:
> Author: dylanmckay
> Date: Mon Feb  6 03:07:56 2017
> New Revision: 294177
>
> URL: http://llvm.org/viewvc/llvm-project?rev=294177=rev
> Log:
> [AVR] Allow specifying the CPU on the command line
>
> Summary:
> This tells clang about all of the different AVR microcontrollers.
>
> It also adds code to define the correct preprocessor macros for each
> device.
>
> Reviewers: jroelofs, asl
>
> Reviewed By: asl
>
> Subscribers: asl, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D28346
>
> Added:
> cfe/trunk/test/CodeGen/avr/
> cfe/trunk/test/CodeGen/avr/target-cpu-defines/
> cfe/trunk/test/CodeGen/avr/target-cpu-defines/atmega328p.c
> cfe/trunk/test/CodeGen/avr/target-cpu-defines/attiny104.c
> cfe/trunk/test/CodeGen/avr/target-cpu-defines/common.c
> Modified:
> cfe/trunk/lib/Basic/Targets.cpp
>
> Modified: cfe/trunk/lib/Basic/Targets.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=294177=294176=294177=diff
> ==
> --- cfe/trunk/lib/Basic/Targets.cpp (original)
> +++ cfe/trunk/lib/Basic/Targets.cpp Mon Feb  6 03:07:56 2017
> @@ -8435,6 +8435,254 @@ public:
>}
>  };
>
> +/// Information about a specific microcontroller.
> +struct MCUInfo {
> +  const char *Name;
> +  const char *DefineName;
> +};
> +
> +// This list should be kept up-to-date with AVRDevices.td in LLVM.
> +static ArrayRef AVRMcus = {
> +  { "at90s1200", "__AVR_AT90S1200__" },
> +  { "attiny11", "__AVR_ATtiny11" },
> +  { "attiny12", "__AVR_ATtiny12" },
> +  { "attiny15", "__AVR_ATtiny15" },
> +  { "attiny28", "__AVR_ATtiny28" },
> +  { "at90s2313", "__AVR_AT90S2313" },
> +  { "at90s2323", "__AVR_AT90S2323" },
> +  { "at90s2333", "__AVR_AT90S2333" },
> +  { "at90s2343", "__AVR_AT90S2343" },
> +  { "attiny22", "__AVR_ATtiny22" },
> +  { "attiny26", "__AVR_ATtiny26" },
> +  { "at86rf401", "__AVR_AT86RF401" },
> +  { "at90s4414", "__AVR_AT90S4414" },
> +  { "at90s4433", "__AVR_AT90S4433" },
> +  { "at90s4434", "__AVR_AT90S4434" },
> +  { "at90s8515", "__AVR_AT90S8515" },
> +  { "at90c8534", "__AVR_AT90c8534" },
> +  { "at90s8535", "__AVR_AT90S8535" },
> +  { "ata5272", "__AVR_ATA5272" },
> +  { "attiny13", "__AVR_ATtiny13" },
> +  { "attiny13a", "__AVR_ATtiny13A" },
> +  { "attiny2313", "__AVR_ATtiny2313" },
> +  { "attiny2313a", "__AVR_ATtiny2313A" },
> +  { "attiny24", "__AVR_ATtiny24" },
> +  { "attiny24a", "__AVR_ATtiny24A" },
> +  { "attiny4313", "__AVR_ATtiny4313" },
> +  { "attiny44", "__AVR_ATtiny44" },
> +  { "attiny44a", "__AVR_ATtiny44A" },
> +  { "attiny84", "__AVR_ATtiny84" },
> +  { "attiny84a", "__AVR_ATtiny84A" },
> +  { "attiny25", "__AVR_ATtiny25" },
> +  { "attiny45", "__AVR_ATtiny45" },
> +  { "attiny85", "__AVR_ATtiny85" },
> +  { "attiny261", "__AVR_ATtiny261" },
> +  { "attiny261a", "__AVR_ATtiny261A" },
> +  { "attiny461", "__AVR_ATtiny461" },
> +  { "attiny461a", "__AVR_ATtiny461A" },
> +  { "attiny861", "__AVR_ATtiny861" },
> +  { "attiny861a", "__AVR_ATtiny861A" },
> +  { "attiny87", "__AVR_ATtiny87" },
> +  { "attiny43u", "__AVR_ATtiny43U" },
> +  { "attiny48", "__AVR_ATtiny48" },
> +  { "attiny88", "__AVR_ATtiny88" },
> +  { "attiny828", "__AVR_ATtiny828" },
> +  { "at43usb355", "__AVR_AT43USB355" },
> +  { "at76c711", "__AVR_AT76C711" },
> +  { "atmega103", "__AVR_ATmega103" },
> +  { "at43usb320", "__AVR_AT43USB320" },
> +  { "attiny167", "__AVR_ATtiny167" },
> +  { "at90usb82", "__AVR_AT90USB82" },
> +  { "at90usb162", "__AVR_AT90USB162" },
> +  { "ata5505", "__AVR_ATA5505" },
> +  { "atmega8u2", "__AVR_ATmega8U2" },
> +  { "atmega16u2", "__AVR_ATmega16U2" },
> +  { "atmega32u2", "__AVR_ATmega32U2" },
> +  { "attiny1634", "__AVR_ATtiny1634" },
> +  { "atmega8", "__AVR_ATmega8" },
> +  { "ata6289", "__AVR_ATA6289" },
> +  { "atmega8a", "__AVR_ATmega8A" },
> +  { "ata6285", "__AVR_ATA6285" },
> +  { "ata6286", "__AVR_ATA6286" },
> +  { "atmega48", "__AVR_ATmega48" },
> +  { "atmega48a", "__AVR_ATmega48A" },
> +  { "atmega48pa", "__AVR_ATmega48PA" },
> +  { "atmega48p", "__AVR_ATmega48P" },
> +  { "atmega88", "__AVR_ATmega88" },
> +  { "atmega88a", "__AVR_ATmega88A" },
> +  { "atmega88p", "__AVR_ATmega88P" },
> +  { "atmega88pa", "__AVR_ATmega88PA" },
> +  { "atmega8515", "__AVR_ATmega8515" },
> +  { "atmega8535", "__AVR_ATmega8535" },
> +  { "atmega8hva", "__AVR_ATmega8HVA" },
> +  { "at90pwm1", "__AVR_AT90PWM1" },
> +  { "at90pwm2", "__AVR_AT90PWM2" },
> +  { "at90pwm2b", "__AVR_AT90PWM2B" },
> +  { "at90pwm3", "__AVR_AT90PWM3" },
> +  { "at90pwm3b", "__AVR_AT90PWM3B" },
> +  { "at90pwm81", "__AVR_AT90PWM81" },
> +  { 

r294180 - Revert "[AVR] Allow specifying the CPU on the command line"

[Diana Picus via cfe-commits]

Author: rovka
Date: Mon Feb  6 05:35:42 2017
New Revision: 294180

URL: http://llvm.org/viewvc/llvm-project?rev=294180=rev
Log:
Revert "[AVR] Allow specifying the CPU on the command line"

This reverts commit r294177. It seems to have broken some buildbots.

Removed:
cfe/trunk/test/CodeGen/avr/target-cpu-defines/atmega328p.c
cfe/trunk/test/CodeGen/avr/target-cpu-defines/attiny104.c
cfe/trunk/test/CodeGen/avr/target-cpu-defines/common.c
Modified:
cfe/trunk/lib/Basic/Targets.cpp

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=294180=294179=294180=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Mon Feb  6 05:35:42 2017
@@ -8435,254 +8435,6 @@ public:
   }
 };
 
-/// Information about a specific microcontroller.
-struct MCUInfo {
-  const char *Name;
-  const char *DefineName;
-};
-
-// This list should be kept up-to-date with AVRDevices.td in LLVM.
-static ArrayRef AVRMcus = {
-  { "at90s1200", "__AVR_AT90S1200__" },
-  { "attiny11", "__AVR_ATtiny11" },
-  { "attiny12", "__AVR_ATtiny12" },
-  { "attiny15", "__AVR_ATtiny15" },
-  { "attiny28", "__AVR_ATtiny28" },
-  { "at90s2313", "__AVR_AT90S2313" },
-  { "at90s2323", "__AVR_AT90S2323" },
-  { "at90s2333", "__AVR_AT90S2333" },
-  { "at90s2343", "__AVR_AT90S2343" },
-  { "attiny22", "__AVR_ATtiny22" },
-  { "attiny26", "__AVR_ATtiny26" },
-  { "at86rf401", "__AVR_AT86RF401" },
-  { "at90s4414", "__AVR_AT90S4414" },
-  { "at90s4433", "__AVR_AT90S4433" },
-  { "at90s4434", "__AVR_AT90S4434" },
-  { "at90s8515", "__AVR_AT90S8515" },
-  { "at90c8534", "__AVR_AT90c8534" },
-  { "at90s8535", "__AVR_AT90S8535" },
-  { "ata5272", "__AVR_ATA5272" },
-  { "attiny13", "__AVR_ATtiny13" },
-  { "attiny13a", "__AVR_ATtiny13A" },
-  { "attiny2313", "__AVR_ATtiny2313" },
-  { "attiny2313a", "__AVR_ATtiny2313A" },
-  { "attiny24", "__AVR_ATtiny24" },
-  { "attiny24a", "__AVR_ATtiny24A" },
-  { "attiny4313", "__AVR_ATtiny4313" },
-  { "attiny44", "__AVR_ATtiny44" },
-  { "attiny44a", "__AVR_ATtiny44A" },
-  { "attiny84", "__AVR_ATtiny84" },
-  { "attiny84a", "__AVR_ATtiny84A" },
-  { "attiny25", "__AVR_ATtiny25" },
-  { "attiny45", "__AVR_ATtiny45" },
-  { "attiny85", "__AVR_ATtiny85" },
-  { "attiny261", "__AVR_ATtiny261" },
-  { "attiny261a", "__AVR_ATtiny261A" },
-  { "attiny461", "__AVR_ATtiny461" },
-  { "attiny461a", "__AVR_ATtiny461A" },
-  { "attiny861", "__AVR_ATtiny861" },
-  { "attiny861a", "__AVR_ATtiny861A" },
-  { "attiny87", "__AVR_ATtiny87" },
-  { "attiny43u", "__AVR_ATtiny43U" },
-  { "attiny48", "__AVR_ATtiny48" },
-  { "attiny88", "__AVR_ATtiny88" },
-  { "attiny828", "__AVR_ATtiny828" },
-  { "at43usb355", "__AVR_AT43USB355" },
-  { "at76c711", "__AVR_AT76C711" },
-  { "atmega103", "__AVR_ATmega103" },
-  { "at43usb320", "__AVR_AT43USB320" },
-  { "attiny167", "__AVR_ATtiny167" },
-  { "at90usb82", "__AVR_AT90USB82" },
-  { "at90usb162", "__AVR_AT90USB162" },
-  { "ata5505", "__AVR_ATA5505" },
-  { "atmega8u2", "__AVR_ATmega8U2" },
-  { "atmega16u2", "__AVR_ATmega16U2" },
-  { "atmega32u2", "__AVR_ATmega32U2" },
-  { "attiny1634", "__AVR_ATtiny1634" },
-  { "atmega8", "__AVR_ATmega8" },
-  { "ata6289", "__AVR_ATA6289" },
-  { "atmega8a", "__AVR_ATmega8A" },
-  { "ata6285", "__AVR_ATA6285" },
-  { "ata6286", "__AVR_ATA6286" },
-  { "atmega48", "__AVR_ATmega48" },
-  { "atmega48a", "__AVR_ATmega48A" },
-  { "atmega48pa", "__AVR_ATmega48PA" },
-  { "atmega48p", "__AVR_ATmega48P" },
-  { "atmega88", "__AVR_ATmega88" },
-  { "atmega88a", "__AVR_ATmega88A" },
-  { "atmega88p", "__AVR_ATmega88P" },
-  { "atmega88pa", "__AVR_ATmega88PA" },
-  { "atmega8515", "__AVR_ATmega8515" },
-  { "atmega8535", "__AVR_ATmega8535" },
-  { "atmega8hva", "__AVR_ATmega8HVA" },
-  { "at90pwm1", "__AVR_AT90PWM1" },
-  { "at90pwm2", "__AVR_AT90PWM2" },
-  { "at90pwm2b", "__AVR_AT90PWM2B" },
-  { "at90pwm3", "__AVR_AT90PWM3" },
-  { "at90pwm3b", "__AVR_AT90PWM3B" },
-  { "at90pwm81", "__AVR_AT90PWM81" },
-  { "ata5790", "__AVR_ATA5790" },
-  { "ata5795", "__AVR_ATA5795" },
-  { "atmega16", "__AVR_ATmega16" },
-  { "atmega16a", "__AVR_ATmega16A" },
-  { "atmega161", "__AVR_ATmega161" },
-  { "atmega162", "__AVR_ATmega162" },
-  { "atmega163", "__AVR_ATmega163" },
-  { "atmega164a", "__AVR_ATmega164A" },
-  { "atmega164p", "__AVR_ATmega164P" },
-  { "atmega164pa", "__AVR_ATmega164PA" },
-  { "atmega165", "__AVR_ATmega165" },
-  { "atmega165a", "__AVR_ATmega165A" },
-  { "atmega165p", "__AVR_ATmega165P" },
-  { "atmega165pa", "__AVR_ATmega165PA" },
-  { "atmega168", "__AVR_ATmega168" },
-  { "atmega168a", "__AVR_ATmega168A" },
-  { "atmega168p", "__AVR_ATmega168P" },
-  { "atmega168pa", "__AVR_ATmega168PA" },
-  { "atmega169", "__AVR_ATmega169" },
-  { "atmega169a", "__AVR_ATmega169A" },
-  { "atmega169p", "__AVR_ATmega169P" },
-  { "atmega169pa", "__AVR_ATmega169PA" },
-  { 

Re: [clang-tools-extra] r293217 - Implement a new clang-tidy check that suggests users replace dynamic exception specifications with noexcept exception specifications.

[Diana Picus via cfe-commits]

Hi Don, Hi Aaron,

I had to revert this in r293267 because all the clang-tools-extra
buildbots were still broken many hours after it was committed.
See for instance
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/1039

Eugene Zelenko also had some small fixes to
modernize-use-noexcept.rst, you might want to incorporate those as
well before recommitting (see r293234).

Regards,
Diana

On 27 January 2017 at 00:34, Aaron Ballman via cfe-commits
 wrote:
> Author: aaronballman
> Date: Thu Jan 26 16:34:24 2017
> New Revision: 293217
>
> URL: http://llvm.org/viewvc/llvm-project?rev=293217=rev
> Log:
> Implement a new clang-tidy check that suggests users replace dynamic 
> exception specifications with noexcept exception specifications.
>
> Patch by Don Hinton.
>
> Added:
> clang-tools-extra/trunk/clang-tidy/modernize/UseNoexceptCheck.cpp
> clang-tools-extra/trunk/clang-tidy/modernize/UseNoexceptCheck.h
> clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-noexcept.rst
> clang-tools-extra/trunk/test/clang-tidy/modernize-use-noexcept-macro.cpp
> clang-tools-extra/trunk/test/clang-tidy/modernize-use-noexcept-opt.cpp
> clang-tools-extra/trunk/test/clang-tidy/modernize-use-noexcept.cpp
> Modified:
> clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt
> clang-tools-extra/trunk/clang-tidy/modernize/ModernizeTidyModule.cpp
> clang-tools-extra/trunk/docs/ReleaseNotes.rst
> clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
>
> Modified: clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt?rev=293217=293216=293217=diff
> ==
> --- clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt (original)
> +++ clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt Thu Jan 26 
> 16:34:24 2017
> @@ -20,6 +20,7 @@ add_clang_library(clangTidyModernizeModu
>UseEmplaceCheck.cpp
>UseEqualsDefaultCheck.cpp
>UseEqualsDeleteCheck.cpp
> +  UseNoexceptCheck.cpp
>UseNullptrCheck.cpp
>UseOverrideCheck.cpp
>UseTransparentFunctorsCheck.cpp
>
> Modified: clang-tools-extra/trunk/clang-tidy/modernize/ModernizeTidyModule.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/ModernizeTidyModule.cpp?rev=293217=293216=293217=diff
> ==
> --- clang-tools-extra/trunk/clang-tidy/modernize/ModernizeTidyModule.cpp 
> (original)
> +++ clang-tools-extra/trunk/clang-tidy/modernize/ModernizeTidyModule.cpp Thu 
> Jan 26 16:34:24 2017
> @@ -26,6 +26,7 @@
>  #include "UseEmplaceCheck.h"
>  #include "UseEqualsDefaultCheck.h"
>  #include "UseEqualsDeleteCheck.h"
> +#include "UseNoexceptCheck.h"
>  #include "UseNullptrCheck.h"
>  #include "UseOverrideCheck.h"
>  #include "UseTransparentFunctorsCheck.h"
> @@ -63,6 +64,7 @@ public:
>  
> CheckFactories.registerCheck("modernize-use-equals-default");
>  CheckFactories.registerCheck(
>  "modernize-use-equals-delete");
> +CheckFactories.registerCheck("modernize-use-noexcept");
>  CheckFactories.registerCheck("modernize-use-nullptr");
>  CheckFactories.registerCheck("modernize-use-override");
>  CheckFactories.registerCheck(
>
> Added: clang-tools-extra/trunk/clang-tidy/modernize/UseNoexceptCheck.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/UseNoexceptCheck.cpp?rev=293217=auto
> ==
> --- clang-tools-extra/trunk/clang-tidy/modernize/UseNoexceptCheck.cpp (added)
> +++ clang-tools-extra/trunk/clang-tidy/modernize/UseNoexceptCheck.cpp Thu Jan 
> 26 16:34:24 2017
> @@ -0,0 +1,114 @@
> +//===--- UseNoexceptCheck.cpp - 
> clang-tidy-===//
> +//
> +// The LLVM Compiler Infrastructure
> +//
> +// This file is distributed under the University of Illinois Open Source
> +// License. See LICENSE.TXT for details.
> +//
> +//===--===//
> +
> +#include "UseNoexceptCheck.h"
> +#include "clang/AST/ASTContext.h"
> +#include "clang/Lex/Lexer.h"
> +
> +using namespace clang::ast_matchers;
> +
> +namespace clang {
> +namespace tidy {
> +namespace modernize {
> +
> +UseNoexceptCheck::UseNoexceptCheck(StringRef Name, ClangTidyContext *Context)
> +: ClangTidyCheck(Name, Context),
> +  NoexceptMacro(Options.get("ReplacementString", "")),
> +  UseNoexceptFalse(Options.get("UseNoexceptFalse", true)) {}
> +
> +void UseNoexceptCheck::storeOptions(ClangTidyOptions::OptionMap ) {
> +  Options.store(Opts, "ReplacementString", NoexceptMacro);
> +  Options.store(Opts, "UseNoexceptFalse", UseNoexceptFalse);
> +}
> +
> +void 

[clang-tools-extra] r293267 - Revert "Implement a new clang-tidy check that suggests users replace dynamic exception specifications with noexcept exception specifications."

[Diana Picus via cfe-commits]

Author: rovka
Date: Fri Jan 27 01:19:22 2017
New Revision: 293267

URL: http://llvm.org/viewvc/llvm-project?rev=293267=rev
Log:
Revert "Implement a new clang-tidy check that suggests users replace dynamic 
exception specifications with noexcept exception specifications."

This reverts commit r293217, its follow-up 293218 and part of 293234 because it
broke all bots that build clang-tools-extra.

Removed:
clang-tools-extra/trunk/clang-tidy/modernize/UseNoexceptCheck.cpp
clang-tools-extra/trunk/clang-tidy/modernize/UseNoexceptCheck.h
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-noexcept.rst
clang-tools-extra/trunk/test/clang-tidy/modernize-use-noexcept-macro.cpp
clang-tools-extra/trunk/test/clang-tidy/modernize-use-noexcept-opt.cpp
clang-tools-extra/trunk/test/clang-tidy/modernize-use-noexcept.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/modernize/ModernizeTidyModule.cpp
clang-tools-extra/trunk/docs/ReleaseNotes.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt?rev=293267=293266=293267=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt Fri Jan 27 
01:19:22 2017
@@ -20,7 +20,6 @@ add_clang_library(clangTidyModernizeModu
   UseEmplaceCheck.cpp
   UseEqualsDefaultCheck.cpp
   UseEqualsDeleteCheck.cpp
-  UseNoexceptCheck.cpp
   UseNullptrCheck.cpp
   UseOverrideCheck.cpp
   UseTransparentFunctorsCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/modernize/ModernizeTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/ModernizeTidyModule.cpp?rev=293267=293266=293267=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/ModernizeTidyModule.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/ModernizeTidyModule.cpp Fri 
Jan 27 01:19:22 2017
@@ -26,7 +26,6 @@
 #include "UseEmplaceCheck.h"
 #include "UseEqualsDefaultCheck.h"
 #include "UseEqualsDeleteCheck.h"
-#include "UseNoexceptCheck.h"
 #include "UseNullptrCheck.h"
 #include "UseOverrideCheck.h"
 #include "UseTransparentFunctorsCheck.h"
@@ -64,7 +63,6 @@ public:
 
CheckFactories.registerCheck("modernize-use-equals-default");
 CheckFactories.registerCheck(
 "modernize-use-equals-delete");
-CheckFactories.registerCheck("modernize-use-noexcept");
 CheckFactories.registerCheck("modernize-use-nullptr");
 CheckFactories.registerCheck("modernize-use-override");
 CheckFactories.registerCheck(

Removed: clang-tools-extra/trunk/clang-tidy/modernize/UseNoexceptCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/UseNoexceptCheck.cpp?rev=293266=auto
==
--- clang-tools-extra/trunk/clang-tidy/modernize/UseNoexceptCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/UseNoexceptCheck.cpp (removed)
@@ -1,114 +0,0 @@
-//===--- UseNoexceptCheck.cpp - 
clang-tidy-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-
-#include "UseNoexceptCheck.h"
-#include "clang/AST/ASTContext.h"
-#include "clang/Lex/Lexer.h"
-
-using namespace clang::ast_matchers;
-
-namespace clang {
-namespace tidy {
-namespace modernize {
-
-UseNoexceptCheck::UseNoexceptCheck(StringRef Name, ClangTidyContext *Context)
-: ClangTidyCheck(Name, Context),
-  NoexceptMacro(Options.get("ReplacementString", "")),
-  UseNoexceptFalse(Options.get("UseNoexceptFalse", true)) {}
-
-void UseNoexceptCheck::storeOptions(ClangTidyOptions::OptionMap ) {
-  Options.store(Opts, "ReplacementString", NoexceptMacro);
-  Options.store(Opts, "UseNoexceptFalse", UseNoexceptFalse);
-}
-
-void UseNoexceptCheck::registerMatchers(MatchFinder *Finder) {
-  if (!getLangOpts().CPlusPlus11)
-return;
-
-  Finder->addMatcher(
-  functionDecl(
-  cxxMethodDecl(
-  hasTypeLoc(loc(functionProtoType(hasDynamicExceptionSpec(,
-  anyOf(hasOverloadedOperatorName("delete[]"),
-hasOverloadedOperatorName("delete"), cxxDestructorDecl()))
-  .bind("del-dtor"))
-  .bind("funcDecl"),
-  this);
-
-  Finder->addMatcher(
-  functionDecl(
-  hasTypeLoc(loc(functionProtoType(hasDynamicExceptionSpec(,
-  

Re: r293004 - Use filename in linemarker when compiling preprocessed source

[Diana Picus via cfe-commits]

Erm, the revert was actually r293032, sorry about the confusion.

On 25 January 2017 at 09:34, Diana Picus  wrote:
> Hi David,
>
> Sorry, but I had to revert this (r283029) because it was breaking the
> non-x86 buildbots (arm, powerpc, hexagon), with errors along the lines
> of:
> error: unknown target CPU 'cortex-a8'
>
> Please recommit after you've fixed the issue.
>
> Thanks,
> Diana
>
> PS: I tried to fix it in r293024, but that broke on Green Dragon. I'll
> let you come up with a more principled fix.
>
> On 25 January 2017 at 03:55, David Callahan via cfe-commits
>  wrote:
>> Author: david2050
>> Date: Tue Jan 24 19:55:28 2017
>> New Revision: 293004
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=293004=rev
>> Log:
>> Use filename in linemarker when compiling preprocessed source
>>
>> Summary:
>> Clang appears to always use name as specified on the command
>> line, whereas gcc uses the name as specified in the linemarker at the
>> first line when compiling a preprocessed source. This results mismatch
>> between two compilers in FILE symbol table entry. This patch makes clang
>> to resemble gcc's behavior in finding the original source file name and
>> use it as an input file name.
>>
>> Even with this patch, values of FILE symbol table entry may still be
>> different because clang uses dirname+basename for the entry whlie gcc
>> uses basename only. I'll write a patch for that once this patch is
>> committed.
>>
>> Reviewers: dblaikie, inglorion
>>
>> Reviewed By: inglorion
>>
>> Subscribers: inglorion, aprantl, bruno
>>
>> Differential Revision: https://reviews.llvm.org/D28796
>>
>> Added:
>> cfe/trunk/test/Frontend/preprocessed-input.c
>> Modified:
>> cfe/trunk/include/clang/Frontend/FrontendOptions.h
>> cfe/trunk/lib/Frontend/FrontendAction.cpp
>>
>> Modified: cfe/trunk/include/clang/Frontend/FrontendOptions.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/FrontendOptions.h?rev=293004=293003=293004=diff
>> ==
>> --- cfe/trunk/include/clang/Frontend/FrontendOptions.h (original)
>> +++ cfe/trunk/include/clang/Frontend/FrontendOptions.h Tue Jan 24 19:55:28 
>> 2017
>> @@ -81,7 +81,7 @@ enum InputKind {
>>IK_LLVM_IR
>>  };
>>
>> -
>> +
>>  /// \brief An input file for the front end.
>>  class FrontendInputFile {
>>/// \brief The file name, or "-" to read from standard input.
>> @@ -109,6 +109,13 @@ public:
>>bool isEmpty() const { return File.empty() && Buffer == nullptr; }
>>bool isFile() const { return !isBuffer(); }
>>bool isBuffer() const { return Buffer != nullptr; }
>> +  bool isPreprocessed() const {
>> +return Kind == IK_PreprocessedC ||
>> +   Kind == IK_PreprocessedCXX ||
>> +   Kind == IK_PreprocessedObjC ||
>> +   Kind == IK_PreprocessedObjCXX ||
>> +   Kind == IK_PreprocessedCuda;
>> +  }
>>
>>StringRef getFile() const {
>>  assert(isFile());
>>
>> Modified: cfe/trunk/lib/Frontend/FrontendAction.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/FrontendAction.cpp?rev=293004=293003=293004=diff
>> ==
>> --- cfe/trunk/lib/Frontend/FrontendAction.cpp (original)
>> +++ cfe/trunk/lib/Frontend/FrontendAction.cpp Tue Jan 24 19:55:28 2017
>> @@ -19,6 +19,7 @@
>>  #include "clang/Frontend/MultiplexConsumer.h"
>>  #include "clang/Frontend/Utils.h"
>>  #include "clang/Lex/HeaderSearch.h"
>> +#include "clang/Lex/LiteralSupport.h"
>>  #include "clang/Lex/Preprocessor.h"
>>  #include "clang/Lex/PreprocessorOptions.h"
>>  #include "clang/Parse/ParseAST.h"
>> @@ -187,6 +188,42 @@ FrontendAction::CreateWrappedASTConsumer
>>return llvm::make_unique(std::move(Consumers));
>>  }
>>
>> +// For preprocessed files, if the first line is the linemarker and specifies
>> +// the original source file name, use that name as the input file name.
>> +static bool ReadOriginalFileName(CompilerInstance , std::string 
>> )
>> +{
>> +  bool Invalid = false;
>> +  auto  = CI.getSourceManager();
>> +  auto MainFileID = SourceMgr.getMainFileID();
>> +  const auto *MainFileBuf = SourceMgr.getBuffer(MainFileID, );
>> +  if (Invalid)
>> +return false;
>> +
>> +  std::unique_ptr RawLexer(
>> +  new Lexer(MainFileID, MainFileBuf, SourceMgr, CI.getLangOpts()));
>> +
>> +  // If the first line has the syntax of
>> +  //
>> +  // # NUM "FILENAME"
>> +  //
>> +  // we use FILENAME as the input file name.
>> +  Token T;
>> +  if (RawLexer->LexFromRawLexer(T) || T.getKind() != tok::hash)
>> +return false;
>> +  if (RawLexer->LexFromRawLexer(T) || T.isAtStartOfLine() ||
>> +  T.getKind() != tok::numeric_constant)
>> +return false;
>> +  RawLexer->LexFromRawLexer(T);
>> +  if (T.isAtStartOfLine() || T.getKind() != tok::string_literal)
>> +return false;
>> +
>> +  

r293032 - Revert "Use filename in linemarker when compiling preprocessed source"

[Diana Picus via cfe-commits]

Author: rovka
Date: Wed Jan 25 01:27:05 2017
New Revision: 293032

URL: http://llvm.org/viewvc/llvm-project?rev=293032=rev
Log:
Revert "Use filename in linemarker when compiling preprocessed source"

This reverts commit r293004 because it broke the buildbots with "unknown CPU"
errors. I tried to fix it in r293026, but that broke on Green Dragon with this
kind of error:

error: expected string not found in input
// CHECK: l{{ +}}df{{ +}}*ABS*{{ +}}{{0+}}{{.+}}preprocessed-input.c{{$}}
  ^
:2:1: note: scanning from here
/Users/buildslave/jenkins/sharedspace/incremental@2/clang-build/tools/clang/test/Frontend/Output/preprocessed-input.c.tmp.o:
 file format Mach-O 64-bit x86-64
^
:2:67: note: possible intended match here
/Users/buildslave/jenkins/sharedspace/incremental@2/clang-build/tools/clang/test/Frontend/Output/preprocessed-input.c.tmp.o:
 file format Mach-O 64-bit x86-64

I suppose this means that llvm-objdump doesn't support Mach-O, so the test
should indeed check for linux (but not for x86). I'll leave it to someone that
knows better.

Removed:
cfe/trunk/test/Frontend/preprocessed-input.c
Modified:
cfe/trunk/include/clang/Frontend/FrontendOptions.h
cfe/trunk/lib/Frontend/FrontendAction.cpp

Modified: cfe/trunk/include/clang/Frontend/FrontendOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/FrontendOptions.h?rev=293032=293031=293032=diff
==
--- cfe/trunk/include/clang/Frontend/FrontendOptions.h (original)
+++ cfe/trunk/include/clang/Frontend/FrontendOptions.h Wed Jan 25 01:27:05 2017
@@ -81,7 +81,7 @@ enum InputKind {
   IK_LLVM_IR
 };
 
-
+  
 /// \brief An input file for the front end.
 class FrontendInputFile {
   /// \brief The file name, or "-" to read from standard input.
@@ -109,13 +109,6 @@ public:
   bool isEmpty() const { return File.empty() && Buffer == nullptr; }
   bool isFile() const { return !isBuffer(); }
   bool isBuffer() const { return Buffer != nullptr; }
-  bool isPreprocessed() const {
-return Kind == IK_PreprocessedC ||
-   Kind == IK_PreprocessedCXX ||
-   Kind == IK_PreprocessedObjC ||
-   Kind == IK_PreprocessedObjCXX ||
-   Kind == IK_PreprocessedCuda;
-  }
 
   StringRef getFile() const {
 assert(isFile());

Modified: cfe/trunk/lib/Frontend/FrontendAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/FrontendAction.cpp?rev=293032=293031=293032=diff
==
--- cfe/trunk/lib/Frontend/FrontendAction.cpp (original)
+++ cfe/trunk/lib/Frontend/FrontendAction.cpp Wed Jan 25 01:27:05 2017
@@ -19,7 +19,6 @@
 #include "clang/Frontend/MultiplexConsumer.h"
 #include "clang/Frontend/Utils.h"
 #include "clang/Lex/HeaderSearch.h"
-#include "clang/Lex/LiteralSupport.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Lex/PreprocessorOptions.h"
 #include "clang/Parse/ParseAST.h"
@@ -188,42 +187,6 @@ FrontendAction::CreateWrappedASTConsumer
   return llvm::make_unique(std::move(Consumers));
 }
 
-// For preprocessed files, if the first line is the linemarker and specifies
-// the original source file name, use that name as the input file name.
-static bool ReadOriginalFileName(CompilerInstance , std::string )
-{
-  bool Invalid = false;
-  auto  = CI.getSourceManager();
-  auto MainFileID = SourceMgr.getMainFileID();
-  const auto *MainFileBuf = SourceMgr.getBuffer(MainFileID, );
-  if (Invalid)
-return false;
-
-  std::unique_ptr RawLexer(
-  new Lexer(MainFileID, MainFileBuf, SourceMgr, CI.getLangOpts()));
-
-  // If the first line has the syntax of
-  //
-  // # NUM "FILENAME"
-  //
-  // we use FILENAME as the input file name.
-  Token T;
-  if (RawLexer->LexFromRawLexer(T) || T.getKind() != tok::hash)
-return false;
-  if (RawLexer->LexFromRawLexer(T) || T.isAtStartOfLine() ||
-  T.getKind() != tok::numeric_constant)
-return false;
-  RawLexer->LexFromRawLexer(T);
-  if (T.isAtStartOfLine() || T.getKind() != tok::string_literal)
-return false;
-
-  StringLiteralParser Literal(T, CI.getPreprocessor());
-  if (Literal.hadError)
-return false;
-  InputFile = Literal.GetString().str();
-  return true;
-}
-
 bool FrontendAction::BeginSourceFile(CompilerInstance ,
  const FrontendInputFile ) {
   assert(!Instance && "Already processing a source file!");
@@ -372,13 +335,6 @@ bool FrontendAction::BeginSourceFile(Com
 if (!isModelParsingAction())
   CI.createASTContext();
 
-// For preprocessed files, check if the first line specifies the original
-// source file name with a linemarker.
-std::string OrigFile;
-if (Input.isPreprocessed())
-  if (ReadOriginalFileName(CI, OrigFile))
-InputFile = OrigFile;
-
 std::unique_ptr Consumer =
 CreateWrappedASTConsumer(CI, InputFile);
 if (!Consumer)
@@ -465,9 +421,9 @@ bool 

Re: r293004 - Use filename in linemarker when compiling preprocessed source

[Diana Picus via cfe-commits]

Hi David,

Sorry, but I had to revert this (r283029) because it was breaking the
non-x86 buildbots (arm, powerpc, hexagon), with errors along the lines
of:
error: unknown target CPU 'cortex-a8'

Please recommit after you've fixed the issue.

Thanks,
Diana

PS: I tried to fix it in r293024, but that broke on Green Dragon. I'll
let you come up with a more principled fix.

On 25 January 2017 at 03:55, David Callahan via cfe-commits
 wrote:
> Author: david2050
> Date: Tue Jan 24 19:55:28 2017
> New Revision: 293004
>
> URL: http://llvm.org/viewvc/llvm-project?rev=293004=rev
> Log:
> Use filename in linemarker when compiling preprocessed source
>
> Summary:
> Clang appears to always use name as specified on the command
> line, whereas gcc uses the name as specified in the linemarker at the
> first line when compiling a preprocessed source. This results mismatch
> between two compilers in FILE symbol table entry. This patch makes clang
> to resemble gcc's behavior in finding the original source file name and
> use it as an input file name.
>
> Even with this patch, values of FILE symbol table entry may still be
> different because clang uses dirname+basename for the entry whlie gcc
> uses basename only. I'll write a patch for that once this patch is
> committed.
>
> Reviewers: dblaikie, inglorion
>
> Reviewed By: inglorion
>
> Subscribers: inglorion, aprantl, bruno
>
> Differential Revision: https://reviews.llvm.org/D28796
>
> Added:
> cfe/trunk/test/Frontend/preprocessed-input.c
> Modified:
> cfe/trunk/include/clang/Frontend/FrontendOptions.h
> cfe/trunk/lib/Frontend/FrontendAction.cpp
>
> Modified: cfe/trunk/include/clang/Frontend/FrontendOptions.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/FrontendOptions.h?rev=293004=293003=293004=diff
> ==
> --- cfe/trunk/include/clang/Frontend/FrontendOptions.h (original)
> +++ cfe/trunk/include/clang/Frontend/FrontendOptions.h Tue Jan 24 19:55:28 
> 2017
> @@ -81,7 +81,7 @@ enum InputKind {
>IK_LLVM_IR
>  };
>
> -
> +
>  /// \brief An input file for the front end.
>  class FrontendInputFile {
>/// \brief The file name, or "-" to read from standard input.
> @@ -109,6 +109,13 @@ public:
>bool isEmpty() const { return File.empty() && Buffer == nullptr; }
>bool isFile() const { return !isBuffer(); }
>bool isBuffer() const { return Buffer != nullptr; }
> +  bool isPreprocessed() const {
> +return Kind == IK_PreprocessedC ||
> +   Kind == IK_PreprocessedCXX ||
> +   Kind == IK_PreprocessedObjC ||
> +   Kind == IK_PreprocessedObjCXX ||
> +   Kind == IK_PreprocessedCuda;
> +  }
>
>StringRef getFile() const {
>  assert(isFile());
>
> Modified: cfe/trunk/lib/Frontend/FrontendAction.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/FrontendAction.cpp?rev=293004=293003=293004=diff
> ==
> --- cfe/trunk/lib/Frontend/FrontendAction.cpp (original)
> +++ cfe/trunk/lib/Frontend/FrontendAction.cpp Tue Jan 24 19:55:28 2017
> @@ -19,6 +19,7 @@
>  #include "clang/Frontend/MultiplexConsumer.h"
>  #include "clang/Frontend/Utils.h"
>  #include "clang/Lex/HeaderSearch.h"
> +#include "clang/Lex/LiteralSupport.h"
>  #include "clang/Lex/Preprocessor.h"
>  #include "clang/Lex/PreprocessorOptions.h"
>  #include "clang/Parse/ParseAST.h"
> @@ -187,6 +188,42 @@ FrontendAction::CreateWrappedASTConsumer
>return llvm::make_unique(std::move(Consumers));
>  }
>
> +// For preprocessed files, if the first line is the linemarker and specifies
> +// the original source file name, use that name as the input file name.
> +static bool ReadOriginalFileName(CompilerInstance , std::string 
> )
> +{
> +  bool Invalid = false;
> +  auto  = CI.getSourceManager();
> +  auto MainFileID = SourceMgr.getMainFileID();
> +  const auto *MainFileBuf = SourceMgr.getBuffer(MainFileID, );
> +  if (Invalid)
> +return false;
> +
> +  std::unique_ptr RawLexer(
> +  new Lexer(MainFileID, MainFileBuf, SourceMgr, CI.getLangOpts()));
> +
> +  // If the first line has the syntax of
> +  //
> +  // # NUM "FILENAME"
> +  //
> +  // we use FILENAME as the input file name.
> +  Token T;
> +  if (RawLexer->LexFromRawLexer(T) || T.getKind() != tok::hash)
> +return false;
> +  if (RawLexer->LexFromRawLexer(T) || T.isAtStartOfLine() ||
> +  T.getKind() != tok::numeric_constant)
> +return false;
> +  RawLexer->LexFromRawLexer(T);
> +  if (T.isAtStartOfLine() || T.getKind() != tok::string_literal)
> +return false;
> +
> +  StringLiteralParser Literal(T, CI.getPreprocessor());
> +  if (Literal.hadError)
> +return false;
> +  InputFile = Literal.GetString().str();
> +  return true;
> +}
> +
>  bool FrontendAction::BeginSourceFile(CompilerInstance ,
>   const FrontendInputFile ) 

r293026 - Try to fix test from r293004

[Diana Picus via cfe-commits]

Author: rovka
Date: Wed Jan 25 00:23:50 2017
New Revision: 293026

URL: http://llvm.org/viewvc/llvm-project?rev=293026=rev
Log:
Try to fix test from r293004

This test broke on a lot of non-x86 buildbots with "unknowm CPU" errors. I don't
see anything platform-specific about this test, and it seems to work fine on ARM
if we just remove the -triple i686 flags from the run line.

Modified:
cfe/trunk/test/Frontend/preprocessed-input.c

Modified: cfe/trunk/test/Frontend/preprocessed-input.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/preprocessed-input.c?rev=293026=293025=293026=diff
==
--- cfe/trunk/test/Frontend/preprocessed-input.c (original)
+++ cfe/trunk/test/Frontend/preprocessed-input.c Wed Jan 25 00:23:50 2017
@@ -1,4 +1,4 @@
 // RUN: %clang -E -o %t.i %s
-// RUN: %clang -Xclang -triple -Xclang i686-linux-gnu -c -o %t.o %t.i
+// RUN: %clang -c -o %t.o %t.i
 // RUN: llvm-objdump -t %t.o | FileCheck %s
 // CHECK: l{{ +}}df{{ +}}*ABS*{{ +}}{{0+}}{{.+}}preprocessed-input.c{{$}}


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r286098 - [OPENMP] Fixed capturing of VLA variables.

[Diana Picus via cfe-commits]

Hi Alexey,

If it is not a simple, quick fix that you can do, it is customary to revert
so the buildbots become green again. Otherwise, if people commit other
things that break the build they will not get emails and it will be much
harder to fix the whole thing.

I'll revert this for you and you can commit the fixed version later on,
when it's ready.

Thanks,
Diana

On 7 November 2016 at 11:54, Alexey Bataev  wrote:

> Hi Diana, will fix it in couple hours.
>
> Best regards,
> Alexey Bataev
>
> 7 нояб. 2016 г., в 12:38, Diana Picus  написал(а):
>
> Hi,
>
> This has been breaking the bots for almost an hour. Can you fix/revert?
>
> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/304
> http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/657
> http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/347
>
> Thanks,
> Diana
>
> On 7 November 2016 at 10:07, Alexey Bataev via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: abataev
>> Date: Mon Nov  7 02:07:25 2016
>> New Revision: 286098
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=286098=rev
>> Log:
>> [OPENMP] Fixed capturing of VLA variables.
>>
>> After some changes in codegen capturing of VLA variables in OpenMP
>> regions was broken, causing compiler crash. Patch fixes this issue.
>>
>> Modified:
>> cfe/trunk/lib/CodeGen/CGExpr.cpp
>> cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
>> cfe/trunk/test/OpenMP/parallel_codegen.cpp
>>
>> Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CG
>> Expr.cpp?rev=286098=286097=286098=diff
>> 
>> ==
>> --- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGExpr.cpp Mon Nov  7 02:07:25 2016
>> @@ -2127,12 +2127,11 @@ LValue CodeGenFunction::EmitDeclRefLValu
>>if (auto *FD = LambdaCaptureFields.lookup(VD))
>>  return EmitCapturedFieldLValue(*this, FD, CXXABIThisValue);
>>else if (CapturedStmtInfo) {
>> -auto it = LocalDeclMap.find(VD);
>> -if (it != LocalDeclMap.end()) {
>> -  if (auto RefTy = VD->getType()->getAs()) {
>> -return EmitLoadOfReferenceLValue(it->second, RefTy);
>> -  }
>> -  return MakeAddrLValue(it->second, T);
>> +auto I = LocalDeclMap.find(VD);
>> +if (I != LocalDeclMap.end()) {
>> +  if (auto RefTy = VD->getType()->getAs())
>> +return EmitLoadOfReferenceLValue(I->second, RefTy);
>> +  return MakeAddrLValue(I->second, T);
>>  }
>>  LValue CapLVal =
>>  EmitCapturedFieldLValue(*this, CapturedStmtInfo->lookup(VD),
>>
>> Modified: cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CG
>> StmtOpenMP.cpp?rev=286098=286097=286098=diff
>> 
>> ==
>> --- cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp Mon Nov  7 02:07:25 2016
>> @@ -307,7 +307,7 @@ CodeGenFunction::GenerateOpenMPCapturedS
>>  if (ArgLVal.getType()->isLValueReferenceType()) {
>>ArgAddr = EmitLoadOfReference(
>>ArgAddr, ArgLVal.getType()->castAs());
>> -} else {
>> +} else if (!VarTy->isVariablyModifiedType() ||
>> !VarTy->isPointerType()) {
>>assert(ArgLVal.getType()->isPointerType());
>>ArgAddr = EmitLoadOfPointer(
>>ArgAddr, ArgLVal.getType()->castAs());
>>
>> Modified: cfe/trunk/test/OpenMP/parallel_codegen.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/pa
>> rallel_codegen.cpp?rev=286098=286097=286098=diff
>> 
>> ==
>> --- cfe/trunk/test/OpenMP/parallel_codegen.cpp (original)
>> +++ cfe/trunk/test/OpenMP/parallel_codegen.cpp Mon Nov  7 02:07:25 2016
>> @@ -10,7 +10,7 @@
>>  // CHECK-DEBUG-DAG: %ident_t = type { i32, i32, i32, i32, i8* }
>>  // CHECK-DEBUG-DAG: [[STR:@.+]] = private unnamed_addr constant [23 x
>> i8] c";unknown;unknown;0;0;;\00"
>>  // CHECK-DEBUG-DAG: [[DEF_LOC_2:@.+]] = private unnamed_addr constant
>> %ident_t { i32 0, i32 2, i32 0, i32 0, i8* getelementptr inbounds ([23 x
>> i8], [23 x i8]* [[STR]], i32 0, i32 0) }
>> -// CHECK-DEBUG-DAG: [[LOC1:@.+]] = private unnamed_addr constant
>> [{{.+}} x i8] c";{{.*}}parallel_codegen.cpp;main;[[@LINE+14]];9;;\00"
>> +// CHECK-DEBUG-DAG: [[LOC1:@.+]] = private unnamed_addr constant
>> [{{.+}} x i8] c";{{.*}}parallel_codegen.cpp;main;[[@LINE+15]];9;;\00"
>>  // CHECK-DEBUG-DAG: [[LOC2:@.+]] = private unnamed_addr constant
>> [{{.+}} x i8] c";{{.*}}parallel_codegen.cpp;tmain;[[@LINE+7]];9;;\00"
>>
>>  template 
>> @@ -24,17 +24,19 @@ int tmain(T argc) {
>>  }
>>
>>  int main (int argc, char **argv) {
>> +  int a[argc];
>> 

r286102 - Revert "[OPENMP] Fixed capturing of VLA variables."

[Diana Picus via cfe-commits]

Author: rovka
Date: Mon Nov  7 04:01:43 2016
New Revision: 286102

URL: http://llvm.org/viewvc/llvm-project?rev=286102=rev
Log:
Revert "[OPENMP] Fixed capturing of VLA variables."

This reverts commit r286098 because the modified test breaks on many of the
buildbots.

Modified:
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/test/OpenMP/parallel_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=286102=286101=286102=diff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Mon Nov  7 04:01:43 2016
@@ -2127,11 +2127,12 @@ LValue CodeGenFunction::EmitDeclRefLValu
   if (auto *FD = LambdaCaptureFields.lookup(VD))
 return EmitCapturedFieldLValue(*this, FD, CXXABIThisValue);
   else if (CapturedStmtInfo) {
-auto I = LocalDeclMap.find(VD);
-if (I != LocalDeclMap.end()) {
-  if (auto RefTy = VD->getType()->getAs())
-return EmitLoadOfReferenceLValue(I->second, RefTy);
-  return MakeAddrLValue(I->second, T);
+auto it = LocalDeclMap.find(VD);
+if (it != LocalDeclMap.end()) {
+  if (auto RefTy = VD->getType()->getAs()) {
+return EmitLoadOfReferenceLValue(it->second, RefTy);
+  }
+  return MakeAddrLValue(it->second, T);
 }
 LValue CapLVal =
 EmitCapturedFieldLValue(*this, CapturedStmtInfo->lookup(VD),

Modified: cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp?rev=286102=286101=286102=diff
==
--- cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp Mon Nov  7 04:01:43 2016
@@ -307,7 +307,7 @@ CodeGenFunction::GenerateOpenMPCapturedS
 if (ArgLVal.getType()->isLValueReferenceType()) {
   ArgAddr = EmitLoadOfReference(
   ArgAddr, ArgLVal.getType()->castAs());
-} else if (!VarTy->isVariablyModifiedType() || 
!VarTy->isPointerType()) {
+} else {
   assert(ArgLVal.getType()->isPointerType());
   ArgAddr = EmitLoadOfPointer(
   ArgAddr, ArgLVal.getType()->castAs());

Modified: cfe/trunk/test/OpenMP/parallel_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/parallel_codegen.cpp?rev=286102=286101=286102=diff
==
--- cfe/trunk/test/OpenMP/parallel_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/parallel_codegen.cpp Mon Nov  7 04:01:43 2016
@@ -10,7 +10,7 @@
 // CHECK-DEBUG-DAG: %ident_t = type { i32, i32, i32, i32, i8* }
 // CHECK-DEBUG-DAG: [[STR:@.+]] = private unnamed_addr constant [23 x i8] 
c";unknown;unknown;0;0;;\00"
 // CHECK-DEBUG-DAG: [[DEF_LOC_2:@.+]] = private unnamed_addr constant %ident_t 
{ i32 0, i32 2, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* 
[[STR]], i32 0, i32 0) }
-// CHECK-DEBUG-DAG: [[LOC1:@.+]] = private unnamed_addr constant [{{.+}} x i8] 
c";{{.*}}parallel_codegen.cpp;main;[[@LINE+15]];9;;\00"
+// CHECK-DEBUG-DAG: [[LOC1:@.+]] = private unnamed_addr constant [{{.+}} x i8] 
c";{{.*}}parallel_codegen.cpp;main;[[@LINE+14]];9;;\00"
 // CHECK-DEBUG-DAG: [[LOC2:@.+]] = private unnamed_addr constant [{{.+}} x i8] 
c";{{.*}}parallel_codegen.cpp;tmain;[[@LINE+7]];9;;\00"
 
 template 
@@ -24,19 +24,17 @@ int tmain(T argc) {
 }
 
 int main (int argc, char **argv) {
-  int a[argc];
 #pragma omp parallel
-  foo(a[1]);
+  foo(argc);
   return tmain(argv);
 }
 
 // CHECK-LABEL: define {{[a-z\_\b]*[ ]?i32}} @main({{i32[ ]?[a-z]*}} %argc, 
i8** %argv)
 // CHECK: store i32 %argc, i32* [[ARGC_ADDR:%.+]],
-// CHECK: [[VLA:%.+]] = alloca i32, i64 [[VLA_SIZE:%[^,]+]],
-// CHECK:  call {{.*}}void (%ident_t*, i32, void (i32*, i32*, ...)*, ...) 
@__kmpc_fork_call(%ident_t* [[DEF_LOC_2]], i32 2, void (i32*, i32*, ...)* 
bitcast (void (i32*, i32*, i64, i32*)* [[OMP_OUTLINED:@.+]] to void (i32*, 
i32*, ...)*), i64 [[VLA_SIZE]], i32* [[VLA]])
+// CHECK:  call {{.*}}void (%ident_t*, i32, void (i32*, i32*, ...)*, ...) 
@__kmpc_fork_call(%ident_t* [[DEF_LOC_2]], i32 1, void (i32*, i32*, ...)* 
bitcast (void (i32*, i32*, i32*)* [[OMP_OUTLINED:@.+]] to void (i32*, i32*, 
...)*), i32* [[ARGC_ADDR]])
 // CHECK-NEXT:  [[ARGV:%.+]] = load i8**, i8*** {{%[a-z0-9.]+}}
 // CHECK-NEXT:  [[RET:%.+]] = call {{[a-z\_\b]*[ ]?i32}} 
[[TMAIN:@.+tmain.+]](i8** [[ARGV]])
-// CHECK:   ret i32
+// CHECK-NEXT:  ret i32 [[RET]]
 // CHECK-NEXT:  }
 // CHECK-DEBUG-LABEL: define i32 @main(i32 %argc, i8** %argv)
 // CHECK-DEBUG:   [[LOC_2_ADDR:%.+]] = alloca %ident_t
@@ -44,33 +42,30 @@ int main (int argc, char **argv) {
 // CHECK-DEBUG-NEXT:  [[KMPC_DEFAULT_LOC_VOIDPTR:%.+]] = bitcast %ident_t* 

Re: r286098 - [OPENMP] Fixed capturing of VLA variables.

[Diana Picus via cfe-commits]

Hi,

This has been breaking the bots for almost an hour. Can you fix/revert?

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/304
http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/657
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/347

Thanks,
Diana

On 7 November 2016 at 10:07, Alexey Bataev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: abataev
> Date: Mon Nov  7 02:07:25 2016
> New Revision: 286098
>
> URL: http://llvm.org/viewvc/llvm-project?rev=286098=rev
> Log:
> [OPENMP] Fixed capturing of VLA variables.
>
> After some changes in codegen capturing of VLA variables in OpenMP
> regions was broken, causing compiler crash. Patch fixes this issue.
>
> Modified:
> cfe/trunk/lib/CodeGen/CGExpr.cpp
> cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
> cfe/trunk/test/OpenMP/parallel_codegen.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> CGExpr.cpp?rev=286098=286097=286098=diff
> 
> ==
> --- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGExpr.cpp Mon Nov  7 02:07:25 2016
> @@ -2127,12 +2127,11 @@ LValue CodeGenFunction::EmitDeclRefLValu
>if (auto *FD = LambdaCaptureFields.lookup(VD))
>  return EmitCapturedFieldLValue(*this, FD, CXXABIThisValue);
>else if (CapturedStmtInfo) {
> -auto it = LocalDeclMap.find(VD);
> -if (it != LocalDeclMap.end()) {
> -  if (auto RefTy = VD->getType()->getAs()) {
> -return EmitLoadOfReferenceLValue(it->second, RefTy);
> -  }
> -  return MakeAddrLValue(it->second, T);
> +auto I = LocalDeclMap.find(VD);
> +if (I != LocalDeclMap.end()) {
> +  if (auto RefTy = VD->getType()->getAs())
> +return EmitLoadOfReferenceLValue(I->second, RefTy);
> +  return MakeAddrLValue(I->second, T);
>  }
>  LValue CapLVal =
>  EmitCapturedFieldLValue(*this, CapturedStmtInfo->lookup(VD),
>
> Modified: cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> CGStmtOpenMP.cpp?rev=286098=286097=286098=diff
> 
> ==
> --- cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp Mon Nov  7 02:07:25 2016
> @@ -307,7 +307,7 @@ CodeGenFunction::GenerateOpenMPCapturedS
>  if (ArgLVal.getType()->isLValueReferenceType()) {
>ArgAddr = EmitLoadOfReference(
>ArgAddr, ArgLVal.getType()->castAs());
> -} else {
> +} else if (!VarTy->isVariablyModifiedType() ||
> !VarTy->isPointerType()) {
>assert(ArgLVal.getType()->isPointerType());
>ArgAddr = EmitLoadOfPointer(
>ArgAddr, ArgLVal.getType()->castAs());
>
> Modified: cfe/trunk/test/OpenMP/parallel_codegen.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/
> parallel_codegen.cpp?rev=286098=286097=286098=diff
> 
> ==
> --- cfe/trunk/test/OpenMP/parallel_codegen.cpp (original)
> +++ cfe/trunk/test/OpenMP/parallel_codegen.cpp Mon Nov  7 02:07:25 2016
> @@ -10,7 +10,7 @@
>  // CHECK-DEBUG-DAG: %ident_t = type { i32, i32, i32, i32, i8* }
>  // CHECK-DEBUG-DAG: [[STR:@.+]] = private unnamed_addr constant [23 x
> i8] c";unknown;unknown;0;0;;\00"
>  // CHECK-DEBUG-DAG: [[DEF_LOC_2:@.+]] = private unnamed_addr constant
> %ident_t { i32 0, i32 2, i32 0, i32 0, i8* getelementptr inbounds ([23 x
> i8], [23 x i8]* [[STR]], i32 0, i32 0) }
> -// CHECK-DEBUG-DAG: [[LOC1:@.+]] = private unnamed_addr constant [{{.+}}
> x i8] c";{{.*}}parallel_codegen.cpp;main;[[@LINE+14]];9;;\00"
> +// CHECK-DEBUG-DAG: [[LOC1:@.+]] = private unnamed_addr constant [{{.+}}
> x i8] c";{{.*}}parallel_codegen.cpp;main;[[@LINE+15]];9;;\00"
>  // CHECK-DEBUG-DAG: [[LOC2:@.+]] = private unnamed_addr constant [{{.+}}
> x i8] c";{{.*}}parallel_codegen.cpp;tmain;[[@LINE+7]];9;;\00"
>
>  template 
> @@ -24,17 +24,19 @@ int tmain(T argc) {
>  }
>
>  int main (int argc, char **argv) {
> +  int a[argc];
>  #pragma omp parallel
> -  foo(argc);
> +  foo(a[1]);
>return tmain(argv);
>  }
>
>  // CHECK-LABEL: define {{[a-z\_\b]*[ ]?i32}} @main({{i32[ ]?[a-z]*}}
> %argc, i8** %argv)
>  // CHECK: store i32 %argc, i32* [[ARGC_ADDR:%.+]],
> -// CHECK:  call {{.*}}void (%ident_t*, i32, void (i32*, i32*, ...)*, ...)
> @__kmpc_fork_call(%ident_t* [[DEF_LOC_2]], i32 1, void (i32*, i32*, ...)*
> bitcast (void (i32*, i32*, i32*)* [[OMP_OUTLINED:@.+]] to void (i32*,
> i32*, ...)*), i32* [[ARGC_ADDR]])
> +// CHECK: [[VLA:%.+]] = alloca i32, i64 [[VLA_SIZE:%[^,]+]],
> +// CHECK:  call {{.*}}void (%ident_t*, i32, void (i32*, i32*, ...)*, ...)
> @__kmpc_fork_call(%ident_t* [[DEF_LOC_2]], i32 2, void (i32*, i32*, 

Re: [PATCH] D24245: [ARM] ARM-specific attributes should be accepted for big-endian

[Diana Picus via cfe-commits]

rovka added a subscriber: rovka.
rovka accepted this revision.
rovka added a reviewer: rovka.
rovka added a comment.
This revision is now accepted and ready to land.

Looks like a sensible thing to do.


Repository:
  rL LLVM

https://reviews.llvm.org/D24245



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r280575 - Add plumbing for new attribute type "Microsoft".

[Diana Picus via cfe-commits]

Scratch that, apparently it fixed itself after I removed the build
directory and restarted the bot.
Sorry about the noise.

Diana

On 7 September 2016 at 11:10, Diana Picus  wrote:
> Hi Nico,
>
> One of our thumb bots [1] is having issues building lately and it
> looks like it might be related to one of the commits in this series.
> Could you please have a look?
>
> Thanks,
> Diana
>
> [1] 
> http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/15286/steps/build%20stage%201/logs/stdio
>
> On 3 September 2016 at 05:55, Nico Weber via cfe-commits
>  wrote:
>> Author: nico
>> Date: Fri Sep  2 21:55:10 2016
>> New Revision: 280575
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=280575=rev
>> Log:
>> Add plumbing for new attribute type "Microsoft".
>>
>> This is for attributes in []-delimited lists preceding a class, like e.g.
>> `[uuid("...")] class Foo {};`  Not used by anything yet, so no behavior 
>> change.
>> Part of https://reviews.llvm.org/D23895
>>
>> Modified:
>> cfe/trunk/include/clang/Basic/Attributes.h
>> cfe/trunk/include/clang/Sema/AttributeList.h
>> cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/Attributes.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attributes.h?rev=280575=280574=280575=diff
>> ==
>> --- cfe/trunk/include/clang/Basic/Attributes.h (original)
>> +++ cfe/trunk/include/clang/Basic/Attributes.h Fri Sep  2 21:55:10 2016
>> @@ -22,6 +22,8 @@ enum class AttrSyntax {
>>GNU,
>>/// Is the identifier known as a __declspec-style attribute?
>>Declspec,
>> +  /// Is the identifier known as a [] Microsoft-style attribute?
>> +  Microsoft,
>>// Is the identifier known as a C++-style attribute?
>>CXX,
>>// Is the identifier known as a pragma attribute?
>>
>> Modified: cfe/trunk/include/clang/Sema/AttributeList.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/AttributeList.h?rev=280575=280574=280575=diff
>> ==
>> --- cfe/trunk/include/clang/Sema/AttributeList.h (original)
>> +++ cfe/trunk/include/clang/Sema/AttributeList.h Fri Sep  2 21:55:10 2016
>> @@ -101,12 +101,14 @@ public:
>>  AS_CXX11,
>>  /// __declspec(...)
>>  AS_Declspec,
>> +/// [uuid("...")] class Foo
>> +AS_Microsoft,
>>  /// __ptr16, alignas(...), etc.
>>  AS_Keyword,
>>  /// Context-sensitive version of a keyword attribute.
>>  AS_ContextSensitiveKeyword,
>>  /// #pragma ...
>> -AS_Pragma
>> +AS_Pragma,
>>};
>>
>>  private:
>> @@ -369,6 +371,7 @@ public:
>>}
>>
>>bool isDeclspecAttribute() const { return SyntaxUsed == AS_Declspec; }
>> +  bool isMicrosoftAttribute() const { return SyntaxUsed == AS_Microsoft; }
>>bool isCXX11Attribute() const {
>>  return SyntaxUsed == AS_CXX11 || isAlignasAttribute();
>>}
>>
>> Modified: cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp?rev=280575=280574=280575=diff
>> ==
>> --- cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp (original)
>> +++ cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp Fri Sep  2 21:55:10 2016
>> @@ -1312,6 +1312,9 @@ writePrettyPrintFunction(Record ,
>>  } else if (Variety == "Declspec") {
>>Prefix = " __declspec(";
>>Suffix = ")";
>> +} else if (Variety == "Microsoft") {
>> +  Prefix = "[";
>> +  Suffix = "]";
>>  } else if (Variety == "Keyword") {
>>Prefix = " ";
>>Suffix = "";
>> @@ -2295,7 +2298,7 @@ void EmitClangAttrHasAttrImpl(RecordKeep
>>// Separate all of the attributes out into four group: generic, C++11, 
>> GNU,
>>// and declspecs. Then generate a big switch statement for each of them.
>>std::vector Attrs = Records.getAllDerivedDefinitions("Attr");
>> -  std::vector Declspec, GNU, Pragma;
>> +  std::vector Declspec, Microsoft, GNU, Pragma;
>>std::map CXX;
>>
>>// Walk over the list of all attributes, and split them out based on the
>> @@ -2308,6 +2311,8 @@ void EmitClangAttrHasAttrImpl(RecordKeep
>>  GNU.push_back(R);
>>else if (Variety == "Declspec")
>>  Declspec.push_back(R);
>> +  else if (Variety == "Microsoft")
>> +Microsoft.push_back(R);
>>else if (Variety == "CXX11")
>>  CXX[SI.nameSpace()].push_back(R);
>>else if (Variety == "Pragma")
>> @@ -2323,6 +2328,9 @@ void EmitClangAttrHasAttrImpl(RecordKeep
>>OS << "case AttrSyntax::Declspec:\n";
>>OS << "  return llvm::StringSwitch(Name)\n";
>>GenerateHasAttrSpellingStringSwitch(Declspec, OS, "Declspec");
>> +  OS << "case AttrSyntax::Microsoft:\n";
>> +  

Re: r280575 - Add plumbing for new attribute type "Microsoft".

[Diana Picus via cfe-commits]

Hi Nico,

One of our thumb bots [1] is having issues building lately and it
looks like it might be related to one of the commits in this series.
Could you please have a look?

Thanks,
Diana

[1] 
http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/15286/steps/build%20stage%201/logs/stdio

On 3 September 2016 at 05:55, Nico Weber via cfe-commits
 wrote:
> Author: nico
> Date: Fri Sep  2 21:55:10 2016
> New Revision: 280575
>
> URL: http://llvm.org/viewvc/llvm-project?rev=280575=rev
> Log:
> Add plumbing for new attribute type "Microsoft".
>
> This is for attributes in []-delimited lists preceding a class, like e.g.
> `[uuid("...")] class Foo {};`  Not used by anything yet, so no behavior 
> change.
> Part of https://reviews.llvm.org/D23895
>
> Modified:
> cfe/trunk/include/clang/Basic/Attributes.h
> cfe/trunk/include/clang/Sema/AttributeList.h
> cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
>
> Modified: cfe/trunk/include/clang/Basic/Attributes.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attributes.h?rev=280575=280574=280575=diff
> ==
> --- cfe/trunk/include/clang/Basic/Attributes.h (original)
> +++ cfe/trunk/include/clang/Basic/Attributes.h Fri Sep  2 21:55:10 2016
> @@ -22,6 +22,8 @@ enum class AttrSyntax {
>GNU,
>/// Is the identifier known as a __declspec-style attribute?
>Declspec,
> +  /// Is the identifier known as a [] Microsoft-style attribute?
> +  Microsoft,
>// Is the identifier known as a C++-style attribute?
>CXX,
>// Is the identifier known as a pragma attribute?
>
> Modified: cfe/trunk/include/clang/Sema/AttributeList.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/AttributeList.h?rev=280575=280574=280575=diff
> ==
> --- cfe/trunk/include/clang/Sema/AttributeList.h (original)
> +++ cfe/trunk/include/clang/Sema/AttributeList.h Fri Sep  2 21:55:10 2016
> @@ -101,12 +101,14 @@ public:
>  AS_CXX11,
>  /// __declspec(...)
>  AS_Declspec,
> +/// [uuid("...")] class Foo
> +AS_Microsoft,
>  /// __ptr16, alignas(...), etc.
>  AS_Keyword,
>  /// Context-sensitive version of a keyword attribute.
>  AS_ContextSensitiveKeyword,
>  /// #pragma ...
> -AS_Pragma
> +AS_Pragma,
>};
>
>  private:
> @@ -369,6 +371,7 @@ public:
>}
>
>bool isDeclspecAttribute() const { return SyntaxUsed == AS_Declspec; }
> +  bool isMicrosoftAttribute() const { return SyntaxUsed == AS_Microsoft; }
>bool isCXX11Attribute() const {
>  return SyntaxUsed == AS_CXX11 || isAlignasAttribute();
>}
>
> Modified: cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp?rev=280575=280574=280575=diff
> ==
> --- cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp (original)
> +++ cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp Fri Sep  2 21:55:10 2016
> @@ -1312,6 +1312,9 @@ writePrettyPrintFunction(Record ,
>  } else if (Variety == "Declspec") {
>Prefix = " __declspec(";
>Suffix = ")";
> +} else if (Variety == "Microsoft") {
> +  Prefix = "[";
> +  Suffix = "]";
>  } else if (Variety == "Keyword") {
>Prefix = " ";
>Suffix = "";
> @@ -2295,7 +2298,7 @@ void EmitClangAttrHasAttrImpl(RecordKeep
>// Separate all of the attributes out into four group: generic, C++11, GNU,
>// and declspecs. Then generate a big switch statement for each of them.
>std::vector Attrs = Records.getAllDerivedDefinitions("Attr");
> -  std::vector Declspec, GNU, Pragma;
> +  std::vector Declspec, Microsoft, GNU, Pragma;
>std::map CXX;
>
>// Walk over the list of all attributes, and split them out based on the
> @@ -2308,6 +2311,8 @@ void EmitClangAttrHasAttrImpl(RecordKeep
>  GNU.push_back(R);
>else if (Variety == "Declspec")
>  Declspec.push_back(R);
> +  else if (Variety == "Microsoft")
> +Microsoft.push_back(R);
>else if (Variety == "CXX11")
>  CXX[SI.nameSpace()].push_back(R);
>else if (Variety == "Pragma")
> @@ -2323,6 +2328,9 @@ void EmitClangAttrHasAttrImpl(RecordKeep
>OS << "case AttrSyntax::Declspec:\n";
>OS << "  return llvm::StringSwitch(Name)\n";
>GenerateHasAttrSpellingStringSwitch(Declspec, OS, "Declspec");
> +  OS << "case AttrSyntax::Microsoft:\n";
> +  OS << "  return llvm::StringSwitch(Name)\n";
> +  GenerateHasAttrSpellingStringSwitch(Microsoft, OS, "Microsoft");
>OS << "case AttrSyntax::Pragma:\n";
>OS << "  return llvm::StringSwitch(Name)\n";
>GenerateHasAttrSpellingStringSwitch(Pragma, OS, "Pragma");
> @@ -2361,8 +2369,9 @@ void EmitClangAttrSpellingListIndex(Reco
>  

Re: [PATCH] D23528: [OpenMP] Sema and parsing for 'teams distribute simd' pragma

[Diana Picus via cfe-commits]

Hi,

I had to revert this (r279045) because it breaks some of our buildbots (e.g.
clang-cmake-aarch64-quick, clang-x86_64-linux-selfhost-modules).

The error is in OpenMP/teams_distribute_simd_ast_print.cpp:
clang:
/home/buildslave/buildslave/clang-cmake-aarch64-quick/llvm/include/llvm/ADT/DenseMap.h:527:
bool llvm::DenseMapBase::LookupBucketFor(const LookupKeyT&, const BucketT*&) const
[with LookupKeyT = clang::Stmt*; DerivedT = llvm::DenseMap;
KeyT = clang::Stmt*; ValueT = long unsigned int;
KeyInfoT = llvm::DenseMapInfo;
BucketT = llvm::detail::DenseMapPair]:

Assertion `!KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val,
TombstoneKey) &&
"Empty/Tombstone value shouldn't be inserted into map!"' failed.

On 18 August 2016 at 02:21, Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL279003: [OpenMP] Sema and parsing for 'teams distribute
> simd’ pragma (authored by kli).
>
> Changed prior to commit:
>   https://reviews.llvm.org/D23528?vs=68216=68448#toc
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D23528
>
> Files:
>   cfe/trunk/include/clang-c/Index.h
>   cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
>   cfe/trunk/include/clang/AST/StmtOpenMP.h
>   cfe/trunk/include/clang/Basic/OpenMPKinds.def
>   cfe/trunk/include/clang/Basic/StmtNodes.td
>   cfe/trunk/include/clang/Sema/Sema.h
>   cfe/trunk/include/clang/Serialization/ASTBitCodes.h
>   cfe/trunk/lib/AST/StmtOpenMP.cpp
>   cfe/trunk/lib/AST/StmtPrinter.cpp
>   cfe/trunk/lib/AST/StmtProfile.cpp
>   cfe/trunk/lib/Basic/OpenMPKinds.cpp
>   cfe/trunk/lib/CodeGen/CGStmt.cpp
>   cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
>   cfe/trunk/lib/CodeGen/CodeGenFunction.h
>   cfe/trunk/lib/Parse/ParseOpenMP.cpp
>   cfe/trunk/lib/Sema/SemaOpenMP.cpp
>   cfe/trunk/lib/Sema/TreeTransform.h
>   cfe/trunk/lib/Serialization/ASTReaderStmt.cpp
>   cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
>   cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
>   cfe/trunk/test/OpenMP/nesting_of_regions.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_aligned_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_ast_print.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_collapse_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_default_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_dist_schedule_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_firstprivate_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_lastprivate_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_linear_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_loop_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_num_teams_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_private_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_reduction_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_safelen_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_shared_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_simdlen_messages.cpp
>   cfe/trunk/test/OpenMP/teams_distribute_simd_thread_limit_messages.cpp
>   cfe/trunk/tools/libclang/CIndex.cpp
>   cfe/trunk/tools/libclang/CXCursor.cpp
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22904: Fix two bugs for musl-libc on ARM

[Diana Picus via cfe-commits]

rovka added a subscriber: rovka.
rovka added a comment.

Hi Lei,

Renato is on vacation, so I committed this for you.

Regards,
Diana


Repository:
  rL LLVM

https://reviews.llvm.org/D22904



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22904: Fix two bugs for musl-libc on ARM

[Diana Picus via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL277985: Fix two bugs for musl-libc on ARM (authored by 
rovka).

Changed prior to commit:
  https://reviews.llvm.org/D22904?vs=66074=67131#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22904

Files:
  cfe/trunk/lib/Driver/ToolChains.cpp
  cfe/trunk/test/Driver/linux-ld.c

Index: cfe/trunk/test/Driver/linux-ld.c
===
--- cfe/trunk/test/Driver/linux-ld.c
+++ cfe/trunk/test/Driver/linux-ld.c
@@ -1613,24 +1613,36 @@
 // RUN: --target=thumb-pc-linux-musleabihf \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=thumbv7-pc-linux-musleabi -mhard-float \
+// RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
+// RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=thumbeb-pc-linux-musleabi \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEB %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=thumbeb-pc-linux-musleabihf \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=thumbv7eb-pc-linux-musleabi -mhard-float \
+// RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
+// RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=arm-pc-linux-musleabi \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARM %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=arm-pc-linux-musleabihf \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=armv7-pc-linux-musleabi -mhard-float \
+// RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
+// RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=armeb-pc-linux-musleabi \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEB %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=armeb-pc-linux-musleabihf \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=armv7eb-pc-linux-musleabi -mhard-float \
+// RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
+// RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=aarch64-pc-linux-musleabi \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-AARCH64 %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
Index: cfe/trunk/lib/Driver/ToolChains.cpp
===
--- cfe/trunk/lib/Driver/ToolChains.cpp
+++ cfe/trunk/lib/Driver/ToolChains.cpp
@@ -4274,19 +4274,28 @@
 
   if (Triple.isAndroid())
 return Triple.isArch64Bit() ? "/system/bin/linker64" : 
"/system/bin/linker";
-  else if (Triple.isMusl()) {
+
+  if (Triple.isMusl()) {
 std::string ArchName;
+bool IsArm = false;
+
 switch (Arch) {
+case llvm::Triple::arm:
 case llvm::Triple::thumb:
   ArchName = "arm";
+  IsArm = true;
   break;
+case llvm::Triple::armeb:
 case llvm::Triple::thumbeb:
   ArchName = "armeb";
+  IsArm = true;
   break;
 default:
   ArchName = Triple.getArchName().str();
 }
-if (Triple.getEnvironment() == llvm::Triple::MuslEABIHF)
+if (IsArm &&
+(Triple.getEnvironment() == llvm::Triple::MuslEABIHF ||
+ tools::arm::getARMFloatABI(*this, Args) == 
tools::arm::FloatABI::Hard))
   ArchName += "hf";
 
 return "/lib/ld-musl-" + ArchName + ".so.1";


Index: cfe/trunk/test/Driver/linux-ld.c
===
--- cfe/trunk/test/Driver/linux-ld.c
+++ cfe/trunk/test/Driver/linux-ld.c
@@ -1613,24 +1613,36 @@
 // RUN: --target=thumb-pc-linux-musleabihf \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=thumbv7-pc-linux-musleabi -mhard-float \
+// RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
+// RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=thumbeb-pc-linux-musleabi \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEB %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=thumbeb-pc-linux-musleabihf \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=thumbv7eb-pc-linux-musleabi -mhard-float \
+// RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
+// RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=arm-pc-linux-musleabi \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARM %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=arm-pc-linux-musleabihf \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=armv7-pc-linux-musleabi -mhard-float \
+// RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
+// RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=armeb-pc-linux-musleabi \
 // RUN:   | FileCheck 

r277985 - Fix two bugs for musl-libc on ARM

[Diana Picus via cfe-commits]

Author: rovka
Date: Mon Aug  8 03:27:36 2016
New Revision: 277985

URL: http://llvm.org/viewvc/llvm-project?rev=277985=rev
Log:
Fix two bugs for musl-libc on ARM

Bug 1: triples like armv7-pc-linux-musl use the wrong linker name
ld-musl-armv7.so.1; the right name should be ld-musl-arm.so.1, disregarding the
subarch field.

Bug 2: when compiler option -mhard-float is used, we should use the "hardfloat"
linker, no matter whether the triple itself mentions "hardfloat".

Patch by Lei Zhang!

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

Modified:
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/test/Driver/linux-ld.c

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=277985=277984=277985=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Mon Aug  8 03:27:36 2016
@@ -4274,19 +4274,28 @@ std::string Linux::getDynamicLinker(cons
 
   if (Triple.isAndroid())
 return Triple.isArch64Bit() ? "/system/bin/linker64" : 
"/system/bin/linker";
-  else if (Triple.isMusl()) {
+
+  if (Triple.isMusl()) {
 std::string ArchName;
+bool IsArm = false;
+
 switch (Arch) {
+case llvm::Triple::arm:
 case llvm::Triple::thumb:
   ArchName = "arm";
+  IsArm = true;
   break;
+case llvm::Triple::armeb:
 case llvm::Triple::thumbeb:
   ArchName = "armeb";
+  IsArm = true;
   break;
 default:
   ArchName = Triple.getArchName().str();
 }
-if (Triple.getEnvironment() == llvm::Triple::MuslEABIHF)
+if (IsArm &&
+(Triple.getEnvironment() == llvm::Triple::MuslEABIHF ||
+ tools::arm::getARMFloatABI(*this, Args) == 
tools::arm::FloatABI::Hard))
   ArchName += "hf";
 
 return "/lib/ld-musl-" + ArchName + ".so.1";

Modified: cfe/trunk/test/Driver/linux-ld.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/linux-ld.c?rev=277985=277984=277985=diff
==
--- cfe/trunk/test/Driver/linux-ld.c (original)
+++ cfe/trunk/test/Driver/linux-ld.c Mon Aug  8 03:27:36 2016
@@ -1613,24 +1613,36 @@
 // RUN: --target=thumb-pc-linux-musleabihf \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=thumbv7-pc-linux-musleabi -mhard-float \
+// RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
+// RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=thumbeb-pc-linux-musleabi \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEB %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=thumbeb-pc-linux-musleabihf \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=thumbv7eb-pc-linux-musleabi -mhard-float \
+// RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
+// RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=arm-pc-linux-musleabi \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARM %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=arm-pc-linux-musleabihf \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=armv7-pc-linux-musleabi -mhard-float \
+// RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
+// RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=armeb-pc-linux-musleabi \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEB %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=armeb-pc-linux-musleabihf \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
 // RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=armv7eb-pc-linux-musleabi -mhard-float \
+// RUN:   | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
+// RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=aarch64-pc-linux-musleabi \
 // RUN:   | FileCheck --check-prefix=CHECK-MUSL-AARCH64 %s
 // RUN: %clang %s -### -o %t.o 2>&1 \


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D23054: [clang-cl] Fix PCH tests to use x86_64 as target

[Diana Picus via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL277457: [clang-cl] Fix PCH tests to use x86_64 as target 
(authored by rovka).

Changed prior to commit:
  https://reviews.llvm.org/D23054?vs=66467=66468#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D23054

Files:
  cfe/trunk/test/Driver/cl-pch-errorhandling.cpp
  cfe/trunk/test/Driver/cl-pch-search.cpp
  cfe/trunk/test/Driver/cl-pch-showincludes.cpp

Index: cfe/trunk/test/Driver/cl-pch-search.cpp
===
--- cfe/trunk/test/Driver/cl-pch-search.cpp
+++ cfe/trunk/test/Driver/cl-pch-search.cpp
@@ -3,4 +3,4 @@
 
 // REQUIRES: x86-registered-target
 // Check that pchfile.h next to to pchfile.cc is found correctly.
-// RUN: %clang_cl -Werror /Ycpchfile.h /FIpchfile.h /c /Fo%t.obj /Fp%t.pch -- 
%S/Inputs/pchfile.cpp 
+// RUN: %clang_cl -Werror --target=x86_64 /Ycpchfile.h /FIpchfile.h /c 
/Fo%t.obj /Fp%t.pch -- %S/Inputs/pchfile.cpp
Index: cfe/trunk/test/Driver/cl-pch-showincludes.cpp
===
--- cfe/trunk/test/Driver/cl-pch-showincludes.cpp
+++ cfe/trunk/test/Driver/cl-pch-showincludes.cpp
@@ -8,39 +8,39 @@
 
 // When building the pch, header1.h (included by header2.h), header2.h (the pch
 // input itself) and header3.h (included directly, above) should be printed.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Ycheader2.h /FIheader2.h 
/Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Ycheader2.h /FIheader2.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YC %s
 // CHECK-YC: Note: including file: {{[^ ]*header2.h}}
 // CHECK-YC: Note: including file:  {{[^ ]*header1.h}}
 // CHECK-YC: Note: including file: {{[^ ]*header3.h}}
 
 // When using the pch, only the direct include is printed.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Yuheader2.h /FIheader2.h 
/Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Yuheader2.h /FIheader2.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YU %s
 // CHECK-YU-NOT: Note: including file: {{.*pch}}
 // CHECK-YU-NOT: Note: including file: {{.*header1.h}}
 // CHECK-YU-NOT: Note: including file: {{.*header2.h}}
 // CHECK-YU: Note: including file: {{[^ ]*header3.h}}
 
 // When not using pch at all, all the /FI files are printed.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /FIheader2.h /c /Fo%t -- 
%s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/FIheader2.h /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-FI %s
 // CHECK-FI: Note: including file: {{[^ ]*header2.h}}
 // CHECK-FI: Note: including file:  {{[^ ]*header1.h}}
 // CHECK-FI: Note: including file: {{[^ ]*header3.h}}
 
 // Also check that /FI arguments before the /Yc / /Yu flags are printed right.
 
 // /FI flags before the /Yc arg should be printed, /FI flags after it 
shouldn't.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Ycheader2.h /FIheader0.h 
/FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Ycheader2.h /FIheader0.h /FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YCFI %s
 // CHECK-YCFI: Note: including file: {{[^ ]*header0.h}}
 // CHECK-YCFI: Note: including file: {{[^ ]*header2.h}}
 // CHECK-YCFI: Note: including file:  {{[^ ]*header1.h}}
 // CHECK-YCFI: Note: including file: {{[^ ]*header4.h}}
 // CHECK-YCFI: Note: including file: {{[^ ]*header3.h}}
 
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Yuheader2.h /FIheader0.h 
/FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Yuheader2.h /FIheader0.h /FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YUFI %s
 // CHECK-YUFI-NOT: Note: including file: {{.*pch}}
 // CHECK-YUFI-NOT: Note: including file: {{.*header0.h}}
Index: cfe/trunk/test/Driver/cl-pch-errorhandling.cpp
===
--- cfe/trunk/test/Driver/cl-pch-errorhandling.cpp
+++ cfe/trunk/test/Driver/cl-pch-errorhandling.cpp
@@ -6,7 +6,7 @@
 // code generation, which makes this test require an x86 backend.
 // REQUIRES: x86-registered-target
 
-// RUN: not %clang_cl -Werror /Yc%S/Inputs/pchfile.h /FI%S/Inputs/pchfile.h 
/Fp%t.pch /c -DERR_HEADER -- %s 2>&1 \
+// RUN: not %clang_cl -Werror --target=x86_64 /Yc%S/Inputs/pchfile.h 
/FI%S/Inputs/pchfile.h /Fp%t.pch /c -DERR_HEADER -- %s 2>&1 \
 // RUN:   | FileCheck %s
 
 // CHECK: nope1


Index: cfe/trunk/test/Driver/cl-pch-search.cpp
===
--- cfe/trunk/test/Driver/cl-pch-search.cpp

r277457 - [clang-cl] Fix PCH tests to use x86_64 as target

[Diana Picus via cfe-commits]

Author: rovka
Date: Tue Aug  2 08:53:00 2016
New Revision: 277457

URL: http://llvm.org/viewvc/llvm-project?rev=277457=rev
Log:
[clang-cl] Fix PCH tests to use x86_64 as target

These tests require x86-registered-target, but they don't force the target as
x86 on the command line, which means they will be run and they might fail when
building the x86 backend on another platform (such as AArch64).

Fixes https://llvm.org/bugs/show_bug.cgi?id=28797

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

Modified:
cfe/trunk/test/Driver/cl-pch-errorhandling.cpp
cfe/trunk/test/Driver/cl-pch-search.cpp
cfe/trunk/test/Driver/cl-pch-showincludes.cpp

Modified: cfe/trunk/test/Driver/cl-pch-errorhandling.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-pch-errorhandling.cpp?rev=277457=277456=277457=diff
==
--- cfe/trunk/test/Driver/cl-pch-errorhandling.cpp (original)
+++ cfe/trunk/test/Driver/cl-pch-errorhandling.cpp Tue Aug  2 08:53:00 2016
@@ -6,7 +6,7 @@
 // code generation, which makes this test require an x86 backend.
 // REQUIRES: x86-registered-target
 
-// RUN: not %clang_cl -Werror /Yc%S/Inputs/pchfile.h /FI%S/Inputs/pchfile.h 
/Fp%t.pch /c -DERR_HEADER -- %s 2>&1 \
+// RUN: not %clang_cl -Werror --target=x86_64 /Yc%S/Inputs/pchfile.h 
/FI%S/Inputs/pchfile.h /Fp%t.pch /c -DERR_HEADER -- %s 2>&1 \
 // RUN:   | FileCheck %s
 
 // CHECK: nope1

Modified: cfe/trunk/test/Driver/cl-pch-search.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-pch-search.cpp?rev=277457=277456=277457=diff
==
--- cfe/trunk/test/Driver/cl-pch-search.cpp (original)
+++ cfe/trunk/test/Driver/cl-pch-search.cpp Tue Aug  2 08:53:00 2016
@@ -3,4 +3,4 @@
 
 // REQUIRES: x86-registered-target
 // Check that pchfile.h next to to pchfile.cc is found correctly.
-// RUN: %clang_cl -Werror /Ycpchfile.h /FIpchfile.h /c /Fo%t.obj /Fp%t.pch -- 
%S/Inputs/pchfile.cpp 
+// RUN: %clang_cl -Werror --target=x86_64 /Ycpchfile.h /FIpchfile.h /c 
/Fo%t.obj /Fp%t.pch -- %S/Inputs/pchfile.cpp

Modified: cfe/trunk/test/Driver/cl-pch-showincludes.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-pch-showincludes.cpp?rev=277457=277456=277457=diff
==
--- cfe/trunk/test/Driver/cl-pch-showincludes.cpp (original)
+++ cfe/trunk/test/Driver/cl-pch-showincludes.cpp Tue Aug  2 08:53:00 2016
@@ -8,14 +8,14 @@
 
 // When building the pch, header1.h (included by header2.h), header2.h (the pch
 // input itself) and header3.h (included directly, above) should be printed.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Ycheader2.h /FIheader2.h 
/Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Ycheader2.h /FIheader2.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YC %s
 // CHECK-YC: Note: including file: {{[^ ]*header2.h}}
 // CHECK-YC: Note: including file:  {{[^ ]*header1.h}}
 // CHECK-YC: Note: including file: {{[^ ]*header3.h}}
 
 // When using the pch, only the direct include is printed.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Yuheader2.h /FIheader2.h 
/Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Yuheader2.h /FIheader2.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YU %s
 // CHECK-YU-NOT: Note: including file: {{.*pch}}
 // CHECK-YU-NOT: Note: including file: {{.*header1.h}}
@@ -23,7 +23,7 @@
 // CHECK-YU: Note: including file: {{[^ ]*header3.h}}
 
 // When not using pch at all, all the /FI files are printed.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /FIheader2.h /c /Fo%t -- 
%s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/FIheader2.h /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-FI %s
 // CHECK-FI: Note: including file: {{[^ ]*header2.h}}
 // CHECK-FI: Note: including file:  {{[^ ]*header1.h}}
@@ -32,7 +32,7 @@
 // Also check that /FI arguments before the /Yc / /Yu flags are printed right.
 
 // /FI flags before the /Yc arg should be printed, /FI flags after it 
shouldn't.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Ycheader2.h /FIheader0.h 
/FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Ycheader2.h /FIheader0.h /FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YCFI %s
 // CHECK-YCFI: Note: including file: {{[^ ]*header0.h}}
 // CHECK-YCFI: Note: including file: {{[^ ]*header2.h}}
@@ -40,7 +40,7 @@
 // CHECK-YCFI: Note: including file: {{[^ ]*header4.h}}
 // CHECK-YCFI: Note: including file: {{[^ ]*header3.h}}
 
-// RUN: %clang_cl -Werror 

Re: [PATCH] D23054: [clang-cl] Fix PCH tests to use x86_64 as target

[Diana Picus via cfe-commits]

rovka retitled this revision from "[clang-cl] Fix 2 pch tests to use x86_64 as 
target" to "[clang-cl] Fix PCH tests to use x86_64 as target".
rovka updated this revision to Diff 66467.
rovka added a comment.

Added cl-pch-errorhandling.cpp


https://reviews.llvm.org/D23054

Files:
  test/Driver/cl-pch-errorhandling.cpp
  test/Driver/cl-pch-search.cpp
  test/Driver/cl-pch-showincludes.cpp

Index: test/Driver/cl-pch-showincludes.cpp
===
--- test/Driver/cl-pch-showincludes.cpp
+++ test/Driver/cl-pch-showincludes.cpp
@@ -8,39 +8,39 @@
 
 // When building the pch, header1.h (included by header2.h), header2.h (the pch
 // input itself) and header3.h (included directly, above) should be printed.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Ycheader2.h /FIheader2.h 
/Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Ycheader2.h /FIheader2.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YC %s
 // CHECK-YC: Note: including file: {{[^ ]*header2.h}}
 // CHECK-YC: Note: including file:  {{[^ ]*header1.h}}
 // CHECK-YC: Note: including file: {{[^ ]*header3.h}}
 
 // When using the pch, only the direct include is printed.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Yuheader2.h /FIheader2.h 
/Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Yuheader2.h /FIheader2.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YU %s
 // CHECK-YU-NOT: Note: including file: {{.*pch}}
 // CHECK-YU-NOT: Note: including file: {{.*header1.h}}
 // CHECK-YU-NOT: Note: including file: {{.*header2.h}}
 // CHECK-YU: Note: including file: {{[^ ]*header3.h}}
 
 // When not using pch at all, all the /FI files are printed.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /FIheader2.h /c /Fo%t -- 
%s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/FIheader2.h /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-FI %s
 // CHECK-FI: Note: including file: {{[^ ]*header2.h}}
 // CHECK-FI: Note: including file:  {{[^ ]*header1.h}}
 // CHECK-FI: Note: including file: {{[^ ]*header3.h}}
 
 // Also check that /FI arguments before the /Yc / /Yu flags are printed right.
 
 // /FI flags before the /Yc arg should be printed, /FI flags after it 
shouldn't.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Ycheader2.h /FIheader0.h 
/FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Ycheader2.h /FIheader0.h /FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YCFI %s
 // CHECK-YCFI: Note: including file: {{[^ ]*header0.h}}
 // CHECK-YCFI: Note: including file: {{[^ ]*header2.h}}
 // CHECK-YCFI: Note: including file:  {{[^ ]*header1.h}}
 // CHECK-YCFI: Note: including file: {{[^ ]*header4.h}}
 // CHECK-YCFI: Note: including file: {{[^ ]*header3.h}}
 
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Yuheader2.h /FIheader0.h 
/FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Yuheader2.h /FIheader0.h /FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YUFI %s
 // CHECK-YUFI-NOT: Note: including file: {{.*pch}}
 // CHECK-YUFI-NOT: Note: including file: {{.*header0.h}}
Index: test/Driver/cl-pch-search.cpp
===
--- test/Driver/cl-pch-search.cpp
+++ test/Driver/cl-pch-search.cpp
@@ -3,4 +3,4 @@
 
 // REQUIRES: x86-registered-target
 // Check that pchfile.h next to to pchfile.cc is found correctly.
-// RUN: %clang_cl -Werror /Ycpchfile.h /FIpchfile.h /c /Fo%t.obj /Fp%t.pch -- 
%S/Inputs/pchfile.cpp 
+// RUN: %clang_cl -Werror --target=x86_64 /Ycpchfile.h /FIpchfile.h /c 
/Fo%t.obj /Fp%t.pch -- %S/Inputs/pchfile.cpp
Index: test/Driver/cl-pch-errorhandling.cpp
===
--- test/Driver/cl-pch-errorhandling.cpp
+++ test/Driver/cl-pch-errorhandling.cpp
@@ -6,7 +6,7 @@
 // code generation, which makes this test require an x86 backend.
 // REQUIRES: x86-registered-target
 
-// RUN: not %clang_cl -Werror /Yc%S/Inputs/pchfile.h /FI%S/Inputs/pchfile.h 
/Fp%t.pch /c -DERR_HEADER -- %s 2>&1 \
+// RUN: not %clang_cl -Werror --target=x86_64 /Yc%S/Inputs/pchfile.h 
/FI%S/Inputs/pchfile.h /Fp%t.pch /c -DERR_HEADER -- %s 2>&1 \
 // RUN:   | FileCheck %s
 
 // CHECK: nope1


Index: test/Driver/cl-pch-showincludes.cpp
===
--- test/Driver/cl-pch-showincludes.cpp
+++ test/Driver/cl-pch-showincludes.cpp
@@ -8,39 +8,39 @@
 
 // When building the pch, header1.h (included by header2.h), header2.h (the pch
 // input itself) 

Re: [PATCH] D23054: [clang-cl] Fix 2 pch tests to use x86_64 as target

[Diana Picus via cfe-commits]

rovka added a comment.

In https://reviews.llvm.org/D23054#503246, @rengolin wrote:

> All tests should have the target explicit, so I'd advocate for all of them to 
> be changed.


Coming right up...

> Also, we need to make sure --target=x86_64 is enough on Windows. I remember 
> some -target=arm not being enough (arm-eabi was enough, for some reason).


It's enough, I've seen it used in other clang-cl tests.


https://reviews.llvm.org/D23054



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D23054: [clang-cl] Fix 2 pch tests to use x86_64 as target

[Diana Picus via cfe-commits]

rovka added a comment.

This seems to be the case for other similar tests as well (e.g. 
cl-pch-errorhandling.cpp requires x86-registered-target, but doesn't force it 
on the command line), but they're not currently crashing. I can update those as 
well if people think it's the right thing to do.


https://reviews.llvm.org/D23054



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D23054: [clang-cl] Fix 2 pch tests to use x86_64 as target

[Diana Picus via cfe-commits]

rovka created this revision.
rovka added a reviewer: thakis.
rovka added subscribers: cfe-commits, hans.
Herald added a subscriber: aemerson.

These tests require x86-registered-target, but they don't force the target as
x86 on the command line, which means they will be run and they might fail when
building the x86 backend on another platform (such as AArch64).

Fixes PR28797 https://llvm.org/bugs/show_bug.cgi?id=28797


https://reviews.llvm.org/D23054

Files:
  test/Driver/cl-pch-search.cpp
  test/Driver/cl-pch-showincludes.cpp

Index: test/Driver/cl-pch-showincludes.cpp
===
--- test/Driver/cl-pch-showincludes.cpp
+++ test/Driver/cl-pch-showincludes.cpp
@@ -8,39 +8,39 @@
 
 // When building the pch, header1.h (included by header2.h), header2.h (the pch
 // input itself) and header3.h (included directly, above) should be printed.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Ycheader2.h /FIheader2.h 
/Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Ycheader2.h /FIheader2.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YC %s
 // CHECK-YC: Note: including file: {{[^ ]*header2.h}}
 // CHECK-YC: Note: including file:  {{[^ ]*header1.h}}
 // CHECK-YC: Note: including file: {{[^ ]*header3.h}}
 
 // When using the pch, only the direct include is printed.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Yuheader2.h /FIheader2.h 
/Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Yuheader2.h /FIheader2.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YU %s
 // CHECK-YU-NOT: Note: including file: {{.*pch}}
 // CHECK-YU-NOT: Note: including file: {{.*header1.h}}
 // CHECK-YU-NOT: Note: including file: {{.*header2.h}}
 // CHECK-YU: Note: including file: {{[^ ]*header3.h}}
 
 // When not using pch at all, all the /FI files are printed.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /FIheader2.h /c /Fo%t -- 
%s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/FIheader2.h /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-FI %s
 // CHECK-FI: Note: including file: {{[^ ]*header2.h}}
 // CHECK-FI: Note: including file:  {{[^ ]*header1.h}}
 // CHECK-FI: Note: including file: {{[^ ]*header3.h}}
 
 // Also check that /FI arguments before the /Yc / /Yu flags are printed right.
 
 // /FI flags before the /Yc arg should be printed, /FI flags after it 
shouldn't.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Ycheader2.h /FIheader0.h 
/FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Ycheader2.h /FIheader0.h /FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YCFI %s
 // CHECK-YCFI: Note: including file: {{[^ ]*header0.h}}
 // CHECK-YCFI: Note: including file: {{[^ ]*header2.h}}
 // CHECK-YCFI: Note: including file:  {{[^ ]*header1.h}}
 // CHECK-YCFI: Note: including file: {{[^ ]*header4.h}}
 // CHECK-YCFI: Note: including file: {{[^ ]*header3.h}}
 
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Yuheader2.h /FIheader0.h 
/FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs 
/Yuheader2.h /FIheader0.h /FIheader2.h /FIheader4.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YUFI %s
 // CHECK-YUFI-NOT: Note: including file: {{.*pch}}
 // CHECK-YUFI-NOT: Note: including file: {{.*header0.h}}
Index: test/Driver/cl-pch-search.cpp
===
--- test/Driver/cl-pch-search.cpp
+++ test/Driver/cl-pch-search.cpp
@@ -3,4 +3,4 @@
 
 // REQUIRES: x86-registered-target
 // Check that pchfile.h next to to pchfile.cc is found correctly.
-// RUN: %clang_cl -Werror /Ycpchfile.h /FIpchfile.h /c /Fo%t.obj /Fp%t.pch -- 
%S/Inputs/pchfile.cpp 
+// RUN: %clang_cl -Werror --target=x86_64 /Ycpchfile.h /FIpchfile.h /c 
/Fo%t.obj /Fp%t.pch -- %S/Inputs/pchfile.cpp 


Index: test/Driver/cl-pch-showincludes.cpp
===
--- test/Driver/cl-pch-showincludes.cpp
+++ test/Driver/cl-pch-showincludes.cpp
@@ -8,39 +8,39 @@
 
 // When building the pch, header1.h (included by header2.h), header2.h (the pch
 // input itself) and header3.h (included directly, above) should be printed.
-// RUN: %clang_cl -Werror /showIncludes /I%S/Inputs /Ycheader2.h /FIheader2.h /Fp%t.pch /c /Fo%t -- %s \
+// RUN: %clang_cl -Werror --target=x86_64 /showIncludes /I%S/Inputs /Ycheader2.h /FIheader2.h /Fp%t.pch /c /Fo%t -- %s \
 // RUN:   | FileCheck --strict-whitespace -check-prefix=CHECK-YC %s
 // CHECK-YC: Note: including file: {{[^ ]*header2.h}}
 // CHECK-YC: Note: including file:  {{[^ 

Re: [libcxx] r274605 - Fix typo in #ifdef, and re-enable tests now that the green-dragon bots are no more

[Diana Picus via cfe-commits]

Hi Marhsall,

This seems to be breaking our libcxx bot:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-arm-linux/builds/1126
I'm a bit confused by that comment you removed, do we need to update
our bot in any way?

Thanks,
Diana

On 6 July 2016 at 08:28, Marshall Clow via cfe-commits
 wrote:
> Author: marshall
> Date: Wed Jul  6 00:28:44 2016
> New Revision: 274605
>
> URL: http://llvm.org/viewvc/llvm-project?rev=274605=rev
> Log:
> Fix typo in #ifdef, and re-enable tests now that the green-dragon bots are no 
> more
>
> Modified:
> 
> libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_constructible.pass.cpp
>
> Modified: 
> libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_constructible.pass.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_constructible.pass.cpp?rev=274605=274604=274605=diff
> ==
> --- 
> libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_constructible.pass.cpp
>  (original)
> +++ 
> libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_constructible.pass.cpp
>  Wed Jul  6 00:28:44 2016
> @@ -103,11 +103,11 @@ int main()
>  test_is_not_constructible ();
>
>  //  LWG 2560  -- postpone this test until bots updated
> -// test_is_not_constructible ();
> -// #if TEST_STD_VERS > 11
> -// test_is_not_constructible ();
> -// test_is_not_constructible ();
> -// test_is_not_constructible ();
> -// test_is_not_constructible ();
> -// #endif
> +test_is_not_constructible ();
> +#if TEST_STD_VER > 11
> +test_is_not_constructible ();
> +test_is_not_constructible ();
> +test_is_not_constructible ();
> +test_is_not_constructible ();
> +#endif
>  }
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D20157: Add test for D20156

[Diana Picus via cfe-commits]

rovka abandoned this revision.
rovka added a comment.

With the new diagnostic handler in r269428, we no longer need this test (it 
will be covered by the existing tests such as 
CodeGen/AArch64/arm64-inline-asm-error-N.ll, by removing the -exit-on-error 
flag).


http://reviews.llvm.org/D20157



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D20157: Add test for D20156

[Diana Picus via cfe-commits]

rovka created this revision.
rovka added reviewers: rengolin, resistor, mcrosier, echristo, qcolombet, 
bogner.
rovka added subscribers: llvm-commits, cfe-commits.
Herald added a subscriber: joker.eph.

This adds a test for PR24071. Its purpose is to make sure that we do not assert 
after identifying an error in inline asm.

It has to be added in Clang because llc exits after identifying the error, and 
therefore never reaches the assert. The situation is similar to [1].

http://reviews.llvm.org/D20156

[1] https://www.mail-archive.com/cfe-commits@cs.uiuc.edu/msg70985.html

http://reviews.llvm.org/D20157

Files:
  test/CodeGen/arm64-asm-diag.c

Index: test/CodeGen/arm64-asm-diag.c
===
--- /dev/null
+++ test/CodeGen/arm64-asm-diag.c
@@ -0,0 +1,24 @@
+// RUN: not %clang_cc1 -triple arm64 %s -S -o /dev/null 2>&1 | FileCheck %s
+
+// This test makes sure that we correctly recover after an error is identified
+// in inline asm during instruction selection.
+// It needs to be in Clang because the diagnostic handler that is used by llc
+// in LLVM's CodeGen tests exits after identifying an error, whereas the
+// diagnostic handler used by Clang keeps running and may trigger assertions
+// (see PR24071).
+// This test as well as arm-asm-diag.c can be moved back into LLVM if llc is
+// updated to use a different diagnostic handler, that tries to catch as many
+// errors as possible without exiting.
+int foo(long int a, long int b){
+const long int c = 32 - b;
+
+long int r;
+asm("lsl  %[o],%[s],%[a]"
+:   [o]"=r"  (r)
+:   [s]"r"   (a),
+[a]"n"   (c));
+
+return r;
+}
+
+// CHECK: error: invalid operand for inline asm constraint 'n'


Index: test/CodeGen/arm64-asm-diag.c
===
--- /dev/null
+++ test/CodeGen/arm64-asm-diag.c
@@ -0,0 +1,24 @@
+// RUN: not %clang_cc1 -triple arm64 %s -S -o /dev/null 2>&1 | FileCheck %s
+
+// This test makes sure that we correctly recover after an error is identified
+// in inline asm during instruction selection.
+// It needs to be in Clang because the diagnostic handler that is used by llc
+// in LLVM's CodeGen tests exits after identifying an error, whereas the
+// diagnostic handler used by Clang keeps running and may trigger assertions
+// (see PR24071).
+// This test as well as arm-asm-diag.c can be moved back into LLVM if llc is
+// updated to use a different diagnostic handler, that tries to catch as many
+// errors as possible without exiting.
+int foo(long int a, long int b){
+const long int c = 32 - b;
+
+long int r;
+asm("lsl  %[o],%[s],%[a]"
+:   [o]"=r"  (r)
+:   [s]"r"   (a),
+[a]"n"   (c));
+
+return r;
+}
+
+// CHECK: error: invalid operand for inline asm constraint 'n'
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r267866 - [MS] Improved implementation of MS stack pragmas (vtordisp, *_seg)

[Diana Picus via cfe-commits]

Hi,

I don't know if you've noticed, but this commit broke a lot of builds -
e.g. http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/11865.

Regards,
Diana

On 28 April 2016 at 13:13, Denis Zobnin via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: dzobnin
> Date: Thu Apr 28 05:13:18 2016
> New Revision: 267866
>
> URL: http://llvm.org/viewvc/llvm-project?rev=267866=rev
> Log:
> [MS] Improved implementation of MS stack pragmas (vtordisp, *_seg)
>
> Rework implementation of several MS pragmas that use internal stack:
> vtordisp, {bss|code|const|data}_seg.
> This patch:
>   1. Makes #pragma vtordisp use PragmaStack class as *_seg pragmas do;
>   2. Fixes "#pragma vtordisp()" behavior: it shouldn't affect stack;
>   3. Saves/restores the stacks on enter/exit a C++ method body.
>
>
> Modified:
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/Parse/ParsePragma.cpp
> cfe/trunk/lib/Parse/ParseStmt.cpp
> cfe/trunk/lib/Sema/Sema.cpp
> cfe/trunk/lib/Sema/SemaAttr.cpp
> cfe/trunk/test/CodeGenCXX/sections.cpp
> cfe/trunk/test/SemaCXX/pragma-vtordisp.cpp
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=267866=267865=267866=diff
>
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Thu Apr 28 05:13:18 2016
> @@ -327,40 +327,21 @@ public:
>LangOptions::PragmaMSPointersToMembersKind
>MSPointerToMemberRepresentationMethod;
>
> -  enum PragmaVtorDispKind {
> -PVDK_Push,  ///< #pragma vtordisp(push, mode)
> -PVDK_Set,   ///< #pragma vtordisp(mode)
> -PVDK_Pop,   ///< #pragma vtordisp(pop)
> -PVDK_Reset  ///< #pragma vtordisp()
> -  };
> -
> -  enum PragmaMsStackAction {
> -PSK_Reset,// #pragma ()
> -PSK_Set,  // #pragma ("name")
> -PSK_Push, // #pragma (push[, id])
> -PSK_Push_Set, // #pragma (push[, id], "name")
> -PSK_Pop,  // #pragma (pop[, id])
> -PSK_Pop_Set,  // #pragma (pop[, id], "name")
> -  };
> -
> -  /// \brief Whether to insert vtordisps prior to virtual bases in the
> Microsoft
> -  /// C++ ABI.  Possible values are 0, 1, and 2, which mean:
> -  ///
> -  /// 0: Suppress all vtordisps
> -  /// 1: Insert vtordisps in the presence of vbase overrides and
> non-trivial
> -  ///structors
> -  /// 2: Always insert vtordisps to support RTTI on partially constructed
> -  ///objects
> -  ///
> -  /// The stack always has at least one element in it.
> -  SmallVector VtorDispModeStack;
> -
>/// Stack of active SEH __finally scopes.  Can be empty.
>SmallVector CurrentSEHFinally;
>
>/// \brief Source location for newly created implicit MSInheritanceAttrs
>SourceLocation ImplicitMSInheritanceAttrLoc;
>
> +  enum PragmaMsStackAction {
> +PSK_Reset = 0x0,// #pragma ()
> +PSK_Set   = 0x1,// #pragma (value)
> +PSK_Push  = 0x2,// #pragma (push[, id])
> +PSK_Pop   = 0x4,// #pragma (pop[, id])
> +PSK_Push_Set  = PSK_Push | PSK_Set, // #pragma (push[, id], value)
> +PSK_Pop_Set   = PSK_Pop | PSK_Set,  // #pragma (pop[, id], value)
> +  };
> +
>template
>struct PragmaStack {
>  struct Slot {
> @@ -377,18 +358,84 @@ public:
>   PragmaMsStackAction Action,
>   llvm::StringRef StackSlotLabel,
>   ValueType Value);
> -explicit PragmaStack(const ValueType )
> -  : CurrentValue(Value) {}
> +
> +// MSVC seems to add artificial slots to #pragma stacks on entering a
> C++
> +// method body to restore the stacks on exit, so it works like this:
> +//
> +//   struct S {
> +// #pragma (push, InternalPragmaSlot,
> )
> +// void Method {}
> +// #pragma (pop, InternalPragmaSlot)
> +//   };
> +//
> +// It works even with #pragma vtordisp, although MSVC doesn't support
> +//   #pragma vtordisp(push [, id], n)
> +// syntax.
> +//
> +// Push / pop a named sentinel slot.
> +void SentinelAction(PragmaMsStackAction Action, StringRef Label) {
> +  assert((Action == PSK_Push || Action == PSK_Pop) &&
> + "Can only push / pop #pragma stack sentinels!");
> +  Act(CurrentPragmaLocation, Action, Label, CurrentValue);
> +}
> +
> +// Constructors.
> +explicit PragmaStack(const ValueType )
> +: DefaultValue(Default), CurrentValue(Default) {}
> +
>  SmallVector Stack;
> +ValueType DefaultValue; // Value used for PSK_Reset action.
>  ValueType CurrentValue;
>  SourceLocation CurrentPragmaLocation;
>};
>// FIXME: We should serialize / deserialize these if they occur in a
> PCH (but
>// we shouldn't do so if they're in a module).
> +
> +  ///