- Fix bug: do not print IL 'label' when generating inline functions (JMPxx label was generating erroneous C code) 2014-03-02, by mjsousa
- Add limited support for the REF() operator (defined in v3 of IEC 61131-3) 2014-03-02, by mjsousa
- Remove assertion being failed by IL labels (IL labels do not yet have specific datatypes). 2014-02-24, by mjsousa
- Added stage1_2/Makefile.am weird rule to keep compatible with previous version of automake 2014-02-28, by Edouard Tisserant
- Merge 2014-02-19, by Edouard Tisserant
- fix definition of pragma. 2014-02-16, by mjsousa
- Fix the state machine that became broken 2 commits ago (when adding support for nested comments) 2014-02-16, by mjsousa
- Add option to control support for nested comments (default is off, as defined in IEC 61131-3 v2) 2014-02-16, by mjsousa
- Add support for nested comments 2014-02-15, by mjsousa
- Fix bug: when checking compatibility between GLOBAL and EXTERNAL variables, must only enforce GLOBAL CONSTANT => EXTERNAL CONSTANT. 2014-02-12, by mjsousa
- merge 2014-02-11, by mjsousa
- Fix bug: correctly generate code when accessing external variables declared inside FBs as a structured variable (realvar := fb1.fb2.extvar1.realvar) 2014-01-06, by Mario de Sousa
- Fix bug in standard: standard does not allow multiple VAR_GLOBAL ... END_VAR constructs in configurations and resources. This is probably a bug, so we allow it. 2014-02-09, by mjsousa
- Code cleanup (part 3): generate_c_typedecl_c is no longer needed for code generation in POUS.c It is now only needed for datatype declaration in POUS.h 2014-02-09, by mjsousa
- Code cleanup (part 2): generate_typedecl_c now only prints to POUS.h ! 2014-02-08, by mjsousa
- Code cleanup (part 1): subrange check functions are now declared in POUS.h (as static inline functions or #define) 2014-02-08, by mjsousa
- Fix get_datatype_info_c::is_subrange(), which did not work when using base type! (we now use get_equivtype() instead of get_base_type() ) 2014-02-08, by mjsousa
- fix a couple of typos. 2014-02-08, by mjsousa
- Fix bug - correctly declare struct members whose type is a directly defined array (e.g.: STRUCT x: ARRAY of XXX; END_STRUCT) 2014-02-08, by mjsousa
- Start using the called_fb_declaration annotation when generating C code from FB calls in ST. 2014-02-05, by mjsousa
- Code cleanup: move datatype analysis to get_datatype_info_c 2013-12-22, by Mario de Sousa
- Fix bug-fix of previous commit. 2013-12-20, by Mario de Sousa
- Fix bug: allow use, as lvalues, structures/arrays inside FBs (e.g. fb1.struct1.r := 33.3). 2013-12-19, by Mario de Sousa
- Fix bug/issue #33 (correctly access struct/array variables declared inside a FB -> r:=FB1.FB2.struct1.array1[3] ) 2013-12-18, by Mario de Sousa
- Add assertion suggested by Manuele. 2013-09-07, by Mario de Sousa
- merge 2013-08-23, by mjsousa
- Use get_datatype_info_c::is_type_valid() to determine datatype validity 2013-08-23, by mjsousa
- Recursively check the datatype compatibility of values/expressions passed in function/FB invocations. 2013-08-23, by mjsousa
- Change error message text so as to become more suitable to where they might occur in the source code. 2013-08-23, by mjs
- Add code to check if an IN_OUT variable is being passed an IL list in formal IL FB/function invocations. 2013-08-22, by mjsousa