[PATCH] D124004: Define __FLT_EVAL_METHOD__ when input source is stdin.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.


================
Comment at: clang/lib/Frontend/FrontendAction.cpp:845-855
+  if (Input.isFile() && Input.getFile() == "-") {
+    Preprocessor &PP = CI.getPreprocessor();
+    std::string PredefineBuffer;
+    PredefineBuffer.reserve(4080);
+    llvm::raw_string_ostream Predefines(PredefineBuffer);
+    Predefines << PP.getPredefines();
+    MacroBuilder Builder(Predefines);
----------------
aaron.ballman wrote:
> zahiraam wrote:
> > aaron.ballman wrote:
> > > I'm confused as to why we want to predefine this macro *only* when the input source is stdin? So I'm not certain I understand why this change is desired.
> > > 
> > > e.g., https://godbolt.org/z/E8Y67381r (note how there's no `__FLT_EVAL_METHOD__` defined there)
> > I was offering a solution  to the issue raised by @glandium in https://reviews.llvm.org/D109239. I thought that the issue was only when the source is stdin, but obviously not.  The default setting should happen under no condition. 
> There have been a lot of reviews over this stuff, so I may be remembering incorrectly... but I thought it was a conscious decision to *not* predefine `__FLT_EVAL_METHOD__` because that value changes depending on pragmas in the TU. I thought the way that macro worked was that we registered it as a macro and we figure out its value at expansion time.
> 
> (The original report confused me into thinking that `__FLT_EVAL_METHOD__` was behaving as though it was never defined, so expansion would never result in a correct value except when the eval method is `0`.)
Yes, you are remembering correctly. I looked at older comments and it's something that was intended. We didn't want to pre-define it, until it is set at expansion.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124004/new/

https://reviews.llvm.org/D124004