GNU Tools @ LPC Thursday 27 Aug 2020: chat record ================================================= All times are BST (UTC + 1) Pre-start --------- [14:10] Elena Zannoni : Hi Sarah I got an email from Andrea Corallo saying he uploaded new slides this morning [14:10] Elena Zannoni : and to make sure you pick them "fresh" from the lpc website [14:11] Sarah Cook : Hi Elena, I downloaded them about 30 minutes ago. When did Andrea email you? [14:12] Elena Zannoni : it was 1:45 AM my time, I am -7 from UK [14:12] Elena Zannoni : so you got the right version [14:12] Sarah Cook : ah ok, thank you for letting me know :) [14:28] YouTube Live : This meeting is streaming live on YouTube [14:34] Jose E. Marchesi : yo [14:35] Sarah Cook : hello :) [14:35] Ulrich Weigand : Hi Sarah [14:35] Jeremy Bennett : Good morning all [14:54] Ben Woodard : Jusst wanted to wave hi to you Jakub [14:55] Elena Zannoni : LLVM people asking for some attendance from GNu people for the memory ordering discussionif anybody is interested [14:58] Elena Zannoni : let's not start too early, the live stream should be going before we start [14:58] Elena Zannoni : let me check [14:59] Elena Zannoni : it's not streaming yet [14:59] Jeremy Bennett : I'll be recording shared notes during the BoFs. Feel free to dive in and correct them (click on the Shared Notes button on the upper left) [14:59] Sarah Cook : Live stream is now working OpenMP, OpenACC & Offloading BoF -------------------------------- [15:00] Elena Zannoni : excellent i can see it too [15:03] Pedro Alves : Hello all. [15:08] Tom de Vries : sounds possible [15:08] Tom de Vries : invoking mkoffload twice [15:09] Ben Woodard : So did I hear correctly that GCN is in a data section not a text section? [15:10] Andrew Stubbs : @Ben the GCN ELF file is embedded in the X86_64 ELF file as data [15:11] Ben Woodard : @andrew does that include the DWARF too? [15:12] Ben Woodard : As in is the DWARF a normal section within the GCN data section within the x86_64 ELF [15:12] Andrew Stubbs : @Ben the whole GCN ELF file [15:13] Ben Woodard : Interesting - very recursive. [15:14] Nick Alcock : sounds similar to what .debug_data does (only that is debug sections only, and compressed). Now I'm wondering if you can have .debug_data inside GCN inside an executable :) [15:14] Nick Alcock : (at least I think that's the name of the section: it's been a while) [15:15] Andrew Stubbs : it's no weirder than putting a tar file inside a tar file [15:15] Andrew Stubbs : I can't get audio connection today either :-( [15:15] Ben Woodard : More staff needed. [15:16] Ben Woodard : The use of OpenMP is growing and so of course the use cases are broadening. [15:17] Jeremy Bennett : Seems somewhat broken that all these supercomputers cost millions, yet there is minimal investment in the optimizations to support that hardware [15:17] Jeremy Bennett : ISTR a statistic that 30% of the code on UK public HPC facilities is compiled with GNU tools [15:19] Andrew Stubbs : I think AMD's primary goal is to write new software in HIP (LLVM inside), and OpenMP/OpenACC is more for enabling legacy projects. [15:19] Patrick McGehearty : HPC tradition (going back to at least the 1980s) is purchase decisions are highly price/perf competitive. Investing by HW vendors in shared SW is not prioritized as it gives little market advantage. [15:20] Andrew Stubbs : I can't claim much insight into their private intensions though [15:20] Ben Woodard : @jeremy Part of the problem is it is not obvious how to connect the people with money to people doing the work. [15:20] Jeremy Bennett : That suggests a disfunctional market. There should be a competitve advantage to a vendor who can take out the cost of developing proprietary tools by sharing that cost. [15:21] Andrew Stubbs : @Jeremy if only there were services companies happy to take their money! ;-) [15:21] Jeremy Bennett : :-) [15:21] Ben Woodard : I will say that part of the problem is religious opposition "c++ is the one and only future" [15:22] Ben Woodard : and I have been doing my best to change that. [15:24] Gaius Mulley : likewise :-) [15:25] Ben Woodard : Honestly the highest bang for buck would ompd [15:28] Jeremy Bennett : Hacker room 1, 3, 4, 5 are free [15:28] Jakub Jelínek : For OMPD it would help with the implementation if e.g. the GDB side was done (which can be e.g. tested against the LLVM implementation) [15:28] Jakub Jelínek : Without the debugger side in order to test OMPD one has to write a test debugger plugin which implements it [15:29] Ben Woodard : that is something useful to know. [15:29] Ben Woodard : I wasn't aware of that, and I will add that to my - "how to get it done" document [15:29] Tobias Burnus : Iff someone wants to continue in a hackroom, I am in 3 @ https://meet.2020.linuxplumbersconf.org/hackrooms Speed v accuracy BoF -------------------- [15:30] Tobias Burnus : However, I think most want to continue in with the next BoF - including me :-) [15:30] Ben Woodard : exactly [15:34] DJ Delorie : is 16 ULP the 16 LSBs, or the value "16" in the LSBs? [15:35] Segher Boessenkool : 16 LSbs [15:35] Jakub Jelínek : I thought 16ulp error means 4smallest mantissa bits wrong [15:35] Jeff Law : is jsm around/ [15:35] Jeff Law : oh, he's typing ;-) [15:35] Joseph Myers : 16ulp should mean 4 smallest bits, but the slides may be using some other sense. [15:35] Segher Boessenkool : yeah [15:37] Joseph Myers : The glibc testsuite expects all functions to have results within 9ulp (9 in the LSBs) everywhere. cpow and Bessel functions are known to fail that at present. [15:37] Joseph Myers : Fixing cpow would mean using very large precision for some inputs. [15:38] Joseph Myers : Bessel functions could be fixed following an approach from a paper of Harrison. [15:39] Joseph Myers : (j0/j1/y0/y1 could be fixed, that is. Fixing jn/yn would probably be much harder.) [15:39] Tobias Burnus : Sometimes, high precision is also not needed. I think a lot of weather -forecast codes recently moved from double to single precision as the extra precision didn't help with the prediction. [15:39] Segher Boessenkool : should -fcx-limited-range be implied by -ffast-math, then? by default only, maybe?\ [15:40] Gaius Mulley : some game engines don't require huge precision [15:42] Segher Boessenkool : (oh heh, it already is!) [15:44] Joseph Myers : There are names such as crexp reserved in TS 18661-4 for correctly rounded versions (probably to become cr_exp in C2x), but those are a lot harder to implement. [15:44] Joseph Myers : And probably not practical to have provably correctly rounded results for binary128 within reasonable resource bounds. [15:45] Tobias Burnus : Didn't we discuss at some point of having different math function such that one can choose? Likewise for using or not using the vectorized versions? - Some other math vendors have some extra libs which override "sin", "cos" etc. of libm to provide faster but less acurate results. [15:45] Jakub Jelínek : If performance doesn't matter and precision is everything, one can always use mpfr/mpc [15:46] DJ Delorie : could a glibc tunable be used to choose a -ffast-math type of option? [15:46] DJ Delorie : or is that a bad idea? [15:46] Jakub Jelínek : But I agree it would be nice to choose accuracy vs. performance [15:47] Tobias Burnus : @DJ: There is already something like that for vectorizable functions, enabled with -ffast-math (and always for Fortran, hmm.) [15:48] Tobias Burnus : /usr/include/bits/math-vector.h and /usr/include/finclude/math-vector-fortran.h with glibc. [15:48] Segher Boessenkool : but what does "accuracy vs. performance" *mean"? everyone wants performance, but the required accuracy differs [15:49] Jeff Law : conceptually you want a knob, not a switch, implementation may be non-trivial [15:50] DJ Delorie : as long as the knob goes up to 11 :-) [15:51] Joseph Myers : People have done work on generating function implementations with configurable accuracy, but that gives more variants than you can reasonably put in a general-purpose system library. [15:51] Segher Boessenkool : yes [15:51] Segher Boessenkool : but the flags as we have them now only give you "reasonable accuracy" vs. "reasonable speed" [15:51] Joseph Myers : (And questions of how you validate that all the variants work correctly.) [15:52] Ben Woodard : amen [15:52] Joseph Myers : FWIW, at some point I'd like to add the many new C2x functions (sinpi, exp2m1, ...) to libm. The FSF is being very slow at processing the addition of MPFR to Mentor's copyright assignment, and most of those functions should be done in MPFR first. [15:52] Gaius Mulley : doom3 uses epsilon 1.0e-6 and the sound epsilon of 1.0/32768 [15:54] Joseph Myers : Paul Z (MPFR/MPC, INRIA) has been doing some things on libm lately. [15:55] Joseph Myers : Also x87 may not be that fast compared to SSE, so it's not so clear how much it should be used. [15:55] Segher Boessenkool : heh [15:56] Joseph Myers : Reviewing complex divide needs the time to read various papers on the subject. [15:56] Jeff Law : jsm. ack. [15:57] Joseph Myers : And Patrick's patches don't obsolete the ones someone sent last year, since the ones from last year also included changes to how GCC expands complex divide inline which I don't think Patrick's do. [15:57] Jeff Law : jsm -- are you referring to what I think was tamar's work? [15:57] Elena Zannoni : patrick close your camera [15:57] Ben Woodard : @patrick https://github.com/woodard/mathbench [15:58] Ben Woodard : may be useful to you [15:58] Joseph Myers : Elan Kalda's. [15:59] Jeff Law : i don't have anything from elan in my box, I'll see if I can find it in the archives Lightning talk: RISC-V bit manipulation --------------------------------------- [16:00] Joseph Myers : Elen Kalda, Aug 2019. [16:00] Jeff Law : thx [16:00] Andrea Corallo : no audio here :/ [16:00] Ben Woodard : I wish the guys from Leon were here to participate in this discussion. [16:00] Joseph Myers : 29 Aug 2019 has the changes to inline expansion. [16:01] Kevin Buettner : I couldn't hear Ulrich either. [16:01] Andrea Corallo : 1+ [16:01] Jeff Law : ah, yes, I remember that patch now... [16:01] Jeremy Bennett : Loud and clear Maxim [16:01] Jeff Law : i don't feel I have the background for that one [16:01] Sarah Cook : I can hear Maxim [16:01] Andrea Corallo : works now [16:05] Joseph Myers : The complex divide patches are in my patch review backlog (which has about 30 GCC and glibc patches or patch series that were too complicated for immediate review when they were posted). [16:11] Serhei Makarov : I can't hear either [16:11] Jeremy Bennett : Ulrich I can't chear you either [16:11] Simon Marchi : I couldn't hear Ulrich either [16:11] Catherine Moore : no [16:12] Catherine Moore : now [16:12] Jeremy Bennett : Yes [16:12] Gaius Mulley : all fine ! [16:13] Nick Alcock : an actual lightning talk! [16:13] DJ Delorie : lightning talk cancelled by lightning? [16:13] Simon Marchi : I think we all wanted to make the same joke, I was too slow [16:13] Serhei Makarov : Got to be fast as lightning to make that joke [16:13] Nick Alcock : yeah you need to move like lightning [16:13] Elena Zannoni : ditto Lightning talk: GNU Tools for CORE-V ------------------------------------ [16:25] Catherine Moore : /me knew there would be a poll [16:27] Gaius Mulley : yes all working [16:27] Sarah Cook : :wave [16:29] Jason Merrill : I imagine many of us didn't feel qualified to judge whether Jeremy's approach was right :) Kludging the editor with the compiler ------------------------------------- [16:30] Jim Wilson : riscv vendor extensions are Xxxx not Yxxx [16:30] Jim Wilson : at least as far as I know [16:31] Jeremy Bennett : Ah - thanks. @Jim - I confess I got that bit from Wikipedia, I couldn't find it on the official RISC-V space [16:33] Jim Wilson : non-privileged spec has an appendix ISA Extension Naming Conventions [16:33] Jim Wilson : maybe they used Y in the past, the naming scheme has changed a few times [16:33] Jeremy Bennett : Thank-you. Knowing where to look is 90% of the skill. [16:35] Nick Alcock : the emacs plugin interface does exist :) [16:35] Nick Alcock : (though it's not very heavily used yet...) [16:36] Welcome to the Linux Plumbers Conference 2020 GNU Tools track/Virtual-Room!

Please remember that the LPC anti-harassment policy applies to interaction in this room, and that this room is being recorded.

Please keep your microphone muted and your video off except when participating in the discussion.

This server is running BigBlueButton. [16:37] David Malcolm : You're welcome! [16:39] Nick Alcock : I don't think the name of an IR has ever made me burst out laughing before [16:41] Nick Alcock : So we may lose advice? I guess you need to suppress this sometimes [16:44] nathan sidwell : why not (the fixnum (1+x )) ? [16:45] Florian Weimer : I think it can't look like Common Lisp? [16:45] DJ Delorie : that bootstrap was "interesting" under djgpp... [16:46] DJ Delorie : hopefully cross-building was considered in all this? [16:46] Nick Alcock : aha! certainly at *this* time we can auto-suppress funcall optimizations specifically of functions that already have (enabled or disabled) advice attached. [16:50] Mark Wielaard : very nice [16:50] Alex Coplan : Can you give an example of the kind of thing that speed 3 breaks w.r.t emacs lisp sematics? [16:50] Mark Wielaard : the libgccjit leaks memory thing seems a bit worrying though [16:51] David Malcolm : Leaks are https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63854 [16:52] Alex Coplan : @Mark: most of the leaks are in the driver and should be easy to fix over time [16:56] Mark Wielaard : https://sourceware.org/libabigail/ Flow based diagnostics in GCC ----------------------------- [17:17] Ben Woodard : Can we add a option like: -Wenable-lowlevel-system-code [17:17] Ben Woodard : to disable those hacks he spoke of [17:26] Mark Wielaard : clap clap clap, thanks Enable Intel CET in Linux OS ---------------------------- [17:45] Joseph Sible : Is there a way that we can test the kernel support for CET without having a processor that supports it, like how we can use SDE to test userspace support for it? [17:47] Mark Wielaard : Is there agreement on the CET markers between kernel and user space/toolchains yet? [17:48] DJ Delorie : iirc the markers are opcodes, so yes [17:48] William Cohen : Has there been any testing to see that CET works with x86 kprobes optimization? [17:48] DJ Delorie : or did you mean the object-level tags? [17:49] Mark Wielaard : DJ I meant the various ELF notes [17:50] Alexander Popov : Thanks for the talk! [17:51] Alexander Popov : Could you compare PAX_RAP va CET? [17:52] Alexander Popov : It is grsecurity feature against ROP [17:52] Alexander Popov : In software [17:52] Kristen Accardi : its a software only feature [17:53] William Cohen : Mark Wielaard, could valgrind emulate CET to check code for people that don't have access to CET enabled-hardware? [17:53] qing zhao : If 100% Linux OS is enabled CET, how well can we prevent ROP? [17:54] Mark Wielaard : wcohen, it could but it would be a lot of work, because it would have to emulate the whole shadow stack itself. [17:56] Mark Wielaard : But it is a good question if the code generated by valgrind VEX is CET safe, it currently isn't. And I don't know of any work of making it so. Basically VEX is a JIT, so it needs to generate the right ENDBR calls [17:57] Mark Wielaard : Go GNU Tools Track! Thanks Jeremy! [17:57] Gaius Mulley : Yes thank you everyone - been great! [17:57] Ben Woodard : clap clap!!!! [17:57] Sarah Cook : Thank you all!!! Hope to see you at Cauldron 2021 [17:57] Ben Woodard : Thank you Sarah [17:58] Ben Woodard : your help was much appreciated. [17:58] Jeremy Bennett : Thank you all [17:58] David Malcolm : Thanks everyone [17:58] Mark Wielaard : Yes, thanks Sarah for so diligently answering all my silly emails. Much appreciated! [17:58] Ulrich Weigand : Thank you [17:58] Jeremy Bennett : I shall now save the public chat for the record