home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
IRIS Development Option 6.2
/
IRIS_Development_Option_6.2_814-0478-001.iso
/
relnotes
/
c_dev
/
ch4.z
/
ch4
Wrap
Text File
|
1996-03-14
|
19KB
|
594 lines
- 1 -
6.2 ANSI C Release Notes
- 2 -
DDDDooooccccuuuummmmeeeennnntttt NNNNuuuummmmbbbbeeeerrrr 000000007777----1111666655559999----000011110000
4. _K_n_o_w_n__P_r_o_b_l_e_m_s__a_n_d__W_o_r_k_a_r_o_u_n_d_s
Unless otherwise indicated, the following bugs
in release 6.2 of the C compiler apply to both
traditional C and ANSI C.
4.1 _K_n_o_w_n__P_r_o_b_l_e_m_s__(_6_4_-_B_i_t__M_o_d_e_)
This section describes problems known to exist
in the 6.2 C compiler running in 64-bit mode.
4.1.1 _P_r_e_p_r_o_c_e_s_s_o_r
+o A warning is issued about macro
redefinitions, even when the new definition
is lexically identical to the existing
(previous) definition.
4.1.2 _C_o_m_p_i_l_e_r
+o For inlined functions, we generate code and
debugging information, even though the
function may be static and inlined at every
call site.
+o We cannot completely turn off the warning:
"209116.c", line 4971: warning(1556): transfer of control bypasses
initialization of:
variable "count" (declared at line 5067)
goto try_autogrow;
with the -_w_o_f_f _1_5_5_6 option, since the
message fragment:
variable "count" (declared at line 5067)
still will be output.
4.2 _K_n_o_w_n__P_r_o_b_l_e_m_s__(_3_2_-_B_i_t__M_o_d_e_)
This section describes problems known to exist
in the 6.2 C compiler running in 32-bit mode.
- 3 -
4.2.1 _P_r_e_p_r_o_c_e_s_s_o_r
+o The following is permitted by the _c_f_e
preprocessor:
#undef __STDC__
However, it should be illegal.
+o The source location for ``f()'' in:
# /* some rather
lengthy
and multi-line
comment */
void f(void) {...}
will be wrongly perceived by _c_f_e to begin
at the line where the comment starts, since
the "#" is assumed to be a line-directive
while the whole comment is viewed as a
single space within the line-directive.
This will cause _d_b_x to list the wrong
source lines for statements in the body of
``f()''.
+o The -_w_l_i_n_t option causes an incorrect
``implicit type conversion'' warning when
an enumerator is assigned to an enumeration
variable, and may also cause incorrect
``used before set'' warnings for variables
in the controlling expressions of loops:
void
foo(int *head)
{
enum E {e1, e2, e3} c;
int *p, *nextp;
int i;
/* incorrect warning: "implicit conversion from int to enum" */
c = e1;
/* incorrect warning: "i may be used before set" */
do {i = *(p++);} while (!i);
/* incorrect warning: "nextp may be used before set" */
for (p = head; p; p = nextp) nextp = p;
}
- 4 -
+o There is a problem with constant
propagation in the context of weakextern
definitions. For the source:
#include <stdio.h>
extern int a;
#pragma weak a=b
int b = 3;
main()
{
a = 5;
printf("%d, %d", a, b);
}
the output when compiled without any
optimization (-_O_0) ``5, 5'', as expected,
while with optimization the output is ``5,
3''. The latter is a result of constant
propagation, which reduces the body of
``main()'' to:
printf("%d, %d", 5, b);
thus effectively eliminating the assignment
to ``a'' and its alias ``b''.
4.2.2 _C_o_m_p_i_l_e_r
+o Signed and unsigned ``long long''
bitfields, spanning across a 32-bit (word)
aligned boundary, can only be accessed
through the ``.'' operator when the left-
hand side is an addressable lvalue. This
is a limitation of our compiler front-end
(_c_f_e) implementation and _c_f_e will emit
error messages when this constraint is
violated. In earlier versions of the
compiler, _c_f_e terminated with an assertion
for such expressions.
+o An indexing expression with a complicated
index expression may sometime generate
illegal ucode, which causes _u_g_e_n to core
dump. A workaround is to move the index
expression out and assign it to a temporary
variable, or just change the expression.
The following illustrates the only known
case of this happening:
- 5 -
char board[19];
int capture[2];
setboard (int x)
{
capture[!(board[x])]++; /* Ugen coredumps on this! */
capture[(board[x])?0:1]++; /* This works just fine! */
}
+o A standalone _l_i_n_t is available, but it does
not support the same options and
compilation modes supported by the C
compiler (it supports the the AT&T SVR4
compilation modes, and treats ``long long''
types as ``long''). Unless _l_i_n_t is used to
handle _l_i_n_t-directives, to provide _l_i_n_t_2
diagnostics, or to produce the _l_i_n_t output
files, we instead strongly recommend use of
the -_w_l_i_n_t option with the _c_c command.
This option works with all the other
compiler options and flags, including
compilation in ANSI mode. Note that -_w_l_i_n_t
does not produce the traditional output
files from the _l_i_n_t passes, nor does it
handle _l_i_n_t directives, while it does
provide _l_i_n_t-like diagnostics.
4.3 _K_n_o_w_n _P_r_o_b_l_e_m_s _w_i_t_h _W_o_r_k_a_r_o_u_n_d_s (_6_4-_B_i_t
_M_o_d_e)
+o The 64-bit and N32 Optimizer produces code
(at optimization level -_O_2 ) that can
suffer from poor performance under the
following conditions:
+o The program has NOT been marked
QUICKSTART by ld, (You can verify
whether a program has been marked
QUICKSTART by running the %elfdump
-info command.) OR the program has
been marked QUICKSTART by ld, but has
not been requickstarted (see _r_q_s(1)
for more info).
+o The program contains loops where
functions are called and executed for
the first time.
Under these circumstances, the optimizer
produces code that moves the instruction
that loads the address of the function out
- 6 -
of the loop and replaces it with a load of
the temporary register that contains that
address. As a result, if that address has
not been resolved by rld (either by that
function being called previously, or by the
program being QUICKSTARTED), the code will
repeatedly call the stub that rld uses for
lazy text resolution. The program will
execute properly, but with a large
performance degradation.
You can verify that this is happening by
doing the following:
For N32 programs:
%setenv _RLDN32_PATH /usr/lib32/rld.debug
%setenv _RLD_ARGS "-trace"
For N64 programs:
%setenv _RLD64_PATH /usr/lib64/rld.debug
%setenv _RLD_ARGS "-trace"
Running the program then generates a trace
log which can be searched for "lazy text
of". If you see the same symbol being
resolved, you have this problem.
For programs that have been marked
QUICKSTART, you can execute the following
workaround before running the executable:
%setenv LD_BIND_NOW 1
(Bug #355959)
+o Benchmarks using computational kernels that
operate on arrays with dimensions of a
modulus of the cache size can cause cache
line thrashing. This condition will usually
manifest in a program taking much longer to
compile than expected, and can be analyzed
further by monitoring system performance
statistics such as I/O use during
compilation. The remedy is to increase the
size of the array by a multiple of the
cache line size. Because cache line size
is fixed for each specific architecture,
check your hardware documentation to see
what applies for your system. (126115)
- 7 -
+o The following will produce an error message
in -cckr mode:
struct X {int i;} *j, *k;
main()
{
j = k?k:k?0:0;
}
since k?0:0 is an int expression, and as
such is incompatible with k which is a
pointer. (224372)
4.4 _K_n_o_w_n _P_r_o_b_l_e_m_s _w_i_t_h _W_o_r_k_a_r_o_u_n_d_s (_3_2-_B_i_t
_M_o_d_e)
+o In 3.17 and earlier versions of the
compiler, no diagnostics were emitted (by
default) in -_c_c_k_r mode for a function
redeclaration with incompatible parameter
types. This could be highly error-prone,
since an argument could be passed to the
same function in differing ways, dependent
on which declaration were in scope at the
point of call. Consider the following
code:
#include <stdio.h>
int f(float f1, float f2);
f(f1, f2)
float f1, f2;
{
printf("f1=%g, f2=%g0, f1, f2);
}
main()
{
f(17.17, 17.17);
}
The unprototyped function definition
expects float arguments to be promoted to
doubles (64 bits entities), while the call
in fact heeds the prototype and passes the
arguments as floats (32 bits entities).
The values printed will be unpredictable.
To avoid this kind of unexpected behavior
we highly recommend that users compile
their code with -_p_r_o_t_o_t_y_p_e_s in -_c_c_k_r mode.
For redeclarations, where references to
parameters in the function body may access
- 8 -
a different bit pattern than that passed on
the caller site (as in the above example),
we now issue an error in -_c_c_k_r mode. Other
forms of incompatible redeclarations still
pass without any diagnostics. The old
(ccom) compiler sometimes successfully
combined such incompatible redeclarations,
but not always. We therefore found it
sounder to disallow the most blatant forms
of mismatches in this version of the
compiler.
+o Note that _l_i_n_t incorrectly diagnoses a
syntax error for the latter of the
following two declarations for
``XSynchronize'':
typedef int Display;
extern int (*XSynchronize(int*))();
extern int (*XSynchronize(Display*))();
The first form of declaration (without the
typedef) can be used as a workaround for
this particular problem.
+o The compiler will incorrectly diagnose the
last of the initializers in the following
code fragment as an incorrect initializing
expression:
typedef unsigned int size_t;
typedef struct uacdef
{
unsigned int *uacind;
unsigned int *uacaln;
unsigned int *uacrcp;
unsigned int *uaccal;
} uacdef;
size_t uacsiz[] = {
(size_t)&(((uacdef*)0))->uacrcp,
(1&0x40 ? sizeof(uacdef) : (unsigned int)&(((uacdef*)0))->uacrcp),
(1&0x40 ? sizeof(uacdef) : (size_t)&(((uacdef*)0))->uacrcp)
};
The first two forms of initializers may be
used as a workaround for this problem.
+o Benchmarks using computational kernels that
operate on arrays with dimensions of a
modulus of the cache size can cause cache
- 9 -
line thrashing. This condition will usually
manifest in a program taking much longer to
compile than expected, and can be analyzed
further by monitoring system performance
statistics such as I/O use during
compilation. The remedy is to increase the
size of the array by a multiple of the
cache line size. Because cache line size
is fixed for each specific architecture,
check your hardware documentation to see
what applies for your system. (126115)
