This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/83252] Wrong code with "-march=skylake-avx512 -O3"


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

--- Comment #6 from Dmitry Babokin <babokin at gmail dot com> ---
(In reply to Jakub Jelinek from comment #1)
> Option bisection is rarely useful for GCC, debugging issues with -Ox -fthat
> -fno-this -fwhatever is usually not beneficial over just -Ox or whatever
> minimal options you need it.  Bisecting to what GCC version introduced the
> bug or changed behavior is usually much better.

Bisecting optimizations is orthogonal to bisecting of revision the bug started
with. In my experience it's extremely useful (with icc and clang) for
understanding the root cause of the bug (just compare two assemblers or IRs
with and without the guilty optimization). It's also very useful for
distinguishing bugs in automatic way - in case of multiple failing test cases I
can sort them in different buckets corresponding to guilty optmizations. This
analysis is not 100% accurate, but is very useful. And the third useful feature
of such bisection - finding an optimization for initial bug assignment.

I'm not insisting on such functionality, as my bugs were always analysed and
fixed in timely manner (unlike with other compilers). But I still think gcc
would benefit from such mechanism a lot.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]