Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Sat, 28 Sep 2024 17:20:56 +0200
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <vd96sp$1a3m9$1@dont-email.me>
References: <vbd6b9$g147$1@dont-email.me>
 <2024Sep10.094353@mips.complang.tuwien.ac.at> <vckf9d$178f2$1@dont-email.me>
 <O2DHO.184073$kxD8.113118@fx11.iad> <vcso7k$2s2da$1@dont-email.me>
 <efXIO.169388$1m96.45507@fx15.iad>
 <35hefjh0c3kvoj5ah3g5npa87th3g6rfg5@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 28 Sep 2024 17:20:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c200d6735aa51a7b54c701292d6dc738";
	logging-data="1380041"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+iQT5o4lHiUuaRuCWX2X27jxyZYtFujPc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:a//7IdCDFX7s6czojZ75rI4OmeY=
Content-Language: en-GB
In-Reply-To: <35hefjh0c3kvoj5ah3g5npa87th3g6rfg5@4ax.com>
Bytes: 3492

On 28/09/2024 01:52, George Neuner wrote:
> On Wed, 25 Sep 2024 12:54:18 -0400, EricP
> <ThatWouldBeTelling@thevillage.com> wrote:
> 
>> For me error detection of all kinds is useful. It just happens
>> to not be conveniently supported in C so no one tries it in C.
>>
>> GCC's -trapv option is not useful for a variety of reasons.
>> 1) its slow, about 50% performance hit

Trapping or other overflow detection makes it extremely difficult to 
optimise arithmetic.  All kinds of re-arrangements, strength reduction 
and constant propagation become problematic if you need to flag 
overflow.  That comes in addition to any actual overflow detection.

I've just tried a quick test on godbolt - when you use -ftrapv, it seems 
that in at least some cases, the trapping arithmetic is done use a 
library function (like "__mulvsi3") rather than direct code.  This will 
have significant performance implications.

>> 2) its always on for a compilation unit which is not what programmers need
>>     as it triggers for many false positives so people turn it off.

GCC lets you turn "-fwrapv" on and off with :

#pragma GCC optimize("-ftrapv")

and

#pragma GCC optimize("-fno-trapv")

It also lets you specify it for a single function at a time with

__attribute__((optimize("-ftrapv")))


Changing these options does have some limitations, such as disabling 
inlining into functions with different options.  But you can happily 
apply it to only some functions in a translation unit.

> 
> Things like that are why some companies have a code policy that allows
> just one function per file.
> 

I have never heard of such a policy, and I think it would be an 
extremely silly one - code would be completely unmanageable, and the 
results would be significantly poorer when using modern compilers (i.e., 
anything this century).

> Still a problem if you need <whatever the relevant flag does> only in
> one or a few places.

There are gcc flags that are only controllable for compiler invocations, 
rather than with pragmas or attributes, and of course not every compiler 
has the flexibility of gcc or clang.  But this is not nearly the level 
you seem to think it is.