Bug 34462 - [4.3 Regression] tree check: expected ssa_name, have struct_field_tag in vuses_compare, at tree-vn.c:118
Summary: [4.3 Regression] tree check: expected ssa_name, have struct_field_tag in vuse...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords: alias, ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2007-12-14 12:40 UTC by Richard Biener
Modified: 2007-12-14 14:22 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
patch (647 bytes, text/plain)
2007-12-14 12:46 UTC, Richard Biener
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Biener 2007-12-14 12:40:20 UTC
 
Comment 1 Richard Biener 2007-12-14 12:41:49 UTC
On ppc, the following ICEs compiled with -O2 during PRE

typedef __builtin_va_list va_list;
void gftp_config_parse_args (int numargs, char **first, ...)
{
  char **dest = first;
  va_list argp;
  __builtin_va_start (argp, first);
  while (numargs-- > 0)
    {
      *dest = __builtin_malloc (1);
      dest = __builtin_va_arg(argp, char **);
      *dest = ((void *)0);
    }
  __builtin_va_end(argp);
}
Comment 2 Richard Biener 2007-12-14 12:46:58 UTC
Created attachment 14753 [details]
patch

The problem is that the operand scanner is triggered on a fake store inserted
by PRE insert_fake_stores() as if a new stmt_ann is generated, the stmt is
marked modified and bsi_insert_after() will update the stmts operands in this
case.

For some reason this figures new, unrenamed virtual operands:

# VUSE <SFT.2_69, SFT.3_70, SFT.4, SFT.5, SFT.6, SMT.15_71> { SFT.2 SFT.3 SFT.4 SFT.5 SFT.6 SMT.15 }
storetmp.19_3 = *dest_22

which triggers this ICE.

So, I believe we should not re-build operands for this stmt, as we carefuly
use create_ssa_artificial_load_stmt () to do so.  In fact, this will make
the following part of that function non-effective:

  /* All uses in this fake stmt must not be in the immediate use lists.  */
  FOR_EACH_SSA_USE_OPERAND (use_p, new_stmt, iter, SSA_OP_ALL_USES)
    delink_imm_use (use_p);


BUT - this patch causes a whole lot of new problems because suddenly VN_TOP
starts to leak into virtual operands which causes bootstrap to fail on 
x86_64 building bid_decimal_globals.c for 32bit.
Comment 3 Richard Biener 2007-12-14 12:53:00 UTC
Which is of course because SCCVN does not like this sort of "broken" immediate
uses!
Comment 4 Richard Biener 2007-12-14 14:21:54 UTC
Subject: Bug 34462

Author: rguenth
Date: Fri Dec 14 14:21:41 2007
New Revision: 130931

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130931
Log:
2007-12-14  Richard Guenther  <rguenther@suse.de>

	PR middle-end/34462
	* tree-ssa-operands.h (create_ssa_artificial_load_stmt): Add
	parameter to say whether to unlink immediate uses.
	* tree-ssa-operands.c (create_ssa_artificial_load_stmt): Do not
	mark the artificial stmt as modified.  Unlink immediate uses
	only if requested.
	* tree-ssa-dom.c (record_equivalences_from_stmt): Update caller.
	* tree-ssa-pre.c (insert_fake_stores): Likewise.

	* gcc.c-torture/compile/20071214-1.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/20071214-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-dom.c
    trunk/gcc/tree-ssa-operands.c
    trunk/gcc/tree-ssa-operands.h
    trunk/gcc/tree-ssa-pre.c

Comment 5 Richard Biener 2007-12-14 14:22:14 UTC
Fixed.