[llvm-bugs] [Bug 46166] New: PCH restrictions on floating-point command line options are too strict

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=46166

            Bug ID: 46166
           Summary: PCH restrictions on floating-point command line
                    options are too strict
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C
          Assignee: unassignedclangbugs at nondot.org
          Reporter: melanie.blower at intel.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

In https://reviews.llvm.org/D72841/ yaxunl pointed out that the precompiled
header restrictions on floating point command line options are too strict.
"Essentially this requires a pch can only be used with the same fp options with
which the pch is generated. Since there are lots of fp options, it is
impractical to generate pch for all the combinations."

John McCall suggested a way to solve the problem, 
"if you restore the pragma stack and FP state naively given the current
representation of FP state, you will completely overwrite the FP settings of
the current translation unit with the FP settings that were in effect when the
PCH was built, which is obviously not okay. This is one way (among several)
that the current representation is not really living up to the statement that
these language options are "compatible". The better way to do this would be for
the pragma stack and Expr nodes to record the current set of overrides in
effect rather than the absolute current state; this could then be easily
applied to an arbitrary global FP state."

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200601/cd6637b0/attachment.html>