Huh, you're right, I forgot that Py_LOCAL_AGGRESSIVE is specific to MSVC (maybe it wasn't always).
I can think of nothing else apart from a gcc or gdb bug. Oh, hm, maybe computed gotos play havoc with the labels??? On Fri, May 21, 2021 at 2:01 PM Skip Montanaro <skip.montan...@gmail.com> wrote: > > > On Fri, May 21, 2021 at 2:48 PM Guido van Rossum <gu...@python.org> wrote: > >> I suspect that you're running into the issue where compiler optimizations >> are *forced* on for ceval.c. >> >> There's a comment near the top about this. Just comment out this line: >> >> #define PY_LOCAL_AGGRESSIVE >> >> We tried to define that macro conditionally, but something broke because >> the C stack frame for _PyEval_EvalFrameDefault became enormous without >> optimization, and some tests failed. (Maybe it was Victor's refleak test? >> The git history will tell you more if you're really interested.) >> >> This is a nasty trap (I fell in myself, so that makes it nasty :-), but >> the proper fix would be convoluted -- we'd need a way to enable or disable >> this separately so the specific test can run but developers trying to step >> through ceval.c will be able to see the unoptimized code. >> > > Thanks, Guido, however that doesn't seem to help. I grepped around for > PY_LOCAL_AGGRESSIVE in the source. It seems to be specific to MSVC. Here's > the definition in Include/pyport.h with a slight change to the indentation > to demonstrate its scope better: > > #if defined(_MSC_VER) > # if defined(PY_LOCAL_AGGRESSIVE) > /* enable more aggressive optimization for MSVC */ > /* active in both release and debug builds - see bpo-43271 */ > # pragma optimize("gt", on) > # endif > /* ignore warnings if the compiler decides not to inline a function */ > # pragma warning(disable: 4710) > /* fastest possible local call under MSVC */ > # define Py_LOCAL(type) static type __fastcall > # define Py_LOCAL_INLINE(type) static __inline type __fastcall > #else > # define Py_LOCAL(type) static type > # define Py_LOCAL_INLINE(type) static inline type > #endif > > I can move the actual point where GDB breaks by replacing -Og with -O0, > but it still breaks at the wrong place, just a different wrong place. If I > set a breakpoint by line number, it stops at the proper place. > > Skip > > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YEPOFKTDHSHZFOBN77KPKGAYYIXQZG55/ Code of Conduct: http://python.org/psf/codeofconduct/