This is an archive of the discontinued LLVM Phabricator instance.

cmath: Support clang's -fdelayed-template-parsing
ClosedPublic

Authored by dexonsmith on Jun 23 2017, 3:56 PM.

Details

Reviewers
hfinkel
EricWF
Summary

r283051 added some functions to cmath (in namespace std) that have the same name as functions in math.h (in the global namespace). Clang's limited support for -fdelayed-template-parsing chokes on this. Rename the ones in cmath and their uses in complex and the test.

(Incidentally, I noticed that r283051 was optimizing the implementation of <complex>. I wonder why we have so much code in that header, instead of calling out to libc's already-optimized <complex.h> implementation?)

rdar://problem/32848355

Diff Detail

Event Timeline

dexonsmith created this revision.Jun 23 2017, 3:56 PM

Ping! Hal, you committed r283051. Do you have a problem with this?

hfinkel accepted this revision.Jul 6 2017, 3:36 PM

Ping! Hal, you committed r283051. Do you have a problem with this?

It looks like you're just renaming __libcpp_isnan and friends to __libcpp_isnan_or_builtin` and similar. LGTM

(Incidentally, I noticed that r283051 was optimizing the implementation of <complex>. I wonder why we have so much code in that header, instead of calling out to libc's already-optimized <complex.h> implementation?)

This is definitely worth looking at (especially given that we don't support complex of user-defined types with those functions). Would making complex<double> use _Complex double, and so on, be an API break? Would that matter?

This revision is now accepted and ready to land.Jul 6 2017, 3:36 PM
dexonsmith closed this revision.Jul 6 2017, 10:20 PM

Ping! Hal, you committed r283051. Do you have a problem with this?

It looks like you're just renaming __libcpp_isnan and friends to __libcpp_isnan_or_builtin` and similar. LGTM

Thanks; committed in r307357.

(Incidentally, I noticed that r283051 was optimizing the implementation of <complex>. I wonder why we have so much code in that header, instead of calling out to libc's already-optimized <complex.h> implementation?)

This is definitely worth looking at (especially given that we don't support complex of user-defined types with those functions). Would making complex<double> use _Complex double, and so on, be an API break? Would that matter?

I think paragraph 4 of complex.numbers (from n4640) effectively enforces that complex<T> and _Complex T are ABI-compatible.