https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
--- Comment #76 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 14 Dec 2021, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 > > --- Comment #75 from Martin Liška <marxin at gcc dot gnu.org> --- > (In reply to David Binderman from comment #74) > > (In reply to Martin Liška from comment #72) > > > You will manage, it's not rocket science. > > > > > > So please, add break point at the place it triggers the ICE and do: > > > > > > (gdb) p &ptr1->x_help_flag > > > (gdb) p &ptr2->x_help_flag > > > > For this to work, I had to replace the options-save.o with a version > > compiled by -O0 and that made the problem go away ;-< > > Or you would have to print &ptr1->x_help_flag with a printf and then > use gdb for the memory. > > > > > I am still happy to walk away from this bug report. It is known > > to occur on only one variant of one architecture and it is hard > > to reproduce. I can think of better things to work on in gcc. > > Ok... > > > > > As far as finding a machine with a bdver2 architecture, I suspect > > any more recent AMD machine would be fine. > > > > Has no one checked the compile farm ? > > No, there's not a bdver2 machine. Maybe the issue reproduces with only -mtune=bdver2 or with -march=bdver2 -mno-xop (XOP is what's removed from znver2 for example, not 100% sure that's all, but ...). It does sound like eventually options-save.c is miscompiled somehow ...
