Re: Enquiry
On 1/30/22 12:17, Jonathan Wakely wrote: Meta-comment: a subject line of "Enquiry" is very vague, and most commonly used by spammers and phishers. Your enquiry is about undefined behaviour due to a missing return, which would have been a much better subject. Indeed. Did not realize that. Will make more attention next time. Theo.
Re: Enquiry
On Sun, Jan 30, 2022 at 11:11:15AM +, Jonathan Wakely wrote:
> On Sun, 30 Jan 2022, 10:58 Jakub Jelinek, wrote:
>
> > On Sun, Jan 30, 2022 at 10:50:56AM +, Jonathan Wakely wrote:
> > > We could put a trap instruction at the end of the function though, which
> > > would make the result a bit less arbitrary.
> > >
> > > I've come around to thinking that's preferable for cases like this.
> >
> > Depends on which exact cases.
> > Because for
> > int foo (int s) { if (s == 123) return 1; }
> > we want to optimize it into
> > return 1;
> > rather than if (s == 123) return 1; else __builtin_trap ();
> > For debugging we have -fsanitize=undefined
>
>
> What if we inserted the trap for -O0?
Adding a trap for -O0 looks reasonable to me, after all, we aren't going to
do too many optimizations with __builtin_unreachable at -O0 anyway.
Jakub
Re: Enquiry
On 1/30/22 11:58, Jakub Jelinek wrote:
On Sun, Jan 30, 2022 at 10:50:56AM +, Jonathan Wakely wrote:
We could put a trap instruction at the end of the function though, which
would make the result a bit less arbitrary.
I've come around to thinking that's preferable for cases like this.
Depends on which exact cases.
Because for
int foo (int s) { if (s == 123) return 1; }
we want to optimize it into
return 1;
rather than if (s == 123) return 1; else __builtin_trap ();
For debugging we have -fsanitize=undefined
Jakub
I understand completely, it is undefined behaviour. What I had not
realized is that undefined behaviour
is not a property of the function itself, but of the function call when
parameters are specified. That seems
more difficult to handle from the compiler perspective, but if that is
the rule, so be it...
It seems to me that this is a case that just makes things more
complicated for programmers (and compiler developers) for the benefit
of only a small community which will know the precise limits of the
undefined behaviour and would like to play at the boundary of the cliff.
Honestly, for the user perspective (or more exactly a majority of
users), it would be nice if there was a way to catch such situations at
compile time (making of course more strict assumptions on the compiler
side). Of course, I can fire gdb or -fsanitize=undefined, but
whatever can be caught earlier is better I will turn that specific
warning into a an error with -Werrror=XXX for my own usage.
Thank's for the explanations. At least, I learned something. Hope I did
not waste too much of your time.
Theo.
Re: Enquiry
On Mon, 31 Jan 2022 at 10:16, Theodore Papadopoulo wrote:
>
> On 1/30/22 11:58, Jakub Jelinek wrote:
> > On Sun, Jan 30, 2022 at 10:50:56AM +, Jonathan Wakely wrote:
> >> We could put a trap instruction at the end of the function though, which
> >> would make the result a bit less arbitrary.
> >>
> >> I've come around to thinking that's preferable for cases like this.
> > Depends on which exact cases.
> > Because for
> > int foo (int s) { if (s == 123) return 1; }
> > we want to optimize it into
> > return 1;
> > rather than if (s == 123) return 1; else __builtin_trap ();
> > For debugging we have -fsanitize=undefined
> >
> > Jakub
> >
> I understand completely, it is undefined behaviour. What I had not
> realized is that undefined behaviour
> is not a property of the function itself, but of the function call when
> parameters are specified. That seems
> more difficult to handle from the compiler perspective, but if that is
> the rule, so be it...
>
> It seems to me that this is a case that just makes things more
> complicated for programmers (and compiler developers) for the benefit
> of only a small community which will know the precise limits of the
> undefined behaviour and would like to play at the boundary of the cliff.
No, not really. You're looking at a very simple example, but the
general case can be much more complicated, and undecidable by the
compiler.
The rules of the standard tend to be consistent, and not depend on how
close the compiler can get to solving the halting problem. If there is
a possible set of arguments to the function that avoids undefined
behaviour, the compiler assumes the user only plans to use those
arguments, and so will only warn and not give an error. Otherwise
valid programs would be rejected.
> Honestly, for the user perspective (or more exactly a majority of
> users), it would be nice if there was a way to catch such situations at
> compile time (making of course more strict assumptions on the compiler
> side).
How can the compiler tell the difference between "the user forgot to
handle a case" and "the user knows this case cannot happen and doesn't
need to be handled"?
Re: Enquiry
On Jan 30 2022, Jonathan Wakely via Gcc wrote:
> On Sun, 30 Jan 2022, 10:58 Jakub Jelinek, wrote:
>
>> On Sun, Jan 30, 2022 at 10:50:56AM +, Jonathan Wakely wrote:
>> > We could put a trap instruction at the end of the function though, which
>> > would make the result a bit less arbitrary.
>> >
>> > I've come around to thinking that's preferable for cases like this.
>>
>> Depends on which exact cases.
>> Because for
>> int foo (int s) { if (s == 123) return 1; }
>> we want to optimize it into
>> return 1;
>> rather than if (s == 123) return 1; else __builtin_trap ();
>> For debugging we have -fsanitize=undefined
>
>
> What if we inserted the trap for -O0?
Note that in C it is not an error to fall through the end of a non-void
function if the caller does not use the return value.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: Enquiry
On Mon, 31 Jan 2022 at 10:25, Andreas Schwab wrote:
>
> On Jan 30 2022, Jonathan Wakely via Gcc wrote:
>
> > On Sun, 30 Jan 2022, 10:58 Jakub Jelinek, wrote:
> >
> >> On Sun, Jan 30, 2022 at 10:50:56AM +, Jonathan Wakely wrote:
> >> > We could put a trap instruction at the end of the function though, which
> >> > would make the result a bit less arbitrary.
> >> >
> >> > I've come around to thinking that's preferable for cases like this.
> >>
> >> Depends on which exact cases.
> >> Because for
> >> int foo (int s) { if (s == 123) return 1; }
> >> we want to optimize it into
> >> return 1;
> >> rather than if (s == 123) return 1; else __builtin_trap ();
> >> For debugging we have -fsanitize=undefined
> >
> >
> > What if we inserted the trap for -O0?
>
> Note that in C it is not an error to fall through the end of a non-void
> function if the caller does not use the return value.
Indeed. Theo's program is undefined in C++ and valid in C.
I would love to see the trap inserted for C++ though.
Porting the Docs to Sphinx - project status
Hello. It's about 5 months since the last project status update: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577108.html Now it's pretty clear that it won't be merged before GCC 12.1 gets released. So where we are? I contacted documentation maintainers (Gerald, Sandra and Joseph) at the end of the year in a private email, where I pinged the patches. My take away is that both Gerald and Joseph are fine with the porting, while Sandra has some concerns. Based on her feedback, I was able to improve the PDF generated output significantly and I'm pleased by the provided feedback. That led to the following 2 Sphinx pulls requests that need to be merged before we can migrate the documentation: [1], [2]. Since the last time I also made one more round of proofreading and the layout was improved (mainly for PDF part). Current version of the documentation can be seen here: https://splichal.eu/scripts/sphinx/ I would like to finish the transition once GCC 12.1 gets released in May/June this year. There are still some minor regressions, but overall the Sphinx-based documentation should be a significant improvement over what we've got right now. Please take this email as urgent call for a feedback! Thank you, Martin [1] https://github.com/sphinx-doc/sphinx/pull/10087 [2] https://github.com/sphinx-doc/sphinx/pull/10001
