Re: r253813 - Driver: Specifically tell the linker the target for mingw-w64

[Rafael Espíndola via cfe-commits]

This changes the linker from old-gnu to gnu. Are you sure you want to
that? I don't think the new linker takes a -target option. In any
case, it needs a test.

Cheers,
Rafael


On 22 November 2015 at 00:40, Martell Malone via cfe-commits
 wrote:
> Author: martell
> Date: Sat Nov 21 23:40:06 2015
> New Revision: 253813
>
> URL: http://llvm.org/viewvc/llvm-project?rev=253813&view=rev
> Log:
> Driver: Specifically tell the linker the target for mingw-w64
>
> Cross compiling from linux and OSX results in Error: Exec format.
> This is because the linker is expecting ELF formated objects.
> By passing the target we can explicitly tell the linker that
> it should be linking COFF objects regardless of the host.
>
> Modified:
> cfe/trunk/lib/Driver/Tools.cpp
>
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=253813&r1=253812&r2=253813&view=diff
> ==
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Sat Nov 21 23:40:06 2015
> @@ -9478,7 +9478,14 @@ void MinGW::Linker::ConstructJob(Compila
>StringRef LinkerName = Args.getLastArgValue(options::OPT_fuse_ld_EQ, "ld");
>if (LinkerName.equals_lower("lld")) {
>  CmdArgs.push_back("-flavor");
> -CmdArgs.push_back("old-gnu");
> +CmdArgs.push_back("gnu");
> +CmdArgs.push_back("-target");
> +if (TC.getArch() == llvm::Triple::x86)
> +  CmdArgs.push_back("i686--windows-gnu");
> +if (TC.getArch() == llvm::Triple::x86_64)
> +  CmdArgs.push_back("x86_64--windows-gnu");
> +if (TC.getArch() == llvm::Triple::arm)
> +  CmdArgs.push_back("armv7--windows-gnu");
>} else if (!LinkerName.equals_lower("ld")) {
>  D.Diag(diag::err_drv_unsupported_linker) << LinkerName;
>}
>
>
> ___
> 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: r253813 - Driver: Specifically tell the linker the target for mingw-w64

[Rafael Espíndola via cfe-commits]

On 23 November 2015 at 11:15, Martell Malone  wrote:
>> This changes the linker from old-gnu to gnu. Are you sure you want to
>> that?
>
> Originally I didn't actually mean to commit that. I had been working on some
> stuff locally.
> Pointing to the new one should be fine as neither work for COFF atm anyway
> so no point in having it point to the old one.
> I'll make lld more verbose about this when it receives this emulation
> target.


The new "gnu" is just ELF.

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

Re: r253874 - Revert part of r253813

[Rafael Espíndola via cfe-commits]

This still needs a testcase.

On 23 November 2015 at 11:04, Martell Malone via cfe-commits
 wrote:
> Author: martell
> Date: Mon Nov 23 10:04:55 2015
> New Revision: 253874
>
> URL: http://llvm.org/viewvc/llvm-project?rev=253874&view=rev
> Log:
> Revert part of r253813
> The new lld gnu frontend does not support the -target option
>
> Modified:
> cfe/trunk/lib/Driver/Tools.cpp
>
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=253874&r1=253873&r2=253874&view=diff
> ==
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Mon Nov 23 10:04:55 2015
> @@ -9479,13 +9479,6 @@ void MinGW::Linker::ConstructJob(Compila
>if (LinkerName.equals_lower("lld")) {
>  CmdArgs.push_back("-flavor");
>  CmdArgs.push_back("gnu");
> -CmdArgs.push_back("-target");
> -if (TC.getArch() == llvm::Triple::x86)
> -  CmdArgs.push_back("i686--windows-gnu");
> -if (TC.getArch() == llvm::Triple::x86_64)
> -  CmdArgs.push_back("x86_64--windows-gnu");
> -if (TC.getArch() == llvm::Triple::arm)
> -  CmdArgs.push_back("armv7--windows-gnu");
>} else if (!LinkerName.equals_lower("ld")) {
>  D.Diag(diag::err_drv_unsupported_linker) << LinkerName;
>}
>
>
> ___
> 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: r253815 - Test: Update mingw-useld.c to reflect r253813

[Rafael Espíndola via cfe-commits]

This (and all the patches in this series) look odd.

The new "gnu" is ELF only. What exactly are you trying to do?

Cheers,
Rafael


On 22 November 2015 at 00:45, Martell Malone via cfe-commits
 wrote:
> Author: martell
> Date: Sat Nov 21 23:45:03 2015
> New Revision: 253815
>
> URL: http://llvm.org/viewvc/llvm-project?rev=253815&view=rev
> Log:
> Test: Update mingw-useld.c to reflect r253813
>
> Modified:
> cfe/trunk/test/Driver/mingw-useld.c
>
> Modified: cfe/trunk/test/Driver/mingw-useld.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/mingw-useld.c?rev=253815&r1=253814&r2=253815&view=diff
> ==
> --- cfe/trunk/test/Driver/mingw-useld.c (original)
> +++ cfe/trunk/test/Driver/mingw-useld.c Sat Nov 21 23:45:03 2015
> @@ -1,19 +1,19 @@
>  // RUN: %clang -### -target i686-pc-windows-gnu 
> --sysroot=%S/Inputs/mingw_clang_tree/mingw32 %s 2>&1 | FileCheck 
> -check-prefix=CHECK_LD_32 %s
>  // CHECK_LD_32: {{ld|ld.exe}}"
>  // CHECK_LD_32: "i386pe"
> -// CHECK_LD_32-NOT: "-flavor" "old-gnu"
> +// CHECK_LD_32-NOT: "-flavor" "gnu"
>
>  // RUN: %clang -### -target i686-pc-windows-gnu 
> --sysroot=%S/Inputs/mingw_clang_tree/mingw32 %s -fuse-ld=lld 2>&1 | FileCheck 
> -check-prefix=CHECK_LLD_32 %s
>  // CHECK_LLD_32-NOT: invalid linker name in argument
> -// CHECK_LLD_32: lld" "-flavor" "old-gnu"
> +// CHECK_LLD_32: lld" "-flavor" "gnu"
>  // CHECK_LLD_32: "i386pe"
>
>  // RUN: %clang -### -target x86_64-pc-windows-gnu 
> --sysroot=%S/Inputs/mingw_clang_tree/mingw32 %s -fuse-ld=lld 2>&1 | FileCheck 
> -check-prefix=CHECK_LLD_64 %s
>  // CHECK_LLD_64-NOT: invalid linker name in argument
> -// CHECK_LLD_64: lld" "-flavor" "old-gnu"
> +// CHECK_LLD_64: lld" "-flavor" "gnu"
>  // CHECK_LLD_64: "i386pep"
>
>  // RUN: %clang -### -target arm-pc-windows-gnu 
> --sysroot=%S/Inputs/mingw_clang_tree/mingw32 %s -fuse-ld=lld 2>&1 | FileCheck 
> -check-prefix=CHECK_LLD_ARM %s
>  // CHECK_LLD_ARM-NOT: invalid linker name in argument
> -// CHECK_LLD_ARM: lld" "-flavor" "old-gnu"
> +// CHECK_LLD_ARM: lld" "-flavor" "gnu"
>  // CHECK_LLD_ARM: "thumb2pe"
>
>
> ___
> 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]: Allow the use of i386/darwin with ELF

[Rafael Espíndola via cfe-commits]

It at least needs a testcase.

Cheers,
Rafael


On 13 December 2015 at 09:53, Luboš Doležel  wrote:
> Hello,
>
> I'm the developer of Darling, a translation layer for running OS X
> binaries on Linux.
>
> I'm facing many difficulties due to the following differences in i386
> ABI between Darwin and Linux:
>
> * size_t on Darwin/i386 is 'unsigned long', but Linux/i386 uses
> 'unsigned int' (=> different mangled names).
> * long double on Darwin/i386 is 128 bits long, but Linux/i386 uses only
> 96 bits.
>
> This problem can be overcome by specifying '-target
> i386-unknown-darwin-elf', but this currently fails due to a different
> data layout string (Darwin specifies Mach-O).
>
> The attached patch allows the use of ELF with the DarwinI386 target. It
> is identical to what is already done in the WindowsX86_32 target.
>
> Pretty please, include my patch, as it would be very helpful and it's a
> rather small change.
>
> Thanks,
> --
> Luboš Doležel
>
> ___
> 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: r255840 - Fix funciton->function typo.

[Rafael Espíndola via cfe-commits]

Thanks :-)
On Dec 16, 2015 6:13 PM, "Eric Christopher via cfe-commits" <
cfe-commits@lists.llvm.org> wrote:

> Author: echristo
> Date: Wed Dec 16 17:10:46 2015
> New Revision: 255840
>
> URL: http://llvm.org/viewvc/llvm-project?rev=255840&view=rev
> Log:
> Fix funciton->function typo.
>
> Modified:
> cfe/trunk/lib/ARCMigrate/ObjCMT.cpp
> cfe/trunk/lib/AST/MicrosoftMangle.cpp
> cfe/trunk/lib/CodeGen/CGDebugInfo.h
>
> Modified: cfe/trunk/lib/ARCMigrate/ObjCMT.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ARCMigrate/ObjCMT.cpp?rev=255840&r1=255839&r2=255840&view=diff
>
> ==
> --- cfe/trunk/lib/ARCMigrate/ObjCMT.cpp (original)
> +++ cfe/trunk/lib/ARCMigrate/ObjCMT.cpp Wed Dec 16 17:10:46 2015
> @@ -1524,7 +1524,7 @@ ObjCMigrateASTConsumer::CF_BRIDGING_KIND
>
>  FuncDecl->hasAttr() ||
>
>  FuncDecl->hasAttr());
>
> -  // Trivial case of when funciton is annotated and has no argument.
> +  // Trivial case of when function is annotated and has no argument.
>if (FuncIsReturnAnnotated && FuncDecl->getNumParams() == 0)
>  return CF_BRIDGING_NONE;
>
> @@ -1653,7 +1653,7 @@ void ObjCMigrateASTConsumer::migrateAddM
>  Editor->commit(commit);
>}
>
> -  // Trivial case of when funciton is annotated and has no argument.
> +  // Trivial case of when function is annotated and has no argument.
>if (MethodIsReturnAnnotated &&
>(MethodDecl->param_begin() == MethodDecl->param_end()))
>  return;
>
> Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=255840&r1=255839&r2=255840&view=diff
>
> ==
> --- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
> +++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Wed Dec 16 17:10:46 2015
> @@ -422,7 +422,7 @@ void MicrosoftCXXNameMangler::mangleFunc
>  // We would like to mangle all extern "C" functions using this
> additional
>  // component but this would break compatibility with MSVC's behavior.
>  // Instead, do this when we know that compatibility isn't important
> (in
> -// other words, when it is an overloaded extern "C" funciton).
> +// other words, when it is an overloaded extern "C" function).
>  if (FD->isExternC() && FD->hasAttr())
>Out << "$$J0";
>
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.h?rev=255840&r1=255839&r2=255840&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.h (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.h Wed Dec 16 17:10:46 2015
> @@ -574,7 +574,7 @@ public:
>/// passing an empty SourceLocation to \a CGDebugInfo::setLocation()
>/// will result in the last valid location being reused.  Note that
>/// all instructions that do not have a location at the beginning of
> -  /// a function are counted towards to funciton prologue.
> +  /// a function are counted towards to function prologue.
>static ApplyDebugLocation CreateEmpty(CodeGenFunction &CGF) {
>  return ApplyDebugLocation(CGF, true, SourceLocation());
>}
>
>
> ___
> 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: r255848 - [WebAssembly] Initial linking support.

[Rafael Espíndola via cfe-commits]

testcase?

Also, this is passing -target to ld, which is not a valid option.

Cheers,
Rafael


On 16 December 2015 at 18:30, Dan Gohman via cfe-commits
 wrote:
> Author: djg
> Date: Wed Dec 16 17:30:41 2015
> New Revision: 255848
>
> URL: http://llvm.org/viewvc/llvm-project?rev=255848&view=rev
> Log:
> [WebAssembly] Initial linking support.
>
> This begins minimal support for invoking 'ld' from clang for WebAssembly
> targets.
>
> Differential Revision: http://reviews.llvm.org/D15586
>
> Modified:
> cfe/trunk/lib/Driver/ToolChains.cpp
> cfe/trunk/lib/Driver/ToolChains.h
> cfe/trunk/lib/Driver/Tools.cpp
> cfe/trunk/lib/Driver/Tools.h
>
> Modified: cfe/trunk/lib/Driver/ToolChains.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=255848&r1=255847&r2=255848&view=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains.cpp Wed Dec 16 17:30:41 2015
> @@ -4418,6 +4418,13 @@ Tool *MyriadToolChain::buildLinker() con
>return new tools::Myriad::Linker(*this);
>  }
>
> +WebAssembly::WebAssembly(const Driver &D, const llvm::Triple &Triple,
> + const llvm::opt::ArgList &Args)
> +  : ToolChain(D, Triple, Args) {
> +  // Use LLD by default.
> +  DefaultLinker = "lld";
> +}
> +
>  bool WebAssembly::IsMathErrnoDefault() const { return false; }
>
>  bool WebAssembly::IsObjCNonFragileABIDefault() const { return true; }
> @@ -4440,6 +4447,8 @@ bool WebAssembly::hasBlocksRuntime() con
>  // TODO: Support profiling.
>  bool WebAssembly::SupportsProfiling() const { return false; }
>
> +bool WebAssembly::HasNativeLLVMSupport() const { return true; }
> +
>  void WebAssembly::addClangTargetOptions(const ArgList &DriverArgs,
>  ArgStringList &CC1Args) const {
>if (DriverArgs.hasFlag(options::OPT_fuse_init_array,
> @@ -4447,6 +4456,10 @@ void WebAssembly::addClangTargetOptions(
>  CC1Args.push_back("-fuse-init-array");
>  }
>
> +Tool *WebAssembly::buildLinker() const {
> +  return new tools::wasm::Linker(*this);
> +}
> +
>  PS4CPU::PS4CPU(const Driver &D, const llvm::Triple &Triple, const ArgList 
> &Args)
>  : Generic_ELF(D, Triple, Args) {
>if (Args.hasArg(options::OPT_static))
>
> Modified: cfe/trunk/lib/Driver/ToolChains.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.h?rev=255848&r1=255847&r2=255848&view=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains.h (original)
> +++ cfe/trunk/lib/Driver/ToolChains.h Wed Dec 16 17:30:41 2015
> @@ -1088,8 +1088,7 @@ private:
>  class LLVM_LIBRARY_VISIBILITY WebAssembly final : public ToolChain {
>  public:
>WebAssembly(const Driver &D, const llvm::Triple &Triple,
> -  const llvm::opt::ArgList &Args)
> -  : ToolChain(D, Triple, Args) {}
> +  const llvm::opt::ArgList &Args);
>
>  private:
>bool IsMathErrnoDefault() const override;
> @@ -1102,8 +1101,11 @@ private:
>bool hasBlocksRuntime() const override;
>bool SupportsObjCGC() const override;
>bool SupportsProfiling() const override;
> +  bool HasNativeLLVMSupport() const override;
>void addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
>   llvm::opt::ArgStringList &CC1Args) const 
> override;
> +
> +  Tool *buildLinker() const override;
>  };
>
>  class LLVM_LIBRARY_VISIBILITY PS4CPU : public Generic_ELF {
>
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=255848&r1=255847&r2=255848&view=diff
> ==
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Wed Dec 16 17:30:41 2015
> @@ -6439,6 +6439,34 @@ void amdgpu::Linker::ConstructJob(Compil
>  }
>  // AMDGPU tools end.
>
> +wasm::Linker::Linker(const ToolChain &TC)
> +  : GnuTool("wasm::Linker", "lld", TC) {}
> +
> +bool wasm::Linker::isLinkJob() const {
> +  return true;
> +}
> +
> +bool wasm::Linker::hasIntegratedCPP() const {
> +  return false;
> +}
> +
> +void wasm::Linker::ConstructJob(Compilation &C, const JobAction &JA,
> +const InputInfo &Output,
> +const InputInfoList &Inputs,
> +const ArgList &Args,
> +const char *LinkingOutput) const {
> +  const char *Linker = Args.MakeArgString(getToolChain().GetLinkerPath());
> +  ArgStringList CmdArgs;
> +  CmdArgs.push_back("-flavor");
> +  CmdArgs.push_back("ld");
> +  CmdArgs.push_back("-target");
> +  CmdArgs.push_back(Args.MakeArgString(getToolChain().getTripleString()));
> +  AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs);
> +  CmdArgs.push_back("-o");
> +  CmdArgs.push_back(Output

Re: [PATCH] D15598: [Driver] Make AddCXXStdlibLibArgs responsible for handling -static-libstdc++.

[Rafael Espíndola via cfe-commits]

I am not sure what is "expected" is here:

$ gcc test.o -o test.so -lstdc++ -shared -static-libstdc++ && ldd
test.so | grep libst
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7f848e57d000)

$ gcc test.o -o test.so -shared -static-libstdc++ -lstdc++ && ldd
test.so | grep libst
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7fc25516d000)



On 16 December 2015 at 20:34, Alexey Samsonov  wrote:
> samsonov created this revision.
> samsonov added reviewers: rafael, compnerd.
> samsonov added a subscriber: cfe-commits.
>
> After this change, AddCXXStdlibLibArgs will check the presence of
> -static-libstdc++ flag and, if necessary, wrap -lc++/-lstdc++ in
> -Bstatic/-Bdynamic to force static linking of C++ standard library.
>
> It's no longer necessary to copy this code around across toolchains
> (unless toolchain is overriding AddCXXStdlibLibArgs).
>
> This change has an important consequnce: if the user provides "-lstdc++"
> manually (i.e. it's not added automatically when we're linking C++ binary),
> then "-static-libstdc++" *will* work as expected.
>
> Other than that, the change attempts to preserve the existing behavior.
>
> http://reviews.llvm.org/D15598
>
> Files:
>   lib/Driver/CrossWindowsToolChain.cpp
>   lib/Driver/ToolChain.cpp
>   lib/Driver/ToolChains.cpp
>   lib/Driver/Tools.cpp
>   test/Driver/static-libstdcxx.c
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15598: [Driver] Make AddCXXStdlibLibArgs responsible for handling -static-libstdc++.

[Rafael Espíndola via cfe-commits]

On 18 December 2015 at 18:13, Alexey Samsonov  wrote:
> samsonov added a comment.
>
> In http://reviews.llvm.org/D15598#314127, @rafael wrote:
>
>> I am not sure what is "expected" is here:
>
>
> Interesting.
> I was assuming that Clang tends to understand "-lstdc++" as a special 
> argument that says "link against C++ standard library", not "link against 
> libstdc++.{a,so}".
> For instance,
>
>   clang a.cc -lstdc++ -stdlib=libc++
>
> will effectively replace "-lstdc++" with "-lc++", and
>
>   clang++ a.cc -stdlib=libc++ -static-libstdc++
>
> will link against libc++ statically. In that sense, it makes sense to assume 
> that "-static-libstdc++" will bind to "-lstdc++" argument.
>
> Apparently, it's not what GCC does :( Do you think we should keep being 
> compatible here?

My preference would be for -lstdc++ to be as least special as
possible. Do you know why -stdlib=libc++ is not a clang++ only option?

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

Re: [PATCH] D15641: [Driver] Pass -O* to the gold plugin via -plugin-opt

[Rafael Espíndola via cfe-commits]

>> This introduces a meaning to -ON during the link. That normally show up by 
>> people passing CFLAGS when linking.
>
> I'm not sure what you mean? When I build clang with cake the link is driven 
> by clang, it will accept the O flag by not propagate it to the actual linker. 
> How would CFLAGS help?

It doesn't. It is just a way -O3 sometimes ends up in a link (clang) line.

> Now we thought about that a few months ago and we were planning to do 
> something during the bring up of ThinLTO.
> The alternative to the command line flag is to encode the optimization level 
> in the bitcode itself.
> It may have the advantage (for ThinLTO) to be able to LTO each file with 
> different optimization level.

I don't have a strong preference one way or the other.

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

Re: r256134 - [Cygwin] Enable TLS as emutls.

[Rafael Espíndola via cfe-commits]

Can we delete

 config.available_features.add('tls')

now?

On 20 December 2015 at 21:37, NAKAMURA Takumi via cfe-commits
 wrote:
> Author: chapuni
> Date: Sun Dec 20 20:37:23 2015
> New Revision: 256134
>
> URL: http://llvm.org/viewvc/llvm-project?rev=256134&view=rev
> Log:
> [Cygwin] Enable TLS as emutls.
>
> It resolves clang selfhosting with std::once() for Cygwin.
>
> FIXME: It may be EmulatedTLS-generic also for X86-Android.
> FIXME: Pass EmulatedTLS to LLVM CodeGen from Clang with -femulated-tls.
>
> Modified:
> cfe/trunk/lib/Basic/Targets.cpp
> cfe/trunk/test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p2.cpp
> cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp
> cfe/trunk/test/PCH/chain-openmp-threadprivate.cpp
>
> Modified: cfe/trunk/lib/Basic/Targets.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=256134&r1=256133&r2=256134&view=diff
> ==
> --- cfe/trunk/lib/Basic/Targets.cpp (original)
> +++ cfe/trunk/lib/Basic/Targets.cpp Sun Dec 20 20:37:23 2015
> @@ -3834,7 +3834,6 @@ class CygwinX86_32TargetInfo : public X8
>  public:
>CygwinX86_32TargetInfo(const llvm::Triple &Triple)
>: X86_32TargetInfo(Triple) {
> -TLSSupported = false;
>  WCharType = UnsignedShort;
>  DoubleAlign = LongLongAlign = 64;
>  DataLayoutString = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32";
>
> Modified: 
> cfe/trunk/test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p2.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p2.cpp?rev=256134&r1=256133&r2=256134&view=diff
> ==
> --- cfe/trunk/test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p2.cpp 
> (original)
> +++ cfe/trunk/test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p2.cpp 
> Sun Dec 20 20:37:23 2015
> @@ -1,5 +1,4 @@
>  // RUN:  %clang_cc1 -std=c++14 -fconcepts-ts -x c++ -verify %s
> -// REQUIRES: tls
>
>  template concept thread_local bool VCTL = true; // 
> expected-error {{variable concept cannot be declared 'thread_local'}}
>
>
> Modified: cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp?rev=256134&r1=256133&r2=256134&view=diff
> ==
> --- cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp (original)
> +++ cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp Sun Dec 20 20:37:23 2015
> @@ -11,7 +11,6 @@
>  // RUN: %clang_cc1 -verify -fopenmp -x c++ -std=c++11 -DLAMBDA -triple 
> %itanium_abi_triple -emit-llvm %s -o - | FileCheck -check-prefix=TLS-LAMBDA %s
>  // RUN: %clang_cc1 -verify -fopenmp -x c++ -fblocks -DBLOCKS -triple 
> %itanium_abi_triple -emit-llvm %s -o - | FileCheck -check-prefix=TLS-BLOCKS %s
>  // RUN: %clang_cc1 -verify -fopenmp -x c++ -std=c++11 -DARRAY -triple 
> x86_64-linux-gnu -emit-llvm %s -o - | FileCheck -check-prefix=TLS-ARRAY %s
> -// REQUIRES: tls
>  // expected-no-diagnostics
>  #ifndef ARRAY
>  #ifndef HEADER
>
> Modified: cfe/trunk/test/PCH/chain-openmp-threadprivate.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/chain-openmp-threadprivate.cpp?rev=256134&r1=256133&r2=256134&view=diff
> ==
> --- cfe/trunk/test/PCH/chain-openmp-threadprivate.cpp (original)
> +++ cfe/trunk/test/PCH/chain-openmp-threadprivate.cpp Sun Dec 20 20:37:23 2015
> @@ -9,8 +9,6 @@
>  // RUN: %clang_cc1 -fopenmp -emit-llvm -chain-include %s -chain-include %s 
> %s -o - | FileCheck %s -check-prefix=CHECK-TLS-1
>  // RUN: %clang_cc1 -fopenmp -emit-llvm -chain-include %s -chain-include %s 
> %s -o - | FileCheck %s -check-prefix=CHECK-TLS-2
>
> -// REQUIRES: tls
> -
>  #if !defined(PASS1)
>  #define PASS1
>
>
>
> ___
> 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] D15705: Adding a scripted test for PR25717

[Rafael Espíndola via cfe-commits]

Can't you use the preprocessor to  produce a large output? See the
testcase in https://llvm.org/bugs/show_bug.cgi?id=10651#c10 for
example.

Cheers,
Rafael

On 21 December 2015 at 20:07, Yunzhong Gao via cfe-commits
 wrote:
> ygao created this revision.
> ygao added subscribers: cfe-commits, rsandifo, majnemer, aaron.ballman.
>
> Hi,
> I am trying to add a test for PR25717. The test itself is fairly 
> straight-forward: it generates a
> large .c temporary file on the fly and then runs the preprocessor over the 
> generated file to
> make sure we do not see any unexpected fatal errors.
> I have never added a scripted test before, so it would be really nice if 
> someone with this
> experience could take a look that I did make all the necessary changes.
> Many thanks in advance,
> - Gao
>
> http://reviews.llvm.org/D15705
>
> Files:
>   test/Preprocessor/bigoutput.py
>   test/Preprocessor/lit.local.cfg
>
> Index: test/Preprocessor/lit.local.cfg
> ===
> --- test/Preprocessor/lit.local.cfg
> +++ test/Preprocessor/lit.local.cfg
> @@ -0,0 +1,2 @@
> +config.suffixes = ['.c', '.cpp', '.m', '.mm', '.cu', '.cl', '.s', '.S', 
> '.py']
> +
> Index: test/Preprocessor/bigoutput.py
> ===
> --- test/Preprocessor/bigoutput.py
> +++ test/Preprocessor/bigoutput.py
> @@ -0,0 +1,11 @@
> +# RUN: python %s
> +# RUN: %clang_cc1 -E -x c bigoutput.c | FileCheck %s
> +
> +# Make sure clang does not crash during preprocessing
> +# CHECK-NOT: fatal error
> +
> +f = open("bigoutput.c", "wb")
> +for i in range(0, 15000):
> +  # this test requires UNIX line endings
> +  f.write("int v%d;\n" % i)
> +f.close()
>
>
>
> ___
> 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: r256216 - [WebAssembly] Remove the -target command-line flag from the ld commandline.

[Rafael Espíndola via cfe-commits]

Thanks!

On 21 December 2015 at 18:30, Dan Gohman via cfe-commits
 wrote:
> Author: djg
> Date: Mon Dec 21 17:30:41 2015
> New Revision: 256216
>
> URL: http://llvm.org/viewvc/llvm-project?rev=256216&view=rev
> Log:
> [WebAssembly] Remove the -target command-line flag from the ld commandline.
>
> This flag isn't needed, or permitted, with the "ld" flavor of lld.
>
> Also, add a basic ld commandline test.
>
> Added:
> cfe/trunk/test/Driver/wasm-toolchain.c
> Modified:
> cfe/trunk/lib/Driver/Tools.cpp
>
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=256216&r1=256215&r2=256216&view=diff
> ==
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Mon Dec 21 17:30:41 2015
> @@ -6516,8 +6516,6 @@ void wasm::Linker::ConstructJob(Compilat
>ArgStringList CmdArgs;
>CmdArgs.push_back("-flavor");
>CmdArgs.push_back("ld");
> -  CmdArgs.push_back("-target");
> -  CmdArgs.push_back(Args.MakeArgString(getToolChain().getTripleString()));
>AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs);
>CmdArgs.push_back("-o");
>CmdArgs.push_back(Output.getFilename());
>
> Added: cfe/trunk/test/Driver/wasm-toolchain.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/wasm-toolchain.c?rev=256216&view=auto
> ==
> --- cfe/trunk/test/Driver/wasm-toolchain.c (added)
> +++ cfe/trunk/test/Driver/wasm-toolchain.c Mon Dec 21 17:30:41 2015
> @@ -0,0 +1,3 @@
> +// RUN: %clang -### -target wasm32-unknown-unknown -x assembler %s 2>&1 | 
> FileCheck -check-prefix=AS_LINK %s
> +// AS_LINK: clang{{.*}}" "-cc1as" {{.*}} "-o" "[[temp:[^"]*]]"
> +// AS_LINK: lld" "-flavor" "ld" "[[temp]]" "-o" "a.out"
>
>
> ___
> 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] D15705: Adding a scripted test for PR25717

[Rafael Espíndola via cfe-commits]

Are you sure the line ending in a problem? The preprocessor output has
16 lines, but the last one is very long.

In any case, it looks like at least on linux clang produces an output
with '\n' even when the input has CRLF:

$ file test.c
test.c: ASCII text, with CRLF line terminators
$ clang -E test.c > test.i
$ file test.i
test.i: C source, ASCII text, with very long lines


Cheers,
Rafael

On 23 December 2015 at 15:22, Yunzhong Gao
 wrote:
> ygao updated this revision to Diff 43554.
> ygao added a comment.
>
> I think what I can do is to run
> svn propset svn:eol-style 'LF'
> on the new file, and hopefully the subversion or git client will get the hint 
> and not auto-translate the line endings.
>
>
> http://reviews.llvm.org/D15705
>
> Files:
>   test/Preprocessor/macro.c
>
> Index: test/Preprocessor/macro.c
> ===
> --- test/Preprocessor/macro.c
> +++ test/Preprocessor/macro.c
> @@ -0,0 +1,16 @@
> +// RUN: %clang_cc1 -E -x c %s | FileCheck %s
> +// The original bug requires UNIX line endings to trigger.
> +
> +// Make sure clang does not crash during preprocessing
> +// CHECK-NOT: fatal error
> +
> +#define M0 extern int x;
> +#define M2  M0  M0  M0  M0
> +#define M4  M2  M2  M2  M2
> +#define M6  M4  M4  M4  M4
> +#define M8  M6  M6  M6  M6
> +#define M10 M8  M8  M8  M8
> +#define M12 M10 M10 M10 M10
> +#define M14 M12 M12 M12 M12
> +
> +M14
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15705: Adding a scripted test for PR25717

[Rafael Espíndola via cfe-commits]

Gosh, that is quite unfortunate. The problems I see are

* The code only work on windows, as opening a file as text on other
systems is not special.
* There is a confusion in the code about binary being "crlf
translation" or "produce a .o". The logic for creating a buffer is
there because the .o writer needs something it can seek on.

What I would suggest is:

* Check that this test fails at least on windows with your patch
reverted. If so, commit it. BTW, don't you need to drop the "|
FileCheck" to cause a  crash?
* Pass two flags to createDefaultOutputFile: TranslateCrLf and
NeedsSeek instead of just Binary.
* Stop using F_Text flag and just print the correct line ending so
this works on any system.

The last two can be just a bug report for now :-)

Cheers,
Rafael



On 23 December 2015 at 17:43, Yunzhong Gao
 wrote:
> ygao added a comment.
>
> If you take a look at
>
>   void PrintPreprocessedAction::ExecuteAction() {
> ...
> while (next < end) {
> if (*cur == 0x0D) {  // CR
>   if (*next == 0x0A)  // CRLF
> BinaryMode = false;
> ...
>
> The value of this BinaryMode reflects whether the line ending style of the 
> input file
> is CRLF or LF. And it is passed all the way down to the constructor of 
> raw_fd_ostream,
>
>   std::unique_ptr 
> CompilerInstance::createOutputFile(...) {
>   ...
> if (!Binary || OS->supportsSeeking())
>   return std::move(OS);
>
> auto B = llvm::make_unique(*OS);
> ...
>
> So I think the line ending style of the input file does affect whether the 
> output is buffered.
>
>
> http://reviews.llvm.org/D15705
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH][Solaris] Add -lc also when linking shared libraries

[Rafael Espíndola via cfe-commits]

r247603

On 7 September 2015 at 13:22, Xan López via cfe-commits
 wrote:
> On Mon, Sep 07, 2015 at 09:07:41AM -0700, Saleem Abdulrasool wrote:
>> > Basically check that -lc is present when clang is called in a certain
>> > way I guess? Or something more sophisticated?
>>
>>
>> Yeah, that it is present when a DSO or executable is linked.
>
> Right, maybe something like this. Patch attached.
>
> (If it seems fine please commit it for me, I do not have commit
> rights)
>
> Xan
>
>
> ___
> 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][Solaris] Default to -fno-cxa-finalize

[Rafael Espíndola via cfe-commits]

From the driver point of view, how does it know if it is targeting
illumos or solaris? Do they use different triples?

In any case, if there is interest in the future this patch can be
extended to work on illumos by

* Creating a shouldUseCxaAtexitByDefault and passing in whatever
information is needed (Triple, a IsIlumos flag, etc)
* Using it instead of the long boolean expression we have right now.

For now I committed this as r247634.

Cheers,
Rafael



On 8 September 2015 at 09:47, Xan López via cfe-commits
 wrote:
> On Tue, Sep 08, 2015 at 03:28:12PM +0200, Joerg Sonnenberger via cfe-commits 
> wro> We don't distinguish Solaris and OpenSolaris forks currently. As such,
>> changing one for the other is not a good choice, especially since you
>> are more likely to find clang users for Illumos, IMO.
>>
>> https://www.illumos.org/issues/3849
>
> Well I'm still a bit confused about what were they using exactly,
> since I'm pretty sure clang has never worked in its upstream form in a
> general way from 2012/3. As I said maybe they ship a branch of their
> own or something, not sure.
>
> In any case Solaris is not Illumos, so we still need a
> solution. Should we add a way to distinguish between them and disable
> this feature only for Sun/Oracle Solaris? If they are diverging in
> things like this it seems sooner or later it would be needed anyway.
>
> Xan
>
>>
>> Joerg
>> ___
>> 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
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r248932 - [DarwinDriver] Use -lto_library to specify the path for libLTO.dylib

[Rafael Espíndola via cfe-commits]

Nice!

On 30 September 2015 at 15:55, Bruno Cardoso Lopes via cfe-commits
 wrote:
> Author: bruno
> Date: Wed Sep 30 14:55:07 2015
> New Revision: 248932
>
> URL: http://llvm.org/viewvc/llvm-project?rev=248932&view=rev
> Log:
> [DarwinDriver] Use -lto_library to specify the path for libLTO.dylib
>
> Usually, when using LTO with a clang installation newer than the
> system's one, there's a libLTO.dylib version mismatch and LTO fails. One
> solution to this is to make ld point to the right libLTO.dylib by
> changing DYLD_LIBRARY_PATH.
>
> However, ld64 supports specifying the complete path to the desired
> libLTO.dylib through the -lto_library option. This commit adds support
> for the clang driver to use this option whenever it's capable of finding
> a libLTO.dylib in clang's installed library directory. This way, we
> don't need to rely on DYLD_LIBRARY_PATH nor get caught by version
> mismatches.
>
> Differential Revision: http://reviews.llvm.org/D13117
>
> rdar://problem/7363476
>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
> cfe/trunk/lib/Driver/Tools.cpp
> cfe/trunk/test/Driver/darwin-ld.c
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=248932&r1=248931&r2=248932&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Wed Sep 30 
> 14:55:07 2015
> @@ -117,6 +117,7 @@ def err_drv_optimization_remark_pattern
>  def err_drv_no_neon_modifier : Error<"[no]neon is not accepted as modifier, 
> please use [no]simd instead">;
>
>  def warn_O4_is_O3 : Warning<"-O4 is equivalent to -O3">, InGroup;
> +def warn_lto_libpath : Warning<"libLTO.dylib relative to clang installed dir 
> not found; using 'ld' default search path instead">;
>  def warn_drv_optimization_value : Warning<"optimization level '%0' is not 
> supported; using '%1%2' instead">,
>InGroup;
>  def warn_ignored_gcc_optimization : Warning<"optimization flag '%0' is not 
> supported">,
>
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=248932&r1=248931&r2=248932&view=diff
> ==
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Wed Sep 30 14:55:07 2015
> @@ -6551,15 +6551,34 @@ void darwin::Linker::AddLinkArgs(Compila
> options::OPT_fno_application_extension, false))
>  CmdArgs.push_back("-application_extension");
>
> -  // If we are using LTO, then automatically create a temporary file path for
> -  // the linker to use, so that it's lifetime will extend past a possible
> -  // dsymutil step.
> -  if (Version[0] >= 116 && D.IsUsingLTO(Args) && NeedsTempPath(Inputs)) {
> -const char *TmpPath = C.getArgs().MakeArgString(
> -D.GetTemporaryPath("cc", 
> types::getTypeTempSuffix(types::TY_Object)));
> -C.addTempFile(TmpPath);
> -CmdArgs.push_back("-object_path_lto");
> -CmdArgs.push_back(TmpPath);
> +  if (D.IsUsingLTO(Args)) {
> +// If we are using LTO, then automatically create a temporary file path 
> for
> +// the linker to use, so that it's lifetime will extend past a possible
> +// dsymutil step.
> +if (Version[0] >= 116 && NeedsTempPath(Inputs)) {
> +  const char *TmpPath = C.getArgs().MakeArgString(
> +  D.GetTemporaryPath("cc", 
> types::getTypeTempSuffix(types::TY_Object)));
> +  C.addTempFile(TmpPath);
> +  CmdArgs.push_back("-object_path_lto");
> +  CmdArgs.push_back(TmpPath);
> +}
> +
> +// Use -lto_library option to specify the libLTO.dylib path. Try to find
> +// it in clang installed libraries. If not found, the option is not used
> +// and 'ld' will use its default mechanism to search for libLTO.dylib.
> +if (Version[0] >= 133) {
> +  // Search for libLTO in /../lib/libLTO.dylib
> +  StringRef P = llvm::sys::path::parent_path(D.getInstalledDir());
> +  SmallString<128> LibLTOPath(P);
> +  llvm::sys::path::append(LibLTOPath, "lib");
> +  llvm::sys::path::append(LibLTOPath, "libLTO.dylib");
> +  if (llvm::sys::fs::exists(LibLTOPath)) {
> +CmdArgs.push_back("-lto_library");
> +CmdArgs.push_back(C.getArgs().MakeArgString(LibLTOPath));
> +  } else {
> +D.Diag(diag::warn_lto_libpath);
> +  }
> +}
>}
>
>// Derived from the "link" spec.
>
> Modified: cfe/trunk/test/Driver/darwin-ld.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-ld.c?rev=248932&r1=248931&r2=248932&view=diff
> ==
> --- cfe/trunk/test/Driver/darwin-ld.c (original)
> +++ cfe/trunk/test/Driver/darwin-l

Re: r249395 - BasicTests: Suppress InMemoryFileSystemTest.WindowsPath on win32 while investigating.

[Rafael Espíndola via cfe-commits]

What was the error?

On 6 October 2015 at 08:16, NAKAMURA Takumi via cfe-commits
 wrote:
> Author: chapuni
> Date: Tue Oct  6 07:16:27 2015
> New Revision: 249395
>
> URL: http://llvm.org/viewvc/llvm-project?rev=249395&view=rev
> Log:
> BasicTests: Suppress InMemoryFileSystemTest.WindowsPath on win32 while 
> investigating.
>
> Modified:
> cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>
> Modified: cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp?rev=249395&r1=249394&r2=249395&view=diff
> ==
> --- cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp (original)
> +++ cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp Tue Oct  6 07:16:27 
> 2015
> @@ -536,7 +536,9 @@ TEST_F(InMemoryFileSystemTest, IsEmpty)
>  TEST_F(InMemoryFileSystemTest, WindowsPath) {
>FS.addFile("c:/windows/system128/foo.cpp", 0, 
> MemoryBuffer::getMemBuffer(""));
>auto Stat = FS.status("c:");
> +#if !defined(_WIN32)
>ASSERT_FALSE(Stat.getError()) << Stat.getError() << FS.toString();
> +#endif
>Stat = FS.status("c:/windows/system128/foo.cpp");
>ASSERT_FALSE(Stat.getError()) << Stat.getError() << FS.toString();
>FS.addFile("d:/windows/foo.cpp", 0, MemoryBuffer::getMemBuffer(""));
>
>
> ___
> 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] D20748: Handle recursion in LLVMIRGeneration Timer

[Rafael Espíndola via cfe-commits]

Since we found only one user, I think my preference is to handle it there.

Cheers,
Rafael


On 8 June 2016 at 13:49, Vedant Kumar  wrote:
> vsk added a comment.
>
> Ping, any updates on this patch?
>
>
> http://reviews.llvm.org/D20748
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Add support for musl-libc on Linux

[Rafael Espíndola via cfe-commits]

Should musl really be an environment? What happens when targeting ARM,
do we get a gnueabi+musl? Is it used as an environment when
configuring gcc?

Cheers,
Rafael


On 13 June 2016 at 08:20, Lei Zhang via cfe-commits
 wrote:
> 2016-06-13 3:07 GMT+08:00 Joerg Sonnenberger :
>> On Sun, Jun 12, 2016 at 10:51:11AM +0800, Lei Zhang via llvm-commits wrote:
>>> Hi,
>>>
>>> I'm replying to this thread; sorry I wasn't subscribed to the list,
>>> thus cannot reply to it directly.
>>>
>>> http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160606/161733.html
>>>
>>> Joerg, thanks for your reply. Could you please tell me what kind of
>>> test cases I should prepare?
>>
>> The target/triple parser has a unit test in
>> unittests/ADT/TripleTest.cpp. The rest should get output validation in
>> clang's test/Driver directory. Not sure which one is the primary
>> GNU/Linux test.
>
> Thanks for the pointer :)
>
> The patches are re-attached with test cases included. Do they look sane 
> enough?
>
>
> Lei
>
> ___
> 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: Add support for musl-libc on Linux

[Rafael Espíndola via cfe-commits]

On 13 June 2016 at 09:25, Lei Zhang  wrote:
> 2016-06-13 21:02 GMT+08:00 Rafael Espíndola :
>> Should musl really be an environment? What happens when targeting ARM,
>> do we get a gnueabi+musl? Is it used as an environment when
>> configuring gcc?
>
> Honestly I couldn't judge if musl *should* be an environment. But it
> *is* used as an environment when configuring gcc, and
> "x86_64-pc-linux-musl" could be parsed by config.sub as a valid
> triplet.
>
> As for ARM, I guess something like arm-linux-musleabi would do.


OK, it is slightly annoying that we will have a Foo and FooMusl
environments, but if that is what is used for configuring gnu tools I
think it is the correct thing for us to do.

So the patch LGTM. We can extend it to handle other architectures once it is in.

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

Re: [gentoo-musl] Re: Add support for musl-libc on Linux

[Rafael Espíndola via cfe-commits]

Do you need someone to commit it for you?
On Jun 13, 2016 9:50 AM, "Lei Zhang via cfe-commits" <
cfe-commits@lists.llvm.org> wrote:

> 2016-06-13 21:21 GMT+08:00 Felix Janda :
> > [Added CC to the musl list]
> >
> > Lei Zhang wrote:
> >> 2016-06-13 3:07 GMT+08:00 Joerg Sonnenberger :
> >> > On Sun, Jun 12, 2016 at 10:51:11AM +0800, Lei Zhang via llvm-commits
> wrote:
> >> >> Hi,
> >> >>
> >> >> I'm replying to this thread; sorry I wasn't subscribed to the list,
> >> >> thus cannot reply to it directly.
> >> >>
> >> >>
> http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160606/161733.html
> >> >>
> >> >> Joerg, thanks for your reply. Could you please tell me what kind of
> >> >> test cases I should prepare?
> >> >
> >> > The target/triple parser has a unit test in
> >> > unittests/ADT/TripleTest.cpp. The rest should get output validation in
> >> > clang's test/Driver directory. Not sure which one is the primary
> >> > GNU/Linux test.
> >>
> >> Thanks for the pointer :)
> >>
> >> The patches are re-attached with test cases included. Do they look sane
> enough?
> >
> >> --- lib/Driver/ToolChains.cpp   (revision 272546)
> >> +++ lib/Driver/ToolChains.cpp   (working copy)
> >> @@ -4152,6 +4152,8 @@
> >>
> >>if (Triple.isAndroid())
> >>  return Triple.isArch64Bit() ? "/system/bin/linker64" :
> "/system/bin/linker";
> >> +  else if (Triple.getEnvironment() == llvm::Triple::Musl)
> >> +return "/lib/ld-musl-" + Triple.getArchName().str() + ".so.1";
> >
> > It does not seem to me that the dynamic linker name detection will work
> > on most archs not in the test cases. For example, the arm gentoo musl
> > stage3's have the target triple
>
> You're right. Frankly I've only had x86 platforms on my mind so far;
> but I agree with Rafael that we could extend this to other archs in
> the future.
>
> > It seems difficult to get all cases right and some of them might not be
> > very interesting, but it would be nice to have a more intelligent patch.
> > See for example
> >
> >
> http://git.alpinelinux.org/cgit/aports/plain/main/clang/clang-0004-Add-musl-targets-and-dynamic-linker.patch
>
> This looks neat :)
>
>
> Lei
> ___
> 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: [gentoo-musl] Re: Add support for musl-libc on Linux

[Rafael Espíndola via cfe-commits]

On 13 June 2016 at 21:07, Lei Zhang  wrote:
> 2016-06-14 5:00 GMT+08:00 Rafael Espíndola :
>> Do you need someone to commit it for you?
>
> Yes, please :)

Committed.

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

Re: r272656 - Add loop pragma for Loop Distribution

[Rafael Espíndola via cfe-commits]

Looks like this broke the docs:
http://lab.llvm.org:8011/builders/clang-sphinx-docs/builds/14690/steps/docs-clang-html/logs/stdio

Cheers,
Rafael


On 14 June 2016 at 08:04, Adam Nemet via cfe-commits
 wrote:
> Author: anemet
> Date: Tue Jun 14 07:04:26 2016
> New Revision: 272656
>
> URL: http://llvm.org/viewvc/llvm-project?rev=272656&view=rev
> Log:
> Add loop pragma for Loop Distribution
>
> Summary:
> This is similar to other loop pragmas like 'vectorize'.  Currently it
> only has state values: distribute(enable) and distribute(disable).  When
> one of these is specified the corresponding loop metadata is generated:
>
>   !{!"llvm.loop.distribute.enable", i1 true/false}
>
> As a result, loop distribution will be attempted on the loop even if
> Loop Distribution in not enabled globally.  Analogously, with 'disable'
> distribution can be turned off for an individual loop even when the pass
> is otherwise enabled.
>
> There are some slight differences compared to the existing loop pragmas.
>
> 1. There is no 'assume_safety' variant which makes its handling slightly
> different from 'vectorize'/'interleave'.
>
> 2. Unlike the existing loop pragmas, it does not have a corresponding
> numeric pragma like 'vectorize' -> 'vectorize_width'.  So for the
> consistency checks in CheckForIncompatibleAttributes we don't need to
> check it against other pragmas.  We just need to check for duplicates of
> the same pragma.
>
> Reviewers: rsmith, dexonsmith, aaron.ballman
>
> Subscribers: bob.wilson, cfe-commits, hfinkel
>
> Differential Revision: http://reviews.llvm.org/D19403
>
> Modified:
> cfe/trunk/docs/LanguageExtensions.rst
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
> cfe/trunk/lib/CodeGen/CGLoopInfo.cpp
> cfe/trunk/lib/CodeGen/CGLoopInfo.h
> cfe/trunk/lib/Parse/ParsePragma.cpp
> cfe/trunk/lib/Sema/SemaStmtAttr.cpp
> cfe/trunk/test/CodeGenCXX/pragma-loop.cpp
> cfe/trunk/test/Misc/ast-print-pragmas.cpp
> cfe/trunk/test/PCH/pragma-loop.cpp
> cfe/trunk/test/Parser/pragma-loop-safety.cpp
> cfe/trunk/test/Parser/pragma-loop.cpp
>
> Modified: cfe/trunk/docs/LanguageExtensions.rst
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=272656&r1=272655&r2=272656&view=diff
> ==
> --- cfe/trunk/docs/LanguageExtensions.rst (original)
> +++ cfe/trunk/docs/LanguageExtensions.rst Tue Jun 14 07:04:26 2016
> @@ -2050,9 +2050,9 @@ Extensions for loop hint optimizations
>
>  The ``#pragma clang loop`` directive is used to specify hints for optimizing 
> the
>  subsequent for, while, do-while, or c++11 range-based for loop. The directive
> -provides options for vectorization, interleaving, and unrolling. Loop hints 
> can
> -be specified before any loop and will be ignored if the optimization is not 
> safe
> -to apply.
> +provides options for vectorization, interleaving, unrolling and
> +distribution. Loop hints can be specified before any loop and will be 
> ignored if
> +the optimization is not safe to apply.
>
>  Vectorization and Interleaving
>  --
> @@ -2147,6 +2147,38 @@ to the same code size limit as with ``un
>
>  Unrolling of a loop can be prevented by specifying ``unroll(disable)``.
>
> +Loop Distribution
> +-
> +
> +Loop Distribution allows splitting a loop into multiple loops.  This is
> +beneficial for example when the entire loop cannot be vectorized but some of 
> the
> +resulting loops can.
> +
> +If ``distribute(enable))'' is specified and the loop has memory dependencies
> +that inhibit vectorization, the compiler will attempt to isolate the 
> offending
> +operations into a new loop.  This optimization is not enabled by default, 
> only
> +loops marked with the pragma are considered.
> +
> +.. code-block:: c++
> +
> +  #pragma clang loop distribute(enable)
> +  for (i = 0; i < N; ++i) {
> +S1: A[i + 1] = A[i] + B[i];
> +S2: C[i] = D[i] * E[i];
> +  }
> +
> +This loop will be split into two loops between statements S1 and S2.  The
> +second loop containing S2 will be vectorized.
> +
> +Loop Distribution is currently not enabled by default in the optimizer 
> because
> +it can hurt performance in some cases.  For example, instruction-level
> +parallelism could be reduced by sequentializing the execution of the
> +statements S1 and S2 above.
> +
> +If Loop Distribution is turned on globally with
> +``-mllvm -enable-loop-distribution``, specifying ``distribute(disable)`` can
> +be used the disable it on a per-loop basis.
> +
>  Additional Information
>  --
>
>
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=272656&r1=272655&r2=272656&view=diff
> ==
> --- cfe/trunk/include/clan

Re: [gentoo-musl] Re: Add support for musl-libc on Linux

[Rafael Espíndola via cfe-commits]

r272825,

Thanks,
Rafael


On 15 June 2016 at 04:28, Lei Zhang  wrote:
> 2016-06-14 20:55 GMT+08:00 Rafael Espíndola :
>> On 13 June 2016 at 21:07, Lei Zhang  wrote:
>>> 2016-06-14 5:00 GMT+08:00 Rafael Espíndola :
 Do you need someone to commit it for you?
>>>
>>> Yes, please :)
>>
>> Committed.
>
> Thanks!
>
> Here's another patch including test cases for various non-x86 archs,
> which should just work with my previous patches. ARM is left out
> purposely since it involves extra complexity. I'll work on it later.
>
>
> Lei
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[Patch] Add a ENABLE_X86_RELAX_RELOCATIONS cmake option

[Rafael Espíndola via cfe-commits]

This corresponds to binutils' --enable-x86-relax-relocations.

Cheers,
Rafael
From 1d5920b88d06afe0575313f3b2fc327a5069e32c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rafael=20=C3=81vila=20de=20Esp=C3=ADndola?=
 
Date: Fri, 17 Jun 2016 15:33:29 -0400
Subject: [PATCH] Add a ENABLE_X86_RELAX_RELOCATIONS  cmake option.

This corresponds to binutils' --enable-x86-relax-relocations.
---
 CMakeLists.txt  | 3 +++
 include/clang/Config/config.h.cmake | 3 +++
 lib/Driver/Tools.cpp| 2 +-
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8516644..114d230 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -185,6 +185,9 @@ set(DEFAULT_SYSROOT "" CACHE PATH
 
 set(ENABLE_LINKER_BUILD_ID OFF CACHE BOOL "pass --build-id to ld")
 
+set(ENABLE_X86_RELAX_RELOCATIONS OFF CACHE BOOL
+"enable x86 relax relocations by default")
+
 set(CLANG_DEFAULT_CXX_STDLIB "" CACHE STRING
   "Default C++ stdlib to use (empty for architecture default, \"libstdc++\" or \"libc++\"")
 if (NOT(CLANG_DEFAULT_CXX_STDLIB STREQUAL "" OR
diff --git a/include/clang/Config/config.h.cmake b/include/clang/Config/config.h.cmake
index 09f5e4b..e5a1d0d 100644
--- a/include/clang/Config/config.h.cmake
+++ b/include/clang/Config/config.h.cmake
@@ -41,4 +41,7 @@
 /* pass --build-id to ld */
 #cmakedefine ENABLE_LINKER_BUILD_ID
 
+/* enable x86 relax relocations by default */
+#cmakedefine01 ENABLE_X86_RELAX_RELOCATIONS
+
 #endif
diff --git a/lib/Driver/Tools.cpp b/lib/Driver/Tools.cpp
index b911c17..6152291 100644
--- a/lib/Driver/Tools.cpp
+++ b/lib/Driver/Tools.cpp
@@ -2837,7 +2837,7 @@ static void CollectArgsForIntegratedAssembler(Compilation &C,
   // options.
   bool CompressDebugSections = false;
 
-  bool UseRelaxRelocations = false;
+  bool UseRelaxRelocations = ENABLE_X86_RELAX_RELOCATIONS;
   const char *MipsTargetFeature = nullptr;
   for (const Arg *A :
Args.filtered(options::OPT_Wa_COMMA, options::OPT_Xassembler)) {
-- 
2.5.5

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

Re: r273016 - Driver: introduce and use `-isystem-after` for cross-windows

[Rafael Espíndola via cfe-commits]

Looks like this broke a few bots:

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/7311

Cheers,
Rafael


On 17 June 2016 at 13:23, Saleem Abdulrasool via cfe-commits
 wrote:
> Author: compnerd
> Date: Fri Jun 17 12:23:16 2016
> New Revision: 273016
>
> URL: http://llvm.org/viewvc/llvm-project?rev=273016&view=rev
> Log:
> Driver: introduce and use `-isystem-after` for cross-windows
>
> This mirrors the many other -i*after options to insert a new system search
> directory at the end of the search path.  This makes it possible to actually
> inject a search path after the resource dir.  This option is similar in spirit
> to the /imsvc option in the clang-cl driver.  This is needed to properly use 
> the
> driver for Windows targets where the clang headers wrap some of the system
> headers.
>
> This concept is actually useful on other targets (e.g. Linux) and would be
> really easy to support on the core toolchain.
>
> Modified:
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/lib/Driver/CrossWindowsToolChain.cpp
> cfe/trunk/lib/Driver/Tools.cpp
> cfe/trunk/test/Driver/windows-cross.c
>
> Modified: cfe/trunk/include/clang/Driver/Options.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=273016&r1=273015&r2=273016&view=diff
> ==
> --- cfe/trunk/include/clang/Driver/Options.td (original)
> +++ cfe/trunk/include/clang/Driver/Options.td Fri Jun 17 12:23:16 2016
> @@ -1277,6 +1277,9 @@ def isysroot : JoinedOrSeparate<["-"], "
>  def isystem : JoinedOrSeparate<["-"], "isystem">, Group,
>Flags<[CC1Option]>,
>HelpText<"Add directory to SYSTEM include search path">, 
> MetaVarName<"">;
> +def isystem_after : JoinedOrSeparate<["-"], "isystem-after">,
> +  Group, Flags<[DriverOption]>, MetaVarName<"">,
> +  HelpText<"Add directory to end of the SYSTEM include search path">;
>  def iwithprefixbefore : JoinedOrSeparate<["-"], "iwithprefixbefore">, 
> Group,
>HelpText<"Set directory to include search path with prefix">, 
> MetaVarName<"">,
>Flags<[CC1Option]>;
>
> Modified: cfe/trunk/lib/Driver/CrossWindowsToolChain.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/CrossWindowsToolChain.cpp?rev=273016&r1=273015&r2=273016&view=diff
> ==
> --- cfe/trunk/lib/Driver/CrossWindowsToolChain.cpp (original)
> +++ cfe/trunk/lib/Driver/CrossWindowsToolChain.cpp Fri Jun 17 12:23:16 2016
> @@ -62,6 +62,8 @@ AddClangSystemIncludeArgs(const llvm::op
>  llvm::sys::path::append(ResourceDir, "include");
>  addSystemInclude(DriverArgs, CC1Args, ResourceDir);
>}
> +  for (const auto &P : 
> DriverArgs.getAllArgValues(options::OPT_isystem_after))
> +addSystemInclude(DriverArgs, CC1Args, P);
>addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/usr/include");
>  }
>
>
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=273016&r1=273015&r2=273016&view=diff
> ==
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Fri Jun 17 12:23:16 2016
> @@ -502,6 +502,13 @@ void Clang::AddPreprocessingOptions(Comp
> << 
> A->getAsString(Args);
>  }
>}
> +} else if (A->getOption().matches(options::OPT_isystem_after)) {
> +  // Handling of paths which must come late.  These entries are handled 
> by
> +  // the toolchain itself after the resource dir is inserted in the right
> +  // search order.
> +  // Do not claim the argument so that the use of the argument does not
> +  // silently go unnoticed on toolchains which do not honour the option.
> +  continue;
>  }
>
>  // Not translated, render as usual.
>
> Modified: cfe/trunk/test/Driver/windows-cross.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/windows-cross.c?rev=273016&r1=273015&r2=273016&view=diff
> ==
> --- cfe/trunk/test/Driver/windows-cross.c (original)
> +++ cfe/trunk/test/Driver/windows-cross.c Fri Jun 17 12:23:16 2016
> @@ -67,3 +67,10 @@
>  // CHECK-SANITIZE-TSAN: error: unsupported argument 'tsan' to option 
> 'fsanitize='
>  // CHECK-SANITIZE-TSAN-NOT: "-fsanitize={{.*}}"
>
> +// RUN: %clang -### -target armv7-windows-itanium -isystem-after "Windows 
> Kits/10/Include/10.0.10586.0/ucrt" -isystem-after "Windows 
> Kits/10/Include/10.0.10586.0/um" -isystem-after "Windows 
> Kits/10/Include/10.0.10586.0/shared" -c %s -o /dev/null 2>&1 \
> +// RUN: | FileCheck %s --check-prefix CHECK-ISYSTEM-AFTER
> +// CHECK-ISYSTEM-AFTER: "-internal-isystem" "{{.*}}/clang/3.9.0/include"
> +// CHECK-ISYSTEM-AFTER: "

Re: [gentoo-musl] Re: Add support for musl-libc on Linux

[Rafael Espíndola via cfe-commits]

There are probably a few more places that need to be patched.

In particular, take a look at lib/Target/ARM. There are things like
computeTargetABI and isTargetHardFloat that probably need to be
updated (and tested).

CCing Peter for an arm opinion.

Cheers,
Rafael


On 17 June 2016 at 05:50, Lei Zhang  wrote:
> 2016-06-15 16:28 GMT+08:00 Lei Zhang :
>> Here's another patch including test cases for various non-x86 archs,
>> which should just work with my previous patches. ARM is left out
>> purposely since it involves extra complexity. I'll work on it later.
>
> Hi,
>
> Here are another two patches which add support for ARM, with some test
> cases included.
>
> They're a lot bigger than previous patches, and I'm not 100% sure if I
> missed anything. Any comments are utterly welcome :)
>
>
> Lei
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r273312 - Re-commit "[Temporary] Add an ExprWithCleanups for each C++ MaterializeTemporaryExpr."

[Rafael Espíndola via cfe-commits]

I think this broke the build on windows:

 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/7421/steps/build/logs/stdio

Cheers,
Rafael


On 21 June 2016 at 16:29, Tim Shen via cfe-commits
 wrote:
> Author: timshen
> Date: Tue Jun 21 15:29:17 2016
> New Revision: 273312
>
> URL: http://llvm.org/viewvc/llvm-project?rev=273312&view=rev
> Log:
> Re-commit "[Temporary] Add an ExprWithCleanups for each C++ 
> MaterializeTemporaryExpr."
>
> Since D21243 fixes relative clang-tidy tests.
>
> This reverts commit a71d9fbd41e99def9159af2b01ef6509394eaeed.
>
> Added:
> cfe/trunk/include/clang/Sema/CleanupInfo.h
> Modified:
> cfe/trunk/include/clang/AST/ExprCXX.h
> cfe/trunk/include/clang/AST/Stmt.h
> cfe/trunk/include/clang/Sema/ScopeInfo.h
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/AST/Expr.cpp
> cfe/trunk/lib/AST/ExprCXX.cpp
> cfe/trunk/lib/Analysis/Consumed.cpp
> cfe/trunk/lib/CodeGen/CGExprConstant.cpp
> cfe/trunk/lib/Sema/Sema.cpp
> cfe/trunk/lib/Sema/SemaCast.cpp
> cfe/trunk/lib/Sema/SemaCoroutine.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/lib/Sema/SemaExprCXX.cpp
> cfe/trunk/lib/Sema/SemaExprObjC.cpp
> cfe/trunk/lib/Sema/SemaInit.cpp
> cfe/trunk/lib/Sema/SemaLambda.cpp
> cfe/trunk/lib/Sema/SemaOpenMP.cpp
> cfe/trunk/lib/Sema/SemaStmt.cpp
> cfe/trunk/lib/Serialization/ASTReaderStmt.cpp
> cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
> cfe/trunk/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
>
> Modified: cfe/trunk/include/clang/AST/ExprCXX.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprCXX.h?rev=273312&r1=273311&r2=273312&view=diff
> ==
> --- cfe/trunk/include/clang/AST/ExprCXX.h (original)
> +++ cfe/trunk/include/clang/AST/ExprCXX.h Tue Jun 21 15:29:17 2016
> @@ -2872,7 +2872,8 @@ private:
>Stmt *SubExpr;
>
>ExprWithCleanups(EmptyShell, unsigned NumObjects);
> -  ExprWithCleanups(Expr *SubExpr, ArrayRef Objects);
> +  ExprWithCleanups(Expr *SubExpr, bool CleanupsHaveSideEffects,
> +   ArrayRef Objects);
>
>friend TrailingObjects;
>friend class ASTStmtReader;
> @@ -2882,6 +2883,7 @@ public:
>unsigned numObjects);
>
>static ExprWithCleanups *Create(const ASTContext &C, Expr *subexpr,
> +  bool CleanupsHaveSideEffects,
>ArrayRef objects);
>
>ArrayRef getObjects() const {
> @@ -2898,6 +2900,9 @@ public:
>
>Expr *getSubExpr() { return cast(SubExpr); }
>const Expr *getSubExpr() const { return cast(SubExpr); }
> +  bool cleanupsHaveSideEffects() const {
> +return ExprWithCleanupsBits.CleanupsHaveSideEffects;
> +  }
>
>/// As with any mutator of the AST, be very careful
>/// when modifying an existing AST to preserve its invariants.
>
> Modified: cfe/trunk/include/clang/AST/Stmt.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Stmt.h?rev=273312&r1=273311&r2=273312&view=diff
> ==
> --- cfe/trunk/include/clang/AST/Stmt.h (original)
> +++ cfe/trunk/include/clang/AST/Stmt.h Tue Jun 21 15:29:17 2016
> @@ -192,7 +192,10 @@ protected:
>
>  unsigned : NumExprBits;
>
> -unsigned NumObjects : 32 - NumExprBits;
> +// When false, it must not have side effects.
> +bool CleanupsHaveSideEffects : 1;
> +
> +unsigned NumObjects : 32 - 1 - NumExprBits;
>};
>
>class PseudoObjectExprBitfields {
>
> Added: cfe/trunk/include/clang/Sema/CleanupInfo.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/CleanupInfo.h?rev=273312&view=auto
> ==
> --- cfe/trunk/include/clang/Sema/CleanupInfo.h (added)
> +++ cfe/trunk/include/clang/Sema/CleanupInfo.h Tue Jun 21 15:29:17 2016
> @@ -0,0 +1,47 @@
> +//===--- CleanupInfo.cpp - Cleanup Control in Sema 
> ===//
> +//
> +// The LLVM Compiler Infrastructure
> +//
> +// This file is distributed under the University of Illinois Open Source
> +// License. See LICENSE.TXT for details.
> +//
> +//===--===//
> +//
> +//  This file implements a set of operations on whether generating an
> +//  ExprWithCleanups in a full expression.
> +//
> +//===--===//
> +
> +#ifndef LLVM_CLANG_SEMA_CLEANUP_INFO_H
> +#define LLVM_CLANG_SEMA_CLEANUP_INFO_H
> +
> +namespace clang {
> +
> +class CleanupInfo {
> +  bool ExprNeedsCleanups = false;
> +  bool CleanupsHaveSideEffects = false;
> +
> +public:
> +  bool exprNeedsCleanups() const { return ExprNeedsCleanups; }
> +
> +  boo

[PATCH] Restructure the propagation of -fPIC/-fPIE.

[Rafael Espíndola via cfe-commits]

The PIC and PIE levels are not independent. In fact, if PIE is defined
it is always the same as PIC.

This is clear in the driver where ParsePICArgs returns a PIC level and
a IsPIE boolean. Unfortunately that is currently lost and we pass two
redundant levels down the pipeline.

This patch keeps a bool and a PIC level all the way down to codegen. I
intend to send a patch for LLVM tomorrow so that CodeGen too can be
simplified.

Cheers,
Rafael
From e36fea8d8fb20a549da60c22a1cd0751fa6ea70d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rafael=20=C3=81vila=20de=20Esp=C3=ADndola?=
 
Date: Tue, 21 Jun 2016 18:46:31 -0400
Subject: [PATCH] Restructure the propagation of -fPIC/-fPIE.

The PIC and PIE levels are not independent. In fact, if PIE is defined
it is always the same as PIC.

This is clear in the driver where ParsePICArgs returns a PIC level and
a IsPIE boolean. Unfortunately that is currently lost and we pass two
redundant levels down the pipeline.

This patch keeps a bool and a PIC level all the way down to codegen. I
intend to send a patch for LLVM tomorrow so that CodeGen too can be
simplified.
---
 include/clang/Basic/LangOptions.def   |  2 +-
 include/clang/Driver/CC1Options.td|  2 --
 include/clang/Driver/Options.td   |  2 +-
 lib/CodeGen/CGObjCGNU.cpp |  2 +-
 lib/CodeGen/CodeGenModule.cpp |  7 ++-
 lib/Driver/Tools.cpp  |  6 ++
 lib/Frontend/CompilerInvocation.cpp   |  4 ++--
 lib/Frontend/InitPreprocessor.cpp |  8 
 test/Driver/fsanitize.c   |  2 +-
 test/Driver/pic.c | 10 +-
 test/Driver/ps4-pic.c |  4 ++--
 test/Modules/explicit-build-flags.cpp |  2 +-
 test/Preprocessor/pic.c   | 12 ++--
 13 files changed, 28 insertions(+), 35 deletions(-)

diff --git a/include/clang/Basic/LangOptions.def b/include/clang/Basic/LangOptions.def
index 3fb4e97..0356196 100644
--- a/include/clang/Basic/LangOptions.def
+++ b/include/clang/Basic/LangOptions.def
@@ -158,7 +158,7 @@ VALUE_LANGOPT(MaxTypeAlign  , 32, 0,
   "default maximum alignment for types")
 VALUE_LANGOPT(AlignDouble, 1, 0, "Controls if doubles should be aligned to 8 bytes (x86 only)")
 COMPATIBLE_VALUE_LANGOPT(PICLevel, 2, 0, "__PIC__ level")
-COMPATIBLE_VALUE_LANGOPT(PIELevel, 2, 0, "__PIE__ level")
+COMPATIBLE_VALUE_LANGOPT(PIE , 1, 0, "is pie")
 COMPATIBLE_LANGOPT(GNUInline , 1, 0, "GNU inline semantics")
 COMPATIBLE_LANGOPT(NoInlineDefine, 1, 0, "__NO_INLINE__ predefined macro")
 COMPATIBLE_LANGOPT(Deprecated, 1, 0, "__DEPRECATED predefined macro")
diff --git a/include/clang/Driver/CC1Options.td b/include/clang/Driver/CC1Options.td
index f816844..d1dbda8 100644
--- a/include/clang/Driver/CC1Options.td
+++ b/include/clang/Driver/CC1Options.td
@@ -546,8 +546,6 @@ def fencode_extended_block_signature : Flag<["-"], "fencode-extended-block-signa
   HelpText<"enable extended encoding of block type signature">;
 def pic_level : Separate<["-"], "pic-level">,
   HelpText<"Value for __PIC__">;
-def pie_level : Separate<["-"], "pie-level">,
-  HelpText<"Value for __PIE__">;
 def fno_validate_pch : Flag<["-"], "fno-validate-pch">,
   HelpText<"Disable validation of precompiled headers">;
 def dump_deserialized_pch_decls : Flag<["-"], "dump-deserialized-decls">,
diff --git a/include/clang/Driver/Options.td b/include/clang/Driver/Options.td
index 9928758..d4c82bf 100644
--- a/include/clang/Driver/Options.td
+++ b/include/clang/Driver/Options.td
@@ -1034,7 +1034,7 @@ def fpcc_struct_return : Flag<["-"], "fpcc-struct-return">, Group, Flag
 def fpch_preprocess : Flag<["-"], "fpch-preprocess">, Group;
 def fpic : Flag<["-"], "fpic">, Group;
 def fno_pic : Flag<["-"], "fno-pic">, Group;
-def fpie : Flag<["-"], "fpie">, Group;
+def fpie : Flag<["-"], "fpie">, Group, Flags<[CC1Option]>;
 def fno_pie : Flag<["-"], "fno-pie">, Group;
 def fplugin_EQ : Joined<["-"], "fplugin=">, Group, Flags<[DriverOption]>, MetaVarName<"">,
   HelpText<"Load the named plugin (dynamic shared object)">;
diff --git a/lib/CodeGen/CGObjCGNU.cpp b/lib/CodeGen/CGObjCGNU.cpp
index bbe1b8b..f9f48c8 100644
--- a/lib/CodeGen/CGObjCGNU.cpp
+++ b/lib/CodeGen/CGObjCGNU.cpp
@@ -2830,7 +2830,7 @@ llvm::GlobalVariable *CGObjCGNU::ObjCIvarOffsetVariable(
 // to replace it with the real version for a library.  In non-PIC code you
 // must compile with the fragile ABI if you want to use ivars from a
 // GCC-compiled class.
-if (CGM.getLangOpts().PICLevel || CGM.getLangOpts().PIELevel) {
+if (CGM.getLangOpts().PICLevel) {
   llvm::GlobalVariable *IvarOffsetGV = new llvm::GlobalVariable(TheModule,
 Int32Ty, false,
 llvm::GlobalValue::PrivateLinkage, OffsetGuess, Name+".guess");
diff --git a/lib/CodeGen/CodeGenModule.cpp b/lib/CodeGen/CodeGenModule.cpp
index a8abe72..5077727 100644
--- a/lib/CodeGen/CodeGenModule.cpp
+++ b/lib/CodeGen/CodeGenModule.cpp
@@ -480,11 +480

Re: [PATCH] Restructure the propagation of -fPIC/-fPIE.

[Rafael Espíndola via cfe-commits]

On 21 June 2016 at 19:04, Joerg Sonnenberger via cfe-commits
 wrote:
> On Tue, Jun 21, 2016 at 06:53:03PM -0400, Rafael Espíndola via cfe-commits 
> wrote:
>> diff --git a/lib/Frontend/InitPreprocessor.cpp 
>> b/lib/Frontend/InitPreprocessor.cpp
>> index 27ef59a..6b93c69 100644
>> --- a/lib/Frontend/InitPreprocessor.cpp
>> +++ b/lib/Frontend/InitPreprocessor.cpp
>> @@ -873,10 +873,10 @@ static void InitializePredefinedMacros(const 
>> TargetInfo &TI,
>>if (unsigned PICLevel = LangOpts.PICLevel) {
>>  Builder.defineMacro("__PIC__", Twine(PICLevel));
>>  Builder.defineMacro("__pic__", Twine(PICLevel));
>> -  }
>> -  if (unsigned PIELevel = LangOpts.PIELevel) {
>> -Builder.defineMacro("__PIE__", Twine(PIELevel));
>> -Builder.defineMacro("__pie__", Twine(PIELevel));
>> +if (LangOpts.PIE) {
>> +  Builder.defineMacro("__PIE__", Twine(PICLevel));
>> +  Builder.defineMacro("__pie__", Twine(PICLevel));
>> +}
>>}
>>
>>// Macros to control C99 numerics and 
>
> This is the only part that I am somewhat nervous about, since it changes
> behavior in an externally visible way. I'm not sure what the code
> expectations are in the wild world right now.

I should not, or there is a bug.

It changes the driver to cc1 interface, but given driver invocation we
should be creating identical defines.

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

Re: [PATCH] D21830: Remove -mrelax-all from Clang -O0

[Rafael Espíndola via cfe-commits]

We need to benchmark this to see if it still makes a difference.

My canonical test is the .s of a lto of clang.

Cheers,
Rafael


On 29 June 2016 at 03:37, Dean Michael Berris  wrote:
> dberris created this revision.
> dberris added reviewers: echristo, rafael, grosbach.
> dberris added a subscriber: cfe-commits.
> Herald added a subscriber: mehdi_amini.
>
> Remove the -mrelax-all options passed onto the integrated assembler in
> -O0.
>
> http://reviews.llvm.org/D21830
>
> Files:
>   lib/Driver/Tools.cpp
>   test/Driver/integrated-as.c
>
> Index: test/Driver/integrated-as.c
> ===
> --- test/Driver/integrated-as.c
> +++ test/Driver/integrated-as.c
> @@ -1,7 +1,6 @@
>  // RUN: %clang -### -c -save-temps -integrated-as %s 2>&1 | FileCheck %s
>
>  // CHECK: cc1as
> -// CHECK: -mrelax-all
>
>  // RUN: %clang -### -fintegrated-as -c -save-temps %s 2>&1 | FileCheck %s 
> -check-prefix FIAS
>
> Index: lib/Driver/Tools.cpp
> ===
> --- lib/Driver/Tools.cpp
> +++ lib/Driver/Tools.cpp
> @@ -2721,38 +2721,10 @@
>return !UseDwarfDirectory;
>  }
>
> -/// \brief Check whether the given input tree contains any compilation 
> actions.
> -static bool ContainsCompileAction(const Action *A) {
> -  if (isa(A) || isa(A))
> -return true;
> -
> -  for (const auto &AI : A->inputs())
> -if (ContainsCompileAction(AI))
> -  return true;
> -
> -  return false;
> -}
> -
>  /// \brief Check if -relax-all should be passed to the internal assembler.
> -/// This is done by default when compiling non-assembler source with -O0.
>  static bool UseRelaxAll(Compilation &C, const ArgList &Args) {
> -  bool RelaxDefault = true;
> -
> -  if (Arg *A = Args.getLastArg(options::OPT_O_Group))
> -RelaxDefault = A->getOption().matches(options::OPT_O0);
> -
> -  if (RelaxDefault) {
> -RelaxDefault = false;
> -for (const auto &Act : C.getActions()) {
> -  if (ContainsCompileAction(Act)) {
> -RelaxDefault = true;
> -break;
> -  }
> -}
> -  }
> -
>return Args.hasFlag(options::OPT_mrelax_all, options::OPT_mno_relax_all,
> -  RelaxDefault);
> +  false);
>  }
>
>  // Convert an arg of the form "-gN" or "-ggdbN" or one of their aliases
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D21830: Remove -mrelax-all from Clang -O0

[Rafael Espíndola via cfe-commits]

On Wed, Jun 29, 2016, 17:43 Joerg Sonnenberger  wrote:

> On Wed, Jun 29, 2016 at 11:00:26AM -0400, Rafael Espíndola via cfe-commits
> wrote:
> > We need to benchmark this to see if it still makes a difference.
> >
> > My canonical test is the .s of a lto of clang.
>
> That won't exercise it? Assembler sources are exempt from this.
>
> Llvm-mc has the corresponding option.

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

Re: r284137 - [ThinLTO] Update doc to include lld (now supported).

[Rafael Espíndola via cfe-commits]

On 16 October 2016 at 22:13, Davide Italiano  wrote:
> On Sun, Oct 16, 2016 at 6:43 PM, Sean Silva  wrote:
>> Nice to see this land!
>>
>> One nit:
>> Currently, doesn't LLD/ELF ignore -plugin-opt? That will mean that if a user
>> uses the "gold syntax" then LLD will silently ignore it, which isn't good.
>> At the very least, can we issue an error if we see `-plugin-opt jobs=N` and
>> suggest the LLD spelling?
>>
>> Or maybe just accept the gold syntax? Our current handling of `-plugin` and
>> `-plugin-opt` is intended to make LLD transparently Do The Right Thing when
>> LLD is invoked as if it were gold, so clearly gold compatibility is
>> important enough for that. This suggests it is important enough to be
>> compatible from a ThinLTO perspective too.
>>
>
> I agree with what you're suggesting.  My initial vote would be for
> error'ing out on anything we can't understand that's passed via
> `-plugin-opt` and see what breaks (and add incremental support for
> every feature needed).
> Teresa, Rafael, any opinions about it?

I agree. Having clang known if it is using gold or lld is probably not worth it.

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

[patch] Don't use appending linkage for embeded bitcode

[Rafael Espíndola via cfe-commits]

Hi Steven,

I think there was a mistake when picking this linkage. The appending
linkage is really just for things that llvm itself special cases. By
an historical artifact it was codegened just like external.

The attached patch changes it to external linkage. I tested that the
produced .o file is bit by bit identical with this change.

But I have to ask, what is the intended use? I was under the
impression that the idea was to allow multiple .o files to have their
IR embedded and have the liker concatenate them.

Currently, with or without this patch, I expect you to get a
duplicated symbol error. To implement the above the symbol should be
internal end the GV added to llvm.used.

Cheers,
Rafael
diff --git a/lib/CodeGen/BackendUtil.cpp b/lib/CodeGen/BackendUtil.cpp
index bffa621..4f0a3ca 100644
--- a/lib/CodeGen/BackendUtil.cpp
+++ b/lib/CodeGen/BackendUtil.cpp
@@ -820,9 +820,8 @@ void clang::EmbedBitcode(llvm::Module *M, const 
CodeGenOptions &CGOpts,
   }
   llvm::Constant *ModuleConstant =
   llvm::ConstantDataArray::get(M->getContext(), ModuleData);
-  // Use Appending linkage so it doesn't get optimized out.
   llvm::GlobalVariable *GV = new llvm::GlobalVariable(
-  *M, ModuleConstant->getType(), true, llvm::GlobalValue::AppendingLinkage,
+  *M, ModuleConstant->getType(), true, llvm::GlobalValue::ExternalLinkage,
   ModuleConstant);
   GV->setSection(getSectionNameForBitcode(T));
   if (llvm::GlobalVariable *Old =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [patch] Don't use appending linkage for embeded bitcode

[Rafael Espíndola via cfe-commits]

On 13 May 2016 at 13:02, Steven Wu  wrote:
> Hi Rafael
>
> Thanks for notice this! That would definitely cause duplicated symbol error 
> and I should definitely change that.
> Here is some background:
> ld64 in Xcode 7+ knows how to handle the embedded bitcode correctly but not 
> the ones in earlier Xcode. The old ld64 will simply concatenate the bitcode 
> files which is not the right thing to do. So there is a symbol generated at 
> the place to prevent user to link the bitcode object file with old ld64 
> because older ld64 will fail and report duplicated symbols.
> I have a radar tracking to change the linkage type when upstream but I 
> dropped the ball on that one. The correct thing to do is to make it internal 
> and add to llvm.used. I will come up with a patch.

Thank you so much!

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

Re: [patch] Don't use appending linkage for embeded bitcode

[Rafael Espíndola via cfe-commits]

You can probably use collectUsedGlobalVariables.

You can probably also delete the FIXME about llvm.used and appending
linkage. I think the way to fix this is to make "can be dropped" an
independent property from the linkage and then we don't need llvm.used
at all.

Cheers,
Rafael


On 13 May 2016 at 17:01, Steven Wu  wrote:
> Attach a patch using private linkage type and adding to llvm.used. I have to 
> recreate llvm.used when embedding bitcode. I don't really like it but I don't 
> have better solutions.
> Few other options:
> 1. Not allowing re-embedded bitcode will simplify the code a bit but not a 
> lot.
> 2. Create a new "llvm.*.used" variable in llvm.metadata section.
> 3. Teach optimizer do not optimize away llvm.* variables.
>
>
>
>
> Steven
>
>> On May 13, 2016, at 10:10 AM, Rafael Espíndola  
>> wrote:
>>
>> On 13 May 2016 at 13:02, Steven Wu  wrote:
>>> Hi Rafael
>>>
>>> Thanks for notice this! That would definitely cause duplicated symbol error 
>>> and I should definitely change that.
>>> Here is some background:
>>> ld64 in Xcode 7+ knows how to handle the embedded bitcode correctly but not 
>>> the ones in earlier Xcode. The old ld64 will simply concatenate the bitcode 
>>> files which is not the right thing to do. So there is a symbol generated at 
>>> the place to prevent user to link the bitcode object file with old ld64 
>>> because older ld64 will fail and report duplicated symbols.
>>> I have a radar tracking to change the linkage type when upstream but I 
>>> dropped the ball on that one. The correct thing to do is to make it 
>>> internal and add to llvm.used. I will come up with a patch.
>>
>> Thank you so much!
>>
>> Cheers,
>> Rafael
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [patch] Don't use appending linkage for embeded bitcode

[Rafael Espíndola via cfe-commits]

+  auto Used = collectUsedGlobalVariables(*M, UsedGlobals, true);

Please use an explicit type instead of auto.

You deleted the assert

I think this is fine otherwise.

Cheers,
Rafael





On 13 May 2016 at 20:00, Steven Wu  wrote:
>
>> On May 13, 2016, at 3:56 PM, Duncan P. N. Exon Smith  
>> wrote:
>>
>> Is this something that you need the linker to treat as "used", or just 
>> something you don't want the compiler to drop?  If the latter, 
>> @llvm.compiler.used seems more appropriate.
>
> Bitcode is actually not really used by the compiler during compilation and 
> shouldn't really used by any part of the code. llvm.compiler.used then.
>
> New patch.
>
>
>
>
> Steven
>
>>
>>> On 2016-May-13, at 14:01, Steven Wu  wrote:
>>>
>>> Attach a patch using private linkage type and adding to llvm.used. I have 
>>> to recreate llvm.used when embedding bitcode. I don't really like it but I 
>>> don't have better solutions.
>>> Few other options:
>>> 1. Not allowing re-embedded bitcode will simplify the code a bit but not a 
>>> lot.
>>> 2. Create a new "llvm.*.used" variable in llvm.metadata section.
>>> 3. Teach optimizer do not optimize away llvm.* variables.
>>>
>>> <0001-Fix-embed-bitcode-linkage-type.patch>
>>>
>>> Steven
>>>
 On May 13, 2016, at 10:10 AM, Rafael Espíndola 
  wrote:

 On 13 May 2016 at 13:02, Steven Wu  wrote:
> Hi Rafael
>
> Thanks for notice this! That would definitely cause duplicated symbol 
> error and I should definitely change that.
> Here is some background:
> ld64 in Xcode 7+ knows how to handle the embedded bitcode correctly but 
> not the ones in earlier Xcode. The old ld64 will simply concatenate the 
> bitcode files which is not the right thing to do. So there is a symbol 
> generated at the place to prevent user to link the bitcode object file 
> with old ld64 because older ld64 will fail and report duplicated symbols.
> I have a radar tracking to change the linkage type when upstream but I 
> dropped the ball on that one. The correct thing to do is to make it 
> internal and add to llvm.used. I will come up with a patch.

 Thank you so much!

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

Re: [patch] Don't use appending linkage for embeded bitcode

[Rafael Espíndola via cfe-commits]

LGTM

On 16 May 2016 at 14:03, Steven Wu  wrote:
>
>> On May 16, 2016, at 6:52 AM, Rafael Espíndola  
>> wrote:
>>
>> +  auto Used = collectUsedGlobalVariables(*M, UsedGlobals, true);
>>
>> Please use an explicit type instead of auto.
>
> Sure.
>
>>
>> You deleted the assert
>
> Are you referring to the assertion that llvm.embedded.module has no uses. I 
> added it back to check it has exactly one use.
>
> Attach the final patch with testcase.
>
> Steven
>
>
>
>
>>
>> I think this is fine otherwise.
>>
>> Cheers,
>> Rafael
>>
>>
>>
>>
>>
>> On 13 May 2016 at 20:00, Steven Wu  wrote:
>>>
 On May 13, 2016, at 3:56 PM, Duncan P. N. Exon Smith 
  wrote:

 Is this something that you need the linker to treat as "used", or just 
 something you don't want the compiler to drop?  If the latter, 
 @llvm.compiler.used seems more appropriate.
>>>
>>> Bitcode is actually not really used by the compiler during compilation and 
>>> shouldn't really used by any part of the code. llvm.compiler.used then.
>>>
>>> New patch.
>>>
>>>
>>>
>>>
>>> Steven
>>>

> On 2016-May-13, at 14:01, Steven Wu  wrote:
>
> Attach a patch using private linkage type and adding to llvm.used. I have 
> to recreate llvm.used when embedding bitcode. I don't really like it but 
> I don't have better solutions.
> Few other options:
> 1. Not allowing re-embedded bitcode will simplify the code a bit but not 
> a lot.
> 2. Create a new "llvm.*.used" variable in llvm.metadata section.
> 3. Teach optimizer do not optimize away llvm.* variables.
>
> <0001-Fix-embed-bitcode-linkage-type.patch>
>
> Steven
>
>> On May 13, 2016, at 10:10 AM, Rafael Espíndola 
>>  wrote:
>>
>> On 13 May 2016 at 13:02, Steven Wu  wrote:
>>> Hi Rafael
>>>
>>> Thanks for notice this! That would definitely cause duplicated symbol 
>>> error and I should definitely change that.
>>> Here is some background:
>>> ld64 in Xcode 7+ knows how to handle the embedded bitcode correctly but 
>>> not the ones in earlier Xcode. The old ld64 will simply concatenate the 
>>> bitcode files which is not the right thing to do. So there is a symbol 
>>> generated at the place to prevent user to link the bitcode object file 
>>> with old ld64 because older ld64 will fail and report duplicated 
>>> symbols.
>>> I have a radar tracking to change the linkage type when upstream but I 
>>> dropped the ball on that one. The correct thing to do is to make it 
>>> internal and add to llvm.used. I will come up with a patch.
>>
>> Thank you so much!
>>
>> Cheers,
>> Rafael
>

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

Re: r269910 - Update for llvm change.

[Rafael Espíndola via cfe-commits]

yes, thanks.

Cheers,
Rafael


On 18 May 2016 at 19:10, Sean Silva  wrote:
>
>
> On Wed, May 18, 2016 at 4:58 AM, Rafael Espindola via cfe-commits
>  wrote:
>>
>> Author: rafael
>> Date: Wed May 18 06:58:56 2016
>> New Revision: 269910
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=269910&view=rev
>> Log:
>> Update for llvm change.
>>
>> Modified:
>> cfe/trunk/lib/Parse/ParseStmtAsm.cpp
>> cfe/trunk/tools/driver/cc1as_main.cpp
>>
>> Modified: cfe/trunk/lib/Parse/ParseStmtAsm.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseStmtAsm.cpp?rev=269910&r1=269909&r2=269910&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Parse/ParseStmtAsm.cpp (original)
>> +++ cfe/trunk/lib/Parse/ParseStmtAsm.cpp Wed May 18 06:58:56 2016
>> @@ -572,8 +572,8 @@ StmtResult Parser::ParseMicrosoftAsmStat
>>
>>llvm::SourceMgr TempSrcMgr;
>>llvm::MCContext Ctx(MAI.get(), MRI.get(), MOFI.get(), &TempSrcMgr);
>> -  MOFI->InitMCObjectFileInfo(TheTriple, llvm::Reloc::Default,
>> - llvm::CodeModel::Default, Ctx);
>> +  MOFI->InitMCObjectFileInfo(TheTriple, /*PIG*/ false,
>> llvm::CodeModel::Default,
>
>
> Did you mean "PIC" here insted of PIG?
>
> -- Sean Silva
>
>>
>> + Ctx);
>>std::unique_ptr Buffer =
>>llvm::MemoryBuffer::getMemBuffer(AsmString, "");
>>
>>
>> Modified: cfe/trunk/tools/driver/cc1as_main.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/cc1as_main.cpp?rev=269910&r1=269909&r2=269910&view=diff
>>
>> ==
>> --- cfe/trunk/tools/driver/cc1as_main.cpp (original)
>> +++ cfe/trunk/tools/driver/cc1as_main.cpp Wed May 18 06:58:56 2016
>> @@ -326,19 +326,18 @@ static bool ExecuteAssembler(AssemblerIn
>>
>>MCContext Ctx(MAI.get(), MRI.get(), MOFI.get(), &SrcMgr);
>>
>> -  llvm::Reloc::Model RM = llvm::Reloc::Default;
>> +  bool PIC = false;
>>if (Opts.RelocationModel == "static") {
>> -RM = llvm::Reloc::Static;
>> +PIC = false;
>>} else if (Opts.RelocationModel == "pic") {
>> -RM = llvm::Reloc::PIC_;
>> +PIC = true;
>>} else {
>>  assert(Opts.RelocationModel == "dynamic-no-pic" &&
>> "Invalid PIC model!");
>> -RM = llvm::Reloc::DynamicNoPIC;
>> +PIC = false;
>>}
>>
>> -  MOFI->InitMCObjectFileInfo(Triple(Opts.Triple), RM,
>> - CodeModel::Default, Ctx);
>> +  MOFI->InitMCObjectFileInfo(Triple(Opts.Triple), PIC,
>> CodeModel::Default, Ctx);
>>if (Opts.SaveTemporaryLabels)
>>  Ctx.setAllowTemporaryLabels(false);
>>if (Opts.GenDwarfForAssembly)
>>
>>
>> ___
>> 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] D20748: Handle recursion in LLVMIRGeneration Timer

[Rafael Espíndola via cfe-commits]

On 27 May 2016 at 17:32, Vedant Kumar  wrote:
> vsk added a comment.
>
> Comments on this patch -- The increment and decrement snippets seem like they 
> could be pulled into helper methods. That should make it easier to update all 
> users of LLVMIRGeneration. I wasn't able to come up with a regression test, 
> but I do think this patch needs one.
>
> Overall comments -- My main concern is that this isn't the only affected user 
> of the Timer class. I have a preference for http://reviews.llvm.org/D20735 
> because it defines the underlying problem away. I'll defer to someone else on 
> this (maybe @rafael?).

What is the other recursive use?

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

Re: r271211 - CodeGen: tweak CFConstantStrings for COFF and ELF

[Rafael Espíndola via cfe-commits]

Why .rodata.cfstring? Which linker treats that specially?

On 30 May 2016 at 12:23, Saleem Abdulrasool via cfe-commits
 wrote:
> Author: compnerd
> Date: Mon May 30 11:23:07 2016
> New Revision: 271211
>
> URL: http://llvm.org/viewvc/llvm-project?rev=271211&view=rev
> Log:
> CodeGen: tweak CFConstantStrings for COFF and ELF
>
> Adjust the constant CFString emission to emit into more appropriate sections 
> on
> ELF and COFF targets.  It would previously try to use MachO section names
> irrespective of the file format.
>
> Added:
> cfe/trunk/test/CodeGen/CFStrings.c
> Modified:
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=271211&r1=271210&r2=271211&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon May 30 11:23:07 2016
> @@ -3092,19 +3092,19 @@ CodeGenModule::GetAddrOfConstantCFString
>llvm::Constant *Zero = llvm::Constant::getNullValue(Int32Ty);
>llvm::Constant *Zeros[] = { Zero, Zero };
>llvm::Value *V;
> -
> +
>// If we don't already have it, get __CFConstantStringClassReference.
>if (!CFConstantStringClassRef) {
>  llvm::Type *Ty = getTypes().ConvertType(getContext().IntTy);
>  Ty = llvm::ArrayType::get(Ty, 0);
> -llvm::Constant *GV = CreateRuntimeVariable(Ty,
> -   
> "__CFConstantStringClassReference");
> +llvm::Constant *GV =
> +CreateRuntimeVariable(Ty, "__CFConstantStringClassReference");
>  // Decay array -> ptr
>  V = llvm::ConstantExpr::getGetElementPtr(Ty, GV, Zeros);
>  CFConstantStringClassRef = V;
> -  }
> -  else
> +  } else {
>  V = CFConstantStringClassRef;
> +  }
>
>QualType CFTy = getContext().getCFConstantStringType();
>
> @@ -3117,8 +3117,8 @@ CodeGenModule::GetAddrOfConstantCFString
>
>// Flags.
>llvm::Type *Ty = getTypes().ConvertType(getContext().UnsignedIntTy);
> -  Fields[1] = isUTF16 ? llvm::ConstantInt::get(Ty, 0x07d0) :
> -llvm::ConstantInt::get(Ty, 0x07C8);
> +  Fields[1] = isUTF16 ? llvm::ConstantInt::get(Ty, 0x07d0)
> +  : llvm::ConstantInt::get(Ty, 0x07C8);
>
>// String pointer.
>llvm::Constant *C = nullptr;
> @@ -3139,18 +3139,17 @@ CodeGenModule::GetAddrOfConstantCFString
>GV->setUnnamedAddr(true);
>// Don't enforce the target's minimum global alignment, since the only use
>// of the string is via this class initializer.
> -  // FIXME: We set the section explicitly to avoid a bug in ld64 224.1. 
> Without
> -  // it LLVM can merge the string with a non unnamed_addr one during LTO. 
> Doing
> -  // that changes the section it ends in, which surprises ld64.
> -  if (isUTF16) {
> -CharUnits Align = getContext().getTypeAlignInChars(getContext().ShortTy);
> -GV->setAlignment(Align.getQuantity());
> -GV->setSection("__TEXT,__ustring");
> -  } else {
> -CharUnits Align = getContext().getTypeAlignInChars(getContext().CharTy);
> -GV->setAlignment(Align.getQuantity());
> -GV->setSection("__TEXT,__cstring,cstring_literals");
> -  }
> +  CharUnits Align = isUTF16
> +? 
> getContext().getTypeAlignInChars(getContext().ShortTy)
> +: 
> getContext().getTypeAlignInChars(getContext().CharTy);
> +  GV->setAlignment(Align.getQuantity());
> +
> +  // FIXME: We set the section explicitly to avoid a bug in ld64 224.1.
> +  // Without it LLVM can merge the string with a non unnamed_addr one during
> +  // LTO.  Doing that changes the section it ends in, which surprises ld64.
> +  if (getTarget().getTriple().getObjectFormat() == llvm::Triple::MachO)
> +GV->setSection(isUTF16 ? "__TEXT,__ustring"
> +   : "__TEXT,__cstring,cstring_literals");
>
>// String.
>Fields[2] =
> @@ -3171,8 +3170,20 @@ CodeGenModule::GetAddrOfConstantCFString
>GV = new llvm::GlobalVariable(getModule(), C->getType(), true,
>  llvm::GlobalVariable::PrivateLinkage, C,
>  "_unnamed_cfstring_");
> -  GV->setSection("__DATA,__cfstring");
>GV->setAlignment(Alignment.getQuantity());
> +  switch (getTarget().getTriple().getObjectFormat()) {
> +  case llvm::Triple::UnknownObjectFormat:
> +llvm_unreachable("unknown file format");
> +  case llvm::Triple::COFF:
> +GV->setSection(".rdata.cfstring");
> +break;
> +  case llvm::Triple::ELF:
> +GV->setSection(".rodata.cfstring");
> +break;
> +  case llvm::Triple::MachO:
> +GV->setSection("__DATA,__cfstring");
> +break;
> +  }
>Entry.second = GV;
>
>return ConstantAddress(GV, Alignment);
>
> Added: cfe/trunk/test/CodeGen/CFStrings.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/CFStrings.c?rev=271211&view=auto
> =

Re: r271211 - CodeGen: tweak CFConstantStrings for COFF and ELF

[Rafael Espíndola via cfe-commits]

On 30 May 2016 at 16:48, Saleem Abdulrasool  wrote:
> On Mon, May 30, 2016 at 12:54 PM, Rafael Espíndola
>  wrote:
>>
>> Why .rodata.cfstring? Which linker treats that specially?
>
>
> Its mimicking the fact that the CF macros tried to place the structures in
> their own section.  This would technically allow a linker to coalesce the
> CFString structures (though, AFAIK, none do atm ... perhaps lld should be
> the first!).  In the worst case, this will just get collapsed into the
> .rodata section, so its no worse off.

BTW, if this is to be coalesced, I think the ELF way to do it would be
to mark the section SHF_MERGE and propose a new SHF_CFSTRING section
flag.

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

Re: r271288 - [ASTMatchers] Breaking change of `has` matcher

[Rafael Espíndola via cfe-commits]

This broke the build:
http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/36968/steps/cmake-configure/logs/stdio

On 31 May 2016 at 08:25, Piotr Padlewski via cfe-commits
 wrote:
> Author: prazek
> Date: Tue May 31 10:25:05 2016
> New Revision: 271288
>
> URL: http://llvm.org/viewvc/llvm-project?rev=271288&view=rev
> Log:
> [ASTMatchers] Breaking change of `has` matcher
>
> has matcher can now match to implicit and paren casts
>
> http://reviews.llvm.org/D20801
>
> Modified:
> cfe/trunk/docs/ReleaseNotes.rst
> cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
> cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> cfe/trunk/include/clang/CMakeLists.txt
> cfe/trunk/unittests/AST/ASTImporterTest.cpp
> cfe/trunk/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
>
> Modified: cfe/trunk/docs/ReleaseNotes.rst
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=271288&r1=271287&r2=271288&view=diff
> ==
> --- cfe/trunk/docs/ReleaseNotes.rst (original)
> +++ cfe/trunk/docs/ReleaseNotes.rst Tue May 31 10:25:05 2016
> @@ -185,11 +185,13 @@ this section should help get you past th
>  AST Matchers
>  
>
> -- hasAnyArgument: Matcher no longer ignores parentheses and implicit casts on
> -  the argument before applying the inner matcher. The fix was done to allow 
> for
> -  greater control by the user. In all existing checkers that use this matcher
> -  all instances of code ``hasAnyArgument()`` must be changed 
> to
> -  ``hasAnyArgument(ignoringParenImpCasts())``.
> +- has and hasAnyArgument: Matchers no longer ignores parentheses and implicit
> +  casts on the argument before applying the inner matcher. The fix was done 
> to
> +  allow for greater control by the user. In all existing checkers that use 
> this
> +  matcher all instances of code ``hasAnyArgument()`` or
> +  ``has()`` must be changed to
> +  ``hasAnyArgument(ignoringParenImpCasts())`` or
> +  ``has(ignoringParenImpCasts())``.
>
>  ...
>
>
> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=271288&r1=271287&r2=271288&view=diff
> ==
> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Tue May 31 10:25:05 2016
> @@ -2169,6 +2169,10 @@ AST_MATCHER_P(CXXRecordDecl, hasMethod,
>  /// ChildT must be an AST base type.
>  ///
>  /// Usable as: Any Matcher
> +/// Note that has is direct matcher, so it also matches things like implicit
> +/// casts and paren casts. If you are matching with expr then you should
> +/// probably consider using ignoringParenImpCasts like:
> +/// has(ignoringParenImpCasts(expr())).
>  const internal::ArgumentAdaptingMatcherFunc
>  LLVM_ATTRIBUTE_UNUSED has = {};
>
>
> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=271288&r1=271287&r2=271288&view=diff
> ==
> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Tue May 31 
> 10:25:05 2016
> @@ -1165,8 +1165,6 @@ public:
>  /// ChildT must be an AST base type.
>  template 
>  class HasMatcher : public WrapperMatcherInterface {
> -  static_assert(IsBaseType::value,
> -"has only accepts base type matcher");
>
>  public:
>explicit HasMatcher(const Matcher &ChildMatcher)
> @@ -1174,10 +1172,9 @@ public:
>
>bool matches(const T &Node, ASTMatchFinder *Finder,
> BoundNodesTreeBuilder *Builder) const override {
> -return Finder->matchesChildOf(
> -Node, this->InnerMatcher, Builder,
> -ASTMatchFinder::TK_IgnoreImplicitCastsAndParentheses,
> -ASTMatchFinder::BK_First);
> +return Finder->matchesChildOf(Node, this->InnerMatcher, Builder,
> +  ASTMatchFinder::TK_AsIs,
> +  ASTMatchFinder::BK_First);
>}
>  };
>
>
> Modified: cfe/trunk/include/clang/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/CMakeLists.txt?rev=271288&r1=271287&r2=271288&view=diff
> ==
> --- cfe/trunk/include/clang/CMakeLists.txt (original)
> +++ cfe/trunk/include/clang/CMakeLists.txt Tue May 31 10:25:05 2016
> @@ -5,3 +5,4 @@ add_subdirectory(Parse)
>  add_subdirectory(Sema)
>  add_subdirectory(Serialization)
>  add_subdirectory(StaticAnalyzer/Checkers)
> +add_subdirectory(ASTMatchers)
>
> Modified: cfe/trunk/unittests/AST/ASTImporterTest.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/c

Re: r271288 - [ASTMatchers] Breaking change of `has` matcher

[Rafael Espíndola via cfe-commits]

I think is just the usual "llvm.org is crazy slow". I am trying to commit.

Cheers,
Rafael


On 31 May 2016 at 08:54, Piotr Padlewski  wrote:
> dunno why but I can't fetch from upstream
>
> Can you push this change?
>
> - include/clang/CMakeLists.txt
> -
> index 96905c9..feb81f0 100644
> @@ -5,4 +5,3 @@ add_subdirectory(Parse)
>  add_subdirectory(Sema)
>  add_subdirectory(Serialization)
>  add_subdirectory(StaticAnalyzer/Checkers)
> -add_subdirectory(ASTMatchers)
>
> 2016-05-31 17:48 GMT+02:00 Piotr Padlewski :
>>
>> Yep, sending fix
>>
>> 2016-05-31 17:45 GMT+02:00 Rafael Espíndola :
>>>
>>> This broke the build:
>>>
>>> http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/36968/steps/cmake-configure/logs/stdio
>>>
>>> On 31 May 2016 at 08:25, Piotr Padlewski via cfe-commits
>>>  wrote:
>>> > Author: prazek
>>> > Date: Tue May 31 10:25:05 2016
>>> > New Revision: 271288
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=271288&view=rev
>>> > Log:
>>> > [ASTMatchers] Breaking change of `has` matcher
>>> >
>>> > has matcher can now match to implicit and paren casts
>>> >
>>> > http://reviews.llvm.org/D20801
>>> >
>>> > Modified:
>>> > cfe/trunk/docs/ReleaseNotes.rst
>>> > cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
>>> > cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>>> > cfe/trunk/include/clang/CMakeLists.txt
>>> > cfe/trunk/unittests/AST/ASTImporterTest.cpp
>>> > cfe/trunk/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
>>> >
>>> > Modified: cfe/trunk/docs/ReleaseNotes.rst
>>> > URL:
>>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=271288&r1=271287&r2=271288&view=diff
>>> >
>>> > ==
>>> > --- cfe/trunk/docs/ReleaseNotes.rst (original)
>>> > +++ cfe/trunk/docs/ReleaseNotes.rst Tue May 31 10:25:05 2016
>>> > @@ -185,11 +185,13 @@ this section should help get you past th
>>> >  AST Matchers
>>> >  
>>> >
>>> > -- hasAnyArgument: Matcher no longer ignores parentheses and implicit
>>> > casts on
>>> > -  the argument before applying the inner matcher. The fix was done to
>>> > allow for
>>> > -  greater control by the user. In all existing checkers that use this
>>> > matcher
>>> > -  all instances of code ``hasAnyArgument()`` must be
>>> > changed to
>>> > -  ``hasAnyArgument(ignoringParenImpCasts())``.
>>> > +- has and hasAnyArgument: Matchers no longer ignores parentheses and
>>> > implicit
>>> > +  casts on the argument before applying the inner matcher. The fix was
>>> > done to
>>> > +  allow for greater control by the user. In all existing checkers that
>>> > use this
>>> > +  matcher all instances of code ``hasAnyArgument()`` or
>>> > +  ``has()`` must be changed to
>>> > +  ``hasAnyArgument(ignoringParenImpCasts())`` or
>>> > +  ``has(ignoringParenImpCasts())``.
>>> >
>>> >  ...
>>> >
>>> >
>>> > Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
>>> > URL:
>>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=271288&r1=271287&r2=271288&view=diff
>>> >
>>> > ==
>>> > --- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
>>> > +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Tue May 31
>>> > 10:25:05 2016
>>> > @@ -2169,6 +2169,10 @@ AST_MATCHER_P(CXXRecordDecl, hasMethod,
>>> >  /// ChildT must be an AST base type.
>>> >  ///
>>> >  /// Usable as: Any Matcher
>>> > +/// Note that has is direct matcher, so it also matches things like
>>> > implicit
>>> > +/// casts and paren casts. If you are matching with expr then you
>>> > should
>>> > +/// probably consider using ignoringParenImpCasts like:
>>> > +/// has(ignoringParenImpCasts(expr())).
>>> >  const internal::ArgumentAdaptingMatcherFunc
>>> >  LLVM_ATTRIBUTE_UNUSED has = {};
>>> >
>>> >
>>> > Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>>> > URL:
>>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=271288&r1=271287&r2=271288&view=diff
>>> >
>>> > ==
>>> > --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>>> > (original)
>>> > +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Tue May
>>> > 31 10:25:05 2016
>>> > @@ -1165,8 +1165,6 @@ public:
>>> >  /// ChildT must be an AST base type.
>>> >  template 
>>> >  class HasMatcher : public WrapperMatcherInterface {
>>> > -  static_assert(IsBaseType::value,
>>> > -"has only accepts base type matcher");
>>> >
>>> >  public:
>>> >explicit HasMatcher(const Matcher &ChildMatcher)
>>> > @@ -1174,10 +1172,9 @@ public:
>>> >
>>> >bool matches(const T &Node, ASTMatchFinder *Finder,
>>> > BoundNodesTreeBuilder *Builder) const override {
>

Don't pass --build-id by default.

[Rafael Espíndola via cfe-commits]

We do it just because gcc in some distributions do it.

I can see why --build-id is useful for distributions, but given the
cost on day to day edit+build cycles, any distro using clang should
really just pass -Wl,--build-id in rpmbuild (or corresponding tool).

Even upstream gcc is not as aggressive as current clang. It has a
--enable-linker-build-id configure option and it defaults to false.

Cheers,
Rafael
diff --git a/lib/Driver/ToolChains.cpp b/lib/Driver/ToolChains.cpp
index a26ca08..9b79bf9 100644
--- a/lib/Driver/ToolChains.cpp
+++ b/lib/Driver/ToolChains.cpp
@@ -3928,11 +3928,6 @@ Linux::Linux(const Driver &D, const llvm::Triple 
&Triple, const ArgList &Args)
   if (IsRedhat(Distro) && Distro != RHEL5 && Distro != RHEL6)
 ExtraOpts.push_back("--no-add-needed");
 
-  if ((IsDebian(Distro) && Distro >= DebianSqueeze) || IsOpenSUSE(Distro) ||
-  (IsRedhat(Distro) && Distro != RHEL5) ||
-  (IsUbuntu(Distro) && Distro >= UbuntuKarmic))
-ExtraOpts.push_back("--build-id");
-
   if (IsOpenSUSE(Distro))
 ExtraOpts.push_back("--enable-new-dtags");
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Don't pass --build-id by default.

[Rafael Espíndola via cfe-commits]

> This is going to break a lot of my local rpm packaging scripts, and I suspect 
> the same is true for others. This is not a huge deal, but I wonder if we 
> should emulate GCC is this regard and provide some CMake option to keep the 
> current behavior?

Yes, a cmake option is probably best.

What do you think of the attached patch (still building).

Cheers,
Rafael
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f84ae47..fce8229 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -197,6 +197,8 @@ set(GCC_INSTALL_PREFIX "" CACHE PATH "Directory where gcc 
is installed." )
 set(DEFAULT_SYSROOT "" CACHE PATH
   "Default  to all compiler invocations for --sysroot=." )
 
+set(ENABLE_LINKER_BUILD_ID OFF CACHE BOOL "pass --build-id to ld")
+
 set(CLANG_DEFAULT_CXX_STDLIB "" CACHE STRING
   "Default C++ stdlib to use (empty for architecture default, \"libstdc++\" or 
\"libc++\"")
 if (NOT(CLANG_DEFAULT_CXX_STDLIB STREQUAL "" OR
diff --git a/include/clang/Config/config.h.cmake 
b/include/clang/Config/config.h.cmake
index 8917065..09f5e4b 100644
--- a/include/clang/Config/config.h.cmake
+++ b/include/clang/Config/config.h.cmake
@@ -38,4 +38,7 @@
 /* Linker version detected at compile time. */
 #cmakedefine HOST_LINK_VERSION "${HOST_LINK_VERSION}"
 
+/* pass --build-id to ld */
+#cmakedefine ENABLE_LINKER_BUILD_ID
+
 #endif
diff --git a/lib/Driver/ToolChains.cpp b/lib/Driver/ToolChains.cpp
index 8242b96..eec4174 100644
--- a/lib/Driver/ToolChains.cpp
+++ b/lib/Driver/ToolChains.cpp
@@ -3978,10 +3978,9 @@ Linux::Linux(const Driver &D, const llvm::Triple 
&Triple, const ArgList &Args)
   if (IsRedhat(Distro) && Distro != RHEL5 && Distro != RHEL6)
 ExtraOpts.push_back("--no-add-needed");
 
-  if ((IsDebian(Distro) && Distro >= DebianSqueeze) || IsOpenSUSE(Distro) ||
-  (IsRedhat(Distro) && Distro != RHEL5) ||
-  (IsUbuntu(Distro) && Distro >= UbuntuKarmic))
-ExtraOpts.push_back("--build-id");
+#ifdef ENABLE_LINKER_BUILD_ID
+  ExtraOpts.push_back("--build-id");
+#endif
 
   if (IsOpenSUSE(Distro))
 ExtraOpts.push_back("--enable-new-dtags");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Don't pass --build-id by default.

[Rafael Espíndola via cfe-commits]

On 2 June 2016 at 17:06, Rafael Espíndola  wrote:
>> This is going to break a lot of my local rpm packaging scripts, and I 
>> suspect the same is true for others. This is not a huge deal, but I wonder 
>> if we should emulate GCC is this regard and provide some CMake option to 
>> keep the current behavior?
>
> Yes, a cmake option is probably best.
>
> What do you think of the attached patch (still building).

It works :-)

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

Re: Don't pass --build-id by default.

[Rafael Espíndola via cfe-commits]

r271692, thanks.

Cheers,
Rafael


On 3 June 2016 at 10:19, Ed Maste  wrote:
> On 2 June 2016 at 21:19, Hal Finkel via cfe-commits
>  wrote:
>> - Original Message -
>>> From: "Rafael Espíndola" 
>>> To: "Hal Finkel" 
>>> Cc: "cfe-commits cfe" 
>>> Sent: Thursday, June 2, 2016 7:06:26 PM
>>> Subject: Re: Don't pass --build-id by default.
>>>
>>> > This is going to break a lot of my local rpm packaging scripts, and
>>> > I suspect the same is true for others. This is not a huge deal,
>>> > but I wonder if we should emulate GCC is this regard and provide
>>> > some CMake option to keep the current behavior?
>>>
>>> Yes, a cmake option is probably best.
>>>
>>> What do you think of the attached patch (still building).
>>
>> Seems reasonable to me.
>
> This sounds like the right approach to me too.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r271692 - Don't pass --build-id to ld by default.

[Rafael Espíndola via cfe-commits]

Patch attached. What do you think?

Cheers,
Rafael


On 3 June 2016 at 16:11, Ed Maste  wrote:
> On 3 June 2016 at 15:53, Nico Weber via cfe-commits
>  wrote:
>> Can you add this to the release notes? It'll for example break chromium's
>> crash server (we can fix this on our end by explicitly passing
>> -Wl,--build-id for release builds, but we only saw this commit fly by by
>> chance.)
>
> Good point. The Debian, SUSE, Redhat and Ubuntu package maintainers
> will also have to update their package build recipes and we want to
> make sure they don't miss the change.
From e803bb8f8f9bf5d4cea513e489fabce5e96a5658 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rafael=20=C3=81vila=20de=20Esp=C3=ADndola?=
 
Date: Sun, 5 Jun 2016 15:30:13 -0400
Subject: [PATCH] Add a release not about --build-id.

---
 docs/ReleaseNotes.rst | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/docs/ReleaseNotes.rst b/docs/ReleaseNotes.rst
index bcf67ec..376b4c7 100644
--- a/docs/ReleaseNotes.rst
+++ b/docs/ReleaseNotes.rst
@@ -47,7 +47,10 @@ sections with improvements to Clang's support for those languages.
 Major New Features
 --
 
-- Feature1...
+- Clang will no longer passes --build-id by default to the linker. In modern
+  linkers that is a relatively expensive option. It can be passed explicitly
+  with -Wl,--build-id. To have clang always pass it, build it with
+  -DENABLE_LINKER_BUILD_ID.
 
 Improvements to Clang's diagnostics
 ^^^
-- 
2.5.5

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

Re: [PATCH] D21006: [Driver] Make -flto -S emit assembly

[Rafael Espíndola via cfe-commits]

Can you check what GCC does?
On Jun 5, 2016 6:40 PM, "Mehdi AMINI"  wrote:

> mehdi_amini added a comment.
>
> Duncan CC for opinion.
>
>
> http://reviews.llvm.org/D21006
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D21006: [Driver] Make -flto -S emit assembly

[Rafael Espíndola via cfe-commits]

OK, it prints assembly with ir in it. That doesn't apply to us since .BC is
not elf.

I guess we could just produce assembly. A .ll  cannot be used for lto.

So I guess this is OK, but please wait to see what others think.

Cheers,
Rafael
On Jun 5, 2016 7:45 PM, "Davide Italiano"  wrote:

> davide added a comment.
>
> In http://reviews.llvm.org/D21006#449380, @rafael wrote:
>
> > Can you check what GCC does?
>
>
> Sure.
>
>   $ gcc flto.c -o flto.o -flto -S && cat flto.o |head -n 15
> .file   "flto.c"
> .section.gnu.lto_.inline.513e7babbe55b1f8,"e",@progbits
> .string "x\234ca\200"
> .string "\021\006\004`d``af``b\371\240\307\300\302\300\004\026\003"
> .ascii  "\020b\001K"
> .text
> .section.gnu.lto_foo.513e7babbe55b1f8,"e",@progbits
> .string
> "x\234eP\275J\003A\020\236o\346\210Q8\365\001R\244\t!\026>C\360\021|\005A\033\341\032\373\254\\\"QA,\242\210X\004LH\341O\022[\213\004\004\021\301\"\202\235EPQ\320&\207\212\225\2363I#8\260;3\314\3673\273\036\215b\016D\276\346\2245\036\201I\017Do\201\216\bT`A\001\237\374\315\350\025[\007\362\301%!x\332F7\373\217\223\326\002im_j[{\3105\234F\277^Inl\243$L1\023\216\221\302\021\314\002'\310)\264z\365v\351\313\004H\353\316m\271\346e\353Fs\347y7\256$\234B\376\362L\007Md\r\376\320\376\331\361\023EC\247M\\5[H\350\252\320a\377\375\372\"\2319t\256\354\334W\267\n\267\236\377\277\203B\333\3104\347\273.\216C\347\356\322\360"
> .ascii
> "\223\347\241\021\rL\224\"\326$\317\bw\327\356\305,B\341P\314"
> .ascii
> "\244\321\253lN\331\263\03138\033JF\254?&OX\235&\247\325\253~"
> .ascii
> "\341\210aJ\003\326\355\264\032[\\^\tf\027H\226\202\340\027\253"
> .ascii  "\277d'"
> .text
> .section
> .gnu.lto_.symbol_nodes.513e7babbe55b1f8,"e",@progbits
> .string "x\234ca``\020\006b\006&\206z\006\206\t\347\030@
> \324\252FE\240\b"
>
>
> http://reviews.llvm.org/D21006
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D21006: [Driver] Make -flto -S emit assembly

[Rafael Espíndola via cfe-commits]

Fair enough, let's keep it as is and try to update the build.

Cheers,
Rafael
On Jun 5, 2016 9:28 PM, "Mehdi AMINI"  wrote:

> mehdi_amini added a comment.
>
> What makes me not comfortable with this change is that after that  `-c`
> would not involves codegen but `-S` would.
> Indeed I am using sometimes `-flto -S` and I expect IR, that's what is the
> most logical to me considering what -c does.
>
>
> http://reviews.llvm.org/D21006
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r260707 - [CMake] Pass stage1 tools through to stage2 when building with LTO

[Rafael Espíndola via cfe-commits]

Any reason it is lto specific? For example, it is nice to test llvm-ar
in stage2 even if not doing LTO, no?

Cheers,
Rafael


On 12 February 2016 at 14:06, Chris Bieneman via cfe-commits
 wrote:
> Author: cbieneman
> Date: Fri Feb 12 13:06:12 2016
> New Revision: 260707
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260707&view=rev
> Log:
> [CMake] Pass stage1 tools through to stage2 when building with LTO
>
> This was originally a hacky if(APPLE) block. Now that we have an option for 
> enabling LTO, it is better to properly gate this.
>
> Modified:
> cfe/trunk/CMakeLists.txt
>
> Modified: cfe/trunk/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=260707&r1=260706&r2=260707&view=diff
> ==
> --- cfe/trunk/CMakeLists.txt (original)
> +++ cfe/trunk/CMakeLists.txt Fri Feb 12 13:06:12 2016
> @@ -677,11 +677,15 @@ if (CLANG_ENABLE_BOOTSTRAP)
>
># If on Darwin we need to make bootstrap depend on LTO and pass
># DARWIN_LTO_LIBRARY so that -flto will work using the just-built compiler
> -  if(APPLE)
> +  if(BOOTSTRAP_LLVM_ENABLE_LTO OR LLVM_ENABLE_LTO)
>  set(LTO_DEP LTO llvm-ar llvm-ranlib)
> -set(LTO_LIBRARY 
> -DDARWIN_LTO_LIBRARY=${LLVM_SHLIB_OUTPUT_INTDIR}/libLTO.dylib)
>  set(LTO_AR -DCMAKE_AR=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-ar)
>  set(LTO_RANLIB -DCMAKE_RANLIB=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-ranlib)
> +if(APPLE)
> +  set(LTO_LIBRARY 
> -DDARWIN_LTO_LIBRARY=${LLVM_SHLIB_OUTPUT_INTDIR}/libLTO.dylib)
> +elseif(NOT WIN32)
> +  list(APPEND LTO_DEP LLVMgold)
> +endif()
>endif()
>
>add_custom_target(${NEXT_CLANG_STAGE}-clear
>
>
> ___
> 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: r261461 - Lex: Never overflow the file in HeaderMap::lookupFilename()

[Rafael Espíndola via cfe-commits]

On 20 February 2016 at 19:14, Duncan P. N. Exon Smith via cfe-commits
 wrote:
> Author: dexonsmith
> Date: Sat Feb 20 18:14:36 2016
> New Revision: 261461
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261461&view=rev
> Log:
> Lex: Never overflow the file in HeaderMap::lookupFilename()
>
> If a header map file is corrupt, the strings in the string table may not
> be null-terminated.  The logic here previously relied on `MemoryBuffer`
> always being null-terminated, but this isn't actually guaranteed by the
> class AFAICT.

Depends on the constructor used. Note the RequiresNullTerminator
parameter. It exists because it apparently makes clang parsing faster
by allowing it to not check for the size all the time.

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

Re: r258504 - Change of UserLabelPrefix default value from "_" to ""

[Rafael Espíndola via cfe-commits]

As a first patch I think you can just leave every

 UserLabelPrefix = ""

in place.

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

Re: r257175 - Driver: Use the new ELF lld linker for AMDGPU

[Rafael Espíndola via cfe-commits]

awesome!

On 8 January 2016 at 10:14, Tom Stellard via cfe-commits
 wrote:
> Author: tstellar
> Date: Fri Jan  8 09:14:31 2016
> New Revision: 257175
>
> URL: http://llvm.org/viewvc/llvm-project?rev=257175&view=rev
> Log:
> Driver: Use the new ELF lld linker for AMDGPU
>
> Summary: 'gnu-old' has been deprecated in favor or 'gnu'.
>
> Reviewers: arsenm, ruiu, rafael
>
> Subscribers: cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D15953
>
> Modified:
> cfe/trunk/lib/Driver/Tools.cpp
> cfe/trunk/lib/Driver/Tools.h
> cfe/trunk/test/Driver/amdgpu-toolchain.c
>
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=257175&r1=257174&r2=257175&view=diff
> ==
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Fri Jan  8 09:14:31 2016
> @@ -6520,10 +6520,6 @@ void amdgpu::Linker::ConstructJob(Compil
>
>std::string Linker = getToolChain().GetProgramPath(getShortName());
>ArgStringList CmdArgs;
> -  CmdArgs.push_back("-flavor");
> -  CmdArgs.push_back("old-gnu");
> -  CmdArgs.push_back("-target");
> -  CmdArgs.push_back(Args.MakeArgString(getToolChain().getTripleString()));
>AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs);
>CmdArgs.push_back("-o");
>CmdArgs.push_back(Output.getFilename());
>
> Modified: cfe/trunk/lib/Driver/Tools.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.h?rev=257175&r1=257174&r2=257175&view=diff
> ==
> --- cfe/trunk/lib/Driver/Tools.h (original)
> +++ cfe/trunk/lib/Driver/Tools.h Fri Jan  8 09:14:31 2016
> @@ -240,7 +240,7 @@ namespace amdgpu {
>
>  class LLVM_LIBRARY_VISIBILITY Linker : public GnuTool {
>  public:
> -  Linker(const ToolChain &TC) : GnuTool("amdgpu::Linker", "lld", TC) {}
> +  Linker(const ToolChain &TC) : GnuTool("amdgpu::Linker", "ld.lld", TC) {}
>bool isLinkJob() const override { return true; }
>bool hasIntegratedCPP() const override { return false; }
>void ConstructJob(Compilation &C, const JobAction &JA,
>
> Modified: cfe/trunk/test/Driver/amdgpu-toolchain.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/amdgpu-toolchain.c?rev=257175&r1=257174&r2=257175&view=diff
> ==
> --- cfe/trunk/test/Driver/amdgpu-toolchain.c (original)
> +++ cfe/trunk/test/Driver/amdgpu-toolchain.c Fri Jan  8 09:14:31 2016
> @@ -1,3 +1,3 @@
>  // RUN: %clang -### -target amdgcn--amdhsa -x assembler -mcpu=kaveri %s 2>&1 
> | FileCheck -check-prefix=AS_LINK %s
>  // AS_LINK: clang{{.*}} "-cc1as"
> -// AS_LINK: lld{{.*}} "-flavor" "old-gnu" "-target" "amdgcn--amdhsa"
> +// AS_LINK: ld.lld{{.*}}
>
>
> ___
> 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: [libcxx] r196411 - Give all members of exception types default visibility. Lack of this is causing some illegal code relocations rare and hard to reproduce cases.

[Rafael Espíndola via cfe-commits]

On 8 January 2016 at 19:50, Duncan P. N. Exon Smith via cfe-commits
 wrote:
> [re-send to lists.llvm.org]
> [necromancy]
>
> This is causing some strangeness for users of libc++ headers that
> ship dylibs and build with -fno-rtti and -fvisibility=hidden.
>
> Strangely, -fno-rtti does *not* imply -fno-exceptions; the type info
> needed for exceptions is generated on-the-fly.  This means that each
> translation unit generates a linkonce_odr copy of the std::exception
> type info -- weird, but kind of reasonable?

Will gcc produce a copy too? It seems really strange to produce
different linkages for -frtti and -fno-rtti -fexcptions.

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

Re: [libcxx] r196411 - Give all members of exception types default visibility. Lack of this is causing some illegal code relocations rare and hard to reproduce cases.

[Rafael Espíndola via cfe-commits]

> I'm not sure about GCC.  Note that there is no linkage for -frtti,
> since the type info is deferred to the TU with the vtable.

Yes, that is what I mean. It is odd that -frtti changes us from "this
is not available anywhere, use linkonce_odr" to "it is available
elsewhere, use an external declaration".

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

Re: [PATCH] D16056: [Gold] Pass -mllvm options to the gold plugin

[Rafael Espíndola via cfe-commits]

Maybe. I would like a second opinion on this one. The potential issue
I see is that we are using compiler options during linking. Normally
they are just ignored. Is it surprising if LTO starts using them?

Cheers,
Rafael


On 11 January 2016 at 06:47, James Molloy  wrote:
> jmolloy created this revision.
> jmolloy added a reviewer: rafael.
> jmolloy added a subscriber: cfe-commits.
> jmolloy set the repository for this revision to rL LLVM.
> Herald added a subscriber: joker.eph.
>
> The gold plugin can take LLVM options, but the syntax is confusing: 
> -Wl,-plugin-opt= or -Xlinker -plugin-opt=.
>
> Instead, pass -mllvm options through to Gold so the obvious syntax works.
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D16056
>
> Files:
>   lib/Driver/Tools.cpp
>   test/Driver/gold-lto.c
>
> Index: test/Driver/gold-lto.c
> ===
> --- test/Driver/gold-lto.c
> +++ test/Driver/gold-lto.c
> @@ -16,11 +16,14 @@
>  // CHECK-X86-64-COREI7: "-plugin-opt=foo"
>  //
>  // RUN: %clang -target arm-unknown-linux -### %t.o -flto 2>&1 \
> -// RUN: -march=armv7a -Wl,-plugin-opt=foo -O0 \
> +// RUN: -march=armv7a -Wl,-plugin-opt=foo -O0 -mllvm -bar=baz \
> +// RUN: -mllvm -test-option \
>  // RUN: | FileCheck %s --check-prefix=CHECK-ARM-V7A
>  // CHECK-ARM-V7A: "-plugin" "{{.*}}/LLVMgold.so"
>  // CHECK-ARM-V7A: "-plugin-opt=mcpu=cortex-a8"
>  // CHECK-ARM-V7A: "-plugin-opt=O0"
> +// CHECK-ARM-V7A: "-plugin-opt=-bar=baz"
> +// CHECK-ARM-V7A: "-plugin-opt=-test-option"
>  // CHECK-ARM-V7A: "-plugin-opt=foo"
>  //
>  // RUN: %clang -target i686-linux-android -### %t.o -flto 2>&1 \
> Index: lib/Driver/Tools.cpp
> ===
> --- lib/Driver/Tools.cpp
> +++ lib/Driver/Tools.cpp
> @@ -1817,6 +1817,12 @@
>
>if (IsThinLTO)
>  CmdArgs.push_back("-plugin-opt=thinlto");
> +
> +  // Claim and pass through -mllvm options to the Gold plugin.
> +  for (const Arg *A : Args.filtered(options::OPT_mllvm)) {
> +A->claim();
> +CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=") + 
> A->getValue(0)));
> +  }
>  }
>
>  /// This is a helper function for validating the optional refinement step
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16295: Change of UserLabelPrefix default value from "_" to ""

[Rafael Espíndola via cfe-commits]

I am pretty sure the cases in init.c are wrong as the assembly itself
doesn't use a '_'.

Having said that, it is probably a good thing to do this in two steps.
So this patch LGTM on the condition that you also open a bug to audit
the cases where we define __USER_LABEL_PREFIX__ to _ in init.c and CC
whoever added those.

Thanks,
Rafael


On 19 January 2016 at 05:58, Andrey Bokhanko  wrote:
> andreybokhanko added a comment.
>
> @rafael, all these changes are driven by tests.
>
> It seems you mean OS targeting, which is handled in other TargetInfo classes 
> (LinuxTargetInfo in Linux case).
>
>
> 
> Comment at: lib/Basic/Targets.cpp:801
> @@ -818,2 +800,3 @@
>  LongDoubleFormat = &llvm::APFloat::PPCDoubleDouble;
> +UserLabelPrefix = "_";
>}
> 
> rafael wrote:
>> This looks wrong, we produce a "f:" not an "_f:" when targeting 
>> powerpc-linux-gnu.
>>
> Is this commented out, tools/clang/test/Preprocessor/init.c:5216 fails. As 
> can be seen in the test, PPC603E target expects UserLabelPrefix to be equal 
> to "_" in freestanding mode.
>
> As for powerpc-linux-gnu target, UserLabelPrefix is set to "" at 
> lib/Basic/Target.cpp:416 (LinuxTargetInfo constructor).
>
> 
> Comment at: lib/Basic/Targets.cpp:1617
> @@ -1633,2 +1616,3 @@
>  GPU = GK_SM20;
> +UserLabelPrefix = "_";
>}
> 
> rafael wrote:
>> This also looks wrong.
> Same as above -- NVPTX target expects UserLabelPrefix to be "_" in 
> freestanding mode (tools/clang/test/Preprocessor/init.c:4853). Linux target 
> is covered in LinuxTargetInfo constructor.
>
>
> http://reviews.llvm.org/D16295
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15705: Adding a scripted test for PR25717

[Rafael Espíndola via cfe-commits]

On 25 January 2016 at 11:03, Yunzhong Gao
 wrote:
> ygao added a comment.
>
> Thanks, Rafael!
> I did verify that the test would fail without my fix. But what do I need to 
> do to make buildbots turn on the new lit parameter?

That I do not know. Mike?

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

Re: [libcxx] r196411 - Give all members of exception types default visibility. Lack of this is causing some illegal code relocations rare and hard to reproduce cases.

[Rafael Espíndola via cfe-commits]

>> Yes, that is what I mean. It is odd that -frtti changes us from "this
>> is not available anywhere, use linkonce_odr" to "it is available
>> elsewhere, use an external declaration".
>
> Yes, I agree, it's weird (although the transition is in the other
> direction, really, since there's no such flag as -frtti, just -fno-rtti).
> -fexceptions -fno-rtti is a weird combination to begin with though.

I got curious and decided to reduce it. What I got was:

class foo {
  virtual void bar();
};
struct zed : public foo {};
int f() { throw zed(); }

Without -fno-rtti _ZTI3foo is external. With -fno-rtti it is
linkonce_odr. It looks like -fno-rtti disables some key function logic
in both gcc and clang.

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

Re: r259507 - Make the remaining headers self-contained.

[Rafael Espíndola via cfe-commits]

Out of curiosity, what technique were you using to find out if the
headers were self-contained? Just "clang -c foo.h"?

Cheers,
Rafael


On 2 February 2016 at 09:24, Benjamin Kramer via cfe-commits
 wrote:
> Author: d0k
> Date: Tue Feb  2 08:24:21 2016
> New Revision: 259507
>
> URL: http://llvm.org/viewvc/llvm-project?rev=259507&view=rev
> Log:
> Make the remaining headers self-contained.
>
> Modified:
> cfe/trunk/include/clang/AST/BaseSubobject.h
> cfe/trunk/include/clang/AST/DeclOpenMP.h
> cfe/trunk/include/clang/AST/Mangle.h
> cfe/trunk/include/clang/AST/TemplateName.h
> cfe/trunk/include/clang/Sema/CodeCompleteConsumer.h
> cfe/trunk/include/clang/Sema/ObjCMethodList.h
> cfe/trunk/include/clang/Sema/Ownership.h
> cfe/trunk/include/clang/Sema/Scope.h
> cfe/trunk/include/clang/Sema/SemaLambda.h
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
> cfe/trunk/lib/CodeGen/CodeGenTBAA.h
>
> Modified: cfe/trunk/include/clang/AST/BaseSubobject.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/BaseSubobject.h?rev=259507&r1=259506&r2=259507&view=diff
> ==
> --- cfe/trunk/include/clang/AST/BaseSubobject.h (original)
> +++ cfe/trunk/include/clang/AST/BaseSubobject.h Tue Feb  2 08:24:21 2016
> @@ -15,13 +15,12 @@
>  #define LLVM_CLANG_AST_BASESUBOBJECT_H
>
>  #include "clang/AST/CharUnits.h"
> +#include "clang/AST/DeclCXX.h"
>  #include "llvm/ADT/DenseMap.h"
>  #include "llvm/Support/DataTypes.h"
>  #include "llvm/Support/type_traits.h"
>
>  namespace clang {
> -  class CXXRecordDecl;
> -
>  // BaseSubobject - Uniquely identifies a direct or indirect base class.
>  // Stores both the base class decl and the offset from the most derived 
> class to
>  // the base class. Used for vtable and VTT generation.
>
> Modified: cfe/trunk/include/clang/AST/DeclOpenMP.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclOpenMP.h?rev=259507&r1=259506&r2=259507&view=diff
> ==
> --- cfe/trunk/include/clang/AST/DeclOpenMP.h (original)
> +++ cfe/trunk/include/clang/AST/DeclOpenMP.h Tue Feb  2 08:24:21 2016
> @@ -17,6 +17,7 @@
>
>  #include "clang/AST/DeclBase.h"
>  #include "llvm/ADT/ArrayRef.h"
> +#include "llvm/Support/TrailingObjects.h"
>
>  namespace clang {
>  class Expr;
>
> Modified: cfe/trunk/include/clang/AST/Mangle.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Mangle.h?rev=259507&r1=259506&r2=259507&view=diff
> ==
> --- cfe/trunk/include/clang/AST/Mangle.h (original)
> +++ cfe/trunk/include/clang/AST/Mangle.h Tue Feb  2 08:24:21 2016
> @@ -14,6 +14,7 @@
>  #ifndef LLVM_CLANG_AST_MANGLE_H
>  #define LLVM_CLANG_AST_MANGLE_H
>
> +#include "clang/AST/Decl.h"
>  #include "clang/AST/Type.h"
>  #include "clang/Basic/ABI.h"
>  #include "llvm/ADT/DenseMap.h"
>
> Modified: cfe/trunk/include/clang/AST/TemplateName.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/TemplateName.h?rev=259507&r1=259506&r2=259507&view=diff
> ==
> --- cfe/trunk/include/clang/AST/TemplateName.h (original)
> +++ cfe/trunk/include/clang/AST/TemplateName.h Tue Feb  2 08:24:21 2016
> @@ -14,6 +14,7 @@
>  #ifndef LLVM_CLANG_AST_TEMPLATENAME_H
>  #define LLVM_CLANG_AST_TEMPLATENAME_H
>
> +#include "clang/AST/NestedNameSpecifier.h"
>  #include "clang/Basic/LLVM.h"
>  #include "llvm/ADT/FoldingSet.h"
>  #include "llvm/ADT/PointerUnion.h"
>
> Modified: cfe/trunk/include/clang/Sema/CodeCompleteConsumer.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/CodeCompleteConsumer.h?rev=259507&r1=259506&r2=259507&view=diff
> ==
> --- cfe/trunk/include/clang/Sema/CodeCompleteConsumer.h (original)
> +++ cfe/trunk/include/clang/Sema/CodeCompleteConsumer.h Tue Feb  2 08:24:21 
> 2016
> @@ -15,6 +15,7 @@
>
>  #include "clang-c/Index.h"
>  #include "clang/AST/CanonicalType.h"
> +#include "clang/AST/DeclBase.h"
>  #include "clang/AST/Type.h"
>  #include "clang/Sema/CodeCompleteOptions.h"
>  #include "llvm/ADT/DenseMap.h"
>
> Modified: cfe/trunk/include/clang/Sema/ObjCMethodList.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/ObjCMethodList.h?rev=259507&r1=259506&r2=259507&view=diff
> ==
> --- cfe/trunk/include/clang/Sema/ObjCMethodList.h (original)
> +++ cfe/trunk/include/clang/Sema/ObjCMethodList.h Tue Feb  2 08:24:21 2016
> @@ -14,6 +14,7 @@
>  #ifndef LLVM_CLANG_SEMA_OBJCMETHODLIST_H
>  #define LLVM_CLANG_SEMA_OBJCMETHODLIST_H
>
> +#include "clang/AST/DeclObjC.h"
>  #include "llvm/ADT/PointerIntPair.h"
>
>  namespace clang {
>
> Modifie

Re: [PATCH] Proper detection and handling of RHEL and variants

[Rafael Espíndola via cfe-commits]

-  if (IsRedhat(Distro))
+  if (Distro == Fedora || Distro == RHEL7)

RHEL8 will probably use --no-add-needed.

Can you change this to "if (IsRedhat(Distro) && !old_rhel_distro) "?

Cheers,
Rafael


On 22 March 2016 at 22:07, Michael Lampe via cfe-commits
 wrote:
> - Don't consider "/etc/lsb-release" to be Ubuntu only.
> - Detect SL, too.
> - Only add "--no-add-needed" for RHEL7 (or Fedora), not for RHEL6 (that's
> what the compilers shipped with RHEL do).
>
>
> ___
> 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] RHEL: Look in more places to find g++ headers and runtime

[Rafael Espíndola via cfe-commits]

LGTM with a comment saying why it is needed.

Cheers,
Rafael


On 22 March 2016 at 23:02, Michael Lampe via cfe-commits
 wrote:
> Some distros with ten years of support ship an old gcc but later offer more
> recent versions for installation in parallel. These versions are typically
> not only needed for the compilation of llvm/clang, but also to properly use
> the clang binary that comes out.
>
> Clang already searches /usr at runtime for the most recent installation of
> gcc. This patch appends paths for add-on installations of gcc in RHEL.
>
>
> ___
> 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: r266276 - Do not use llvm:getGlobalContext() in unittests

[Rafael Espíndola via cfe-commits]

On 14 April 2016 at 01:34, Mehdi Amini via cfe-commits
 wrote:
> Author: mehdi_amini
> Date: Thu Apr 14 00:34:32 2016
> New Revision: 266276
>
> URL: http://llvm.org/viewvc/llvm-project?rev=266276&view=rev
> Log:
> Do not use llvm:getGlobalContext() in unittests
>
> Currently trying to nuke this API from LLVM.

Thanks!

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

Re: r267756 - [CMake] On Darwin bootstrap LTO builds set DYLD_LIBRARY_PATH instead of using llvm-ar

[Rafael Espíndola via cfe-commits]

BTW, do you know what is missing in llvm-ar? I know of fat archive
support, but if there is something else could you open a bug report?

Cheers,
Rafael


On 27 April 2016 at 14:52, Chris Bieneman via cfe-commits
 wrote:
> Author: cbieneman
> Date: Wed Apr 27 13:52:48 2016
> New Revision: 267756
>
> URL: http://llvm.org/viewvc/llvm-project?rev=267756&view=rev
> Log:
> [CMake] On Darwin bootstrap LTO builds set DYLD_LIBRARY_PATH instead of using 
> llvm-ar
>
> llvm-ar isn't really supported for Darwin, instead the host tools will load 
> libLTO, so we can use the just-built libLTO.
>
> This actually makes Darwin bootstrap builds a little faster because you don't 
> need to build llvm-ar before starting the next stage.
>
> Modified:
> cfe/trunk/CMakeLists.txt
>
> Modified: cfe/trunk/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=267756&r1=267755&r2=267756&view=diff
> ==
> --- cfe/trunk/CMakeLists.txt (original)
> +++ cfe/trunk/CMakeLists.txt Wed Apr 27 13:52:48 2016
> @@ -685,17 +685,21 @@ if (CLANG_ENABLE_BOOTSTRAP)
>
>set(STAMP_DIR ${CMAKE_CURRENT_BINARY_DIR}/${NEXT_CLANG_STAGE}-stamps/)
>set(BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/${NEXT_CLANG_STAGE}-bins/)
> +  set(cmake_command ${CMAKE_COMMAND})
>
> -  # If on Darwin we need to make bootstrap depend on LTO and pass
> -  # DARWIN_LTO_LIBRARY so that -flto will work using the just-built compiler
> +  # If the next stage is LTO we need to depend on LTO and possibly LLVMgold
>if(BOOTSTRAP_LLVM_ENABLE_LTO OR LLVM_ENABLE_LTO)
> -set(LTO_DEP LTO llvm-ar llvm-ranlib)
> -set(LTO_AR -DCMAKE_AR=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-ar)
> -set(LTO_RANLIB -DCMAKE_RANLIB=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-ranlib)
> +set(LTO_DEP LTO)
>  if(APPLE)
> +  # on Darwin we need to set DARWIN_LTO_LIBRARY so that -flto will work
> +  # using the just-built compiler, and we need to override 
> DYLD_LIBRARY_PATH
> +  # so that the host object file tools will use the just-built libLTO.
>set(LTO_LIBRARY 
> -DDARWIN_LTO_LIBRARY=${LLVM_SHLIB_OUTPUT_INTDIR}/libLTO.dylib)
> +  set(cmake_command ${CMAKE_COMMAND} -E env 
> DYLD_LIBRARY_PATH=${LLVM_LIBRARY_OUTPUT_INTDIR} ${CMAKE_COMMAND})
>  elseif(NOT WIN32)
> -  list(APPEND LTO_DEP LLVMgold)
> +  list(APPEND LTO_DEP LLVMgold llvm-ar llvm-ranlib)
> +  set(LTO_AR -DCMAKE_AR=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-ar)
> +  set(LTO_RANLIB 
> -DCMAKE_RANLIB=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-ranlib)
>  endif()
>endif()
>
> @@ -791,6 +795,7 @@ if (CLANG_ENABLE_BOOTSTRAP)
>   -DCLANG_STAGE=${NEXT_CLANG_STAGE}
>  ${COMPILER_OPTIONS}
>  ${LTO_LIBRARY} ${LTO_AR} ${LTO_RANLIB} ${verbose} ${PGO_OPT}
> +CMAKE_COMMAND ${cmake_command}
>  INSTALL_COMMAND ""
>  STEP_TARGETS configure build
>  ${cmake_3_4_USES_TERMINAL_OPTIONS}
> @@ -799,7 +804,7 @@ if (CLANG_ENABLE_BOOTSTRAP)
># exclude really-install from main target
>set_target_properties(${NEXT_CLANG_STAGE} PROPERTIES 
> _EP_really-install_EXCLUDE_FROM_MAIN On)
>ExternalProject_Add_Step(${NEXT_CLANG_STAGE} really-install
> -COMMAND ${CMAKE_COMMAND} --build  --target install
> +COMMAND ${cmake_command} --build  --target install
>  COMMENT "Performing install step for '${NEXT_CLANG_STAGE}'"
>  DEPENDEES build
>  ${cmake_3_4_USES_TERMINAL}
> @@ -815,7 +820,7 @@ if (CLANG_ENABLE_BOOTSTRAP)
>  set_target_properties(${NEXT_CLANG_STAGE} PROPERTIES 
> _EP_${target}_EXCLUDE_FROM_MAIN On)
>
>  ExternalProject_Add_Step(${NEXT_CLANG_STAGE} ${target}
> -  COMMAND ${CMAKE_COMMAND} --build  --target ${target}
> +  COMMAND ${cmake_command} --build  --target ${target}
>COMMENT "Performing ${target} for '${NEXT_CLANG_STAGE}'"
>DEPENDEES configure
>${cmake_3_4_USES_TERMINAL}
>
>
> ___
> 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: r268055 - Recommitted r264281 "Supporting all entities declared in lexical scope in LLVM debug info."

[Rafael Espíndola via cfe-commits]

Maybe this is the cause of this bootstrap failure:
http://lab.llvm.org:8080/green/job/llvm-stage2-cmake-RgLTO_build/6843
?

Cheers,
Rafael


On 29 April 2016 at 12:08, Amjad Aboud via cfe-commits
 wrote:
> Author: aaboud
> Date: Fri Apr 29 11:08:08 2016
> New Revision: 268055
>
> URL: http://llvm.org/viewvc/llvm-project?rev=268055&view=rev
> Log:
> Recommitted r264281 "Supporting all entities declared in lexical scope in 
> LLVM debug info."
> After fixing PR26942 in r267004.
>
> Added:
> cfe/trunk/test/CodeGenCXX/debug-info-lb.cpp
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/lib/CodeGen/CGDebugInfo.h
> cfe/trunk/lib/CodeGen/CGDecl.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=268055&r1=268054&r2=268055&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Apr 29 11:08:08 2016
> @@ -814,15 +814,18 @@ llvm::DIType *CGDebugInfo::CreateType(co
>
>  llvm::DIType *CGDebugInfo::CreateType(const TypedefType *Ty,
>llvm::DIFile *Unit) {
> +  TypedefNameDecl *TD = Ty->getDecl();
>// We don't set size information, but do specify where the typedef was
>// declared.
> -  SourceLocation Loc = Ty->getDecl()->getLocation();
> +  SourceLocation Loc = TD->getLocation();
> +
> +  llvm::DIScope *TDContext = getDeclarationLexicalScope(*TD, QualType(Ty, 
> 0));
>
>// Typedefs are derived from some other type.
>return DBuilder.createTypedef(
>getOrCreateType(Ty->getDecl()->getUnderlyingType(), Unit),
>Ty->getDecl()->getName(), getOrCreateFile(Loc), getLineNumber(Loc),
> -  getDeclContextDescriptor(Ty->getDecl()));
> +  TDContext);
>  }
>
>  llvm::DIType *CGDebugInfo::CreateType(const FunctionType *Ty,
> @@ -1457,6 +1460,23 @@ llvm::DIType *CGDebugInfo::getOrCreateSt
>return T;
>  }
>
> +void CGDebugInfo::recordDeclarationLexicalScope(const Decl &D) {
> +  assert(LexicalBlockMap.find(&D) == LexicalBlockMap.end() &&
> + "D is already mapped to lexical block scope");
> +  if (!LexicalBlockStack.empty())
> +LexicalBlockMap[&D] = LexicalBlockStack.back();
> +}
> +
> +llvm::DIScope *CGDebugInfo::getDeclarationLexicalScope(const Decl &D,
> +   QualType Ty) {
> +  auto I = LexicalBlockMap.find(&D);
> +  if (I != LexicalBlockMap.end()) {
> +RetainedTypes.push_back(Ty.getAsOpaquePtr());
> +return I->second;
> +  }
> +  return getDeclContextDescriptor(cast(&D));
> +}
> +
>  void CGDebugInfo::completeType(const EnumDecl *ED) {
>if (DebugKind <= codegenoptions::DebugLineTablesOnly)
>  return;
> @@ -2060,7 +2080,7 @@ llvm::DIType *CGDebugInfo::CreateEnumTyp
>  // entered into the ReplaceMap: finalize() will replace the first
>  // FwdDecl with the second and then replace the second with
>  // complete type.
> -llvm::DIScope *EDContext = getDeclContextDescriptor(ED);
> +llvm::DIScope *EDContext = getDeclarationLexicalScope(*ED, QualType(Ty, 
> 0));
>  llvm::DIFile *DefUnit = getOrCreateFile(ED->getLocation());
>  llvm::TempDIScope TmpContext(DBuilder.createReplaceableCompositeType(
>  llvm::dwarf::DW_TAG_enumeration_type, "", TheCU, DefUnit, 0));
> @@ -2104,7 +2124,7 @@ llvm::DIType *CGDebugInfo::CreateTypeDef
>
>llvm::DIFile *DefUnit = getOrCreateFile(ED->getLocation());
>unsigned Line = getLineNumber(ED->getLocation());
> -  llvm::DIScope *EnumContext = getDeclContextDescriptor(ED);
> +  llvm::DIScope *EnumContext = getDeclarationLexicalScope(*ED, QualType(Ty, 
> 0));
>llvm::DIType *ClassTy =
>ED->isFixed() ? getOrCreateType(ED->getIntegerType(), DefUnit) : 
> nullptr;
>return DBuilder.createEnumerationType(EnumContext, ED->getName(), DefUnit,
> @@ -2365,7 +2385,7 @@ llvm::DICompositeType *CGDebugInfo::Crea
>unsigned Line = getLineNumber(RD->getLocation());
>StringRef RDName = getClassName(RD);
>
> -  llvm::DIScope *RDContext = getDeclContextDescriptor(RD);
> +  llvm::DIScope *RDContext = getDeclarationLexicalScope(*RD, QualType(Ty, 
> 0));
>
>// If we ended up creating the type during the context chain construction,
>// just return that.
> @@ -2536,8 +2556,15 @@ void CGDebugInfo::collectVarDeclProps(co
>if (DC->isRecord())
>  DC = CGM.getContext().getTranslationUnitDecl();
>
> - llvm::DIScope *Mod = getParentModuleOrNull(VD);
> - VDContext = getContextDescriptor(cast(DC), Mod ? Mod : TheCU);
> +  if (VD->isStaticLocal()) {
> +// Get context for static locals (that are technically globals) the same 
> way
> +// we do for "local" locals -- by using current lexical block.
> +assert(!LexicalBlockStack.empty() && "Region stack mismatch, stack 
> empty!");
> +  

Re: r268055 - Recommitted r264281 "Supporting all entities declared in lexical scope in LLVM debug info."

[Rafael Espíndola via cfe-commits]

The same error message shows up in https://llvm.org/bugs/show_bug.cgi?id=27579.

On 29 April 2016 at 16:47, Aboud, Amjad  wrote:
> I could not reproduce the issue.
> This error appeared before and it always meant that LLVM and Clang were not 
> aligned.
> You need both revisions to work correctly: (LLVM) 268054, (Clang) 268055
>
> Please, let me know if you can reproduce the issue locally using these 
> versions.
>
> Regards,
> Amjad
>
>> -Original Message-
>> From: Rafael Espíndola [mailto:rafael.espind...@gmail.com]
>> Sent: Friday, April 29, 2016 22:42
>> To: Aboud, Amjad 
>> Cc: cfe-commits cfe 
>> Subject: Re: r268055 - Recommitted r264281 "Supporting all entities declared 
>> in
>> lexical scope in LLVM debug info."
>>
>> Maybe this is the cause of this bootstrap failure:
>> http://lab.llvm.org:8080/green/job/llvm-stage2-cmake-RgLTO_build/6843
>> ?
>>
>> Cheers,
>> Rafael
>>
>>
>> On 29 April 2016 at 12:08, Amjad Aboud via cfe-commits > comm...@lists.llvm.org> wrote:
>> > Author: aaboud
>> > Date: Fri Apr 29 11:08:08 2016
>> > New Revision: 268055
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=268055&view=rev
>> > Log:
>> > Recommitted r264281 "Supporting all entities declared in lexical scope in 
>> > LLVM
>> debug info."
>> > After fixing PR26942 in r267004.
>> >
>> > Added:
>> > cfe/trunk/test/CodeGenCXX/debug-info-lb.cpp
>> > Modified:
>> > cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> > cfe/trunk/lib/CodeGen/CGDebugInfo.h
>> > cfe/trunk/lib/CodeGen/CGDecl.cpp
>> > cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp
>> >
>> > Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> > URL:
>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.
>> > cpp?rev=268055&r1=268054&r2=268055&view=diff
>> >
>> =
>> =
>> > 
>> > --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
>> > +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Apr 29 11:08:08 2016
>> > @@ -814,15 +814,18 @@ llvm::DIType *CGDebugInfo::CreateType(co
>> >
>> >  llvm::DIType *CGDebugInfo::CreateType(const TypedefType *Ty,
>> >llvm::DIFile *Unit) {
>> > +  TypedefNameDecl *TD = Ty->getDecl();
>> >// We don't set size information, but do specify where the typedef was
>> >// declared.
>> > -  SourceLocation Loc = Ty->getDecl()->getLocation();
>> > +  SourceLocation Loc = TD->getLocation();
>> > +
>> > +  llvm::DIScope *TDContext = getDeclarationLexicalScope(*TD,
>> > + QualType(Ty, 0));
>> >
>> >// Typedefs are derived from some other type.
>> >return DBuilder.createTypedef(
>> >getOrCreateType(Ty->getDecl()->getUnderlyingType(), Unit),
>> >Ty->getDecl()->getName(), getOrCreateFile(Loc), getLineNumber(Loc),
>> > -  getDeclContextDescriptor(Ty->getDecl()));
>> > +  TDContext);
>> >  }
>> >
>> >  llvm::DIType *CGDebugInfo::CreateType(const FunctionType *Ty, @@
>> > -1457,6 +1460,23 @@ llvm::DIType *CGDebugInfo::getOrCreateSt
>> >return T;
>> >  }
>> >
>> > +void CGDebugInfo::recordDeclarationLexicalScope(const Decl &D) {
>> > +  assert(LexicalBlockMap.find(&D) == LexicalBlockMap.end() &&
>> > + "D is already mapped to lexical block scope");
>> > +  if (!LexicalBlockStack.empty())
>> > +LexicalBlockMap[&D] = LexicalBlockStack.back(); }
>> > +
>> > +llvm::DIScope *CGDebugInfo::getDeclarationLexicalScope(const Decl &D,
>> > +   QualType Ty) {
>> > +  auto I = LexicalBlockMap.find(&D);
>> > +  if (I != LexicalBlockMap.end()) {
>> > +RetainedTypes.push_back(Ty.getAsOpaquePtr());
>> > +return I->second;
>> > +  }
>> > +  return getDeclContextDescriptor(cast(&D));
>> > +}
>> > +
>> >  void CGDebugInfo::completeType(const EnumDecl *ED) {
>> >if (DebugKind <= codegenoptions::DebugLineTablesOnly)
>> >  return;
>> > @@ -2060,7 +2080,7 @@ llvm::DIType *CGDebugInfo::CreateEnumTyp
>> >  // entered into the ReplaceMap: finalize() will replace the first
>> >  // FwdDecl with the second and then replace the second with
>> >  // complete type.
>> > -llvm::DIScope *EDContext = getDeclContextDescriptor(ED);
>> > +llvm::DIScope *EDContext = getDeclarationLexicalScope(*ED,
>> > + QualType(Ty, 0));
>> >  llvm::DIFile *DefUnit = getOrCreateFile(ED->getLocation());
>> >  llvm::TempDIScope
>> TmpContext(DBuilder.createReplaceableCompositeType(
>> >  llvm::dwarf::DW_TAG_enumeration_type, "", TheCU, DefUnit,
>> > 0)); @@ -2104,7 +2124,7 @@ llvm::DIType *CGDebugInfo::CreateTypeDef
>> >
>> >llvm::DIFile *DefUnit = getOrCreateFile(ED->getLocation());
>> >unsigned Line = getLineNumber(ED->getLocation());
>> > -  llvm::DIScope *EnumContext = getDeclContextDescriptor(ED);
>> > +  llvm::DIScope *EnumContext = getDeclarationLexicalScope(*ED,
>> > + QualType(Ty, 0));
>> >llvm::DIType *ClassTy =
>> >ED->isFixed() ? getOrCreateType(ED->getInteg

Re: [PATCH] RHEL: Look in more places to find g++ headers and runtime

[Rafael Espíndola via cfe-commits]

LGTM. Do you have commit access?

Cheers,
Rafael


On 11 April 2016 at 14:49, Michael Lampe  wrote:
> New patch attached.
>
> -Michael
>
>
> Rafael Espíndola wrote:
>>
>> LGTM with a comment saying why it is needed.
>>
>> Cheers,
>> Rafael
>>
>>
>> On 22 March 2016 at 23:02, Michael Lampe via cfe-commits
>>  wrote:
>>>
>>> Some distros with ten years of support ship an old gcc but later offer
>>> more
>>> recent versions for installation in parallel. These versions are
>>> typically
>>> not only needed for the compilation of llvm/clang, but also to properly
>>> use
>>> the clang binary that comes out.
>>>
>>> Clang already searches /usr at runtime for the most recent installation
>>> of
>>> gcc. This patch appends paths for add-on installations of gcc in RHEL.
>>>
>>>
>>> ___
>>> 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] D19996: New clang option -mpiecopyrelocs to indicate support for linker copy relocations when linking as PIE

[Rafael Espíndola via cfe-commits]

Is there a gcc option or they just assume they are targeting the
linker that was around when gcc was built?


> +  if (Args.hasFlag(options::OPT_mpiecopyrelocs, 
> options::OPT_mno_piecopyrelocs,
> +   false)) {
> +CmdArgs.push_back("-piecopyrelocs");
> +  }

you don't need the {}

> +def piecopyrelocs : Flag<["-"], "piecopyrelocs">,
> +  HelpText<"Linker copy relocations support when linking as PIE">;

I think you are missing a verb: Linker copy relocations *are* supported.

But how about just "Position independent executables can have copy relocations"?

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

Re: [PATCH] RHEL: Look in more places to find g++ headers and runtime

[Rafael Espíndola via cfe-commits]

r268912.

Thanks,
Rafael


On 6 May 2016 at 17:06, Michael Lampe  wrote:
> No, I'm hoping on someone else to commit this. (You?)
>
> Same with this one:
>
> https://www.mail-archive.com/cfe-commits@lists.llvm.org/msg18696.html
>
> -Michael
>
>
> Rafael Espíndola wrote:
>>
>> LGTM. Do you have commit access?
>>
>> Cheers,
>> Rafael
>>
>>
>> On 11 April 2016 at 14:49, Michael Lampe 
>> wrote:
>>>
>>> New patch attached.
>>>
>>> -Michael
>>>
>>>
>>> Rafael Espíndola wrote:


 LGTM with a comment saying why it is needed.

 Cheers,
 Rafael


 On 22 March 2016 at 23:02, Michael Lampe via cfe-commits
  wrote:
>
>
> Some distros with ten years of support ship an old gcc but later offer
> more
> recent versions for installation in parallel. These versions are
> typically
> not only needed for the compilation of llvm/clang, but also to properly
> use
> the clang binary that comes out.
>
> Clang already searches /usr at runtime for the most recent installation
> of
> gcc. This patch appends paths for add-on installations of gcc in RHEL.
>
>
> ___
> 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] Proper detection and handling of RHEL and variants

[Rafael Espíndola via cfe-commits]

r268914.

Thanks,
Rafael

On 26 March 2016 at 20:35, Michael Lampe  wrote:
> New patch attached. I've also removed RHEL4 which is now four years past EOL
> and certainly incapable of building or running any recent version of
> llvm/clang.
>
> -Michael
>
>
> Rafael Espíndola wrote:
>>
>> -  if (IsRedhat(Distro))
>> +  if (Distro == Fedora || Distro == RHEL7)
>>
>> RHEL8 will probably use --no-add-needed.
>>
>> Can you change this to "if (IsRedhat(Distro) && !old_rhel_distro) "?
>>
>> Cheers,
>> Rafael
>>
>>
>> On 22 March 2016 at 22:07, Michael Lampe via cfe-commits
>>  wrote:
>>>
>>> - Don't consider "/etc/lsb-release" to be Ubuntu only.
>>> - Detect SL, too.
>>> - Only add "--no-add-needed" for RHEL7 (or Fedora), not for RHEL6 (that's
>>> what the compilers shipped with RHEL do).
>>>
>>>
>>> ___
>>> 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] D10012: Refactor: Simplify boolean conditional return statements in lib/CodeGen

[Rafael Espíndola via cfe-commits]

r251213

On 24 October 2015 at 14:58, Richard  wrote:
> LegalizeAdulthood updated this revision to Diff 38317.
> LegalizeAdulthood added a comment.
>
> Update to latest.
> I do not have commit access.
>
>
> http://reviews.llvm.org/D10012
>
> Files:
>   lib/CodeGen/BranchFolding.cpp
>   lib/CodeGen/CodeGenPrepare.cpp
>   lib/CodeGen/LiveDebugVariables.cpp
>   lib/CodeGen/MachineRegisterInfo.cpp
>   lib/CodeGen/PeepholeOptimizer.cpp
>   lib/CodeGen/PseudoSourceValue.cpp
>   lib/CodeGen/ScheduleDAGInstrs.cpp
>   lib/CodeGen/StackProtector.cpp
>   lib/CodeGen/TargetInstrInfo.cpp
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D14179: Remove some legacy mingw-w64 gcc struct info

[Rafael Espíndola via cfe-commits]

Correct. I we just switched to the 4.7 abi in r197163.

Cheers,
Rafael


On 29 October 2015 at 12:25, Reid Kleckner  wrote:
> rnk added a comment.
>
> Rafael, we don't support pre GCC 4.7 mingw right? They switched to thiscall 
> on 32bit, right? I think we can take a break for x64.
>
>
> http://reviews.llvm.org/D14179
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r242121 - Add support for -fuse-ld= in the mingw toolchain driver.

[Rafael Espíndola via cfe-commits]

This needs a testcase. Nothing is checking the linker invocation.

On 14 July 2015 at 01:23, Yaron Keren  wrote:
> Author: yrnkrn
> Date: Tue Jul 14 00:23:34 2015
> New Revision: 242121
>
> URL: http://llvm.org/viewvc/llvm-project?rev=242121&view=rev
> Log:
> Add support for -fuse-ld= in the mingw toolchain driver.
> We will still default to ld until such a time lld become a
> stable release. lld supports arm NT under the machine name "thumb2pe".
>
> http://reviews.llvm.org/D11088
>
> Patch by Martell Malone
> Reviewed by Reid Kleckner
>
>
> Modified:
> cfe/trunk/lib/Driver/Tools.cpp
>
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=242121&r1=242120&r2=242121&view=diff
> ==
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Tue Jul 14 00:23:34 2015
> @@ -8947,6 +8947,12 @@ void MinGW::Linker::ConstructJob(Compila
>// handled somewhere else.
>Args.ClaimAllArgs(options::OPT_w);
>
> +  StringRef LinkerName = Args.getLastArgValue(options::OPT_fuse_ld_EQ, "ld");
> +  if (LinkerName.equals_lower("lld")) {
> +CmdArgs.push_back("-flavor");
> +CmdArgs.push_back("gnu");
> +  }
> +
>if (!D.SysRoot.empty())
>  CmdArgs.push_back(Args.MakeArgString("--sysroot=" + D.SysRoot));
>
> @@ -8958,6 +8964,8 @@ void MinGW::Linker::ConstructJob(Compila
>  CmdArgs.push_back("i386pe");
>if (TC.getArch() == llvm::Triple::x86_64)
>  CmdArgs.push_back("i386pep");
> +  if (TC.getArch() == llvm::Triple::arm)
> +CmdArgs.push_back("thumb2pe");
>
>if (Args.hasArg(options::OPT_mwindows)) {
>  CmdArgs.push_back("--subsystem");
> @@ -9067,7 +9075,7 @@ void MinGW::Linker::ConstructJob(Compila
>
>if (Args.hasArg(options::OPT_static))
>  CmdArgs.push_back("--end-group");
> -  else
> +  else if (!LinkerName.equals_lower("lld"))
>  AddLibGCC(Args, CmdArgs);
>  }
>
> @@ -9078,7 +9086,7 @@ void MinGW::Linker::ConstructJob(Compila
>CmdArgs.push_back(Args.MakeArgString(TC.GetFilePath("crtend.o")));
>  }
>}
> -  const char *Exec = Args.MakeArgString(TC.GetProgramPath("ld"));
> +  const char *Exec = 
> Args.MakeArgString(TC.GetProgramPath(LinkerName.data()));
>C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs));
>  }
>
>
>
> ___
> cfe-commits mailing list
> cfe-comm...@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r242121 - Add support for -fuse-ld= in the mingw toolchain driver.

[Rafael Espíndola via cfe-commits]

On 15 November 2015 at 02:39, Filipe Cabecinhas  wrote:
> Handling of values other than lld looked weird.
> Can you make it a hard error to use something other than, I guess, ld, gold,
> lld?
> Or are there other linkers available?

What I find strange is that we use -flavor at all. We should ideally
just be using different links to lld, like we do with "-fuse-ld=lld2".


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

Re: [PATCH][Solaris] Clang/Driver, stop hardcoding GCC paths in crt/ld.so lookup

[Rafael Espíndola via cfe-commits]

SolarisScanLibDirForGCCTriple should start with a lower case. Starting
it with "scan" would probably also be more in line with the code
style.

LGTM

On 11 August 2015 at 16:33, Xan López  wrote:
> Hi,
>
> thanks for the review, I was not even aware that this could be
> tested. Adding a test helped to fix me a couple extra issues (plus the
> one you already mentioned). New patch attached.
>
> Xan
>
> On Wed, Aug 05, 2015 at 09:14:30AM -0400, Rafael Espíndola wrote:
>> Please git-clang-format this patch.
>>
>> +  // /usr/gcc/./lib/gcc/../,
>>
>> The code appends a triple after the "/lib/gcc". Is the comment missing it?
>>
>> The inner loop has no version comparison. Are you depending on the
>> directory iteration order?
>>
>> Can you add a testcase?
>>
>>
>> On 28 July 2015 at 12:35, Xan López  wrote:
>> > Here it is.
>> >
>> > On Tue, Jul 28, 2015 at 01:21:06PM +0200, Xan López wrote:
>> >> On Tue, Jul 28, 2015 at 01:55:23PM +0300, Yaron Keren wrote:
>> >> > +cfe-commits
>> >> >
>> >> > This is a very large Solaris special case in ScanLibDirForGCCTriple 
>> >> > which
>> >> > shares almost no code with the function.
>> >> > How about splitting it out to a helper function or
>> >> > making ScanLibDirForGCCTriple virtual and overriding on Solaris?
>> >>
>> >> Yep, at least a helper function makes sense, you are right. I'll send
>> >> another patch with either of those suggestions later today.
>> >>
>> >>
>> >> Xan
>> >> ___
>> >> llvm-commits mailing list
>> >> llvm-comm...@cs.uiuc.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> >
>> > ___
>> > llvm-commits mailing list
>> > llvm-comm...@cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> >
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH][Solaris] Clang/Driver, stop hardcoding GCC paths in crt/ld.so lookup

[Rafael Espíndola via cfe-commits]

Do you have a version with the last suggestions? I lgtmed it conditional on
it.   Do you need someone to commit it for you?
On Aug 23, 2015 7:07 PM, "Rafael Espíndola" 
wrote:

> SolarisScanLibDirForGCCTriple should start with a lower case. Starting
> it with "scan" would probably also be more in line with the code
> style.
>
> LGTM
>
> On 11 August 2015 at 16:33, Xan López  wrote:
> > Hi,
> >
> > thanks for the review, I was not even aware that this could be
> > tested. Adding a test helped to fix me a couple extra issues (plus the
> > one you already mentioned). New patch attached.
> >
> > Xan
> >
> > On Wed, Aug 05, 2015 at 09:14:30AM -0400, Rafael Espíndola wrote:
> >> Please git-clang-format this patch.
> >>
> >> +  // /usr/gcc/./lib/gcc/../,
> >>
> >> The code appends a triple after the "/lib/gcc". Is the comment missing
> it?
> >>
> >> The inner loop has no version comparison. Are you depending on the
> >> directory iteration order?
> >>
> >> Can you add a testcase?
> >>
> >>
> >> On 28 July 2015 at 12:35, Xan López  wrote:
> >> > Here it is.
> >> >
> >> > On Tue, Jul 28, 2015 at 01:21:06PM +0200, Xan López wrote:
> >> >> On Tue, Jul 28, 2015 at 01:55:23PM +0300, Yaron Keren wrote:
> >> >> > +cfe-commits
> >> >> >
> >> >> > This is a very large Solaris special case in
> ScanLibDirForGCCTriple which
> >> >> > shares almost no code with the function.
> >> >> > How about splitting it out to a helper function or
> >> >> > making ScanLibDirForGCCTriple virtual and overriding on Solaris?
> >> >>
> >> >> Yep, at least a helper function makes sense, you are right. I'll send
> >> >> another patch with either of those suggestions later today.
> >> >>
> >> >>
> >> >> Xan
> >> >> ___
> >> >> llvm-commits mailing list
> >> >> llvm-comm...@cs.uiuc.edu
> >> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >> >
> >> > ___
> >> > llvm-commits mailing list
> >> > llvm-comm...@cs.uiuc.edu
> >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >> >
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH][Solaris] Clang/Driver, stop hardcoding GCC paths in crt/ld.so lookup

[Rafael Espíndola via cfe-commits]

r246473.

On 31 August 2015 at 13:30, Xan López  wrote:
> Oops, missed this. Here is the updated patch.
>
> And yes please, commit the patch for me.
>
> Cheers,
>
> Xan
>
> On Mon, Aug 31, 2015 at 01:07:35PM -0400, Rafael Espíndola wrote:
>> Do you have a version with the last suggestions? I lgtmed it conditional on
>> it.   Do you need someone to commit it for you?
>> On Aug 23, 2015 7:07 PM, "Rafael Espíndola" 
>> wrote:
>>
>> > SolarisScanLibDirForGCCTriple should start with a lower case. Starting
>> > it with "scan" would probably also be more in line with the code
>> > style.
>> >
>> > LGTM
>> >
>> > On 11 August 2015 at 16:33, Xan López  wrote:
>> > > Hi,
>> > >
>> > > thanks for the review, I was not even aware that this could be
>> > > tested. Adding a test helped to fix me a couple extra issues (plus the
>> > > one you already mentioned). New patch attached.
>> > >
>> > > Xan
>> > >
>> > > On Wed, Aug 05, 2015 at 09:14:30AM -0400, Rafael Espíndola wrote:
>> > >> Please git-clang-format this patch.
>> > >>
>> > >> +  // /usr/gcc/./lib/gcc/../,
>> > >>
>> > >> The code appends a triple after the "/lib/gcc". Is the comment missing
>> > it?
>> > >>
>> > >> The inner loop has no version comparison. Are you depending on the
>> > >> directory iteration order?
>> > >>
>> > >> Can you add a testcase?
>> > >>
>> > >>
>> > >> On 28 July 2015 at 12:35, Xan López  wrote:
>> > >> > Here it is.
>> > >> >
>> > >> > On Tue, Jul 28, 2015 at 01:21:06PM +0200, Xan López wrote:
>> > >> >> On Tue, Jul 28, 2015 at 01:55:23PM +0300, Yaron Keren wrote:
>> > >> >> > +cfe-commits
>> > >> >> >
>> > >> >> > This is a very large Solaris special case in
>> > ScanLibDirForGCCTriple which
>> > >> >> > shares almost no code with the function.
>> > >> >> > How about splitting it out to a helper function or
>> > >> >> > making ScanLibDirForGCCTriple virtual and overriding on Solaris?
>> > >> >>
>> > >> >> Yep, at least a helper function makes sense, you are right. I'll send
>> > >> >> another patch with either of those suggestions later today.
>> > >> >>
>> > >> >>
>> > >> >> Xan
>> > >> >> ___
>> > >> >> llvm-commits mailing list
>> > >> >> llvm-comm...@cs.uiuc.edu
>> > >> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> > >> >
>> > >> > ___
>> > >> > llvm-commits mailing list
>> > >> > llvm-comm...@cs.uiuc.edu
>> > >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> > >> >
>> >
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12511: [LTO] Pass -no-zero-initialized-in-bss on linker command line

[Rafael Espíndola via cfe-commits]

Looks like something that should be in the bitcode, no? What happens if one
compile unit has it and another one doesn't?
On Aug 31, 2015 8:50 PM, "Akira Hatanaka via cfe-commits" <
cfe-commits@lists.llvm.org> wrote:

> ahatanak created this revision.
> ahatanak added reviewers: echristo, dexonsmith.
> ahatanak added a subscriber: cfe-commits.
>
> Clang driver option -fno-zero-initialized-in-bss is used to prevent global
> variables that are initialized to zero from being placed in the bss
> section, but is currently ignored when doing LTO. This patch fixes this bug
> by passing -no-zero-initialized-in-bss on ld64's command line using -mllvm.
> If we agree on the approach this patch takes, I plan to make similar
> changes for gold's plugin.
>
> http://reviews.llvm.org/D12511
>
> Files:
>   lib/Driver/Tools.cpp
>   test/Driver/no-zero-initialized-in-bss.c
>
> Index: test/Driver/no-zero-initialized-in-bss.c
> ===
> --- /dev/null
> +++ test/Driver/no-zero-initialized-in-bss.c
> @@ -0,0 +1,11 @@
> +// RUN: %clang -### -c -fno-zero-initialized-in-bss %s 2>&1 | FileCheck
> -check-prefix CHECK-NO-ZERO %s
> +// RUN: %clang -### -c -fzero-initialized-in-bss %s 2>&1 | FileCheck
> -check-prefix CHECK-ZERO %s
> +// RUN: %clang -### -c %s 2>&1 | FileCheck -check-prefix CHECK-ZERO %s
> +// RUN: %clang -### -flto -fzero-initialized-in-bss
> -fno-zero-initialized-in-bss -target x86_64-apple-darwin %s 2>&1 |
> FileCheck -check-prefix CHECK-NO-ZERO-LTO-DARWIN %s
> +// RUN: %clang -### -flto -fno-zero-initialized-in-bss
> -fzero-initialized-in-bss -target x86_64-apple-darwin %s 2>&1 | FileCheck
> -check-prefix CHECK-ZERO-LTO-DARWIN %s
> +// RUN: %clang -### -flto -target x86_64-apple-darwin %s 2>&1 | FileCheck
> -check-prefix CHECK-ZERO-LTO-DARWIN %s
> +
> +// CHECK-NO-ZERO: -mno-zero-initialized-in-bss
> +// CHECK-ZERO-NOT: -mno-zero-initialized-in-bss
> +// CHECK-NO-ZERO-LTO-DARWIN: -mllvm -nozero-initialized-in-bss
> +// CHECK-ZERO-LTO-DARWIN-NOT: -mllvm -nozero-initialized-in-bss
> Index: lib/Driver/Tools.cpp
> ===
> --- lib/Driver/Tools.cpp
> +++ lib/Driver/Tools.cpp
> @@ -6579,6 +6579,11 @@
>Args.AddAllArgs(CmdArgs, options::OPT_dylinker__install__name);
>Args.AddLastArg(CmdArgs, options::OPT_dylinker);
>Args.AddLastArg(CmdArgs, options::OPT_Mach);
> +
> +  if (D.IsUsingLTO(Args))
> +if (!Args.hasFlag(options::OPT_fzero_initialized_in_bss,
> +  options::OPT_fno_zero_initialized_in_bss))
> +  CmdArgs.push_back("-mllvm -nozero-initialized-in-bss");
>  }
>
>  void darwin::Linker::ConstructJob(Compilation &C, const JobAction &JA,
>
>
>
> ___
> 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] D12511: [LTO] Pass -no-zero-initialized-in-bss on linker command line

[Rafael Espíndola via cfe-commits]

On 31 August 2015 at 22:45, Akira Hatanaka  wrote:
> ahatanak added a comment.
>
> If it's important to be able to compile one file with 
> -fno-zero-initialized-in-bss and another without the option, we could add a 
> bit to GlobalVariable that indicates it shouldn't be go into the bss section. 
> Is that what you are suggesting?

Yes, but note that we don't need an extra bit, we can explicitly set
the section.

> If we are going to take that approach, users will be passing 
> -fno-zero-initialized-in-bss at compile time to set the bit for the 
> GlobalVariables clang creates and pass the option again at link time (which 
> will translate into -mllvm -nozero-initialized-in-bss) since some of the 
> passes that are run at link time create GlobalVariables.

This on the other hand suggests that a global flag (i.e., your patch)
is better. We don't optimize a function from SSE2 to SSE4, but we
might noticed that the initializer of a GV is always zero and then
have the choice of putting it in .bss or .data.

Eric, any thoughts?

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

Re: r246497 - [modules] Rework serialized DeclContext lookup table management. Instead of

[Rafael Espíndola via cfe-commits]

Any chance this is what caused the following leak?

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/8340/steps/check-clang%20asan/logs/stdio

Cheers,
Rafael


On 31 August 2015 at 18:17, Richard Smith via cfe-commits
 wrote:
> Author: rsmith
> Date: Mon Aug 31 17:17:11 2015
> New Revision: 246497
>
> URL: http://llvm.org/viewvc/llvm-project?rev=246497&view=rev
> Log:
> [modules] Rework serialized DeclContext lookup table management. Instead of
> walking the loaded ModuleFiles looking for lookup tables for the context, 
> store
> them all in one place, and merge them together if we find we have too many
> (currently, more than 4). If we do merge, include the merged form in our
> serialized lookup table, so that downstream readers never need to look at our
> imports' tables.
>
> This gives a huge performance improvement to builds with very large numbers of
> modules (in some cases, more than a 2x speedup was observed).
>
> Added:
> cfe/trunk/lib/Serialization/MultiOnDiskHashTable.h
> Modified:
> cfe/trunk/include/clang/Serialization/ASTBitCodes.h
> cfe/trunk/include/clang/Serialization/ASTReader.h
> cfe/trunk/include/clang/Serialization/ASTWriter.h
> cfe/trunk/include/clang/Serialization/Module.h
> cfe/trunk/lib/Serialization/ASTReader.cpp
> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
> cfe/trunk/lib/Serialization/ASTReaderInternals.h
> cfe/trunk/lib/Serialization/ASTWriter.cpp
> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
> cfe/trunk/lib/Serialization/Module.cpp
> cfe/trunk/test/Modules/cxx-templates.cpp
> cfe/trunk/test/Modules/merge-using-decls.cpp
>
> Modified: cfe/trunk/include/clang/Serialization/ASTBitCodes.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Serialization/ASTBitCodes.h?rev=246497&r1=246496&r2=246497&view=diff
> ==
> --- cfe/trunk/include/clang/Serialization/ASTBitCodes.h (original)
> +++ cfe/trunk/include/clang/Serialization/ASTBitCodes.h Mon Aug 31 17:17:11 
> 2015
> @@ -1530,4 +1530,23 @@ namespace clang {
>}
>  } // end namespace clang
>
> +namespace llvm {
> +  template <> struct DenseMapInfo {
> +static clang::serialization::DeclarationNameKey getEmptyKey() {
> +  return clang::serialization::DeclarationNameKey(-1, 1);
> +}
> +static clang::serialization::DeclarationNameKey getTombstoneKey() {
> +  return clang::serialization::DeclarationNameKey(-1, 2);
> +}
> +static unsigned
> +getHashValue(const clang::serialization::DeclarationNameKey &Key) {
> +  return Key.getHash();
> +}
> +static bool isEqual(const clang::serialization::DeclarationNameKey &L,
> +const clang::serialization::DeclarationNameKey &R) {
> +  return L == R;
> +}
> +  };
> +}
> +
>  #endif
>
> Modified: cfe/trunk/include/clang/Serialization/ASTReader.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Serialization/ASTReader.h?rev=246497&r1=246496&r2=246497&view=diff
> ==
> --- cfe/trunk/include/clang/Serialization/ASTReader.h (original)
> +++ cfe/trunk/include/clang/Serialization/ASTReader.h Mon Aug 31 17:17:11 2015
> @@ -282,9 +282,8 @@ class ReadMethodPoolVisitor;
>
>  namespace reader {
>class ASTIdentifierLookupTrait;
> -  /// \brief The on-disk hash table used for the DeclContext's Name lookup 
> table.
> -  typedef llvm::OnDiskIterableChainedHashTable
> -ASTDeclContextNameLookupTable;
> +  /// \brief The on-disk hash table(s) used for DeclContext name lookup.
> +  struct DeclContextLookupTable;
>  }
>
>  } // end namespace serialization
> @@ -507,6 +506,10 @@ private:
>/// \brief Map from the TU to its lexical contents from each module file.
>std::vector> TULexicalDecls;
>
> +  /// \brief Map from a DeclContext to its lookup tables.
> +  llvm::DenseMap + serialization::reader::DeclContextLookupTable> Lookups;
> +
>// Updates for visible decls can occur for other contexts than just the
>// TU, and when we read those update records, the actual context may not
>// be available yet, so have this pending map using the ID as a key. It
> @@ -514,7 +517,6 @@ private:
>struct PendingVisibleUpdate {
>  ModuleFile *Mod;
>  const unsigned char *Data;
> -unsigned BucketOffset;
>};
>typedef SmallVector DeclContextVisibleUpdates;
>
> @@ -1089,6 +1091,10 @@ public:
>  Visit(GetExistingDecl(ID));
>}
>
> +  /// \brief Get the loaded lookup tables for \p Primary, if any.
> +  const serialization::reader::DeclContextLookupTable *
> +  getLoadedLookupTables(DeclContext *Primary) const;
> +
>  private:
>struct ImportedModule {
>  ModuleFile *Mod;
> @@ -1870,6 +1876,13 @@ public:
>/// Note: overrides method in ExternalASTSource
>Module *getModule(unsigned ID) override;
>
> +  /// \brief 

Re: r246659 - [MS ABI] Number unnamed TagDecls which aren't externally visible

[Rafael Espíndola via cfe-commits]

Thanks!

On 2 September 2015 at 11:50, David Majnemer via cfe-commits
 wrote:
> Author: majnemer
> Date: Wed Sep  2 10:50:38 2015
> New Revision: 246659
>
> URL: http://llvm.org/viewvc/llvm-project?rev=246659&view=rev
> Log:
> [MS ABI] Number unnamed TagDecls which aren't externally visible
>
> TagDecls (structs, enums, etc.) may have the same name for linkage
> purposes of one another; to disambiguate, we add a number to the mangled
> named.  However, we didn't do this if the TagDecl has a pseudo-name for
> linkage purposes (it was defined alongside a DeclaratorDecl or a
> TypeNameDecl).
>
> This fixes PR24651.
>
> Modified:
> cfe/trunk/lib/AST/MicrosoftMangle.cpp
> cfe/trunk/test/CodeGenCXX/mangle-ms-cxx11.cpp
>
> Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=246659&r1=246658&r2=246659&view=diff
> ==
> --- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
> +++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Wed Sep  2 10:50:38 2015
> @@ -180,7 +180,9 @@ public:
>
>  // Anonymous tags are already numbered.
>  if (const TagDecl *Tag = dyn_cast(ND)) {
> -  if (Tag->getName().empty() && !Tag->getTypedefNameForAnonDecl())
> +  if (!Tag->hasNameForLinkage() &&
> +  !getASTContext().getDeclaratorForUnnamedTagDecl(Tag) &&
> +  !getASTContext().getTypedefNameForUnnamedTagDecl(Tag))
>  return false;
>  }
>
>
> Modified: cfe/trunk/test/CodeGenCXX/mangle-ms-cxx11.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/mangle-ms-cxx11.cpp?rev=246659&r1=246658&r2=246659&view=diff
> ==
> --- cfe/trunk/test/CodeGenCXX/mangle-ms-cxx11.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/mangle-ms-cxx11.cpp Wed Sep  2 10:50:38 2015
> @@ -261,3 +261,19 @@ struct B {
>  void f(decltype(B::e)) {}
>  // CHECK-DAG: @"\01?f@UnnamedType@@YAXPAW4@?$B@H@1@@Z
>  }
> +
> +namespace PR24651 {
> +template 
> +void f(T) {}
> +
> +void g() {
> +  enum {} E;
> +  f(E);
> +  {
> +enum {} E;
> +f(E);
> +  }
> +}
> +// CHECK-DAG: 
> @"\01??$f@W4@?1??g@PR24651@@YAXXZ@@PR24651@@YAXW4@?1??g@0@YAXXZ@@Z"
> +// CHECK-DAG: 
> @"\01??$f@W4@?2??g@PR24651@@YAXXZ@@PR24651@@YAXW4@?2??g@0@YAXXZ@@Z"
> +}
>
>
> ___
> 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 for PR23472

[Rafael Espíndola via cfe-commits]

I fully trust Reid review on this, so OK with me.

On 3 September 2015 at 14:04, Yaron Keren  wrote:
> http://llvm.org/pr23472
>
> As suggested by Reid, OK to commit?
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits