Joerg Sonnenberger via cfe-commits writes:
> On Tue, Mar 20, 2018 at 08:42:55PM -, Rafael Espindola via cfe-commits
> wrote:
>> Author: rafael
>> Date: Tue Mar 20 13:42:55 2018
>> New Revision: 328040
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=328040&view=rev
>> Log:
>> Set dso_loca
Sorry, I was just missing "git pull" in the llvm repo.
Cheers,
Rafael
Artem Belevich writes:
> Thanks for the heads up.
>
> Which buildbot shows the failure? I don't see the failure on the cuda
> buildbot, nor do I see it on my machine locally.
>
> It may be due to llvm/clang being out of sync.
With this clang/test/CodeGen/builtins-nvptx-sm_70.cu is crashing:
lib/IR/Instructions.cpp:299: void
llvm::CallInst::init(llvm::FunctionType *, llvm::Value *,
ArrayRef, ArrayRef, const
llvm::Twine &): Assertion `(i >= FTy->getNumParams()||
FTy->getParamType(i) == Args[i]->getType()) && "Calling a f
Thanks!
Reid Kleckner via cfe-commits writes:
> Author: rnk
> Date: Fri Mar 16 13:36:49 2018
> New Revision: 327738
>
> URL: http://llvm.org/viewvc/llvm-project?rev=327738&view=rev
> Log:
> [MS] Don't escape MS C++ names with \01
>
> It is not needed after LLVM r327734. Now it will be easier to
Sriraman Tallam via Phabricator writes:
> + if (CodeGenOpts.NoPLT) {
> +getModule().setAvoidPLT();
> + }
> +
You don't need the {}.
LGTM with that.
Cheers,
Rafael
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-
Eric Christopher via Phabricator writes:
> echristo added inline comments.
>
>
>
> Comment at: lib/CodeGen/CodeGenModule.h:728
> + /// This must be called after dllimport/dllexport is set.
> + /// FIXME: should this set dllimport/dllexport instead?
>void setGVProperties(llv
ping
Rafael Avila de Espindola via Phabricator
writes:
> espindola created this revision.
> espindola added a reviewer: rnk.
>
> The value of dso_local can be computed from just IR properties and global
> information (object file type, command line options, etc).
>
> With this patch we no longe
Sean Fertile via Phabricator writes:
> sfertile added inline comments.
>
>
>
> Comment at: clang/lib/CodeGen/CodeGenModule.cpp:750
> + // If we can use a plt entry as the symbol address we can assume it
> + // is local.
> + if (isa(D) && !CGOpts.NoPLT)
>
> I d
With this I am getting a test failure on linux:
TEST 'Clang :: Driver/riscv-gnutools.c' FAILED
Script:
--
/home/admin/llvm/build/bin/clang -target riscv32-linux-unknown-elf
-fno-integrated-as
--gcc-toolchain=/home/admin/llvm/llvm-project/clang/test/Dri
Ping.
Is this direction OK? Should a put the time to update the existing tests
to account for dso_local?
I do volunteer to implement the rest of ELF, COFF and MachO once this is
in.
Cheers,
Rafael
Rafael Avila de Espindola writes:
> Reid Kleckner via Phabricator writes:
>
>> rnk added inline
Reid Kleckner via Phabricator writes:
> rnk added inline comments.
>
>
>
> Comment at: lib/CodeGen/CodeGenModule.cpp:690-692
> + // Only handle ELF for now.
> + if (!CGM.getTriple().isOSBinFormatELF())
> +return false;
>
> Handling COFF here is probably tri
Petr Hosek writes:
> That's the Fuchsia CMake cache file which is used to build Fuchsia
> toolchain, it's not needed there anymore because Fuchsia Clang driver now
> handles this. I haven't touched Clang's CMakeLists.txt which defines
> the ENABLE_X86_RELAX_RELOCATIONS option.
Oops, I guess I sh
I am probably missing something, but the patch has
-# This is a "Does your linker support it?" option that only applies
-# to x86-64 ELF targets. All Fuchsia target linkers do support it.
-# For x86-64 Linux, it's supported by LLD and by GNU linkers since
-# binutils 2.27, so one can hope that al
Petr Hosek via Phabricator writes:
> -# This is a "Does your linker support it?" option that only applies
> -# to x86-64 ELF targets. All Fuchsia target linkers do support it.
> -# For x86-64 Linux, it's supported by LLD and by GNU linkers since
> -# binutils 2.27, so one can hope that all Linu
Daniel Dunbar writes:
> Author: ddunbar
> Date: Mon Jan 31 16:00:44 2011
> New Revision: 124613
>
> URL: http://llvm.org/viewvc/llvm-project?rev=124613&view=rev
> Log:
> libclang: Don't allow RemoveFileOnSignal to be called via libclang, badness
> can
> ensue.
Sorry for digging out such an old
LGTM
George Rimar via Phabricator writes:
> grimar created this revision.
>
> https://reviews.llvm.org/D28684 changed llvm::zlib to return Error instead of
> Status.
> It was accepted and committed in r292214, but then reverted in r292217
> because I missed that clang code also needs to be upda
16 matches
Mail list logo
