Can you show the complete source that causes the bug to show up? When you define label with "var dd 0,0" there should be no difference between "[var]" and "dword[var]" constructions.

vcvtsi2sd xmm0,xmm0,[var]
var dd 0,0    

Thank you! This helped me find the bug. Please try 1.71.51.

Seems like another non-recoverable error at the wrong place.

In fasm g I have no errors that are not recoverable other than running out of memory or hitting the limit of allowed passes

;allows to debug long running loops
;usage: mLimitLoops $100000
macro mLimitLoops limit=$100000
{
        macro while args&
        \{
                while args
                        if % > limit
                                display 'Error: too many iterations',13,10
                                err
                        end if
        \}
        macro repeat args&
        \{
                repeat args
                        if % > limit
                                display 'Error: too many iterations',13,10
                                err
                        end if
        \}
}    

macro mLimitLoops limit=$100000
        macro while?! args&
                while args
                        if % > limit
                                err 'too many iterations'
                                break
                        end if
        end macro
        macro repeat?! args&
                repeat args
                        if % > limit
                                err 'too many iterations'
                                break
                        end if
        end macro
end macro


mLimitLoops 1000

while a = 0

end while

a = 0    

The above sample shows the "too many iterations" error correctly,

and when you change "a = 0" to "a = 1" it is going to assemble without an error - something that the variant with unrecoverable error would not allow

Tomasz Grysztar

Quote:

The above sample shows the "too many iterations" error correctly,

Well, in this simple example yes, but in a larger code with many loops it's still gonna continue to execute other loops to the specified limit, and then do more passes and possibly even end up with "code cannot be generated".

The purpose of the macro is debugging of compiler hanging. It's not meant be used in a code that correctly compiles.

Yes, and this is what meant when I mentioned that I overestimated the potential problems caused by such approach

Still, if the assembler aborts at a later pass, when many of the values are better known, you may get a more informative debugging

And in this variant such macro may actually help with some regular assembly, too (by skipping over the wrongly predicted long loops).

I actually see it as less informative. And especially disadvantageous if the compiler somehow would manage to succeed with enforced loop limits, but not without them. The actual desired loop termination conditions would not be satisfied leading to inexpressive "better known" values.

As I said above, I am aware of the theoretical "bad case scenarios"

And in this variant such macro may actually help with some regular assembly, too (by skipping over the wrongly predicted long loops).

You try to present it as an advantage, but the point was to find the bug that led to long running loops. Not to make the source code somehow magically compile. And the result is that the bug was not found.

The bug was not found because there was no actual bug to find.

as long as we are both discussing hypothetical advantages and hypothetical disadvantages, we may keep this going for long

However I do speak from the experience

Yes, but that's a different kind of experience. Your use cases are limited to finding a solution for the source code no matter what. And the use case I'm talking about is debugging. One thing is to not use unrecoverable errors internally and a completely different thing is to not provide a possibility to generate them at all. If I say to the compiler that I want it to stop at this particular point then it's really what I mean, and I prefer to have the possibility to say that.

It's not unique to fasm resolution process that you'd be willing to stop the process as early as possible. It's the generally desired fail-fast property. E.g. if you experience heap corruption, you really wanna stop the process at the very moment of the misbehaving write, and not some time later when the heap corruption manifests itself at unrelated locations. It indeed would require you to have much more knowledge of the heap operation internals to find the root cause of the corruption.