Previously, they were hard-coded as 60, but the clock tick frequency actually depends on the video mode. They now call a new library function that can detect the video mode and return the proper value.
This also makes CLOCKS_PER_SEC have the type clock_t, as C99 and later require.
These are currently only run by the new DOIT3 test-running script.
Note that these tests are designed to be applicable to most implementations of C95/C99/C11, not just ORCA/C. They do make certain assumptions not guaranteed by the standards (e.g. power of 2 types and some properties of IEEE-like FP), but in general those assumptions should be true for most 'normal' systems.
Enumeration constants must have values representable as an int (i.e. 16-bit signed values, in ORCA/C), but errors were not being reported if code tried to use the values 0xFFFF8000 to 0xFFFFFFFF. This problem could also affect certain larger values of type unsigned long long. The issue stemmed from not properly accounting for whether the constant expression had a signed or unsigned type.
This sample code demonstrated the problem:
enum E {
a = 0xFFFFFFFF,
b = 0xFFFF8000,
y = 0x7FFFFFFFFFFFFFFFull,
z = 0x8000000000000000
};
This should be allowed, but it previously could lead to spurious errors in contexts like argument lists, where a comma would normally be expected to end the expression.
The following example program demonstrated the problem:
#include <stdlib.h>
int main(void) {
return abs(1 ? 2,-3 : 4);
}
The correct values for LDBL_MAX and LDBL_MIN can now be provided, because we support long double constants. The other values are also updated to have more precision, so that they evaluate to bit-correct values in the long double format.
For now, this is only used for _Generic expressions. Eventually, it should probably replace the current CompTypes, but CompTypes currently performs somewhat looser checks that are suitable for some situations, so adjustments would be needed at some call sites.
These were previously treated as having type int. This resulted in incorrect results from sizeof, and would also be a problem for _Generic if it was implemented.
Note that this creates a token kind of "charconst", but this is not the kind for character constants in the source code. Those have type int, so their kind is intconst. The new kinds of "tokens" are created only through casts of constant expressions.
Previously, the type was forced to extended in many circumstances. This was visible in that the results of sizeof were incorrect. It would also affect _Generic, if and when that is implemented.
Note that this does not affect the actual format used for computations and storage of intermediates. That is still the extended format.
This could read and write a byte beyond the value being modified. This normally would not matter, but theoretically could in some cases involving concurrency.
The C standards generally allow floating-point operations to be done with extra range and precision, but they require that explicit casts convert to the actual type specified. ORCA/C was not previously doing that.
This patch relies on some new library routines (currently in ORCALib) to do this precision reduction.
This fixes#64.
The FENV_ACCESS pragma is now implemented. It causes floating-point operations to be evaluated at run time to the maximum extent possible, so that they can affect and be affected by the floating-point environment. It also disables optimizations that might evaluate floating-point operations at compile time or move them around calls to the <fenv.h> functions.
The FP_CONTRACT and CX_LIMITED_RANGE pragmas are also recognized, but they have no effect. (FP_CONTRACT relates to "contracting" floating-point expressions in a way that ORCA/C does not do, and CX_LIMITED_RANGE relates to complex arithmetic, which ORCA/C does not support.)
This was already done by the optimizer, but it is simple enough to just do it all the time. This avoids most performance regressions from the previous commit, and also generates more efficient code for long long stores (in the common cases where the value of an assignment expression is not used in any larger expression).
The value of an assignment expression should be exactly what gets written to the destination, without any extra range or precision. Since floating-point expressions generally do have extra precision, we need to load the actual stored value to get rid of it.
This means that floating-point constants can now have the range and precision of the extended type (aka long double), and floating-point constant expressions evaluated within the compiler also have that same range and precision (matching expressions evaluated at run time). This new behavior is intended to match the behavior specified in the C99 and later standards for FLT_EVAL_METHOD 2.
This fixes the previous problem where long double constants and constant expressions of type long double were not represented and evaluated with the full range and precision that they should be. It also gives extra range and precision to constants and constant expressions of type double or float. This may have pluses and minuses, but at any rate it is consistent with the existing behavior for expressions evaluated at run time, and with one of the possible models of floating point evaluation specified in the C standards.
This gives the name of the current function, as if the following definition appeared at the beginning of the function body:
static const char __func__[] = "function-name";
These instructions can be generated for indirect accesses to quad values, and the optimization can sometimes make those code sequences more efficient (e.g. avoiding unnecessary reloads of Y).
It was calling fabs() without having included <math.h>, causing fabs() to be treated as returning an int rather than a floating-point value. This misinterpretation of the return value could cause test failures.
* longlong:
In PP expressions, make sure identifiers turn into 0LL.
Optimize quad == 0 comparisons.
Do unsigned quad inequalities without loading operands on stack.
Do quad equality comparisons without loading operands on stack.
Do unary quad ops without loading operand on stack.
Do quad add/subtract without loading operands on stack.
Implement support for doing quad ops without loading operands on stack.
Evaluate constant expressions with long long and floating operands.
Let functions store a long long return value directly into a variable in the caller.
Optimize some quad ops to use interleaved loads and stores.
Basic infrastructure for using different quadword locations in codegen.
Allow static evaluation of ? : expressions with long long operands.
Statically evaluate casts to and from long long.
Implement conversions from long long to other types in the optimizer.
Add various intermediate code peephole optimizations.
Fix a comment.
Support switch statements using long long expressions.
Update headers to support long long (and intmax_t typedef'd as long long).
Add the predefined macro __ORCAC_HAS_LONG_LONG__.
Do preprocessor arithmetic in intmax_t/uintmax_t (aka long long types).
Evaluate 64-bit comparisons in constant expressions.
Add support for real to long long conversions.
Implement comparisons for signed long long.
Implement comparisons (>, >=, <, <=) for unsigned long long.
Support 64-bit decimal constants in code.
Evaluate arithmetic and shifts in long long constant expressions.
Update printf/scanf format checker to match recent library changes.
Implement && and || operators for long long types.
Implement pc_ind (load indirect) for long long.
Do not corrupt long long expressions that cannot be evaluated at compile time.
Report errors in a few cases where the codegen finds unexpected types.
Slightly optimize stack save code for calls to long long functions.
Handle long long in pc_equ/pc_neq optimizations.
Allow unsigned constants in "address+constant" constant expressions.
Evaluate some kinds of long long operations in constant expressions.
Implement 64-bit shifts.
Implement basic peephole optimizations for some 64-bit operations.
Do not copy CGI.Comments into CGI.pas.
Generate code for long long to real conversions.
Don't bogusly push stuff on the stack for conversions to non-long types.
Implement support for functions returning (unsigned) long long.
Compute how many bytes of arguments are passed to a function.
Implement 64-bit division and remainder, signed and unsigned.
Implement 64-bit multiplication support.
Allow pointer arithmetic using long long values.
Implement indirect store/copy operations for 64-bit types.
Add long long support for a couple lint checks.
Add long long support for the ! operator.
Give an error when trying to evaluate constant expressions with long long operands.
Make expressionValue a saturating approximation of the true value for long long expressions.
Enable automatic comparison with 0 for long longs.
Add some support for ++/-- on long long values.
Add support for emitting 64-bit constants in statically-initialized data.
Add most of the infrastructure to support 64-bit decimal constants.
Support 64-bit integer constants in hex/octal/binary formats.
Initial support for constants with long long types.
Implement equality/inequality comparisons for 64-bit types.
Implement remaining conversions of integer types to and from long long.
Update the debugging format for long long values.
Begin implementing conversions to and from 64-bit types.
Implement 64-bit addition and subtraction.
Add support for new pcodes in optimizer.
Implement unary negation and bitwise complement for 64-bit types.
Implement bitwise and/or/xor for 64-bit types.
Handle (unsigned) long long in the front-end code for binary conversions.
Restore old order of baseTypeEnum values.
Implement basic load/store ops for long long.
Initial code to recognize 'long long' as a type.
