Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Newsgroups: comp.arch Subject: Re: is Vax addressing sane today Date: Sat, 12 Oct 2024 09:18:23 GMT Organization: Institut fuer Computersprachen, Technische Universitaet Wien Lines: 30 Message-ID: <2024Oct12.111823@mips.complang.tuwien.ac.at> References: <2024Sep10.094353@mips.complang.tuwien.ac.at> Injection-Date: Sat, 12 Oct 2024 11:36:50 +0200 (CEST) Injection-Info: dont-email.me; posting-host="29d5d06e203f002c66a9502ffb11d396"; logging-data="109941"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18dO8Zjm5kL0E/Q4XX/69jI" Cancel-Lock: sha1:q4nV/EzHx3y9N8bSIM6Jz7rKdG8= X-newsreader: xrn 10.11 Bytes: 2180 EricP writes: >Kent Dickey wrote: [...] >GCC's -trapv option is not useful for a variety of reasons. >1) its slow, about 50% performance hit >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. .... >> So why should any hardware include an instruction to trap-on-overflow? > >Because ALL the negative speed and code size consequences do not occur. Looking at and selecting MIPS clang 18.1.0, I get a 15-instruction sequence which does not include add (the trap-on-overflow version). MIPS gcc 14.2.0 generates a sequence that includes jal __addvsi3 i.e., just as for x86-64. Similar for MIPS64 with these compilers. Interestingly, with RISC-V rv64gc clang 18.1.0, the sequence is much shorter than for MIPS clang 18.1.0, even though RV64GC has no specific way of checking overflow at all. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup,