Calling parse_url ==== 17-09-2021 ==== 11:51:37 — @corbet: This is the matrix chatroom for the LPC GNU Tools track, available at #gnu-tools-track:lpc.events ==== 20-09-2021 ==== 09:02:06 — @jemarch.gnu.org: Hola hola! :) 09:28:39 — @elena.zannoni.oracle.com: howdy 09:36:34 — @sarah.cook.embecosm.com: Hello all! 09:36:53 — @jemarch.gnu.org: hi sarah 09:40:17 — @jeremy.bennett.embecosm.com: Hi all. Looks like the BBB integration might not be working. 09:41:47 — @jeremy.bennett.embecosm.com: OK - looks like it takes a Loonnnnnnnnnnngggggggggggg time - spinning circle still for me. 09:41:54 — @nix.esperi.org.uk: ta-da! the homeserver appears :) 09:42:10 — @jeremy.bennett.embecosm.com: And now its there. 09:42:48 — @nix.esperi.org.uk: matrix.lpc.events still can't get to it though. 09:43:39 — @jeremy.bennett.embecosm.com: Took me a while to actually read the help message. The login is not your email you need to change the @ to . in your email address. 09:43:33 — @dwmw2: It's on port 8448 and some corporate networks might not allow egress to that port. 09:43:51 — @richard.guenther.gmail.com: connection seems to be somewhat unreliable as well 09:44:18 — @mchehab.kernel.org: > <@nix.esperi.org.uk:lpc.events> matrix.lpc.events still can't get to it though. I tried it with pidgin (pidgin-matrix plugin)... it doesn't recognize my user/pass 09:44:37 — @jemarch.gnu.org: Yeah I'm out of the VPN and seems to be working just fine for me 09:45:00 — @elena.zannoni.oracle.com: you do not stricley speaking need to be on the matrix server, the chat in BBB would probably be enough 09:45:29 — @elena.zannoni.oracle.com: VPN + matrix is not going to work 09:45:40 — @segher.kernel.crashing.org: woohoo, hello everyone 09:46:45 — @nix.esperi.org.uk: @Jeremy Bennett, I was stymied by a "helpful" Chrome changing my username back to my email address again. Thanks, but not really somewhere autocorrect is useful... 09:47:00 — @mchehab.kernel.org: > <@elena.zannoni.oracle.com:lpc.events> you do not stricley speaking need to be on the matrix server, the chat in BBB would probably be enough chat in BBB is not working here.. no VPNs 09:49:06 — @mchehab.kernel.org: hmm... after *several* seconds, BBB started working here 09:51:31 — @sarah.cook.embecosm.com: yes 09:51:35 — @jemarch.gnu.org: yeeees 09:51:42 — @sarah.cook.embecosm.com: all loud and clear 09:52:40 — @segher.kernel.crashing.org: DMs don't work at all though? firewall stuff? 09:54:07 — @sarah.cook.embecosm.com: Yes David can hear and see 09:54:05 — @dwmw2: As you log in for the first time, it creates an account. The server is kind of busy creating accounts right now, and should speed up a lot after a while 09:54:16 — @elena.zannoni.oracle.com: yes to both 10:02:41 — @corbet.lwn.net: I love to see somebody with Linux Device Drivers on their bookshelf :) 10:10:47 — @richard.guenther.gmail.com: C++ support to the level to be able to analyze GCC itself would be nice (and terminate in finite time with analyzing during in LTO bootstrap) 10:20:07 — @richard.guenther.gmail.com: Are there publically available "testsuites" for static analyzers? It must be an active research topic after all. 10:33:19 — @jeremy.bennett.embecosm.com: The answer from David was "yes" - there is a testsuite from NIST. He'll post links. 10:43:55 — @richard.guenther.gmail.com: -Wunused-structure-field 10:51:17 — @dmalcolm.redhat.com: Static analyzer testsuites: https://samate.nist.gov/SARD/testsuite.php 11:12:09 — @nix.esperi.org.uk: hm, why not arrange for all dg tests to scan all options given in dg-options to see if they're supported as a matter of course, and XFAIL things that aren't (and that are declared in some tool-specific dejagnu config file as being expected to fail with this toolchain?). That way you don't have to hack every test individually... 11:16:59 — @joseph.codesourcery.com: For vla-6.c, it's not a test requiring VLAs in structs, it's a test verifying various things (including that) are rejected with -pedantic-errors. So it seems more like a "different error messages" case than "requires GCC-specific feature". 11:18:43 — @joseph.codesourcery.com: And pr87929.c is nothing really to do with -fsignaling-nans, it's just testing particular options that happened to produce an ICE. So it's more like a case where the option should be removed when testing LLVM, than one where the test should be skipped for lack of option support. 11:19:15 — @joseph.codesourcery.com: So for both of those tests that were used as examples, I think the proposed choice is questionable. 11:22:28 — @joseph.codesourcery.com: I do have a related question (maybe for the community in general): any thoughts on the use or practicality of using glibc tests to test other libc implementations? 11:25:31 — @siddhesh.poyarekar.gmail.com: There are some tests that use glibc internals but in general it shouldn't be impossible to do. 11:26:38 — @joseph.codesourcery.com: I'm not working on any answers there, it just seems like a related issue. 11:27:11 — @jemarch.gnu.org: what would be the advantage of doing so? 11:28:49 — @jeremy.bennett.embecosm.com: We can hear you Serhei 11:28:49 — @sarah.cook.embecosm.com: We can hear you 11:29:16 — @alves.ped.gmail.com: Serhei Makarov: we can hear and see you. 11:30:20 — @jeremy.bennett.embecosm.com: We can't hear you now Serhei 11:30:58 — @jemarch.gnu.org: I can't hear anything 11:31:25 — @sawdey.us.ibm.com: I cannot hear Serhei 11:39:45 — @joseph.codesourcery.com: (The compile-time subset of the glibc testsuite is on the stricter side than the execution tests - generally clean for all configurations, except when broken by new GCC warnings.) 11:59:47 — stubbs.mentor.com: I will probably give Bunsen a try. :-) 12:00:43 — @sawdey.us.ibm.com: Are Serhei's slides posted somewhere? They are not here: https://linuxplumbersconf.org/event/11/contributions/1013/ 12:32:36 — @richard.guenther.gmail.com: If the register file were visible as part of global memory would DWARF 5 be expressive enough to specify locations via that global memory mapping? 12:33:44 — @richard.guenther.gmail.com: Thinking of a special __gdb_regs "symbol" to make locations relative to (that could also include threads/slices/whatever) 12:41:29 — @elena.zannoni.oracle.com: it seems the chat is back inside BBB, please try to open the tab 12:41:48 — @elena.zannoni.oracle.com: it takes a minute to reload 12:42:42 — @smakarov.redhat.com: I'm uploading the Bunsen slides to https://people.redhat.com/~smakarov/2021-lpc-talk/ 12:53:28 — @nix.esperi.org.uk: (Side note: CTF archives are used when types have conflicting definitions in different CUs. BTF probably doesn't need this because such definitions shouldn't exist in the kernel: if they do, they'll probably vanish sooner or later because they'd break LTO.) 13:10:39 — @nix.esperi.org.uk: Progress report for binutils libctf since last year: one new feature, symbols derived from TUs compiled with -gctf are now tracked so that you can look up the types of symbols by name or -- in linked output -- by symtab idx. 13:35:08 — @tony.tye.amd.com: Was interested in learning more about how the BPF relocations are encoded and how that supports the kinds of changes that can happen to header files. 13:35:40 — @tony.tye.amd.com: * Was interested in learning more about how the BPF relocations are encoded and how that supports the kinds of changes that can happen to header files. 13:45:27 — @nix.esperi.org.uk: certainly using strings for relocation info in CTF would be... well, I'd fight it ;) I suspect the DWARF hackers would say no too! 13:46:34 — @nix.esperi.org.uk: 2GiB or so for the vmlinux alone. 12GiB for an enterprise kernel. (CTF: 8MiB. BTF: ~2MiB, but BTF doesn't include any types in modules at all, nor function type signatures.) 13:53:12 — @jeremy.bennett.embecosm.com: Bye all - good first day 13:56:57 — @sarah.cook.embecosm.com: Thank you to all our speakers, to you for attending and the events sponsors 13:57:08 — @sarah.cook.embecosm.com: We look forward to seeing you all again tomorrow :) 23:07:00 — @lpcchatadmin: This is the matrix chatroom for the LPC GNU Tools track, available at #gnu-tools-track:lpc.events ==== 21-09-2021 ==== 09:49:04 — @sarah.cook.embecosm.com: Hi All! Welcome to day 2 of the GNU Tools Track! 09:49:32 — @sarah.cook.embecosm.com: If any of the speakers would like to test their microphones and cameras ahead of the event starting in 10 minutes, you are welcome to :) 10:00:05 — @patmcgeh.flash.net: microphone does not seem to be connected... 10:00:19 — @sarah.cook.embecosm.com: Maybe leave and re-join 10:00:30 — @sarah.cook.embecosm.com: sometimes I find I have to reset it to make it behave 10:00:36 — @jemarch.gnu.org: Yeah sometimes the echo test fails 10:04:15 — @patmcgeh.flash.net: odd... headset speakers are working fine but microphone is not; works on zoom and discord 10:04:22 — @jemarch.gnu.org: That patch needs reviewers!!! 10:04:28 — @jemarch.gnu.org: ^^^ 10:05:05 — @sarah.cook.embecosm.com: > <@patmcgeh.flash.net:lpc.events> odd... headset speakers are working fine but microphone is not; works on zoom and discord hmmmm this is odd. You are welcome to join one of the hackrooms to try and fix it ahead of your talk 10:05:59 — @patmcgeh.flash.net: I'll try hackroom 2 10:06:09 — @nix.esperi.org.uk: Patrick, check your source/sink configuration? I bet it's different for different apps (they remember what they used last, especially when you don't want them to) 10:09:05 — @richard.guenther.gmail.com: so gprofng compares to AMD uprof or Intel VTune? 10:09:20 — @patmcgeh.flash.net: Microphone working now. Internal config glitch. 10:09:21 — @richard.guenther.gmail.com: not so much to gprof 10:10:11 — @jeffreyalaw.gmail.com: yea, seems closer to perf, vtune, etc very different than old gprof 10:10:37 — @richard.guenther.gmail.com: gprof (or rather the instrumentation done by GCC) is also used for profile-feedback compilation 10:11:57 — @richard.guenther.gmail.com: I wonder why it wants to be part of binutils 10:13:58 — @rohit.athavale.info: Very similar to perf cli 10:25:37 — @anatol.belski.microsoft.com: Is it possible to use gprofng to profile binaries compiled by other languages (in particular Rust)? Otherwise, what would it take to have such a support? Thanks 10:31:34 — @nix.esperi.org.uk: It should just work I think. No source support for Rust yet though. 10:38:08 — @anatol.belski.microsoft.com: Yep, that would work for the basic case. For the source level, would there be some sort of plugin support possible, etc.? 10:38:43 — @nix.esperi.org.uk: No more than GDB does, I'm afraid. 10:39:06 — @nix.esperi.org.uk: (yet, anyway!) 10:39:08 — @jason237: Why would source support be language-dependent? I'd expect it to just use DWARF line number information. 10:39:31 — @jason237: (assuming rust uses dwarf) 10:39:40 — @anatol.belski.microsoft.com: There's rust-gdb actually, i'm just not sure how it connects through. 10:40:03 — @nix.esperi.org.uk: Oh true! I was thining expression parsing etc, but that isn't relevant here, is it? Not much change needed, then (if any). 10:40:24 — @plumbers.wildebeest.org: the gccrs frontend does and gdb is happy 10:40:42 — @anatol.belski.microsoft.com: AFAIK Rust does use DWARF, yep. 10:40:49 — @anatol.belski.microsoft.com: Great, thanks for clarifying! 10:53:47 — @codonell.redhat.com: waves 10:57:56 — @codonell.redhat.com: ... random number generation for double-double :-) 10:59:51 — @codonell.redhat.com: Thank you Patrick! 11:00:03 — @jwakely.redhat.com: Very interesting, thanks! 11:04:44 — @vladimir.mezentsev.oracle.com: > <@anatol.belski.microsoft.com:lpc.events> Is it possible to use gprofng to profile binaries compiled by other languages (in particular Rust)? Otherwise, what would it take to have such a support? Thanks gprofng supports binaries only in elf-format. If compiler generates elf, gprofng can profile it. gprofng reads Dwarf and Stabs. I never used Rust. Fortran is supported. 11:05:18 — @nix.esperi.org.uk: rust generates ELF (statically linked against all but libc by default) 11:05:44 — @nix.esperi.org.uk: A shame DJ isn't here... 11:07:25 — @codonell.redhat.com: Nick, DJ is on PST time, so he's only just getting up. We have discussed a lot of these values when looking at customer workloads we captured with the new high-speed malloc trace. 11:07:52 — @codonell.redhat.com: I agree that these 3 parameters yield a lot of change. 11:08:08 — @siddhesh.poyarekar.gmail.com: ... or just use GLIBC_TUNABLES=glibc.malloc.mmap_threshold , etc. Those underscores are evil. 11:08:26 — @codonell.redhat.com: Performance is one aspect, but memory used today has become a critical aspect of glibc's malloc. 11:10:11 — @codonell.redhat.com: This is where I feel we could switch to a % overhead and let malloc raise the trim. 11:10:30 — @codonell.redhat.com: We have a dynamic threshold if you don't set the threshold, but it isn't smart enough. 11:10:51 — @nix.esperi.org.uk: The hard part is getting the percentages remotely right without costing too much time figuring it out... 11:11:20 — @nix.esperi.org.uk: (since the time taken to do syscalls etc can vary wildly depending on system configuration, etc.) 11:12:01 — @siddhesh.poyarekar.gmail.com: The dynamic threshold just grows the new threshold to the size of the latest freed block. 11:12:06 — @siddhesh.poyarekar.gmail.com: never shrinks. 11:12:14 — @codonell.redhat.com: If given the API calls you consume X, then you should, IMO be able to say I want to only keep Y% more than X. 11:12:35 — @codonell.redhat.com: jemalloc has a distinct delta-t time decay thread which frees back. 11:12:39 — @nix.esperi.org.uk: maybe spend an ms or so figuring it out after the program has been running for a while and is demonstrably doing malloc/free in complicated patterns? 11:12:46 — @siddhesh.poyarekar.gmail.com: So if a benchmark allocates all the way up to 32M early enough and frees it, it's equivalent to setting mmap_threshold to 32M. 11:12:56 — @siddhesh.poyarekar.gmail.com: Which may explain near-identical performance. 11:13:24 — @codonell.redhat.com: Yeah, an early 32M allocation will raise the threshold. 11:14:13 — @codonell.redhat.com: Yes, jemalloc's algorithm has an aspect related to delta-t, and that gives you part of a PID control. 11:14:57 — @vladimir.mezentsev.oracle.com: > <@nix.esperi.org.uk:lpc.events> It should just work I think. No source support for Rust yet though. gprofng should show sources if Rust geberates "standart" Dwarf. 11:15:36 — @alehotsky.codegentllc.com: I came late to the session; can I download your slides? 11:16:14 — @codonell.redhat.com: Question for Patrick: Have you seen issues with producer consumer threaded workloads and does tuning help? 11:16:50 — @philip.herron.embecosm.com: I can hear you all 11:16:57 — @jbowen.infinitecactus.com: We can hear you 11:17:41 — @segher.kernel.crashing.org: > <@codonell.redhat.com:lpc.events> ... random number generation for double-double :-) random-random number-numbers 11:17:45 — @codonell.redhat.com: I think this is the mixed up BBB issues. 11:17:49 — @elena.zannoni.oracle.com: patric 11:17:57 — @jbowen.infinitecactus.com: It seems Patrick cannot hear us 11:18:02 — @elena.zannoni.oracle.com: patrick cannot hear 11:18:15 — @mulley.gaius.gmail.com: re: previous talk. Complex numbers are also used by ferrari's algorithm for quartic root calculation. Used in some game engines (collision prediction). 11:18:31 — stubbs.mentor.com: I can hear Carlos 11:19:19 — @elena.zannoni.oracle.com: carlos can you type please? 11:19:22 — @patmcgeh.flash.net: seem to have lost both input/output 11:19:27 — @codonell.redhat.com: Will type. 11:19:38 — @elena.zannoni.oracle.com: thanks, otherwise patrick cannot hear 11:19:59 — @codonell.redhat.com: Just commenting: Would be interesting to add a WAIT-FREE-QUEUE at the thread holding the arena lock, and a freer could drop a chunk in that queue. 11:20:14 — @codonell.redhat.com: To batch the free work and see if that has performance impact. 11:20:16 — @siddhesh.poyarekar.gmail.com: @Patrick, it would be interesting to see your findings with higher than 32M upper limit for dynamic thresholds. But I would like to see more results from cases where the dynamic threshold doesn't just get bumped up to maximum early on. 11:20:43 — @kgoebel.me.com: sometimes refreshing the conf window can reset audio 11:20:55 — @codonell.redhat.com: Let me resfresh too. 11:21:04 — @elena.zannoni.oracle.com: you can join a hackroom if you want to continue the malloc discussion 11:21:07 — @nix.esperi.org.uk: Carlos: presumably the existing malloc per-thread cache won't suffice> 11:21:11 — @elena.zannoni.oracle.com: or even ask for a bof 11:21:24 — @siddhesh.poyarekar.gmail.com: Another interesting experiment would be to see how common it is for the dynamic threshold to get bumped up to maximum very early, thus losing it's "dynamicness". 11:21:33 — @patmcgeh.flash.net: I have audio; seems my system has an internal issue with speaker/microphone identification 11:21:40 — @siddhesh.poyarekar.gmail.com: i.e. different workloads. 11:21:50 — @patmcgeh.flash.net: I see the chat discussion 11:21:54 — @codonell.redhat.com: Malloc telemetry :-) 11:21:55 — @alves.ped.gmail.com: let's all switch to Zoom :-D 11:22:01 — @codonell.redhat.com: Hey Pedro! 11:22:01 — @jemarch.gnu.org: noooo zoom nooo 11:22:09 — @alves.ped.gmail.com: Hey! 11:22:17 — @nix.esperi.org.uk: Patrick: pop up pavucontrol and look at the per-app source/sink mapping 11:22:19 — @elena.zannoni.oracle.com: patrick you can try disconnecting and reconnecting 11:22:23 — @codonell.redhat.com: Yeah, we need to get the high speed malloc tracer integrated into upstream proper as a preload. 11:22:23 — @dmalcolm.redhat.com: I see Patrick's icon is a headphone rather than a muted microphone; maybe he should disconnect and reconnect? 11:22:29 — @indu.bhagat.oracle.com: Patrick you are in "listen only" mode it seems 11:22:33 — @codonell.redhat.com: And integrate dynamic threshold data, and more fastbin info. 11:22:34 — @jeffreyalaw.gmail.com: carlos, pedro & friends..... hi everyone 11:22:40 — @codonell.redhat.com: Hi Jeff! :-) 11:22:52 — @patmcgeh.flash.net: yes; can't join in microphone mode after switching headsets 11:23:00 — @codonell.redhat.com: Ah. 11:23:03 — @patmcgeh.flash.net: I'm going to leave the conference and rejoin 11:23:08 — @jeffreyalaw.gmail.com: yea, found that out yesterday as well... 11:25:16 — @nix.esperi.org.uk: well, mostly the kernel doesn't migrate unless the application asks it to... 11:26:05 — @nix.esperi.org.uk: ahhhh makes sense! 11:27:03 — @ulrich.weigand.de.ibm.com: Patrick, you're still in listen-only mode 11:27:48 — @patmcgeh.flash.net: I have audio only; did not want to miss the discussion 11:27:48 — @codonell.redhat.com: Are you going to be working on improving malloc? :-) 11:28:15 — @patmcgeh.flash.net: My next scheduled task is to increase the MALLOC max 11:28:27 — @codonell.redhat.com: We should talk on libc-alpha. 11:28:34 — @codonell.redhat.com: And discuss places to improve that performance. 11:28:34 — @jemarch.gnu.org: PGA: profile guided allocation. Allocation profiles :) 11:28:39 — @patmcgeh.flash.net: yes; I'm on libc-alpha 11:28:51 — @siddhesh.poyarekar.gmail.com: @Patrick, we should probably even talk about removing MMAP_MAX if we can. 11:29:17 — @patmcgeh.flash.net: memcpy is tomorrow's talk 11:29:18 — @jemarch.gnu.org: Patrick is the best 11:29:24 — @codonell.redhat.com: Thank you Patrick! :-) 11:29:31 — @siddhesh.poyarekar.gmail.com: Thank you! 11:29:48 — @codonell.redhat.com: I can hear you. 11:29:50 — @codonell.redhat.com: I can see you. 11:29:58 — @siddhesh.poyarekar.gmail.com: I can hear you HJ 11:35:05 — @codonell.redhat.com: Down with COPY relocations! :-) 11:36:10 — @codonell.redhat.com: Is that exception because today we use the address of the PLT on x86? 11:39:37 — @elena.zannoni.oracle.com: @room there is a pop up menu in the bottom icon with the "telephone handset" to switch microphones and leave and join audio, can you see that? You can test during the break after HJ's talk 11:39:38 — @nix.esperi.org.uk: So,,, this makes accesses to undefined symbols (but not calls to undefined functions) from non-shared libs more expensive, while making self-refs to protected symbols in shared libs cheaper? Seems like you'd almost always want to do this. I guess distros that always compile from source will want to turn this on by default on their next recompile? 11:41:21 — @joseph.codesourcery.com: I'd guess it might work best with applications that are careful about marking their internal symbols hidden (so as much optimization as possible can happen at compile time rather than link time)? 11:41:35 — @jeffreyalaw.gmail.com: QT for example? 11:41:54 — @nix.esperi.org.uk: Most big C++ apps these days 11:42:16 — @jeffreyalaw.gmail.com: my recollection is that QT + copy relocs has been a huge headache 11:42:53 — @nix.esperi.org.uk: particularly if (like Python etc) they are turning off interposition etc anyway 11:43:22 — @jeffreyalaw.gmail.com: i think there's a general trend towards turning off interposition 11:43:23 — @patmcgeh.flash.net: > <@elena.zannoni.oracle.com:lpc.events> @room there is a pop up menu in the bottom icon with the "telephone handset" to switch microphones and leave and join audio, can you see that? You can test during the break after HJ's talk I've tried leave/join audio multiple times. 11:52:30 — @codonell.redhat.com: Common variable attribute? __attribute__((access_mode("indirect-external-access")) ??? 11:53:28 — @joseph.codesourcery.com: As I understand it, one general issue behind lots of these things is that ELF dynamic linking was originally defined to make things behave the same as static linking did, which resulted in various issues that now turn out to have performance impact. And so we now look at things to change that make it less like static linking (and may require special markup of exported/non-exported symbols, access modes, etc.) but should improve performance. 11:56:37 — @segher.kernel.crashing.org: > <@jeffreyalaw.gmail.com:lpc.events> i think there's a general trend towards turning off interposition it would be nice if that became the default... long transition period needed of course 11:58:39 — @jeffreyalaw.gmail.com: For FLorian's request, could we emit new reloc to get the behavior he wants? 11:58:53 — @nix.esperi.org.uk: There are a very few symbols we'd often like to keep interposable regardless, and if we do that everything else could probably lose interposition and actually fix problems due to symbol collisions etc :) basically if malloc and friends are still interposable, almost nobody would notice the change. maybe fopen etc too... 11:59:46 — @siddhesh.poyarekar.gmail.com: especially since we just got rid of malloc hooks and asked users to use malloc interposition instead. 12:05:01 — @jeffreyalaw.gmail.com: I think if go away interposable by default that we would have to have a mechanism to explicitly ask for some symbols to be interposable 12:07:28 — @fweimer.redhat.com: > <@nix.esperi.org.uk:lpc.events> There are a very few symbols we'd often like to keep interposable regardless, and if we do that everything else could probably lose interposition and actually fix problems due to symbol collisions etc :) basically if malloc and friends are still interposable, almost nobody would notice the change. maybe fopen etc too... `fopen` is already not interposable as far as glibc's internal use is concerned. But for all other `fopen` users, nothing changes. 12:08:52 — @codonell.redhat.com: Internal uses were never meant to be interposable in order to ensure the consistency of the implemented function. 12:08:58 — @codonell.redhat.com: How we use fopen internally is an implementation detail. 12:09:07 — @jemarch.gnu.org: Thanks Ulrich! 12:09:38 — @codonell.redhat.com: I think other applications are starting to want that option of not allowing interposition to hide their internal details. 12:09:50 — @siddhesh.poyarekar.gmail.com: yeah it's possible to do that for fopen because there's no real processwide state that needs to be managed like in case of malloc. 12:12:08 — @elena.zannoni.oracle.com: patrick can you try playing around with the telephone icon menu at the bottom to see if you can make yourself join the audio? 12:16:37 — @siddhesh.poyarekar.gmail.com: FWIW, I wasn't able to get the microphone working on firefox. It worked on chrome. 12:19:01 — @elena.zannoni.oracle.com: I tried in a hackroom, I joined w/o microphone, and the icon with the "headset" in the bottom lets you leave the audio, then you rejoin (also at the bottom) and you can select at that point to use the microphone. It worked fine. 12:19:57 — @plumbers.wildebeest.org: This is fun. Currecntly tsearch red/black trees use the lower bit in an (aligned) pointer to store the color bit. This requires masking and the internal pointers cannot be leaked out without masking off the low bit first. With this it could use the upper bits without any need of masking it seems. 12:21:01 — @nix.esperi.org.uk: any benchmarking of this? I guess the point is to reduce data-dependencies from the now-unnecessary masking? 12:21:26 — @plumbers.wildebeest.org: (tsearch in glibc) 12:22:40 — @nix.esperi.org.uk: I'm just remembering all the work that went into x86 hardware lock elision, followed shortly afterwards by Torvald posting benchmarks showing that lock elision slowed things down... don't want that to happen again, really. 12:22:52 — @alehotsky.codegentllc.com: I was imagining lisp tags 12:25:25 — @elver.google.com: Similar feature is already proven on arm64 (called TBI). One big usecase is HWASAN: https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html 12:26:09 — @siddhesh.poyarekar.gmail.com: luajit 12:26:24 — @plumbers.wildebeest.org: I don't follow, how does the loader know the program or some other library isn't using LAM already when dlopening a non-LAM enabled library. You cannot disable it then anymore can you? 12:26:44 — @nix.esperi.org.uk: Hm I guess AMD might get something similar then. Distinctly niche usecase without that. 12:27:11 — @nix.esperi.org.uk: (If it actually does boost performance. Benchmarks!) 12:28:11 — @elver.google.com: Nick: This has some data on HWASAN benefits: https://source.android.com/devices/tech/debug/hwasan Memory usage is another benefit. 12:29:10 — @nix.esperi.org.uk: Ah! Sounds like something valgrind could use too, for the uninitialized bit -- at least for pointers. hm. sounds tricky... 12:29:36 — @dvyukov.google.com: We want LAM a lot for HWASAN in user-space and kernel CONFIG_KASAN_SW_TAGS (effectively KASAN but with lower memory overhead). 12:29:36 — @nix.esperi.org.uk: Another horror to fix: libreoffice 12:29:39 — @plumbers.wildebeest.org: So how can a library, like glibc, use LAM, if it can be loaded by either LAM enabled and non-LAM enabled programs? 12:32:40 — @plumbers.wildebeest.org: > <@nix.esperi.org.uk:lpc.events> Ah! Sounds like something valgrind could use too, for the uninitialized bit -- at least for pointers. hm. sounds tricky... Valgrind would need to make sure it is the only component using LAM, if the use application also uses LAM itself, valgrind would have to check the LAM bits of the application (and cannot use them itself). 12:32:59 — @nix.esperi.org.uk: this would have helped the 68k back in the day too. A pointer-width marker seems like a thing that is useful even in the absence of LAM. 12:36:46 — @dvyukov.google.com: Are all patches for LAM are upstream already (gcc, glibc, qemu, kernel, etc)? Or something is in flight still? 12:39:11 — @codonell.redhat.com: I can hear you. 12:39:21 — @codonell.redhat.com: @Dmitry 12:39:32 — @codonell.redhat.com: I'd say we have RFCs for discussion. 12:40:26 — @dvyukov.google.com: @Carlos let's continue the discussion over email 12:41:23 — @jemarch.gnu.org: headphones 12:41:28 — @elena.zannoni.oracle.com: i do not hear any echo 12:41:40 — @elena.zannoni.oracle.com: ok 12:43:32 — @sarah.cook.embecosm.com: yes I know what you mean 13:09:44 — @tdevries.suse.de: so, is the alias analysis now done before the outlining? 13:20:19 — @sarah.cook.embecosm.com: yes 13:21:11 — @sarah.cook.embecosm.com: yes! 13:54:24 — @roger.nextmovesoftware.com: Richard: Is the endianness the same between the ARM host and the Nvidia GPU? Is this handled by the off-loading? 13:55:07 — @richard.guenther.gmail.com: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96265 14:01:11 — @jeremy.bennett.embecosm.com: Good night all 14:01:27 — @mulley.gaius.gmail.com: bye everyone 14:01:36 — @segher.kernel.crashing.org: bye 14:01:51 — @sarah.cook.embecosm.com: Thank you to all the speakers, to the you for joining us and a thank you to the sponsors of LPC. We look forward to seeing you tomorrow 14:02:25 — @elena.zannoni.oracle.com: thank you David 14:02:39 — @elena.zannoni.oracle.com: appreciate it 14:02:41 — @brobecke.adacore.com: Thanks David! 14:02:49 — @elena.zannoni.oracle.com: see you tomorrow! 14:02:52 — @jeffreyalaw.gmail.com: thanks to everyone who's worked to pull this together! 14:04:20 — @elena.zannoni.oracle.com: I'll close the room for the day, you will be kicked out ==== 22-09-2021 ==== 09:43:21 — @segher.kernel.crashing.org: Pong? 09:43:36 — @jemarch.gnu.org: Hey 09:43:55 — @joseph.codesourcery.com: Yes. 09:44:03 — @codonell.redhat.com: Thanks. 09:44:20 — @dje.gcc.gmail.com: Ping? 09:49:10 — @iain.sandoe.co.uk: good afternoon 10:01:42 — @simon.marchi.polymtl.ca: Good morning! 10:01:52 — @codonell.redhat.com: /me waves 10:02:18 — @codonell.redhat.com: Thank you Embecosm! :-) 10:02:49 — @jeremy.bennett.embecosm.com: > <@codonell.redhat.com:lpc.events> Thank you Embecosm! :-) :-) 10:03:13 — @codonell.redhat.com: Joseph Myers - glibc, gcc. 10:08:08 — @plumbers.wildebeest.org: Can we use that for the gcc rust frontend? They are currently stuck on github for that, which is really, really, really painful 10:11:45 — @joseph.codesourcery.com: And I have build-many-glibcs.py bots running after commit, but doing that as a trybot for all posted patches would need a *lot* of compute resources. 10:13:20 — @joseph.codesourcery.com: In practice, many of the cases where it shows breakage are where it wasn't at all obvious in advance that some configuration might break. 10:14:52 — @joseph.codesourcery.com: It's GDB that has problems with flaky tests. GCC doesn't have that so much, though I've sometimes seen random variation in test results. 10:15:26 — @alehotsky.codegentllc.com: You're using parallel make.. 10:16:03 — @plumbers.wildebeest.org: So for gccrs there is a bot that checks a --no-bootstrap build on just x86_64 (and just --enable-langagues=rust) on every approved commit. And then the bot commits to the main branch only when the build succeeds. 10:16:50 — @plumbers.wildebeest.org: That doesn't take that long. But doing a real bootstrap build and doing it for all arches... 10:17:17 — @ngompa13.gmail.com: Is there something like a Buildbot planned? 10:17:31 — @plumbers.wildebeest.org: It also helps that gccrs only has a couple of thousand tests. 10:17:51 — @ngompa13.gmail.com: it'd be nice for normies like me tracking stuff in GNU toolchain can see stuff happening all the time 10:18:17 — @plumbers.wildebeest.org: > <@ngompa13.gmail.com:lpc.events> Is there something like a Buildbot planned? I have one for gccrs (but it only does rust) https://builder.wildebeest.org/buildbot/#/builders?tags=gccrust 10:18:21 — @jakub.redhat.com: For patchworks and GCC, quite high priority is figure out what patches have been committed by a bit, which gets harder when patches slightly change before commit 10:18:57 — @plumbers.wildebeest.org: and yes, that buildbot is only after commit 10:19:02 — @ngompa13.gmail.com: sure, but post-merge checks are still useful, as well as having nightly runs across everything 10:19:16 — @joseph.codesourcery.com: There were post-commit glibc bots for a few architectures, but I think they bitrotted. And one had mysterious make errors. 10:19:18 — @ngompa13.gmail.com: because that tests how the environment influences the tree 10:19:23 — @siddhesh.poyarekar.gmail.com: Right now I'm the bot that runs the bot for glibc :) 10:19:30 — @jeffreyalaw.gmail.com: neal: there's also https://gcc.gnu.org/jenkins which is constantly doing testing of the tree 10:19:58 — @siddhesh.poyarekar.gmail.com: Jon for gcc, but gcc's success rate is lower because patches change before commit. 10:20:03 — @simon.marchi.polymtl.ca: Tom de Vries: I'm curious about what kind of setup you have for testing GDB, because you are catching regressions really quickly 10:20:07 — @ngompa13.gmail.com: > <@jakub.redhat.com:lpc.events> For patchworks and GCC, quite high priority is figure out what patches have been committed by a bit, which gets harder when patches slightly change before commit I see that surprisingly often with email-based workflows :( 10:20:19 — @ngompa13.gmail.com: it's frustrating and annoying 10:20:29 — @jemarch.gnu.org: Carlos: that email-driven interface, you got that working? Will it work with git-format-patch patch series? Will it be possible to specify target/conf/RUNTESTFLAGS? Will the results of the build be sent to the list as a reply to the request email? What do you need from each particular project to join the party? 10:20:42 — @joseph.codesourcery.com: One benefit of not committing ChangeLog changes in a commit is that what's committed can often be the same (same git-patch-id) as originally posted. 10:21:09 — @siddhesh.poyarekar.gmail.com: +1 10:21:37 — @tdevries.suse.de: > <@simon.marchi.polymtl.ca:lpc.events> Tom de Vries: I'm curious about what kind of setup you have for testing GDB, because you are catching regressions really quickly manual daily testing, unfortunately ;) 10:21:39 — @siddhesh.poyarekar.gmail.com: FWIW, changing the commit message is OK because patchwork only hashes the diff portion. 10:21:47 — @jeffreyalaw.gmail.com: and the git flow w/o ChangeLogs makes it a hell of a lot easier to cherry-pick across trees 10:22:13 — @jakub.redhat.com: The patch changes before commit are mostly when reviewer says your patch is ok for trunk with this and this nit fixed and they are so obvious that a repost and another review is unnecessary 10:22:28 — @iain.sandoe.co.uk: +1 (on the cherry - pick ) - we do have a history of "OK with the folowing nits fixed" 10:22:54 — @konstantin.linuxfoundation.org: on the kernel side, we also run a patchwork bot that can do things like automatically notify submitters that their patches were merged and automatically sets patch status as "accepted" when they show up in a monitored git tree. https://korg.docs.kernel.org/patchwork/pwbot.html 10:22:58 — @siddhesh.poyarekar.gmail.com: One thing I'm considering for the auto-closing bot is to post the [committed] patch to the list. 10:23:06 — @alves.ped.gmail.com: Does patchwork look at gerrit-like "Change-Id:" tags nowadays, to identify same-patch? 10:23:25 — @ngompa13.gmail.com: I firmly disagree. If I'm going through the pain of the email based workflow, my patches are what *I* want you to accept. 10:23:33 — @siddhesh.poyarekar.gmail.com: > <@alves.ped.gmail.com:lpc.events> Does patchwork look at gerrit-like "Change-Id:" tags nowadays, to identify same-patch? Unfortunately not, which is why older versions just stay there :( 10:23:54 — @ngompa13.gmail.com: I barely like appending the "Ack-by"/"Reviewed-by"/etc. to the patches before adding them 10:24:04 — @ngompa13.gmail.com: changing anything else is unacceptable 10:24:05 — @simon.marchi.polymtl.ca: > <@siddhesh.poyarekar.gmail.com:lpc.events> Unfortunately not, which is why older versions just stay there :( I had opened a question upstram to ask if they would be open to that, they would be 10:24:28 — @simon.marchi.polymtl.ca: https://github.com/getpatchwork/patchwork/issues/327 10:24:38 — @joseph.codesourcery.com: I'd guess there should be good heuristics for detecting "probably committed with changes" patches in patchwork (e.g. same subject and author, committed within a month), for quick manual review to confirm they were committed. 10:24:43 — @siddhesh.poyarekar.gmail.com: > <@simon.marchi.polymtl.ca:lpc.events> https://github.com/getpatchwork/patchwork/issues/327 That would be great! 10:25:35 — @plumbers.wildebeest.org: so how about only allowing the bot to commit to the main branch when it passes tests and is approved? Then what gets committed is always wat was approved? 10:25:40 — @ngompa13.gmail.com: Carlos O'Donell: The biggest issue I have with the email based workflow is how hard it is for me to track feedback 10:26:06 — @dmalcolm.redhat.com: It's traditional at this point to ask when GCC is going to transition to git :) 10:26:19 — @wschmidt.us.ibm.com: LOL 10:26:22 — @dje.gcc.gmail.com: Soon 10:26:27 — @fweimer.redhat.com: > <@plumbers.wildebeest.org:lpc.events> so how about only allowing the bot to commit to the main branch when it passes tests and is approved? Then what gets committed is always wat was approved? That's the Gerrit model. When done over email, authentication will be hard. 10:26:40 — @ngompa13.gmail.com: Soon™️ 😛 10:27:05 — @andre.almeida.collabora.com: how do you folks bisect gcc? I tried another day, but the build was broke in some commmits :( 10:27:47 — @joseph.codesourcery.com: Only-bot-can-push-to-master is also problematic with email workflows when a patch is too big to post to the list (e.g. large generated files - you can post all the rest of the patch, but what's posted then isn't exactly what's committed). 10:27:50 — @plumbers.wildebeest.org: > <@fweimer.redhat.com:lpc.events> > <@plumbers.wildebeest.org:lpc.events> so how about only allowing the bot to commit to the main branch when it passes tests and is approved? Then what gets committed is always wat was approved? That's the Gerrit model. When done over email, authentication will be hard. agreed. That is also basically the problem with the gccrs model. Only people with a github account can get their contributions tested/approved/committed 10:28:10 — @siddhesh.poyarekar.gmail.com: However, not everyone in glibc uses Reviewed-by since it's not really enforced in any way. 10:28:21 — @ngompa13.gmail.com: I honestly think this is one of the bigger reasons people prefer the PR model, because it's generally more tricky to sneakily intercept and modify changes and review feedback is consolidated in a way that is easily followed. 10:28:35 — @dje.gcc.gmail.com: > <@andre.almeida.collabora.com:lpc.events> how do you folks bisect gcc? I tried another day, but the build was broke in some commmits :( CI/CD will allow wider testing to prevent broken revisions. 10:28:36 — @ngompa13.gmail.com: * I honestly think this is one of the bigger reasons people prefer the PR model, because it's generally more tricky to sneakily intercept and modify changes and review feedback is consolidated in a way that is easily followed. 10:29:50 — @plumbers.wildebeest.org: But we could maybe install a sourcehut instance on sourceware, so everybody can easily have their own git branches and link their email patches to the actual tree/commit. 10:30:02 — @wschmidt.us.ibm.com: Do the Steering Committee / Stewards see directions where its desirable for the toolchain to improve, but we don't yet have sufficient focus? 10:31:05 — @dje.gcc.gmail.com: > <@wschmidt.us.ibm.com:lpc.events> Do the Steering Committee / Stewards see directions where its desirable for the toolchain to improve, but we don't yet have sufficient focus? Focus or resources? 10:31:07 — @wilson.tuliptree.org: the GNU project would like to see ObjC improvements for GNUstep 10:31:29 — @joseph.codesourcery.com: Variant: push the "OK" button but with an option "run the testsuite first in case the original submitter didn't do so". 10:31:52 — @philip.herron.embecosm.com: > <@plumbers.wildebeest.org:lpc.events> That's the Gerrit model. When done over email, authentication will be hard. > > agreed. That is also basically the problem with the gccrs model. Only people with a github account can get their contributions tested/approved/committed I agree with you Mark, Its annoying because the github tools have made it easier for people to get involved, it would be nice if there was an open source alternative that gave us similar level of integration, that allowed us to be closer to GCC processes 10:31:53 — @ngompa13.gmail.com: I would love to see a Pagure instance on sourceware for that kind of thing, and we could have email and PR workflows 10:31:59 — @plumbers.wildebeest.org: BTW. There are mirrors of the sourceware projects on sourcehut, which does make sending in patches really easy: https://sr.ht/projects/~sourceware/ 10:32:01 — @wschmidt.us.ibm.com: > > <@wschmidt.us.ibm.com:lpc.events> Do the Steering Committee / Stewards see directions where its desirable for the toolchain to improve, but we don't yet have sufficient focus? > > Focus or resources? Either. Where would we try to steer additional resources in an ideal world? 10:32:04 — @jeffreyalaw.gmail.com: Andre: the tree should always build with most targets, what problems did you run into 10:32:17 — @iain.sandoe.co.uk: Jim - are there specific PRs for these ? - if so please CC me on them 10:32:25 — @dje.gcc.gmail.com: > <@jeffreyalaw.gmail.com:lpc.events> Andre: the tree should always build with most targets, what problems did you run into There has been a lot of breakage recently. 10:32:35 — @alehotsky.codegentllc.com: I've used Gerrit at a client site as part of a gcc upgrade; it's good automation for tracking whether all the bots have run successfully, and required reviews have happened. It's annoying because I had to often nag the guys with the 'commit' privileges to push the button after all the reviews were done. 10:34:16 — @jeffreyalaw.gmail.com: would it make sense if anyone could push the button *if* there's a Reviewed-By tag from a global reviwer? 10:34:20 — @jeffreyalaw.gmail.com: Alan:^^ 10:34:29 — @andre.almeida.collabora.com: > <@jeffreyalaw.gmail.com:lpc.events> Andre: the tree should always build with most targets, what problems did you run into I was trying to build x86 with default options, bisecting from 10.3 -> 11.1 10:35:06 — @wilson.tuliptree.org: just a general request for ObjC v2 features, there is some commentary on the gnustep web site but I probably no gcc bug report 10:35:25 — @jeffreyalaw.gmail.com: I regularly have to bisect 10.2 to 11.2 and find it works very consistently, at least on x86. I don't have to do that on other targets 10:35:37 — @ngompa13.gmail.com: is GNUStep still alive? 10:35:45 — @jwakely.redhat.com: > <@andre.almeida.collabora.com:lpc.events> how do you folks bisect gcc? I tried another day, but the build was broke in some commmits :( Several terabytes worth of already built gcc binaries! Git bisect does allow you to skip revisions that are known to not build. It's a powerful tool, but takes a bit of practice to use really quickly and smoothly on a complex codebase like gcc 10:35:47 — @philip.herron.embecosm.com: I personally find github/bitbucket things make it easier to review code, since there is a way to approve things with a button and add reviewers with a conversation system. 10:36:01 — @iain.sandoe.co.uk: Jim Wilson: there's some work going on to allow NeXT v2 on a 32 bit host 10:36:18 — @wilson.tuliptree.org: I'm not sure if GNUstep is still interesting, but rms still cares about it 10:36:46 — @iain.sandoe.co.uk: I'd love to see some specific PRs - there is a lot to do to catch up with the "reference implementation" .. prioritising would help 10:37:00 — @ngompa13.gmail.com: > <@philip.herron.embecosm.com:lpc.events> I personally find github/bitbucket things make it easier to review code, since there is a way to approve things with a button and add reviewers with a conversation system. If there was a pagure system, that could be done, and still support people having their git trees elsewhere (since it supports remote PRs from arbitrary git servers). 10:37:03 — @codonell.redhat.com: https://sourceware.org/glibc/wiki/PatchworkReviewMeetings 10:38:06 — @brobecke.adacore.com: Even if not officially "qualified", I think your opinion is still going to be valuable. 10:38:15 — @dje.gcc.gmail.com: > <@wschmidt.us.ibm.com:lpc.events> > > <@wschmidt.us.ibm.com:lpc.events> Do the Steering Committee / Stewards see directions where its desirable for the toolchain to improve, but we don't yet have sufficient focus? > > Focus or resources? Either. Where would we try to steer additional resources in an ideal world? Without financial or developer resources, the leaders of the GNU Toolchain projects only can cajole and promote projects of interest. 10:39:05 — @ngompa13.gmail.com: I guess I don't particularly matter since I've never managed to get over the hurdle of directly contributing to the GNU toolchain :( 10:39:07 — @dje.gcc.gmail.com: Rust is a very important component with a lot of low-hanging fruit. 10:39:20 — @ngompa13.gmail.com: admittedly, the CAA was a problem, but that's not a thing anymore now, I think? 10:39:42 — @dje.gcc.gmail.com: Also, as we heard yesterday in the OpenMP/OpenACC talk, additional resources for Graphite and Polyhedral loop optimization would be useful. 10:40:27 — @plumbers.wildebeest.org: guix is really, really cool. IMHO. 10:40:27 — @ngompa13.gmail.com: I'm really looking forward to Rust being fully supported in GCC 10:40:44 — @jeffreyalaw.gmail.com: Presumably responding to Bill? Yes, I think starting to carve up the Graphiphe infrastructure would be a good place to invest 10:40:45 — @ngompa13.gmail.com: even though Rust is an ugly language 😛 10:40:58 — @plumbers.wildebeest.org: also fun to build gcc because guix doesn't have /usr/include which makes fixincludes unhappy :) 10:41:07 — @wilson.tuliptree.org: you probably have to talk to the GNUstep team, there is a little info here http://wiki.gnustep.org/index.php/Objective-C_Compiler_and_Runtime_FAQ 10:41:34 — @wilson.tuliptree.org: the GNU project is also interested in a Rust GCC front end, but there are people working on that 10:41:52 — @dje.gcc.gmail.com: Also, Andrew Pinski has done a great job to clean up GCC Bugzilla. A great opportunity for a new member of the GCC community would be Bugzilla triage, which was the standard on-boarding process for Cygnus back in the day. 10:42:13 — @ngompa13.gmail.com: speaking as someone who does GCC stuff in a bunch of smaller distros, `-O3` still scares me :) 10:43:26 — @joseph.codesourcery.com: We could probably do with more Bugzilla triage in glibc as well. There must be plenty of bugs that are duplicates, or fixed but not yet closed, or invalid, or very easy to fix. 10:43:45 — @dje.gcc.gmail.com: And we would welcome more blog posts and articles about GCC and the GNU Toolchain. User testimonials: How is the GNU Toolchain effective for end users in different business segments? 10:44:12 — @jeffreyalaw.gmail.com: Neal: is -O3 or -flto more scary to you? 10:44:57 — @plumbers.wildebeest.org: BTW. Also trying to just checkout gcc git is a little intimidating. Just doing a fresh clone you need to pull 1GB... Which is a barrier to entry. It would be good to have a smaller (shallow) newbie gcc.git repo. 10:45:24 — @dje.gcc.gmail.com: One can use git to only pull main/master and shallow 10:45:31 — @richard.guenther.gmail.com: can't you tell git to just fetch the "top"? 10:45:40 — @jeffreyalaw.gmail.com: yea, shallow clone 10:45:58 — @plumbers.wildebeest.org: yes, you can, but you have to remember/know that is necessary 10:46:00 — @jakub.redhat.com: --depth 1 10:46:01 — @dje.gcc.gmail.com: --single-branch --depth 1 10:46:18 — @richard.guenther.gmail.com: though even that's going to be a few hundred MS 10:46:21 — @richard.guenther.gmail.com: MB even 10:46:27 — @nix.esperi.org.uk: These days you can also tell it not to pull bigger blobs until needed(but this is still a bit embryonic) 10:46:34 — @siddhesh.poyarekar.gmail.com: > <@plumbers.wildebeest.org:lpc.events> BTW. Also trying to just checkout gcc git is a little intimidating. Just doing a fresh clone you need to pull 1GB... Which is a barrier to entry. It would be good to have a smaller (shallow) newbie gcc.git repo. The linux repo is 3.8GB. I don't think that's a barrier to entry :) 10:46:41 — @jeffreyalaw.gmail.com: i used to do it in the jenkins system since it originally pulled the repo every build 10:46:51 — @jason237: --depth implies --single-branch 10:47:13 — @joseph.codesourcery.com: Even excluding .git completely, the GCC sources are over 900MB. 10:47:32 — @plumbers.wildebeest.org: I think it is a (maybe small) barrier to entry. gcc for example is 10 times bigger than glibc or binutils-gdb. 10:47:42 — @iain.sandoe.co.uk: but on the plus side - it means someone else fixed a problem :) 10:48:36 — @plumbers.wildebeest.org: It might not be a giant issue, but I did notice recently when setting up a gcc setup on a new machine it really takes much much longer than any other project 10:48:42 — @joseph.codesourcery.com: We document the tricks for sharing .git history between multiple checkouts, but that's an advanced user thing, not so much for new contributors who probably only have one checkout. 10:49:02 — @siddhesh.poyarekar.gmail.com: > <@plumbers.wildebeest.org:lpc.events> I think it is a (maybe small) barrier to entry. gcc for example is 10 times bigger than glibc or binutils-gdb. What's probably more intimidating (with respect to size) is the breadth of features in the source base. Some projects deal with it by doing subprojects (e.g. clang, compiler-rt, etc.) but I'm personally not a great fan of it. 10:49:39 — @siddhesh.poyarekar.gmail.com: gdb was also among the first to adopt patchwork with glibc. 10:49:54 — @plumbers.wildebeest.org: Right, maybe we could have a default gcc.git that just contains the master branch from gcc5 and later. 10:50:12 — @fweimer.redhat.com: I think we were using Gerrit wrong, like not giving -1 for patches that needed changes. This defeated the built-in tracking in Gerrit. 10:50:30 — @jwakely.redhat.com: Mark 10:50:32 — @joseph.codesourcery.com: And LLVM also uses a git monorepo with almost all those subprojects in it. 10:50:35 — @jwakely.redhat.com: oops 10:50:57 — @plumbers.wildebeest.org: But yes, then knowing you really want to build --without-bootstrap --disabled-shared --enable-languages=please-not-everything is probably more of a deterrent :) 10:51:02 — @jwakely.redhat.com: Mark: anon gcc check outs are throttled, which makes it very slow. Much faster to clone form the unofficial mirror on github 10:51:34 — @jwakely.redhat.com: (unless you have a ssh key on sourceware and use it for the clone) 10:51:41 — @jeffreyalaw.gmail.com: Mark: yea, that's probably a much larger issue than the size of the repo 10:52:14 — @jwakely.redhat.com: we could add "small gcc tips" to the gcc.gnu.org/wiki/InstallingGCC page 10:52:27 — @jwakely.redhat.com: or one of the pages with beginner info 10:52:44 — @richard.guenther.gmail.com: I think it's already there 10:52:45 — @plumbers.wildebeest.org: https://git.sr.ht/~sourceware/gcc is also nice for anon checkouts (or your own fork on sourcehut). It does feel slightly faster than sourceware. 10:52:55 — @nix.esperi.org.uk: > <@jwakely.redhat.com:lpc.events> (unless you have a ssh key on sourceware and use it for the clone) Oh! I was asuming the additional computational load incurred by tunnelling over ssh made ssh cloning less desirable than anonymous, if the option was available. I had it backwards :) 10:53:00 — @mricon: One word of caution is that shallow clones are hard on the server side. 10:53:25 — @jwakely.redhat.com: yeah, it has to repack a new set of objects for each shallow clone 10:53:49 — @jeffreyalaw.gmail.com: oh, didn't know that about shallow, good to remember (I don't use it anymore) 10:53:53 — @mricon: and if the repo is large, that pack hangs in RAM while the client downloads it 10:54:19 — @mricon: so, a shallow clone of a 900MB repo means your git-daemon eats up 1GB for each clone :) 10:54:33 — @plumbers.wildebeest.org: urgh 10:54:36 — @jeffreyalaw.gmail.com: Nick A: Definitely better to use authenticated access... 10:54:40 — @mricon: throttling it speed-wise actually makes things worse 10:54:49 — @mricon: you want to send it out as fast as you can so you can free up the rAM 10:55:05 — @jeffreyalaw.gmail.com: Though we could look at the throttling. I don't know if we've reviewed when/how that kicks in for years 10:55:06 — @jwakely.redhat.com: the throttling for anon is to stop idiotic web crawlers DOSing the server 10:55:33 — @jwakely.redhat.com: I think it was reviewed when moving from svn to git, but fche would know for sure 10:55:53 — @siddhesh.poyarekar.gmail.com: I think Simon's point is that *patchwork* doesn't always read patches correctly. 10:55:56 — @mricon: (just sharing my experience managing git.kernel.org. :)) 10:56:06 — @jwakely.redhat.com: thanks! 10:56:08 — @jeffreyalaw.gmail.com: definitely helpful Konstantin.... 10:56:56 — @plumbers.wildebeest.org: For 5 minutes this might be too "big" a question, but how is the relationship of the steering committees with the FSF and how do the stering committees get new frsh members? 10:58:11 — @fweimer.redhat.com: Right, recovering state from email is somewhat questionable. 10:58:27 — @mricon: you can require base-commit: data for patch submissions 10:58:33 — @dje.gcc.gmail.com: > <@plumbers.wildebeest.org:lpc.events> For 5 minutes this might be too "big" a question, but how is the relationship of the steering committees with the FSF and how do the stering committees get new frsh members? This is a good question, but should have been asked earlier in the meting. 10:59:16 — @wschmidt.us.ibm.com: We can ask it during the glibc BoF since we did the glibc BoF during this slot. :-) 10:59:17 — @wilson.tuliptree.org: On the gcc side, I think I am on e of the few that still talks to rms, but I am trying to keep commnication open. 10:59:20 — @plumbers.wildebeest.org: sorry, should have asked earlier. 10:59:48 — @alves.ped.gmail.com: git has this "format.useAutoBase" setting, which when enabled, git format-patch/send-email includes the base commit your commit applies on top of. 10:59:57 — @mricon: > <@fweimer.redhat.com:lpc.events> Right, recovering state from email is somewhat questionable. it's not great, but it's possible if a diff is sent with git indexes 11:00:09 — @alves.ped.gmail.com: I've been using it for months, but I've not seen anyone else use it. 11:00:18 — @mricon: > <@alves.ped.gmail.com:lpc.events> git has this "format.useAutoBase" setting, which when enabled, git format-patch/send-email includes the base commit your commit applies on top of. yes, but this requires that the branch is checkout as tracking 11:00:24 — @ngompa13.gmail.com: > <@jeffreyalaw.gmail.com:lpc.events> Neal: is -O3 or -flto more scary to you? `-O3`, it causes successful builds leading to broken programs :D 11:00:37 — @mricon: I do heartily agree that useAutoBase is great 11:00:42 — @joseph.codesourcery.com: Patch review is a general problem for active projects in general, not at all limited to the GNU toolchain. 11:00:46 — @philip.herron.embecosm.com: Thanks to GCC community for being so kind about the gccrs effort hope you all have a great rest of conference :) 11:00:47 — @plumbers.wildebeest.org: I am happy with all the patch review, ci/cd, bots talk. 11:00:51 — @mricon: even easier for when there aren't 50 different trees to consider. :) 11:01:00 — @jeffreyalaw.gmail.com: Neal: Any option could do that. -O2 does get the most testing, which tends to make it more stable 11:01:09 — @joseph.codesourcery.com: Projects using pull request workflows can have huge numbers of open unreviewed PRs. 11:01:19 — @jemarch.gnu.org: Philip Herron: thanks to you for your nice work. Many people are exciting about the rust frontend 11:01:23 — @alves.ped.gmail.com: > <@mricon:chat.lfx.linuxfoundation.org> > <@alves.ped.gmail.com:lpc.events> git has this "format.useAutoBase" setting, which when enabled, git format-patch/send-email includes the base commit your commit applies on top of. yes, but this requires that the branch is checkout as tracking yeah, you'll do the occasional "git branch --set-upstream-to=upstream/master" to that the base hash is correct. 11:01:41 — @fweimer.redhat.com: > <@mricon:chat.lfx.linuxfoundation.org> yes, but this requires that the branch is checkout as tracking Why is that? `git format-patch` already knows the parent of the first generated patch? 11:02:07 — @alves.ped.gmail.com: leaving for another meeting. cheers! 11:02:13 — @sarah.cook.embecosm.com: You will need to screen share Maxim 11:03:38 — @mricon: > <@fweimer.redhat.com:lpc.events> Why is that? `git format-patch` already knows the parent of the first generated patch? I guess because you may want to format-patch against any number of other branches, so git needs to know against which branch you want the diffs 11:03:59 — @dmalcolm.redhat.com: Is Maxim muted? 11:04:34 — @dmalcolm.redhat.com: Looking and sounding good 11:04:39 — @tschwinge: F5 11:11:38 — @fweimer.redhat.com: Ahh, this ABI explains why Xcode switched the default to `-Werror=implicit-function-declarations`. 11:12:41 — @iain.sandoe.co.uk: I suspect it was accidental - LLVM makes it very easy to have different layouts for variadic and "regular" calls... 11:12:59 — @iain.sandoe.co.uk: but it's in the wild ... so 11:13:53 — @nix.esperi.org.uk: So there's always an executable, writable page present in this implementation? bit of a target for attackers 11:14:19 — @iain.sandoe.co.uk: no - it's not permitted to be writeable and executable at the same time 11:14:21 — @jakub.redhat.com: so will it leak trampolines on longjmp out of a function with those trampolines? 11:14:36 — @plumbers.wildebeest.org: darn, I had a warning for telling when a nested function needed a trampoline or not. But never finished it :{ 11:14:38 — @nix.esperi.org.uk: oh right, that wasn'tclear 11:15:17 — @iain.sandoe.co.uk: at present, yes it could leak trampolines if you long jump over the cleanups 11:16:21 — @jakub.redhat.com: For exceptions, it could be handled easily if it could be known at gimplification time that the cleanup will be needed 11:17:38 — @segher.kernel.crashing.org: maybe something with `attribute((cleanup))` can be done? 11:18:43 — @segher.kernel.crashing.org: it runs stuff whenever the frame goes away 11:18:57 — @iain.sandoe.co.uk: we're wrapping nested function pointers in a cleanup - so some of tis is available already 11:19:25 — @segher.kernel.crashing.org: ah cool 11:20:08 — @iain.sandoe.co.uk: the tricky bit is that if you have split stacks (e.g. calling in some funky way from go) .. you can't use the stack high water mark to know that someone has long-jumped past a cleaup 11:20:53 — @nix.esperi.org.uk: IIRC, go doesn't use split stacks any more;does anyone? 11:20:58 — @iain.sandoe.co.uk: (or perhaps a split signal stack) .. for a mono-stack, we believe you can apply a secondary test to cleanup based on the high-water mark, 11:21:32 — @segher.kernel.crashing.org: Nick Alcock: many existing systems still use it 11:21:42 — @nix.esperi.org.uk: but yeah sigaltstack and things like that are still a problem here 11:22:30 — @segher.kernel.crashing.org: have those things __ever__ worked together with nested functions? 11:22:41 — @segher.kernel.crashing.org: * have those things __ever__ worked together with nested functions? 11:24:44 — @iain.sandoe.co.uk: we're also a bit wary of fibres - which already have some of these properties (and have trouble even with TLS pointer-caching) 11:24:59 — @nix.esperi.org.uk: I do wonder what the effect of this is on the single-threaded workload case, since users are often going to be waiting for such things to finish. 11:25:34 — @fweimer.redhat.com: > <@segher.kernel.crashing.org:lpc.events> have those things __ever__ worked together with nested functions? The trampoline is valid as long as the static chain pointer is valid, so I don't see a particular problem with trampoline management here. 11:25:51 — @nix.esperi.org.uk: One thread under high load might well want to use all the shared cache, and using it would cost nothing if no other cores are active 11:26:17 — @joseph.codesourcery.com: This reminds me of past concerns about use of AVX-512 in string functions serving to reduce processor speed for other processes (because max speed was slower when AVX-512 was in use at all on the processor). 11:28:17 — @nix.esperi.org.uk: But if the single thread is the only live thread, using all the cache is *not* overuse! 11:29:26 — @nix.esperi.org.uk: So... non-cloud environments get penalized by this? I'm thinking desktops, chromebooks, etc. Users waiting for one thread to come back. 11:31:05 — @jeffreyalaw.gmail.com: THe shared L3 cache is the key feature and I don't think that's common on the desktops/laptops (yet) 11:31:20 — @jeffreyalaw.gmail.com: so one might argue the tuning should changed based on the cpuid 11:32:50 — @nix.esperi.org.uk: Not sure about that. Both my most recent desktops have shared L3 (one Intel, one AMD). Even the Chromebook I'm typing this on has one! CPUID tuning seems like a very good idea for autotuning this, since server/desktop parts are often distinguished that way. 11:33:04 — @ndesaulniers.google.com: I don't think LLVM has call used registers wiping on return 11:33:08 — @keescook.chromium.org: (clang doesn't have call-used registers yet) 11:33:14 — @keescook.chromium.org: but it will soon :) 11:33:25 — @ndesaulniers.google.com: yeah? let's see some patches :P 11:33:34 — @keescook.chromium.org: I await Bill's work :) 11:34:38 — @siddhesh.poyarekar.gmail.com: > <@jeffreyalaw.gmail.com:lpc.events> so one might argue the tuning should changed based on the cpuid It shouldn't be too hard to set the x86_non_temporal_threshold tunable based on cpuid. 11:37:31 — @glider.google.com: How does call registers wiping perform compared to control-flow integrity instrumentation provided by Clang? 11:37:39 — @ndesaulniers.google.com: Q: what if for my ROP gadget I need to write a NULL ptr into a pointer param? 0:-) I guess I should read that paper! 11:37:43 — @patmcgeh.flash.net: will still need to have a suitable default for cpuid's that are created after library was built (i.e. new mobile/desktop/server chips) 11:38:06 — @keescook.chromium.org: Nick: nothing's perfect. ;) 11:38:44 — @nix.esperi.org.uk: Another use for nonzero null pointer constants! 11:38:59 — @ndesaulniers.google.com: I wonder if aarch64 PAC helps? pointer wouldn't be signed? 11:39:01 — @keescook.chromium.org: > <@glider.google.com:lpc.events> How does call registers wiping perform compared to control-flow integrity instrumentation provided by Clang? ROP tends to get used for backward-edge. Clang CFI is covers forward-edge. 11:39:09 — @glider.google.com: > <@ndesaulniers.google.com:lpc.events> Q: what if for my ROP gadget I need to write a NULL ptr into a pointer param? 0:-) I guess I should read that paper! guess it's still highly unlikely that none of your gadgets rely on registers :) 11:39:32 — @patmcgeh.flash.net: with register clearing, the ptr will always be null with or without an attacker 11:39:57 — @keescook.chromium.org: > <@ndesaulniers.google.com:lpc.events> I wonder if aarch64 PAC helps? pointer wouldn't be signed? SCS and PAC help against backward edge, yes. 11:40:02 — @ndesaulniers.google.com: cool, there's the answer to my Q 11:42:03 — @ndesaulniers.google.com: skip is nice to have; there will be places (hopefully very few) in the kernel where we may need to turn this off. 11:43:00 — @glider.google.com: I'd rather have this opt-out as a function attribute probably. 11:43:11 — @nix.esperi.org.uk: in glibc too -- probably mostly the same places that need to inhibit the stack-protector canary. 11:43:47 — @keescook.chromium.org: Here's the kernel commit, BTW: https://git.kernel.org/linus/a82adfd5c7cb4b8bb37ef439aed954f9972bb618 11:44:17 — @lf-wiki-id.bigeasy.linutronix.de: thank you, I was about to ask :) 11:44:17 — @ndesaulniers.google.com: Kees were there parent patches that used skip anywhere? 11:45:59 — @keescook.chromium.org: > <@ndesaulniers.google.com:lpc.events> Kees were there parent patches that used skip anywhere? Nope; currently a big hammer. :) 11:46:48 — @ndesaulniers.google.com: but it boots? 11:47:01 — @keescook.chromium.org: yeah, totally 11:47:07 — @ndesaulniers.google.com: ship it! 11:47:14 — @keescook.chromium.org: virtually no performance change. 11:47:35 — @keescook.chromium.org: see above commit for details on perf/image-size changes 11:49:23 — @ndesaulniers.google.com: -Wsometimes-uninitialized and -Wmaybe-uninitialized, too? 11:49:44 — @glider.google.com: To be precise, AddressSanitizer does not detect uses of uninitialized memory, only MemorySanitizer does. 11:50:01 — @diane2332.gmail.com: gcc doesn't support -fsanitize=memory, unfortunately 11:50:30 — @glider.google.com: > <@diane2332.gmail.com:lpc.events> gcc doesn't support -fsanitize=memory, unfortunately also true 11:50:57 — @richard.guenther.gmail.com: we need a NaT on memory cells ;) 11:52:40 — @richard.guenther.gmail.com: The Microsoft compiler is the same as clang, no? 11:53:07 — @keescook.chromium.org: > <@richard.guenther.gmail.com:lpc.events> we need a NaT on memory cells ;) I would love this. :) Each "ret" could auto-invalidate the stack frame, etc. 11:53:08 — @ndesaulniers.google.com: You're thinking of ICX (nee ICC). 11:53:19 — @nix.esperi.org.uk: hmm, is this in glibc yet... no; I feel a patch coming on 11:54:11 — @richard.guenther.gmail.com: Itanic had NaT on registers, so there's precendent! (for yet another Intel opportunity to mess up ;)) 11:54:20 — @keescook.chromium.org: > <@nix.esperi.org.uk:lpc.events> hmm, is this in glibc yet... no; I feel a patch coming on Yeah, -ftrivial-auto-var-init=zero needs to be part of -Wall. ;) 11:54:30 — @ndesaulniers.google.com: Does clang have the uninitialized attr? 11:54:38 — @keescook.chromium.org: Yup 11:54:42 — @glider.google.com: > <@ndesaulniers.google.com:lpc.events> Does clang have the uninitialized attr? Yes. 11:55:17 — @fweimer.redhat.com: With `__attribute__ ((uninitialized))`, can we start warning on variable auto-assignment now (`int x = x;`)? 11:55:26 — @diane2332.gmail.com: Maybe there should be a new flag for security, like -fsecurity=... so that lots of useful things can be enabled all at once. And I think maybe it should be on by default. 11:56:00 — @keescook.chromium.org: > <@fweimer.redhat.com:lpc.events> With `__attribute__ ((uninitialized))`, can we start warning on variable auto-assignment now (`int x = x;`)? The kernel removed all auto-assignments. 11:56:39 — @nix.esperi.org.uk: > <@diane2332.gmail.com:lpc.events> Maybe there should be a new flag for security, like -fsecurity=... so that lots of useful things can be enabled all at once. And I think maybe it should be on by default. They do have compatibility implications; glibc likely needs changes before the call-used clearing can go in, for instance. 11:56:43 — @keescook.chromium.org: > <@diane2332.gmail.com:lpc.events> Maybe there should be a new flag for security, like -fsecurity=... so that lots of useful things can be enabled all at once. And I think maybe it should be on by default. Ubuntu's gcc does this by default (but yes, I'd love an upstream way to do this.) 11:56:46 — @jeremy.bennett.embecosm.com: > <@diane2332.gmail.com:lpc.events> Maybe there should be a new flag for security, like -fsecurity=... so that lots of useful things can be enabled all at once. And I think maybe it should be on by default. Nice idea, but I fear that it would end up breaking a lot of existing code bases. Things like this generally need to be off by default for a long time. 11:56:57 — @glider.google.com: Question: Clang performs locals initialization in the frontend. How is this done in GCC? Also, do you have any performance data for GCC-implemented auto-initialization? 11:57:15 — @keescook.chromium.org: > <@nix.esperi.org.uk:lpc.events> > <@diane2332.gmail.com:lpc.events> Maybe there should be a new flag for security, like -fsecurity=... so that lots of useful things can be enabled all at once. And I think maybe it should be on by default. They do have compatibility implications; glibc likely needs changes before the call-used clearing can go in, for instance. Why? What caller is depending on a call-used register? 11:57:45 — @jeremy.bennett.embecosm.com: Question: Does the register erasure work across longjump? Or C++ throwing exceptions. 11:57:56 — @diane2332.gmail.com: 11:58:02 — @diane2332.gmail.com: Easy enough to turn off. 11:58:42 — @keescook.chromium.org: > <@jeremy.bennett.embecosm.com:lpc.events> > <@diane2332.gmail.com:lpc.events> Maybe there should be a new flag for security, like -fsecurity=... so that lots of useful things can be enabled all at once. And I think maybe it should be on by default. Nice idea, but I fear that it would end up breaking a lot of existing code bases. Things like this generally need to be off by default for a long time. Gentoo paved the path here, but Ubuntu made most security features enabled by default. As a result, the entire Debian software base has been fixed for those kinds of problems about ten years ago. :) 11:59:29 — @nix.esperi.org.uk: There was at least one place in the x86 mutex implementation depending on a register not being clobbered across a function call; the register happened to be %rax, so I spotted it in the stack-protector-all work, but if it was true of that register, it might be true of others... 11:59:51 — @ndesaulniers.google.com: Changing the implicit compiler defaults makes for hard to reproduce bug reports. Do we not have a warning for self assignment? https://godbolt.org/z/PYTohPn76 11:59:52 — @keescook.chromium.org: > <@nix.esperi.org.uk:lpc.events> There was at least one place in the x86 mutex implementation depending on a register not being clobbered across a function call; the register happened to be %rax, so I spotted it in the stack-protector-all work, but if it was true of that register, it might be true of others... Eek :) 12:00:17 — @jeremy.bennett.embecosm.com: > <@keescook.chromium.org:lpc.events> Nice idea, but I fear that it would end up breaking a lot of existing code bases. Things like this generally need to be off by default for a long time. > > Gentoo paved the path here, but Ubuntu made most security features enabled by default. As a result, the entire Debian software base has been fixed for those kinds of problems about ten years ago. :) Well there would be nothing to stop Linux distros setting alternative flags for the compiler they ship. 12:00:51 — @nix.esperi.org.uk: Obviously all such places are bugs, but it's easy to introduce them in asm by mistake over time 12:00:53 — @diane2332.gmail.com: If the code fails with these features, it is buggy. 12:01:04 — @glider.google.com: Thanks Jose! 12:01:20 — @diane2332.gmail.com: All code should be run through the Sanitizers before release. 12:01:48 — @ndesaulniers.google.com: there's definitely places in the kernel where __attribute__((always_inline)) is _needed_ for runtime correctness; places that generally violate the calling conventions (inline assembly shenanigans) 12:02:26 — @nix.esperi.org.uk: glibc too, sigreturn is evil 12:04:52 — @jeremy.bennett.embecosm.com: Thanks Qing Zhao 12:04:56 — @nix.esperi.org.uk: setjmp could erase registers itself, I think with no compiler support needed. setcontext probably should too. 12:05:20 — @nix.esperi.org.uk: uh I mean longjmp of course! 12:05:37 — @jeremy.bennett.embecosm.com: > <@nix.esperi.org.uk:lpc.events> setjmp could erase registers itself, I think with no compiler support needed. setcontext probably should too. That's a good solution. It's a harder problem for the stack erasure 12:06:16 — @jeremy.bennett.embecosm.com: The issue might be setjmp knowing whether or not this was a function with a register erasure attribute 12:06:24 — @msebor.redhat.com: > <@ndesaulniers.google.com:lpc.events> Changing the implicit compiler defaults makes for hard to reproduce bug reports. Do we not have a warning for self assignment? https://godbolt.org/z/PYTohPn76 -Winit-self 12:07:05 — @nix.esperi.org.uk: > <@jeremy.bennett.embecosm.com:lpc.events> The issue might be setjmp knowing whether or not this was a function with a register erasure attribute Just do it unconditionally. longjmp is not performance-sensitive. 12:07:39 — @jeremy.bennett.embecosm.com: But that changes the semantics - albeit in an undocumented way. I guess that doesn't really matter 12:08:05 — @ndesaulniers.google.com: Thanks for the talk! 12:08:07 — @corbet.lwn.net: Nice talk, thanks 12:08:14 — @jeremy.bennett.embecosm.com: Thanks for the talk 12:08:29 — @keescook.chromium.org: Thank you for the talk! (And the work on the features!) 12:08:31 — @jemarch.gnu.org: And thanks David for the moderation 12:08:39 — @nix.esperi.org.uk: Yeah... I suppose people dangerously depending on non-volatile variable valus get even more broken than they are already! 12:13:16 — @dje.gcc.gmail.com: Thanks Jose for summarizing the questions for Qing 12:18:14 — @fweimer.redhat.com: Wish we had this at the start for ppc64le, so that we could have defaulted to `-fsigned-char`. 12:20:49 — @fweimer.redhat.com: glibc will also need `double double` indefinitely. 12:21:12 — @qing.zhao69.gmail.com: > <@keescook.chromium.org:lpc.events> > <@glider.google.com:lpc.events> How does call registers wiping perform compared to control-flow integrity instrumentation provided by Clang? ROP tends to get used for backward-edge. Clang CFI is covers forward-edge. Thank you Kees for the answer 12:21:59 — @jwakely.redhat.com: libstdc++ is likely to have to keep supporting all three of 64-bit long double, double double and ieee128, for compat. /me cries 12:22:10 — @wschmidt.us.ibm.com: sorry Jon :( 12:23:32 — @codonell.redhat.com: /me waves 12:23:37 — @codonell.redhat.com: Sorry, had to be in another meeting. 12:23:42 — @qing.zhao69.gmail.com: > <@glider.google.com:lpc.events> To be precise, AddressSanitizer does not detect uses of uninitialized memory, only MemorySanitizer does. Thanks for this info 12:25:55 — @qing.zhao69.gmail.com: > <@diane2332.gmail.com:lpc.events> Maybe there should be a new flag for security, like -fsecurity=... so that lots of useful things can be enabled all at once. And I think maybe it should be on by default. Nice idea 12:27:23 — @iain.sandoe.co.uk: nods 12:28:33 — @qing.zhao69.gmail.com: > <@glider.google.com:lpc.events> Question: Clang performs locals initialization in the frontend. How is this done in GCC? Also, do you have any performance data for GCC-implemented auto-initialization? Clang does the -Wuninitialized analysis in FE. But gcc does it quite late in middle end, that makes gcc implementation more complicated 12:29:22 — @jwakely.redhat.com: Should std::random_device use the power DARN instruction (ISA 3.0) to get a random number? We support using RDRAND and RDSEED on x86 12:29:39 — @jwakely.redhat.com: I thought I'd filed a BZ reminding me to do this, but I can't find it. 12:30:43 — @mrmeissn.us.ibm.com: Note, you do have to deal with DARN failing. 12:31:28 — @joseph.codesourcery.com: Any plans to add _Float16 support (to the psABIs and the GCC back end), such as was recently added for x86_64 and has been present for AArch64 for a long time? Power has conversion instructions between binary16 and wider floating-point formats (thought not yet direct arithmetic on binary16, I think). 12:31:38 — @iain.sandoe.co.uk: I have to drop off now - thanks to all for talks and discussions. 12:34:22 — @wschmidt.us.ibm.com: Thanks, Iain! 12:38:06 — @ngompa13.gmail.com: I'd be curious if these POWER changes would make it so we don't get weird things with the defaults for ppc64le with boolean 12:38:17 — @ngompa13.gmail.com: e.g. altivec bool by default screws with lots of applications 12:39:53 — @joseph.codesourcery.com: _Float16 is always IEEE binary16 format. 12:40:16 — @joseph.codesourcery.com: (C and C++ rejected "short float".) 12:40:26 — @jwakely.redhat.com: OK, thanks 12:40:56 — @jwakely.redhat.com: Ah, I seem to recall I asked about it before and "it actually works correctly" wasn't the case. If it works now, I'll make it (optionally) usable 12:42:31 — @joseph.codesourcery.com: (glibc doesn't have any _Float16 support on any architecture at present.) 12:43:28 — @pdrocaldeira.gmail.com: Hey ppl, about AI libraries, do you guys have an idea how better MMA performs for AI, for example, any benchmark result for OpenBLAS? Another one, is MMA available for Tensorflow already? 12:44:48 — @rforraji.gmail.com: connecting back.. 12:46:41 — @pdrocaldeira.gmail.com: Oh thank you :D 12:47:31 — @ngompa13.gmail.com: Bill Schmidt: I am not opting into AltiVec most of the time 12:47:36 — @ngompa13.gmail.com: and it still happens, causing breakage 12:48:27 — @ngompa13.gmail.com: Will do, 👍️ 12:49:11 — @jwakely.redhat.com: ok, cool. I'll take a look at it next week 12:50:36 — @sawdey.us.ibm.com: gcc will figure out that the result is just being compared to zero 12:52:41 — @christophm30.gmail.com: You were mentioning a "single-line-patch" in the backend, that pushed the SPEC performance by more than 2%. Can you explain more details and/or give some pointers to this amazing patch? 12:52:44 — @ngompa13.gmail.com: looking forward to the day Raptor will offer POWER10 systems... 12:52:56 — @ngompa13.gmail.com: actually, in general, it'd be nice to see more affordable POWER systems... 12:53:14 — @ngompa13.gmail.com: right now, it's _too_ expensive to get a POWER system :( 12:53:33 — @ngompa13.gmail.com: even cloud availability is too limited (just IBM cloud :( ) 12:54:52 — @ngompa13.gmail.com: having POWER in AWS, for example, would be really nice 13:01:48 — @elena.zannoni.oracle.com: yes 13:01:48 — @ngompa13.gmail.com: Yes! 13:05:08 — @jwakely.redhat.com: there's an open libstdc++ bug I need to look at, where the wrong symbol from the DSO seems to be getting used 13:05:49 — @nix.esperi.org.uk: Yeah. Just a while back I saw an advert for a POWER desktop -- and then saw the prices started at something like £10k, and, just no. 13:05:56 — @jwakely.redhat.com: but it's not a glibc bug, it's something in my court 13:06:09 — @tuliom.quites.com.br: Jonathan Wakely: is that bug reported anywhere? I'd like to track it. 13:06:32 — @jwakely.redhat.com: Tulio, it's in GCC BZ, lemme find it for you ... 13:06:44 — @jwakely.redhat.com: Carlos right, that's why I thought I'd mention it 13:06:54 — @mscastanho.gmail.com: Is that 100912? 13:07:19 — @tuliom.quites.com.br: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 13:08:34 — @lazyparser.gmail.com: lazyparser has handed over this account to MaskRay :) Will glibc be happy with Clang buildability? The most important patch is to removal C nested functions https://sourceware.org/bugzilla/show_bug.cgi?id=27220 (the patch has been up for several weeks now) 13:09:36 — @jwakely.redhat.com: yes, 100912 13:11:48 — @jeffreyalaw.gmail.com: We've run into situations where invoking a program via ld.so results in a different memory layout (particularly the relationship between the .bss and heap) is changed and as a result we end up unexpectedly changing malloc arenas due sbrk failure. Has anyone else stumbled over this and does it really matter, or this kind of use really only important for the testsuite? 13:11:58 — @joseph.codesourcery.com: Could we do Bugzilla triage better, especially making sure bugs that have been fixed are closed? This seems like a similar backlog issue to patch review. 13:13:36 — @joseph.codesourcery.com: Regarding clang buildability: each separate logical change should be sent separately (and in particular, fixes for installed headers, which should work with a wide range of compiler versions, should be separate). 13:14:26 — @joseph.codesourcery.com: Regarding the specific dynamic linker patch, certainly passing explicit parameters would feel better than using static variables, even given the comment in the latest patch revision explaining why there is no thread-safety issue. 13:14:55 — @lazyparser.gmail.com: Both musl ldso and FreeBSD rtld have cleaner relocation resolving code. I do hope this part of glibc can be cleaned up whenever it makes sense:) 13:16:10 — @joseph.codesourcery.com: I think there might also be a use for being able to run much of the glibc testsuite with compilers that can't build glibc. For example: I'd still like to be able to run the tgmath.h changes with GCC 6 once we no longer support GCC 6 for building glibc, since it uses different macro definitions depending on the compiler version. 13:18:34 — @ngompa13.gmail.com: the only architecture Fedora doesn't have in common use is ppc64be 13:18:55 — @lazyparser.gmail.com: > Regarding the specific dynamic linker patch, certainly passing explicit parameters would feel better than using static variables 13:19:07 — @ngompa13.gmail.com: there's a group trying to bring glibc back to irix+mips :P 13:19:30 — @lazyparser.gmail.com: The issue is that RESOLVE_MAP and the other macro don't share parameter list ;-) 13:24:05 — @joseph.codesourcery.com: I didn't get a reply to my recent message to overseers about glibc commits not getting filed properly. 13:26:08 — @joseph.codesourcery.com: For glibc, we rely on marking bugs fixed as soon as fixed on master, for the automatic generation of the list of fixed bugs for NEWS (which only looks at FIXED bugs with the relevant milestone). 13:27:39 — @joseph.codesourcery.com: (We also rely on people actually remembering to set the milestone at that time, but it's an easy search to find bugs marked FIXED since the last release but without milestone set, and thus to fix the milestone before the release - provided someone remembers to do that search.) 13:30:32 — @joseph.codesourcery.com: We look for "bug ", and if it's "(bug" or "[bug" or similar, it won't match, apart from any issue about whether the first line of the commit gets checked properly. 13:32:15 — @nix.esperi.org.uk: [^[:alnum:]_-]bug would seem a good thing to match on... 13:39:46 — @lazyparser.gmail.com: Can b4 be used for glibc patches posted on libc-alpha? 13:39:46 — @joseph.codesourcery.com: In principle, From: mangling isn't needed on mailing lists for DKIM/DMARC issues *if* the lists don't change anything about the message that would break DKIM signatures. 13:39:48 — @plumbers.wildebeest.org: I am here 13:40:52 — @plumbers.wildebeest.org: But not change anything also means not dropping CCs for people who don 13:40:58 — @plumbers.wildebeest.org: t want dupicates 13:41:34 — @plumbers.wildebeest.org: stripping HTML attachements... 13:42:24 — @plumbers.wildebeest.org: not change reply-to headers 13:42:32 — @nix.esperi.org.uk: You can add headers, but not change anything, IIRC 13:42:46 — @nix.esperi.org.uk: changing reply-to breaks DKIM: can't do it 13:45:32 — @plumbers.wildebeest.org: O. One nice thing of sourcehut is that it can sent clean patches (with correct extra From: header). 13:45:34 — @plumbers.wildebeest.org: https://git.sr.ht/~sourceware/glibc/ 13:46:03 — @plumbers.wildebeest.org: It might be something to recommend to people who might have trouble sending "clean" patches. 13:46:39 — @tuliom.quites.com.br: https://public-inbox.org/libc-alpha/ 13:46:42 — @fweimer.redhat.com: http://public-inbox.org/libc-alpha/ 13:47:13 — @jemarch.gnu.org: wtf why I didnt know about that o_O 13:47:34 — @nix.esperi.org.uk: it is wonderful! I suck all my mailing lists into it 13:51:14 — @sarah.cook.embecosm.com: Thank you everyone! 13:51:14 — @codonell.redhat.com: Thank you! 13:51:39 — @dje.gcc.gmail.com: How do we add GCC and GCC Patches to public inbox? 13:52:05 — @simon.marchi.polymtl.ca: And GDB! 13:52:10 — @jemarch.gnu.org: Yeah I was reading readme.html for poke! 14:00:44 — @elena.zannoni.oracle.com: i am closing the room. I have saved the notes. See you tomorrow! 16:48:50 — @segher.kernel.crashing.org: > <@dje.gcc.gmail.com:lpc.events> How do we add GCC and GCC Patches to public inbox? And importantly, add the decades of archive, too? ==== 23-09-2021 ==== 09:37:57 — @elena.zannoni.oracle.com: Morning. I saved the notes from yesterday and added them to the website in the timetable 09:38:18 — @sarah.cook.embecosm.com: Morning. Thank you Elena 09:38:30 — @elena.zannoni.oracle.com: the chats are archived, and we are taking a snapshot of each matrix room every night, we'll make those available at the end 09:41:03 — @codonell.redhat.com: Good morning. 09:41:55 — @sarah.cook.embecosm.com: Morning Carlos :) 09:43:03 — @jeremy.bennett.embecosm.com: Good morning all 09:50:19 — @codonell.redhat.com: Audio is good. I can hear Florian. 09:50:22 — @elena.zannoni.oracle.com: can you make the slides downloadable too? 09:50:36 — @jeremy.bennett.embecosm.com: Just discovered how weird it is to have both BBB and the YouTube live stream on at the same time! 09:51:08 — @elena.zannoni.oracle.com: @jeremy i am in 2 MCs at the same time too. I have to mute one tab otherwise the audio mixes, kind of weird :-) 09:51:14 — @nix.esperi.org.uk: > <@segher.kernel.crashing.org:lpc.events> > <@dje.gcc.gmail.com:lpc.events> How do we add GCC and GCC Patches to public inbox? And importantly, add the decades of archive, too? A typical starting point for public-inbox is to take an mbox archive and suck the lot in, and then switch it to pulling in the maildir-format feed as it comes in. So yes, public-inbox is biult for exactly this :) 09:51:18 — @codonell.redhat.com: The LPC slide upload != Presentation upload. 09:51:23 — @codonell.redhat.com: Just upload them right now. 09:51:35 — @codonell.redhat.com: As presenter you click + and then add slide material and add it. 09:57:16 — @plumbers.wildebeest.org: Sorry, I should just push all the buttons 09:57:32 — @plumbers.wildebeest.org: NOT. NOT push all the buttons... 10:01:57 — @codonell.redhat.com: DOWN WITH IMPLICIT FUNCTION DECLS! 10:02:03 — @codonell.redhat.com: /me holds pitch fork 10:03:05 — @jwakely.redhat.com: and my axe 10:03:58 — @nix.esperi.org.uk: Of course the implicit promotion hell stays with us even then thanks to stdargs. Anyone got any idea how to give *those* proper types :/ 10:04:10 — @jwakely.redhat.com: C++ 10:04:12 — @jwakely.redhat.com: :-P 10:04:25 — @nix.esperi.org.uk: :)) 10:04:31 — @jemarch.gnu.org: nope nope 10:06:48 — @codonell.redhat.com: /me cries 10:07:11 — @richard.guenther.gmail.com: It also miscompiled X11 for us once 10:07:45 — @jemarch.gnu.org: Segher: drop your question to the chat. I will be collecting them in the shared notes for the later discussion 10:10:36 — @nix.esperi.org.uk: ... then you have to get fixes this small past reviewers who really aren't likely to care enough to review it. That means that only major contributors can likely submit things like this in advance of the switch-over. 10:11:09 — @richard.guenther.gmail.com: binary-compare results! 10:11:48 — @joseph.codesourcery.com: Yes, using reproducible builds and comparing binaries (e.g. for the large subset of Debian that builds reproducibly) comes to mind to me. 10:12:12 — @nix.esperi.org.uk: binary comparison only works for those implicit decsl that affect this build in particular. The implicit decl check thing Florian mentioned avoids that :) 10:12:31 — @richard.guenther.gmail.com: well, it avoids feature disabling by broken configure checks 10:12:50 — @codonell.redhat.com: /me laughs at "gloomy November days" :-) 10:12:52 — @richard.guenther.gmail.com: for the particular configuration, yes 10:13:20 — @richard.guenther.gmail.com: in the end this isn't much different from switching to -fno-common ... 10:13:39 — @nix.esperi.org.uk: The magic error log thing should also go upstream, so that the fixes can be done in a distributed fashion after release 10:14:02 — @nix.esperi.org.uk: (yes, it's ugly, but either it should be upstreamed or everyone has to reimplement it!) 10:14:31 — @richard.guenther.gmail.com: we already have -fdiagnostic-output=xyz, just overload that somehow 10:15:06 — @joseph.codesourcery.com: Does the magic error log have complications to avoid problems (a) when the function indeed does not exist so the error is right and (b) when the configure test is actually looking for which header declares the function? 10:16:19 — @joseph.codesourcery.com: We switched to -std=gnu11 by default (meaning warning for this by default) in GCC 5. 10:16:24 — @richard.guenther.gmail.com: disable the new behavior for input files named conftest.c ;) 10:16:53 — @pjones.redhat.com: That's (yet another) argument for tossing autoconf 10:17:29 — @nix.esperi.org.uk: Not practical unless you have a way to convince everyone to not use all the huge amount of software that is still using it! Live with the world as it is etc 10:18:13 — @pjones.redhat.com: looking at it from the other direction, though: tossing it as a maintainer 10:18:14 — @nix.esperi.org.uk: (and if these projects are too dead to fix implicit int, what's the likelihood they'll be willing to totally redo their build systems?) 10:18:27 — @jemarch.gnu.org: Why would be toss autoconf?? It is awesome 10:18:49 — @jwakely.redhat.com: toss the old defunct junk in the distros instead 10:19:09 — @jemarch.gnu.org: that ^ 10:19:16 — @nix.esperi.org.uk: I'm using too much of it to want to do that :) 10:19:29 — @jwakely.redhat.com: ok, send all patches to nick ;) 10:19:34 — @joseph.codesourcery.com: Common distribution infrastructure for shared fixes to dead upstreams? 10:19:34 — @richard.guenther.gmail.com: btw, in SUSE we had been using some -Wunprototped-calls warning by default for years 10:20:13 — @nix.esperi.org.uk: > <@joseph.codesourcery.com:lpc.events> Common distribution infrastructure for shared fixes to dead upstreams? We could call it a place for cronically dead but critical projects 10:20:40 — @richard.guenther.gmail.com: Joseph: we tend to treat Debian as that (because it tends to package everything) 10:22:08 — @alehotsky.codegentllc.com: What about writing the implicit linkage into the obj file and having the linker complain when the actual function's prototype doesn't match? 10:24:39 — @jwakely.redhat.com: Invalidate them then 10:25:09 — @simon.marchi.polymtl.ca: IME, -Wmissing-declarations always helps 10:25:50 — @joseph.codesourcery.com: Incidental note: C23 will probably make bool, true and false into keywords, which I expect will cause a lot of distribution breakage - but that should be noisy breakage, not quiet breakage like you get with implicit function declaration errors. 10:25:58 — @jemarch.gnu.org: haha 10:26:29 — @dwmw2: Much as I hate autoconf, I have so far failed to find an alternative that I hate even less :) 10:28:00 — @richard.guenther.gmail.com: https://gcc.gnu.org/legacy-ml/gcc-patches/2013-04/msg00363.html 10:29:25 — @codonell.redhat.com: Red Hat has an open job position for an Autotools maintainer :-) 10:31:24 — @sarah.cook.embecosm.com: Jose your on mute 10:32:37 — @segher.kernel.crashing.org: David Woodhouse (LPC): i have never heard about any actual alternative, even 10:34:10 — @dwmw2: Oh, there's a new crop every year but they don't make anything any *better*; they just add new ways for things to break (and require even newer tools, and stop building on older distros). 10:34:28 — @dwmw2: So I still wear the t-shirt, but I still use autohate., 10:34:31 — @dwmw2: autoconf.jpeg 10:36:18 — @codonell.redhat.com: "I HATE AUTOCONF LESS THAN I HATE [Bazel, Meson, Ninja, Scons, Cons, Bitbake, Maven, Jenkins, Webpack, Buck, Gradle...]" 10:36:30 — @richard.guenther.gmail.com: The SUSE packages are built from the gcc-11 branch, not OG11 10:36:45 — @jemarch.gnu.org: Carlos: now nobody will want to apply, knowing what her first task will be :P 10:36:46 — @segher.kernel.crashing.org: > <@nix.esperi.org.uk:lpc.events> And importantly, add the decades of archive, too? > > A typical starting point for public-inbox is to take an mbox archive and suck the lot in, and then switch it to pulling in the maildir-format feed as it comes in. So yes, public-inbox is biult for exactly this :) i know, but my point is we should *do* that :-) it is much easier to set up things only for new stuff 10:37:20 — @philip.herron.embecosm.com: I always remember thinking when I was first using linux the ./configure output looks really cool 10:38:11 — stubbs.mentor.com: 10:38:23 — @segher.kernel.crashing.org: and it is! and the whole **point** of autoxxxx is it works **everywhere** 10:38:33 — stubbs.mentor.com: > <@richard.guenther.gmail.com:lpc.events> The SUSE packages are built from the gcc-11 branch, not OG11 That's what I said. 10:38:55 — @nix.esperi.org.uk: > <@philip.herron.embecosm.com:lpc.events> I always remember thinking when I was first using linux the ./configure output looks really cool These days, everytime it says "no" to something I twitch and think "is this true, or is it FPing at an unrelated wearning message?". Occasionally I even check. 10:40:05 — @jwakely.redhat.com: tui mode is great 10:42:44 — @bergner.linux.ibm.com: tui mode, I just learned something new! How long as that been there? 10:42:56 — @simon.marchi.polymtl.ca: For ever :) 10:43:03 — @bergner.linux.ibm.com: heh 10:43:06 — @jwakely.redhat.com: gdb --tui ... 10:43:08 — @simon.marchi.polymtl.ca: But it has received a lot of improvements in the last few years 10:43:21 — @richard.guenther.gmail.com: others just use emacs 10:43:27 — stubbs.mentor.com: It had an amazing overhaul a few years ago, but it's been there a long time. 10:43:42 — @simon.marchi.polymtl.ca: So, important question: how come "error" and "success" are coloured? 10:43:47 — stubbs.mentor.com: I usually use Vim 8 debug support these days though 10:44:16 — @jwakely.redhat.com: Yeah I switched to https://www.dannyadam.com/blog/2019/05/debugging-in-vim/ instead of tui for many uses 10:44:26 — @jemarch.gnu.org: Simon: aren't they supposed to be styled? 10:44:38 — @bergner.linux.ibm.com: vim user here, so I'll have to look into that too. Thanks! 10:44:52 — @simon.marchi.polymtl.ca: I don't know, because they are comments? 10:44:59 — @alves.ped.gmail.com: > <@simon.marchi.polymtl.ca:lpc.events> So, important question: how come "error" and "success" are coloured? That explains why this isn't live! This is all CGI. ;-) 10:45:08 — @jemarch.gnu.org: well they are not C keywords neither 10:45:17 — @simon.marchi.polymtl.ca: > <@alves.ped.gmail.com:lpc.events> That explains why this isn't live! This is all CGI. ;-) You can tell by the pixels 10:45:27 — @jwakely.redhat.com: ha 10:45:41 — @simon.marchi.polymtl.ca: I'm wondering whether he put escape sequences in his comments ;) 10:46:09 — stubbs.mentor.com: I don't actually know where the colour comes from 10:46:15 — @jemarch.gnu.org: what is the meaning of the map(var) openmp pragma? 10:46:26 — @richard.guenther.gmail.com: it's youtube auto-coloring video by AI 10:46:52 — stubbs.mentor.com: map(var) means copy the variable from the host to the device and then back again 10:47:00 — @jemarch.gnu.org: ok thanks 10:49:04 — @jemarch.gnu.org: this is very cool 10:49:28 — @jwakely.redhat.com: impressive magic 10:51:59 — @vladimir.mezentsev.oracle.com: Can gdb attach to the multi-thread application ? 10:52:23 — stubbs.mentor.com: Hmmm, I've never tried. 10:53:02 — stubbs.mentor.com: I would have thought so? 10:53:04 — @jemarch.gnu.org: hm is the ring sound part of the video? 10:53:09 — stubbs.mentor.com: Tony Tye:? 10:53:26 — stubbs.mentor.com: > <@jemarch.gnu.org:lpc.events> hm is the ring sound part of the video? Sadly yes 10:53:28 — @simon.marchi.polymtl.ca: Multi-threaded as in pthread? 10:53:37 — @jemarch.gnu.org: Ok I thought I was finally going nuts 10:54:12 — stubbs.mentor.com: > <@simon.marchi.polymtl.ca:lpc.events> Multi-threaded as in pthread? Multi-thread as in GPU processors. 10:55:03 — @vladimir.mezentsev.oracle.com: On Linux, dbx (Oracle studio) can attach but only in one thread. 10:55:20 — @simon.marchi.polymtl.ca: I don't know if it's possible today, but I am pretty sure we want it to work 10:55:22 — @vladimir.mezentsev.oracle.com: yes it is pthread 10:55:35 — @simon.marchi.polymtl.ca: For pthreads, sure it works 10:55:43 — @tony.tye.amd.com: ROCgdb has the same abilities as gdb. So it supports multiple threads in a single process as well as multiple inferiors. However, the implementation for some hardware limits how many pocesses can use the same GPU at a time. 10:56:41 — @simon.marchi.polymtl.ca: I don't know what time y'all at, but "We have to kill it from another terminal" when a GPU thread is stuck waiting forever. That sounds like the problem Pedro Alves 's ctrl-c work fixes 10:57:08 — @alves.ped.gmail.com: attaching to amdgpu-using programs works -- though for some architectures after attaching you may miss dispatch/work-group info. 10:57:10 — stubbs.mentor.com: Could be. 10:58:06 — @vladimir.mezentsev.oracle.com: We used dbx to attach and start to profile application. Now gprofng cannot do it. 10:59:33 — @alves.ped.gmail.com: > <@simon.marchi.polymtl.ca:lpc.events> I don't know what time y'all at, but "We have to kill it from another terminal" when a GPU thread is stuck waiting forever. That sounds like the problem Pedro Alves 's ctrl-c work fixes yes, you're stuck forever if no host thread is running as happens with scheduler-locking on. (because ctrl-c release on ptrace intercepting the SIGINT that is sent to the host). no host-side running, no ctrl-c, must kill gdb. 10:59:47 — @alves.ped.gmail.com: another great reason for getting my ctrl-c patches in! 11:00:08 — @simon.marchi.polymtl.ca: I thought that was the original reason 11:01:03 — @alves.ped.gmail.com: the orignal reason was programs that use sigwait/sigprocmask / block SIGINT in normal unix programs. 11:02:29 — @blarsen.redhat.com: oooh Lords of Iron is a banger! 11:02:36 — @tschwinge: Great demo! ... and I learned something new -- didn't know GDB 'display' command! :-O 11:02:50 — @jemarch.gnu.org: Thomas: dude :D 11:03:04 — @simon.marchi.polymtl.ca: Pedro Alves: Well, the original AMD motivation :) 11:04:01 — @tschwinge: Jose E. Marchesi: I promise I'll be using it very often from now on! 11:05:09 — @honza.hubicka.gmail.com: Hello, I have bit of problem for next track, since power is out here. I will try to login using data and start with talk and hope to be saved by power coming back during talk (which will mean I will disconnect for a while) :) 11:06:05 — @jemarch.gnu.org: > <@honza.hubicka.gmail.com:lpc.events> Hello, I have bit of problem for next track, since power is out here. I will try to login using data and start with talk and hope to be saved by power coming back during talk (which will mean I will disconnect for a while) :) copy 11:06:40 — @jemarch.gnu.org: > <@tschwinge:fosdem.org> Jose E. Marchesi: I promise I'll be using it very often from now on! Just wait for the poke command.. gotta send a V2 for that 11:07:12 — @honza.hubicka.gmail.com: As speaker I only join the next track and should be able speak, right? (Sorry, normally I would read the presentation info but was bit occupied with the power problem) 11:07:45 — @jemarch.gnu.org: Yes. Just join the GNU Tools Track in https://meet.lpc.events/ 11:07:57 — @honza.hubicka.gmail.com: thanks! 11:08:16 — @jemarch.gnu.org: Did you send your slides to sarah in advance? 11:08:38 — @sarah.cook.embecosm.com: > <@jemarch.gnu.org:lpc.events> Did you send your slides to sarah in advance? They should already be uploaded 11:09:01 — @jemarch.gnu.org: ok then we can transition quickly to save honza's data :) 11:14:19 — @honza.hubicka.gmail.com: OK, thanks :) 11:15:11 — @tony.tye.amd.com: Thanks Andrew. Cool seeing OpenMP GPU debugging in action:-) 11:17:25 — @ruud.vanderpas.gmail.com: I totally agree :-) 11:44:31 — @visda.vokhshoori.gmail.com: this type of alias disambiguation is useful for the tree inliner as well. any plans to do this w.o. LTO. do you have numbers on code size? 11:46:44 — @sarah.cook.embecosm.com: yes 11:47:07 — @elena.zannoni.oracle.com: Is Jan video frozen? 11:47:14 — @elena.zannoni.oracle.com: ah ok delay 12:00:24 — @sarah.cook.embecosm.com: The Screen Share has ended 12:00:35 — @jemarch.gnu.org: urg 12:01:12 — @jemarch.gnu.org: how did that happen? 12:01:30 — @sarah.cook.embecosm.com: A moderator must have given someone else presenter rights 12:01:39 — @jeremy.bennett.embecosm.com: Bug in BBB? 12:01:54 — @jeremy.bennett.embecosm.com: It was the person just before Enrico in the list 12:02:44 — @jemarch.gnu.org: Question: do you plan to extend the GDB risc-v simulator as well, or you plan to contribute this GVSoC simulator as a separated sim/ ? 12:04:16 — @wilson.tuliptree.org: The gdb risc-v sim still needs ~20 patches upstreamed from riscv-gnu-toolchain. 12:09:22 — @jeremy.bennett.embecosm.com: There's also the CGEN simulator... 12:09:51 — @wilson.tuliptree.org: The cgen simulator only supports a small subset of possible architectures. It isn't useful unless you can fix that. 12:09:54 — @jemarch.gnu.org: yes, about that 12:11:42 — @philipp.tomsich.vrull.eu: Is the cgen project alive? I had the impression that I had been dormant since 2010… 12:11:52 — @philipp.tomsich.vrull.eu: s/I/it/g 12:12:13 — @jeremy.bennett.embecosm.com: See the talks at GNU Cauldrons passim. Very much still alive! 12:12:43 — @jemarch.gnu.org: Yeah, some idiot got global CGEN maintainership lately 12:12:57 — @jemarch.gnu.org: Philipp: we use CGEN in the BPF port 12:13:08 — @jeremy.bennett.embecosm.com: Very much appreciated that idiot! 12:13:28 — @jeremy.bennett.embecosm.com: We use CGEN widely for our RISC-V customers. 12:14:11 — @philipp.tomsich.vrull.eu: > <@jemarch.gnu.org:lpc.events> Yeah, some idiot got global CGEN maintainership lately You seem to volunteer for some of the most thankless tasks ;-) 12:14:49 — @palmer.dabbelt.com: presumably we'd need to fix our sim port first ;) 12:22:11 — @wilson.tuliptree.org: I have a patch set for the simulator, but needs a lot of changes for reviewer comments. 12:23:04 — @jemarch.gnu.org: Jim: if you need help with that, maybe you could link to the patch submission thread? Maybe someone is willing to take it from there :) 12:23:19 — @palmer.dabbelt.com: if you've gotten somewhere then you're more than welcome to send it out and ask one of us to pick up the slack 12:28:24 — @wilson.tuliptree.org: This is a long thread. https://sourceware.org/pipermail/gdb-patches/2021-April/177847.html 12:30:30 — @geert.linux-m68k.org: I see no poll? 12:30:44 — @geert.linux-m68k.org: (same in the previous session I attended) 12:30:49 — @philipp.tomsich.vrull.eu: I was about to ask the same question… 12:32:00 — @jemarch.gnu.org: seems like the poll doesnt survive a change of presenter 12:32:05 — @jemarch.gnu.org: 8-) 12:38:36 — @wilson.tuliptree.org: there are a number of interesting comments from Jessica Clarke in IRC about the vendor specific linker relaxation proposal for CORE-V 12:39:07 — @joseph.codesourcery.com: I'm not convinced it's the point of the vendor field in target triplets (that's more a relic of m68k--sysv), but certainly plenty of targets have -m options for vendor extensions. 12:40:46 — @philipp.tomsich.vrull.eu: This is why they'll have to call it x-thead-v 12:42:27 — @alves.ped.gmail.com: it's useful to be able to install multiple versions of the toolchain one masking others. e.g., x86-64-akme-gcc and x86-64-msft-gcc both on the PATH. otherwise, should be cosmetic, IMHO. 12:42:47 — @alves.ped.gmail.com: * WITHOUT one masking... 12:43:28 — @jemarch.gnu.org: That works well enough for many arches, like sparc 12:44:31 — @wilson.tuliptree.org: irc log, see jrtc27 comments https://libera.irclog.whitequark.org/riscv/2021-09-23 12:47:47 — @joseph.codesourcery.com: With these extensions in master (which I think is a good idea), at some point you'll need to deal with obsolescing/removing support for extensions that's no longer maintained and causing maintenance problems (cf. the removal of e500 support from the GCC powerpc port, for example). 12:48:34 — @philipp.tomsich.vrull.eu: Can we first move from the guthub integration branches to vendor branches in the GCC git? 12:52:10 — @philipp.tomsich.vrull.eu: I'd change this from SOON to NOW: Zb[abcs] doesn't have bits assigned. 12:52:42 — @palmer.dabbelt.com: agreed: the letter thing is broken and has been for a while, we just haven't had anything concrete to trigger that breakage 12:53:00 — @jeremy.bennett.embecosm.com: That will be good. We spend a lot of time with customers who don't understand that the Git repos are not a simple mirror of the official upstream. 12:53:27 — @philipp.tomsich.vrull.eu: > <@palmer.dabbelt.com:lpc.events> agreed: the letter thing is broken and has been for a while, we just haven't had anything concrete to trigger that breakage Just pointing out that this is not a future problem, but there's an immediate need to resolve this ideally in the current cycle. 12:53:33 — @palmer.dabbelt.com: yep 13:01:24 — @joseph.codesourcery.com: Getting 64k state in every process because of detecting vector support sounds like the issue with Intel AMX. https://sourceware.org/pipermail/libc-alpha/2021-June/127933.html 13:02:13 — @philipp.tomsich.vrull.eu: They should have called it MAX (instead of AMX), as it MAXimizes the process state. 13:03:25 — @jamie.shareable.org: After Glibc has used the vector unit in memcpy(), is there not a fast way to say "no longer care about preserving vector state from here" so that context switch doesn't have to save it? 13:04:43 — @jemarch.gnu.org: you are gonna need a lot of bits :D 13:07:25 — @sarah.cook.embecosm.com: you have 8 minutes left 13:08:17 — @jemarch.gnu.org: So what simulator should make it to GDB :) 13:09:07 — @pdp7pdp7.gmail.com: oh, did the RISC-V BoF just start? 13:09:26 — @palmer.dabbelt.com: it's just ending ;) 13:09:32 — @pdp7pdp7.gmail.com: ah! :) 13:15:05 — @jeremy.bennett.embecosm.com: Thanks Kito, Palmer and Jim 13:16:31 — @jemarch.gnu.org: Just to clarify: I wasn't suggesting to switch to a CGEN-based assembler. If you have good hand-written opcodes, so much the better :) 13:21:29 — @palmer.dabbelt.com: OK, I guess I generally like tools and we used to have something (though it was sort of half-way there and had a lot of hand finishing) 13:22:15 — @palmer.dabbelt.com: it's kind of a headache to have so many descriptions of the ISA floating around in one project, I think there's some merit to that "make CGEN generate tables that match our current assembler tables" approach 13:22:31 — @palmer.dabbelt.com: that would at least let us have a single source of truth for the new extensions going in 13:24:46 — @jemarch.gnu.org: Yes thats my feeling too 13:25:07 — @palmer.dabbelt.com: OK, cool 13:25:21 — @palmer.dabbelt.com: maybe it's worth prototyping that with one of these new extensions? 13:25:57 — @palmer.dabbelt.com: IMO it should be straight-forward to generate tables that look like what we have now, but I haven't looked at CGEN 13:26:05 — @palmer.dabbelt.com: it's not like we're really doing anything interesting, though 13:26:14 — @jemarch.gnu.org: where is embecosm' cpu description anyway? It is not in upstream cpu/ 13:28:45 — @wilson.tuliptree.org: there was a patch posted to gdb-patches early this year or maybe late last year, I'll have to hunt for it 13:38:30 — @chip.kerchner.ibm.com: This may be a silly question but for some of these issues has anyone considered using an AI for register pressure, etc.? 13:45:02 — @wilson.tuliptree.org: > <@jemarch.gnu.org:lpc.events> where is embecosm' cpu description anyway? It is not in upstream cpu/ https://sourceware.org/pipermail/gdb-patches/2019-September/160285.html 13:45:44 — @wilson.tuliptree.org: They have a newer verison obviously. 13:45:48 — @jemarch.gnu.org: > <@wilson.tuliptree.org:lpc.events> https://sourceware.org/pipermail/gdb-patches/2019-September/160285.html Nice, thanks 14:00:52 — @jemarch.gnu.org: Everyone: remember tomorrow there is the Toolchains & Kernel microconference. This year we have a lot of discussion on binary-postprocessing (objtool in the kernel, BOLT, ...) much of which could be moved up to the toolchain 14:01:58 — @richard.guenther.gmail.com: David, maybe you can post the shared notes on gcc@ so we can followup there 14:02:39 — @richard.guenther.gmail.com: Btw, thanks all for the great content this year! 14:02:46 — @jeffreyalaw.gmail.com: +1 14:02:48 — @elena.zannoni.oracle.com: the shared notes will be on the linuxplumbers website, you can get them from there 14:02:51 — @elena.zannoni.oracle.com: as well 14:02:52 — @sarah.cook.embecosm.com: Thank you everyone!! Hope to see you in person next year 14:03:04 — @elena.zannoni.oracle.com: thank you all 14:03:09 — @jakub.redhat.com: Thanks 14:03:11 — @richard.guenther.gmail.com: fingers crossing... 14:05:14 — @elena.zannoni.oracle.com: oh, the room was closed too early 14:05:24 — @elena.zannoni.oracle.com: We will fetch the notes and the chat 14:05:30 — @elena.zannoni.oracle.com: from the servres