Discussion:
[tree-ssa] Mainline merge as of 2003-02-02
Diego Novillo
2003-02-03 17:27:30 UTC
Permalink
This merge needed a few tweaks to allow bootstrapping with
-Werror. The warnings are mostly caused by the gimplifier.
There are two types:

- Use of uninitialized variables. Given the following code
fragment:

j = 3;
if (j < 5 || (i = 3) > 0)
j = i++;

The gimplifier will produce the following transformation:

j = 3;
T.1 = j <= 4;
if (T.1 == 0)
{
i = 3;
T.1 = i > 0
};
if (T.1)
{
i.2 = i;
i = i + 1;
j = i.2
};

This trips the warning because we still don't have enough
analysis implemented to determine that 'i' is never used
uninitialized. The two if's generated by the gimplifier are
mutually exclusive. We could probably change the gimplifier to
not do this expansion, but it's easier to fix the code for now.

Initializing inside an if() is not very common, anyway.


- The second type of warning comes from the expanders for
va_start. In tree.c:build_stmt, we have

build_stmt VPARAMS ((enum tree_code code, ...))
{
...
VA_OPEN (p, code);
...
}

build_stmt (code)
{
...
code.162 = (unsigned int)code;
__builtin_va_start (p.161, code.162);
...
}

The builtin expander issues the warning 'second parameter of
`va_start' not last named argument'. Jason thinks that this
warning should be moved up into the front end. I agree with
that.

I added -Wno-error to the files that trigger this warning.


Bootstrapped and tested on x86.


2003-02-03 Diego Novillo <***@redhat.com>

Fix warnings to allow bootstrapping with -Werror.

* Makefile.in (c-semantics.o-warn): Add -Wno-error.
(emit-rtl.o-warn): Likewise.
(profile.o-warn): Likewise.
(tree.o-warn): Likewise.
(OBJS): Remove simple-break-elim.o and simple-goto-elim.o.
* c-pretty-print.c (print_function_decl): Remove unused function.
* bitmap.c (bitmap_last_set_bit): Initialize variable 'word'.
* c-typeck.c (build_binary_op): Initialize variable 'type'.
* combine.c (combine_simplify_rtx): Initialize variable 'reversed'.
(make_compound_operation): Initialize variable 'i'.
* dwarf2out.c (dwarf2out_finish): Initialize variable 'context'.
* expr.c (store_constructor): Initialize variables 'lo', 'hi',
'startb' and 'endb'.
(expand_expr): Initialize variable 'op0'.
* fold-const.c (fold): Initialize variable 'tem'.
* profile.c (branch_prob): Initialize variable 'prev_file_name'.
* reload.c (find_equiv_reg): Initialize variables 'valtry and
'valueno'.
* rtlanal.c (get_jump_table_offset): Initialize variable 'set'.
* ssa-ccp.c (ssa_const_prop): Fix sign mismatch warning.
* varasm.c (output_constant_def): Initialize variable 'defstr'.
* gimplify.c (simplify_expr): Initialize variables
'saved_input_filename' and 'saved_lineno'.
(simplify_compound_lval): Initialize variable 'code'.
* tree-alias-ander.c (pta_bottom): De-ansify.
(andersen_cleanup): Remove unused variables.
(andersen_heap_assign): Mark argument lhs ATTRIBUTE_UNUSED.
(pta_bottom): Remove unused function.
(pta_get_ptsize): Remove unused function.


cp/

2003-02-03 Diego Novillo <***@redhat.com>

* parser.c (cp_parser_asm_definition): Call finish_asm_stmt with
'volatile_p' directly.
* typeck.c (build_binary_op): Initialize variable 'type'.
* Make-lang.in (cp/tree.o-warn): Add -Wno-error.


java/

2003-02-03 Diego Novillo <***@redhat.com>

* parse.y (qualify_ambiguous_name): Initialize variable 'decl'.
Diego Novillo
2003-02-03 17:45:59 UTC
Permalink
Post by Diego Novillo
- Use of uninitialized variables. Given the following code
j = 3;
if (j < 5 || (i = 3) > 0)
j = i++;
j = 3;
T.1 = j <= 4;
if (T.1 == 0)
{
i = 3;
T.1 = i > 0
};
if (T.1)
{
i.2 = i;
i = i + 1;
j = i.2
};
This trips the warning because we still don't have enough
analysis implemented to determine that 'i' is never used
uninitialized. The two if's generated by the gimplifier are
mutually exclusive. We could probably change the gimplifier to
^^^^^^^^^
Er, the example is bogus. Sorry.

Variable 'i' can indeed be used uninitialized in this case. I'll
try to distill a better example from one of the files that were
triggering the warning.


Diego.
Daniel Berlin
2003-02-03 17:51:04 UTC
Permalink
Post by Diego Novillo
(pta_bottom): Remove unused function.
This is about to be used momentarily (IE i was seconds away from
committing a patch that used it).
Post by Diego Novillo
(pta_get_ptsize): Remove unused function.
This one will be used slightly more in the future (to determine if we
should aggregate or not).


Can you just #if 0 these out for the moment, and i'll remove the #if
0's when they are used?
--Dan
Diego Novillo
2003-02-03 17:56:42 UTC
Permalink
Post by Daniel Berlin
Can you just #if 0 these out for the moment, and i'll remove the #if
0's when they are used?
That's what I did. Oh, and I forgot to ask you in my previous
message about the warnings we get in tree-alias-ander.c due to
libbanshee's headers. Could those be fixed?


Diego.
Daniel Berlin
2003-02-03 18:06:34 UTC
Permalink
Post by Diego Novillo
Post by Daniel Berlin
Can you just #if 0 these out for the moment, and i'll remove the #if
0's when they are used?
That's what I did. Oh, and I forgot to ask you in my previous
message about the warnings we get in tree-alias-ander.c due to
libbanshee's headers. Could those be fixed?
Done.
Post by Diego Novillo
Diego.
Diego Novillo
2003-02-03 19:35:02 UTC
Permalink
Post by Diego Novillo
That's what I did. Oh, and I forgot to ask you in my previous
message about the warnings we get in tree-alias-ander.c due to
libbanshee's headers. Could those be fixed?
Done.
Cool. Thanks.


Diego.
Daniel Berlin
2003-02-03 18:09:18 UTC
Permalink
I should mention, since this merge, i now get:

gcc -c -g -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wtraditional -pedantic -Wno-long-long -fno-common -DHAVE_CONFIG_H
-I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config
-I../../gcc/../include -I../../gcc/../libbanshee/libcompat
-I../../gcc/../libbanshee -I../../gcc/../libbanshee/points-to
../../gcc/c-lex.c -o c-lex.o
In file included from ../../gcc/c-tree.h:25,
from ../../gcc/c-lex.c:33:
../../gcc/c-common.h:996:1: warning: "GOTO_DESTINATION" redefined

In file included from ../../gcc/c-lex.c:29:
../../gcc/tree.h:992:1: warning: this is the location of the previous
definition
gcc -c -g -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wtraditional -pedantic -Wno-long-long -fno-common -DHAVE_CONFIG_H
-I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config
-I../../gcc/../include -I../../gcc/../libbanshee/libcompat
-I../../gcc/../libbanshee -I../../gcc/../libbanshee/points-to
../../gcc/c-pragma.c -o c-pragma.o
In file included from ../../gcc/c-pragma.c:34:
../../gcc/c-common.h:996:1: warning: "GOTO_DESTINATION" redefined
In file included from ../../gcc/c-pragma.c:27:


all over the place.

And it's right.
It's defined in both tree.h and c-common.h
Post by Diego Novillo
Post by Daniel Berlin
Can you just #if 0 these out for the moment, and i'll remove the #if
0's when they are used?
That's what I did. Oh, and I forgot to ask you in my previous
message about the warnings we get in tree-alias-ander.c due to
libbanshee's headers. Could those be fixed?
Diego.
Diego Novillo
2003-02-03 19:34:35 UTC
Permalink
Post by Daniel Berlin
gcc -c -g -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wtraditional -pedantic -Wno-long-long -fno-common -DHAVE_CONFIG_H
-I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config
-I../../gcc/../include -I../../gcc/../libbanshee/libcompat
-I../../gcc/../libbanshee -I../../gcc/../libbanshee/points-to
../../gcc/c-lex.c -o c-lex.o
In file included from ../../gcc/c-tree.h:25,
../../gcc/c-common.h:996:1: warning: "GOTO_DESTINATION" redefined
Thanks. I just saw this myself. I messed up the merge in
tree.h. I'll fix it momentarily.


Diego.
Richard Henderson
2003-02-06 02:23:10 UTC
Permalink
Post by Diego Novillo
- The second type of warning comes from the expanders for
va_start. In tree.c:build_stmt, we have
build_stmt VPARAMS ((enum tree_code code, ...))
{
...
VA_OPEN (p, code);
...
}
build_stmt (code)
{
...
code.162 = (unsigned int)code;
__builtin_va_start (p.161, code.162);
...
}
The builtin expander issues the warning 'second parameter of
`va_start' not last named argument'. Jason thinks that this
warning should be moved up into the front end. I agree with
that.
Indeed, not only should the warning be handled by the front end,
but I expect that va_start itself should be expanded so that it
can be gimplified.



r~

Loading...