Michael S <already5chosen@yahoo.com> writes:

> On Sunday, October 17, 2021 at 5:27:35 PM UTC+3, Tim Rentsch wrote:
>
>> Michael S <already...@yahoo.com> writes:
>>
>>> On Saturday, October 16, 2021 at 9:23:45 PM UTC+3, Niklas Holsti wrote:
>>>
>>>> On 2021-10-16 20:03, Michael S wrote:
>>
>> [...]
>>
>>>>> A war story from ~2 years ago (I am not sure if details of code
>>>>> are correct, but sure about principle):
>>>>>
>>>>> #define TIME_VAL (*(volatile uint32_t*)0x12345608))
>>>>> #define ACTION_REG (*(volatile uint32_t*)0x43215604))
>>
>> Note that these definitions have unbalanced parentheses.
>>
>>>>> void foo(int moo, int arg, uint32_t t0, uint32_t dt)
>>>>> {
>>>>> uint32_t bar;
>>>>> if (moo)
>>>>> bar = 0.42 * arg - 11.3;
>>>>> else
>>>>> bar = 0.43 * arg + 11.7;
>>>>>
>>>>> if (moo) {
>>>>> while (TIME_VAL-t0 < dt);
>>>>> }
>>>>> ACTION_REG = bar;
>>>>> }
>>>>>
>>>>> [which was compiled to something like]
>>>>>
>>>>> void foo(int moo, int arg, uint32_t t0, uint32_t dt)
>>>>> {
>>>>> uint32_t bar;
>>>>> if (moo) {
>>>>> while (TIME_VAL-t0 < dt);
>>>>> bar = 0.42 * arg - 11.3;
>>>>> } else {
>>>>> bar = 0.43 * arg + 11.7;
>>>>> }
>>>>> ACTION_REG = bar;
>>>>> }
>>>>
>>>> That is of course an allowed re-ordering of the code. A nice
>>>> reminder for us all to be careful and aware of such things.
>>>>
>>>>> so calculation of bar indeed takes few uSec and that's the reason
>>>>> why code was structured to do it outside of time-critical section.
>>>>
>>>> As I think has been commented recently here, C can be forced to
>>>> obey the source-code order by good use of "volatile". Making "bar"
>>>> volatile should have solved this problem.
>>>
>>> Generally speaking, it's only correct if bar is external to the
>>> module.
>>
>> If 'bar' were extern rather than auto that might change the order
>> of code produced, but the comment about making 'bar' volatile is
>> right: if 'bar' were declared volatile then the while() loop
>> must not be moved to execute before the assignment to 'bar'.
>
> Are you sure?

Short answer: yes.

More explanation in my followup to a later posting of yours in
this general thread.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Yes, gfortran definitely needs to become better at this. This is an
>easy case, and I am surprised that it cannot do this.

Just to check, I tried to compile this:

#include <stdlib.h>
void foo(float b, float a[], unsigned long n)
{ unsigned long i;
for (i=0; i<n; i++) {
if (i>=n)
abort();
a[i]=a[i]*b;
}
}

with gcc-10.2 -O1, the inner loop became

f: 0f 28 c1 movaps %xmm1,%xmm0
12: f3 0f 59 00 mulss (%rax),%xmm0
16: f3 0f 11 00 movss %xmm0,(%rax)
1a: 48 83 c0 04 add $0x4,%rax
1e: 48 39 d0 cmp %rdx,%rax
21: 75 ec jne f <foo+0xf>

So gcc eliminated the bounds check. Given that gfortran is just a
different front end for gcc, I wonder why this does not happen for
gfortran's bounds checks.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Sunday, October 17, 2021 at 6:49:58 PM UTC+3, Thomas Koenig wrote:
> Michael S <already...@yahoo.com> schrieb:
> >#define TIME_VAL (*(volatile uint32_t*)0x12345608))
> >#define ACTION_REG (*(volatile uint32_t*)0x43215604))
> >
> > extern uint32_t gl_wait0, gl_wait1, gl_wait2;
> > void foo(int moo, uint32_t t0)
> > {
> > uint32_t wait0_clk = gl_wait0 * 0.42;
> > uint32_t wait1_clk = gl_wait1 * 0.42;
> > uint32_t wait2_clk = gl_wait2 * 0.42;
> >
> > while (TIME_VAL-t0 < wait0_clk);
> > if (moo) {
> > ACTION_REG = 142;
> > while (TIME_VAL-t0 < wait1_clk);
> > ACTION_REG = 242;
> > } else {
> > ACTION_REG = 242;
> > while (TIME_VAL-t0 < wait2_clk);
> > ACTION_REG = 142;
> > }
> > }
> >
> > And compiler transformation was like that:
> >
> > void foo(int moo, uint32_t t0)
> > {
> > uint32_t wait0_clk = gl_wait0 * 0.42;
> >
> > while (TIME_VAL-t0 < wait0_clk);
> > if (moo) {
> > ACTION_REG = 142;
> > uint32_t wait1_clk = gl_wait1 * 0.42;
> > while (TIME_VAL-t0 < wait1_clk);
> > ACTION_REG = 242;
> > } else {
> > ACTION_REG = 242;
> > uint32_t wait2_clk = gl_wait2 * 0.42;
> > while (TIME_VAL-t0 < wait2_clk);
> > ACTION_REG = 142;
> > }
> > }
> >
> > Perfectly legal transformation, one can even say - reasonable,
> > but it took original developer by surprise. Even for gray-bearded
> > developer like myself, it took considerable time to start suspecting
> > in the right direction.
> It's not quite clear to me what the problem was.
>
> Did gl_wait1 and gl_wait2 change their values while the first
> while loop was running? If so, declaring them as "extern volatile"
> should have done the trick.

The problem explained in my post that started this sub-thread.
It's about hard real time and avoidance of slow double precision calculation in time-critical section of the code that begins immediately after completion of the first while() loop.

> The problem explained in my post that started this sub-thread.
> It's about hard real time and avoidance of slow double precision calculation
> in time-critical section of the code that begins immediately after
> completion of the first while() loop.

So maybe what the language should offer here is a way for the programmer
to mark a section as time-critical, so the compiler would know not to
move instructions into this section.

At least, IIUC, as a programmer you were quite aware that this is
time-critical, so if the language offered such an annotation it would
have been natural for you to use it, right?

Stefan

On Sunday, October 17, 2021 at 7:28:44 PM UTC+3, Stefan Monnier wrote:
> > The problem explained in my post that started this sub-thread.
> > It's about hard real time and avoidance of slow double precision calculation
> > in time-critical section of the code that begins immediately after
> > completion of the first while() loop.
> So maybe what the language should offer here is a way for the programmer
> to mark a section as time-critical, so the compiler would know not to
> move instructions into this section.
>
> At least, IIUC, as a programmer you were quite aware that this is
> time-critical, so if the language offered such an annotation it would
> have been natural for you to use it, right?
>
>
> Stefan

May be.
I didn't try to think about solutions. I only wanted, on request of Stephen Fuld, to illustrate with real-life example the omission in C language (and not only C) that was mentioned earlier by David Brown.

On 17/10/2021 16:40, Victor Yodaiken wrote:
> On Sunday, October 17, 2021 at 6:39:07 AM UTC-5, David Brown wrote:
>
>> I want to be able to say "do this calculation /now/, not just some time
>> between when you have the inputs ready and need the output". C has no
>> such concept. You can order memory accesses by using "volatile", but
>> that does not affect any other kind of operation or calculation, or
>> ordering of non-volatile memory accesses. So if I want to push all
>> non-critical work outside of a critical section, C can't give me that.
>> This is a real problem:
>
> Agreed. The Standard says statements should be executed in order unless
> otherwise "indicated", but this seems to be a dead letter. In fact the now optional
> (and always awful) threads component allows for arbitrary compiler movements
> of statements
> within synchronization blocks. This standards language was not properly edited when
> the concurrency/thread stuff became optional and both WG14 and gcc/clang
> seem to believe that they can ignore statement order pretty much everywhere.

The compiler has always been able to re-organise things like that. As
Tim said in a post, execution order is specified for the C abstract
machine, but there only needs to be synchronisation between the C
abstract machine and the real target system at points of "observable
behaviour".

And IMHO, that is fine - in general, I /want/ the compiler to be able to
re-organise a lot. Sure, it can be a pain in debugging or when
examining generated assembly code, but that's part of life as a
programmer. I'd like, on a few rare occasions, to be able to give the
compiler firmer commands here - but /only/ on those rare occasions.

>
>> I would like to be able to tell the compiler "x is between 1 and 3 here
>> - optimise using that knowledge, and ignore the possibility that it is
>> outside that range". Again, I can do a lot of this in gcc - using
>> __builtin_unreachable() to indicate undefined behaviour. (Yes, I am
>> /adding/ undefined behaviour to improve my code.)
>
> Good example of how the concept of undefined has become too much of the hammer used
> on every problem.

I don't understand you here.

If I tell the compiler "assume x is between 1 and 3", what do you think
should happen if it is /not/ in that range?

Perhaps I have code:

if ((x < 1) || (x > 3)) __builtin_unreachable();
y = z / x;

and this is on a target with very expensive division. The compiler
could turn "y = z / x;" into :

if (x == 1) {
y = 1;
} else if (x == 2) {
y = z / 2;
} else {
y = z / 3;
}

and then convert those divide by constants into shifts, multiply by
reciprocals, etc.

If I attempt to run it with an invalid "x", what will be the result?.
It could be "z / 3", it could be an overflow, or it could be something
entirely different and unpredictable, depending on how the compiler
actually manipulated the code. It could even be "z / x". There is no
defined behaviour for the code - it is /undefined/ behaviour. But
that's fine - I told the compiler this is never going to happen, and it
can rely on that promise.

UB is not a "hammer for every problem" - it is a useful tool in the
toolbox. It just seems to be a bit too difficult for some people to
understand, or too dangerous for some programmers to use without
injuring themselves.

>
>> Some of the things I would like could be done by standardising things
>> that can be expressed with gcc. Other things, I have no good idea of
>> how they could be handled.
>>
>> But what I /can/ say is that I think these things would be a lot more
>> useful for low-level code, OS's, and the like, than making signed
>> integer overflow wrap, or disabling TBAA.
>
> This depends on what you are doing. For OS "in the large"
> those things are more of a problem.
>
> #include <bigdatastructureT.h>
>
> f(T* x){
> // T.i is signed int, but work unsigned to allow modular arithmetic
> unsigned int *i = (unsigned int *)&T->i;
> *i += read_sensor();
> ....
> }
>
> and then to find out at some much later time that someone changed T.i to a long
> and the optimizer has silently deleted the assignment.

I'll agree that is a risk of casts. (It would still be wrong even if
the assignment were not deleted, if "int" and "long" are different sizes.)

> What I want here is for the compiler to WARN me there is a possible type error and
> not for the compiler to silently "optimize" it .

If you need to support such possible changes, there are plenty of ways
to do this safely - but they require more effort. For example, you
could use _Generic, or switch to C++ and use templates, to make a
"wrapping increment" operation that works for any size of signed
integer. You can have static assertions to check sizes. You can use
coding conventions, typedefs, or development strategies that avoid the
possibility of the changes. C is not an inherently "safe" language - it
needs help from the programmer. (And making signed integer overflow
wrapping would certainly /not/ help.)

And yes, more and better compiler warnings or static error detection is
almost always a good thing, and I'd like a check that caught such a
mistake - if such a check is possible without too many false positives.

Oh, and it's always better to have good software designers and code
reviews, helping to stop you doing silly things or making silly
requirements - such as wanting to have wrapping behaviour for adding up
sensor readings, rather than having a sensible design that won't
overflow and won't give you meaningless values. It's extremely rare
that wrapping behaviour is actually correct.

>
> or
> if ( ptr < &stack[0])stackoverflow();
>
> OOPS! That comparison is UB and whole statement can be silently deleted
>

Note that the compiler cannot (and will not) remove this statement
unless it /knows/ that the pointer cannot possibly point to something in
the stack. And if the compiler knows that, then the programmer should
probably know that too - in which case the whole thing is another
example of silly code where the fault lies with the software design.
(This happens a /lot/ when people write stuff with undefined behaviour -
it's not so often that the programmer has misunderstood some subtleties
of the C standards. More often, the programmer is writing code that
doesn't really make sense, or alternatively they are writing smart-arse
code instead of smart code.)

> or ....
>
>
>
> Linux has 30million some lines of code (God save us), it's going to have very different problems than
> a device driver or microcontroller code. Many UB ill effects come from the inevitable problems
> of a huge, old, codebase touched by many different people, few of whom have much visibility
> into the larger system.
>

Yes. So the main solution here involves a lot of code review, a lot of
testing, a lot of static checking, and a lot of specifically written
tools and checks - which is exactly what they have done. And as a
backup for reducing the consequences for certain types of code errors
that haven't yet been found, they specify a few extra semantics added to
the C language - such as you get using "gcc -fno-strict-aliasing".

That's fine - the code is not remotely portable to other compilers
anyway (even to closely compatible tools like clang and icc - though
progress is being made here).

That doesn't mean it is a good idea to change the C standards - nor does
it mean that the OS /needs/ to have these extra semantics from those
extra flags.

On 17/10/2021 17:10, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>
>> I want to be able to say "do this calculation /now/, not just some time
>> between when you have the inputs ready and need the output". C has no
>> such concept. You can order memory accesses by using "volatile", but
>> that does not affect any other kind of operation or calculation, or
>> ordering of non-volatile memory accesses. So if I want to push all
>> non-critical work outside of a critical section, C can't give me that.
>> This is a real problem:
>>
>> <https://www.nongnu.org/avr-libc/user-manual/optimization.html>
>
> For the particular problem described there,
>
> #define cli() __asm volatile( "cli" ::: "memory" )
> #define sei() __asm volatile( "sei" ::: "memory" )
> unsigned int ivar;
> void test2( unsigned int val )
> {
> val = 65535U / val;
> cli();
> ivar = val;
> sei();
> }
>
> it should be possible to write a version for cli which has a
> register operand. What about (x86 assembly here)
>
> #define cli_reg(var) __asm volatile ( "cli" :"=r" (var): "r" (var) :)
> #define sti() __asm volatile( "sti" ::: "memory" )
> unsigned int ivar;
> void test2( unsigned int val )
> {
> val = 65535U / val;
> cli_reg (val);
> ivar = val;
> sti();
> }
>
> By declaring val as both input and output, and being a register,
> gcc generates for me
>
> 000000000000000 <test2>:
> 0: 31 d2 xor %edx,%edx
> 2: b8 ff ff 00 00 mov $0xffff,%eax
> 7: f7 f7 div %edi
> 9: fa cli
> a: 89 05 00 00 00 00 mov %eax,0x0(%rip) # 10 <test2+0x10>
> 10: fb sti
> 11: c3 ret
>
> which has the cli/sti pair right where you want it.
>

That is (approximately) the way I solve such things. But rather than
tying the extra inline assembly dependency to the "cli" instruction, I
have it as a general macro:

// Ensure that "val" has been calculated before next volatile access
// by requiring it as an assembly input. Note that only volatiles are
// ordered!
#define forceDependency(val) \
asm volatile("" :: "" (val) : )

A lot of the inline assembly I use doesn't seem to have any assembly code!

Niklas Holsti wrote:
> On 2021-10-16 20:49, Thomas Koenig wrote:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>> [bounds checking]
>>>> There are languages where the necessary info is provided, Ada
>>>> and Fortran among them. However, that there is a rather large
>>>> overhead in code size and, more importantly, execution time.
>>>
>>> Please support your claim with empirical results.
>>
>> $ cat mm.f90
>> module mm
>> implicit none
>> contains
>> subroutine do_mm (a,b,c)
>> real, dimension(:,:), intent(in) :: a, b
>> real, dimension(:,:), intent(out) :: c
>
>
> (Btw, shouldn't C be "in out"? I got a correct warning from GNAT when I
> made it just "in".)
>
>
>> integer :: i, j, k
>> do j=1, size(b,2)
>> do k=1, size(a,2)
>> do i=1, size(a,1)
>> c(i,j) = c(i,j) + a(i,k) * b(k,j)
>> end do
>> end do
>> end do
>> end subroutine do_mm
>> end module mm
>>
>> $ cat main.f90
>> program main
>> use mm
>> implicit none
>> real, dimension(:,:), allocatable :: a, b, c
>> character (len=20) :: line
>> real :: t1, t2
>> allocate (a(1000,1000), b(1000,1000), c(1000,1000))
>> call random_number (a)
>> call random_number (b)
>> call cpu_time (t1)
>> call do_mm(a,b,c)
>> call cpu_time (t2)
>> write (unit=line,fmt=*) c(1,1)
>> write (*,*) t2-t1
>> end program main
>> $ gfortran -O3 mm.f90 main.f90
>> $ ./a.out
>> 9.59559977E-02
>> $ gfortran -fcheck=bounds -O3 mm.f90 main.f90
>> $ ./a.out
>> 0.563069999
>>
>> Is a factor of 5.8 significant enough for you?
>
>
> With Ada/GNAT -O2 on a small MacBook Air, I found no significant
> slow-down from all checks suppressed (-gnatp) to checks on (-gnato),
> compared to the standard deviation in 10 test executions of each case.
> This is a bit surprising, but nice (if true). The program did steadily
> use close to 100% of a processor core, so it seems there was scant
> interference from other jobs. The absolute times are all larger than in
> the Fortran case, above, but of course the computers are different too.
>
> Program follows. Note that I added some preconditions to Do_MM, on the
> sanity of the matrix index ranges. However, these seem to have no
> significant effect on the execution time, whether checks are enabled or
> suppressed.
>
> $ cat mm.ads
>
> package MM is
>
> type Matrix is array (Positive range <>, Positive range <>) of Float;
>
> procedure Randomize (M : out Matrix);
>
> procedure Do_MM (A, B : in Matrix; C : in out Matrix)
> with Pre =>
> A'First(2) = B'First(1)
> and A'Last (2) = B'Last (1)
> and C'First(1) = A'First(1)
> and C'Last (1) = A'Last (1)
> and C'First(2) = B'First(2)
> and C'Last (2) = B'Last (2);
>
> end MM;
>
>
> $ cat mm.adb
> with Ada.Numerics.Float_Random;
>
> package body MM is
>
> procedure Randomize (M : out Matrix)
> is
> use Ada.Numerics.Float_Random;
> Gen : Generator;
> begin
> Reset (Gen);
> for I in M'Range(1) loop
> for J in M'Range(2) loop
> M(I,J) := Random (Gen);
> end loop;
> end loop;
> end Randomize;
>
>
> procedure Do_MM (A, B : in Matrix; C : in out Matrix)
> is
> begin
> for J in B'Range(2) loop
> for K in A'Range(2) loop
> for I in A'Range(1) loop
> C(I,J) := C(I,J) + A(I,K) * B(K,J);
> end loop;
> end loop;
> end loop;
> end Do_MM;
>
> end MM;
>
>
> $ cat main.adb
> with Ada.Real_Time;
> with Ada.Text_IO;
>
> with MM;
>
> procedure Main
> is
> use Ada.Real_Time;
> type Matrix_Ref is access MM.Matrix;
> A, B, C : Matrix_Ref := new MM.Matrix (1 .. 1000, 1 .. 1000);
> T1, T2: Time with Volatile;
>
> begin
>
> MM.Randomize (A.all);
> MM.Randomize (B.all);
> MM.Randomize (C.all);
>
> T1 := Clock;
> MM.Do_MM (A.all, B.all, C.all);
> T2 := Clock;
>
> Ada.Text_IO.Put_Line (Duration'Image (
> To_Duration (T2 - T1)));
>
> end Main;

Remember that Fortran is column major array indexing, Ada is row major.

It might improve the optimization because that makes the all array
accesses sequential and strength reduction of the loop induction
variables hopefully replaces array indexing with ptr++.

I tried to compile this on Godbolt but gnat seems to be hardwired
that specs go in files with extension "ads" and bodies with "adb"
and there is no way to override it. Gnat won't accept a spec in the
file with adb and won't compile a body without its spec.
There is no such file naming restriction in the Ada language
and no reason for there to be in a compiler.

On 2021-10-17 21:14, EricP wrote:
> Niklas Holsti wrote:
>> On 2021-10-16 20:49, Thomas Koenig wrote:
>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>> [bounds checking]
>>>>> There are languages where the necessary info is provided, Ada
>>>>> and Fortran among them.  However, that there is a rather large
>>>>> overhead in code size and, more importantly, execution time.
>>>>
>>>> Please support your claim with empirical results.
>>>
>>> $ cat mm.f90
>>> module mm
>>>    implicit none
>>> contains
>>>    subroutine do_mm (a,b,c)
>>>      real, dimension(:,:), intent(in) :: a, b
>>>      real, dimension(:,:), intent(out) :: c
>>
>>
>> (Btw, shouldn't C be "in out"? I got a correct warning from GNAT when
>> I made it just "in".)
>>
>>
>>>      integer :: i, j, k
>>>      do j=1, size(b,2)
>>>         do k=1, size(a,2)
>>>            do i=1, size(a,1)
>>>               c(i,j) = c(i,j) + a(i,k) * b(k,j)
>>>            end do
>>>         end do
>>>      end do
>>>    end subroutine do_mm
>>> end module mm
>>>
>>> $ cat main.f90
>>> program main
>>>    use mm
>>>    implicit none
>>>    real, dimension(:,:), allocatable :: a, b, c
>>>    character (len=20) :: line
>>>    real :: t1, t2
>>>    allocate (a(1000,1000), b(1000,1000), c(1000,1000))
>>>    call random_number (a)
>>>    call random_number (b)
>>>    call cpu_time (t1)
>>>    call do_mm(a,b,c)
>>>    call cpu_time (t2)
>>>    write (unit=line,fmt=*) c(1,1)
>>>    write (*,*) t2-t1
>>> end program main
>>> $ gfortran -O3 mm.f90  main.f90
>>> $ ./a.out
>>>     9.59559977E-02
>>> $ gfortran -fcheck=bounds -O3 mm.f90  main.f90
>>> $ ./a.out
>>>    0.563069999
>>>
>>> Is a factor of 5.8 significant enough for you?
>>
>>
>> With Ada/GNAT -O2 on a small MacBook Air, I found no significant
>> slow-down from all checks suppressed (-gnatp) to checks on (-gnato),
>> compared to the standard deviation in 10 test executions of each case.

[snip]

> Remember that Fortran is column major array indexing, Ada is row major.
>
> It might improve the optimization because that makes the all array
> accesses sequential and strength reduction of the loop induction
> variables hopefully replaces array indexing with ptr++.

I'll try the Fortran order and report back.

> I tried to compile this on Godbolt but gnat seems to be hardwired
> that specs go in files with extension "ads" and bodies with "adb"
> and there is no way to override it.

That is a convention that makes normal ad-hoc use of GNAT very easy,
compared to earlier Ada compilers which did not use a "source-based
library" scheme as GNAT does.

The convention can be overridden - see chapter 10 in
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_ugn.pdf. But Godbolt may
not let you do that.

Here is a single-file version of the program (where I also simplified
the random initialization a bit). Interestingly, with this version I do
get a significant slow-down with checks enabled (-gnato) as compared to
checks suppressed (-gnatp), with about 11% increase in execution time
when checks are enabled. Perhaps the compiler in-lines code in this
version since it can see that MM.Do_MM is called only in one place.

$ cat main_mm.adb

with Ada.Numerics.Float_Random;
with Ada.Real_Time;
with Ada.Text_IO;

procedure Main_MM
is

package MM is

type Matrix is array (Positive range <>, Positive range <>) of Float;

procedure Randomize (M : out Matrix);

procedure Do_MM (A, B : in Matrix; C : in out Matrix)
with Pre =>
A'First(2) = B'First(1)
and A'Last (2) = B'Last (1)
and C'First(1) = A'First(1)
and C'Last (1) = A'Last (1)
and C'First(2) = B'First(2)
and C'Last (2) = B'Last (2);

end MM;

package body MM is

procedure Randomize (M : out Matrix)
is
use Ada.Numerics.Float_Random;
Gen : Generator;
begin
Reset (Gen);
for E of M loop
E := Random (Gen);
end loop;
end Randomize;

procedure Do_MM (A, B : in Matrix; C : in out Matrix)
is
begin
for J in B'Range(2) loop
for K in A'Range(2) loop
for I in A'Range(1) loop
C(I,J) := C(I,J) + A(I,K) * B(K,J);
end loop;
end loop;
end loop;
end Do_MM;

end MM;

use Ada.Real_Time;

type Matrix_Ref is access MM.Matrix;

A, B, C : Matrix_Ref := new MM.Matrix (1 .. 1000, 1 .. 1000);

T1, T2: Time with Volatile;

begin

MM.Randomize (A.all);
MM.Randomize (B.all);
MM.Randomize (C.all);

T1 := Clock;
MM.Do_MM (A.all, B.all, C.all);
T2 := Clock;

Ada.Text_IO.Put_Line (Duration'Image (To_Duration (T2 - T1)));

end Main_MM;

On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:
> On 17/10/2021 16:40, Victor Yodaiken wrote:
> > On Sunday, October 17, 2021 at 6:39:07 AM UTC-5, David Brown wrote:
> >
> >> I want to be able to say "do this calculation /now/, not just some time
> >> between when you have the inputs ready and need the output". C has no
> >> such concept. You can order memory accesses by using "volatile", but
> >> that does not affect any other kind of operation or calculation, or
> >> ordering of non-volatile memory accesses. So if I want to push all
> >> non-critical work outside of a critical section, C can't give me that.
> >> This is a real problem:
> >
> > Agreed. The Standard says statements should be executed in order unless
> > otherwise "indicated", but this seems to be a dead letter. In fact the now optional
> > (and always awful) threads component allows for arbitrary compiler movements
> > of statements
> > within synchronization blocks. This standards language was not properly edited when
> > the concurrency/thread stuff became optional and both WG14 and gcc/clang
> > seem to believe that they can ignore statement order pretty much everywhere.
> The compiler has always been able to re-organise things like that. As
> Tim said in a post, execution order is specified for the C abstract
> machine, but there only needs to be synchronisation between the C
> abstract machine and the real target system at points of "observable
> behaviour".

As far as I can tall, that is not in the text of the standard at all.

>
> And IMHO, that is fine - in general, I /want/ the compiler to be able to
> re-organise a lot. Sure, it can be a pain in debugging or when
> examining generated assembly code, but that's part of life as a
> programmer. I'd like, on a few rare occasions, to be able to give the
> compiler firmer commands here - but /only/ on those rare occasions.
> >
> >> I would like to be able to tell the compiler "x is between 1 and 3 here
> >> - optimise using that knowledge, and ignore the possibility that it is
> >> outside that range". Again, I can do a lot of this in gcc - using
> >> __builtin_unreachable() to indicate undefined behaviour. (Yes, I am
> >> /adding/ undefined behaviour to improve my code.)
> >
> > Good example of how the concept of undefined has become too much of the hammer used
> > on every problem.
> I don't understand you here.
>
> If I tell the compiler "assume x is between 1 and 3", what do you think
> should happen if it is /not/ in that range?
>
> Perhaps I have code:
>
> if ((x < 1) || (x > 3)) __builtin_unreachable();
> y = z / x;
>
> and this is on a target with very expensive division. The compiler
> could turn "y = z / x;" into :
>
> if (x == 1) {
> y = 1;
> } else if (x == 2) {
> y = z / 2;
> } else {
> y = z / 3;
> }

Which you could easily do yourself without any assistance from the compiler

> and then convert those divide by constants into shifts, multiply by
> reciprocals, etc.
>

And this is something the compiler should do, but there is no need to
invoke UB.

> If I attempt to run it with an invalid "x", what will be the result?.
> It could be "z / 3", it could be an overflow, or it could be something
> entirely different and unpredictable, depending on how the compiler
> actually manipulated the code. It could even be "z / x". There is no
> defined behaviour for the code - it is /undefined/ behaviour. But
> that's fine - I told the compiler this is never going to happen, and it
> can rely on that promise.

Fine. But your gain here is minimal. It is the usual case of using UB
to produce trivial optimizations. If it is a performance drag, then
profile and fix it. Otherwise, it's not a problem.

> UB is not a "hammer for every problem" - it is a useful tool in the
> toolbox. It just seems to be a bit too difficult for some people to
> understand, or too dangerous for some programmers to use without
> injuring themselves.

Not all of us can be as smart as you - if that's your point.

> >
> >> Some of the things I would like could be done by standardising things
> >> that can be expressed with gcc. Other things, I have no good idea of
> >> how they could be handled.
> >>
> >> But what I /can/ say is that I think these things would be a lot more
> >> useful for low-level code, OS's, and the like, than making signed
> >> integer overflow wrap, or disabling TBAA.
> >
> > This depends on what you are doing. For OS "in the large"
> > those things are more of a problem.
> >
> > #include <bigdatastructureT.h>
> >
> > f(T* x){
> > // T.i is signed int, but work unsigned to allow modular arithmetic
> > unsigned int *i = (unsigned int *)&T->i;
> > *i += read_sensor();
> > ....
> > }
> >
> > and then to find out at some much later time that someone changed T.i to a long
> > and the optimizer has silently deleted the assignment.
> I'll agree that is a risk of casts. (It would still be wrong even if
> the assignment were not deleted, if "int" and "long" are different sizes.)
> > What I want here is for the compiler to WARN me there is a possible type error and
> > not for the compiler to silently "optimize" it .
> If you need to support such possible changes, there are plenty of ways
> to do this safely - but they require more effort. For example, you
> could use _Generic, or switch to C++ and use templates, to make a
> "wrapping increment" operation that works for any size of signed
> integer. You can have static assertions to check sizes. You can use
> coding conventions, typedefs, or development strategies that avoid the
> possibility of the changes. C is not an inherently "safe" language - it
> needs help from the programmer. (And making signed integer overflow
> wrapping would certainly /not/ help.)
>

None of that is practical.

> And yes, more and better compiler warnings or static error detection is
> almost always a good thing, and I'd like a check that caught such a
> mistake - if such a check is possible without too many false positives.
>
> Oh, and it's always better to have good software designers and code
> reviews, helping to stop you doing silly things or making silly
> requirements - such as wanting to have wrapping behaviour for adding up
> sensor readings, rather than having a sensible design that won't
> overflow and won't give you meaningless values. It's extremely rare
> that wrapping behaviour is actually correct.

That is 100% incorrect.

there are millions of lines of code that check for overflow the obvious way
where the checks are deleted without fwrapv

and that's just a start.

I don't want the results of arithmetic operations to depend on the optimizer level and
version of the optimizer. Others can have different priorities.

> >
> > or
> > if ( ptr < &stack[0])stackoverflow();
> >
> > OOPS! That comparison is UB and whole statement can be silently deleted
> >
> Note that the compiler cannot (and will not) remove this statement
> unless it /knows/ that the pointer cannot possibly point to something in
> the stack.

That is not correct. if the ptr points before the stack such a comparison
*would be* UB, but since UB is axiomatically impossible, the compiler
can delete the checks as an optimization by replacing (ptr < &stack[0]) with FALSE.

>And if the compiler knows that, then the programmer should
> probably know that too - in which case the whole thing is another
> example of silly code where the fault lies with the software design.
> (This happens a /lot/ when people write stuff with undefined behaviour -
> it's not so often that the programmer has misunderstood some subtleties
> of the C standards.

As you just have.

More often, the programmer is writing code that
> doesn't really make sense, or alternatively they are writing smart-arse
> code instead of smart code.)
> > or ....

As you were saying.

> >
> >
> >
> > Linux has 30million some lines of code (God save us), it's going to have very different problems than
> > a device driver or microcontroller code. Many UB ill effects come from the inevitable problems
> > of a huge, old, codebase touched by many different people, few of whom have much visibility
> > into the larger system.
> >
> Yes. So the main solution here involves a lot of code review, a lot of
> testing, a lot of static checking, and a lot of specifically written
> tools and checks - which is exactly what they have done. And as a
> backup for reducing the consequences for certain types of code errors
> that haven't yet been found, they specify a few extra semantics added to
> the C language - such as you get using "gcc -fno-strict-aliasing".
>
> That's fine - the code is not remotely portable to other compilers
> anyway (even to closely compatible tools like clang and icc - though
> progress is being made here).
>
> That doesn't mean it is a good idea to change the C standards - nor does
> it mean that the OS /needs/ to have these extra semantics from those
> extra flags.

Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
> On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:
>> On 17/10/2021 16:40, Victor Yodaiken wrote:
>> > On Sunday, October 17, 2021 at 6:39:07 AM UTC-5, David Brown wrote:
>> >
>> >> I want to be able to say "do this calculation /now/, not just some time
>> >> between when you have the inputs ready and need the output". C has no
>> >> such concept. You can order memory accesses by using "volatile", but
>> >> that does not affect any other kind of operation or calculation, or
>> >> ordering of non-volatile memory accesses. So if I want to push all
>> >> non-critical work outside of a critical section, C can't give me that.
>> >> This is a real problem:
>> >
>> > Agreed. The Standard says statements should be executed in order unless
>> > otherwise "indicated", but this seems to be a dead letter. In fact the now optional
>> > (and always awful) threads component allows for arbitrary compiler movements
>> > of statements
>> > within synchronization blocks. This standards language was not properly edited when
>> > the concurrency/thread stuff became optional and both WG14 and gcc/clang
>> > seem to believe that they can ignore statement order pretty much everywhere.
>> The compiler has always been able to re-organise things like that. As
>> Tim said in a post, execution order is specified for the C abstract
>> machine, but there only needs to be synchronisation between the C
>> abstract machine and the real target system at points of "observable
>> behaviour".
>
>
> As far as I can tall, that is not in the text of the standard at all.

5.1.2.3 Program execution

The least requirements on a conforming implementation are:

— Volatile accesses to objects are evaluated strictly according
to the rules of the abstract machine.

— At program termination, all data written into files shall be
identical to the result that execution of the program according
to the abstract semantics would have produced.

— The input and output dynamics of interactive devices shall take
place as specified in 7.21.3. The intent of these requirements
is that unbuffered or line-buffered output appear as soon as
possible, to ensure that prompting messages actually appear prior
to a program waiting for input.

This is the _observable behavior_ of the program.

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>> The problem explained in my post that started this sub-thread.
>> It's about hard real time and avoidance of slow double precision calculation
>> in time-critical section of the code that begins immediately after
>> completion of the first while() loop.
>
> So maybe what the language should offer here is a way for the programmer
> to mark a section as time-critical, so the compiler would know not to
> move instructions into this section.

Fortran offers SYNC MEMORY for something like that.

On 15/10/2021 17:03, Victor Yodaiken wrote:
> On Friday, October 15, 2021 at 4:32:55 AM UTC-5, David Brown wrote:
>> On 14/10/2021 20:20, Victor Yodaiken wrote:
>>> "Undefined behavior" does not mean "programming error" and never
>>> has. One meaning is just something not specified explicitly in the
>>> standard.
>> "Undefined behaviour" in the C standard means the C standard does not
>> define the behaviour. It really is that simple.
>>
>
> Correct. And in this discussion, "undefined behavior" is usually being used to mean
> "undefined behavior modulo the ISO C standard". My first point was that it is
> fundamentally incorrect to identify undefined behavior in that sense as a
> C-Standard programming error.

I disagree that this discussion has been solely about code whose
behaviour is undefined in the C standard (let's call that CSUB to save
space). But I /do/ agree that relying on the effect of CSUB is not
necessarily a programming error - as long as the behaviour is defined
elsewhere (compiler manual, platform ABI, etc.). /True/ undefined
behaviour (TUB) would mean the behaviour is not defined or described
anywhere for the compiler, target and flags you are using, and expecting
that to do something useful, safe or reliable /is/ a programming error.

> The C Standard only says that the behavior is not defined
> by the C Standard and much of what is in C programs qualifies as undefined. The
> obvious examples are most system calls, POSIX libraries, interactions with devices,
> intrinsics, etc.
>

Agreed.

> My second point is that that the C standard, at the very least, does not require
> compilers to use C Standard undefined behavior as opportunity for "optimization"
> or program error or similar.

The C standard makes /very/ few requirements about how the compiler
should implement anything. It leaves the C compiler free to implement
multiplication by repeated addition, and division by a trial-and-error
loop of guessing the result then checking it. CSUB gives no
requirements whatsoever - that is what the phrase means. It would be
truly bizarre for the C standards to leave everything else regarding
code efficiency and quality up to the implementation, yet insist that
the compiler optimise in regard to things the C standard does not cover
or describe.

> In fact,
> the current interpretation of the standard delegates UB entirely to the compiler.
> So compilers are free to leave the semantics of pointer comparison, signed
> arithmetic, shifts,etc. to the processor architecture. The decision to pick "UB optimization"
> over "processor semantics" on those issues is an engineering decision, not a matter
> of compliance with the standard.

I suppose you are correct, in the same sense that my choice of font size
in my newsreader program is compliant with the tax laws in Argentina.

The C standard says it does not describe, specify, or care about what
happens when the code attempts to do something it considers meaningless,
nor does it specify what happens when it hasn't specified a result (CSUB
by omission). It abdicates all responsibility - the C standard is
irrelevant for any effect or treatment of code with CSUB. Discussing
"compliance with the standard" in that context has no relevance.

> It is clearly the intention of at least some of the
> WG14 that compilers make the decision to "optimize" on UB but it is an intention, not
> a requirement.

If that was "clear", it would have been in the standard. To me, it is
clear that the intention of the WG14 is that in the C language, UB is UB
and there is /no/ implication about what anyone or anything should do
about it.

> I think the compilers have made a bad decision that makes C less useful
> and probably dooms the language to irrelevance (which doesn't necessarily matter for a
> compiler that is increasingly focused on other languages). But it is impossible to even discuss the
> merits of that decision as long as we get these legalistic claims that there is no alternative.
>

Well, you can have that opinion if you like. It would be an odd idea,
given how popular and useful C remains after all these years. Perhaps
you are new to this game? Maybe you think "optimising on the assumption
that UB does not occur" is a new concept? Maybe, like some, you think
it is a gcc-specific idea? I believe the first time I remember using a
powerful optimising complier was around 25 years ago, and it was not gcc
- but it did TBAA (and yes, that confused me the first time I saw it),
and it did some optimisations on the assumption that signed integer
arithmetic never overflows.

> ( On this point, Chris Lattner's discussion of how C-Standard UB has produced what
> he called a "terrifying" situation ends with a proposed solution: replace C with Swift)
>

There are good reasons for making and using languages that are defined
differently from C. I can't tell you whether Swift (or Rust, the other
popular alternative) is "better" than C for any given use - I don't know
those languages. I could certainly give a long list of things that I
think are not ideal in C, or that I would have preferred to be different
- so could any experienced C user. Such lists would have some overlap
and a lot of differences.

I would also say that a large proportion of code that is today written
in C would be better written in other languages, and a large proportion
of today's C programmers would do better in other languages.

>> The C standard provides /part/ of the description of how a particular
>> piece of C source code will act when you run the final binary. The
>> documentation (in theory - though we all know how bad software
>> documentation can be!) for the C compiler provides additional semantics
>> covering everything that the C standard describes as
>> "implementation-dependent".
>
> This is confusing, but people need to be clear about it. UB (C-Standard UB) and
> implementation dependent (C Standard) are different things.

I fully agree. And a lot of C programmers don't understand that well
enough.

>
>> But once you have taken all these things into account, if your program
>> attempts to execute something whose behaviour is not defined, then it
>> /is/ a programming error.
>
> Again, it is important to be clear about terminology. A call to pthread_create
> may be UB (C-standard) but perfectly well defined for gcc because gcc
> implements POSIX. And what is UB (C-Standard) is defined, by necessity,
> by gcc/clang in some way, whether documented or whether it makes sense or not.
>

gcc does not "implement POSIX" in any sense.

The effects of a call to pthread_create are CSUB, though the call itself
is not. The effects are also unknown to gcc. But because the compiler
knows nothing about what happens inside the call, it must assume that
the behaviour /is/ defined and pass on all the arguments as specified by
the C standards and the platform ABI. It does this even though the call
to pthread_create may actually be UB - for example, the POSIX standards
do not (AFAIK) define what happens if you pass a "start_routine" pointer
that is not appropriately aligned for the cpu in use. Making such a TUB
call would, of course, be a programmer error.

>> So - not all things that are undefined behaviour in the C standard are
>> programming errors. But executing code whose behaviour is not defined
>> anywhere in the execution environment, /is/ a programming error.
>>
>
> I don't know what that would mean. Everything is defined somewhere, whether as an error
> or not is something else.
>

No, it is not. The result of a signed integer arithmetic overflow in C
code is not defined anywhere, on most implementations (an
"implementation" being roughly a compiler, target, flags, library
combination).

You might /think/ that it is defined by the cpu instructions, but it is
not - because the C code is not defined in terms of those instructions.

>
>> You misunderstand. You cannot write a useful C program that does not
>> rely on behaviour that is undefined by the C standard.
>
> I this context, I was talking about C-Standard UB, not something wider. Given that, I guess we
> agree.
>

(I've tried to use CSUB and TUB in this post - many posts here would
have been clearer if we had been more careful about the distinction.)

>
>>> The theory that undefined behavior can be treated as impossible has
>>> very little basis in the C standard text. It is a compiler
>>> implementation innovation.
>> The C standard says it imposes /no/ restrictions on how it is treated.
>> A compiler that considers it as impossible is entirely acceptable based
>> on the standard
>
> I doubt this, but I am confident that debating the meaning of the standard on this
> point is not a useful exercise.
>
>

David Brown <david.brown@hesbynett.no> schrieb:
> On 17/10/2021 17:10, Thomas Koenig wrote:
>> David Brown <david.brown@hesbynett.no> schrieb:
>>
>>> I want to be able to say "do this calculation /now/, not just some time
>>> between when you have the inputs ready and need the output". C has no
>>> such concept. You can order memory accesses by using "volatile", but
>>> that does not affect any other kind of operation or calculation, or
>>> ordering of non-volatile memory accesses. So if I want to push all
>>> non-critical work outside of a critical section, C can't give me that.
>>> This is a real problem:
>>>
>>> <https://www.nongnu.org/avr-libc/user-manual/optimization.html>
>>
>> For the particular problem described there,
>>
>> #define cli() __asm volatile( "cli" ::: "memory" )
>> #define sei() __asm volatile( "sei" ::: "memory" )
>> unsigned int ivar;
>> void test2( unsigned int val )
>> {
>> val = 65535U / val;
>> cli();
>> ivar = val;
>> sei();
>> }
>>
>> it should be possible to write a version for cli which has a
>> register operand. What about (x86 assembly here)
>>
>> #define cli_reg(var) __asm volatile ( "cli" :"=r" (var): "r" (var) :)
>> #define sti() __asm volatile( "sti" ::: "memory" )
>> unsigned int ivar;
>> void test2( unsigned int val )
>> {
>> val = 65535U / val;
>> cli_reg (val);
>> ivar = val;
>> sti();
>> }
>>
>> By declaring val as both input and output, and being a register,
>> gcc generates for me
>>
>> 000000000000000 <test2>:
>> 0: 31 d2 xor %edx,%edx
>> 2: b8 ff ff 00 00 mov $0xffff,%eax
>> 7: f7 f7 div %edi
>> 9: fa cli
>> a: 89 05 00 00 00 00 mov %eax,0x0(%rip) # 10 <test2+0x10>
>> 10: fb sti
>> 11: c3 ret
>>
>> which has the cli/sti pair right where you want it.
>>
>
> That is (approximately) the way I solve such things. But rather than
> tying the extra inline assembly dependency to the "cli" instruction, I
> have it as a general macro:
>
> // Ensure that "val" has been calculated before next volatile access
> // by requiring it as an assembly input. Note that only volatiles are
> // ordered!
>#define forceDependency(val) \
> asm volatile("" :: "" (val) : )

Does this work for all cases?

In the example above, I found that the mov was still moved around
unless I included the variable both as an input and as an output
operand.

(It might also generate more efficient code to specify this as
a register, but I'm not sure about that).

On 16/10/2021 16:53, Ivan Godard wrote:
> On 10/16/2021 7:39 AM, David Brown wrote:

>>
>> Perhaps an interesting topic might be a look at how an ISA could be made
>> that worked better with UB (in C or other languages)?  Is there a way to
>> introduce quiet and signalling NaN's to integers in an architecture?
>> Could a concept of UB, or unspecified values, be efficiently included in
>> a CPU - and could it even allow more efficient operation?  Could "fat
>> pointers" work well to catch UB and bugs early?
>>
>> I think maybe there's scope for a new thread on those lines.
>>
>
> You mean Mill NaRs?

Could be. I am afraid I haven't followed much about your Mill here. It
sounds very interesting, but I haven't had the time to look at it. But
if you have a way of marking registers or data as invalid and trapping
on attempts to use it, then that could definitely be a useful aid in
finding bugs in code.

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> What does such a test look like in a lnaguage like Java where bounds
> checking is always enabled, and hence where the motivation to perform
> such optimizations might be higher?

It's a simple thing that mostly falls out of other optimizations. We
first try to find counted loops of the form

for (i = start; i < limit; i += step)

so we then know that (i <= start < limit). All instances of a[i] in a
are of the form

if (i >= a.length) throw SomeException;
tmp = a[i];

then the check can be hoisted out of the loop

if (limit < a.length) {
for (i = start; i < limit; i += step) {
...
loop version without bounds checks
}
} else {
uncommon trap to slow version

This is only possible because we know that a.length is invariant.

Andrew.

On 17/10/2021 17:39, Tim Rentsch wrote:
> Michael S <already5chosen@yahoo.com> writes:
>
> [.. on code reordering and volatile ..]
>
>
> Here again the surprising code reordering can be prevented by
> making the three local variables volatile.
>
>> Perfectly legal transformation, one can even say - reasonable, but
>> it took original developer by surprise.
>
> I think it would take most developers by surprise. The rules for
> how volatile works exactly are AFAICT not widely known.
>

It surprises me sometimes how poorly they are understood - even amongst
some small-systems embedded programmers, for whom "volatile" is
absolutely essential. (Part of that is that the embedded world used to
have lots of brain-dead 8-bit CISC cpus along with poorly optimising
compilers - you got much the same results with "volatile" as without it.)

The key aspects of "volatile" are not particularly hard to understand,
as long as you restrict yourself to a couple of simple rules.

Volatile reads and writes are never removed or added, and never
re-ordered with respect to each other (or other observable behaviour).

The main thing people get wrong, IME, is that they think volatile
accesses also enforce ordering of non-volatile memory accesses, and
sometimes also of calculations, function calls, and other code.

The second thing they get wrong is thinking "volatile" means "atomic".

And the third thing is thinking that it makes sense to have multiple
volatile accesses in an expression, making assumptions about the
ordering. People often have a poor idea about sequence points and
evaluation order, and the standards give no guidance on how something
like "v1 = v2 + v2;" or "v1 += v2;" should be handled. (C++20 dropped
support for a lot of confusing use of volatiles.)

So rule 1 for getting volatile right is to learn what it /doesn't/ mean.
And rule 2 is to restrict yourself to a single volatile read or a
single volatile write within one statement. (That's stricter than it
need be, but safe and easy to understand.)

It helps a great deal to think in terms of volatile /accesses/, rather
than volatile /objects/, even though that is not what the C standard
says at the moment.

>> Even for gray-bearded developer like myself, it took considerable
>> time to start suspecting in the right direction.
>
> The rules for how volatile works are IMO perhaps the most broken
> part of the C standard. What is allowed isn't clear from the
> wording (one might even say the wording doesn't express it), and
> the consequences are often surprising. So I have to agree your
> complaints have some justification.
>

They are certainly underspecified - it's mostly left to the
implementation. C23 has a significant improvement, however - it
describes volatile in terms of accesses rather than objects. (Under the
discussions for that change, it became apparent that every compiler
known to the committee already treated all volatile accesses in the same
way as accesses to volatile objects, and lots of software relies on
that, but it was good to get it formalised.)

> A rule of thumb for volatile and code reordering: reordering is
> not allowed for two volatile accesses, but reordering is allowed
> to move non-volatile accesses across volatile accesses (assuming
> of course there are no direct dependencies). I don't claim this
> rule is absolutely right but I think it's a good first check.
>

It is correct. If follows simply from the "observable behaviour"
execution model.

> Incidentally, it isn't absolutely necessary to declare the three
> locals as volatile to avoid the unfortunate code reordering.
> That can be done using volatile a bit more selectively:
>
> uint32_t wait0_clk;
> uint32_t wait1_clk;
> uint32_t wait2_clk;
> *(volatile uint32_t*) &wait0_clk = gl_wait0 * 0.42;
> *(volatile uint32_t*) &wait1_clk = gl_wait1 * 0.42;
> *(volatile uint32_t*) &wait2_clk = gl_wait2 * 0.42;
>

Yes, that will work (though as noted above, it is only from C23 that it
is actually guaranteed to work from the standards).

You can also write:

uint32_t wait0_clk = gl_wait0 * 0.42;
uint32_t wait1_clk = gl_wait1 * 0.42;
uint32_t wait2_clk = gl_wait2 * 0.42;

volatile uint32_t v = wait0_clk + wait1_clk + wait2_clk;

That will only require a single volatile access, which is probably more
efficient (despite the extra additions) on many modern platforms.

> Depending on circumstances one or the other of these techniques
> may give better results than the other (or more likely just be
> down in the noise so it wouldn't really matter which one is
> used).
>
> (I have verified the results regarding volatile and code
> reordering under gcc with -O2.)
>

On 18/10/2021 01:47, Victor Yodaiken wrote:
> On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:
>> On 17/10/2021 16:40, Victor Yodaiken wrote:
>>> On Sunday, October 17, 2021 at 6:39:07 AM UTC-5, David Brown wrote:
>>>
>>>> I want to be able to say "do this calculation /now/, not just some time
>>>> between when you have the inputs ready and need the output". C has no
>>>> such concept. You can order memory accesses by using "volatile", but
>>>> that does not affect any other kind of operation or calculation, or
>>>> ordering of non-volatile memory accesses. So if I want to push all
>>>> non-critical work outside of a critical section, C can't give me that.
>>>> This is a real problem:
>>>
>>> Agreed. The Standard says statements should be executed in order unless
>>> otherwise "indicated", but this seems to be a dead letter. In fact the now optional
>>> (and always awful) threads component allows for arbitrary compiler movements
>>> of statements
>>> within synchronization blocks. This standards language was not properly edited when
>>> the concurrency/thread stuff became optional and both WG14 and gcc/clang
>>> seem to believe that they can ignore statement order pretty much everywhere.
>> The compiler has always been able to re-organise things like that. As
>> Tim said in a post, execution order is specified for the C abstract
>> machine, but there only needs to be synchronisation between the C
>> abstract machine and the real target system at points of "observable
>> behaviour".
>
>
> As far as I can tall, that is not in the text of the standard at all.
>

5.1.2.2.1p6, under "Program execution":

"""
6 The least requirements on a conforming implementation are:

— Volatile accesses to objects are evaluated strictly according to the
rules of the abstract machine.

— At program termination, all data written into files shall be identical
to the result that execution of the program according to the abstract
semantics would have produced.

— The input and output dynamics of interactive devices shall take place
as specified in 7.21.3. The intent of these requirements is that
unbuffered or line-buffered output appear as soon as possible, to ensure
that prompting messages actually appear prior to a program waiting for
input.

This is the observable behavior of the program.
"""

>>
>> And IMHO, that is fine - in general, I /want/ the compiler to be able to
>> re-organise a lot. Sure, it can be a pain in debugging or when
>> examining generated assembly code, but that's part of life as a
>> programmer. I'd like, on a few rare occasions, to be able to give the
>> compiler firmer commands here - but /only/ on those rare occasions.
>>>
>>>> I would like to be able to tell the compiler "x is between 1 and 3 here
>>>> - optimise using that knowledge, and ignore the possibility that it is
>>>> outside that range". Again, I can do a lot of this in gcc - using
>>>> __builtin_unreachable() to indicate undefined behaviour. (Yes, I am
>>>> /adding/ undefined behaviour to improve my code.)
>>>
>>> Good example of how the concept of undefined has become too much of the hammer used
>>> on every problem.
>> I don't understand you here.
>>
>> If I tell the compiler "assume x is between 1 and 3", what do you think
>> should happen if it is /not/ in that range?
>>
>> Perhaps I have code:
>>
>> if ((x < 1) || (x > 3)) __builtin_unreachable();
>> y = z / x;
>>
>> and this is on a target with very expensive division. The compiler
>> could turn "y = z / x;" into :
>>
>> if (x == 1) {
>> y = 1;
>> } else if (x == 2) {
>> y = z / 2;
>> } else {
>> y = z / 3;
>> }
>
> Which you could easily do yourself without any assistance from the compiler

I could - but the compiler can also do that kind of thing (I haven't
checked for this particular example). I'd rather spend my time writing
clear, maintainable and flexible code, and let the compiler do its job
of turning that into the smallest and fastest object code. If I had
wanted to micro-manage all the details, I'd write in assembly.

>
>> and then convert those divide by constants into shifts, multiply by
>> reciprocals, etc.
>>
>
> And this is something the compiler should do, but there is no need to
> invoke UB.

No one is "invoking UB" - that, I think, is /your/ phrase. It is useful
for the compiler to know about things that can't happen - whether it is
because it would be UB, or because the programmer tells it that they
can't happen. It amounts to the same thing.

>
>> If I attempt to run it with an invalid "x", what will be the result?.
>> It could be "z / 3", it could be an overflow, or it could be something
>> entirely different and unpredictable, depending on how the compiler
>> actually manipulated the code. It could even be "z / x". There is no
>> defined behaviour for the code - it is /undefined/ behaviour. But
>> that's fine - I told the compiler this is never going to happen, and it
>> can rely on that promise.
>
> Fine. But your gain here is minimal.

No, it is not. And I have used this technique in code where it is not
"minimal" gain - it is /essential/ gain. There are also added benefits
in the documentation of the code, in static error checking in some
cases, and options for run-time checking.

> It is the usual case of using UB
> to produce trivial optimizations. If it is a performance drag, then
> profile and fix it. Otherwise, it's not a problem.
>

I don't need you to tell me what I need in my code, or to make wild
guesses as to what you think makes a difference.

You can make measurements of existing code compiled with and without
optimisations such as TBAA, and use that to get some idea of the general
benefits (or lack thereof) of such optimisations. Usually the
measurements are not particularly helpful because they are done in
environments (such as modern x86 systems) where other effects swamp the
results. And usually the results are given with a misunderstanding of
the point of optimisations.

Modern compilers do /lots/ of optimisations. Some have general effects
that apply to a lot of code. Others have no effect on most code, but
can have a big benefit to particular code constructs. Some have general
but low level effects - a percent here or there, which are little on
their own but add up to something useful when you have 40 such passes.
Some only really come into play if you write code that takes advantage
of them, others can dramatically change the way you can write code.

>
>> UB is not a "hammer for every problem" - it is a useful tool in the
>> toolbox. It just seems to be a bit too difficult for some people to
>> understand, or too dangerous for some programmers to use without
>> injuring themselves.
>
> Not all of us can be as smart as you - if that's your point.
>

A lot of C programmers could do with more training - or perhaps some of
the people doing the training or writing the books could do with a
better understanding of the language. But I don't think UB in general
should be too difficult for a programmer who is qualified to work in C
coding - it is only a problem for a small proportion of programmers. As
a source of bugs in code, it is - I believe - a very minor one.

>
>>>
>>>> Some of the things I would like could be done by standardising things
>>>> that can be expressed with gcc. Other things, I have no good idea of
>>>> how they could be handled.
>>>>
>>>> But what I /can/ say is that I think these things would be a lot more
>>>> useful for low-level code, OS's, and the like, than making signed
>>>> integer overflow wrap, or disabling TBAA.
>>>
>>> This depends on what you are doing. For OS "in the large"
>>> those things are more of a problem.
>>>
>>> #include <bigdatastructureT.h>
>>>
>>> f(T* x){
>>> // T.i is signed int, but work unsigned to allow modular arithmetic
>>> unsigned int *i = (unsigned int *)&T->i;
>>> *i += read_sensor();
>>> ....
>>> }
>>>
>>> and then to find out at some much later time that someone changed T.i to a long
>>> and the optimizer has silently deleted the assignment.
>> I'll agree that is a risk of casts. (It would still be wrong even if
>> the assignment were not deleted, if "int" and "long" are different sizes.)
>>> What I want here is for the compiler to WARN me there is a possible type error and
>>> not for the compiler to silently "optimize" it .
>> If you need to support such possible changes, there are plenty of ways
>> to do this safely - but they require more effort. For example, you
>> could use _Generic, or switch to C++ and use templates, to make a
>> "wrapping increment" operation that works for any size of signed
>> integer. You can have static assertions to check sizes. You can use
>> coding conventions, typedefs, or development strategies that avoid the
>> possibility of the changes. C is not an inherently "safe" language - it
>> needs help from the programmer. (And making signed integer overflow
>> wrapping would certainly /not/ help.)
>>
>
> None of that is practical.

On 10/18/2021 12:56 AM, David Brown wrote:
> On 16/10/2021 16:53, Ivan Godard wrote:
>> On 10/16/2021 7:39 AM, David Brown wrote:
>
>>>
>>> Perhaps an interesting topic might be a look at how an ISA could be made
>>> that worked better with UB (in C or other languages)?  Is there a way to
>>> introduce quiet and signalling NaN's to integers in an architecture?
>>> Could a concept of UB, or unspecified values, be efficiently included in
>>> a CPU - and could it even allow more efficient operation?  Could "fat
>>> pointers" work well to catch UB and bugs early?
>>>
>>> I think maybe there's scope for a new thread on those lines.
>>>
>>
>> You mean Mill NaRs?
>
> Could be. I am afraid I haven't followed much about your Mill here. It
> sounds very interesting, but I haven't had the time to look at it. But
> if you have a way of marking registers or data as invalid and trapping
> on attempts to use it, then that could definitely be a useful aid in
> finding bugs in code.
>

Operands on the belt or during computation (but not in memory) have an
extra bit. They propagate through idempotent instructions like add but
if set will trap when used as an argument to instructions (called
"non-speculable") that irrecoverably change machine state. The most
common examples of non-specs are store and all control flow instructions.

On 18/10/2021 09:40, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>> On 17/10/2021 17:10, Thomas Koenig wrote:
>>> David Brown <david.brown@hesbynett.no> schrieb:
>>>
>>>> I want to be able to say "do this calculation /now/, not just some time
>>>> between when you have the inputs ready and need the output". C has no
>>>> such concept. You can order memory accesses by using "volatile", but
>>>> that does not affect any other kind of operation or calculation, or
>>>> ordering of non-volatile memory accesses. So if I want to push all
>>>> non-critical work outside of a critical section, C can't give me that.
>>>> This is a real problem:
>>>>
>>>> <https://www.nongnu.org/avr-libc/user-manual/optimization.html>
>>>
>>> For the particular problem described there,
>>>
>>> #define cli() __asm volatile( "cli" ::: "memory" )
>>> #define sei() __asm volatile( "sei" ::: "memory" )
>>> unsigned int ivar;
>>> void test2( unsigned int val )
>>> {
>>> val = 65535U / val;
>>> cli();
>>> ivar = val;
>>> sei();
>>> }
>>>
>>> it should be possible to write a version for cli which has a
>>> register operand. What about (x86 assembly here)
>>>
>>> #define cli_reg(var) __asm volatile ( "cli" :"=r" (var): "r" (var) :)
>>> #define sti() __asm volatile( "sti" ::: "memory" )
>>> unsigned int ivar;
>>> void test2( unsigned int val )
>>> {
>>> val = 65535U / val;
>>> cli_reg (val);
>>> ivar = val;
>>> sti();
>>> }
>>>
>>> By declaring val as both input and output, and being a register,
>>> gcc generates for me
>>>
>>> 000000000000000 <test2>:
>>> 0: 31 d2 xor %edx,%edx
>>> 2: b8 ff ff 00 00 mov $0xffff,%eax
>>> 7: f7 f7 div %edi
>>> 9: fa cli
>>> a: 89 05 00 00 00 00 mov %eax,0x0(%rip) # 10 <test2+0x10>
>>> 10: fb sti
>>> 11: c3 ret
>>>
>>> which has the cli/sti pair right where you want it.
>>>
>>
>> That is (approximately) the way I solve such things. But rather than
>> tying the extra inline assembly dependency to the "cli" instruction, I
>> have it as a general macro:
>>
>> // Ensure that "val" has been calculated before next volatile access
>> // by requiring it as an assembly input. Note that only volatiles are
>> // ordered!
>> #define forceDependency(val) \
>> asm volatile("" :: "" (val) : )
>
> Does this work for all cases?
>
> In the example above, I found that the mov was still moved around
> unless I included the variable both as an input and as an output
> operand.

Yes, it works - it tells the compiler that it needs the value "val" as
an input to the empty assembly.

Your solution, on the other hand, is not actually correct - though it is
highly likely to work in most cases. gcc inline assembly is subtle.
(And while I know a lot about it, I don't know everything - it's easy to
get things that work when you test them but might not work everywhere.)

What you have told the compiler is "Calculate val and put it in a
register of your choosing. Allocate another register of your choosing,
which may be the same one or a different one. Do "cli". Put the
contents of this second register into the variable val, optimising away
any extra register moves if you like".

In particular, the compiler could choose a different register for the
input and output registers that you asked it to pick (but don't use).
This would result in the compiler calculating "val" and putting it into
one register, then after "cli" it would use the contents of a different
register as "val".

If you want to force the same register (or memory) for input and ouput,
use the "+g" output constraint:

// Tell the compiler that it no longer knows about "v", without actually
// changing it.
// This can be used to break relationships or ranges that the compiler
// knows due to array information, type-based analysis, etc.
#define forgetCompilerKnowledge(v) \
asm ("" : "+g" (v))

// As forgetCompilerKnowledge, but with a block of memory
#define forgetCompilerBlock(start, size) \
do { typedef struct { char x[size]; } XS; XS *p = (XS *) start; \
asm ("" : "+m" (*p)); \
} while (0);

#define forgetCompilerKnowledgeObj(v) forgetCompilerBlock((void*) &(v),\
sizeof(v))

These are not macros I have often needed. In fact, the only example I
found in any projects I've done recently was as a workaround due to a
suspected gcc compiler bug!

>
> (It might also generate more efficient code to specify this as
> a register, but I'm not sure about that).
>

That is conceivable, but it will typically make no difference on targets
with enough registers. If your target has direct to memory ALU
instructions, or so few registers that the value might be calculated
then stored on the stack before it is later used, then that could be true.

On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:
> On 18/10/2021 01:47, Victor Yodaiken wrote:
> > On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:
> >> On 17/10/2021 16:40, Victor Yodaiken wrote:
> >>> On Sunday, October 17, 2021 at 6:39:07 AM UTC-5, David Brown wrote:
> >>>
> >>>> I want to be able to say "do this calculation /now/, not just some time
> >>>> between when you have the inputs ready and need the output". C has no
> >>>> such concept. You can order memory accesses by using "volatile", but
> >>>> that does not affect any other kind of operation or calculation, or
> >>>> ordering of non-volatile memory accesses. So if I want to push all
> >>>> non-critical work outside of a critical section, C can't give me that.
> >>>> This is a real problem:
> >>>
> >>> Agreed. The Standard says statements should be executed in order unless
> >>> otherwise "indicated", but this seems to be a dead letter. In fact the now optional
> >>> (and always awful) threads component allows for arbitrary compiler movements
> >>> of statements
> >>> within synchronization blocks. This standards language was not properly edited when
> >>> the concurrency/thread stuff became optional and both WG14 and gcc/clang
> >>> seem to believe that they can ignore statement order pretty much everywhere.
> >> The compiler has always been able to re-organise things like that. As
> >> Tim said in a post, execution order is specified for the C abstract
> >> machine, but there only needs to be synchronisation between the C
> >> abstract machine and the real target system at points of "observable
> >> behaviour".
> >
> >
> > As far as I can tall, that is not in the text of the standard at all.
> >
> 5.1.2.2.1p6, under "Program execution":
>
> """
> 6 The least requirements on a conforming implementation are:
> — Volatile accesses to objects are evaluated strictly according to the
> rules of the abstract machine.
>
> — At program termination, all data written into files shall be identical
> to the result that execution of the program according to the abstract
> semantics would have produced.
>
> — The input and output dynamics of interactive devices shall take place
> as specified in 7.21.3. The intent of these requirements is that
> unbuffered or line-buffered output appear as soon as possible, to ensure
> that prompting messages actually appear prior to a program waiting for
> input.
> This is the observable behavior of the program.
> """
>
>
> >>
> >> And IMHO, that is fine - in general, I /want/ the compiler to be able to
> >> re-organise a lot. Sure, it can be a pain in debugging or when
> >> examining generated assembly code, but that's part of life as a
> >> programmer. I'd like, on a few rare occasions, to be able to give the
> >> compiler firmer commands here - but /only/ on those rare occasions.
> >>>
> >>>> I would like to be able to tell the compiler "x is between 1 and 3 here
> >>>> - optimise using that knowledge, and ignore the possibility that it is
> >>>> outside that range". Again, I can do a lot of this in gcc - using
> >>>> __builtin_unreachable() to indicate undefined behaviour. (Yes, I am
> >>>> /adding/ undefined behaviour to improve my code.)
> >>>
> >>> Good example of how the concept of undefined has become too much of the hammer used
> >>> on every problem.
> >> I don't understand you here.
> >>
> >> If I tell the compiler "assume x is between 1 and 3", what do you think
> >> should happen if it is /not/ in that range?
> >>
> >> Perhaps I have code:
> >>
> >> if ((x < 1) || (x > 3)) __builtin_unreachable();
> >> y = z / x;
> >>
> >> and this is on a target with very expensive division. The compiler
> >> could turn "y = z / x;" into :
> >>
> >> if (x == 1) {
> >> y = 1;
> >> } else if (x == 2) {
> >> y = z / 2;
> >> } else {
> >> y = z / 3;
> >> }
> >
> > Which you could easily do yourself without any assistance from the compiler
> I could - but the compiler can also do that kind of thing (I haven't
> checked for this particular example). I'd rather spend my time writing
> clear, maintainable and flexible code, and let the compiler do its job
> of turning that into the smallest and fastest object code. If I had
> wanted to micro-manage all the details, I'd write in assembly.
> >
> >> and then convert those divide by constants into shifts, multiply by
> >> reciprocals, etc.
> >>
> >
> > And this is something the compiler should do, but there is no need to
> > invoke UB.
> No one is "invoking UB" - that, I think, is /your/ phrase. It is useful
> for the compiler to know about things that can't happen - whether it is
> because it would be UB, or because the programmer tells it that they
> can't happen. It amounts to the same thing.
> >
> >> If I attempt to run it with an invalid "x", what will be the result?.
> >> It could be "z / 3", it could be an overflow, or it could be something
> >> entirely different and unpredictable, depending on how the compiler
> >> actually manipulated the code. It could even be "z / x". There is no
> >> defined behaviour for the code - it is /undefined/ behaviour. But
> >> that's fine - I told the compiler this is never going to happen, and it
> >> can rely on that promise.
> >
> > Fine. But your gain here is minimal.
> No, it is not. And I have used this technique in code where it is not
> "minimal" gain - it is /essential/ gain. There are also added benefits
> in the documentation of the code, in static error checking in some
> cases, and options for run-time checking.
> > It is the usual case of using UB
> > to produce trivial optimizations. If it is a performance drag, then
> > profile and fix it. Otherwise, it's not a problem.
> >
> I don't need you to tell me what I need in my code, or to make wild
> guesses as to what you think makes a difference.
>

I'd very much prefer
y = x > 1 && x < 4 ? z/x : z;
Depending on distribution of x, it can be either faster or slower or the same as your variant, but is fully-defined, does not depend on gcc extensions and, IMHO, is easier to grasp.

> You can make measurements of existing code compiled with and without
> optimisations such as TBAA, and use that to get some idea of the general
> benefits (or lack thereof) of such optimisations. Usually the
> measurements are not particularly helpful because they are done in
> environments (such as modern x86 systems) where other effects swamp the
> results. And usually the results are given with a misunderstanding of
> the point of optimisations.
>
> Modern compilers do /lots/ of optimisations. Some have general effects
> that apply to a lot of code. Others have no effect on most code, but
> can have a big benefit to particular code constructs. Some have general
> but low level effects - a percent here or there, which are little on
> their own but add up to something useful when you have 40 such passes.
> Some only really come into play if you write code that takes advantage
> of them, others can dramatically change the way you can write code.
> >
> >> UB is not a "hammer for every problem" - it is a useful tool in the
> >> toolbox. It just seems to be a bit too difficult for some people to
> >> understand, or too dangerous for some programmers to use without
> >> injuring themselves.
> >
> > Not all of us can be as smart as you - if that's your point.
> >
> A lot of C programmers could do with more training - or perhaps some of
> the people doing the training or writing the books could do with a
> better understanding of the language. But I don't think UB in general
> should be too difficult for a programmer who is qualified to work in C
> coding - it is only a problem for a small proportion of programmers. As
> a source of bugs in code, it is - I believe - a very minor one.
> >
> >>>
> >>>> Some of the things I would like could be done by standardising things
> >>>> that can be expressed with gcc. Other things, I have no good idea of
> >>>> how they could be handled.
> >>>>
> >>>> But what I /can/ say is that I think these things would be a lot more
> >>>> useful for low-level code, OS's, and the like, than making signed
> >>>> integer overflow wrap, or disabling TBAA.
> >>>
> >>> This depends on what you are doing. For OS "in the large"
> >>> those things are more of a problem.
> >>>
> >>> #include <bigdatastructureT.h>
> >>>
> >>> f(T* x){
> >>> // T.i is signed int, but work unsigned to allow modular arithmetic
> >>> unsigned int *i = (unsigned int *)&T->i;
> >>> *i += read_sensor();
> >>> ....
> >>> }
> >>>
> >>> and then to find out at some much later time that someone changed T.i to a long
> >>> and the optimizer has silently deleted the assignment.
> >> I'll agree that is a risk of casts. (It would still be wrong even if
> >> the assignment were not deleted, if "int" and "long" are different sizes.)
> >>> What I want here is for the compiler to WARN me there is a possible type error and
> >>> not for the compiler to silently "optimize" it .
> >> If you need to support such possible changes, there are plenty of ways
> >> to do this safely - but they require more effort. For example, you
> >> could use _Generic, or switch to C++ and use templates, to make a
> >> "wrapping increment" operation that works for any size of signed
> >> integer. You can have static assertions to check sizes. You can use
> >> coding conventions, typedefs, or development strategies that avoid the
> >> possibility of the changes. C is not an inherently "safe" language - it
> >> needs help from the programmer. (And making signed integer overflow
> >> wrapping would certainly /not/ help.)
> >>
> >
> > None of that is practical.
> I find writing correct code to be a lot more practical than writing
> incorrect code.
> >
> >> And yes, more and better compiler warnings or static error detection is
> >> almost always a good thing, and I'd like a check that caught such a
> >> mistake - if such a check is possible without too many false positives..
> >>
> >> Oh, and it's always better to have good software designers and code
> >> reviews, helping to stop you doing silly things or making silly
> >> requirements - such as wanting to have wrapping behaviour for adding up
> >> sensor readings, rather than having a sensible design that won't
> >> overflow and won't give you meaningless values. It's extremely rare
> >> that wrapping behaviour is actually correct.
> >
> >
> > That is 100% incorrect.
> OK, sorry. Yes, I agree - the best solution here would be to dumb down
> the language and compilers to something that can be used without any
> training or education. People should be free to write whatever garbage
> they like - and compilers should be smart enough to give the right
> answers even from incorrect inputs, while still being slavish enough to
> do exactly what the programmer wrote, however nonsensical. And before
> any dangerous calls, the program should automatically pop up an "Are you
> sure?" box to the user.
>
> Back here in the real world, if programmers stopped writing silly code
> then there would be a lot fewer software problems to go around.
> >
> > there are millions of lines of code that check for overflow the obvious way
> > where the checks are deleted without fwrapv
> It's not obvious - it is obviously wrong, to anyone who understands C.
> It's smart-arse coding. And yes, it exists, and yes, it is a problem -
> smart-arses are not new, nor are they a dying breed. "-fwrapv" is a
> cheap way of sweeping that one particular problem under the rug, rather
> than fixing it (which would be hard and costly).
>
> And if anyone happens to use a compiler other than gcc, clang or icc
> that have that option - good luck. I suppose people are already used to
> so many unexplained crashes in Windows that they won't notice those
> caused by code monkey's who think MSVC supports wrapping signed arithmetic.
> >
> > and that's just a start.
> >
> > I don't want the results of arithmetic operations to depend on the optimizer level and
> > version of the optimizer. Others can have different priorities.
> >
> Neither do I - that's why I don't write shite code that depends on the
> optimizer level or compiler version for its behaviour. Don't let your
> signed integer arithmetic overflow - it's a simple rule. Instead of
> inventing endless ways to try to justify why you should be able to write
> meaningless code, how about trying to find ways to encourage people to
> write /sensible/ code instead?
> >>>
> >>> or
> >>> if ( ptr < &stack[0])stackoverflow();
> >>>
> >>> OOPS! That comparison is UB and whole statement can be silently deleted
> >>>
> >> Note that the compiler cannot (and will not) remove this statement
> >> unless it /knows/ that the pointer cannot possibly point to something in
> >> the stack.
> >
> > That is not correct. if the ptr points before the stack such a comparison
> > *would be* UB, but since UB is axiomatically impossible, the compiler
> > can delete the checks as an optimization by replacing (ptr < &stack[0]) with FALSE.
> >
> That is not correct. With the code you have shown, "stack" could be a
> pointer to anywhere, including within a larger object and "ptr" may
> point to a different part of that same object.
> >
> >> And if the compiler knows that, then the programmer should
> >> probably know that too - in which case the whole thing is another
> >> example of silly code where the fault lies with the software design.
> >> (This happens a /lot/ when people write stuff with undefined behaviour -
> >> it's not so often that the programmer has misunderstood some subtleties
> >> of the C standards.
> >
> > As you just have.
> >
> > More often, the programmer is writing code that
> >> doesn't really make sense, or alternatively they are writing smart-arse
> >> code instead of smart code.)
> >>> or ....
> >
> > As you were saying.
> >
> See above.
> >>>
> >>>
> >>>
> >>> Linux has 30million some lines of code (God save us), it's going to have very different problems than
> >>> a device driver or microcontroller code. Many UB ill effects come from the inevitable problems
> >>> of a huge, old, codebase touched by many different people, few of whom have much visibility
> >>> into the larger system.
> >>>
> >> Yes. So the main solution here involves a lot of code review, a lot of
> >> testing, a lot of static checking, and a lot of specifically written
> >> tools and checks - which is exactly what they have done. And as a
> >> backup for reducing the consequences for certain types of code errors
> >> that haven't yet been found, they specify a few extra semantics added to
> >> the C language - such as you get using "gcc -fno-strict-aliasing".
> >>
> >> That's fine - the code is not remotely portable to other compilers
> >> anyway (even to closely compatible tools like clang and icc - though
> >> progress is being made here).
> >>
> >> That doesn't mean it is a good idea to change the C standards - nor does
> >> it mean that the OS /needs/ to have these extra semantics from those
> >> extra flags.
> >
> >
> >
> >

On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:
> On 18/10/2021 01:47, Victor Yodaiken wrote:
> > On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:
> >> On 17/10/2021 16:40, Victor Yodaiken wrote:
> >>> On Sunday, October 17, 2021 at 6:39:07 AM UTC-5, David Brown wrote:
> >>>
> >>>> I want to be able to say "do this calculation /now/, not just some time
> >>>> between when you have the inputs ready and need the output". C has no
> >>>> such concept. You can order memory accesses by using "volatile", but
> >>>> that does not affect any other kind of operation or calculation, or
> >>>> ordering of non-volatile memory accesses. So if I want to push all
> >>>> non-critical work outside of a critical section, C can't give me that.
> >>>> This is a real problem:
> >>>
> >>> Agreed. The Standard says statements should be executed in order unless
> >>> otherwise "indicated", but this seems to be a dead letter. In fact the now optional
> >>> (and always awful) threads component allows for arbitrary compiler movements
> >>> of statements
> >>> within synchronization blocks. This standards language was not properly edited when
> >>> the concurrency/thread stuff became optional and both WG14 and gcc/clang
> >>> seem to believe that they can ignore statement order pretty much everywhere.
> >> The compiler has always been able to re-organise things like that. As
> >> Tim said in a post, execution order is specified for the C abstract
> >> machine, but there only needs to be synchronisation between the C
> >> abstract machine and the real target system at points of "observable
> >> behaviour".
> >
> >
> > As far as I can tall, that is not in the text of the standard at all.
> >
> 5.1.2.2.1p6, under "Program execution":
>
> """
> 6 The least requirements on a conforming implementation are:
> — Volatile accesses to objects are evaluated strictly according to the
> rules of the abstract machine.
>
> — At program termination, all data written into files shall be identical
> to the result that execution of the program according to the abstract
> semantics would have produced.
>
> — The input and output dynamics of interactive devices shall take place
> as specified in 7.21.3. The intent of these requirements is that
> unbuffered or line-buffered output appear as soon as possible, to ensure
> that prompting messages actually appear prior to a program waiting for
> input.
> This is the observable behavior of the program.
> """
>
>
> >>
> >> And IMHO, that is fine - in general, I /want/ the compiler to be able to
> >> re-organise a lot. Sure, it can be a pain in debugging or when
> >> examining generated assembly code, but that's part of life as a
> >> programmer. I'd like, on a few rare occasions, to be able to give the
> >> compiler firmer commands here - but /only/ on those rare occasions.
> >>>
> >>>> I would like to be able to tell the compiler "x is between 1 and 3 here
> >>>> - optimise using that knowledge, and ignore the possibility that it is
> >>>> outside that range". Again, I can do a lot of this in gcc - using
> >>>> __builtin_unreachable() to indicate undefined behaviour. (Yes, I am
> >>>> /adding/ undefined behaviour to improve my code.)
> >>>
> >>> Good example of how the concept of undefined has become too much of the hammer used
> >>> on every problem.
> >> I don't understand you here.
> >>
> >> If I tell the compiler "assume x is between 1 and 3", what do you think
> >> should happen if it is /not/ in that range?
> >>
> >> Perhaps I have code:
> >>
> >> if ((x < 1) || (x > 3)) __builtin_unreachable();
> >> y = z / x;
> >>
> >> and this is on a target with very expensive division. The compiler
> >> could turn "y = z / x;" into :
> >>
> >> if (x == 1) {
> >> y = 1;
> >> } else if (x == 2) {
> >> y = z / 2;
> >> } else {
> >> y = z / 3;
> >> }
> >
> > Which you could easily do yourself without any assistance from the compiler
> I could - but the compiler can also do that kind of thing (I haven't
> checked for this particular example). I'd rather spend my time writing
> clear, maintainable and flexible code, and let the compiler do its job
> of turning that into the smallest and fastest object code. If I had
> wanted to micro-manage all the details, I'd write in assembly.
> >
> >> and then convert those divide by constants into shifts, multiply by
> >> reciprocals, etc.
> >>
> >
> > And this is something the compiler should do, but there is no need to
> > invoke UB.
> No one is "invoking UB" - that, I think, is /your/ phrase. It is useful
> for the compiler to know about things that can't happen - whether it is
> because it would be UB, or because the programmer tells it that they
> can't happen. It amounts to the same thing.
> >
> >> If I attempt to run it with an invalid "x", what will be the result?.
> >> It could be "z / 3", it could be an overflow, or it could be something
> >> entirely different and unpredictable, depending on how the compiler
> >> actually manipulated the code. It could even be "z / x". There is no
> >> defined behaviour for the code - it is /undefined/ behaviour. But
> >> that's fine - I told the compiler this is never going to happen, and it
> >> can rely on that promise.
> >
> > Fine. But your gain here is minimal.
> No, it is not. And I have used this technique in code where it is not
> "minimal" gain - it is /essential/ gain. There are also added benefits
> in the documentation of the code, in static error checking in some
> cases, and options for run-time checking.
> > It is the usual case of using UB
> > to produce trivial optimizations. If it is a performance drag, then
> > profile and fix it. Otherwise, it's not a problem.
> >
> I don't need you to tell me what I need in my code, or to make wild
> guesses as to what you think makes a difference.
>
> You can make measurements of existing code compiled with and without
> optimisations such as TBAA, and use that to get some idea of the general
> benefits (or lack thereof) of such optimisations. Usually the
> measurements are not particularly helpful because they are done in
> environments (such as modern x86 systems) where other effects swamp the
> results. And usually the results are given with a misunderstanding of
> the point of optimisations.

For my own code, I would expect no [positive] effect on any target.
I can predict what happens to other's coding styles.

>
> Modern compilers do /lots/ of optimisations. Some have general effects
> that apply to a lot of code. Others have no effect on most code, but
> can have a big benefit to particular code constructs. Some have general
> but low level effects - a percent here or there, which are little on
> their own but add up to something useful when you have 40 such passes.
> Some only really come into play if you write code that takes advantage
> of them, others can dramatically change the way you can write code.
> >
> >> UB is not a "hammer for every problem" - it is a useful tool in the
> >> toolbox. It just seems to be a bit too difficult for some people to
> >> understand, or too dangerous for some programmers to use without
> >> injuring themselves.
> >
> > Not all of us can be as smart as you - if that's your point.
> >
> A lot of C programmers could do with more training - or perhaps some of
> the people doing the training or writing the books could do with a
> better understanding of the language. But I don't think UB in general
> should be too difficult for a programmer who is qualified to work in C
> coding - it is only a problem for a small proportion of programmers. As
> a source of bugs in code, it is - I believe - a very minor one.
> >
> >>>
> >>>> Some of the things I would like could be done by standardising things
> >>>> that can be expressed with gcc. Other things, I have no good idea of
> >>>> how they could be handled.
> >>>>
> >>>> But what I /can/ say is that I think these things would be a lot more
> >>>> useful for low-level code, OS's, and the like, than making signed
> >>>> integer overflow wrap, or disabling TBAA.
> >>>
> >>> This depends on what you are doing. For OS "in the large"
> >>> those things are more of a problem.
> >>>
> >>> #include <bigdatastructureT.h>
> >>>
> >>> f(T* x){
> >>> // T.i is signed int, but work unsigned to allow modular arithmetic
> >>> unsigned int *i = (unsigned int *)&T->i;
> >>> *i += read_sensor();
> >>> ....
> >>> }
> >>>
> >>> and then to find out at some much later time that someone changed T.i to a long
> >>> and the optimizer has silently deleted the assignment.
> >> I'll agree that is a risk of casts. (It would still be wrong even if
> >> the assignment were not deleted, if "int" and "long" are different sizes.)
> >>> What I want here is for the compiler to WARN me there is a possible type error and
> >>> not for the compiler to silently "optimize" it .
> >> If you need to support such possible changes, there are plenty of ways
> >> to do this safely - but they require more effort. For example, you
> >> could use _Generic, or switch to C++ and use templates, to make a
> >> "wrapping increment" operation that works for any size of signed
> >> integer. You can have static assertions to check sizes. You can use
> >> coding conventions, typedefs, or development strategies that avoid the
> >> possibility of the changes. C is not an inherently "safe" language - it
> >> needs help from the programmer. (And making signed integer overflow
> >> wrapping would certainly /not/ help.)
> >>
> >
> > None of that is practical.
> I find writing correct code to be a lot more practical than writing
> incorrect code.
> >
> >> And yes, more and better compiler warnings or static error detection is
> >> almost always a good thing, and I'd like a check that caught such a
> >> mistake - if such a check is possible without too many false positives..
> >>
> >> Oh, and it's always better to have good software designers and code
> >> reviews, helping to stop you doing silly things or making silly
> >> requirements - such as wanting to have wrapping behaviour for adding up
> >> sensor readings, rather than having a sensible design that won't
> >> overflow and won't give you meaningless values. It's extremely rare
> >> that wrapping behaviour is actually correct.
> >
> >
> > That is 100% incorrect.
> OK, sorry. Yes, I agree - the best solution here would be to dumb down
> the language and compilers to something that can be used without any
> training or education. People should be free to write whatever garbage
> they like - and compilers should be smart enough to give the right
> answers even from incorrect inputs, while still being slavish enough to
> do exactly what the programmer wrote, however nonsensical. And before
> any dangerous calls, the program should automatically pop up an "Are you
> sure?" box to the user.
>
> Back here in the real world, if programmers stopped writing silly code
> then there would be a lot fewer software problems to go around.

Michael S <already5chosen@yahoo.com> writes:

> On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:
>> On 18/10/2021 01:47, Victor Yodaiken wrote:
>> > On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:
>> >> On 17/10/2021 16:40, Victor Yodaiken wrote:
>> >>> On Sunday, October 17, 2021 at 6:39:07 AM UTC-5, David Brown wrote:
>> >>>

[..]

>> Back here in the real world, if programmers stopped writing silly code
>> then there would be a lot fewer software problems to go around.
>
> Don't be silly.
> The best solution does not involve magic.
> Something like that will do:
>
> Signed overflow is implementation-defined, but in constrained way.

I think that is what standard calls "unspecified behavior"

> Possible options are
> 1. two-complement wrap-around
> 2. trap
> 3. saturation
> 4. one-complement wrap-around, if there exist a member of committee

only squared. (It's quite possible that my idea of Unspec*B* is
incorrect though)

> that care about it

[..]

On 18/10/2021 14:23, Michael S wrote:
> On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:
>> On 18/10/2021 01:47, Victor Yodaiken wrote:
>>> On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:

>>>> If I tell the compiler "assume x is between 1 and 3", what do you think
>>>> should happen if it is /not/ in that range?
>>>>
>>>> Perhaps I have code:
>>>>
>>>> if ((x < 1) || (x > 3)) __builtin_unreachable();
>>>> y = z / x;
>>>>

>
> I'd very much prefer
> y = x > 1 && x < 4 ? z/x : z;
> Depending on distribution of x, it can be either faster or slower or the same as your variant, but is fully-defined, does not depend on gcc extensions and, IMHO, is easier to grasp.
>

A quick test will show you that my version is faster - a compiler will
either make use of the extra information in order to give more efficient
results, or it will ignore the test entirely and give you the same as
plain "y = z / x;". Your version (after correcting to "x >= 1"), on the
other hand, /forces/ the compiler to make the comparison, and any
optimisations it might have been able to apply to the "z/x" bit could be
applied in my version.

Your version is not fully defined for all x - it is undefined if x is 0.
It /is/ fully defined on the specified input range with x from 1 to 3,
but so is mine. Being defined for values of x that cannot occur is of
no benefit whatsoever.

Your version does not depend on a gcc extension, that is certainly true
- there is no good portable way to give the compiler such extra
information (that was my point).

Easier to grasp is, of course, in the eye of the reader.

In practice, I have such tests wrapped in a macro, and thus write :

assume((x >= 1) && (x <= 3));
y = z / x;

If the compiler can tell at compile-time that the assumption is wrong,
it gives me an error message. If I want to check it at run-time, I set
a pre-processor symbol (like DEBUG for standard "assert") to choose such
checking.

On Monday, October 18, 2021 at 4:02:21 PM UTC+3, David Brown wrote:
> On 18/10/2021 14:23, Michael S wrote:
> > On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:
> >> On 18/10/2021 01:47, Victor Yodaiken wrote:
> >>> On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:
>
> >>>> If I tell the compiler "assume x is between 1 and 3", what do you think
> >>>> should happen if it is /not/ in that range?
> >>>>
> >>>> Perhaps I have code:
> >>>>
> >>>> if ((x < 1) || (x > 3)) __builtin_unreachable();
> >>>> y = z / x;
> >>>>
>
> >
> > I'd very much prefer
> > y = x > 1 && x < 4 ? z/x : z;
> > Depending on distribution of x, it can be either faster or slower or the same as your variant, but is fully-defined, does not depend on gcc extensions and, IMHO, is easier to grasp.
> >
> A quick test will show you that my version is faster -

So, do it.
I can't test it myself, because right now I have no HW on my table on which division is much slower than branch mispredict.
Don't forget to test a distribution in which x==1 occures much more often than 2 and 3.

> a compiler will
> either make use of the extra information in order to give more efficient
> results, or it will ignore the test entirely and give you the same as
> plain "y = z / x;". Your version (after correcting to "x >= 1"),

No need to correct anything. My version is correct as written.

> on the
> other hand, /forces/ the compiler to make the comparison, and any
> optimisations it might have been able to apply to the "z/x" bit could be
> applied in my version.
>
> Your version is not fully defined for all x - it is undefined if x is 0.

Wrong. For x=0 it returns z.

> It /is/ fully defined on the specified input range with x from 1 to 3,
> but so is mine. Being defined for values of x that cannot occur is of
> no benefit whatsoever.
>
> Your version does not depend on a gcc extension, that is certainly true
> - there is no good portable way to give the compiler such extra
> information (that was my point).
>
> Easier to grasp is, of course, in the eye of the reader.
>
> In practice, I have such tests wrapped in a macro, and thus write :
>
> assume((x >= 1) && (x <= 3));
> y = z / x;
> If the compiler can tell at compile-time that the assumption is wrong,
> it gives me an error message. If I want to check it at run-time, I set
> a pre-processor symbol (like DEBUG for standard "assert") to choose such
> checking.