diff -r e94368340160 -r 57c08195c962 stage3/forced_narrow_candidate_datatypes.cc
--- a/stage3/forced_narrow_candidate_datatypes.cc	Mon Jul 03 20:28:26 2017 +0100
+++ b/stage3/forced_narrow_candidate_datatypes.cc	Mon Jul 03 20:31:47 2017 +0100
@@ -120,6 +120,30 @@
 
 
 
+void forced_narrow_candidate_datatypes_c::set_datatype_in_prev_il_instructions(symbol_c *datatype, il_instruction_c *symbol) {
+	if (NULL == symbol) ERROR;
+	/* In the forced_narrow_candidate_datatypes algorithm, we do NOT set any datatypes to invalid_type_name_c
+	 * Any IL instructions that really are of an invalid_type_name_c (because the IL code is buggy?) have already
+	 * been set by the standard narrow_candidate_datatypes algorithm.
+	 * 
+	 * Remember too that valid IL code may also have some IL instructions correctly set to invalid_type_name_c, especially
+	 * in cases where the data in the accumulator will not be used in the current IL instruction
+	 * For example:
+	 *        LD   bool_var
+	 *        JMPC label1
+	 *        LD 34
+	 *        ST int_var
+	 * lable1:            <----  This IL instruction_c (with NULL symbol->il_instruction) has invalid_type_name_c datatype!!
+	 *        LD T#3s              And yet, the code is legal!!!
+	 *        ST time_var
+	 */ 
+	if (!get_datatype_info_c::is_type_valid(datatype)) return;
+	// Call the 'original' version of the set_datatype_in_prev_il_instructions() function, from narrow_candidate_datatypes_c
+	return narrow_candidate_datatypes_c::set_datatype_in_prev_il_instructions(datatype, symbol);
+}
+
+
+
 void forced_narrow_candidate_datatypes_c::forced_narrow_il_instruction(symbol_c *symbol, std::vector <symbol_c *> &next_il_instruction) {
   if (NULL == symbol->datatype) {
     if (symbol->candidate_datatypes.empty()) {