The err directive, usually used to stop the assembly when some condition is met, stops the assembly immediately, regardless of whether the current pass is final or intermediate. So even when the condition that caused this directive to be interpreted is temporary, and would eventually disappear in the later passes, the assembly is stopped anyway.

The assert directive signalizes the error only if its expression is false after all the symbols have been resolved. You can use assert 0 in place of err when you do not want to have assembly stopped during the intermediate passes.

x = -1 shl 63
x = x+x
x = -x

if x = 0
   display "x is zero",13,10
 err
end if
    

Code:

x = -1 shl 63
x = x+x
x = -x

if x = 0
 display "x is zero",13,10
 err
end if
    

if x = 0
        display "x is zero",13,10
        err
end if
x=1    

Then whenever a comparison is performed it would never be able to match to any numeric value.

The same thing is seen here also

x = 1
if x = 0
   err
end if    

x = (-1) shl 64
x = -x

if x = 0 
        err
end if    

;First case
x = (-1) shl 64
x = x shl 1

if x = 0 
    err 
end if    

;Second case
x = (-1) shl 64
x = -x

if x = 0 
        err
end if    

If it was the "assert x<>0" that failed for you even though x was not zero, then it would really be false positive (that is: a bug, for that matter).

rb x*2
x = $-1    

2) The err directive must trigger an error, because it's just present in the source after preprocessing. That's probably the Tomasz Grysztar's usage intention for the err directive.

IMHO the error messages should be the same and point to the overflow line and no display output placed after the error line may appear, which is only true for the first case overflow.

Quote:

If it was the "assert x<>0" that failed for you even though x was not zero, then it would really be false positive (that is: a bug, for that matter).

Wouldn't be the following code one of such cases?

Code:

rb x*2
x = $-1    

The compilation fails because -1 is assigned to x, but that's not a valid solution. So the real failure reason is that fasm can't find the correct solution ("code cannot be generated") rather than invalid value for the rb directive.

There are some constructions like IF directive with EQ operator, which allow to hide some code from assembler, and the intention was that it should be possible to use ERR with such checks.

x = 1
if x = 0
   err
end if    

So whether in some cases you get the display and in some not, may vary wildly with various versions of fasm and - and it is documented that this is not a reliable info

But otherwise fasm would just have to display "code cannot be generated" for any error that occurs, because that's what happens - it cannot find the right solution because of some error.

rb x*2
x = $-1    

What should I expect compiling the following code? A clean compilation or undefined behaviour?

Code:

x = 1
if x = 0
   err
end if    

OK. That's convincing, but I still don't understand, why the behaviour should differ between the provided overflow cases.

As long as fasm didn't get a consistent value for x at the second pass it should continue with more passes. If it fails to continue, then the specific reason for that is that "a consistent value for x could not be found within n passes", if you prefer to give an exact error message.

the values fall into surely supported range    

I made fasm put a little more effort into trying to recover from error when it is a substraction/addition overflow, because I consider it to be probable that such error is temporary in some non-synthetic case, and I don't think it is so probable with multiplication/shifting.

if @F = 1
use16
else
use32
end if
xchg eax,eax
@@:

x = (-1) shl 64
x = -x    

Which one of those was the crucial one may not be decidable in general. And even if some value appeared to be consistent, it may not have been consistent with what value it truly should have had for the correct solution.

(...) so this detail about falling into "surely supported range" seems to be irrelevant.

Could you provide an example (no matter synthetic or non-synthetic, because a correct implementation should not differentiate such things), where fasm is able to recover.

Because as for me the heuristic literally kills fasm :

Code:

if @F = 1
use16
else
use32
end if
xchg eax,eax
@@:

x = (-1) shl 64
x = -x    

If there are multiple valid solutions, it's also not generally decidable, which one should be chosen. However you still choose one. Therefore one possible option is to choose any variable, that did not achieve a consistent value at the last pass (i.e. it's value has changed during the last pass). It would be anyway dependent on that "crucial" one.

Another option is to relax the exactness of the message to smth. like "not all numeric values could be consistently resolved within n passes".