| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
Spotted by Edward
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197903 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
| |
These names weren't referred to anywhere in the source so don't need a written
name.
Depends on the TableGen fix for anonymous records in LLVM r197869.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197896 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
imply -fno-math-errno if the user passed -fno-fast-math OR -ffast-math,
regardless of in which order and regardless of the tool chain default.
I've fixed this to follow the logic:
1) If the last dominating flag is -fno-math-errno, -ffast-math, or
-Ofast, then do not use math-errno.
2) If the last dominating flag is an explicit -fmath-errno, do use
math-errno.
3) Otherwise, use the toolchain default.
This, for example, allows the flag sequence
'-ffast-math ... -fno-fast-math' with no mention of '-fmath-errno' or
'-fno-math-errno' to preserve the toolchain default. Most notably, this
should prevent users trying to disable fast-math optimizations on Darwin
and BSD platforms from simultaneously enabling (pointless) -fmath-errno.
I've enhanced the tests (after more reorganization) to cover this and
other weird permutations of flags and targets.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182203 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
| |
setting. Consolidate the collection of tests that enable -fmath-errno
and share a single CHECK line for simplicity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182202 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
is not used.
It is not set at targetting cygming. See PR12920.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169824 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
rdar://12299433
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164638 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
| |
and disable it by default on more platforms.
For now -fno-math-errno is the default on BSD-derived platforms (Darwin,
DragonFlyBSD, FreeBSD, NetBSD, OpenBSD). If the default is not right for
your platform, please yell. I only verified the result with the default
compilers on Darwin and FreeBSD.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155990 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155691 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Linux and other (non-Darwin) platforms and have it use -fmath-errno by
default (for better or worse).
Darwin has seen the light here and uses -fno-math-errno by default, this
patch preserves that.
If any maintainers for a non-Linux platform would also like to opt-in to
-fno-math-errno by default, I'm happy to add folks, but we're currently
getting buts and misleading comparisons with GCC due to this difference
in behavior on Linux at least.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155607 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
Clang driver. This involves a bunch of silly option parsing code to try
to carefully emulate GCC's options. Currently, this takes a conservative
approach, and unless all of the unsafe optimizations are enabled, none
of them are. The fine grained control doesn't seem particularly useful.
If it ever becomes useful, we can add that to LLVM first, and then
expose it here.
This also fixes a few tiny bugs in the flag management around
-fhonor-infinities and -fhonor-nans; the flags now form proper sets both
for enabling and disabling, with the last flag winning.
I've also implemented a moderately terrifying GCC feature where
a language change is also provided by the '-ffast-math' flag by defining
the __FAST_MATH__ preprocessor macro. This feature is tracked and
serialized in the frontend but it isn't used yet. A subsequent patch
will add the preprocessor macro and tests for it.
I've manually tested that codegen appears to respect this, but I've not
dug in enough to see if there is an easy way to test codegen options w/o
relying on the particulars of LLVM's optimizations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147434 91177308-0d34-0410-b5e6-96231b3b80d8
|
