tinycc/tests/tests2/33_ternary_op.expect

33_ternary_op.c:26: warning: pointer/integer mismatch in conditional expression
0
1
4
9
16
15
18
21
24
27
152
okay
1
Factor out common type combination as there's overlap between handling types for binary and ternay operations. Factor this into a single routine (combine_types). This uses the structure that gen_op was following, and expr_cond was using as well in the past, which I find easier to reconvene with the standard language. But it reuses the new functions for diagnostics to improve (a little) on what GCC or clang produce :) 2020-01-18 09:36:29 +08:00			`33_ternary_op.c:26: warning: pointer/integer mismatch in conditional expression`
tests: Added numerous tests. The tests are taken almost verbatim from the open source project PicoC. It can be found at https://code.google.com/p/picoc/. The tests range from very simple/trivial ones to more complicated. My view is that the more tests the better. Without tests like this I was very reluctant to make any changes to tcc for the fear of breaking things. The tests pass on Win32, OSX, Linux x86 and x86_64. One or two tests fail on each platform due to differences in the runtime library. 2012-06-19 01:27:32 +08:00			`0`
			`1`
			`4`
			`9`
			`16`
			`15`
			`18`
			`21`
			`24`
			`27`
Factor out common type combination as there's overlap between handling types for binary and ternay operations. Factor this into a single routine (combine_types). This uses the structure that gen_op was following, and expr_cond was using as well in the past, which I find easier to reconvene with the standard language. But it reuses the new functions for diagnostics to improve (a little) on what GCC or clang produce :) 2020-01-18 09:36:29 +08:00			`152`
Fix more jumpopts (in ternary op) the code in expr_cond save nocode_wanted around some parts of expression evaluation, but at the wrong spots. If the evaluation of the condition itself (e.g. in the testcase the first whole ternary expression) resulted in CODE_OFF, then that was saved, and restored before return, even if in-between codegen would have CODE_ON'ed already. Thus the whole CODE_OFF state bled out to outside the expression evaluation and also disabled the whole if-block. Found by yarpgen v1 (seed 64). 2023-03-10 01:18:29 +08:00			`okay`
Fix nocode_wanted in expr_landor The generated code by yarpgen failed. I traced the problem to expr_landor. The problem was that nocode_wanted was removing too much code. See also testcase 33. 2023-03-11 14:51:00 +08:00			`1`