This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/29478] [4.2 Regression] optmization generates warning for casts
- From: "amylaar at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 23 Oct 2006 17:30:22 -0000
- Subject: [Bug middle-end/29478] [4.2 Regression] optmization generates warning for casts
- References: <bug-29478-11533@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #7 from amylaar at gcc dot gnu dot org 2006-10-23 17:30 -------
(In reply to comment #6)
> A regression hunt identified the following patch:
>
> http://gcc.gnu.org/viewcvs?view=rev&rev=116424
>
> r116424 | amylaar | 2006-08-25 18:51:57 +0000 (Fri, 25 Aug 2006)
>
When I modify the testcase to have the function defintion after the use:
struct block;
static int remove_out_of_scope_renamings ();
int
ada_lookup_symbol_list (const struct block *block0)
{
return remove_out_of_scope_renamings ((struct block *) block0);
}
static int
remove_out_of_scope_renamings (current_block)
struct block *current_block;
{
return 1;
}
I still see that the cast has been stripped at the point where
c_convert_parm_for_inlining is called:
(gdb) call debug_tree(value)
<parm_decl 0xb593c000 block0
type <pointer_type 0xb59315c0
type <record_type 0xb5931564 block readonly VOID
...
OTOH, if I further change the passed parameter to a plain 0, value contains an
unadorned integer constant.
(gdb) call debug_tree(value)
<integer_cst 0xb58aa978 type <integer_type 0xb58bb284 int> constant invariant
0>
I think it is wrong that we are optimizing the expression before converting
it to the required type.
Moreover, why is it right to drop NOP_EXPRESSIONS there? If for some reason
the compiler finds it needs to put the initializer in a temporary variable,
and uses the type of the value for that variable, we'll get an alias set
problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478