Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:

A general point: On Usenet, it is considered good form to
limit line lengths to 72. Would you mind following that
convention? I keep having to re-break your lines in
quotaions. Thanks!

> On Thursday, October 14, 2021 at 1:40:35 AM UTC-5, Thomas Koenig wrote:
>> Victor Yodaiken schrieb:
>> > The paper really focuses on the example of alias optimizations
>> > and Dennis Ritchie's strong - and prescient warnings.
>> Dennis Ritchie was warning about a specific feature which did
>> not make it into the language.
>>
>
> His warning - including his discussion of Fortran which you
> might want to read, is generally applicable.

Dennis Ritchie in 1988 could hardly have known Fortran 90.

>> One of the design faults of C is the overuse of pointers,
>> specifically for array access (including pointer arithmetic),
>
>
> If you don't like C and don't appreciate its design basis, then your opinion of
> what optimizations are reasonable may not be as insightful as you believe.

Huh?

I do like the language (I use it quite often), but I am
not blind to its faults.

> C pointers are extremely useful for some applications. But
> certainly other approaches have advantages in other applications.

>
>>
>> Now, consider:
>>
>> float *fp;
>> int *fp;
>> float a;
>>
>> /* ... */
>>
>> *fp = something;
>> *ip = something_else;
>> printf ("%f", *fp);
>>
>> Assume that the value of *fp is held in a register. Should the
>> store to *ip make a reload of fp necessary before the printf?
>
> This depends on whether the pointers point to the same object.

Um... and how does the compiler determine that?

This is exactly the point - in the absence of other information,
(for example in pointers passed to a function), the compiler _must_
reload *fp if you have it your way. You quite vehemently argue
for this.

According to the C standard (and to my preference) it need not do
so, because of the difference in type.

>
>
>> > And part of the reason is because sound alias analysis is much
>> > *harder* for compilers than alias assumptions.
>> Which is why I like the Fortran model much better. In Fortran,
>>
>
> I am happy for you and I agree that Fortran is well suited to certain types
> of applications.
>
>> - if you have overlapping dummy arguments, you cannot store
>> a value through one and access it through another one
>> (which is rarely checked, unfortunately)
>
> Indeed. And why is that?

In the case of gfortran, because nobody to date has stepped
up to write a patch. There is also a run-time overhead.

> If I had known about Fortran's issues with alias analysis, I
> might have even included in a 6 page paper a reference to Fortran
> alias analysis -something like this:

> " Fortran has similar problems with similar assumptions:
> "anything may happen: the program may appear to run normally,
> or produce incorrect answers, or behave unpredictably." [24]."

In Fortran, the wording is clearer than C's weasel-word "undefined
behavior". Code which does so is in violation of a "shall"
directive, so the program is erronous. This is not a violation
of a constraint (which are clearly labeled and numbered) so a
compiler is not required to diagnose it.

Case closed.

>
>> > Since you bring it up, for me the way C originally handled
>> > integer overflow was sloppy and sometimes dangerous - it was an
>> > engineering tradeoff made to make fast code and simple compilation.
>> > BUT the ISO-C approach is mathematically incoherent and even more
>> > dangerous - because semantics is unpredictable.
>> Signed integer overflow is an error, period (the same in
>> Fortran as in C).
>> > Ironically, as C compilers muddied int arithmetic, processors
>> > became much better about native signed arithmetic. Mod 2^k 2s
>> > complement, which is native on the vast majority of modern
>> > processors is mathematically coherent even if it is hard to
>> > work with.
>> Very hard, and a source of errors...
>
> Programming is hard. Some languages have runtime to catch
> those errrors,

Run-time checks to catch thinking errors in mod 2^n arithmetic?
I am amazed, please tell me what these are.

> and even in some C compilers we have an option for ftrapv. But
> there are tradeoffs. This is why Fortran uses floating point
> arithmetic even though it is a notorious source of errors.

C also uses floating point, in case you had not noticed - the types
are called "float" and "double".

>> > But what we have in ISO C makes arithmetic depend on vagaries
>> > of the optimizer and produces paradoxes.
>> Ah, no. It means that an erroneous program gets random results,
>
> With modular arithmetic, or even saturating as you have on some
> processors, you do not get random results. You may not get the
> results you expect if you think 4 byte or even 8 or 16 byte "ints"
> can represent all of Z.

You are confusing the C language with whatever happens on a
particular system. Might I point out section 5.1.2.3 of n2346.pdf:

# The semantic descriptions in this document describe the behavior of
# an abstract machine in which issues of optimization are irrelevant.

The C standard is the specification for that abstract machine.
As long as you stick to that, you're reasonably safe (and you can
holler at compiler writers if you find bugs). If you insist on
peculiarities of a particular implementation... well, you violated
the contract, it's your fault.

> If you adopt the axiom that overflow is programming error,
> than you will conclude it is a programming error, but that's not
> super illuminating.

It is a programming error iff the specification says it is.
If you have a language whose spec says that 32767 + 1 = -32868,
that is another matter. I'm not aware of such a language, but
there may well be one.

>> which is not surprising. Would you also like to prosrcribe results
>> for array overruns?
>
> Indeed I would.

OK, I can live with that. It would incur significant run-time
overhead, but one goal of compiler writes is to reduce that
run-time overhead.

For example, I would like the run-time cheks for

subroutine foo(a,n, i)
integer, dimension(n) :: a
if (i > n) stop "Nope!"
do j=1,i
a(i) = 1.0
end do
end subroutine foo

to be removed by optimization.

>
>>Ada does so, and both it and Fortran are
>> better languages if you want to have a lower error rate than for C.
>>

> What's fascinating for me is how many people who consider C
> to be a botched language from the start

I'm not one of them. C has its strenghts and its weaknesses,
as has every other programming languages.

>are so interested in insisting on their ideas for C semantics.

It's what is written in the standard, not somebody's idea.

> C is useful for some applications, less for others. We have
> different languages for a reason. Fortran is not inferior to Haskell
> because it does not offer bignumbers as default. One would not want
> to write finite element analysis programs in Haskell. Similarly,
> I would not want to attempt operating systems or cryptography
> coding in Fortran.

Cryptography would be somewhat hampered by Fortran not having
unsigned numbers.

nemo <invalid@invalid.invalid> schrieb:
> On 2021-10-13 08:38, Thomas Koenig wrote:
> [...]
>>
>> AFAIK, there will be M1 support in gcc 12. Interestingly enough,
>> it was the lack of a Fortran compiler which mostly drove demand
>> for this port.
>
> Well, getting there... Configure accepts it but the next level down
> spits out:
> *** Configuration aarch64-apple-darwin20.4.0 not supported

Not in there yet.

See https://gcc.gnu.org/pipermail/gcc/2021-September/237340.html
for the announcement.

On 10/14/2021 4:05 AM, Branimir Maksimovic wrote:

snip

> Fortran is pre structured era, spagetti code. Good for
> arrays, not mutch for anything else :P
> Good luck with network code or parsing with FORTRAN :P

Sort of. FORTRAN was defined pre structured era, but it added
structuring features decades ago.

As for parsing, in the late 1970s, I used AMDASM, an assembler for 2901
bit sliced CPUs that was written in FORTRAN. It worked fine.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
> On Thursday, October 14, 2021 at 9:24:43 AM UTC-5, David Brown wrote:
>
>> The standard has to provide the lowest common denominator - the most
>> vague version of the language, with the most undefined behaviours and
>> implementation-defined behaviours. It is then up to implementations to
>> tighten these details as appropriate, or offer options for additional
>> semantics.
>>
>
> I disagree. Overuse of UB degrades the semantics of the language
> and reduces its utility. The overhead in dealing with unpredictable
> unsound optimizations is a serious drag on the utility of C.

Let's called "undefined behavior" what it is - programming errors,
and see how much your sentence makes sense then.

On Thu, Oct 14, 2021 at 10:42 AM Thomas Koenig wrote:
>>Victor Yodaiken schrieb:

>A general point: On Usenet, it is considered good form to
>limit line lengths to 72. Would you mind following that
>convention? I keep having to re-break your lines in
>quotaions. Thanks!

i will try. I may have inconsistent quoting in this reply, so please forgive me.

>> On Thursday, October 14, 2021 at 1:40:35 AM UTC-5, Thomas Koenig wrote:
>>> Victor Yodaiken schrieb:
>>> > The paper really focuses on the example of alias optimizations
>>> > and Dennis Ritchie's strong - and prescient warnings.
>>> Dennis Ritchie was warning about a specific feature which did
>>> not make it into the language.
>>>
>>
>>> His warning - including his discussion of Fortran which you
>> might want to read, is generally applicable.

>Dennis Ritchie in 1988 could hardly have known Fortran 90.

in 1988 there was significant experience with Fortran optimization, particularly, with
alias analysis. Not all that much changed by 1990.

>> One of the design faults of C is the overuse of pointers,
>> specifically for array access (including pointer arithmetic),
>
>
> If you don't like C and don't appreciate its design basis, then your opinion of
> what optimizations are reasonable may not be as insightful as you believe..

>Huh?

>I do like the language (I use it quite often), but I am
>not blind to its faults.

Overuse of pointers is a key part of what makes C useful.

>> C pointers are extremely useful for some applications. But
>> certainly other approaches have advantages in other applications.

>>
>>>
>>> Now, consider:
>>>
>>> float *fp;
>>> int *fp;
>>> float a;
>>>
>>> /* ... */
>>>
>>> *fp = something;
>>> *ip = something_else;
>>> printf ("%f", *fp);
>>>
>>> Assume that the value of *fp is held in a register. Should the
>>> store to *ip make a reload of fp necessary before the printf?
>>
>> This depends on whether the pointers point to the same object.
>
>Um... and how does the compiler determine that?
>
>This is exactly the point - in the absence of other information,
>(for example in pointers passed to a function), the compiler _must_
>reload *fp if you have it your way. You quite vehemently argue
>for this.

I am against unsound transformations. For example, transforming a
double float radix sort into a no-op would not be sound.
>According to the C standard (and to my preference) it need not do
>so, because of the difference in type.

I think that is a significant reduction in C expressive range and not at all worth
the minimal optimization gains.

>>
>>
>>> > And part of the reason is because sound alias analysis is much
>>> > *harder* for compilers than alias assumptions.
>>> Which is why I like the Fortran model much better. In Fortran,
>>>
>>
>> I am happy for you and I agree that Fortran is well suited to certain types
>> of applications.
>>
>>> - if you have overlapping dummy arguments, you cannot store
>>> a value through one and access it through another one
>>> (which is rarely checked, unfortunately)
>>
>> Indeed. And why is that?
>
>In the case of gfortran, because nobody to date has stepped
>up to write a patch. There is also a run-time overhead.

Yes.
>> If I had known about Fortran's issues with alias analysis, I
>> might have even included in a 6 page paper a reference to Fortran
>> alias analysis -something like this:
>
>> " Fortran has similar problems with similar assumptions:
>> "anything may happen: the program may appear to run normally,
>> or produce incorrect answers, or behave unpredictably." [24]."
>
>In Fortran, the wording is clearer than C's weasel-word "undefined
>behavior".

Absolutely agree that "undefined behavior" is an awful concept.
I think it is used to evade burden on the compilers for error checking and
to evade plainly stating proposed limitations to C expressiveness.
>Code which does so is in violation of a "shall"
>directive, so the program is erronous. This is not a violation
>of a constraint (which are clearly labeled and numbered) so a
>compiler is not required to diagnose it.
>
>Case closed.

>>
>>> > Since you bring it up, for me the way C originally handled
>>> > integer overflow was sloppy and sometimes dangerous - it was an
>>> > engineering tradeoff made to make fast code and simple compilation.
>>> > BUT the ISO-C approach is mathematically incoherent and even more
>>> > dangerous - because semantics is unpredictable.
>>> Signed integer overflow is an error, period (the same in
>>> Fortran as in C).
>>> > Ironically, as C compilers muddied int arithmetic, processors
>>> > became much better about native signed arithmetic. Mod 2^k 2s
>>> > complement, which is native on the vast majority of modern
>>> > processors is mathematically coherent even if it is hard to
>>> > work with.
>>> Very hard, and a source of errors...
>>
>> Programming is hard. Some languages have runtime to catch
>> those errrors,
>
>Run-time checks to catch thinking errors in mod 2^n arithmetic?
>I am amazed, please tell me what these are.

You can, if you want, select ftrapv on both gcc and clang. This will catch overflows.
>> and even in some C compilers we have an option for ftrapv. But
>> there are tradeoffs. This is why Fortran uses floating point
>> arithmetic even though it is a notorious source of errors.
>
>C also uses floating point, in case you had not noticed - the types
>are called "float" and "double".

It does for the same reason.
>>> > But what we have in ISO C makes arithmetic depend on vagaries
>>> > of the optimizer and produces paradoxes.
>>> Ah, no. It means that an erroneous program gets random results,
>>
>> With modular arithmetic, or even saturating as you have on some
>> processors, you do not get random results. You may not get the
>> results you expect if you think 4 byte or even 8 or 16 byte "ints"
>> can represent all of Z.
>
>You are confusing the C language with whatever happens on a
>particular system. Might I point out section 5.1.2.3 of n2346.pdf:

You are confusing your interpretation of C standard for laws of physics. I propose
different semantics.
BTW: C overflow semantics are not described in the C standard at all. The standard
leaves it up to the implementation.
># The semantic descriptions in this document describe the behavior of
># an abstract machine in which issues of optimization are irrelevant.
>
>The C standard is the specification for that abstract machine.
>As long as you stick to that, you're reasonably safe (and you can
>holler at compiler writers if you find bugs). If you insist on
>peculiarities of a particular implementation... well, you violated
>the contract, it's your fault.
>

And overflow is specifically stated to be undefined. So an implementation
that, for example, adopts target architecture arithmetic semantics is following the standard
as much or more than one that interprets "undefined" to mean "impossible".
In fact, the interpretation of undefined to mean "not possible" is controversial and
not particularly well founded in the text or history of the standard. It is actually
a byproduct of how certain intermediate languages work. It is convenient in gcc/clang
to treat UB as impossible, but that's a bizarre way to come up with semantics.
>> If you adopt the axiom that overflow is programming error,
>> than you will conclude it is a programming error, but that's not
>> super illuminating.
>
>It is a programming error iff the specification says it is.

Which it does not.
>If you have a language whose spec says that 32767 + 1 = -32868,
>that is another matter. I'm not aware of such a language, but
>there may well be one.

C standard says

"the sign bit has the value −(2 M ) (two’s complement);"

with choice of integer representation being implementation defined.
So in C where sizeof(short) = 2 and, as it assumes but doesn't make
clear anywhere, bytes are 8 bits, we know there are only 2^{16} possible
values and there is no representation of 32768 in 2s complement in
16 bits. then, if we care about mathematical consistency,
32767+1 = -32868

On Thursday, October 14, 2021 at 6:05:22 AM UTC-5, Branimir Maksimovic wrote:
> On 2021-10-14, Thomas Koenig <tko...@netcologne.de> wrote:
> > Victor Yodaiken <victor....@gmail.com> schrieb:
> >
> >> The paper really focuses on the example of alias optimizations
> >> and Dennis Ritchie's strong - and prescient warnings.
> >
> > Dennis Ritchie was warning about a specific feature which did
> > not make it into the language.
> >
> > [...]
> >
> >> Again, I don't have to believe that Ritchie was always right
> >> about everything to consider him one of the most brilliant CS
> >> researchers/programmers and to find his arguments on this issue
> >> strong. And I don't even have to oppose all alias analysis -
> >> in fact, I think, the type based approach taken by ISO reduces
> >> the expressive range of the language, creates complexity and
> >> murky semantics, AND leaves a lot of alias based optimization on
> >> the table.
> >
> > One of the design faults of C is the overuse of pointers,
> > specifically for array access (including pointer arithmetic),
> > dynamic memory allocation and for argument passing. While a
> > good design decision for the 1970s with limited resources for a
> > compiler, the very first high-level programming language, FORTRAN,
> > had already handled parts of this better.
> >
> > Now, consider:
> >
> > float *fp;
> > int *fp;
> > float a;
> >
> > /* ... */
> >
> > *fp = something;
> > *ip = something_else;
> > printf ("%f", *fp);
> >
> > Assume that the value of *fp is held in a register. Should the
> > store to *ip make a reload of fp necessary before the printf?
> >
> >> And part of the reason is because sound alias analysis is much
> >> *harder* for compilers than alias assumptions.
> >
> > Which is why I like the Fortran model much better. In Fortran,
> >
> > - if you have overlapping dummy arguments, you cannot store
> > a value through one and access it through another one
> > (which is rarely checked, unfortunately)
> >
> > - variables which can be a target of a pointer must be
> > marked TARGET
> >
> > - you have allocatable variables (which are automatically
> > deallocated when they go out of scope), which are not
> > TARGETs and which cannot alias anything else
> >
> > - Pointers can also point to multi-dimensional arrays
> >
> > (and teaching the somewhat C-centric gcc about optimizations
> > possible according to the Fortran language definition is an
> > ongoing process).
> >
> >> Since you bring it up, for me the way C originally handled
> >> integer overflow was sloppy and sometimes dangerous - it was an
> >> engineering tradeoff made to make fast code and simple compilation.
> >> BUT the ISO-C approach is mathematically incoherent and even more
> >> dangerous - because semantics is unpredictable.
> >
> > Signed integer overflow is an error, period (the same in
> > Fortran as in C).
> >
> >> Ironically, as C compilers muddied int arithmetic, processors
> >> became much better about native signed arithmetic. Mod 2^k 2s
> >> complement, which is native on the vast majority of modern
> >> processors is mathematically coherent even if it is hard to
> >> work with.
> >
> > Very hard, and a source of errors...
> >
> >> But what we have in ISO C makes arithmetic depend on vagaries
> >> of the optimizer and produces paradoxes.
> >
> > Ah, no. It means that an erroneous program gets random results,
> > which is not surprising. Would you also like to prosrcribe results
> > for array overruns? Ada does so, and both it and Fortran are
> > better languages if you want to have a lower error rate than for C.
> >
> > You will not have much luck changing C.
> Fortran is pre structured era, spagetti code. Good for
> arrays, not mutch for anything else :P
> Good luck with network code or parsing with FORTRAN :P
<
I lead a team that built a FORTRAN runtime library using nothing other
than FORTRAN.
> --
>
> 7-77-777
> Evil Sinner!
> with software, you repeat same experiment, expecting different results...

Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
>
> On Thu, Oct 14, 2021 at 10:42 AM Thomas Koenig wrote:
>>>Victor Yodaiken schrieb:
>
>>A general point: On Usenet, it is considered good form to
>>limit line lengths to 72. Would you mind following that
>>convention? I keep having to re-break your lines in
>>quotaions. Thanks!
>
>
> i will try. I may have inconsistent quoting in this reply, so please forgive me.
>
>>> On Thursday, October 14, 2021 at 1:40:35 AM UTC-5, Thomas Koenig wrote:
>>>> Victor Yodaiken schrieb:
>>>> > The paper really focuses on the example of alias optimizations
>>>> > and Dennis Ritchie's strong - and prescient warnings.
>>>> Dennis Ritchie was warning about a specific feature which did
>>>> not make it into the language.
>>>>
>>>
>>>> His warning - including his discussion of Fortran which you
>>> might want to read, is generally applicable.
>
>>Dennis Ritchie in 1988 could hardly have known Fortran 90.
>
>
> in 1988 there was significant experience with Fortran optimization, particularly, with
> alias analysis. Not all that much changed by 1990.

[ ] You know the first thing about Fortran and Fortran standards.

>
>>> One of the design faults of C is the overuse of pointers,
>>> specifically for array access (including pointer arithmetic),
>>
>>
>> If you don't like C and don't appreciate its design basis, then your opinion of
>> what optimizations are reasonable may not be as insightful as you believe.
>
>>Huh?
>
>>I do like the language (I use it quite often), but I am
>>not blind to its faults.

> Overuse of pointers is a key part of what makes C useful.

"Overuse" implies "too much", so I doubt that this
is what you meant.

>>> C pointers are extremely useful for some applications. But
>>> certainly other approaches have advantages in other applications.
>
>>>
>>>>
>>>> Now, consider:
>>>>
>>>> float *fp;
>>>> int *fp;
>>>> float a;
>>>>
>>>> /* ... */
>>>>
>>>> *fp = something;
>>>> *ip = something_else;
>>>> printf ("%f", *fp);
>>>>
>>>> Assume that the value of *fp is held in a register. Should the
>>>> store to *ip make a reload of fp necessary before the printf?
>>>
>>> This depends on whether the pointers point to the same object.
>>
>>Um... and how does the compiler determine that?
>>
>>This is exactly the point - in the absence of other information,
>>(for example in pointers passed to a function), the compiler _must_
>>reload *fp if you have it your way. You quite vehemently argue
>>for this.

> I am against unsound transformations. For example, transforming a
> double float radix sort into a no-op would not be sound.

I cannot understand how this sentence applies to what I wrote,
so I take it you concur with what I wrote.

>>According to the C standard (and to my preference) it need not do
>>so, because of the difference in type.
>
>
> I think that is a significant reduction in C expressive range
> and not at all worth the minimal optimization gains.

[Again, would you mind following Usenet conventions with line
breaking? Thanks.]

What you want will impede a lot of vectorization on current
architectures, then. [Yes, Mitch's VVM is better that way :-]

>>>> > And part of the reason is because sound alias analysis is much
>>>> > *harder* for compilers than alias assumptions.
>>>> Which is why I like the Fortran model much better. In Fortran,
>>>>
>>>
>>> I am happy for you and I agree that Fortran is well suited to certain types
>>> of applications.
>>>
>>>> - if you have overlapping dummy arguments, you cannot store
>>>> a value through one and access it through another one
>>>> (which is rarely checked, unfortunately)
>>>
>>> Indeed. And why is that?
>>
>>In the case of gfortran, because nobody to date has stepped
>>up to write a patch. There is also a run-time overhead.
>
>
> Yes.
>
>>> If I had known about Fortran's issues with alias analysis, I
>>> might have even included in a 6 page paper a reference to Fortran
>>> alias analysis -something like this:
>>
>>> " Fortran has similar problems with similar assumptions:
>>> "anything may happen: the program may appear to run normally,
>>> or produce incorrect answers, or behave unpredictably." [24]."
>>
>>In Fortran, the wording is clearer than C's weasel-word "undefined
>>behavior".
>
>
> Absolutely agree that "undefined behavior" is an awful concept.
> I think it is used to evade burden on the compilers for error checking and
> to evade plainly stating proposed limitations to C expressiveness.

However, the effect is the same, but it brings on many more
misunderstandings.

>>Code which does so is in violation of a "shall"
>>directive, so the program is erronous. This is not a violation
>>of a constraint (which are clearly labeled and numbered) so a
>>compiler is not required to diagnose it.
>>
>>Case closed.
>
>>>
>>>> > Since you bring it up, for me the way C originally handled
>>>> > integer overflow was sloppy and sometimes dangerous - it was an
>>>> > engineering tradeoff made to make fast code and simple compilation.
>>>> > BUT the ISO-C approach is mathematically incoherent and even more
>>>> > dangerous - because semantics is unpredictable.
>>>> Signed integer overflow is an error, period (the same in
>>>> Fortran as in C).
>>>> > Ironically, as C compilers muddied int arithmetic, processors
>>>> > became much better about native signed arithmetic. Mod 2^k 2s
>>>> > complement, which is native on the vast majority of modern
>>>> > processors is mathematically coherent even if it is hard to
>>>> > work with.
>>>> Very hard, and a source of errors...
>>>
>>> Programming is hard. Some languages have runtime to catch
>>> those errrors,
>>
>>Run-time checks to catch thinking errors in mod 2^n arithmetic?
>>I am amazed, please tell me what these are.
>
>
> You can, if you want, select ftrapv on both gcc and
> clang. This will catch overflows.

There are no overflows in 2^n arithmetic.

>
>>> and even in some C compilers we have an option for ftrapv. But
>>> there are tradeoffs. This is why Fortran uses floating point
>>> arithmetic even though it is a notorious source of errors.
>>
>>C also uses floating point, in case you had not noticed - the types
>>are called "float" and "double".
>
>
> It does for the same reason.

??

>
>>>> > But what we have in ISO C makes arithmetic depend on vagaries
>>>> > of the optimizer and produces paradoxes.
>>>> Ah, no. It means that an erroneous program gets random results,
>>>
>>> With modular arithmetic, or even saturating as you have on some
>>> processors, you do not get random results. You may not get the
>>> results you expect if you think 4 byte or even 8 or 16 byte "ints"
>>> can represent all of Z.
>>
>>You are confusing the C language with whatever happens on a
>>particular system. Might I point out section 5.1.2.3 of n2346.pdf:
>
>
> You are confusing your interpretation of C standard for laws of physics. I propose
> different semantics.

OK, so I understand that you want another language, not C.

> BTW: C overflow semantics are not described in the C standard at all. The standard
> leaves it up to the implementation.
>
>># The semantic descriptions in this document describe the behavior of
>># an abstract machine in which issues of optimization are irrelevant.
>>
>>The C standard is the specification for that abstract machine.
>>As long as you stick to that, you're reasonably safe (and you can
>>holler at compiler writers if you find bugs). If you insist on
>>peculiarities of a particular implementation... well, you violated
>>the contract, it's your fault.
>>
>
> And overflow is specifically stated to be undefined.

MitchAlsup wrote:
> On Thursday, October 14, 2021 at 6:05:22 AM UTC-5, Branimir Maksimovic wrote:
>> Fortran is pre structured era, spagetti code. Good for
>> arrays, not mutch for anything else :P
>> Good luck with network code or parsing with FORTRAN :P
> <
> I lead a team that built a FORTRAN runtime library using nothing other
> than FORTRAN.

Ratfor was a structured language preprocessor by Brian Kernighan in 1974
who said it was "shamelessly stolen from the language C",
was written in Ratfor and spit out Fortran 66,
which when compiled processed the Ratfor.

Never used it myself.

EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> MitchAlsup wrote:
>> On Thursday, October 14, 2021 at 6:05:22 AM UTC-5, Branimir Maksimovic wrote:
>>> Fortran is pre structured era, spagetti code. Good for
>>> arrays, not mutch for anything else :P
>>> Good luck with network code or parsing with FORTRAN :P
>> <
>> I lead a team that built a FORTRAN runtime library using nothing other
>> than FORTRAN.
>
> Ratfor was a structured language preprocessor by Brian Kernighan in 1974
> who said it was "shamelessly stolen from the language C",
> was written in Ratfor and spit out Fortran 66,
> which when compiled processed the Ratfor.

It was actually used as prior art for IF/THEN/ELSE, or Fortran 77
might not even have gotten that.

For one of the inventors of C, Kernighan certainly had a lot of
contact with Fortran. I like the story that he wrote a version
of runoff for his PhD thesis (in pre-77 Fortran, no less) so
his was the first computer-printed PhD thesis at Princeton.

> Never used it myself.

Neither have I, when I started serious programming, Fortran 77
was already available.

"Undefined behavior" does not mean "programming error" and never has.
One meaning is just something not specified explicitly in the standard.

----
If a “shall” or “shall not” requirement that appears outside of a constraint or
runtime-constraint is violated, the behavior is undefined. Undefined behavior
is otherwise indicated in this International Standard by the words “undefined
behavior” or by the omission
of any explicit definition of behavior. There is no difference in emphasis among
these three; they all describe “behavior that is undefined”.
----

Note: "or by the omission of any explicit definition of behavior.". What does pthread_create do? There
is no explicit definition in the C Standard. What does asm do? Same. What does mmap do? Same again.
What happens when device driver code initiates a DMA operation? Not one word in the standard.
It is impossible to write a serious C program without producing undefined behavior and, certainly,
implementations are permitted a wide range of action on encountering undefined behavior
An implementation that chooses, e.g. to implement signed arithmetic by delegating semantics to the target
processor would be conforming.

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.

This is basic. If you are confused about it, your interpretations of the C standard are not going to
make any sense at all.

On 10/14/2021 11:49 AM, Thomas Koenig wrote:
> Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
>> On Thursday, October 14, 2021 at 9:24:43 AM UTC-5, David Brown wrote:
>>
>>> The standard has to provide the lowest common denominator - the most
>>> vague version of the language, with the most undefined behaviours and
>>> implementation-defined behaviours. It is then up to implementations to
>>> tighten these details as appropriate, or offer options for additional
>>> semantics.
>>>
>>
>> I disagree. Overuse of UB degrades the semantics of the language
>> and reduces its utility. The overhead in dealing with unpredictable
>> unsound optimizations is a serious drag on the utility of C.
>
> Let's called "undefined behavior" what it is - programming errors,
> and see how much your sentence makes sense then.
>

This would only be true IMO, if all of the "undefined behavior" cases
only represented things which could happen unintentionally, or which
otherwise did not serve any use.

Many of the common cases are things which have "perfectly reasonable"
behavior on most targets, and are themselves useful for writing
straightforward and performant code, but none the less fall outside the
scope of the C standard.

Eg:
Signed right shift;
Signed integer overflow;
Ability to cast and dereference pointers as
"whatever the hell one wants";
...

For general consistency, one might define:
Signed right shift is an arithmetic right shift;
Signed integer overflow is modular;
Pointers exist within a linear address space,
types have concrete sizes and representations;
Floating point types follow IEEE format,
with the same endianess as integer types;
...

Then, say, one defines several sub-models:
IP16 (int/pointer are 16 bits, long is 32 bits, long long is opt 64)
LP32 (int is 16 bits, long / pointer are 32 bits, long long is opt 64)
ILP32 (int/long/pointer are 32 bits, long long is 64 bits)
LLP64 (int / long are 32 bits, long long / pointer are 64 bits)
LP64 (int is 32 bits, long / long long / pointer are 64 bits)

So, eg:
IP16, 16-bit machines;
LP32, 16-bit, or 32 bit machines faking a 16-bit machine;
ILP32, 32-bit machines
...

Then, say, one allows a more restricted form of aliasing rules:
Dereferening a volatile pointer may alias with anything;
Any explicit cast and dereference operation may also alias;
...

In this case, one could gain some of the performance benefits of
strict-aliasing semantics, without them having the annoying property of
breaking code which is built on top of using pointer casts for
type-punning and similar.

Some secondary (likely more controversial) rules:
We can assume that the machine is little endian;
Or, maybe add official PP defines for machine endianess (*).
We can assume that shift operators are size-modular;
Eg: (x<<64)==x, for long-long and smaller.
The nominal type for array indexing is 'int';
...

Say, a machine using LP64 may have built-in defines like, say:
__ARCH_LP64__
__ARCH_LITTLE_ENDIAN__
...

Or if say, it is something like my RIL3 IR, which can compile code in a
sub-mode where it can be either ILP32 or LP64 and thus 'sizeof(long)'
and similar is not be known until later, this can be specified as well
via a define.

Maybe also define how C would behave on a machine with a 128-bit address
space.

Current thinking:
int/long/long long: Same sizes as in LP64
pointer: 128 bits
intptr_t / etc: also 128 bits

Might also specify 128-bit integer literals.

Maybe also a literal type suffix specifically for machine addresses /
pointers, ... This behaves like if one did the usual thing of using an
appropriate suffix for the specific machine and then cast it to 'void *'
or similar.

Say:
0xA0003F80C000P //or similar
Maps to the equivalent of:
(void *)0xA0003F80C000ULL

Though, need not map 1:1 to the integer representation on machines where
the logical mapping is not itself 1:1, say:
0x43219876CDEF123456789ABCP
Might map to:
(void *)0x000043219876CDEF0000123456789ABCUI128

Within the possible 96-bit address space extension (with the 0000 bits
still being used for dynamic type-tags and flags and similar).

Though, some of this depends on how I interpret pointer casts between
int128 and xptr types (whether it is a direct 1:1 cast, or whether the
cast shuffles the bits around so that the integer representation looks
like a linear 96 bit address, with 32 bits of tagging data in the
high-order bits).

Though, granted, this is with a funky default addressing scheme based
around 48-bit "quadrants" (1/4 petabyte), with everything above the
48-bit mark being addressed in terms of "quads".

Some of this is partly an artifact of trying to come up with ways to
implement this feature in a way which doesn't ruin timing (direct linear
96-bit address calculations are no-go; hence the scheme based on pairs
of 48 bit addresses).

Actually, if we have _BitInt(n), might also add that there is a way to
specify literal values of this type (vs, say, an implementation which
has huge integer types but no way to express huge integer literals).

....

More speculatively:
What if we also specify a format which can be used to specify things
like source files, library dependencies, ... in a C based project;
Which is not itself tied to a particular build-system or build tool (we
already have enough of these).

This could be sort of like a highly stripped down and minimal subset of
Makefile or CMake syntax, intended to be reasonably easy to parse and
generic.

Well, or someone could be a jerk and base the whole thing on MSBuild
syntax (XML based)...

....

On Thursday, October 14, 2021 at 12:57:30 PM UTC-5, Thomas Koenig wrote:
> EricP <ThatWould...@thevillage.com> schrieb:
> > MitchAlsup wrote:
> >> On Thursday, October 14, 2021 at 6:05:22 AM UTC-5, Branimir Maksimovic wrote:
> >>> Fortran is pre structured era, spagetti code. Good for
> >>> arrays, not mutch for anything else :P
> >>> Good luck with network code or parsing with FORTRAN :P
> >> <
> >> I lead a team that built a FORTRAN runtime library using nothing other
> >> than FORTRAN.
> >
> > Ratfor was a structured language preprocessor by Brian Kernighan in 1974
> > who said it was "shamelessly stolen from the language C",
> > was written in Ratfor and spit out Fortran 66,
> > which when compiled processed the Ratfor.
> It was actually used as prior art for IF/THEN/ELSE, or Fortran 77
> might not even have gotten that.
>
> For one of the inventors of C, Kernighan certainly had a lot of
> contact with Fortran. I like the story that he wrote a version
> of runoff for his PhD thesis (in pre-77 Fortran, no less) so
> his was the first computer-printed PhD thesis at Princeton.
<
I wrote a typesetting program n ALGOL on the 1108 for a
CMU programming class. The program was only about 30
lines of code.
>
> > Never used it myself.
>
> Neither have I, when I started serious programming, Fortran 77
> was already available.
<
F77 was the language and target for the runtime library I lead.
Negligibly different then the Watfiv I used at CMU.

On Thursday, October 14, 2021 at 1:20:29 PM UTC-5, victor....@gmail.com wrote:
> "Undefined behavior" does not mean "programming error" and never has.
> One meaning is just something not specified explicitly in the standard.
>
> ----
> If a “shall” or “shall not” requirement that appears outside of a constraint or
> runtime-constraint is violated, the behavior is undefined. Undefined behavior
> is otherwise indicated in this International Standard by the words “undefined
> behavior” or by the omission
> of any explicit definition of behavior. There is no difference in emphasis among
> these three; they all describe “behavior that is undefined”.
> ----
>
> Note: "or by the omission of any explicit definition of behavior.". What does pthread_create do? There
> is no explicit definition in the C Standard. What does asm do? Same. What does mmap do? Same again.
> What happens when device driver code initiates a DMA operation? Not one word in the standard.
>
> It is impossible to write a serious C program without producing undefined behavior
<
The original UNIX 'cat' has undefined behavior ?!?!
all it does is copy an input stream to an output stream.
<
> and, certainly,
> implementations are permitted a wide range of action on encountering undefined behavior
> An implementation that chooses, e.g. to implement signed arithmetic by delegating semantics to the target
> processor would be conforming.
>
> 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.
>
> This is basic. If you are confused about it, your interpretations of the C standard are not going to
> make any sense at all.

George Neuner [2021-10-13 14:26:18] wrote:
> You can separate the marking flags so as not to have to /write/ to
> objects during marking, but you must scan every live object.

Indeed. Using separate flags can save you from modifying those many
cache lines and it can also reduce save you from accessing the cache
line storing an object when encountering a second reference to it.
This second effect is usually quite secondary, tho, since most objects
have typically only a single reference to them (as is well known from
ref-count schemes where the vast majority of ref-counts are 1).

> Sweep has to touch, at minimum, every dead object.

Some allocation schemes can keep the metadata modified during sweep
separately from the actual objects (typically some kind of bibop
allocation where each "page" has a bitmap keeping track of which object
is free).

That can reduce the amount of memory accessed during sweep to less than
what is accessed during mark.

> If you are using the GC normally, there almost always will be far more
> dead objects than live objects.

That's what you want ideally for a copying GC, indeed, but in my
experience this is rarely the case. Cases where I've seen that are for
the nurseries of generational GCs (where copying GCs are popular for
that reason).

If you have more dead objects than live objects, it means your GC
imposes an overhead of more than 100% (and if you have "far more" dead
objects, than it's even "far worse"). As mentioned, for the nursery of
a generational GC this is not a problem since the nursery is a small
fraction of the total heap anyway, but such an overhead over the whole
heap would be rather problematic (if it's not, then there's a high
chance that your program doesn't actually care about performance at all
anyway and any GC scheme would be fine as well).

Don't get me wrong: I love copying schemes and I do think they work very
well in most cases, but it doesn't come for free.

> Again, the assumption is that the live set is much smaller than the
> dead set. Which IS the case for most programs in GC'd languages.

I think this is not inherently true. Rather, it needs to be true for
the GC to work efficiently, so the GC itself is tweaked so as to try and
make it true more often, e.g. by using generations (or other partitioned
heap schemes) and using heuristics that try to guess which partition to
GC this cycle (hoping it will hold the higher fraction of dead objects).

But over the whole heap, we still want to try and minimize the
proportion of dead objects, since they are an undesirable overhead
(that may increase VM or cache pressure).

Stefan

David Brown [2021-10-14 16:24:40] wrote:
> The standard has to provide the lowest common denominator - the most
> vague version of the language, with the most undefined behaviours and
> implementation-defined behaviours. It is then up to implementations to
> tighten these details as appropriate, or offer options for additional
> semantics.
>
> But programmers have to understand that the C language is what is
> described by the standards, and this is the default for compilers - if
> the C standards don't say what happens when you do X, then neither does
> the compiler.

There lies the problem: the standard is bound by the "lowest common
denominator" and then compilers in turn use this lower target, rather
than having an intermediate target which is made more precise by relying
on extra knowledge of the target system.

This has the side effect that if you take code which relies on having
a flat address space, it can't be used reliably even if you make sure
it's only used on systems with a flat address space.

[ I mean, yes, in practice, it can be used, but you can never be sure
it'll work: instead, you have to try it out, see where it breaks,
figure out which trick to use to prevent the undesired "optimization",
... until you decide that it experimentally seems to work well enough
for the current version of your compiler. ]

Maybe for `<` and `-` between pointers to unrelated objects, the
standard should say that this is not UB when used on a system with
a flat address space (and that while the exact return value is
implementation dependent, it obeys the usual rules of those operators).

Stefan

> Maybe for `<` and `-` between pointers to unrelated objects, the
> standard should say that this is not UB when used on a system with
> a flat address space (and that while the exact return value is
> implementation dependent, it obeys the usual rules of those operators).

Rather than "a system with a flat address space" I guess it would
instead introduce a notion of "class of target" (a bit like the standard
already distinguishes between hosted and non-hosted cases). After all,
a compiler on a system with a flat address space might very well decide
not to obey the above refinement (e.g. because it does its own
copying-GC internally, I'm thinking here of something like
a C interpreter) and thus choose a different "target class" than the one
that would be more naturally chosen for the target system.

Stefan

Victor Yodaiken <victor.yodaiken@gmail.com> writes:

> [...] GCC says that you can use unions for type puns (which I find
> awkward) although the standard does not.

The C standard says very plainly that type punning may be achieved
by means of union member access. Quoting 6.5.2.3, paragraph 3,
footnote 95, first sentence, from N1570

If the member used to read the contents of a union object is
not the same as the member last used to store a value in the
object, the appropriate part of the object representation of
the value is reinterpreted as an object representation in the
new type as described in 6.2.6 (a process sometimes called
"type punning").

Thomas Koenig <tkoenig@netcologne.de> writes:

> For one of the inventors of C, Kernighan certainly had a lot of
> contact with Fortran. [...]

Kernighan is not one of the inventors of C. He worked with
Dennis Ritchie writing the book "The C Programming Language",
but that was years after C was developed, and he did not play
any role in inventing the language. Kernighan himself has
said this ("it's entirely Dennis Ritchie's work").

According to Tim Rentsch <tr.17687@z991.linuxsc.com>:
>Thomas Koenig <tkoenig@netcologne.de> writes:
>
>> For one of the inventors of C, Kernighan certainly had a lot of
>> contact with Fortran. [...]
>
>Kernighan is not one of the inventors of C. He worked with
>Dennis Ritchie writing the book "The C Programming Language",
>but that was years after C was developed, and he did not play
>any role in inventing the language. Kernighan himself has
>said this ("it's entirely Dennis Ritchie's work").

In the 1960s and early 1970s everyone in academic computer
science knew Fortran even if we didn't use it much. It was
the language that could, with some effort, run on anything.

I used Ratfor a little. I got it running on our PDP-10 at Yale
and arranged to pass through the line sequence numbers so that
errors from the Fortran compiler would match the ones in the
original source. I think I wrote the glue in bliss36.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

EricP <ThatWouldBeTelling@thevillage.com> writes:

> Tim Rentsch wrote:
>
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>
>>> Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
>>>
>>>> Can you cast a pointer to a different type? Sure.
>>>>
>>>> Can you dereference it?
>>>
>>> No.
>>
>> This statement is wrong, or at best much overstated. There are
>> plenty of situations where a C pointer value converted to a
>> different type may be safely and portably dereferenced.
>> Certainly that isn't always true, but it isn't always false
>> either.
>
> The problem is not accessing memory through a cast pointer. It is
> that according to C's rules for TBAA Typed Based Alias Analysis
> the optimizer is not required to recognize that accesses through
> different pointer types may be to the same memory location. [...]

My statement about safe and portable dereferencing includes
observing the boundaries of C's effective type rules.

(Note that "effective type" is the term used in the C standard
itself, not "strict aliasing" or "type based alias analysis",
even though it is common for people to use the latter terms when
what they are talking about are implications of C's effective
type rules.)

David Brown <david.brown@hesbynett.no> wrote:
> On 13/10/2021 11:11, Branimir Maksimovic wrote:
>> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>> On 10/12/2021 7:21 PM, Branimir Maksimovic wrote:
>>>> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>>>> To me, the big advantage of Ada (it's a woman's name, not an acronym -
>>>>> hence not all caps) is that its syntax makes it easier to write correct
>>>>> programs, and harder, though of course not impossible, to make the kind
>>>>> of errors this thread has been talking about.
>>>>>
>>>>> But others here are far more qualified to discuss this than I am.
>>>>>
>>>> OK, I'll try it, it, but on macOS I can't have compiler, let alone
>>>> IDE support :P
>>>
>>> Again, others are more qualified than I am to comment, but it appears
>>> that GNAT (GNU Ada compiler) is available on MacOS.
>>>
>>
>> Yes, but is only for x86, does not builds for my M1.
>> Interrestingly except gforth (without extensions)
>> there is no forth for M1, as well.
>
> I think that is mainly due to Apple's determination to stop people using
> Apple devices for any development other than Apple applications using
> Apple's tools and paying Apple's fees (for whatever they can get away
> with).

XCode is a free download.

> I can appreciate that an M1 machine gives you a lot of
> processing power in a small and low-power device, but they seem to be
> competing with Windows in their battle to make programmers' and small
> developers' lives as inconvenient as possible.
>
> Maybe they'll make an Ada front-end to clang, and call it "gnat" to
> confuse their users like they did with their C compiler.

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>> Maybe for `<` and `-` between pointers to unrelated objects, the
>> standard should say that this is not UB when used on a system with
>> a flat address space (and that while the exact return value is
>> implementation dependent, it obeys the usual rules of those operators).
>
> Rather than "a system with a flat address space" I guess it would
> instead introduce a notion of "class of target" (a bit like the standard
> already distinguishes between hosted and non-hosted cases). After all,
> a compiler on a system with a flat address space might very well decide
> not to obey the above refinement (e.g. because it does its own
> copying-GC internally, I'm thinking here of something like
> a C interpreter) and thus choose a different "target class" than the one
> that would be more naturally chosen for the target system.

So, a pointer would be a handle instead of a memory address?

I don't see offhand how that would work with pointer arithmetic
(which is central to C).

BGB <cr88192@gmail.com> schrieb:
> On 10/14/2021 11:49 AM, Thomas Koenig wrote:
>> Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
>>> On Thursday, October 14, 2021 at 9:24:43 AM UTC-5, David Brown wrote:
>>>
>>>> The standard has to provide the lowest common denominator - the most
>>>> vague version of the language, with the most undefined behaviours and
>>>> implementation-defined behaviours. It is then up to implementations to
>>>> tighten these details as appropriate, or offer options for additional
>>>> semantics.
>>>>
>>>
>>> I disagree. Overuse of UB degrades the semantics of the language
>>> and reduces its utility. The overhead in dealing with unpredictable
>>> unsound optimizations is a serious drag on the utility of C.
>>
>> Let's called "undefined behavior" what it is - programming errors,
>> and see how much your sentence makes sense then.
>>
>
> This would only be true IMO, if all of the "undefined behavior" cases
> only represented things which could happen unintentionally, or which
> otherwise did not serve any use.
>
> Many of the common cases are things which have "perfectly reasonable"
> behavior on most targets, and are themselves useful for writing
> straightforward and performant code, but none the less fall outside the
> scope of the C standard.

In this case, they need to be documented in the compiler you use
(if you use your own, you are of course free to do anything :-)

This will lock the code into that particular compiler, or into a
set of compilers which happen to support the same feature. IMHO,
this is bad. Compiler vendors who manage to lock their customers
into their product to generate additional revenue will probably
have a different opinion.

>
>
> Eg:
> Signed right shift;
> Signed integer overflow;

That is something that I do not understand.

C has perfectly good unsigned integers. Instead of (assuming 32-bit
ints here)

int i;
....
i = i >> 1;

what's wrong with

i = ((unsigned int) i) >> 1;

or

i = (((unsigned int) i) >> 1) | (((unsigned int) i) & (1u << 31));

thus telling the compiler exactly what it should do with the sign
bit, and being portable at the same time? If you don't like to
write it out, put it in a macro or a static inline function in a
header somewhere (better type-safety that way), and you're done.

> Ability to cast and dereference pointers as
> "whatever the hell one wants";

"cast" using memcpy to make your intentions clear to the compiler.

On 10/15/2021 1:26 AM, Thomas Koenig wrote:
> BGB <cr88192@gmail.com> schrieb:
>> On 10/14/2021 11:49 AM, Thomas Koenig wrote:
>>> Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
>>>> On Thursday, October 14, 2021 at 9:24:43 AM UTC-5, David Brown wrote:
>>>>
>>>>> The standard has to provide the lowest common denominator - the most
>>>>> vague version of the language, with the most undefined behaviours and
>>>>> implementation-defined behaviours. It is then up to implementations to
>>>>> tighten these details as appropriate, or offer options for additional
>>>>> semantics.
>>>>>
>>>>
>>>> I disagree. Overuse of UB degrades the semantics of the language
>>>> and reduces its utility. The overhead in dealing with unpredictable
>>>> unsound optimizations is a serious drag on the utility of C.
>>>
>>> Let's called "undefined behavior" what it is - programming errors,
>>> and see how much your sentence makes sense then.
>>>
>>
>> This would only be true IMO, if all of the "undefined behavior" cases
>> only represented things which could happen unintentionally, or which
>> otherwise did not serve any use.
>>
>> Many of the common cases are things which have "perfectly reasonable"
>> behavior on most targets, and are themselves useful for writing
>> straightforward and performant code, but none the less fall outside the
>> scope of the C standard.
>
> In this case, they need to be documented in the compiler you use
> (if you use your own, you are of course free to do anything :-)
>
> This will lock the code into that particular compiler, or into a
> set of compilers which happen to support the same feature. IMHO,
> this is bad. Compiler vendors who manage to lock their customers
> into their product to generate additional revenue will probably
> have a different opinion.
>

Most of this same stuff works on existing compilers as-is.

Eg, one can write code using many of the rules I described, throw it at
MSVC or similar, and it just magically works.

A lot of this also works with GCC and Clang, with the main exception
being issues with strict aliasing (eg, needing "-fno-strict-aliasing"
and similar).

Some of us would prefer if "-fno-strict-aliasing" was the default, and
"-fstrict-aliasing" was left more for those who like to live a little
more dangerously...

>>
>>
>> Eg:
>> Signed right shift;
>> Signed integer overflow;
>
> That is something that I do not understand.
>
> C has perfectly good unsigned integers. Instead of (assuming 32-bit
> ints here)
>
> int i;
> ...
> i = i >> 1;
>
> what's wrong with
>
> i = ((unsigned int) i) >> 1;
>
> or
>
> i = (((unsigned int) i) >> 1) | (((unsigned int) i) & (1u << 31));
>
> thus telling the compiler exactly what it should do with the sign
> bit, and being portable at the same time? If you don't like to
> write it out, put it in a macro or a static inline function in a
> header somewhere (better type-safety that way), and you're done.
>

This requires heavy lifting from the compiler to realize that this
convoluted mess represents an arithmetic shift.

It is easier, for both normal programmers and the compiler implementers,
to declare that signed right shift is an arithmetic shift.

It is like asking people to use byte operations and shifts to read
values. Some compilers can figure it out (and turn it into a plain
load), while some others will give byte operations and shifts.

>> Ability to cast and dereference pointers as
>> "whatever the hell one wants";
>
> "cast" using memcpy to make your intentions clear to the compiler.
>

It depends on the compiler being clever to make it "not suck" (eg: turn
the memcpy call into a register operation or similar).

So, if the compiler is clever, it works.
But, if the compiler is not as clever and tries to do a memory copy
operation (or, worse, actually calls memcpy), then it sucks...

It is also a lot more awkward to type than (ab)using the use of pointer
casts and dereferencing.

The main tradeoff is that one can't use strict aliasing semantics, but
then it is notable that a number of projects explicitly disable
strict-aliasing on compilers which use it.

And, some other compilers have opted instead against using strict
aliasing by default. Granted, one of these compilers also didn't bother
adding any C99 features for well over a decade, and even then just kinda
half-assed it.

Also, this:
https://www.godbolt.org/z/Wqz99fK11

Or (with MSVC):
long long a, b;
a=30;
memcpy(&b, &a, sizeof(long long));
return b;
Becomes:
sub rsp, 40 ; 00000028H
mov r8d, 8
mov QWORD PTR a$[rsp], 30
lea rdx, QWORD PTR a$[rsp]
lea rcx, QWORD PTR b$[rsp]
call memcpy
mov eax, DWORD PTR b$[rsp]
add rsp, 40 ; 00000028H
ret 0

Note the:
call memcpy

Or, as can be paraphrased:
Don't do this sort of thing with MSVC; it kinda risks suck...

One can then argue:
"Well, /O2 makes it not suck, why not just use /O2?"

But, "/O2" is itself a tradeoff, it also enables a bunch of wacky
auto-vectorization stuff which is at times prone to make the program
slower than with "/O1".

Also, some older versions (sadly, "godbolt.org" only has newer MSVC
versions), were prone to transform it into a "similarly awful" sequence,
namely setting up for and using "REP MOVSB".

Now, what if we use a casts and dereferencing:
long long a, b;
a=30;
*(long long *)(&b)=*(long long *)(&a);
return b;
We get:
mov eax, 30
ret 0

Or, IOW, MSVC is a lot more clever about pointer operations.
Granted, this does still respect the type system.

What if we actually type pun:
double f;
long long a, b;
f=30;
*(long long *)(&b)=*(long long *)(&f);
return b;
We get:
movsd xmm0, QWORD PTR __real@403e000000000000
movsd QWORD PTR b$[rsp], xmm0
mov eax, DWORD PTR b$[rsp]
ret 0

But, meh, whatever, good enough...
At least it is better than a function call to "memcpy"...

On 2021-10-14, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>> Fortran is pre structured era, spagetti code.
>
>
> Fortran has evolved. Look at current Fortran, not at something from over
> half a century ago.
Well, it's not FORTRAN anymore then :P

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...