On Fri, Jun 12, 2015 at 7:34 PM, Peter Collingbourne <[email protected]> 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 <[email protected]> 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
