From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by sourceware.org (Postfix) with ESMTPS id 985CB3870846 for ; Tue, 12 May 2020 22:39:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 985CB3870846 Received: by mail-il1-x143.google.com with SMTP id q10so14082675ile.0 for ; Tue, 12 May 2020 15:39:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GZ2o8fLMEb0T6dYikYnaPQVoFNGh1gCnPFSaSj9xo28=; b=D0ZcQcgbBpq8yPc9v5ZWBaGtzy64G7Tg0DWMMdhXz64Yj9Ncoh5IWj9udqtADUfULl eyaC6qC/6BqFerVC3dlSYf0F9o5hPYtrzIL5KY6ldkFSXlj7xlGyHztOBMD8xhWXEMMH xHJtvb3lBjFyLGERVZMpfGPF2bCwGB8D2gUWXby3qRZ72FLg2WObXnncV39aimwIxl0n nGZ7U6ZeSdB0oxN7iooqVNYiTESjf4IJ7X4FtYkEXsamvZ22cyhd57KleeGUuhBT3AKO aT/htJjT5SRwJEYwIltHL7dEG/UrJChZwyX4XrQax578PnT8aQQxrkY6OWw85dKEMhuA KEMg== X-Gm-Message-State: AGi0PuZZrcaGsEks9VvXoPUxtXtgyWEjSndqSdsHME9WFEYY+CT5fllX xkgim+OnOMGVpMwZ2PKMBQieNK39k1n11fZwwNU= X-Google-Smtp-Source: APiQypJ6KUJeB2yJpdzZ+qvZJud0bkwoRZbCTpzjoMhP7utoYQ6xVdPyo6awlvWU7rj+rb3Nl89BKUdr25zJ/fw0FgA= X-Received: by 2002:a92:c401:: with SMTP id e1mr19544245ilp.134.1589323168107; Tue, 12 May 2020 15:39:28 -0700 (PDT) MIME-Version: 1.0 References: <0bbdaab7-c083-e14e-6227-27713dab9657@users.sourceforge.net> <874ksmg3fb.fsf@oldenburg2.str.redhat.com> <929cc727-20c6-480c-3412-d3f7a08f7544@users.sourceforge.net> <1ca27c9f-235d-5e97-a506-e6267aeb81c6@redheads.de> <7ff5de622d68b00e195cb4bf176a729064cb4eb5.camel@op.pl> In-Reply-To: From: Jonathan Wakely Date: Tue, 12 May 2020 23:39:17 +0100 Message-ID: Subject: Re: size of exception handling (Was: performance of exception handling) To: Freddie Chopin Cc: =?UTF-8?Q?Moritz_Str=C3=BCbe?= , "gcc@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 22:39:30 -0000 On Tue, 12 May 2020, 21:57 Freddie Chopin, wrote: > > On Tue, 2020-05-12 at 12:07 +0100, Jonathan Wakely wrote: > > You're talking about C++ exceptions in general, but the problems you > > mention seems to be issues with specific implementation properties. > > Possibly true, but this argument - that all the problems are related to > specific implementation and thus can be easily fixed I didn't say anything about it being easy to fix. I'm just trying to stop misinformation about std::terminate requiring string handling or I/O, which isn't true for C++ in general, and isn't even true for libstdc++ because it's configurable. If you want a smaller EH runtime, that's already possible with libstdc++. Could it be even smaller? Yes, probably, but we need bug reports or concrete suggestions, not outdated or misleading claims about optional properties of the libstdc++ runtime. > - is the same for > years and yet the problem is still there (; I guess that if this could > be easily fixed, then it would be done years ago. Along with the > performance and non-deterministic execution issues... Nobody said it can easily be fixed though. > > If the comments above are referring to the libstdc++ verbose > > terminate > > handler, that's configurable. Configuring GCC with > > --disable-libstdcxx-verbose will disable that, and so will building > > libstdc++ with -fno-exceptions. That was fixed years ago. > > True, sorry for the confusion, indeed I was talking about verbose > terminate handler. I check the state of C++ exceptions for MCUs only > once every few years, so that's why I got that mixed with > std::terminate(). I use my custom compilation with disabled exceptions > (toolchain & libstdc++ built with -fno-exceptions -fno-rtti) and this > works perfectly fine. It's been a few years since we changed anything, because disabling the verbose handler solved one of the biggest issues. > Anyway... If you have to recompile the toolchain, the problem is still > there. Most of the people (like 99,666%) will not do that for various > reasons. Some don't know how, some use only Windows, some don't have > time to deal with the compilation (the whole toolchain takes around an > hour here, but this excludes the time to prepare the script that builds > it), some other consider the toolchain provided by MCU vendor (or by > ARM) as "tested to work correctly" so they don't want to replace that > with their custom built solution, and so on, and so on... There is no one-size-fits-all solution that gives everybody their ideal set of defaults, so we provide configuration options to tune things for your needs. Complaining that you have to rebuild things to get different defaults seems silly. Would you prefer we don't offer the options at all? If you have concrete suggestions for improvements or can identify places we can improve, I'd like to hear them. If you just want to complain about C++ exceptions, that's not very helpful.