[Bug debug/39355] New: [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[Bug debug/39355] New: [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[danglin at gcc dot gnu dot org]

Executing on host: /home/dave/gnu/gcc-4.4/objdir/./gcc/g++ -shared-libgcc
-B/hom
e/dave/gnu/gcc-4.4/objdir/./gcc -nostdinc++
-L/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libstdc++-v3/src
-L/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libstdc++-v3/
src/.libs -B/home/dave/opt/gnu/gcc/gcc-4.4.0/hppa-linux/bin/
-B/home/dave/opt/gn
u/gcc/gcc-4.4.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.4.0/hppa-l
inux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.4.0/hppa-linux/sys-include
-g
 -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections
-g
 -O2 -D_GNU_SOURCE -g -O2   -D_GNU_SOURCE   -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libstdc++-v3/include/hppa-linux
-I/home/dave/
gnu/gcc-4.4/objdir/hppa-linux/libstdc++-v3/include
-I/home/dave/gnu/gcc-4.4/gcc/
libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc-4.4/gcc/libstdc++-v3/include/backwar
d -I/home/dave/gnu/gcc-4.4/gcc/libstdc++-v3/testsuite/util -Wl,--gc-sections
/home/dave/gnu/gcc-4.4/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc 
  -include bits/stdc++.h ./libtestc++.a  -lm   -o ./13450.exe    (timeout =
600)/home/dave/gnu/gcc-4.4/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc:
In function 'std::complex<_Tp> std::pow(const _Tp&, const std::complex<_Tp>&)
[with _Tp =
double]':/home/dave/gnu/gcc-4.4/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc:37:
internal compiler error: Segmentation fault

Analyzing compilation unit
Performing interprocedural optimizations
 <visibility> <early_local_cleanups>
Program received signal SIGSEGV, Segmentation fault.
loc_descriptor_from_tree_1 (loc=0x0, want_address=2)
    at ../../gcc/gcc/dwarf2out.c:10353
10353     switch (TREE_CODE (loc))
(gdb) bt
#0  loc_descriptor_from_tree_1 (loc=0x0, want_address=2)
    at ../../gcc/gcc/dwarf2out.c:10353
#1  0x00291d8c in loc_descriptor_from_tree_1 (loc=0x6082ab00, want_address=2)
    at ../../gcc/gcc/dwarf2out.c:10438
#2  0x00298c2c in add_location_or_const_value_attribute (die=0x40443c90, 
    decl=0x6082ab00, attr=<value optimized out>)
    at ../../gcc/gcc/dwarf2out.c:10789
#3  0x0029d70c in gen_formal_parameter_die (node=0x0, origin=0x40408150, 
    context_die=0x40443c00) at ../../gcc/gcc/dwarf2out.c:13328
#4  0x0029a340 in gen_decl_die (decl=0x0, origin=0x6082ab00, 
    context_die=0x40443c00) at ../../gcc/gcc/dwarf2out.c:15378
#5  0x0029fe84 in decls_for_scope (stmt=0x40448d58, context_die=0x40443c00, 
    depth=3) at ../../gcc/gcc/dwarf2out.c:14986
#6  0x002a1ff8 in gen_lexical_block_die (stmt=0x40448d58, 
    context_die=<value optimized out>, depth=3)
    at ../../gcc/gcc/dwarf2out.c:14225
#7  0x002a25d4 in gen_block_die (stmt=0x40448d58, context_die=0x40443cf0, 
    depth=3) at ../../gcc/gcc/dwarf2out.c:14930
#8  0x0029fec4 in decls_for_scope (stmt=0x40448d20, context_die=0x40443cf0, 
    depth=<value optimized out>) at ../../gcc/gcc/dwarf2out.c:14998
#9  0x002a23d0 in gen_block_die (stmt=0x40448d20, context_die=0x40443cf0, 
    depth=2) at ../../gcc/gcc/dwarf2out.c:14933
#10 0x0029fec4 in decls_for_scope (stmt=0x40448ce8, context_die=0x40443cf0, 
---Type <return> to continue, or q <return> to quit---
    depth=<value optimized out>) at ../../gcc/gcc/dwarf2out.c:14998
#11 0x002a1ff8 in gen_lexical_block_die (stmt=0x40448ce8, 
    context_die=<value optimized out>, depth=1)
    at ../../gcc/gcc/dwarf2out.c:14225
#12 0x002a25d4 in gen_block_die (stmt=0x40448ce8, context_die=0x40443b70, 
    depth=1) at ../../gcc/gcc/dwarf2out.c:14930
#13 0x0029fec4 in decls_for_scope (stmt=0x403416c8, context_die=0x40443b70, 
    depth=<value optimized out>) at ../../gcc/gcc/dwarf2out.c:14998
#14 0x002a02c0 in gen_subprogram_die (decl=0x4036cd00, context_die=0x22)
    at ../../gcc/gcc/dwarf2out.c:13838
#15 0x0029a47c in gen_decl_die (decl=0x4036cd00, origin=0x0, 
    context_die=0x602efe80) at ../../gcc/gcc/dwarf2out.c:15292
#16 0x0029a020 in dwarf2out_abstract_function (decl=0x4036cd00)
    at ../../gcc/gcc/dwarf2out.c:13489
#17 0x001d7f34 in expand_call_inline (bb=0x40447940, stmt=0x403ae370, 
    id=0xfb66c130) at ../../gcc/gcc/tree-inline.c:3448
#18 0x001d919c in optimize_inline_calls (fn=0x4036ef00)
    at ../../gcc/gcc/tree-inline.c:3477
#19 0x0068a040 in cgraph_early_inlining () at ../../gcc/gcc/ipa-inline.c:1530
#20 0x00413664 in execute_one_pass (pass=0x996528)
    at ../../gcc/gcc/passes.c:1277
#21 0x004138f8 in execute_pass_list (pass=0x996528)
    at ../../gcc/gcc/passes.c:1326
---Type <return> to continue, or q <return> to quit---
#22 0x0041390c in execute_pass_list (pass=0x91f5d4)
    at ../../gcc/gcc/passes.c:1327
#23 0x00413cc0 in execute_ipa_pass_list (pass=0x91f5a0)
    at ../../gcc/gcc/passes.c:890
#24 0x0068406c in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1239
#25 0x000cf248 in cp_write_global_declarations ()
    at ../../gcc/gcc/cp/decl2.c:3645
#26 0x004cbc40 in toplev_main (argc=<value optimized out>, 
    argv=<value optimized out>) at ../../gcc/gcc/toplev.c:981
#27 0x406495a4 in __libc_start_main () from /lib/libc.so.6
#28 0x00020ff8 in _start ()
(gdb) p/x $pc
$1 = 0x29100c
(gdb) disass 0x291000 0x29101c
Dump of assembler code from 0x291000 to 0x29101c:
0x00291000 <loc_descriptor_from_tree_1+32>:     stw r7,-54(sp)
0x00291004 <loc_descriptor_from_tree_1+36>:     stw r6,-50(sp)
0x00291008 <loc_descriptor_from_tree_1+40>:     stw r5,-4c(sp)
0x0029100c <loc_descriptor_from_tree_1+44>:     ldh 0(r26),r9
...
(gdb) p/x $r26
$3 = 0x0

dave@hiauly6:~/gnu/gcc-4.4/objdir/gcc$ ./xgcc -B./ -v
Reading specs from ./specs
Target: hppa-linux
Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared
--prefix=/home/dave/opt/gnu/gcc/gcc-4.4.0
--with-local-prefix=/home/dave/opt/gnu --enable-threads=posix
--enable-__cxa_atexit --build=hppa-linux --enable-clocale=gnu
--enable-java-gc=boehm --enable-java-awt=xlib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
Thread model: posix
gcc version 4.4.0 20090301 (experimental) [trunk revision 144533] (GCC)


-- 
           Summary: [4.4 Regression] ICE at dwarf2out.c:10353 in
                    loc_descriptor_from_tree_1
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-03 02:09 -------
Subject: Re:   New: [4.4 Regression] ICE at
        dwarf2out.c:10353 in loc_descriptor_from_tree_1

Attached preprocessed source.

Dave


------- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-03 02:09 -------
Created an attachment (id=17391)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17391&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2009-03-03 13:04 -------
Honza, I'm sure this is yours.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu dot
                   |                            |org
            Summary|[4.4 Regression] ICE at     |[4.4 Regression] ICE at
                   |dwarf2out.c:10353 in        |dwarf2out.c:10353 in
                   |loc_descriptor_from_tree_1  |loc_descriptor_from_tree_1
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2009-03-04 12:13 -------
Dave, did this ICE by chance disappear with the fix for PR39345?  At least
the testcase works for me on i?86-linux now.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
           Priority|P3                          |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-04 17:26 -------
Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1

> Dave, did this ICE by chance disappear with the fix for PR39345?  At least
> the testcase works for me on i?86-linux now.

This is still failing for me at revision 144591.  The fix for PR39345
was applied at revision 144581.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2009-03-04 19:13 -------
I can't reproduce this with x86_64-linux -> hppa-linux cross on the current
trunk.
Can you reproduce it with the provided preprocessed source?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-04 20:46 -------
Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1

> ------- Comment #6 from jakub at gcc dot gnu dot org  2009-03-04 19:13 -------
> I can't reproduce this with x86_64-linux -> hppa-linux cross on the current
> trunk.
> Can you reproduce it with the provided preprocessed source?

I did some more testing and I can't reproduce it with the preprocessed
source.  The problem only occurs when I compile directly with 13450.cc.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[jakub at gcc dot gnu dot org]

------- Comment #8 from jakub at gcc dot gnu dot org  2009-03-05 08:07 -------
Can you reproduce it with stage1 cc1plus (or non-bootstrapped cc1plus) built by
some older gcc, or only with stage2/stage3 cc1plus?  Wonder if cc1plus hasn't
been miscompiled.  In any case, as this can't be reproduced with a
cross-compiler, somebody with hppa-linux access needs to debug it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[hubicka at ucw dot cz]

------- Comment #9 from hubicka at ucw dot cz  2009-03-05 11:18 -------
Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1

> ------- Comment #8 from jakub at gcc dot gnu dot org  2009-03-05 08:07 -------
> Can you reproduce it with stage1 cc1plus (or non-bootstrapped cc1plus) built by
> some older gcc, or only with stage2/stage3 cc1plus?  Wonder if cc1plus hasn't
> been miscompiled.  In any case, as this can't be reproduced with a
> cross-compiler, somebody with hppa-linux access needs to debug it.

I've just run across interesting memory corruption in Ada: by
duplicating DECL node for nested function we ended up with pointer to
ggc_freeded DECL_STRUCT_FUNCTION.  I have patch to always make functions
nonlocal that might solve this problem as well (as we get methods for
C++ local classes).  I am just on the way to Prague, but I will break it
up from my tree then.

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-07 16:52 -------
Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1

> Can you reproduce it with stage1 cc1plus (or non-bootstrapped cc1plus) built by
> some older gcc, or only with stage2/stage3 cc1plus?  Wonder if cc1plus hasn't
> been miscompiled.  In any case, as this can't be reproduced with a
> cross-compiler, somebody with hppa-linux access needs to debug it.

I can't reproduce it with stage1 cc1plus, only with stage2/stage3 cc1plus.

The bug appeared after the following change:

2009-03-01  Jan Hubicka  <jh@suse.cz>

        PR debug/39267
        * tree.h (BLOCK_NONLOCALIZED_VARS, BLOCK_NUM_NONLOCALIZED_VARS,

Looking at dwarf2out.c, I see:

    case PARM_DECL:
      if (DECL_HAS_VALUE_EXPR_P (loc))
        return loc_descriptor_from_tree_1 (DECL_VALUE_EXPR (loc),
                                           want_address);

(gdb) p loc->decl_common.decl_flag_3
$11 = 1

but

DECL_VALUE_EXPR (loc) returns NULL_TREE.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[hjl dot tools at gmail dot com]

------- Comment #11 from hjl dot tools at gmail dot com  2009-03-08 17:40 -------
(In reply to comment #10)
> Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
> loc_descriptor_from_tree_1
> 
> > Can you reproduce it with stage1 cc1plus (or non-bootstrapped cc1plus) built by
> > some older gcc, or only with stage2/stage3 cc1plus?  Wonder if cc1plus hasn't
> > been miscompiled.  In any case, as this can't be reproduced with a
> > cross-compiler, somebody with hppa-linux access needs to debug it.
> 
> I can't reproduce it with stage1 cc1plus, only with stage2/stage3 cc1plus.
> 
> The bug appeared after the following change:
> 
> 2009-03-01  Jan Hubicka  <jh@suse.cz>
> 
>         PR debug/39267
>         * tree.h (BLOCK_NONLOCALIZED_VARS, BLOCK_NUM_NONLOCALIZED_VARS,
> 

It seems that stage2 cc1plus is miscompiled on hppa. I suggest you replace
.o files from stage1 and relink stage2 cc1plus to find out which files
are miscompiled by stage1 cc1. You may be to extract a small testcase to
show miscompilation.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-10 01:47 -------
Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1

> ------- Comment #11 from hjl dot tools at gmail dot com  2009-03-08 17:40 -------

> It seems that stage2 cc1plus is miscompiled on hppa. I suggest you replace
> .o files from stage1 and relink stage2 cc1plus to find out which files
> are miscompiled by stage1 cc1. You may be to extract a small testcase to
> show miscompilation.

The ICE doesn't occur if I replace parser.o.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[hjl dot tools at gmail dot com]

------- Comment #13 from hjl dot tools at gmail dot com  2009-03-10 03:52 -------
(In reply to comment #12)
> Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
> loc_descriptor_from_tree_1
> 
> > ------- Comment #11 from hjl dot tools at gmail dot com  2009-03-08 17:40 -------
> 
> > It seems that stage2 cc1plus is miscompiled on hppa. I suggest you replace
> > .o files from stage1 and relink stage2 cc1plus to find out which files
> > are miscompiled by stage1 cc1. You may be to extract a small testcase to
> > show miscompilation.
> 
> The ICE doesn't occur if I replace parser.o.
> 

Can you find out which function is miscompiled?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[steven at gcc dot gnu dot org]

------- Comment #14 from steven at gcc dot gnu dot org  2009-03-10 06:32 -------
ISTR Richi has scripts to automatically identify file+function that is
miscompiled...?


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[jakub at gcc dot gnu dot org]

------- Comment #15 from jakub at gcc dot gnu dot org  2009-03-10 08:05 -------
You can start with trying if -O2 -fno-inline -fno-inline-small-functions is
still miscompiled and if -O0 works, then you can add
__attribute__((__optimized__([02]))) to suspected functions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[hjl dot tools at gmail dot com]

------- Comment #16 from hjl dot tools at gmail dot com  2009-03-14 15:01 -------
There is

pa/pa.h:#define SHIFT_COUNT_TRUNCATED 1

PR 39454 is a SHIFT_COUNT_TRUNCATED bug, which is fixed by revision 144857.
Does revision 144857 fix this bug?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-14 15:51 -------
Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1

> There is
> 
> pa/pa.h:#define SHIFT_COUNT_TRUNCATED 1
> 
> PR 39454 is a SHIFT_COUNT_TRUNCATED bug, which is fixed by revision 144857.
> Does revision 144857 fix this bug?

It's a possibility.  I've started some builds.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-14 16:15 -------
Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1

> The ICE doesn't occur if I replace parser.o.

I messed up in testing the above.  The problem is actually in libcpp/expr.o.
The ICE doesn't occur with stage1-libcpp.  It also doesn't occur if I replace
libcpp/expr.o with the stage1 version.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-14 21:31 -------
Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
        loc_descriptor_from_tree_1

On Tue, 10 Mar 2009, jakub at gcc dot gnu dot org wrote:

> You can start with trying if -O2 -fno-inline -fno-inline-small-functions is
> still miscompiled and if -O0 works, then you can add
> __attribute__((__optimized__([02]))) to suspected functions.

-O2 -fno-inline -fno-inline-small-functions and -O0 both work.  However,
I couldn't get the attribute to work, or find any documentation for it.

I did find that the ICE doesn't occur with the following change to
libcpp/expr.c:

Index: expr.c
===================================================================
--- expr.c      (revision 144529)
+++ expr.c      (working copy)
@@ -39,7 +39,7 @@
 /* Some simple utility routines on double integers.  */
 #define num_zerop(num) ((num.low | num.high) == 0)
 #define num_eq(num1, num2) (num1.low == num2.low && num1.high == num2.high)
-static bool num_positive (cpp_num, size_t);
+static bool num_positive (cpp_num, size_t) __attribute__((noinline));
 static bool num_greater_eq (cpp_num, cpp_num, size_t);
 static cpp_num num_trim (cpp_num, size_t);
 static cpp_num num_part_mul (cpp_num_part, cpp_num_part);

So, it seems quite likely that this is a shift issue.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-15 02:22 -------
Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1

> ------- Comment #16 from hjl dot tools at gmail dot com  2009-03-14 15:01 -------
> There is
> 
> pa/pa.h:#define SHIFT_COUNT_TRUNCATED 1
> 
> PR 39454 is a SHIFT_COUNT_TRUNCATED bug, which is fixed by revision 144857.
> Does revision 144857 fix this bug?

No.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[hjl dot tools at gmail dot com]

------- Comment #21 from hjl dot tools at gmail dot com  2009-03-15 17:37 -------
(In reply to comment #19)

> I did find that the ICE doesn't occur with the following change to
> libcpp/expr.c:
> 
> Index: expr.c
> ===================================================================
> --- expr.c      (revision 144529)
> +++ expr.c      (working copy)
> @@ -39,7 +39,7 @@
>  /* Some simple utility routines on double integers.  */
>  #define num_zerop(num) ((num.low | num.high) == 0)
>  #define num_eq(num1, num2) (num1.low == num2.low && num1.high == num2.high)
> -static bool num_positive (cpp_num, size_t);
> +static bool num_positive (cpp_num, size_t) __attribute__((noinline));
>  static bool num_greater_eq (cpp_num, cpp_num, size_t);
>  static cpp_num num_trim (cpp_num, size_t);
>  static cpp_num num_part_mul (cpp_num_part, cpp_num_part);
> 

Since revision 144529:

http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00000.html

is the cause and it is inline related, I suggest you use revision
144529 as base and revert the tree-inline.c change to see if it fixes
libcpp/expr.c.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.4 Regression] ICE at     |[4.4 Regression] Revision
                   |dwarf2out.c:10353 in        |144529 miscompiled
                   |loc_descriptor_from_tree_1  |libcpp/expr.c


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #22 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-15 18:07 -------
Subject: Re:  [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

> Since revision 144529:
> 
> http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00000.html
> 
> is the cause and it is inline related, I suggest you use revision
> 144529 as base and revert the tree-inline.c change to see if it fixes
> libcpp/expr.c.

I'll give it a try.  I was hoping to to pin down what's being miscompiled
but it is proving difficult.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[hjl dot tools at gmail dot com]

------- Comment #23 from hjl dot tools at gmail dot com  2009-03-15 18:47 -------
(In reply to comment #22)
> Subject: Re:  [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
> 
> > Since revision 144529:
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00000.html
> > 
> > is the cause and it is inline related, I suggest you use revision
> > 144529 as base and revert the tree-inline.c change to see if it fixes
> > libcpp/expr.c.
> 
> I'll give it a try.  I was hoping to to pin down what's being miscompiled
> but it is proving difficult.
> 

If the tree-inline.c change is the cause, I would check each call
to can_be_nonlocal to find out which one caused this regression.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |39345


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[rguenth at gcc dot gnu dot org]

------- Comment #24 from rguenth at gcc dot gnu dot org  2009-03-15 19:51 -------
Well, that change cannot possibly cause a miscompilation.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[jakub at gcc dot gnu dot org]

------- Comment #25 from jakub at gcc dot gnu dot org  2009-03-16 07:52 -------
I'd say first try to add noinline attribute on all callers of num_positive, if
it fails even with those, add also __attribute__((__optimize__(0))) to them one
by one.  If the noinline attribute to those makes the miscompilation go away,
search one by one which one it is and retry with all callers of that function.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #26 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-16 17:20 -------
Subject: Re:  [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

> Since revision 144529:
> 
> http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00000.html
> 
> is the cause and it is inline related, I suggest you use revision
> 144529 as base and revert the tree-inline.c change to see if it fixes
> libcpp/expr.c.

The regressions don't occur with revision 144874 if I replace
tree-inline.c with the version from revision 144528.

http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg01655.html

144529 significantly changed the amount of inlining.  Thus, it's
very difficult to determine the location of the miscompilation in
expr.o by comparing the difference in code between 144528 and 144529.
It's also my impression that the miscompilation has moved in subsequent
revisions.

The miscompilation is related to the generation of dwarf2 debug
information as it doesn't appear with hpux.

While it may be that the changes to tree-inline.c are not directly
responsilble for the regressions, they are definitely a contributing
factor.  I note that Jan does have an account on a hppa linux machine,
gsyprf11.external.hp.com.

Probably, I should rebuild 144529 and try Jakub's suggestions.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[hjl dot tools at gmail dot com]

------- Comment #27 from hjl dot tools at gmail dot com  2009-03-16 17:26 -------
(In reply to comment #26)
> 
> Probably, I should rebuild 144529 and try Jakub's suggestions.

You need the fix for PR 39345 on top of revision 144529.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[jakub at gcc dot gnu dot org]

------- Comment #28 from jakub at gcc dot gnu dot org  2009-03-17 10:42 -------
Better just do that with the latest trunk.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-20 01:30 -------
Subject: Re:  [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

> I'd say first try to add noinline attribute on all callers of num_positive, if
> it fails even with those, add also __attribute__((__optimize__(0))) to them one
> by one.  If the noinline attribute to those makes the miscompilation go away,
> search one by one which one it is and retry with all callers of that function.

With todays, head, it seems the miscompilation is related to the inlining
of check_promotion.  Adding noinline attribute makes the ICE go away.
Adding __attribute__((__optimize__(0))) or __attribute__((__optimize__(1)))
also makes the ICE go away.  Removing either half of the
"if (op->value.unsignedp)" also makes the ICE go away.  However, I haven't
been able to spot the actual miscompilation yet.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-20 13:17 -------
Subject: Re:  [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

> With todays, head, it seems the miscompilation is related to the inlining
> of check_promotion.  Adding noinline attribute makes the ICE go away.
> Adding __attribute__((__optimize__(0))) or __attribute__((__optimize__(1)))
> also makes the ICE go away.  Removing either half of the
> "if (op->value.unsignedp)" also makes the ICE go away.  However, I haven't
> been able to spot the actual miscompilation yet.

Just want to add that the bug is not in the code inlined by the call
to check_promotion.  It's not entered in the testcase.  The inlining
changes the register allocation and some of the optimizations applied
to _cpp_parse_expr.

A small change can make the ICE disappear.  For example, the ICE
doesn't appear with:

Index: expr.c
===================================================================
--- expr.c      (revision 144962)
+++ expr.c      (working copy)
@@ -1023,8 +1023,10 @@
   prio = optab[op].prio - ((optab[op].flags & LEFT_ASSOC) != 0);
   while (prio < optab[top->op].prio)
     {
+#if 1
       if (CPP_OPTION (pfile, warn_num_sign_change)
          && optab[top->op].flags & CHECK_PROMOTION)
+#endif
        check_promotion (pfile, top);

       switch (top->op)

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[jason at gcc dot gnu dot org]

------- Comment #31 from jason at gcc dot gnu dot org  2009-03-20 17:22 -------
Changing component to tree-optimization.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|debug                       |tree-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[rguenth at gcc dot gnu dot org]

------- Comment #32 from rguenth at gcc dot gnu dot org  2009-03-20 17:29 -------
Did you really mean that inserting the #if 1 disables the ICE or did you mean
to insert #if 0?  Is the preprocessor output different for the ICEing testcase?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[hjl dot tools at gmail dot com]

------- Comment #33 from hjl dot tools at gmail dot com  2009-03-20 18:04 -------
Please provide preprocessed libcpp/expr.c which is miscompiled as
well as the command line used to miscompile it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #34 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-20 19:07 -------
Subject: Re:  [4.4 Regression] Revision 144529
        miscompiled libcpp/expr.c

> Did you really mean that inserting the #if 1 disables the ICE or did you mean
> to insert #if 0?  Is the preprocessor output different for the ICEing testcase?

Sorry, #if 0 disables the ICE.  #if 1 enables ICE.  There is no difference
in the preprocessor output for the ICEing testcase.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #35 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-20 19:09 -------
Subject: Re:  [4.4 Regression] Revision 144529
        miscompiled libcpp/expr.c

> Please provide preprocessed libcpp/expr.c which is miscompiled as
> well as the command line used to miscompile it.

Attached.  Command line is:

/home/dave/gnu/gcc-4.4/objdir/./prev-gcc/xgcc
-B/home/dave/gnu/gcc-4.4/objdir/./prev-gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.4.0/hppa-linux/bin/  -I../../gcc/libcpp -I.
-I../../gcc/libcpp/../include -I../../gcc/libcpp/include  -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -pedantic -Wno-long-long -Werror -I../../gcc/libcpp
-I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include  -c -o expr.o -MT
expr.o -MMD -MP -MF .deps/expr.Tpo ../../gcc/libcpp/expr.c

Dave


------- Comment #36 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-20 19:10 -------
Created an attachment (id=17503)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17503&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[danglin at gcc dot gnu dot org]

------- Comment #37 from danglin at gcc dot gnu dot org  2009-03-21 00:53 -------
Looking at the ICE some more, I see that the backtrace shown in the original
report involves the code added by Honza in revision 144529.  The loc value
in frame 1 appears a somewhat wierd.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[hjl dot tools at gmail dot com]

------- Comment #38 from hjl dot tools at gmail dot com  2009-03-21 16:13 -------
(In reply to comment #37)
> Looking at the ICE some more, I see that the backtrace shown in the original
> report involves the code added by Honza in revision 144529.  The loc value
> in frame 1 appears a somewhat wierd.
> 

I think you should try to find out which part of revision 144529 triggers
this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #39 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-21 17:24 -------
Subject: Re:  [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

> ------- Comment #38 from hjl dot tools at gmail dot com  2009-03-21 16:13 -------
> (In reply to comment #37)
> > Looking at the ICE some more, I see that the backtrace shown in the original
> > report involves the code added by Honza in revision 144529.  The loc value
> > in frame 1 appears a somewhat wierd.
> > 
> 
> I think you should try to find out which part of revision 144529 triggers
> this.

One thing that I know is decl_value_expr_insert is not called at all
in the testcase.  So, DECL_HAS_VALUE_EXPR_P (loc) being true is completely
bogus.  The value of loc arises from this call added in revision 144529.

Breakpoint 2, decls_for_scope (stmt=0x40223dc8, context_die=0x401dbf90, 
    depth=3) at ../../gcc/gcc/dwarf2out.c:14919
14919       process_scope_var (stmt, NULL, BLOCK_NONLOCALIZED_VAR (stmt, i),

(gdb) p *(struct tree_block *)stmt
$18 = {common = {base = {code = BLOCK, side_effects_flag = 0, 
      constant_flag = 0, addressable_flag = 0, volatile_flag = 0, 
      readonly_flag = 0, unsigned_flag = 0, asm_written_flag = 0, 
      nowarning_flag = 0, used_flag = 0, nothrow_flag = 0, static_flag = 0, 
      public_flag = 0, private_flag = 0, protected_flag = 0, 
      deprecated_flag = 0, saturating_flag = 0, default_def_flag = 0, 
      lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, 
      lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, 
      spare = 0, ann = 0x0}, chain = 0x0, type = 0x0}, abstract_flag = 1, 
  block_num = 182, locus = 9123098, vars = 0x0, 
  nonlocalized_vars = 0x40224d80, subblocks = 0x40223e00, 
  supercontext = 0x40223d20, abstract_origin = 0x40223348, 
  fragment_origin = 0x0, fragment_chain = 0x0}

The VEC is:

(gdb) x/8x 0x40224d80
0x40224d80:     0x00000002      0x00000004      0x60809ee0      0x60809e90
0x40224d90:     0xafafafaf      0xafafafaf      0xafafafaf      0xafafafaf

The tree stmt is created in remap_block.  At this point, I think the
problem is in remap_decls since before the call we have

(gdb) x/8x 0x40224d80
0x40224d80:     0x00000000      0x00000000      0x00000000      0x00000000
0x40224d90:     0x00000000      0x00000000      0x00000000      0x00000000

and after the call we have

(gdb) x/8x 0x40224d80
0x40224d80:     0x00000002      0x00000004      0x60809ee0      0x60809e90
0x40224d90:     0xafafafaf      0xafafafaf      0xafafafaf      0xafafafaf

(gdb) p debug_tree (0x60809ee0)
 <parm_decl 0x60809ee0 __y
    type <complex_type 0x604cab28 complex double
        type <real_type 0x604ca578 double sizes-gimplified asm_written type_6
DF
            size <integer_cst 0x60c0e900 constant 64>
            unit size <integer_cst 0x60c0e940 constant 8>
            align 64 symtab 1614619136 alias set 22 canonical type 0x604ca578
precision 64
            pointer_to_this <pointer_type 0x604ca6b0> reference_to_this
<reference_type 0x607156c8>>
        sizes-gimplified asm_written type_6 DC
        size <integer_cst 0x60cc44a0 constant 128>
        unit size <integer_cst 0x60c0eb00 constant 16>
        align 64 symtab 1614710336 alias set 24 canonical type 0x604cab28
        pointer_to_this <pointer_type 0x604e3260>>
        used DC file
/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libstdc++-v3/include/complex line 993
col 60 size <integer_cst 0x60cc44a0 128> unit size <integer_cst 0x60c0eb00 16>
        align 64 context <function_decl 0x601c1f00 __complex_pow> arg-type
<complex_type 0x604cab28 complex double>>
$23 = void
(gdb) p ((tree)0x60809ee0)->decl_common.decl_flag_3
$24 = 1

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[hjl dot tools at gmail dot com]

------- Comment #40 from hjl dot tools at gmail dot com  2009-03-21 18:04 -------
(In reply to comment #39)
> Subject: Re:  [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

> The tree stmt is created in remap_block.  At this point, I think the
> problem is in remap_decls since before the call we have
> 

remap_decls in revision 144529 was incorrect, see PR 39345. I
added remapped_type for PR 39345. Please found which remap_decls
or remapped_type call is the trigger. We may need another fix for
remap_decls/remapped_type.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[hjl dot tools at gmail dot com]

------- Comment #41 from hjl dot tools at gmail dot com  2009-03-21 18:08 -------
(In reply to comment #40)
> (In reply to comment #39)
> > Subject: Re:  [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
> 
> > The tree stmt is created in remap_block.  At this point, I think the
> > problem is in remap_decls since before the call we have
> > 
> 
> remap_decls in revision 144529 was incorrect, see PR 39345. I
> added remapped_type for PR 39345. Please found which remap_decls
> or remapped_type call is the trigger. We may need another fix for
> remap_decls/remapped_type.
> 

I meant to say can_be_nonlocal was incorrect. One of can_be_nonlocal 
call may be the trigger.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #42 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-21 18:32 -------
Subject: Re:  [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

> remap_decls in revision 144529 was incorrect, see PR 39345. I
> added remapped_type for PR 39345. Please found which remap_decls
> or remapped_type call is the trigger. We may need another fix for
> remap_decls/remapped_type.

I am currently debugging with trunk revision 144962, so I think I have
all the current bug fixes in this area..

The problem appears to occur before remap_decls.
DECL_HAS_VALUE_EXPR_P (origin_var) is true for

(gdb) p debug_tree (origin_var)
 <parm_decl 0x60809ee0 __y
    type <complex_type 0x604cab28 complex double
    ...

It's a puzzle how this can occur with no DECL_VALUE_EXPR.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[danglin at gcc dot gnu dot org]

------- Comment #43 from danglin at gcc dot gnu dot org  2009-03-21 18:53 -------
This is the decl passed to can_be_nonlocal:

(gdb) p debug_tree (decl)
 <var_decl 0x60b45148 __y
    type <complex_type 0x604cab28 complex double
        type <real_type 0x604ca578 double sizes-gimplified asm_written type_6
DF
            size <integer_cst 0x60c0e900 constant 64>
            unit size <integer_cst 0x60c0e940 constant 8>
            align 64 symtab 1614619136 alias set 22 canonical type 0x604ca578
precision 64
            pointer_to_this <pointer_type 0x604ca6b0> reference_to_this
<reference_type 0x607156c8>>
        sizes-gimplified asm_written type_6 DC
        size <integer_cst 0x60cc44a0 constant 128>
        unit size <integer_cst 0x60c0eb00 constant 16>
        align 64 symtab 1614710336 alias set 24 canonical type 0x604cab28
        pointer_to_this <pointer_type 0x604e3260>>
    in_system_header DC file
/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libstdc++-v3/include/complex line 1004
col 52 size <integer_cst 0x60cc44a0 128> unit size <integer_cst 0x60c0eb00 16>
    align 64 context <function_decl 0x40107c80 pow> abstract_origin <parm_decl
0x60809ee0 __y> chain <var_decl 0x60b450f0 __x>>
$45 = void
(gdb) p decl->decl_common.decl_flag_3
$46 = 0

It returns true.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c

[danglin at gcc dot gnu dot org]

------- Comment #44 from danglin at gcc dot gnu dot org  2009-03-21 21:59 -------
The parm_decl at 0x60809ee0 first appears in memory after the call to
cpp_push_include.  I'm thinking it must come from PCH.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[danglin at gcc dot gnu dot org]

------- Comment #45 from danglin at gcc dot gnu dot org  2009-03-22 18:34 -------
The testsuite fails disappear if I add --disable-libstdcxx-pch to the
configure command.  The ICE can be suppressed with

Index: dwarf2out.c
===================================================================
--- dwarf2out.c (revision 144988)
+++ dwarf2out.c (working copy)
@@ -10431,8 +10431,12 @@

     case PARM_DECL:
       if (DECL_HAS_VALUE_EXPR_P (loc))
-       return loc_descriptor_from_tree_1 (DECL_VALUE_EXPR (loc),
-                                          want_address);
+       {
+         tree loc1 = DECL_VALUE_EXPR (loc);
+
+         if (loc1 != NULL_TREE)
+           return loc_descriptor_from_tree_1 (loc1, want_address);
+       }
       /* FALLTHRU */

     case RESULT_DECL:

However, it is probably better to determine why the value expression
isn't found.

I looked at the PCH mapping.  The file appears to be correctly mapped
at the specified location and offset by the kernel.

There is some variation in the mapping location for stdc++.h.gch from
build to build.  However, I still don't know why slight changes to expr.o
affect the search for the value expression.


-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.4 Regression] Revision   |[4.4 Regression] Revision
                   |144529 miscompiled          |144529: ICE due to missing
                   |libcpp/expr.c               |or incorrectly relocated
                   |                            |DECL_VALUE_EXPR in PCH
                   |                            |header for PARM_DECL


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[danglin at gcc dot gnu dot org]

------- Comment #46 from danglin at gcc dot gnu dot org  2009-03-22 19:37 -------
When I modified expr.c and the test passed, the PCH file wasn't loaded.
So, the PCH bug wasn't triggered.

Need to figure out why its not being loaded.  


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[danglin at gcc dot gnu dot org]

------- Comment #47 from danglin at gcc dot gnu dot org  2009-03-23 20:39 -------
I hate PCH!

The reason a small change inhibits PCH file loading is the following:

  /* If the text segment was not loaded at the same address as it was
     when the PCH file was created, function pointers loaded from the
     PCH will not be valid.  We could in theory remap all the function
     pointers, but no support for that exists at present.
     Since we have the same executable, it should only be necessary to
     check one function.  */
  if (v.pch_init != &pch_init)
    {
      if (cpp_get_options (pfile)->warn_invalid_pch)
        cpp_error (pfile, CPP_DL_WARNING,
                   "%s: had text segment at different address", name);
      return 2;
    }

Since I wasn't rebuilding the libstdc++ PCH files when I hacked expr.c and
rebuilt cc1plus, I was effectively disabling PCH.

As a side note, the comparison of v.pch_init and &pch_init is dangerous
on targets that use function descriptors.  The value v.pch_init was
recorded by a different binary, so it could point to garbage in the binary
performing the check.

So, we are left with the original PCH bug.  Is the missing DECL_VALUE_EXPR
expected for PCH data?   


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[danglin at gcc dot gnu dot org]

------- Comment #48 from danglin at gcc dot gnu dot org  2009-03-24 16:31 -------
On i686-apple-darwin9, this doesn't fail because DECL_HAS_VALUE_EXPR_P (loc)
is not set:

(gdb) p debug_tree (loc)
 <parm_decl 0x12c4140 __y
    type <complex_type 0xf6dba0 complex double
        type <real_type 0xf6adb0 double sizes-gimplified asm_written type_6 DF
            size <integer_cst 0x1be1b80 constant 64>
            unit size <integer_cst 0x1be1bb0 constant 8>
            align 64 symtab 28208224 alias set 24 canonical type 0xf6adb0
precision 64
            pointer_to_this <pointer_type 0xf6b0c0> reference_to_this
<reference_type 0x11a3e10>>
        sizes-gimplified asm_written type_6 DC
        size <integer_cst 0x1a8d830 constant 128>
        unit size <integer_cst 0x1be1ca0 constant 16>
        align 64 symtab 28379296 alias set 26 canonical type 0xf6dba0
        pointer_to_this <pointer_type 0xfdc4e0>>
    used DC file
/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/libstdc++-v3/include/complex line
993 col 60 size <integer_cst 0x1a8d830 128> unit size <integer_cst 0x1be1ca0
16>
    align 64 context <function_decl 0xcd7300 __complex_pow> arg-type
<complex_type 0xf6dba0 complex double>>
$15 = void
(gdb) p loc->decl_common.decl_flag_3
$16 = 0


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[jakub at gcc dot gnu dot org]

------- Comment #49 from jakub at gcc dot gnu dot org  2009-03-25 07:30 -------
Best is just to track where this VAR_DECL is being written into the pch file
during PCH generation, see if it has DECL_HAS_VALUE_EXPR_P set, what
DECL_VALUE_EXPR it has (if any) and if all is ok on that side, see during PCH
reading whether DECL_HAS_VALUE_EXPR_P has been set and what went up with
DECL_VALUE_EXPR.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4/4.5 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[danglin at gcc dot gnu dot org]

------- Comment #50 from danglin at gcc dot gnu dot org  2009-03-29 18:49 -------
During the PCH generation, there's only one node for which
decl_value_expr_insert 
is called (a different PARM_DECL).  So, I have to think the flag shouldn't be
set.

However, finding the PARM_DECL during PCH generation is a bit of a trick and
I haven't been able to find it so far.  


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4/4.5 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.0                       |4.4.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4/4.5 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.1                       |4.4.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4/4.5 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[danglin at gcc dot gnu dot org]

------- Comment #51 from danglin at gcc dot gnu dot org  2009-07-27 15:10 -------
Doesn't occur if  I configure with --disable-libstdcxx-pch.

This problem also causes the following fails (4.4.2):

FAIL: 26_numerics/complex/pow.cc (test for excess errors)
FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors)
FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4/4.5 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[danglin at gcc dot gnu dot org]

------- Comment #52 from danglin at gcc dot gnu dot org  2009-07-30 03:55 -------
This ICE appears to have been fixed on the trunk by revision 149750:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00631.html

The change affected inlining (see PR 40908), so possibly the problem is
just latent.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4/4.5 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.2                       |4.4.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4/4.5 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.3                       |4.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4/4.5/4.6 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.4                       |4.4.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #54 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-13 13:07:15 UTC ---
And 4.4 is no longer supported.

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.6                       |4.4.7

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
            Summary|[4.4/4.5/4.6 Regression]    |[4.4 Regression] Revision
                   |Revision 144529: ICE due to |144529: ICE due to missing
                   |missing or incorrectly      |or incorrectly relocated
                   |relocated DECL_VALUE_EXPR   |DECL_VALUE_EXPR in PCH
                   |in PCH header for PARM_DECL |header for PARM_DECL

--- Comment #53 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-06 10:45:32 UTC ---
As we don't have any reproducer for 4.5/4.6 (and nobody but John could ever
reproduce it), let's just not track it as 4.5/4.6 regression.