Bug 21610 - [4.0/4.1 Regression] ICE in make_decl_rtl
Summary: [4.0/4.1 Regression] ICE in make_decl_rtl
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.1
Assignee: Not yet assigned to anyone
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: ice-on-valid-code, patch
Depends on:
Blocks:
 
Reported: 2005-05-16 18:44 UTC by Jakub Jelinek
Modified: 2005-05-17 11:25 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-05-16 19:15:05


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Jelinek 2005-05-16 18:44:42 UTC
struct S { char s; };
struct T { struct S t; };

struct S *const p = &((struct T * const) (0x40000000))->t;

void
foo (void)
{
  p->s = 0;
}

ICEs at -O2 e.g. on {x86_64,i386}-linux on gcc-4_0-branch.  On HEAD it seems to
work by luck.

The problem seems to be tree sharing between p's initializer and foo's body.
The gimplifier destroys the tree, on HEAD then manages to fix it up again
by further optimizations.
Comment 1 Andrew Pinski 2005-05-16 19:15:05 UTC
Hmm, shouldn't we unshare the tree when copy the value of p in? (oh that is what your patch does).
I wonder if we can just get rid of decl_constant_value_for_broken_optimization/decl_constant_value.
Comment 2 Andrew Pinski 2005-05-16 19:17:53 UTC
Oh, I think the reason why the mainline does not create a new tree is because we don't gimple twice.
Comment 3 joseph@codesourcery.com 2005-05-16 20:01:15 UTC
Subject: Re:  [4.0/4.1 Regression] ICE in
 make_decl_rtl

On Mon, 16 May 2005, pinskia at gcc dot gnu dot org wrote:

> Hmm, shouldn't we unshare the tree when copy the value of p in? (oh that is what your patch does).
> I wonder if we can just get rid of decl_constant_value_for_broken_optimization/decl_constant_value.

If you get rid of decl_constant_value_for_broken_optimization then I 
suspect you'll lose some optimizations because fold doesn't operate on SSA 
so some constant values won't be available to fold, only to later 
optimizations.  But you'll get rid of the only references to "optimize" in 
the C front end other than those defining built-in macros, and the 
front-end shouldn't care about "optimize" in principle, and you'll 
probably get rid of some XFAILs in c9?-const-expr-?.c in the process.

Comment 4 Andrew Pinski 2005-05-16 20:03:48 UTC
(In reply to comment #3)
> If you get rid of decl_constant_value_for_broken_optimization then I 
> suspect you'll lose some optimizations because fold doesn't operate on SSA 
> so some constant values won't be available to fold, only to later 
> optimizations.  But you'll get rid of the only references to "optimize" in 
> the C front end other than those defining built-in macros, and the 
> front-end shouldn't care about "optimize" in principle, and you'll 
> probably get rid of some XFAILs in c9?-const-expr-?.c in the process.

Why do you believe fold does not operate on SSA?
Comment 5 joseph@codesourcery.com 2005-05-16 20:28:34 UTC
Subject: Re:  [4.0/4.1 Regression] ICE in
 make_decl_rtl

On Mon, 16 May 2005, pinskia at gcc dot gnu dot org wrote:

> 
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 20:03 -------
> (In reply to comment #3)
> > If you get rid of decl_constant_value_for_broken_optimization then I 
> > suspect you'll lose some optimizations because fold doesn't operate on SSA 
> > so some constant values won't be available to fold, only to later 
> > optimizations.  But you'll get rid of the only references to "optimize" in 
> > the C front end other than those defining built-in macros, and the 
> > front-end shouldn't care about "optimize" in principle, and you'll 
> > probably get rid of some XFAILs in c9?-const-expr-?.c in the process.
> 
> Why do you believe fold does not operate on SSA?

Fold has optimizations working on large complicated trees of expressions, 
looking at their subexpressions and subsubexpressions; such trees are only 
available during parsing, before conversion to GIMPLE form.  If the 
constants aren't available in these non-GIMPLE trees then you lose the 
optimizations.  The folding called from the SSA optimizers can only fold 
smaller fragments of trees.  Everything fold does which looks at 
subexpressions and subsubexpressions of non-GIMPLE trees can in principle 
be done on GIMPLE but I don't think there's evidence that every such fold 
optimization is implemented for GIMPLE.

Here is a trivial example where the transformation ~A + 1 to -A is only 
done by the RTL optimizers in function g but is done by fold for function 
f.

int f(int a) { return ~a + 1; }
int g(int a) { int b = 1; return ~a + b; }

Comment 6 Andrew Pinski 2005-05-16 20:34:38 UTC
Subject: Re:  [4.0/4.1 Regression] ICE in make_decl_rtl


On May 16, 2005, at 4:28 PM, joseph at codesourcery dot com wrote:
>> ------- Additional Comments From pinskia at gcc dot gnu dot org  
>> 2005-05-16 20:03 -------
>> (In reply to comment #3)
>>> If you get rid of decl_constant_value_for_broken_optimization then I
>>> suspect you'll lose some optimizations because fold doesn't operate 
>>> on SSA
>>> so some constant values won't be available to fold, only to later
>>> optimizations.  But you'll get rid of the only references to 
>>> "optimize" in
>>> the C front end other than those defining built-in macros, and the
>>> front-end shouldn't care about "optimize" in principle, and you'll
>>> probably get rid of some XFAILs in c9?-const-expr-?.c in the process.
>>
>> Why do you believe fold does not operate on SSA?
>
> Fold has optimizations working on large complicated trees of 
> expressions,
> looking at their subexpressions and subsubexpressions; such trees are 
> only
> available during parsing, before conversion to GIMPLE form.  If the
> constants aren't available in these non-GIMPLE trees then you lose the
> optimizations.  The folding called from the SSA optimizers can only 
> fold
> smaller fragments of trees.  Everything fold does which looks at
> subexpressions and subsubexpressions of non-GIMPLE trees can in 
> principle
> be done on GIMPLE but I don't think there's evidence that every such 
> fold
> optimization is implemented for GIMPLE.

Yes that is what the tree combiner would do but since I have not have 
time
to work it, we are missing more and more optimizations because not 
having
it.

-- Pinski

Comment 7 CVS Commits 2005-05-17 06:45:55 UTC
Subject: Bug 21610

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	jakub@gcc.gnu.org	2005-05-17 06:45:49

Modified files:
	gcc            : ChangeLog c-typeck.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.c-torture/compile: 20050516-1.c 

Log message:
	PR tree-optimization/21610
	* c-typeck.c (decl_constant_value_for_broken_optimization): If not
	returning DECL, call unshare_expr.
	
	* gcc.c-torture/compile/20050516-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8811&r2=2.8812
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.441&r2=1.442
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5479&r2=1.5480
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050516-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 8 CVS Commits 2005-05-17 07:08:12 UTC
Subject: Bug 21610

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	jakub@gcc.gnu.org	2005-05-17 07:07:59

Modified files:
	gcc            : ChangeLog c-typeck.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.c-torture/compile: 20050516-1.c 

Log message:
	PR tree-optimization/21610
	* c-typeck.c (decl_constant_value_for_broken_optimization): If not
	returning DECL, call unshare_expr.
	
	* gcc.c-torture/compile/20050516-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.249&r2=2.7592.2.250
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.419.2.4&r2=1.419.2.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.181&r2=1.5084.2.182
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050516-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1

Comment 9 Andrew Pinski 2005-05-17 11:25:26 UTC
Fixed.