On Mon, Oct 27, 2014 at 7:40 PM, Richard Smith <[email protected]> wrote:
> On Mon, Oct 27, 2014 at 7:09 PM, Sean Silva <[email protected]> wrote: > >> >> >> On Mon, Oct 27, 2014 at 6:16 PM, Robinson, Paul < >> [email protected]> wrote: >> >>> I don't know about Mac, but on my Ubuntu, Intrin.h shows up in the >>> expected place: >>> >>> >>> >>> ~/projects/upstream/writeable/obj$ find . -name Intrin.h >>> >>> ./Debug+Asserts/lib/clang/3.6.0/include/Intrin.h >>> >>> ./Debug+Asserts/lib/clang/3.5.0/include/Intrin.h >>> >>> ./Debug+Asserts/lib/clang/3.4/include/Intrin.h >>> >>> ./Debug+Asserts/lib/clang/3.5/include/Intrin.h >>> >> >> I presume that isn't where existing software for those platforms looks >> for them. >> > > It is, but they do nothing but #include_next the next Intrin.h if you're > not targeting win32, so they act as if they don't exist. > Why do they do that? -- Sean Silva > > >> -- Sean Silva >> >> >>> >>> >>> *From:* Chandler Carruth [mailto:[email protected]] >>> *Sent:* Monday, October 27, 2014 5:17 PM >>> *To:* Robinson, Paul >>> *Cc:* Sean Silva; [email protected] >>> *Subject:* Re: [PATCH][X86] __builtin_ctz/clz sometimed defined for >>> zero input >>> >>> >>> >>> >>> >>> On Mon, Oct 27, 2014 at 5:02 PM, Robinson, Paul < >>> [email protected]> wrote: >>> >>> That makes lzcntintrin.h completely pointless. They'd just be alternate >>> names for the functions in Intrin.h. >>> >>> >>> If those names need to be supported for compatibility and portability >>> then it still seems to have a point. >>> >>> >>> >>> Note that Intrin.h doesn't exist on Linux or Mac. >>> >> >> >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
