Re: Interpreters and caller-saved registers

anton@mips.complang.tuwien.ac.at
Tue, 24 Oct 2023 17:15:04 +0000

          From comp.compilers

Related articles
Interpreters and caller-saved registers anton@mips.complang.tuwien.ac.at (2023-10-13)
Re: Interpreters and caller-saved registers tkoenig@netcologne.de (Thomas Koenig) (2023-10-15)
Re: Interpreters and caller-saved registers anton@mips.complang.tuwien.ac.at (2023-10-19)
Re: Interpreters and caller-saved registers tkoenig@netcologne.de (Thomas Koenig) (2023-10-22)
Re: Interpreters and caller-saved registers anton@mips.complang.tuwien.ac.at (2023-10-24)
Re: bug fixes, Interpreters and caller-saved registers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-10-25)
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at
Newsgroups: comp.compilers
Date: Tue, 24 Oct 2023 17:15:04 +0000
Organization: Compilers Central
References: 23-10-001 23-10-002 23-10-003 23-10-004
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="7225"; mail-complaints-to="abuse@iecc.com"
Keywords: interpreter, optimize
Posted-Date: 25 Oct 2023 08:31:54 EDT

Thomas Koenig <tkoenig@netcologne.de> writes:
>anton@mips.complang.tuwien.ac.at <anton@mips.complang.tuwien.ac.at> schrieb:
>> If you want to file such a bug report, I can give you the commit of
>> Gforth before we added all the workarounds, where all the problems
>> are visible without ado.
>
>This reply shows an interesting aspect of compiler development that is
>often overlooked: The social aspect.
>
>Compiler writers generally want to improve their product, but they
>also generally feel that bug submitters (at least those who don't have
>a support contract) should also invest a minimum of work if he wants
>something fixed, and a general "look at large package xyz, it'll be
>obvious" is below that threshold. (This is the reason why gcc, for
>example, asks for a complete and self-contained test case in its bug
>reports.)
>
>People who complain about bugs, but are not willing to put in that
>minimum amount of work, are often ignored.


In my experience with gcc maintainers, when I put in that effort, it
is wasted, because


1) the resulting bug report is resolved as invalid (e.g., PR25285) in
      less time than it took me to create it. Moreover gcc maintainers
      who knew much less about the performance implications of the bug
      than I did (I had researched the topic for several years at that
      point), yet wrote patronizingly down to me; but that would have
      been forgiven if they had kept their part of the social contract
      and fixed the bug.


2) they confirm the bug and do nothing about it (PR93811).


3) they just do nothing about it (PR 93765).


In the present case, declaring the bug to be INVALID would be easy
given that the program uses features outside standard C, and I expect
that if you make such a bug report, it will be resolved as INVALID.
So why should anyone waste their time on it? If you think they are
going to fix it, why don't you invest your time in it?


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.