Re: [i386, x32] Trouble bootstrapping x86_64-pc-linux-gnux32
On 08/13/2017 05:52 PM, Daniel Santos wrote: > cc1plus: out of memory allocating 56137200 bytes after a total of > 314880 bytes > make[3]: *** [Makefile:1104: insn-extract.o] Error 1 > make[3]: *** Waiting for unfinished jobs I apparently misunderstood the "after a total of x" part of the message -- that is indicating the total amount of memory that has been allocated by the process thus far. So the problem is that the stage2 link of libgcc with --enable-checking=yes,rtl just requires more than 4GiB of memory, which can't be addressed by an x32 process. This was not the case with 7.1.0, but maybe more checks have been added and that uses additional memory? Anyway, In case it's helpful for anybody, this is the backtrace of the allocation prior to it failing: (gdb) bt #0 __GI___libc_malloc (bytes=56137200) at malloc.c:2905 #1 0x025bc8dc in xmalloc (size=56137200) at /home/daniel/proj/sys/gcc/head/libiberty/xmalloc.c:147 #2 0x0124ffa7 in (anonymous namespace)::pass_cprop_hardreg::execute (this=0x32b8e50, fun=0xd359d270) at /home/daniel/proj/sys/gcc/head/gcc/regcprop.c:1272 #3 0x011c9f23 in execute_one_pass (pass=) at /home/daniel/proj/sys/gcc/head/gcc/passes.c:2495 #4 0x011ca2ac in execute_pass_list_1 (pass=) at /home/daniel/proj/sys/gcc/head/gcc/passes.c:2584 #5 0x011ca2de in execute_pass_list_1 (pass=) at /home/daniel/proj/sys/gcc/head/gcc/passes.c:2585 #6 0x011ca2de in execute_pass_list_1 (pass=) at /home/daniel/proj/sys/gcc/head/gcc/passes.c:2585 #7 0x011ca340 in execute_pass_list (fn=0xd359d270, pass=) at /home/daniel/proj/sys/gcc/head/gcc/passes.c:2595 #8 0x00cb317b in cgraph_node::expand (this=) at /home/daniel/proj/sys/gcc/head/gcc/cgraphunit.c:2054 #9 0x00cb384b in expand_all_functions () at /home/daniel/proj/sys/gcc/head/gcc/cgraphunit.c:2190 #10 0x00cb4469 in symbol_table::compile (this=0xf64f60d8) at /home/daniel/proj/sys/gcc/head/gcc/cgraphunit.c:2542 #11 0x00cb46d4 in symbol_table::finalize_compilation_unit (this=0xf64f60d8) at /home/daniel/proj/sys/gcc/head/gcc/cgraphunit.c:2631 #12 0x013c7412 in compile_file () at /home/daniel/proj/sys/gcc/head/gcc/toplev.c:496 #13 0x013c9c51 in do_compile () at /home/daniel/proj/sys/gcc/head/gcc/toplev.c:2037 #14 0x013c9f76 in toplev::main (this=0xcb20, argc=77, argv=0xcc14) at /home/daniel/proj/sys/gcc/head/gcc/toplev.c:2171 #15 0x024fd468 in main (argc=77, argv=0xcc14) at /home/daniel/proj/sys/gcc/head/gcc/main.c:39
Re: [i386, x32] Trouble bootstrapping x86_64-pc-linux-gnux32
On 08/13/2017 07:05 PM, H.J. Lu wrote: > On Sun, Aug 13, 2017 at 3:52 PM, Daniel Santos > wrote: >> I've setup an x32 test environment using Gentoo in hopes of being able >> to both compile and run x32 tests, but I'm having problems getting a >> successful bootstrap. I'm guessing this is due to something currently >> broken with x32, but I want to make sure it's not something I'm doing >> wrong, and if it is broken that we are aware of it. >> >> I'm able to get a 7.1 bootstrap using: >> >> /home/daniel/proj/sys/gcc/7.x/configure >> --prefix=/home/daniel/local/gcc-7.1.0 --build=x86_64-pc-linux-gnux32 >> --with-abi=mx32 --enable-checking=yes,rtl --enable-languages=all >> --enable-bootstrap --enable-option-checking --enable-lto >> --enable-gold=yes --with-system-zlib --enable-link-mutex >> --enable-libgomp --enable-targets=all --disable-gcj > No need to build x32 GCC. Just enable x32 run-time in x86-64 GCC > with > > -with-multilib-list=m32,m64,mx32 > > is sufficient. Well the problem I had when trying that was ld failing because on Gentoo x32, ld is an x32 binary and it fails when it tries to load the lto plugin: /usr/lib/gcc/x86_64-pc-linux-gnux32/5.4.0/../../../../x86_64-pc-linux-gnux32/bin/ld: /home/daniel/proj/sys/gcc/builds/unpatched/./gcc/liblto_plugin.so: error loading plugin: /home/daniel/proj/sys/gcc/builds/unpatched/./gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64 collect2: error: ld returned 1 exit status make[5]: *** [Makefile:982: libgcc_s.so] Error 1 make[5]: Leaving directory '/home/daniel/proj/sys/gcc/builds/unpatched/x86_64-pc-linux-gnu/32/libgcc' I'm trying this again without --enable-gold=yes and maybe I can avoid this problem. Maybe I also need to either use a different OS that can build the x32 libs without making all of /bin and /usr/bin x32. It seems that the only way Gentoo supports x32 so far is a profile that lets you have 32, 64, and x32 libs all side-by-side, but all executables in /bin, /usr/bin, etc. are x32. >> (I guess --disable-gcj was probably useless now) >> >> But when I configure the same way from the head (from two days ago), it >> fails on stage2: >> >> /home/daniel/proj/sys/gcc/unpatched/configure >> --prefix=/home/daniel/local/gcc-unpatched --build=x86_64-pc-linux-gnux32 >> --with-abi=mx32 --enable-checking=yes,rtl --enable-languages=all >> --enable-bootstrap --enable-option-checking --enable-lto >> --enable-gold=yes --with-system-zlib --enable-link-mutex >> --enable-libgomp --enable-targets=all --disable-gcj > x32 GCC built fine on trunk on Aug. 10 with > > configure --with-demangler-in-ld > --enable-languages=c,c++,fortran,lto,objc,obj-c++,go > --prefix=/usr/gcc-8.0.0-mx32 --with-local-prefix=/usr/local > --enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib > --enable-libmpx --with-multilib-list=m32,m64,mx32 > --enable-linker-build-id --enable-gnu-unique-object --with-abi=mx32 > --with-fpmath=sse > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu > checking target system type... x86_64-pc-linux-gnu > > I didn't use --build=x86_64-pc-linux-gnux32 > But you also didn't have --enable-checking=yes,rtl and that's probably what is pushing it over the 4GiB limit. I guess I don't really need that anymore, so I should probably disable that and be done with it. But if I can't get --with-multilib-list=m32,m64,mx32 to work, I'll try this exact set of configure options next. Thanks! Daniel
Re: What to do about all the gcc.dg/guality test failures?
On Wed, Aug 9, 2017 at 5:59 PM, Jeff Law wrote: > On 08/08/2017 01:38 PM, Steve Ellcey wrote: >> I was wondering if something needs to be done about the gcc.dg/guality tests. >> >> There are two main issues I see with these tests, one is that they are often >> not run during testing and so failures do not show up. I looked into this >> and found that, at least on my ubuntu 16.04 system, the kernel parameter >> kernel.yama.ptrace_scope is set to 1 by default. This limits the use of >> ptrace to direct child processes and causes the guality tests to not run >> on my system. They also don't show up as failures, all you get is a message >> in the test log that says 'gdb: took too long to attach'. After changing >> this >> to 0, the guality tests do get run. >> >> The second problem is that many of the tests fail when they are run. >> For example, looking at some August test runs: >> >> x86_64 failures: >> https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg00651.html >> aarch64 failures: >> https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg00603.html >> mips64 failures: >> https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg00527.html >> s390x failures: >> https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg00509.html >> >> These all show many failures in gcc.dg/guality. Most of the failures >> are related to using the '-O2 -flto' or '-O3' options. If I remove those >> option runs I get 15 failures involving 5 tests on my aarch64 system: >> >> gcc.dg/guality/pr36728-1.c >> gcc.dg/guality/pr41447-1.c >> gcc.dg/guality/pr54200.c >> gcc.dg/guality/pr54693-2.c >> gcc.dg/guality/vla-1.c >> >> So I guess there are number of questions: Are these tests worth runnning? >> Do they make sense with -O3 and/or -O2 -flto? If they make sense and >> should be run do we need to fix GCC to clean up the failures? Or should >> we continue to just ignore them? > I look at them strictly from a regression standpoint. Whatever set > passes from my baseline run must continue to pass after whatever changes > I'm contemplating. > > They're unfortunately very fragile (in terms of how they behave on > different versions of gdb, kernels, etc), so absolute pass/fail status > isn't particularly helpful. And yes, if analysis tells us that we can never support it for some option then either dg-skip-if that or amend the testcase (adding more asm optimization barriers, function attributes, etc.). Note that in most cases there are real issues with debuginfo generation, in some cases target difficulties. Documenting them (after analyzing) would also help (and then xfailing or skipping). Richard. > > Jeff
GCC 7.2 Released
The GNU Compiler Collection version 7.2 has been released. GCC 7.2 is a bug-fix release from the GCC 7 branch containing important fixes for regressions and serious bugs in GCC 6.1 with more than 95 bugs fixed since the previous release. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
GCC 7.3 Status report (2017-08-14)
Status == GCC 7.2 has been released and the branch is again open for regression and documentation fixes. History makes us expect a GCC 7.3 release at the end of this or the beginning of next year. Quality Data Priority # Change from last report --- --- P1 P2 139 - 2 P3 22 + 19 P4 156 P5 28 --- --- Total P1-P3 161 + 17 Total 345 + 17 Previous Report === https://gcc.gnu.org/ml/gcc/2017-07/msg00194.html
Re: Optimization breaks inline asm code w/ptrs
On Sun, Aug 13, 2017 at 10:25:14PM +0930, Alan Modra wrote:
> On Sun, Aug 13, 2017 at 03:35:15AM -0700, David Wohlferd wrote:
> > Using "m"(*pStr) as an (unused) input parameter has no effect.
>
> Use "m" (*(const void *)pStr) and ignore the warning, or use
> "m" (*(const struct {char a; char x[];} *) pStr).
or even better "m" (*(const char (*)[]) pStr).
> The issue is one of letting gcc know what memory is accessed by the
> asm, if you don't want to use a "memory" clobber. And there are very
> good reasons to avoid clobbering all memory.
>
> "m"(*pStr) ought to work IMO, but apparently just tells gcc you are
> only interested in the first character. Of course that is exactly
> what *pStr is, but in this context it would be nicer if it meant the
> entire array.
I take that back. The relatively simple cast to differentiate a
pointer to a char from a pointer to an indeterminate length char array
makes it quite unnecessary for "m"(*pStr) to be treated as as array
reference.
I've opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81845 to
track the lack of documentation.
--
Alan Modra
Australia Development Lab, IBM
Re: [i386, x32] Trouble bootstrapping x86_64-pc-linux-gnux32
On Mon, Aug 14, 2017 at 12:35 AM, Daniel Santos wrote: > On 08/13/2017 07:05 PM, H.J. Lu wrote: >> On Sun, Aug 13, 2017 at 3:52 PM, Daniel Santos >> wrote: >>> I've setup an x32 test environment using Gentoo in hopes of being able >>> to both compile and run x32 tests, but I'm having problems getting a >>> successful bootstrap. I'm guessing this is due to something currently >>> broken with x32, but I want to make sure it's not something I'm doing >>> wrong, and if it is broken that we are aware of it. >>> >>> I'm able to get a 7.1 bootstrap using: >>> >>> /home/daniel/proj/sys/gcc/7.x/configure >>> --prefix=/home/daniel/local/gcc-7.1.0 --build=x86_64-pc-linux-gnux32 >>> --with-abi=mx32 --enable-checking=yes,rtl --enable-languages=all >>> --enable-bootstrap --enable-option-checking --enable-lto >>> --enable-gold=yes --with-system-zlib --enable-link-mutex >>> --enable-libgomp --enable-targets=all --disable-gcj >> No need to build x32 GCC. Just enable x32 run-time in x86-64 GCC >> with >> >> -with-multilib-list=m32,m64,mx32 >> >> is sufficient. > > Well the problem I had when trying that was ld failing because on Gentoo > x32, ld is an x32 binary and it fails when it tries to load the lto plugin: > > /usr/lib/gcc/x86_64-pc-linux-gnux32/5.4.0/../../../../x86_64-pc-linux-gnux32/bin/ld: > /home/daniel/proj/sys/gcc/builds/unpatched/./gcc/liblto_plugin.so: error > loading plugin: > /home/daniel/proj/sys/gcc/builds/unpatched/./gcc/liblto_plugin.so: wrong > ELF class: ELFCLASS64 > collect2: error: ld returned 1 exit status > make[5]: *** [Makefile:982: libgcc_s.so] Error 1 > make[5]: Leaving directory > '/home/daniel/proj/sys/gcc/builds/unpatched/x86_64-pc-linux-gnu/32/libgcc' > > I'm trying this again without --enable-gold=yes and maybe I can avoid > this problem. Maybe I also need to either use a different OS that can > build the x32 libs without making all of /bin and /usr/bin x32. It > seems that the only way Gentoo supports x32 so far is a profile that > lets you have 32, 64, and x32 libs all side-by-side, but all executables > in /bin, /usr/bin, etc. are x32. > >>> (I guess --disable-gcj was probably useless now) >>> >>> But when I configure the same way from the head (from two days ago), it >>> fails on stage2: >>> >>> /home/daniel/proj/sys/gcc/unpatched/configure >>> --prefix=/home/daniel/local/gcc-unpatched --build=x86_64-pc-linux-gnux32 >>> --with-abi=mx32 --enable-checking=yes,rtl --enable-languages=all >>> --enable-bootstrap --enable-option-checking --enable-lto >>> --enable-gold=yes --with-system-zlib --enable-link-mutex >>> --enable-libgomp --enable-targets=all --disable-gcj >> x32 GCC built fine on trunk on Aug. 10 with >> >> configure --with-demangler-in-ld >> --enable-languages=c,c++,fortran,lto,objc,obj-c++,go >> --prefix=/usr/gcc-8.0.0-mx32 --with-local-prefix=/usr/local >> --enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib >> --enable-libmpx --with-multilib-list=m32,m64,mx32 >> --enable-linker-build-id --enable-gnu-unique-object --with-abi=mx32 >> --with-fpmath=sse >> checking build system type... x86_64-pc-linux-gnu >> checking host system type... x86_64-pc-linux-gnu >> checking target system type... x86_64-pc-linux-gnu >> >> I didn't use --build=x86_64-pc-linux-gnux32 >> > > But you also didn't have --enable-checking=yes,rtl and that's probably > what is pushing it over the 4GiB limit. I guess I don't really need > that anymore, so I should probably disable that and be done with it. Yes, I got the same error with --enable-checking=yes,rtl: cc1plus: out of memory allocating 56137200 bytes after a total of 3139436544 bytes make[5]: *** [Makefile:1104: insn-extract.o] Error 1 > But if I can't get --with-multilib-list=m32,m64,mx32 to work, I'll try > this exact set of configure options next. > > Thanks! > Daniel > -- H.J.
Should --enable-checking=yes,rtl work on 32-bit hosts?
For GCC 8, when --enable-checking=yes,rtl is used with x32 GCC, I got cc1plus: out of memory allocating 56137200 bytes after a total of 3139436544 bytes make[5]: *** [Makefile:1104: insn-extract.o] Error 1 make[5]: *** Waiting for unfinished jobs gcc-7-branch is OK. Is this expected? -- H.J.
Re: Behaviour of __forced_unwind with noexcept
On 13 August 2017 at 19:20, Ron wrote: > > Hi, > > I'm looking for some clarification of how the __forced_unwind thread > cancellation exceptions intersect with noexcept. I've long been a > big fan of the __forced_unwind idiom, but now that C++14 is the default > since GCC 6.1, and many methods including destructors are implicitly > noexcept, using it safely appears to have become a lot more tricky. > > The closest I've found so far to an "authoritative" statement of the > expected behaviour is the comments from Jonathan Wakely here: > > https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex > > In particular: "It interacts with noexcept as you'd expect: > std::terminate() is called if a __forced_unwind escapes a noexcept > function, so noexcept functions are really noexcept, they won't > unexpectedly throw some 'special' type" > > Which does seem logical, but unless I'm missing something this makes > it unsafe to perform any operation in a destructor which might cross > a cancellation point, unless that destructor is noexcept(false). Unfortunately I still think that's true. This was also raised in https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html > And since that could be something as simple as logging to stdio and > almost impossible to definitely rule out in a future proof way if the > destructor does anything non-trivial (like calling functions in a > system or other 3rd party library) ... and since the race of catching > a cancellation request in such a destructor could be a relatively rare > one to lose in a lot of code ... there could be a lot of extant code > with new latent 'crasher' bugs when built with GCC 6.1 or later. > > And/or a lot of people are going to have to go through a lot of code > and mark up a lot of methods with noexcept(false). > > > So I'm half-hoping that I am actually missing something here which > mitigates that - but if not, is this something we need to give a > bit more thought to? > > (Please keep me cc'd, I'm not currently on this list) > > Cheers, > Ron >
Re: [i386, x32] Trouble bootstrapping x86_64-pc-linux-gnux32
On 08/14/2017 08:09 AM, H.J. Lu wrote: > Yes, I got the same error with --enable-checking=yes,rtl: > > cc1plus: out of memory allocating 56137200 bytes after a total of > 3139436544 bytes > make[5]: *** [Makefile:1104: insn-extract.o] Error 1 Thanks for the confirmation. I have a successful x32 bootstrap using --enable-checking=yes without rtl -- good enough for all of the tests that I need to run. Daniel
Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.
On 08/14/2017 04:22 PM, Eric Gallager wrote: I'm emailing this manually to the list because Bugzilla is down and I can't file a bug on Bugzilla about Bugzilla being down. The error message looks like this: Bugzilla and the rest of gcc.gnu.org have been down much of the afternoon/evening due to a hard drive upgrade (the old disk apparently failed). You're not the only one who found out about it the hard way. I (and I suspect most others) also discovered it when things like Git and SVN (and Bugzilla) stopped working. I've CC'd the gcc list to let others know (not sure what list to subscribe to in order to get a heads up on these kinds of maintenance issues). Martin Software error: Can't connect to the database. Error: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) Is your database installed and up and running? Do you have the correct username and password selected in localconfig? For help, please send mail to the webmaster (sourcemas...@sourceware.org), giving this error message and the time and date of the error. Unfortunately, the email address listed for the webmaster, , sends me its own error message when I try to email it, because the address apparently doesn't exist. I'm forwarding a copy of the failure email with this message. Is there a different address I should be emailing instead? Thanks, Eric Gallager -- Forwarded message -- From: mailer-dae...@sourceware.org Date: 14 Aug 2017 22:03:54 - Subject: failure notice To: eg...@gwmail.gwu.edu Hi. This is the qmail-send program at sourceware.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : Sorry, no mailbox here by that name. (#5.1.1) --- Below this line is a copy of the message. Return-Path: Received: (qmail 24677 invoked by uid 89); 14 Aug 2017 22:03:52 - Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-Spam-Status: No, score=0.5 required=5.0 tests=RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-wm0-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 14 Aug 2017 22:03:51 + Received: by mail-wm0-f42.google.com with SMTP id i66so3361599wmg.0 for ; Mon, 14 Aug 2017 15:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gwmail-gwu-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=A6iFIzlnSazSObmM6Wb7tDW+ZAb4ojY1zG6bxpdCLCQ=; b=cvRTbJxAB1UKTO01xqOGTtvgLjbLLOumX/FUdM3ruLkvMpJx6QiO7X51cU6X6jcx24 ReoVRxaW8NwWcVJts9JB5tPJSg/8+ljL8ywMoa9Aa6S1MQ4PS246aVgKM5aUNmaB1E+u NrQMAmsxixJG/wmrAnSpQ/imIt7XNHRBNnZ5/B1JiGAt3ChjHwTNKV/9W4fxydsJL9BE iL9D/duAl6C/RAvBPQ5BC0Kv+/HtzhH8bwgElbjP93hMJk/nAfceI7Rh/4zIgY5V6ZHS E7LzrUetB7aeyzdlTy6i/3Lsyb0wnUuocZdZtGndQD24WSngk3fInlHwWrcUVdTpRMQ5 e4tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=A6iFIzlnSazSObmM6Wb7tDW+ZAb4ojY1zG6bxpdCLCQ=; b=GQbdg3EVSV+aMfKeSffGxae54jos3nNUt3qQWoSthUOEFy57YAeV5Fn86IOYLTw4fI gZKi7samoFHs0yHdF4sawi+xVMfZMzGPqGrJjsAIHYSE9T+o9vx0cEJPhPs0rswqinCO WovmT8Kh1jNEaIyxLwZGk07lt5oyWTk72zaT+CxWjamKbLJzDfqWMfpahDuTVI74QQie m8qtMTBQjek1Di51mxiBcuaLlr1xNqwrVS3JQEjdl2NCOBEDodLosGkUJCFR29hw6EAK ag3Lo96yUeNlfjOXv8/FYbCTrbcrhxbms02n0p3oK3cSHkoqZKcUOQQJzuNq0c38W9PU 6A0w== X-Gm-Message-State: AHYfb5ilSTxPFsi8yTAJsSJ6LpZu+DahzJygxoF6Q5usa2PIRZDQhD5i b5akwEZnwfnttac6yAR/os3Kbj3Gqwbh X-Received: by 10.80.215.68 with SMTP id i4mr25610854edj.258.1502748228995; Mon, 14 Aug 2017 15:03:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.129.227 with HTTP; Mon, 14 Aug 2017 15:03:48 -0700 (PDT) From: Eric Gallager Date: Mon, 14 Aug 2017 18:03:48 -0400 Message-ID: Subject: GCC bugzilla down? To: sourcemas...@sourceware.org Content-Type: text/plain; charset="UTF-8" When I tried to access the GCC Bugzilla this evening of August 14, 2017, at 6PM Eastern Daylight Time, it displayed this error message: Software error: Can't connect to the database. Error: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) Is your database installed and up and running? Do you have the correct username and password selected in localconfig? For help, please send mail to the webmaster (sourcemas...@sourceware.org), giving this error message and
Re: Behaviour of __forced_unwind with noexcept
On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote: > On 13 August 2017 at 19:20, Ron wrote: > > > > Hi, > > > > I'm looking for some clarification of how the __forced_unwind thread > > cancellation exceptions intersect with noexcept. I've long been a > > big fan of the __forced_unwind idiom, but now that C++14 is the default > > since GCC 6.1, and many methods including destructors are implicitly > > noexcept, using it safely appears to have become a lot more tricky. > > > > The closest I've found so far to an "authoritative" statement of the > > expected behaviour is the comments from Jonathan Wakely here: > > > > https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex > > > > In particular: "It interacts with noexcept as you'd expect: > > std::terminate() is called if a __forced_unwind escapes a noexcept > > function, so noexcept functions are really noexcept, they won't > > unexpectedly throw some 'special' type" > > > > Which does seem logical, but unless I'm missing something this makes > > it unsafe to perform any operation in a destructor which might cross > > a cancellation point, unless that destructor is noexcept(false). > > Unfortunately I still think that's true. > > This was also raised in https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html Ouch. Had you considered the option of having any scope that is noexcept(true) also be treated as if it was implicitly in a scoped pthread_setcancelstate(PTHREAD_CANCEL_DISABLE), restoring the old state when it leaves that scope? Would it be feasible for the compiler to automatically generate that? For any toolchain which does use the unwinding exceptions extension, that also seems like a logical extension to the noexcept behaviour, since allowing cancellation will otherwise result in an exception and process termination. If people really need cancellation in such scopes, then they can more manageably mark just those noexcept(false). It would need to be done by the compiler, since in user code I can't do that in a destructor in a way that will also protect unwinding members of a class (which may have destructors in code I don't control). I can't even completely mitigate this by just always using -std=c++03 because presumably I'm also exposed to (at least) libstdc++.so being built with the new compiler default of C++14 or later. I'd be really sad to lose the stack unwinding we currently have when a thread is cancelled. I've always known it was an extension (and I'm still a bit surprised it hasn't become part of the official standard), but it is fairly portable in practice. On Linux (or on Debian at least) clang also supports it. It's also supported by gcc on FreeBSD and MacOS (though not by clang there). It's supported by mingw for Windows builds. OpenBSD is currently the only platform I know of where even its gcc toolchain doesn't support this (but they're also missing support for standard locale functionality so it's a special snowflake anyway). It seems that we need to find some way past the status-quo though, because "don't ever use pthread_cancel" is the same as saying that there's no longer any use for the forced_unwind extension. Or that "you can have a pthread_cancel which leaks resources, or none at all". Having a pthread_cancel that only works on cancellation points that aren't noexcept seems like a reasonable compromise and extension to the shortcomings of the standard to me. Am I missing something there which makes that solution not a viable option either? > > And since that could be something as simple as logging to stdio and > > almost impossible to definitely rule out in a future proof way if the > > destructor does anything non-trivial (like calling functions in a > > system or other 3rd party library) ... and since the race of catching > > a cancellation request in such a destructor could be a relatively rare > > one to lose in a lot of code ... there could be a lot of extant code > > with new latent 'crasher' bugs when built with GCC 6.1 or later. > > > > And/or a lot of people are going to have to go through a lot of code > > and mark up a lot of methods with noexcept(false). > > > > > > So I'm half-hoping that I am actually missing something here which > > mitigates that - but if not, is this something we need to give a > > bit more thought to? > > > > (Please keep me cc'd, I'm not currently on this list) > > > > Cheers, > > Ron
