Re: [RFC][GCC][rs6000] Remaining work for inline expansion of strncmp/strcmp/memcmp for powerpc
* Aaron Sawdey: > If you are aware of any real world code that is faster when built > with -fno-builtin-strcmp and/or -fno-builtin-strncmp, please let me know > so I can look at avoiding those situations. Sorry, I have not tried to benchmark this. One more question: There's a hardware erratum on POWER9 DD2.1 related to VSX load instructions causing memory corruption when accessing cache-inhibited memory. It may not be very likely that strncmp is used on such memory, but memcpy and memmove definitely need to take that into account, and perhaps memset and memcmp as well. In the past, I did not receive positive feedback for my suggestion that we should have a separate family of string functions for device memory. (This is a general problem that is not specific to POWER.) So we still have the problem that at least some of the string functions in glibc need to be compatible with device memory. My concern here is that the GCC inline expansion could essentially disable the workaround we have in glibc memcpy and memmove for the hardware erratum. Thanks, Florian
Re: [RFC][GCC][rs6000] Remaining work for inline expansion of strncmp/strcmp/memcmp for powerpc
On 12/3/18 8:34 AM, Florian Weimer wrote:
> * Aaron Sawdey:
>
>> If you are aware of any real world code that is faster when built
>> with -fno-builtin-strcmp and/or -fno-builtin-strncmp, please let me know
>> so I can look at avoiding those situations.
> Sorry, I have not tried to benchmark this.
>
> One more question: There's a hardware erratum on POWER9 DD2.1 related to
> VSX load instructions causing memory corruption when accessing
> cache-inhibited memory. It may not be very likely that strncmp is used
> on such memory, but memcpy and memmove definitely need to take that into
> account, and perhaps memset and memcmp as well.
>
> In the past, I did not receive positive feedback for my suggestion that
> we should have a separate family of string functions for device memory.
> (This is a general problem that is not specific to POWER.) So we still
> have the problem that at least some of the string functions in glibc
> need to be compatible with device memory.
>
> My concern here is that the GCC inline expansion could essentially
> disable the workaround we have in glibc memcpy and memmove for the
> hardware erratum.
I don't think we have a real concern here. DD2.1 is used in a particular
situation where GCC 4.8.5 is the supported compiler, and not used elsewhere.
So I'd prefer not to cripple the compiler for this specific use case. If
the customer with DD2.1 hardware chooses to use GCC 8 or later, and runs
into this problem, they can use -mno-builtin-mem{set,cmp} as a workaround.
Do you feel that's satisfactory?
We can also have a private discussion if you feel that's warranted.
Thanks,
Bill
>
> Thanks,
> Florian
>
Re: [PATCH] Add missing noexpect causes in tuple for move functions
Sent offlist. On Sun, 2 Dec 2018 at 20:06, nick wrote: > > > > On 2018-12-02 11:53 a.m., David Edelsohn wrote: > > On Sat, Dec 1, 2018 at 11:46 PM nick wrote: > >> > >> On 2018-12-01 10:32 a.m., Jonathan Wakely wrote: > >>> On Fri, 30 Nov 2018 at 20:54, Nicholas Krause wrote: > > This adds the remainging noexcept causes required for this cause > to meet the spec as dicussed last year and documented here: > http://cplusplus.github.io/LWG/lwg-active.html#2899. > >>> > >>> This isn't "the spec", it's a proposed (but incorrect) resolution to a > >>> defect in the standard. What it proposes may not fix the defect, but I > >>> think it's an improvement to the std::tuple API anyway, and so I want > >>> libstdc++ to implement it. "The spec" is the C++ standard, but it > >>> explicitly allows implementations to add stronger > >>> exception-specifications where a function is known not to throw. > >>> > >>> Thanks for the patch. Something this small could be accepted without a > >>> copyright assignment, but as it seems like you're interested in > >>> contributing more (which is great!) you should be aware of the legal > >>> prerequisites for larger contributions (which also applies to several > >>> small contributions, even if each one is trivial). See > >>> https://gcc.gnu.org/contribute.html for details, and let me know if > >>> you have any questions about that. > >>> > >> > >> Jonathan, > >> > >> My only question remains is for copyright is it per patch or just one time. > >> > >> My other question is related to the noexcept parts and that either I or > >> you should move and CC the other involed list i.e. the llibstdc++ list. > > > > You can submit one copyright assignment per patch ... if you're a masochist. > > > > The recommended approach is a single "Futures" copyright assignment > > for all current and future patches. > > > > Thanks, David > > > > It mentions on the page to just ask about copyright forms, so I am asking here > for them before I just send them to the assign email address given. > > Nick
Re: [PATCH] Add missing noexpect causes in tuple for move functions
On Sun, 2 Dec 2018 at 04:45, nick wrote: > My other question is related to the noexcept parts and that either I or > you should move and CC the other involed list i.e. the llibstdc++ list. Oh I didn't realise this thread wasn't already on that list. Yes, we should be discussing it there, not here.
Re: [RFC][GCC][rs6000] Remaining work for inline expansion of strncmp/strcmp/memcmp for powerpc
* Bill Schmidt:
> I don't think we have a real concern here. DD2.1 is used in a particular
> situation where GCC 4.8.5 is the supported compiler, and not used elsewhere.
> So I'd prefer not to cripple the compiler for this specific use case. If
> the customer with DD2.1 hardware chooses to use GCC 8 or later, and runs
> into this problem, they can use -mno-builtin-mem{set,cmp} as a workaround.
> Do you feel that's satisfactory?
>
> We can also have a private discussion if you feel that's warranted.
Okay, let's move this off list.
Thanks,
Florian
Re: [PATCH 1/1] stackleak: Register the 'stackleak_cleanup' pass before the 'mach' pass
On 30.11.2018 20:12, Kees Cook wrote: > On Fri, Nov 30, 2018 at 9:09 AM Kees Cook wrote: >> >> On Fri, Nov 30, 2018 at 5:20 AM Alexander Popov wrote: >>> >>> Currently the 'stackleak_cleanup' pass deleting a CALL insn is executed >>> after the 'reload' pass. That allows gcc to do some weird optimization in >>> function prologues and epilogues, which are generated later [1]. >>> >>> Let's avoid that by registering the 'stackleak_cleanup' pass before >>> the 'mach' pass, which performs the machine dependent code transformations. >>> It's the moment when the stack frame size is final and function prologues >>> and epilogues are already generated. >>> >>> [1] https://www.openwall.com/lists/kernel-hardening/2018/11/23/2 >>> >>> Reported-by: kbuild test robot >>> Signed-off-by: Alexander Popov >> >> Thanks, applied! > > Eek, no, this is breaking my build badly: > > *** WARNING *** there are active plugins, do not report this as a bug > unless you can reproduce it without enabling any plugins. > Event| Plugins > PLUGIN_START_UNIT| stackleak_plugin > kernel/exit.c: In function ‘release_task’: > kernel/exit.c:228:1: internal compiler error: Segmentation fault > } > > Failing with: > > gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0 I've done debugging of gcc with gdb and now understand my mistake. It turned out that I register the 'stackleak_cleanup' pass deleting CALL insn for that particular moment when the control flow graph is inconsistent. That's what the machine-specific reorg passes do on various architectures: /* We are freeing block_for_insn in the toplev to keep compatibility with old MDEP_REORGS that are not CFG based. Recompute it now. */ compute_bb_for_insn (); So recomputing basic block info for insns before calling delete_insn_and_edges() fixes the issue. But I think it's better to register the 'stackleak_cleanup' pass just one pass earlier -- before the '*free_cfg' pass. I'll double check it for different versions of gcc on all supported architectures and return with a new patch. Best regards, Alexander
Fwd: [GSOC] variations in testsuite results
-- Forwarded message - From: Siddhartha Sen Date: Sat 1 Dec, 2018, 2:01 AM Subject: Re: [GSOC] variations in testsuite results To: Hi Martin, I apologise for the late reply.My semester end exams are currently going on and I am finding it a bit difficult to devote time for this. However, this time I have taken a bit different approach and it has worked perfectly fine. I don't know what went wrong the last time,but this is what I did this time: Firstly,I use an x86_64(Ubuntu 18.04) since you asked,although I am not sure whether that was a big factor or not. Anyways, I checked out the source code. I checked on the internet to find that a few missing libraries were required to compile gcc. Initially I was going to install them by hand but then I realised it woud be a long process, considering I had to get each one of those as well as check each of their versions,etc. So I used the script that has been bundled with the source about which,to be honest, I was unaware of until very recently. Then, I initially unset everything and then enabled 'langages' and 'gold' and disabled 'libquadmath'(the quad math library),werror' and 'bootstrap'.(A quick question:Did I also need to disable the support for quadmath as well?).I thought of using the default ld linker instead of the gold linker, but then I read somewhere gold linker worked faster for c++ projects. Finally I compiled it(which took a bit longer than it should have) and installed it for usage.I was actually experimenting a bit and went a bit further and added it as an environment variable through the export command. And that was all. Please let me know what you thought and tell me what to do next. Thank You. On Wed, Nov 28, 2018 at 10:46 PM Martin Jambor wrote: > Hi Siddhartha, > > On Tue, Nov 27 2018, Siddhartha Sen wrote: > > I am Siddhartha Sen,currently pursuing my B.Tech degree in Information > > Science and Engineering,2nd year. I have taken a keen interest in your > > projects and have some ideas of my own as well. I am really interested in > > working with you in G-SOC 2019. > > We are delighted. > > > I am proficient in C and C++ and am eager > > to work on brushing my skills in whichever field required. I have already > > checked out the GCC trunk source-code and am being able to build GCC from > > it.I have run the testsuite and saved the results. > > Great, those are all the essential first steps, it seems like you are > ready to work on your first patch. > > > However, upon building > > it and saving it again, the results don't match. I apologise for my lack > of > > knowledge but any help on your part would be great. > > How did you compare the test results and which tests behaved > differently? How did you configure GCC? Was it on an x86_64? > > Unfortunately, this sometimes happens. As far as I can tell, the libgo > testsuite is very flaky and I basically ignore its results. In the > past, I believe that also some guality tests sometimes passed and > sometimes did not, but I have not heard such reports recently. These > tests however also depend on the GDB (version) you have installed on > your system. > > Martin >
Re: Bug 84762 - GCC for PowerPC32 violates the SysV ABI spec for small struct returns
Thank you Sirl, >>-msvr4-struct-return=standard and -msvr4-struct-return=gnu (which would be the default (-msvr4-struct-return=standard) by default, you mean using registers to return? Lokesh On Fri, Nov 30, 2018 at 4:18 PM Franz Sirl wrote: > > Am 2018-11-26 um 06:13 schrieb Lokesh Janghel: > > Hi Sirl, > > > > As you mentioned in Bugzilla (comment 13), > > aix_return ( return in memory) > > svr4_return (return in register) > > what is the semantics of svr4gnu w.r.t. return. > > Hi Lokesh, > > I don't quite understand what you are asking me here? In comment 13 > I've talked about the option naming, which I was unsure about. In the > end (before I was stuffed with other work again) I was settling for > -msvr4-struct-return=standard and -msvr4-struct-return=gnu (which would > be the default and is equal the current behaviour), leaving > -maix-struct-return unchanged. > > What else do you want to know? > > Franz -- Thanks & Regards Lokesh Janghel +91-9752984749
