diff mbox

Combine location with block using block_locations

Message ID 20120919094040.GA3014@virgil.arch.suse.de
State New
Headers show

Commit Message

Martin Jambor Sept. 19, 2012, 9:40 a.m. UTC 
Hi,

On Wed, Sep 12, 2012 at 04:17:45PM +0200, Michael Matz wrote:
> Hi,
> 
> On Wed, 12 Sep 2012, Michael Matz wrote:
> 
> > > Hm, but we shouldn't end up streaming any BLOCKs at this point (nor 
> > > local TYPE_DECLs).  Those are supposed to be in the local function 
> > > sections only where no fixup for prevailing decls happens.
> > 
> > That's true, something is fishy with the patch, will try to investigate.
> 
> ipa-prop creates the problem.  Its tree mapping can contain expressions, 
> expressions can have locations, locations now have blocks.  The tree maps 
> are stored as part of jump functions, and hence as part of node summaries.  
> Node summaries are global, hence blocks, and therefore block vars can be 
> placed in the global blob.
> 
> That's not supposed to happen.  The patch below fixes this instance of the 
> problem and makes the testcase work with Dehaos patch with the 
> LTO_NO_PREVAIL call added back in.
> 

The following patch implements the unsharing and location pruning at
all required places in a way that passes bootstrap and testing on an
x86_64-linux.  Honza pre-approved it on IRC so unless there are any
objections within a few hours I'm going to commit it.

(The patch does not introduce any of the asserts Michael's patch had
because, as far as I my grep told me, IS_UNKNOWN_LOCATION is not in
trunk yet and I suppose the pre-approval does not cover introducing
things like that.)

Thanks,

Martin


2012-09-18  Martin Jambor  <mjambor@suse.cz>

	* ipa-prop.c (prune_expression_for_jf): New function.
	(ipa_set_jf_constant): Use it.
	(ipa_set_jf_arith_pass_through): Likewise.
	(determine_known_aggregate_parts): Likewise.

Comments

Michael Matz Sept. 19, 2012, 2 p.m. UTC | #1 
Hi,
On Wed, 19 Sep 2012, Martin Jambor wrote:

> (The patch does not introduce any of the asserts Michael's patch had 
> because, as far as I my grep told me, IS_UNKNOWN_LOCATION is not in 
> trunk yet and I suppose the pre-approval does not cover introducing 
> things like that.)

Dehaos patch contains it.  For current trunk it would simply be an 
equality test with UNKNOWN_LOCATION.  If have no opinion if the asserts 
should be there or not.


Ciao,
Michael.
Dehao Chen Sept. 19, 2012, 7:59 p.m. UTC | #2 
This patch was commited as r191494.

Thank all for the reviews and helping test.
Dehao
Paolo Carlini Sept. 20, 2012, 1:04 p.m. UTC | #3 
Hi,

On 09/19/2012 09:59 PM, Dehao Chen wrote:
> This patch was commited as r191494.
I'm afraid I can't help *much* with the debugging, but on my 
x86_64-linux machine and a very straightforward configuration 
(--enable-languages=c++ --disable-multilib) after r191494 I'm seeing the 
following libstdc++ regressions.

FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors)
FAIL: 17_intro/headers/c++1998/all_c++200x_compatibility.cc (test for 
excess errors)
FAIL: 17_intro/headers/c++1998/all_pedantic_errors.cc (test for excess 
errors)
FAIL: 17_intro/headers/c++1998/stdc++.cc (test for excess errors)
FAIL: 17_intro/headers/c++1998/stdc++_multiple_inclusion.cc (test for 
excess errors)
FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for 
excess errors)

are all ICEs like the below. Apparently PCHs are required, I can't 
reproduce outside the testsuite, without the library PCHs.

Does it make any sense to you? Please let me know if I can somehow help.

Thanks,
Paolo.

///////////////////

In file included from 
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_ios.h:39:0, 

                  from 
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/ios:45, 

                  from 
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/istream:40, 

                  from 
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:39, 

                  from 
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/complex:47, 

                  from 
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdc++.h:67, 

                  from 
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdtr1c++.h:29, 

                  from 
/scratch/Gcc/svn-dirs/trunk/libstdc++-v3/include/precompiled/extc++.h:30:
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h: 
In member function 'virtual std::ctype<char>::char_type 
std::ctype<char>::do_widen(char) const':
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:1077:7: 
internal compiler error: Segmentation fault
        do_widen(char __c) const
        ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Paolo Carlini Sept. 20, 2012, 1:26 p.m. UTC | #4 
On 09/20/2012 03:04 PM, Paolo Carlini wrote:
> are all ICEs like the below. Apparently PCHs are required, I can't 
> reproduce outside the testsuite, without the library PCHs.
Take this only as a vague hint: I'm seeing many pch-related regressions 
here, between r191490 and r191501:

     http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01906.html
     http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01924.html

Paolo.
Martin Jambor Sept. 20, 2012, 2:05 p.m. UTC | #5 
On Thu, Sep 20, 2012 at 03:26:29PM +0200, Paolo Carlini wrote:
> On 09/20/2012 03:04 PM, Paolo Carlini wrote:
> >are all ICEs like the below. Apparently PCHs are required, I can't
> >reproduce outside the testsuite, without the library PCHs.
> Take this only as a vague hint: I'm seeing many pch-related
> regressions here, between r191490 and r191501:

r191502 is the jump function expression unsharing and location pruning
patch of mine so if that revision fixes it, it's probably the same
problem.  (I'm still a bit surprised though, I thought the issue was
an LTO one.  But perhaps not.)

Martin

> 
>     http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01906.html
>     http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01924.html
> 
> Paolo.
Paolo Carlini Sept. 20, 2012, 2:13 p.m. UTC | #6 
On 09/20/2012 04:05 PM, Martin Jambor wrote:
> On Thu, Sep 20, 2012 at 03:26:29PM +0200, Paolo Carlini wrote:
>> On 09/20/2012 03:04 PM, Paolo Carlini wrote:
>>> are all ICEs like the below. Apparently PCHs are required, I can't
>>> reproduce outside the testsuite, without the library PCHs.
>> Take this only as a vague hint: I'm seeing many pch-related
>> regressions here, between r191490 and r191501:
> r191502 is the jump function expression unsharing and location pruning
> patch of mine so if that revision fixes it, it's probably the same
> problem.  (I'm still a bit surprised though, I thought the issue was
> an LTO one.  But perhaps not.)
Note that the regressions are still there post r191502 (and that is 
consistent with what I'm seeing on my own machine):

     http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01954.html
     http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01962.html
     http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01970.html
     http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01976.html

Paolo.
Jan Hubicka Sept. 20, 2012, 2:26 p.m. UTC | #7 
> On Thu, Sep 20, 2012 at 03:26:29PM +0200, Paolo Carlini wrote:
> > On 09/20/2012 03:04 PM, Paolo Carlini wrote:
> > >are all ICEs like the below. Apparently PCHs are required, I can't
> > >reproduce outside the testsuite, without the library PCHs.
> > Take this only as a vague hint: I'm seeing many pch-related
> > regressions here, between r191490 and r191501:
> 
> r191502 is the jump function expression unsharing and location pruning
> patch of mine so if that revision fixes it, it's probably the same
> problem.  (I'm still a bit surprised though, I thought the issue was
> an LTO one.  But perhaps not.)

Jump functions never go to PCH and you did not change any GTY annotations, so I
would bet it is unrelated to that changes.

Honza
Dehao Chen Sept. 20, 2012, 2:59 p.m. UTC | #8 
Hi, Paolo,

I'll look into the ICE problems now.

Thanks,
Dehao

On Thu, Sep 20, 2012 at 9:04 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>
>
> On 09/19/2012 09:59 PM, Dehao Chen wrote:
>>
>> This patch was commited as r191494.
>
> I'm afraid I can't help *much* with the debugging, but on my x86_64-linux
> machine and a very straightforward configuration (--enable-languages=c++
> --disable-multilib) after r191494 I'm seeing the following libstdc++
> regressions.
>
> FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors)
> FAIL: 17_intro/headers/c++1998/all_c++200x_compatibility.cc (test for excess
> errors)
> FAIL: 17_intro/headers/c++1998/all_pedantic_errors.cc (test for excess
> errors)
> FAIL: 17_intro/headers/c++1998/stdc++.cc (test for excess errors)
> FAIL: 17_intro/headers/c++1998/stdc++_multiple_inclusion.cc (test for excess
> errors)
> FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
> FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for excess
> errors)
>
> are all ICEs like the below. Apparently PCHs are required, I can't reproduce
> outside the testsuite, without the library PCHs.
>
> Does it make any sense to you? Please let me know if I can somehow help.
>
> Thanks,
> Paolo.
>
> ///////////////////
>
> In file included from
> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_ios.h:39:0,
>                  from
> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/ios:45,
>                  from
> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/istream:40,
>                  from
> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:39,
>                  from
> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/complex:47,
>                  from
> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdc++.h:67,
>                  from
> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdtr1c++.h:29,
>                  from
> /scratch/Gcc/svn-dirs/trunk/libstdc++-v3/include/precompiled/extc++.h:30:
> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:
> In member function 'virtual std::ctype<char>::char_type
> std::ctype<char>::do_widen(char) const':
> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:1077:7:
> internal compiler error: Segmentation fault
>        do_widen(char __c) const
>        ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
>
Dehao Chen Sept. 20, 2012, 8:17 p.m. UTC | #9 
Sorry for breaking these tests.

This problem is very hard to reproduce. However, I had a patch to fix
another compile-time problem which may be related to this one.
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01491.html

After applying the patch, the PCH related bugs are not showing any
more on my machines.

Dehao

On Thu, Sep 20, 2012 at 10:59 PM, Dehao Chen <dehao@google.com> wrote:
> Hi, Paolo,
>
> I'll look into the ICE problems now.
>
> Thanks,
> Dehao
>
> On Thu, Sep 20, 2012 at 9:04 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
>> Hi,
>>
>>
>> On 09/19/2012 09:59 PM, Dehao Chen wrote:
>>>
>>> This patch was commited as r191494.
>>
>> I'm afraid I can't help *much* with the debugging, but on my x86_64-linux
>> machine and a very straightforward configuration (--enable-languages=c++
>> --disable-multilib) after r191494 I'm seeing the following libstdc++
>> regressions.
>>
>> FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors)
>> FAIL: 17_intro/headers/c++1998/all_c++200x_compatibility.cc (test for excess
>> errors)
>> FAIL: 17_intro/headers/c++1998/all_pedantic_errors.cc (test for excess
>> errors)
>> FAIL: 17_intro/headers/c++1998/stdc++.cc (test for excess errors)
>> FAIL: 17_intro/headers/c++1998/stdc++_multiple_inclusion.cc (test for excess
>> errors)
>> FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
>> FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for excess
>> errors)
>>
>> are all ICEs like the below. Apparently PCHs are required, I can't reproduce
>> outside the testsuite, without the library PCHs.
>>
>> Does it make any sense to you? Please let me know if I can somehow help.
>>
>> Thanks,
>> Paolo.
>>
>> ///////////////////
>>
>> In file included from
>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_ios.h:39:0,
>>                  from
>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/ios:45,
>>                  from
>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/istream:40,
>>                  from
>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:39,
>>                  from
>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/complex:47,
>>                  from
>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdc++.h:67,
>>                  from
>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdtr1c++.h:29,
>>                  from
>> /scratch/Gcc/svn-dirs/trunk/libstdc++-v3/include/precompiled/extc++.h:30:
>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:
>> In member function 'virtual std::ctype<char>::char_type
>> std::ctype<char>::do_widen(char) const':
>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:1077:7:
>> internal compiler error: Segmentation fault
>>        do_widen(char __c) const
>>        ^
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <http://gcc.gnu.org/bugs.html> for instructions.
>>
>>
Dehao Chen Sept. 20, 2012, 9:51 p.m. UTC | #10 
The PCH related failures are caused by this patch. The patch I posted
earlier http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01491.html solved
another problem, but not this one.

The issue here is: when reading PCH data, the line_table is also read
from PCH files. But the location_adhoc_data_map is not managed by GC,
thus is not read in from PCH file (only a pointer is read in).

To solve this problem, we'll need to move location_adhoc_data_map into
GC. I'll have another patch to solve this problem.

However, I still do not quite understand how muliple line_tables can
co-exist. E.g. foo() is from a.H, bar() is from b.H. When bar() is
inlined into foo(), both line_tables (a.H and b.H) should be used. But
I didn't find in GCC how this is handled...

Dehao

On Fri, Sep 21, 2012 at 4:17 AM, Dehao Chen <dehao@google.com> wrote:
> Sorry for breaking these tests.
>
> This problem is very hard to reproduce. However, I had a patch to fix
> another compile-time problem which may be related to this one.
> http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01491.html
>
> After applying the patch, the PCH related bugs are not showing any
> more on my machines.
>
> Dehao
>
> On Thu, Sep 20, 2012 at 10:59 PM, Dehao Chen <dehao@google.com> wrote:
>> Hi, Paolo,
>>
>> I'll look into the ICE problems now.
>>
>> Thanks,
>> Dehao
>>
>> On Thu, Sep 20, 2012 at 9:04 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
>>> Hi,
>>>
>>>
>>> On 09/19/2012 09:59 PM, Dehao Chen wrote:
>>>>
>>>> This patch was commited as r191494.
>>>
>>> I'm afraid I can't help *much* with the debugging, but on my x86_64-linux
>>> machine and a very straightforward configuration (--enable-languages=c++
>>> --disable-multilib) after r191494 I'm seeing the following libstdc++
>>> regressions.
>>>
>>> FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors)
>>> FAIL: 17_intro/headers/c++1998/all_c++200x_compatibility.cc (test for excess
>>> errors)
>>> FAIL: 17_intro/headers/c++1998/all_pedantic_errors.cc (test for excess
>>> errors)
>>> FAIL: 17_intro/headers/c++1998/stdc++.cc (test for excess errors)
>>> FAIL: 17_intro/headers/c++1998/stdc++_multiple_inclusion.cc (test for excess
>>> errors)
>>> FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
>>> FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for excess
>>> errors)
>>>
>>> are all ICEs like the below. Apparently PCHs are required, I can't reproduce
>>> outside the testsuite, without the library PCHs.
>>>
>>> Does it make any sense to you? Please let me know if I can somehow help.
>>>
>>> Thanks,
>>> Paolo.
>>>
>>> ///////////////////
>>>
>>> In file included from
>>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_ios.h:39:0,
>>>                  from
>>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/ios:45,
>>>                  from
>>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/istream:40,
>>>                  from
>>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:39,
>>>                  from
>>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/complex:47,
>>>                  from
>>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdc++.h:67,
>>>                  from
>>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdtr1c++.h:29,
>>>                  from
>>> /scratch/Gcc/svn-dirs/trunk/libstdc++-v3/include/precompiled/extc++.h:30:
>>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:
>>> In member function 'virtual std::ctype<char>::char_type
>>> std::ctype<char>::do_widen(char) const':
>>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:1077:7:
>>> internal compiler error: Segmentation fault
>>>        do_widen(char __c) const
>>>        ^
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> See <http://gcc.gnu.org/bugs.html> for instructions.
>>>
>>>
Dehao Chen Sept. 21, 2012, 2:51 a.m. UTC | #11 
Hi,

As expected, since this patch was checked in yesterday, there are 4
bugs exposed (1 fixed, 1 patch ready, 2 TBD):

1. http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01413.html
Failed targets such as arm and mips. Fixed by r191510

2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54649
Failed Go bootstrap (I didn't test --enable-language=go). The problem
is when we set the line number for stmts in the finally block
(tree-eh.c), we don't want to change its block info.
A fix was proposed: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01513.html

3. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645
All PCH related tests fail intermittently. (They didn't manifest when
I was doing the test...)
The cause of the problem is: when reading PCH data, the line_table is
also read from PCH files. But the location_adhoc_data_map is not
managed by GC, thus is not read in from PCH file (only a pointer is
read in).
I'll try to provide a patch to resolve the problem by the end of Friday.

4. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54650
Failed one regression test in libgomp (I didn't know that there are
regression tests for libraries before...)
This error should be a bug exposed by this patch. I'll try to provide
a patch as soon as possible.

Thanks,
Dehao
Michael Matz Sept. 21, 2012, 12:59 p.m. UTC | #12 
Hi,

On Thu, 20 Sep 2012, Dehao Chen wrote:

> 4. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54650 Failed one 
> regression test in libgomp (I didn't know that there are regression 
> tests for libraries before...) This error should be a bug exposed by 
> this patch. I'll try to provide a patch as soon as possible.

Always do a 'make check' from the toplevel build directory.  For looking 
at the results you may find contrib/test_summary afterwards useful.  
Compare it's output from a run with and without patch.  All new FAILs will 
have to be investigated, and with the above procedure you won't miss any.


Ciao,
Michael.
Markus Trippelsdorf Sept. 21, 2012, 1:44 p.m. UTC | #13 
On 2012.09.20 at 19:51 -0700, Dehao Chen wrote:
> As expected, since this patch was checked in yesterday, there are 4
> bugs exposed (1 fixed, 1 patch ready, 2 TBD):

It also causes: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54655
diff mbox

Patch

Index: src/gcc/ipa-prop.c
===================================================================
--- src.orig/gcc/ipa-prop.c
+++ src/gcc/ipa-prop.c
@@ -287,6 +287,19 @@  ipa_print_all_jump_functions (FILE *f)
     }
 }
 
+/* Return the expression tree EXPR unshared and with location stripped off.  */
+
+static tree
+prune_expression_for_jf (tree exp)
+{
+  if (EXPR_P (exp))
+    {
+      exp = unshare_expr (exp);
+      SET_EXPR_LOCATION (exp, UNKNOWN_LOCATION);
+    }
+  return exp;
+}
+
 /* Set JFUNC to be a known type jump function.  */
 
 static void
@@ -305,7 +318,7 @@  static void
 ipa_set_jf_constant (struct ipa_jump_func *jfunc, tree constant)
 {
   jfunc->type = IPA_JF_CONST;
-  jfunc->value.constant = constant;
+  jfunc->value.constant = prune_expression_for_jf (constant);
 }
 
 /* Set JFUNC to be a simple pass-through jump function.  */
@@ -327,7 +340,7 @@  ipa_set_jf_arith_pass_through (struct ip
 			       tree operand, enum tree_code operation)
 {
   jfunc->type = IPA_JF_PASS_THROUGH;
-  jfunc->value.pass_through.operand = operand;
+  jfunc->value.pass_through.operand = prune_expression_for_jf (operand);
   jfunc->value.pass_through.formal_id = formal_id;
   jfunc->value.pass_through.operation = operation;
   jfunc->value.pass_through.agg_preserved = false;
@@ -1344,7 +1357,7 @@  determine_known_aggregate_parts (gimple
 	    {
 	      struct ipa_agg_jf_item item;
 	      item.offset = list->offset - arg_offset;
-	      item.value = list->constant;
+	      item.value = prune_expression_for_jf (list->constant);
 	      VEC_quick_push (ipa_agg_jf_item_t, jfunc->agg.items, item);
 	    }
 	  list = list->next;