[Vm-dev] [Pharo-dev] Debugging GCC code generation

Ben Coman btc at openinworld.com
Wed Dec 11 22:26:55 UTC 2019

On Thu, 12 Dec 2019 at 04:03, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> Hi Pablo,
> On Wed, Dec 11, 2019 at 11:33 AM tesonep at gmail.com <tesonep at gmail.com>
> wrote:
>> Hi Nicolas,
>>   thanks for the comment, you are right the problem is the bad
>> original code. But my opinion is that it just is not reporting the
>> situation correctly, generating a warning or non-optimizing the code
>> looks more like a expected behavior. Because as I have said, using a
>> constant as index in the last statement generates a meaningful warning
>> and the non-optimizated version of the function.
>> And again as you said, the only thing to learn about all this is that
>> we should not write crappy code.
> Hang on.  "crappy code" is too strong.  Back in tre ANSI days it was not
> undefined behavior, and in fact I think this only because undefined
> behavior because C compilers were faced with lots of code where variables
> were typed int but were being used on 64-bit machines.  Had the C world
> used long as its default type then there would have been no need to make
> casting the address of a long into the address of an int undefined
> behavior.  So this isn't crappy code (if you think of what it means in
> memory on a 64-bit little endnan machine it is perfectly sensible).  It
> /is/ code that is inappropriate given C99.
> So yes, we have to bow to the C gods and generate C99 compliant code, but
> what we were doing here wasn't crappy, it was merely code that became
> undefined behavior so that C compilers could generate more efficient code
> for 64-bit systems in the presence of code that contains lots of integer
> variables declared as int.  So let's just say that we have to generate C99
> compliant code.  You'll notice that the Smalltalk code in the original does
> exactly what you suggest Pablo.

So maybe interesting to see what happens if C89 is specified...

Possibly useful sanitizer...

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20191212/f6a5002e/attachment.html>

More information about the Vm-dev mailing list