r239213 - clang-cl: Implement /GL in terms of -flto.

[Hans Wennborg]

On Fri, Jun 12, 2015 at 7:34 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> We are planning to create bitcode-compatible replacements for link.exe and
> lib.exe, so it doesn't seem entirely unreasonable for /GL to map to -flto,
> at least once those tools are ready.
>
> In the meantime, there's probably no way at the moment to pass /GL on its own
> and get something that works, so it does make sense to make /GL a no-op again.
> I don't know if we should expose -flto as a core flag though. I'll see if
> there is some combination of -Xclang flags I can use as a workalike for -flto,
> if so I can probably just use that for now until we're ready to implement /GL.
>
> Feel free to revert or I'll do it when I get a chance.

I've reverted in r239656.

Thanks,
Hans

> On Fri, Jun 12, 2015 at 06:59:59PM -0700, Nico Weber wrote:
>> This breaks building with /GL (e.g. in an official chrome build). Clang
>> will think "hey, I'll emit bitcode" and then link.exe or lib.exe will fall
>> over. Mapping /GL to -flto guarantees that every build that uses /GL won't
>> work, which doesn't seem that great. (Linker and static library archiver
>> are called directly on Windows, not through the driver.)
>>
>> Maybe -flto should be a core flag so that it can be passed to clang-cl
>> explicitly, but mapping /GL to -flto seems wrong to me.
>>
>> On Fri, Jun 5, 2015 at 7:09 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
>>
>> > Author: pcc
>> > Date: Fri Jun  5 21:09:34 2015
>> > New Revision: 239213
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=239213&view=rev
>> > Log:
>> > clang-cl: Implement /GL in terms of -flto.
>> >
>> > No documentation yet; the linker needs more work.