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/
