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
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 pres
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 ne
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
>
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 win
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
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 l
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
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
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.
>
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 201
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
>
> Tag
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/
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/
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://re
>> 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 f
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.or
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/vie
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 h
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
>
>
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.o
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:
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-c
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
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 commi
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 (IsRe
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
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 earl
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
+ 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
>> wro
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 t
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=
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 neede
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 AP
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 regre
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 CFConsta
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 techni
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/l
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
> --
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 aggressiv
> 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.
Wha
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
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
>>>
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 passi
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.or
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
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 so
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-commi
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
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
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,
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.llv
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://l
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 :)
>>
>> Committe
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_RELOCATION
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
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 Z
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 Rev
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
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..6b9
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 subscrib
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.
&g
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
- 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-releas
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 be
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 -f
> 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 declar
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 rev
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 C
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
_
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
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 ideal
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
>
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
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 do
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.or
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
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
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
> Lo
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 => /l
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 s
>> 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
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 a
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, rsandi
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.
>
> T
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 tes
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 wr
87 matches
Mail list logo
