Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > muc.lists.netbsd.tech.toolchain > #3613

C compiler (over-)optimization (was: netbsd-11 gcc bug)

Show all headers | View raw

> That is, after all, what compilers are for: to be useful.
This makes me believe the problem is much simpler, worse, and lies deeper.
The question is: useful for whom?

One part of people programming in C, especially system programmers (for whom 
the language has originally been designed) obviously (or so I think) regard 
C as a kind of abstract portable assembler (which, as far as I understand, 
B and K&R C were sort of intended to be), are knowledgeble of assembly 
language(s) and read
	*p++ = q->foo_ch;
as
	MOV.B 37(A5), (A6)+

Then, because C was so widely available (because it ws used to write OSes 
and without an OS, there would be no point in writing applications), 
application programmers started to use C to write, well, applications 
(I'm not talking of Unix userland, which was probably mostly written by 
system programmers).
And they read above C code as
	abstract_assignement(source_type: abstract_char, destination_type: abstract_char, destination: abstract_pointer_dereference(p), source: abstract_struct_type_fetch(type: char, base: abstract_pointer_dereference(q), field: "ch")); abstract_pointer_increment(type: abstract_char, pointer: p); sequence_point;

Parallel to that, two things happened to real computers:
1. sign-magnitude, one's complement, 6-bit-chars and 36-bit-words disappeared
2. SMP, out-of-order-execution, speculative execution etc. appeared

And then, C, the gory details of which used to be de-facto-defined by the 
existing compiler(s), written by system programmers in a way the language 
was useful to them, was standarized (sill supporting 
6-bit-one's-complement-chars and 36 bit longs), trying to abstractly define 
what was common sense for the sematics before. On top of that, compiler 
authors who weren't (or didn't care for) system programmers tried to make 
the language "useful" (e.g. 0.03% faster in edge cases) for application 
programmers, obeying the words of the standard.

That can't work.

I'm afraid the only way out would be to abandon C as a system programming 
language, invent a new one that, e.g., forbids optimizing away null pointer 
tests because 42 lines above, there's an expression that is formally UB 
if NULL is 0x12345678.

Of course that's not going to happen.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

Back to muc.lists.netbsd.tech.toolchain | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

netbsd-11 gcc bug Manuel Bouyer <bouyer@antioche.eu.org> - 2026-05-23 10:59 +0200
  Re: netbsd-11 gcc bug Manuel Bouyer <bouyer@antioche.eu.org> - 2026-05-23 12:55 +0200
    Re: netbsd-11 gcc bug Manuel Bouyer <bouyer@antioche.eu.org> - 2026-05-23 20:45 +0200
  Re: netbsd-11 gcc bug Valery Ushakov <uwe@stderr.spb.ru> - 2026-05-23 14:22 +0300
    Re: netbsd-11 gcc bug Manuel Bouyer <bouyer@antioche.eu.org> - 2026-05-23 13:28 +0200
  Re: netbsd-11 gcc bug Roland Illig <roland.illig@gmx.de> - 2026-05-23 20:38 +0200
    Re: netbsd-11 gcc bug Manuel Bouyer <bouyer@antioche.eu.org> - 2026-05-23 20:47 +0200
      Re: netbsd-11 gcc bug Robert Elz <kre@munnari.OZ.AU> - 2026-05-24 02:29 +0700
        Re: netbsd-11 gcc bug Mouse <mouse@Rodents-Montreal.ORG> - 2026-05-23 19:11 -0400
          Re: netbsd-11 gcc bug Martin Husemann <martin@duskware.de> - 2026-05-24 10:44 +0200
            Re: netbsd-11 gcc bug Mouse <mouse@Rodents-Montreal.ORG> - 2026-05-24 08:33 -0400
              Re: netbsd-11 gcc bug Jason Thorpe <thorpej@me.com> - 2026-05-24 11:38 -0400
                Re: netbsd-11 gcc bug "Greg A. Woods" <woods@planix.ca> - 2026-05-24 16:53 -0700
              Re: netbsd-11 gcc bug David Holland <dholland-tech@netbsd.org> - 2026-05-25 00:02 +0000
                Re: netbsd-11 gcc bug Mouse <mouse@Rodents-Montreal.ORG> - 2026-05-25 08:23 -0400
                C compiler (over-)optimization (was: netbsd-11 gcc bug) Edgar Fuß <ef@math.uni-bonn.de> - 2026-05-29 19:12 +0200
                Re: C compiler (over-)optimization (was: netbsd-11 gcc bug) Mouse <mouse@Rodents-Montreal.ORG> - 2026-05-29 14:21 -0400
                Re: C compiler (over-)optimization (was: netbsd-11 gcc bug) "Greg A. Woods" <woods@planix.ca> - 2026-05-29 14:27 -0700
                Re: C compiler (over-)optimization Anders Magnusson <ragge@tethuvudet.se> - 2026-05-30 12:30 +0200
                Re: C compiler (over-)optimization (was: netbsd-11 gcc bug) Andrew Cagney <andrew.cagney@gmail.com> - 2026-05-31 13:02 -0400
                Re: C compiler (over-)optimization (was: netbsd-11 gcc bug) Jason Thorpe <thorpej@me.com> - 2026-05-31 14:29 -0500
                Re: netbsd-11 gcc bug "Greg A. Woods" <woods@planix.ca> - 2026-05-28 14:40 -0700
                Re: netbsd-11 gcc bug Mouse <mouse@Rodents-Montreal.ORG> - 2026-05-28 18:36 -0400
                Re: netbsd-11 gcc bug Jason Thorpe <thorpej@me.com> - 2026-05-28 19:04 -0400
                Re: netbsd-11 gcc bug "Greg A. Woods" <woods@planix.ca> - 2026-05-29 14:31 -0700
      Re: netbsd-11 gcc bug Jörg Sonnenberger <joerg@bec.de> - 2026-05-26 13:52 +0200
        Re: netbsd-11 gcc bug Jason Thorpe <thorpej@me.com> - 2026-05-26 10:02 -0400

csiph-web