This is an archive of the discontinued LLVM Phabricator instance.

Fix emission of _fltused for MSVC.
ClosedPublic

Authored by jyknight on Jan 10 2019, 7:38 AM.

Details

Summary

It should be emitted when any floating-point operations (including
calls) are present in the object, not just when calls to printf/scanf
with floating point args are made.

The difference caused by this is very subtle: in static (/MT) builds,
on x86-32, in a program that uses floating point but doesn't print it,
the default x87 rounding mode may not be set properly upon
initialization.

This commit also removes the walk of the types pointed to by pointer
arguments in calls. (To assist in opaque pointer types migration --
eventually the pointee type won't be available.)

That latter implies that it will no longer consider a call like
scanf("%f", &floatvar) as sufficient to emit _fltused on its
own. And without _fltused, scanf("%f") will abort with error R6002. This
new behavior is unlikely to bite anyone in practice (you'd have to
read a float, and do nothing with it!), and also, is consistent with
MSVC.

Diff Detail

Repository
rL LLVM

Event Timeline

jyknight created this revision.Jan 10 2019, 7:38 AM
rnk accepted this revision.Jan 14 2019, 6:03 PM

I have no idea how you ended up here, but looks good, just a few NFC comments. :)

llvm/include/llvm/IR/Type.h
470 ↗(On Diff #181061)

Seems unrelated?

llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
394 ↗(On Diff #181061)

for (const Instruction &I : instructions(F)) ? That range-for helper is defined near inst_begin.

This revision is now accepted and ready to land.Jan 14 2019, 6:03 PM
jyknight marked 2 inline comments as done.Jan 24 2019, 10:32 AM
jyknight added inline comments.
llvm/include/llvm/IR/Type.h
470 ↗(On Diff #181061)

This GraphTraits code is actually how I ended up looking at _fltused in the first place -- it's the only caller, and I was looking at removing uses of subtype_begin/end. :)

It can go in a followup commit, however.

This revision was automatically updated to reflect the committed changes.
thakis added a subscriber: thakis.Jan 24 2019, 11:51 AM

On https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8923423461858190016/+/steps/package_clang/0/stdout I'm getting:

********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90
FAIL: lld :: COFF/lto-new-symbol.ll (43503 of 45323)
******************** TEST 'lld :: COFF/lto-new-symbol.ll' FAILED ********************
Script:
--
: 'RUN: at line 2';   /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/bin/llvm-as -o /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/tools/lld/test/COFF/Output/lto-new-symbol.ll.tmp.obj /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm/tools/lld/test/COFF/lto-new-symbol.ll
: 'RUN: at line 3';   /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/bin/lld-link /out:/b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/tools/lld/test/COFF/Output/lto-new-symbol.ll.tmp.exe /entry:foo /subsystem:console /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/tools/lld/test/COFF/Output/lto-new-symbol.ll.tmp.obj
--
Exit Code: 1

Command Output (stderr):
--
lld-link: error: undefined symbol: _fltused
>>> referenced by lto.tmp

--

********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.
FAIL: lld :: COFF/lto-lazy-reference.ll (43516 of 45323)
******************** TEST 'lld :: COFF/lto-lazy-reference.ll' FAILED ********************
Script:
--
: 'RUN: at line 2';   /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/bin/llc -mtriple=i686-pc-windows-msvc -filetype=obj -o /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/tools/lld/test/COFF/Output/lto-lazy-reference-quadruple.obj /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm/tools/lld/test/COFF/Inputs/lto-lazy-reference-quadruple.ll
: 'RUN: at line 3';   /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/bin/llvm-as -o /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/tools/lld/test/COFF/Output/lto-lazy-reference-dummy.bc /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm/tools/lld/test/COFF/Inputs/lto-lazy-reference-dummy.ll
: 'RUN: at line 4';   rm -f /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/tools/lld/test/COFF/Output/lto-lazy-reference.ll.tmp.lib
: 'RUN: at line 5';   llvm-ar cru /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/tools/lld/test/COFF/Output/lto-lazy-reference.ll.tmp.lib /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/tools/lld/test/COFF/Output/lto-lazy-reference-quadruple.obj /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/tools/lld/test/COFF/Output/lto-lazy-reference-dummy.bc
: 'RUN: at line 6';   /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/bin/llvm-as -o /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/tools/lld/test/COFF/Output/lto-lazy-reference.ll.tmp.obj /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm/tools/lld/test/COFF/lto-lazy-reference.ll
: 'RUN: at line 7';   /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/bin/lld-link /out:/b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/tools/lld/test/COFF/Output/lto-lazy-reference.ll.tmp.exe /entry:main /subsystem:console /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/tools/lld/test/COFF/Output/lto-lazy-reference.ll.tmp.obj /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm-bootstrap/tools/lld/test/COFF/Output/lto-lazy-reference.ll.tmp.lib
--
Exit Code: 1

Command Output (stderr):
--
lld-link: error: undefined symbol: __fltused
>>> referenced by lto.tmp

Could that be due to this change?

The _fltused symbol being required in those two compilations is expected behavior. What I'm not sure about is why those two tests don't see any definition of the _fltused symbol? I guess they don't link against the C runtime?

The _fltused symbol being required in those two compilations is expected behavior. What I'm not sure about is why those two tests don't see any definition of the _fltused symbol? I guess they don't link against the C runtime?

Oh, of course they don't, because they're intended to work on all platforms. I've fixed the tests in r352110 by just defining the symbol. I believe that's the correct fix.

One of the LLDB bots is still failing because of this change: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/978/steps/test/logs/stdio

Committed r352159 to fix this.

One of the LLDB bots is still failing because of this change: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/978/steps/test/logs/stdio

Committed r352159 to fix this.

Thanks! The Buildbot is back to green.