<div dir="auto">I can now present this problem more clearly. I was missing flags fno-math-errno, fno-trapping-math, but clang is also missing some functionality.<div dir="auto"><br></div><div dir="auto">I think that various clang builtins have the same semantics as llvm builtins with both of these math flags set, e.g. sin, exp. There's special handling for sqrt (including returning undef on negative inputs with no-nans-fp-math) in CGBuiltin, but most of libm is emitted as library calls.</div><div dir="auto"><br></div><div dir="auto">SelectionDAGBuilder then matches some of the library calls and emits ISD nodes for them, e.g. it supports exp2 but misses exp. This is too late for implementing libm but otherwise OK.</div><div dir="auto"><br></div><div dir="auto">I would like to add handling to CGBuiltin to lower more of the libm derived clang intrinsics to llvm intrinsics when appropriate fpmath flags are set.</div><div dir="auto"><br></div><div dir="auto">AMDGPU duplicates the libm derived builtins, lowering them via SelectionDAG. This would also work for me but it seems a shame to ignore llvm.sin.f32 et al when they already exist. I can't find a way to target them from C without changing clang.</div><div dir="auto"><br></div><div dir="auto">What does the list think of extending CGBuiltin vs adding more target specific nodes?</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto"><br></div><div dir="auto">Jon</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 Feb 2018 05:41, "via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send cfe-dev mailing list submissions to<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:cfe-dev-request@lists.llvm.org">cfe-dev-request@lists.llvm.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:cfe-dev-owner@lists.llvm.org">cfe-dev-owner@lists.llvm.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cfe-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Implement foo in terms of __builtin_foo fails<br>
(Jon Chesterfield via cfe-dev)<br>
2. Google Summer of Code 2018 (Réka Nikolett Kovács via cfe-dev)<br>
3. Re: GSoC 2018 (Devin Coughlin via cfe-dev)<br>
4. Re: Google Summer of Code 2018 (Artem Dergachev via cfe-dev)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Fri, 23 Feb 2018 20:45:01 +0000<br>
From: Jon Chesterfield via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
Subject: Re: [cfe-dev] Implement foo in terms of __builtin_foo fails<br>
Message-ID:<br>
<<a href="mailto:CAOUYtQB2jX2YGteNifkNA1UaufCVxQeDiLmD0_v9n7rQHpaA7w@mail.gmail.com">CAOUYtQB2jX2YGteNifkNA1UaufCV<wbr>xQeDiLmD0_v9n7rQHpaA7w@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I think this means I'm missing some compilation flags.<br>
<br>
I'm not passing -ffast-math because treating floating point as associative<br>
etc is unattractive, but I'm willing to violate iso c handling of errorno.<br>
fast-math and denormal-fp-math are the only two flags I can find in the<br>
documentation. ffreestanding and fno-builtin don't appear to change the<br>
example. Where are the controlling flags listed?<br>
<br>
Thanks!<br>
<br>
Jon<br>
<br>
On 23 Feb 2018 7:05 p.m., "Joerg Sonnenberger" <<a href="mailto:joerg@bec.de">joerg@bec.de</a>> wrote:<br>
<br>
On Fri, Feb 23, 2018 at 05:03:46PM +0000, Jon Chesterfield via cfe-dev<br>
wrote:<br>
> How can I write C that generates a call to the llvm.sin.f64 intrinsic?<br>
<br>
Why do you want to force that? The library handling already does it when<br>
the compilation flags match them up. I.e. most of the intrinsics are a<br>
lot more restricted than the ISO C constraints.<br>
<br>
Joerg<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20180223/37d29d67/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/cfe-dev/attachments/<wbr>20180223/37d29d67/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sat, 24 Feb 2018 01:10:34 +0100<br>
From: Réka Nikolett Kovács via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
Subject: [cfe-dev] Google Summer of Code 2018<br>
Message-ID:<br>
<CAFdNtUc_hM=<a href="mailto:nHB3pUOta-HEzCGF4e-dVi6L9SeW84NBJEjr_QA@mail.gmail.com">nHB3pUOta-<wbr>HEzCGF4e-dVi6L9SeW84NBJEjr_QA@<wbr>mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Dear All,<br>
<br>
I'm Réka Kovács, a final-year M.S. student from Eötvös Loránd University,<br>
Budapest, and I would love to work on a Clang SA-related GSoC project this<br>
summer.<br>
<br>
I've been working on static analysis for the past half a year and started<br>
meddling in Clang by submitting a few patches:<br>
- 3 Clang-Tidy checks [1][2][3],<br>
- a Clang SA check [4],<br>
- a diagnostic flag extension [5][6], and<br>
- a tiny tweak in the core [7].<br>
<br>
I'm currently studying constraint solving issues in symbolic execution as<br>
part of a university project, and plan to continue with a PhD focusing on<br>
Clang-related stuff.<br>
<br>
I was initially most interested in the Z3 integration project, but I've<br>
noticed that Mikhail has applied already. Creating a checker for dangling<br>
string pointers would also be an interesting challenge, so I'd like to<br>
express my enthusiasm for that project.<br>
<br>
The main goal for me would be to get more comfortable with the inner<br>
workings of the analyzer and learn as much along the process as possible.<br>
<br>
I'm also open to any other suggestions, so please be so kind to share your<br>
thoughts with me.<br>
<br>
Thanks,<br>
Réka<br>
<br>
<br>
[1] bugprone-suspicious-memset-<wbr>usage: <a href="https://reviews.llvm.org/D32700" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D32700</a><br>
[2] bugprone-undefined-memory-<wbr>manipulation: <a href="https://reviews.llvm.org/D35051" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D35051</a><br>
[3] bugprone-integer-division: <a href="https://reviews.llvm.org/D35932" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D35932</a><br>
[4] alpha.cplusplus.<wbr>DeleteWithNonVirtualDtor: <a href="https://reviews.llvm.org/
D35796" rel="noreferrer" target="_blank">https://reviews.llvm.org/<br>
D35796</a><br>
[5] -Wenum-compare: <a href="https://reviews.llvm.org/D36407" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D36407</a><br>
[6] -Wenum-compare-switch: <a href="https://reviews.llvm.org/D36526" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D36526</a><br>
[7] model unrepresentable left shifts: <a href="https://reviews.llvm.org/D41816" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D41816</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20180224/ee457111/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/cfe-dev/attachments/<wbr>20180224/ee457111/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 23 Feb 2018 17:03:00 -0800<br>
From: Devin Coughlin via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: Mikhail Ramalho <<a href="mailto:mikhail.ramalho@gmail.com">mikhail.ramalho@gmail.com</a>><br>
Cc: Mikhail Ramalho via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
Subject: Re: [cfe-dev] GSoC 2018<br>
Message-ID: <<a href="mailto:B33C8A2F-73E5-4D6A-A37C-FFB9F8505FB4@apple.com">B33C8A2F-73E5-4D6A-A37C-<wbr>FFB9F8505FB4@apple.com</a>><br>
Content-Type: text/plain; CHARSET=US-ASCII<br>
<br>
<br>
<br>
> On Feb 23, 2018, at 9:29 AM, Mikhail Ramalho via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I also have a question about the proposal. I understand that ideas about the project will be discussed in the mailing list. However, once that's settled and I write my first draft proposal, should I send it to the mailing list for discussion again or should I send it only to the mentor?<br>
<br>
Please make sure to keep email discussions on the mailing list rather than just personal email. This is a topic that members of the community will be interested in and will have valuable feedback on.<br>
<br>
Devin<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 23 Feb 2018 21:40:32 -0800<br>
From: Artem Dergachev via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: Réka Nikolett Kovács <<a href="mailto:rekanikolett@gmail.com">rekanikolett@gmail.com</a>>,<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
Subject: Re: [cfe-dev] Google Summer of Code 2018<br>
Message-ID: <<a href="mailto:3de8dfa0-40d3-230d-aaaa-42b5dbc55a9b@gmail.com">3de8dfa0-40d3-230d-aaaa-<wbr>42b5dbc55a9b@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Hey, welcome!<br>
<br>
First of all, it's great that you let us know about your interest in the<br>
Z3 integration project. It might be puzzling for us to come up with the<br>
final arrangement, given how the project doesn't seem to be easy to<br>
quantize for cooperative work, but a lot of things may change by the<br>
time everything is settled, and your enthusiasm is an important piece of<br>
the puzzle!<br>
<br>
We didn't come up with other exciting project ideas so far, but the list<br>
of projects is definitely not set in stone. I'd let you know if anything<br>
shows up, and please feel free to share your ideas of how the analyzer<br>
could be improved or what features you want it to have :) I guess i'd<br>
explain the other project a little bit, for completeness.<br>
<br>
The use-after-free-like checker for values managed by temporary objects<br>
should be an easier and more straightforward project than Z3, but there<br>
are quite a lot of unknowns here as well. Because internals of<br>
std::string and other similar classes are too hard for the analyzer's<br>
generic use-after-free checker to understand (partially because of the<br>
lack of a good solver, but mostly due to how hard it is to track STL's<br>
internal invariants, and how not all of the code is necessarily present<br>
in the header), an API-specific checker seems to be necessary. The<br>
original plan we've had in mind was to keep track of dangerous values<br>
like str.c_str() in the program state (similarly to how<br>
SimpleStreamChecker tracks file descriptors) and then see if any of them<br>
are still present in memory at the end of the original value's lifetime<br>
(similarly to how StackAddrEscape checker finds stack pointers at the<br>
end of a function's stack frame).<br>
<br>
With this description and your knowledge, you'd probably be able to<br>
think of how the checker might be implemented (and if it's of interest<br>
to you) - though also feel free to ask if you have any questions! The<br>
unknowns here include how easy would it be to track scopes (for now we<br>
only track function scopes, but if fairly old but recently reincarnated<br>
patches [1] and [2] land any time soon, we may get a much better<br>
granularity), how easy would it be to track objects when they are moved<br>
or lifetime-extended by binding to references, which was a large problem<br>
for other C++ object checkers, but we may work our way around it to some<br>
extent (or do it properly, depending on my current work outlined in [3]<br>
and in follow-up mails in February), and also how helpful inlining would<br>
be (eg. would we be able to automagically support string_view-like<br>
classes by inlining their methods?). So the checker would need an almost<br>
indefinite amount of incremental improvements once the initial prototype<br>
is done, some of which must be fairly curious and would certainly expose<br>
you to some of the analyzer's internals.<br>
<br>
[1] <a href="https://reviews.llvm.org/D16403" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D16403</a><br>
[2] <a href="https://reviews.llvm.org/D19979" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D19979</a><br>
[3] <a href="http://lists.llvm.org/pipermail/cfe-dev/2018-January/056691.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/cfe-dev/2018-<wbr>January/056691.html</a><br>
<br>
On 23/02/2018 4:10 PM, Réka Nikolett Kovács via cfe-dev wrote:<br>
> Dear All,<br>
><br>
> I'm Réka Kovács, a final-year M.S. student from Eötvös Loránd<br>
> University, Budapest, and I would love to work on a Clang SA-related<br>
> GSoC project this summer.<br>
><br>
> I've been working on static analysis for the past half a year and<br>
> started meddling in Clang by submitting a few patches:<br>
> - 3 Clang-Tidy checks [1][2][3],<br>
> - a Clang SA check [4],<br>
> - a diagnostic flag extension [5][6], and<br>
> - a tiny tweak in the core [7].<br>
><br>
> I'm currently studying constraint solving issues in symbolic execution<br>
> as part of a university project, and plan to continue with a PhD<br>
> focusing on Clang-related stuff.<br>
><br>
> I was initially most interested in the Z3 integration project, but<br>
> I've noticed that Mikhail has applied already. Creating a checker for<br>
> dangling string pointers would also be an interesting challenge, so<br>
> I'd like to express my enthusiasm for that project.<br>
><br>
> The main goal for me would be to get more comfortable with the inner<br>
> workings of the analyzer and learn as much along the process as possible.<br>
><br>
> I'm also open to any other suggestions, so please be so kind to share<br>
> your thoughts with me.<br>
><br>
> Thanks,<br>
> Réka<br>
><br>
><br>
> [1] bugprone-suspicious-memset-<wbr>usage:<a href="https://reviews.llvm.org/D32700" rel="noreferrer" target="_blank">https://reviews.llvm.<wbr>org/D32700</a><br>
> <<a href="https://reviews.llvm.org/D32700" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D32700</a>><br>
> [2]<br>
> bugprone-undefined-memory-<wbr>manipulation:<a href="https://reviews.llvm.org/D35051" rel="noreferrer" target="_blank">https://reviews.<wbr>llvm.org/D35051</a><br>
> <<a href="https://reviews.llvm.org/D35051" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D35051</a>><br>
> [3] bugprone-integer-division:<a href="https://reviews.llvm.org/D35932" rel="noreferrer" target="_blank">http<wbr>s://reviews.llvm.org/D35932</a><br>
> <<a href="https://reviews.llvm.org/D35932" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D35932</a>><br>
> [4]<br>
> alpha.cplusplus.<wbr>DeleteWithNonVirtualDtor:<a href="https://reviews.llvm.org/D35796" rel="noreferrer" target="_blank">https<wbr>://reviews.llvm.org/D35796</a><br>
> <<a href="https://reviews.llvm.org/D35796" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D35796</a>><br>
> [5] -Wenum-compare:<a href="https://reviews.llvm.org/D36407" rel="noreferrer" target="_blank">https://<wbr>reviews.llvm.org/D36407</a><br>
> <<a href="https://reviews.llvm.org/D36407" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D36407</a>><br>
> [6] -Wenum-compare-switch:<a href="https://reviews.llvm.org/D36526" rel="noreferrer" target="_blank">https://<wbr>reviews.llvm.org/D36526</a><br>
> <<a href="https://reviews.llvm.org/D36526" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D36526</a>><br>
> [7] model unrepresentable left shifts:<a href="https://reviews.llvm.org/D41816" rel="noreferrer" target="_blank">https://reviews.llvm.<wbr>org/D41816</a><br>
> <<a href="https://reviews.llvm.org/D41816" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D41816</a>><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of cfe-dev Digest, Vol 128, Issue 71<br>
******************************<wbr>**********<br>
</blockquote></div><br></div>