Hi frankie,
This is a compiler bug that fails on the code line:
d->m_dict[TDEFL_LZ_DICT_SIZE + dst_pos] = c;
I've got some more code that compiles without error as 32 bit but shows the same "fatal error: Internal error: 'Access violation' at 0x00007ff7ae3b3e99." when compiled as 64 bit. I've changed all of the d->xxx[ calculations] to the workaround you showed by calculating the index value(s) ahead so that they all become simple d->xxx[ value]. So there appears to be something else under 64 bit.
So is there a particular technique you used to identify code causing the access violation, or is it based on your years of experience?
I managed to get it to compile (and work) in 64 bit by a code change which makes no sense to me. yet it works.
change this line: unsigned int probe_pos = d->m_hash[hash]; // access violation crash
into this line : int probe_pos = d->m_hash[hash]; // no crash - working zip code
Give a man a fish he eats for a day, teach him to fish and he eats for the rest of his life .... 
John Z
John a compiler is a very complex piece of software and the logic behind it is very complicate and fragile.
So when you have a compiler crashing for
internal error, and you don't have the source (and to have them wouldn't be enough at all because you'll miss the whole strategy behind that code) there is no deep analysis you can do.
What you can do is to isolate the offending part of code and try whichever diversion will cross your mind. In the complex compiler logic any diversion can lead to a different path inside, that can eventually skip the bugged code.
So you find a different workaround, but be sure that there could be infinite.
Someday when compilers will use AI they will be supposed to detect by themselves the bugs and correct them. Also the optimization will reach the maximum with all due respect to the assembler enthusiasts.
The cost will be hundreds of GB, fast internet connections, big servers and a lot of waste energy... I'm not so sure I will like that future...
Have a nice week-end
