Re: [PATCH v17 2/2] c: Add __countof__ operator

2024-10-26 Thread Alejandro Colomar via Gcc 
Hi mirabilos,

On Sun, Oct 27, 2024 at 01:40:23AM GMT, mirabilos wrote:
> Not too sure what the root context of this thread is, but in BSD land

The root context is that

-  _Lengthof was added to C2y in the Minnesota meeting.  It was proposed
   by me, although they pushed me to rename the operator to _Lengthof,
   which I was strongly against.  The semantics of the operator are
   agreed by everyone, but the name is under fight.

-  I'm sending a patch to GCC proposing __countof__, since overloading
   length for both string length and array number of elements is (IMO)
   going to promote off-by-one bugs in string-handling code (and I've
   shown two bug fixes for bugs that I found and fixed in shadow utils
   in which this precise ambiguous naming issue was present, so it's not
   just theoretical).  That is, I'm trying GCC to force WG14 to change
   the name of the operator (which BTW was influenced by a survey
   conducted on programmers some of which declared hating C and not
   wanting to use it ever, so I refuse to acknowledge validity of the
   results of that survey; that survey also didn't inform of possible
   problems of each name).

So basically, we're on a fight for the standard name of the operator.
It seems that the names that have more serious support are

-  _Lengthof
-  _Countof
-  _Nelementsof
-  _Nelemsof

Anything else can be just discarded, as they didn't receive many votes.
Although I presonally would like anything that is not _Lengthof (or a
derivative), whatever it is.

> we use NELEM or NENTS for (sizeof(a) / sizeof((a)[0])) generally.

Yup, I know.  I think I prefer to keep a *of suffix for the operator for
consistency with the other operators, which is why _Nelemsof was
considered.

> 
> >> and Unix/Plan9.
> 
> yay!
> 
> >Another thing I think would be interesting is to allow to choose a
> >matrix of options:
> 
> I pointed out in Fedi (also mostly contextless) to thephd that another
> option is devotee-style preferential voting (Condorcet etc. and “none of
> the above” and “further discussion” can be voted atop or in the middle
> or below the options) for this kind of thing.

+1


Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Re: [PATCH v17 2/2] c: Add __countof__ operator

2024-10-26 Thread Thorsten Glaser 
Hi Alejandro,

>On Sun, Oct 27, 2024 at 01:40:23AM GMT, mirabilos wrote:
>> Not too sure what the root context of this thread is, but in BSD land
>
>The root context is that
>
>-  _Lengthof was added to C2y in the Minnesota meeting.  It was proposed

where/how would this be used for? Also, do you have the n.pdf link
handy? I don’t actively follow C other than what thephd posts.

>-  I'm sending a patch to GCC proposing __countof__, since overloading
>   length for both string length and array number of elements is (IMO)
>   going to promote off-by-one bugs in string-handling code (and I've

Definitely! The string length is one less than the amount of array
elements it has (works for char and wide strings).

>-  _Nelementsof
>-  _Nelemsof

If you want to shorten elements, elts is probably seen more
often than elems, at least in my experience. But this is very
low-grade bikeshedding, so just me pointing it out but putting
not much weight behind it.

bye,
//mirabilos
PS: Got any contacts in the OpenBSD and NetBSD worlds that can
add input? They invest a lot into good C code as well, in
the OpenBSD case rather heavily (if opinionated).
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

Re: [PATCH v17 2/2] c: Add __countof__ operator

2024-10-26 Thread Alejandro Colomar via Gcc 
On Sat, Oct 26, 2024 at 12:07:04PM GMT, Alejandro Colomar wrote:
> [Moved from gcc-patches@ to gcc@]
> 
> Hi JeanHeyd, наб,
> 
> I see you (JeanHeyd) are developing yet another survey about the names
> for this new operator.  Let me ask you to be clear about my fear of
> ambiguity with null-terminated strings which are stored within arrays
> and the length of both entities differ, usually by exactly one, being a
> potential cause of a confusion that might result in buffer overflows, or
> other kinds of errors (and it would be interesting to mention that I've
> presented a link to an actual bug of that class in shadow-utils, which I
> fixed recently).  I would also like the survey to be presented to
> programmers that like programming in C; I would refuse to acknowledge
> the results of any survey that is presented to C++ or rust programmers
> who acknowledge not wanting to program in C ever again.  They have a
> clear conflict of interest.  If this survey is conducted, it should
> include the gcc and glibc communities, and the resons why each name is

It would also be interesting to hear the opinion of people from the BSDs
and Unix/Plan9.

> considered good and bad should be clearly stated alongside the options,
> in a detailed rationale.
> 
> For extentof(), my only caveat is that one might want to add a 2-args
> operator (or macro) that has the C++ semantics, that is, allowing you to
> specify the dimension of the array that you want.  I don't see why it
> would be useful, but didn't want to preclude it either.  But other than
> that, I'm okay with that name.
> 
> Another thing is that I'd prefer it to be based on email, or something
> that doesn't impose a barrier to those who don't have an account in a
> given platform, and don't want to create it.
> 
> Thanks for your interest in this operator!
> 
> Have a lovely day!
> Alex
> 
> 
> P.S.:  наб, you asked why not array_size().  I agree with the defenders
> of lengthof that size should not be overloaded to mean both the number
> of bytes and the number of elements of an object (although I'm closer to
> accepting overloading the term "size" than overloading the term
> "length", since size at least doesn't promote off-by-one errors).  Also,
> I have a macro sizeof_array() which I define as
> 
>   #define sizeof_array(a)  (countof(a) * sizeof((a)[0]))
> 
> It would be very weird and confusing to have
> 
>   #define sizeof_array(a)  (array_size(a) * sizeof((a)[0]))
> 
> 
> 
> On Sat, Oct 26, 2024 at 12:10:56AM GMT, Alejandro Colomar wrote:
> > Hi Joseph,
> > 
> > On Fri, Oct 25, 2024 at 08:44:15PM GMT, Joseph Myers wrote:
> > > I don't see the use of pedwarn_c23 and associated tests (error with 
> > > -std=c23 -pedantic-errors, warning with -std=c23 -pedantic, no diagnostic 
> > > with -std=c23 -pedantic-errors -Wno-c23-c2y-compat, no diagnostic with 
> > > -std=c2y -pedantic-errors, warning with -std=c2y -pedantic-errors 
> > > -Wc23-c2y-compat), previously discussed in comments on v13, that would be 
> > > appropriate before considering this for inclusion with an appropriate 
> > > substitution of names.
> > 
> > I removed it because I renamed it to __countof__, which is a GNU
> > extension, and thus should not be warned by -Wpedantic.  As part of my
> > opposition to _Lengthof, I will not provide you with that part, which
> > would amount to basically giving you _Lengthof but not.  As part of the
> > editorialising process, you'll also have to add pedantic warnings, if
> > that's what you want to do.  Again, I will earnestly ask to once more to
> > consider __countof__, but it's up to you.
> > 
> > Have a lovely night!
> > Alex
> > 
> > -- 
> > 
> 
> 
> 
> -- 
> 



-- 



signature.asc
Description: PGP signature

Re: [PATCH v17 2/2] c: Add __countof__ operator

2024-10-26 Thread Alejandro Colomar via Gcc 
On Sat, Oct 26, 2024 at 12:27:03PM GMT, Alejandro Colomar wrote:
> On Sat, Oct 26, 2024 at 12:12:39PM GMT, Alejandro Colomar wrote:
> > On Sat, Oct 26, 2024 at 12:07:04PM GMT, Alejandro Colomar wrote:
> > > [Moved from gcc-patches@ to gcc@]
> > > 
> > > Hi JeanHeyd, наб,
> > > 
> > > I see you (JeanHeyd) are developing yet another survey about the names
> > > for this new operator.  Let me ask you to be clear about my fear of
> > > ambiguity with null-terminated strings which are stored within arrays
> > > and the length of both entities differ, usually by exactly one, being a
> > > potential cause of a confusion that might result in buffer overflows, or
> > > other kinds of errors (and it would be interesting to mention that I've
> > > presented a link to an actual bug of that class in shadow-utils, which I
> > > fixed recently).  I would also like the survey to be presented to
> > > programmers that like programming in C; I would refuse to acknowledge
> > > the results of any survey that is presented to C++ or rust programmers
> > > who acknowledge not wanting to program in C ever again.  They have a
> > > clear conflict of interest.  If this survey is conducted, it should
> > > include the gcc and glibc communities, and the resons why each name is
> > 
> > It would also be interesting to hear the opinion of people from the BSDs
> > and Unix/Plan9.
> > 
> > > considered good and bad should be clearly stated alongside the options,
> > > in a detailed rationale.
> > > 
> > > For extentof(), my only caveat is that one might want to add a 2-args
> > > operator (or macro) that has the C++ semantics, that is, allowing you to
> > > specify the dimension of the array that you want.  I don't see why it
> > > would be useful, but didn't want to preclude it either.  But other than
> > > that, I'm okay with that name.
> > > 
> > > Another thing is that I'd prefer it to be based on email, or something
> > > that doesn't impose a barrier to those who don't have an account in a
> > > given platform, and don't want to create it.
> 
> Another thing I think would be interesting is to allow to choose a
> matrix of options:
> 
>| love | LGTM | could live with it | dislike | hate | No opinion
> lenof
> lengthof
> countof
> nelemsof
> nelementsof
> extentof
> 
> Where multiple ones can be voted by the same person at the same level of
> likeness.

(And I would rather require to give some text justifying the options
 chosen.)

> 
> > > 
> > > Thanks for your interest in this operator!
> > > 
> > > Have a lovely day!
> > > Alex
> > > 
> > > 
> > > P.S.:  наб, you asked why not array_size().  I agree with the defenders
> > > of lengthof that size should not be overloaded to mean both the number
> > > of bytes and the number of elements of an object (although I'm closer to
> > > accepting overloading the term "size" than overloading the term
> > > "length", since size at least doesn't promote off-by-one errors).  Also,
> > > I have a macro sizeof_array() which I define as
> > > 
> > >   #define sizeof_array(a)  (countof(a) * sizeof((a)[0]))
> > > 
> > > It would be very weird and confusing to have
> > > 
> > >   #define sizeof_array(a)  (array_size(a) * sizeof((a)[0]))
> > > 
> > > 
> > > 
> > > On Sat, Oct 26, 2024 at 12:10:56AM GMT, Alejandro Colomar wrote:
> > > > Hi Joseph,
> > > > 
> > > > On Fri, Oct 25, 2024 at 08:44:15PM GMT, Joseph Myers wrote:
> > > > > I don't see the use of pedwarn_c23 and associated tests (error with 
> > > > > -std=c23 -pedantic-errors, warning with -std=c23 -pedantic, no 
> > > > > diagnostic 
> > > > > with -std=c23 -pedantic-errors -Wno-c23-c2y-compat, no diagnostic 
> > > > > with 
> > > > > -std=c2y -pedantic-errors, warning with -std=c2y -pedantic-errors 
> > > > > -Wc23-c2y-compat), previously discussed in comments on v13, that 
> > > > > would be 
> > > > > appropriate before considering this for inclusion with an appropriate 
> > > > > substitution of names.
> > > > 
> > > > I removed it because I renamed it to __countof__, which is a GNU
> > > > extension, and thus should not be warned by -Wpedantic.  As part of my
> > > > opposition to _Lengthof, I will not provide you with that part, which
> > > > would amount to basically giving you _Lengthof but not.  As part of the
> > > > editorialising process, you'll also have to add pedantic warnings, if
> > > > that's what you want to do.  Again, I will earnestly ask to once more to
> > > > consider __countof__, but it's up to you.
> > > > 
> > > > Have a lovely night!
> > > > Alex
> > > > 
> > > > -- 
> > > > 
> > > 
> > > 
> > > 
> > > -- 
> > > 
> > 
> > 
> > 
> > -- 
> > 
> 
> 
> 
> -- 
> 



-- 



signature.asc
Description: PGP signature

Re: [PATCH v17 2/2] c: Add __countof__ operator

2024-10-26 Thread Alejandro Colomar via Gcc 
On Sat, Oct 26, 2024 at 12:12:39PM GMT, Alejandro Colomar wrote:
> On Sat, Oct 26, 2024 at 12:07:04PM GMT, Alejandro Colomar wrote:
> > [Moved from gcc-patches@ to gcc@]
> > 
> > Hi JeanHeyd, наб,
> > 
> > I see you (JeanHeyd) are developing yet another survey about the names
> > for this new operator.  Let me ask you to be clear about my fear of
> > ambiguity with null-terminated strings which are stored within arrays
> > and the length of both entities differ, usually by exactly one, being a
> > potential cause of a confusion that might result in buffer overflows, or
> > other kinds of errors (and it would be interesting to mention that I've
> > presented a link to an actual bug of that class in shadow-utils, which I
> > fixed recently).  I would also like the survey to be presented to
> > programmers that like programming in C; I would refuse to acknowledge
> > the results of any survey that is presented to C++ or rust programmers
> > who acknowledge not wanting to program in C ever again.  They have a
> > clear conflict of interest.  If this survey is conducted, it should
> > include the gcc and glibc communities, and the resons why each name is
> 
> It would also be interesting to hear the opinion of people from the BSDs
> and Unix/Plan9.
> 
> > considered good and bad should be clearly stated alongside the options,
> > in a detailed rationale.
> > 
> > For extentof(), my only caveat is that one might want to add a 2-args
> > operator (or macro) that has the C++ semantics, that is, allowing you to
> > specify the dimension of the array that you want.  I don't see why it
> > would be useful, but didn't want to preclude it either.  But other than
> > that, I'm okay with that name.
> > 
> > Another thing is that I'd prefer it to be based on email, or something
> > that doesn't impose a barrier to those who don't have an account in a
> > given platform, and don't want to create it.

Another thing I think would be interesting is to allow to choose a
matrix of options:

   | love | LGTM | could live with it | dislike | hate | No opinion
lenof
lengthof
countof
nelemsof
nelementsof
extentof

Where multiple ones can be voted by the same person at the same level of
likeness.

> > 
> > Thanks for your interest in this operator!
> > 
> > Have a lovely day!
> > Alex
> > 
> > 
> > P.S.:  наб, you asked why not array_size().  I agree with the defenders
> > of lengthof that size should not be overloaded to mean both the number
> > of bytes and the number of elements of an object (although I'm closer to
> > accepting overloading the term "size" than overloading the term
> > "length", since size at least doesn't promote off-by-one errors).  Also,
> > I have a macro sizeof_array() which I define as
> > 
> > #define sizeof_array(a)  (countof(a) * sizeof((a)[0]))
> > 
> > It would be very weird and confusing to have
> > 
> > #define sizeof_array(a)  (array_size(a) * sizeof((a)[0]))
> > 
> > 
> > 
> > On Sat, Oct 26, 2024 at 12:10:56AM GMT, Alejandro Colomar wrote:
> > > Hi Joseph,
> > > 
> > > On Fri, Oct 25, 2024 at 08:44:15PM GMT, Joseph Myers wrote:
> > > > I don't see the use of pedwarn_c23 and associated tests (error with 
> > > > -std=c23 -pedantic-errors, warning with -std=c23 -pedantic, no 
> > > > diagnostic 
> > > > with -std=c23 -pedantic-errors -Wno-c23-c2y-compat, no diagnostic with 
> > > > -std=c2y -pedantic-errors, warning with -std=c2y -pedantic-errors 
> > > > -Wc23-c2y-compat), previously discussed in comments on v13, that would 
> > > > be 
> > > > appropriate before considering this for inclusion with an appropriate 
> > > > substitution of names.
> > > 
> > > I removed it because I renamed it to __countof__, which is a GNU
> > > extension, and thus should not be warned by -Wpedantic.  As part of my
> > > opposition to _Lengthof, I will not provide you with that part, which
> > > would amount to basically giving you _Lengthof but not.  As part of the
> > > editorialising process, you'll also have to add pedantic warnings, if
> > > that's what you want to do.  Again, I will earnestly ask to once more to
> > > consider __countof__, but it's up to you.
> > > 
> > > Have a lovely night!
> > > Alex
> > > 
> > > -- 
> > > 
> > 
> > 
> > 
> > -- 
> > 
> 
> 
> 
> -- 
> 



-- 



signature.asc
Description: PGP signature

Re: [PATCH v17 2/2] c: Add __countof__ operator

2024-10-26 Thread Alejandro Colomar via Gcc 
[Moved from gcc-patches@ to gcc@]

Hi JeanHeyd, наб,

I see you (JeanHeyd) are developing yet another survey about the names
for this new operator.  Let me ask you to be clear about my fear of
ambiguity with null-terminated strings which are stored within arrays
and the length of both entities differ, usually by exactly one, being a
potential cause of a confusion that might result in buffer overflows, or
other kinds of errors (and it would be interesting to mention that I've
presented a link to an actual bug of that class in shadow-utils, which I
fixed recently).  I would also like the survey to be presented to
programmers that like programming in C; I would refuse to acknowledge
the results of any survey that is presented to C++ or rust programmers
who acknowledge not wanting to program in C ever again.  They have a
clear conflict of interest.  If this survey is conducted, it should
include the gcc and glibc communities, and the resons why each name is
considered good and bad should be clearly stated alongside the options,
in a detailed rationale.

For extentof(), my only caveat is that one might want to add a 2-args
operator (or macro) that has the C++ semantics, that is, allowing you to
specify the dimension of the array that you want.  I don't see why it
would be useful, but didn't want to preclude it either.  But other than
that, I'm okay with that name.

Another thing is that I'd prefer it to be based on email, or something
that doesn't impose a barrier to those who don't have an account in a
given platform, and don't want to create it.

Thanks for your interest in this operator!

Have a lovely day!
Alex


P.S.:  наб, you asked why not array_size().  I agree with the defenders
of lengthof that size should not be overloaded to mean both the number
of bytes and the number of elements of an object (although I'm closer to
accepting overloading the term "size" than overloading the term
"length", since size at least doesn't promote off-by-one errors).  Also,
I have a macro sizeof_array() which I define as

#define sizeof_array(a)  (countof(a) * sizeof((a)[0]))

It would be very weird and confusing to have

#define sizeof_array(a)  (array_size(a) * sizeof((a)[0]))



On Sat, Oct 26, 2024 at 12:10:56AM GMT, Alejandro Colomar wrote:
> Hi Joseph,
> 
> On Fri, Oct 25, 2024 at 08:44:15PM GMT, Joseph Myers wrote:
> > I don't see the use of pedwarn_c23 and associated tests (error with 
> > -std=c23 -pedantic-errors, warning with -std=c23 -pedantic, no diagnostic 
> > with -std=c23 -pedantic-errors -Wno-c23-c2y-compat, no diagnostic with 
> > -std=c2y -pedantic-errors, warning with -std=c2y -pedantic-errors 
> > -Wc23-c2y-compat), previously discussed in comments on v13, that would be 
> > appropriate before considering this for inclusion with an appropriate 
> > substitution of names.
> 
> I removed it because I renamed it to __countof__, which is a GNU
> extension, and thus should not be warned by -Wpedantic.  As part of my
> opposition to _Lengthof, I will not provide you with that part, which
> would amount to basically giving you _Lengthof but not.  As part of the
> editorialising process, you'll also have to add pedantic warnings, if
> that's what you want to do.  Again, I will earnestly ask to once more to
> consider __countof__, but it's up to you.
> 
> Have a lovely night!
> Alex
> 
> -- 
> 



-- 



signature.asc
Description: PGP signature

gcc-14-20241026 is now available

2024-10-26 Thread GCC Administrator via Gcc 
Snapshot gcc-14-20241026 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/14-20241026/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-14 revision e44d4b7647c6b9c9a147b13de588b14e5a54354a

You'll find:

 gcc-14-20241026.tar.xz   Complete GCC

  SHA256=eed20926476b0c70d48d3b175c6895bf0547dc8bd5ad930fdcf8ae0513741c4f
  SHA1=9f3cc290d1d15a3b49fac543cb0d08c27c2c9d24

Diffs from 14-20241019 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-14
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [PATCH v17 2/2] c: Add __countof__ operator

2024-10-26 Thread mirabilos 
On Sat, 26 Oct 2024, Alejandro Colomar wrote:

>> It would also be interesting to hear the opinion of people from the BSDs

>> >#define sizeof_array(a)  (countof(a) * sizeof((a)[0]))
>> >#define sizeof_array(a)  (array_size(a) * sizeof((a)[0]))

Not too sure what the root context of this thread is, but in BSD land
we use NELEM or NENTS for (sizeof(a) / sizeof((a)[0])) generally.

>> and Unix/Plan9.

yay!

>Another thing I think would be interesting is to allow to choose a
>matrix of options:

I pointed out in Fedi (also mostly contextless) to thephd that another
option is devotee-style preferential voting (Condorcet etc. and “none of
the above” and “further discussion” can be voted atop or in the middle
or below the options) for this kind of thing.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

examples of (so called) time-travel optimisations in GCC?

2024-10-26 Thread Iain Sandoe 
Hi,

The background here is that I made a trial implementation of P1494r4 - 
std::observable() - and want to produce testcases.

—— so …..

I am looking for either examples where GCC produces time-travel optimisation 
(or alternately some evidence that these are not expected).

(In case someone is not familiar with the time-travel analogy) a simple example 
from P1494:

void b(int &r, int *p) {
  if (!p) std::fprintf(stderr, "count: %d\n", ++r);
  if (!p) std::fprintf(stderr, "p is null\n");
  *p += r; // p may be assumed non-null
}

Since dereferencing p is UB, the compiler may assume that p is non-null - and 
therefore elide the check(s) before (thus time-travel). 

In practice, (at least on the platform I am testing on)  GCC trunk does not do 
this - it does reorder code to eliminate the second null test - but it still 
prints both sets of output.

TIA
Iain

Re: examples of (so called) time-travel optimisations in GCC?

2024-10-26 Thread Martin Uecker via Gcc 
Am Samstag, dem 26.10.2024 um 18:55 +0200 schrieb Richard Biener via Gcc:
> 
> > Am 26.10.2024 um 17:30 schrieb Iain Sandoe :
> > 
> > Hi,
> > 
> > The background here is that I made a trial implementation of P1494r4 - 
> > std::observable() - and want to produce testcases.
> > 
> > —— so …..
> > 
> > I am looking for either examples where GCC produces time-travel 
> > optimisation (or alternately some evidence that these are not expected).
> > 

A conforming compiler can not do time-travel optimizations
across function calls. For a function call the compiler must
assume  that it exits the program or uses a non-local return,
so it can not assume that UB that comes later will happen.

This then typically applies to I/O which is hidden behind
function calls.

Where compilers do not observe this, this causes bugs, e.g.
this old bug which broke Postgresql:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41239

Or this recent in MSVC which I found when investigating
this question (now fixed):
https://developercommunity.visualstudio.com/t/Invalid-optimization-in-CC/10337428?q=muecker

C23 clarifies that time-travel is not allowed (it was never
really supported by the wording in the C standard).

One area where GCC is not conforming are volatile accesses:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800

Martin

> > (In case someone is not familiar with the time-travel analogy) a simple 
> > example from P1494:
> > 
> > void b(int &r, int *p) {
> >  if (!p) std::fprintf(stderr, "count: %d\n", ++r);
> >  if (!p) std::fprintf(stderr, "p is null\n");
> >  *p += r; // p may be assumed non-null
> > }
> > 
> > Since dereferencing p is UB, the compiler may assume that p is non-null - 
> > and therefore elide the check(s) before (thus time-travel).
> > 
> > In practice, (at least on the platform I am testing on)  GCC trunk does not 
> > do this - it does reorder code to eliminate the second null test - but it 
> > still prints both sets of output.
> 
> I think we at least do not optimistically propagate backwards - that is, the 
> conditional code may not exit or infinitely loop.  Printf due to callbacks 
> might, so I suggest to rework to tell GCC the conditional code will still 
> make sure the dereference is reached.

Re: examples of (so called) time-travel optimisations in GCC?

2024-10-26 Thread Richard Biener via Gcc 



> Am 26.10.2024 um 17:30 schrieb Iain Sandoe :
> 
> Hi,
> 
> The background here is that I made a trial implementation of P1494r4 - 
> std::observable() - and want to produce testcases.
> 
> —— so …..
> 
> I am looking for either examples where GCC produces time-travel optimisation 
> (or alternately some evidence that these are not expected).
> 
> (In case someone is not familiar with the time-travel analogy) a simple 
> example from P1494:
> 
> void b(int &r, int *p) {
>  if (!p) std::fprintf(stderr, "count: %d\n", ++r);
>  if (!p) std::fprintf(stderr, "p is null\n");
>  *p += r; // p may be assumed non-null
> }
> 
> Since dereferencing p is UB, the compiler may assume that p is non-null - and 
> therefore elide the check(s) before (thus time-travel).
> 
> In practice, (at least on the platform I am testing on)  GCC trunk does not 
> do this - it does reorder code to eliminate the second null test - but it 
> still prints both sets of output.

I think we at least do not optimistically propagate backwards - that is, the 
conditional code may not exit or infinitely loop.  Printf due to callbacks 
might, so I suggest to rework to tell GCC the conditional code will still make 
sure the dereference is reached.

Richard 

> TIA
> Iain
>