Enquiry
Before creating a bug report, I want to check with the GCC community
(all the more that checking that the problem has not yet been reported
is complicated at leat for me).
The following (admitedly buggy) program generates a segmentation
violation on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat
11.2.1-7) (GCC))
when compiled with -O3 (other versions replacing unisgned by std::string
may trigger the exception instead of the segv)
bool assert_sthg(const unsigned s) {
if (s==123)
throw 1;
}
int main() {
assert_sthg(0);
return 0;
}
When compiling, we indeed get a warning:
test.C:4:1: warning: control reaches end of non-void function
[-Wreturn-type]
I can well understand that the program being buggy that the optimizer is
allowed to do anything including the observed segmentation violation.
Yet the result is quite surprising
The question is, in that case, wouldn't it be better to turn the warning
into an error at -O3 ?
Thank's for any input.
Theo.
Re: Enquiry
On Sun, Jan 30, 2022 at 10:47:41AM +0100, Theodore Papadopoulo wrote:
> Before creating a bug report, I want to check with the GCC community (all
> the more that checking that the problem has not yet been reported is
> complicated at leat for me).
>
> The following (admitedly buggy) program generates a segmentation violation
> on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC))
> when compiled with -O3 (other versions replacing unisgned by std::string may
> trigger the exception instead of the segv)
>
> bool assert_sthg(const unsigned s) {
> if (s==123)
> throw 1;
> }
>
> int main() {
> assert_sthg(0);
> return 0;
> }
>
> When compiling, we indeed get a warning:
>
> test.C:4:1: warning: control reaches end of non-void function
> [-Wreturn-type]
>
> I can well understand that the program being buggy that the optimizer is
> allowed to do anything including the observed segmentation violation.
> Yet the result is quite surprising
Undefined behavior can have any kind of surprising behavior.
> The question is, in that case, wouldn't it be better to turn the warning
> into an error at -O3 ?
No, it can't be an error by default, it is undefined behavior only at
runtime, if you never call the function or always call it with
assert_sthg(123), then the program can be valid.
Jakub
Re: Enquiry
On Sun, 30 Jan 2022, 10:42 Jakub Jelinek via Gcc, wrote:
> On Sun, Jan 30, 2022 at 10:47:41AM +0100, Theodore Papadopoulo wrote:
> > Before creating a bug report, I want to check with the GCC community (all
> > the more that checking that the problem has not yet been reported is
> > complicated at leat for me).
> >
> > The following (admitedly buggy) program generates a segmentation
> violation
> > on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC))
> > when compiled with -O3 (other versions replacing unisgned by std::string
> may
> > trigger the exception instead of the segv)
> >
> > bool assert_sthg(const unsigned s) {
> > if (s==123)
> > throw 1;
> > }
> >
> > int main() {
> > assert_sthg(0);
> > return 0;
> > }
> >
> > When compiling, we indeed get a warning:
> >
> > test.C:4:1: warning: control reaches end of non-void function
> > [-Wreturn-type]
> >
> > I can well understand that the program being buggy that the optimizer is
> > allowed to do anything including the observed segmentation violation.
> > Yet the result is quite surprising
>
> Undefined behavior can have any kind of surprising behavior.
>
> > The question is, in that case, wouldn't it be better to turn the warning
> > into an error at -O3 ?
>
> No, it can't be an error by default, it is undefined behavior only at
> runtime, if you never call the function or always call it with
> assert_sthg(123), then the program can be valid.
>
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.
Re: Enquiry
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
Re: Enquiry
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?
1. Not everybody uses ubsan even when they should use it.
2. The code can use unreachable annotations if it really needs to leave
some paths unhandled, but really can't live with the branch and trap
instructions. (The C++ standard is getting std::unreachable and std::assume
to do that in a portable way, so there is less excuse for not doing it).
Re: Enquiry
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.
On Sun, 30 Jan 2022, 09:48 Theodore Papadopoulo, <
theodore.papadopo...@inria.fr> wrote:
> Before creating a bug report, I want to check with the GCC community
> (all the more that checking that the problem has not yet been reported
> is complicated at leat for me).
>
> The following (admitedly buggy) program generates a segmentation
> violation on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat
> 11.2.1-7) (GCC))
> when compiled with -O3 (other versions replacing unisgned by std::string
> may trigger the exception instead of the segv)
>
> bool assert_sthg(const unsigned s) {
> if (s==123)
> throw 1;
> }
>
> int main() {
> assert_sthg(0);
> return 0;
> }
>
> When compiling, we indeed get a warning:
>
> test.C:4:1: warning: control reaches end of non-void function
> [-Wreturn-type]
>
> I can well understand that the program being buggy that the optimizer is
> allowed to do anything including the observed segmentation violation.
> Yet the result is quite surprising
> The question is, in that case, wouldn't it be better to turn the warning
> into an error at -O3 ?
>
> Thank's for any input.
>
> Theo.
>
>
Re: Bisecting
On Sun, 2022-01-30 at 01:09 +, Jonathan Wakely via Gcc wrote: > On Sat, 29 Jan 2022, 20:25 Søren Holm via Gcc, wrote: > > > Hi > > > > I believe I have found some kind of bug in GCC. The target is a > > cortex-m7 CPU. I do not have an isolated test software so I'm > > thinking > > of bisecting GCC between GCC 9.4 and 10.1. > > > > Are there any easy way do do a fast "change - compile - test"- cycle > > - > > and how do I do that? All the guide on building GCC is using huge > > scripts with installs and such. I'm sure the main developers does not > > do > > that. > > > > > > https://gcc.gnu.org/wiki/InstallingGCC is not a huge script, it's a > very > small number of commands. > > You can use git bisect to simplify things, but if you don't have a > small > reproducer for the problem then I don't see how you can avoid doing a > full > build and install. With a simple reproducer, you can just great using > the > cc1 or cc1plus binary in the build tree, without installing anything. > Indeed: try to come up with a minimal reproducer demonstrating the issue (or its absence) deterministically, one that involves a simple invocation of cc1 (or cc1plus if C++). Some tips for speeding builds up: * configure gcc with --disable-bootstrap * configure gcc with --enable-languages containing just the languages you need * you may be able to get away with just "make cc1" in the BUILDDIR/gcc subdirectory each time; you might need to rebuild BUILDDIR/libcpp sometimes though, since the API/ABI exposed by BUILDDIR/libcpp to BUILDDIR/gcc/cc1 changes in some commits * do the build on a machine with plenty of cores and use an appropriate -j option to "make" Might be an idea to configure with --enable-checking=debug since the versions you refer to straddle the boundaries between released versions (where --enable-checking=release is the default) and development versions (where --enable-checking=debug is the default). --enable- checking=debug adds lots of extra checking, which is likely to identify problems in a more controlled fashion even though the built compiler will be slower. How deterministic is the failure? If you're seeing randomness, it could be an issue with garbage collector markings, in which case --param=ggc-min-expand=0 --param=ggc-min-heapsize=0 will fully run the garbage collector at every GC opportunity (which is *slow*, but very good at quickly pinpointing the problem if it's a issue with the GC, which otherwise are a major pain to track down). Hope this is helpful Dave
gcc-12-20220130 is now available
Snapshot gcc-12-20220130 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20220130/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision baf98320ac6cd56da0c0b460fb94e3b87a79220d You'll find: gcc-12-20220130.tar.xz Complete GCC SHA256=5e63ab057bc747ca17b47fa8b15afdcaf1919d38977e94ce788b181aa4ad237f SHA1=4928208590010b85e665bffb3c42e9c59bdb3f5a Diffs from 12-20220123 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 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.
