Commit Graph

11 Commits

Author SHA1 Message Date
Reid Kleckner e6ef4f98d2 The MinGW linker supports response files
This affects both LLD and ld.bfd.

This isn't testable with a normal driver test with -### because those
command lines are printed before response file setup. I tested manually
and confirmed it seems to do the right thing.

llvm-svn: 367733
2019-08-02 22:55:00 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Martin Storsjo 4b75df2cca [MinGW] Allow using LTO when lld is used as linker
Differential Revision: https://reviews.llvm.org/D53195

llvm-svn: 344412
2018-10-12 20:15:51 +00:00
Martin Storsjo f32a0fc80d [MinGW] Allow using ASan
Linking to ASan for MinGW is similar to MSVC, but MinGW always links
the MSVCRT dynamically, so there is only one of the MSVC cases to
consider.

When linking to a shared compiler runtime library on MinGW, the suffix
of the import library is .dll.a.

The existing case of .dll as suffix for windows in general doesn't
seem correct (since this is used for linking). As long as callers never
actually set the Shared flag, the default static suffix of .lib also
worked fine for import libraries as well.

Differential Revision: https://reviews.llvm.org/D52538

llvm-svn: 343537
2018-10-01 20:53:25 +00:00
Martin Storsjo deff753627 [MinGW] Look for a cross sysroot relative to the clang binary
If found, prefer this over looking for a similar gcc later in the
system path.

Differential Revision: https://reviews.llvm.org/D45504

llvm-svn: 330244
2018-04-18 08:47:26 +00:00
Martell Malone c950c651a4 Toolchain: Normalize dwarf, sjlj and seh eh
This is a re-apply of r319294.

adds -fseh-exceptions and -fdwarf-exceptions flags

clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1

-fno-exceptions has a higher priority then specifying the model

move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag

move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check

remove unused USESEHExceptions from the MinGW Driver

fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models

Reviewers: rnk, mstorsjo

Differential Revision: https://reviews.llvm.org/D39673

llvm-svn: 319297
2017-11-29 07:25:12 +00:00
Martell Malone 2fa25706ed Revert "Toolchain: Normalize dwarf, sjlj and seh eh"
This reverts rL319294.
The windows sanitizer does not like seh on x86.
Will re apply with None type for x86

llvm-svn: 319295
2017-11-29 06:51:27 +00:00
Martell Malone 390cfcb0b1 Toolchain: Normalize dwarf, sjlj and seh eh
adds -fseh-exceptions and -fdwarf-exceptions flags

clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1

clang cc1 assumes dwarf is the default if none is passed
and -fno-exceptions has a higher priority then specifying the model

move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag

move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check

remove unused USESEHExceptions from the MinGW Driver

fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models

Reviewers: rnk, mstorsjo

Differential Revision: https://reviews.llvm.org/D39673

llvm-svn: 319294
2017-11-29 06:25:13 +00:00
Akira Hatanaka b72e35a4c4 [Driver][Darwin] Pass -munwind-table when !UseSjLjExceptions.
This commit fixes a bug where clang/llvm doesn't emit an unwind table
for a function when it is marked noexcept. Without this patch, the
following code terminates with an uncaught exception on ARM64:

int foo1() noexcept {
  try {
    throw 0;
  } catch (int i) {
    return 0;
  }
  return 1;
}

int main() {
  return foo1();
}

rdar://problem/32411865

Differential Revision: https://reviews.llvm.org/D35693

llvm-svn: 310006
2017-08-03 23:55:42 +00:00
Martell Malone f9799c70a3 Driver: Better detection of mingw-gcc
Stop blindly searching for "gcc.exe" on windows.
Stop assuming "/usr" on unix, fixes cross compiling.

Reviewers: mati865, yaron.keren

Subscribers: ismail, rnk

Differential revision: https://reviews.llvm.org/D15005

llvm-svn: 300555
2017-04-18 14:27:36 +00:00
David L. Jones f561abab56 [Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)

This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.

There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.

I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.

There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.

Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar

Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D30372

llvm-svn: 297250
2017-03-08 01:02:16 +00:00