[Bug pch/32636] New: [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[Bug pch/32636] New: [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[hp at gcc dot gnu dot org]

My autotester flags the following failure as introduced between revisions
126197 and 126206 (people with gcc/ChangeLog entries in this range are CCed; no
suspect cp or libstdc++-v3 changes):
Running
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
FAIL: 25_algorithms/search_n/iterator.cc (test for excess errors)

with this in libstdc++.log:
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/stl_algo.h:
In function '_ForwardIterator std::__search_n(_ForwardIterator,
_ForwardIterator, _Integer, const _Tp&, std::forward_iterator_tag) [with
_ForwardIterator = __gnu_test::forward_iterator_wrapper<int>, _Integer = int,
_Tp = int]':^M
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/stl_algo.h:763:
error: definition in block 22 does not dominate use in block 25^M
for SSA_NAME: __i$D47460$SharedInfo_40 in statement:^M
if (__i$D47460$SharedInfo_40 != D.52134_317)^M
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/stl_algo.h:763:
internal compiler error: verify_ssa failed^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See <URL:http://gcc.gnu.org/bugs.html> for instructions.^M

The target and host combination is significant; I haven't been able to
reproduce this on a x86 system, neither with x86_64-unknown-linux-gnu native.
At first sight the bug is generic, but apparently hidden for other
combinations.

A iterator.ii is (to be) attached, but is likely not as helpful as it's
supposed to be, not more than avoiding the "make check" part, as it does not
contain the complete context for debugging cc1plus. It instead contains
#pragma GCC pch_preprocess
"/tmp/hptestregress/obj/cris-elf/libstdc++-v3/include/cris-elf/bits/stdc++.h.gch/O2g.gch"
and when configuring with --disable-libstdcxx-pch, the bug is not exposed.

With a complete built tree and edited file path on the pch_preprocess line,
"cc1plus -melf -fpreprocessed /tmp/iterator.ii -g -O2 -o iterator.s" is
sufficient to reproduce the bug. (Actually the -g seems optional which it
shouldn't be, but I think that's a separate bug.)

Due to the PCH-ness and lack of debug context in iterator.ii, the steps to
reproduce are a bit involved, but trivial and the usual ones for a variant of
cross-testing:
1. Check out, build and install targetted binutils somewhere:
/path/to/src/configure --target=cris-elf --prefix=/where/ever && make all &&
make install
2. Check out and combine newlib and gcc, for example as per
gcc.gnu.org/simtest-howto.html, and make sure gmp and mpfr are accessible
(in-tree or installed on the host)
3. Include /where/ever/bin in your PATH
4, Do /path/to/gccandnewlib/configure --target=cris-elf --prefix=/where/ever
--enable-languages=c++
5. Build; "make all"
6. You now have sufficient PCH context; edit the attached iterator.ii adjusting
the file path to the just-built O2g.gch and run the cc1plus line as above.


-- 
           Summary: [4.3 regression] 25_algorithms/search_n/iterator.cc:
                    pch-related verify_ssa failure
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: ice-checking
          Severity: normal
          Priority: P3
         Component: pch
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-elf


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[hp at gcc dot gnu dot org]

------- Comment #1 from hp at gcc dot gnu dot org  2007-07-05 16:08 -------
Created an attachment (id=13850)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13850&action=view)
preprocessed test-case (with significant parts of context missing due to pch)

See PR description for the cc1plus command-line.


-- 


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[hp at gcc dot gnu dot org]

------- Comment #2 from hp at gcc dot gnu dot org  2007-07-05 16:16 -------
There are ready-to-use tarballs (binutils+sim, gcc+newlib+gmp+mpfr) on
gcc12:/home/hp for those inclined.


-- 


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[ubizjak at gmail dot com]

------- Comment #3 from ubizjak at gmail dot com  2007-07-05 17:19 -------
(In reply to comment #0)
> My autotester flags the following failure as introduced between revisions
> 126197 and 126206 (people with gcc/ChangeLog entries in this range are CCed; no
> suspect cp or libstdc++-v3 changes):

As -ftree-vectorize is not enabled for this test, I think that r126206 (mine)
wasn't the cause for failure.


-- 


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[hp at gcc dot gnu dot org]

------- Comment #4 from hp at gcc dot gnu dot org  2007-07-07 15:17 -------
In reply to comment #4: confirmed.  I've now confirmed that it is commit 126198
that exposed this bug, so I'll remove all other people from CC.  You're very
welcome to add yourself back, of course. :)  Richi, if you can shed some light
on what optimizations (what passes) your patch helped (caused more work for)
the most, I'd be grateful. Or if you just fix the bug. :)  There are trees
named regress126197 and regress126198 in my home directory on gcc11 on the
compile farm... where you don't have an account, bother.


-- 

hp at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-07-07 15:17:58
               date|                            |


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[rguenther at suse dot de]

------- Comment #5 from rguenther at suse dot de  2007-07-07 15:24 -------
Subject: Re:  [4.3 regression] 25_algorithms/search_n/iterator.cc:
 pch-related verify_ssa failure

On Sat, 7 Jul 2007, hp at gcc dot gnu dot org wrote:

> ------- Comment #4 from hp at gcc dot gnu dot org  2007-07-07 15:17 -------
> In reply to comment #4: confirmed.  I've now confirmed that it is commit 126198
> that exposed this bug, so I'll remove all other people from CC.  You're very
> welcome to add yourself back, of course. :)  Richi, if you can shed some light
> on what optimizations (what passes) your patch helped (caused more work for)
> the most, I'd be grateful. Or if you just fix the bug. :)  There are trees
> named regress126197 and regress126198 in my home directory on gcc11 on the
> compile farm... where you don't have an account, bother.

So the only real change in this patch is in the following hunk:

Index: tree-inline.c
===================================================================
--- tree-inline.c       (revision 126197)
+++ tree-inline.c       (revision 126198)
@@ -1278,10 +1278,15 @@ setup_one_parameter (copy_body_data *id,
   tree init_stmt;
   tree var;
   tree var_sub;
-  tree rhs = value ? fold_convert (TREE_TYPE (p), value) : NULL;
+  tree rhs = value;
   tree def = (gimple_in_ssa_p (cfun)
              ? gimple_default_def (id->src_cfun, p) : NULL);

+  if (value
+      && value != error_mark_node
+      && !useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value)))
+    rhs = fold_build1 (NOP_EXPR, TREE_TYPE (p), value);
+
   /* If the parameter is never assigned to, has no SSA_NAMEs created,
      we may not need to create a new variable here at all.  Instead, we 
may
      be able to just use the argument value.  */


See also PR32624.  Can you check if changing this part like in
comment #4 of that PR fixes this bug?  It will only result in
less casts and less temporaries, but as can be seen from PR32624
this has some strange effects.

Richard.


-- 


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[hp at gcc dot gnu dot org]

------- Comment #6 from hp at gcc dot gnu dot org  2007-07-07 15:44 -------
Failing pass:

#4  0x0000000000738bbf in execute_one_pass (pass=0xca6280) at
/home/hp/regress126198/gcc/gcc/passes.c:1147
(gdb) p *pass
$1 = {name = 0xafff81 "store_copyprop", gate = 0x848c70 <gate_store_copy_prop>,
execute = 0x84c060 <store_copy_prop>,
  sub = 0x0, next = 0xca61c0, static_pass_number = 85, tv_id = 40,
properties_required = 584, properties_provided = 0,
  properties_destroyed = 0, todo_flags_start = 131072, todo_flags_finish =
1063, letter = 0 '\0'}


-- 


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[hp at gcc dot gnu dot org]

------- Comment #7 from hp at gcc dot gnu dot org  2007-07-07 15:56 -------
Created an attachment (id=13864)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13864&action=view)
one of the dumps generated with -fdump-tree-store_copyprop-vops-blocks
-fdump-tree-store_ccp-vops-blocks


-- 


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[hp at gcc dot gnu dot org]

------- Comment #8 from hp at gcc dot gnu dot org  2007-07-07 15:57 -------
Created an attachment (id=13865)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13865&action=view)
the other dump


-- 


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[hp at gcc dot gnu dot org]

------- Comment #9 from hp at gcc dot gnu dot org  2007-07-07 16:00 -------
Using the patch in comment #5 applied on 126197 causes the same failure.


-- 


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2007-07-07 16:13 -------
So the bogus replacement happens in store_copyprop (function
_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiET_S3_S3_T0_RKT1_St20forward_iterator_tag)

for a (yet) mysterious reason it replaces in

    # BLOCK 25 freq:2
    # PRED: 23 [46.0%]  (false,exec) 21 [46.0%]  (false,exec)
    # SMT.1008_263 = PHI <SMT.1008_221(23), SMT.1008_149(21)>
    # __i$D47460$SharedInfo_92 = PHI <__i$D47460$SharedInfo_40(23),
SR.1030_31(21)>
    # __i$D47460$ptr_93 = PHI <__i$D47460$ptr_39(23), __i$D47460$ptr_75(21)>
    __i$D47460$ptr_106 = __i$D47460$ptr_93 + 4;
    # VUSE <SMT.1008_263>
    D.52134_317 = D.48545_101->SharedInfo;
!   if (__i$D47460$SharedInfo_92 != D.52134_317)
      goto <bb 32>;
    else
      goto <bb 26>;
    # SUCC: 32 [85.0%]  (true,exec) 26 [15.0%]  (false,exec)

the __i$D47460$SharedInfo_92 by __i$D47460$SharedInfo_40.


-- 


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[hp at gcc dot gnu dot org]

------- Comment #11 from hp at gcc dot gnu dot org  2007-07-07 16:15 -------
Created an attachment (id=13866)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13866&action=view)
dump with -fdump-tree-store_copyprop-vops-blocks-details


-- 


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.3.0


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2007-07-07 17:04 -------
So the problem is that we detect

PHI node __i$D47460$SharedInfo_92 copy-of chain: __i$D47460$SharedInfo_92 ->
__i$D47460$SharedInfo_40 -> SR.1030_31 -> SR.1030_31 [COPY]

but later replace with __i$D47460$SharedInfo_40 instead of SR.1030_31.

So the problem seems to be we sort of have

struct Foo {
  int x;
};

void use(int);

void foo(struct Foo *p, int q)
{
  int a = p->x;
  int b, c, d;

  if (a)
    c_1 = p->x;
  else
    {
      c_3 = a;
    }

# c_4 = PHI <c_1, c_3>
  use (c);
}

where copyprop figures that c_1 and a are the same load and so does
figure that c_4 is a copy of a and c_1 and c_3.  But there is no
code that figures the proper ssa_name loaded into as of a dominance
relationship.  (Of course the above testcase doesn't fail... but you
get the idea what happens.)


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dnovillo at gcc dot gnu dot
                   |                            |org
   Target Milestone|4.3.0                       |---


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

[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2007-07-07 17:23 -------
The following creates a similar copy chain, but still chooses the right one to
copy from.

struct Foo {
  int x;
};

void use(int);

void foo(struct Foo *p, int q)
{
  int a = p->x;
  int b, c;

  p->x = a;

  if (q)
    c = p->x;
  else
    c = a;

  use (c);
}

 ./cc1 -quiet -O2 t.i -fdump-tree-all-vops-details -fno-tree-fre -fno-tree-pre
-fno-tree-dominator-opts -fno-tree-vrp

Visiting PHI node: c_1 = PHI <c_5(3), a_3(2)>

        Argument #0: c_5 copy-of chain: c_5 -> a_3 -> a_3 [COPY]
        Argument #1: a_3 copy-of chain: a_3 -> a_3 [NOT A COPY]

PHI node c_1 copy-of chain: c_1 -> c_5 -> a_3 -> a_3 [COPY]


-- 


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|pch                         |tree-optimization
   Target Milestone|---                         |4.3.0


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[hp at gcc dot gnu dot org]

------- Comment #14 from hp at gcc dot gnu dot org  2007-07-09 18:30 -------
>From revision 126479 (in the range 126472..126429), the bug is again hidden.
There's a libstdc++-v3/include/bits/stl_algo.h tweak in that range that
apparently sufficiently changed the code.


-- 


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2007-07-12 09:57 -------
I bet this is the same as PR32722.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |32722


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[danglin at gcc dot gnu dot org]

------- Comment #16 from danglin at gcc dot gnu dot org  2007-08-01 16:30 -------
A similar error appeared in revision 127096 on hppa-unknown-linux-gnu:

/home/dave/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bits/stl_algo.h: In
fu
nction '_ForwardIterator std::__search_n(_ForwardIterator, _ForwardIterator,
_In
teger, const _Tp&, std::forward_iterator_tag) [with _ForwardIterator =
__gnu_tes
t::forward_iterator_wrapper<X>, _Integer = int, _Tp = Y]':
/home/dave/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bits/stl_algo.h:754:
e
rror: definition in block 21 does not dominate use in block 24
for SSA_NAME: __i$D55786$SharedInfo_40 in statement:
if (__i$D55786$SharedInfo_40 != D.56866_41)
/home/dave/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bits/stl_algo.h:754:
i
nternal compiler error: verify_ssa failed
...
FAIL: 25_algorithms/search_n/check_type.cc (test for excess errors)

I'm also seeing on hpux

FAIL: 25_algorithms/search_n/iterator.cc execution test

Program received signal SIGBUS, Bus error.
__gnu_test::forward_iterator_wrapper<int>
std::__search_n<__gnu_test::forward_iterator_wrapper<int>, int, int, bool
(*)(int, int)>(__gnu_test::forward_iterator_wrapper<int>,
__gnu_test::forward_iterator_wrapper<int>, int, int const&, bool (*)(int, int),
std::forward_iterator_tag) (__first=@0x7eff0838,
    __last=@0x7eff0840, __count=2, __val=@0x7eff0654,
    __binary_pred=@0x40001602: 0x3140 <_Z4predii>)
    at /test/gnu/gcc/gcc/libstdc++-v3/testsuite/util/testsuite_iterators.h:195
195           : ptr(in.ptr), SharedInfo(in.SharedInfo)
(gdb) bt
#0  __gnu_test::forward_iterator_wrapper<int>
std::__search_n<__gnu_test::forward_iterator_wrapper<int>, int, int, bool
(*)(int, int)>(__gnu_test::forward_iterator_wrapper<int>,
__gnu_test::forward_iterator_wrapper<int>, int, int const&, bool (*)(int, int),
std::forward_iterator_tag) (__first=@0x7eff0838,
    __last=@0x7eff0840, __count=2, __val=@0x7eff0654,
    __binary_pred=@0x40001602: 0x3140 <_Z4predii>)
    at /test/gnu/gcc/gcc/libstdc++-v3/testsuite/util/testsuite_iterators.h:195
#1  0x00003b50 in __gnu_test::forward_iterator_wrapper<int>
std::search_n<__gnu_test::forward_iterator_wrapper<int>, int, int, bool
(*)(int, int)>(__gnu_test::forward_iterator_wrapper<int>,
__gnu_test::forward_iterator_wrapper<int>, int, int const&, bool (*)(int, int))
(__first=@0x7eff0730, __last=@0x7eff0738,
    __count=1073747616, __val=@0x7eff0654,
    __binary_pred=@0x40001602: 0x3140 <_Z4predii>)
    at /test/gnu/gcc/gcc/libstdc++-v3/testsuite/util/testsuite_iterators.h:195
#2  0x00005e7c in main ()
    at
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/25_algorithms/search_n/iterator.cc:87

The bus error doesn't occur at -O0 and -O1.


-- 

danglin at gcc dot gnu dot org changed:

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


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[danglin at gcc dot gnu dot org]

------- Comment #17 from danglin at gcc dot gnu dot org  2007-08-01 17:27 -------
Looking at the hpux failure, it seems
_ZSt8search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT
1_T2_ is miscompiled.

The problem is probably the same as reported in PR32878.


-- 


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[jakub at gcc dot gnu dot org]

------- Comment #18 from jakub at gcc dot gnu dot org  2007-11-13 15:57 -------
Is this still reproduceable with current trunk?


-- 


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca  2007-11-13 19:27 -------
Subject: Re:  [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related
verify_ssa failure

> Is this still reproduceable with current trunk?

As of last night, this still occurs on hppa2.0w-hp-hpux11.11.  It's
the only remaining failure in the libstdc++ testsuite.

Dave


-- 


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[jakub at gcc dot gnu dot org]

------- Comment #20 from jakub at gcc dot gnu dot org  2007-11-16 14:31 -------
Does the problem go away if you
mv include/*-*-*/bits/stdc++.h.gch{,bad}
and recompile the test?  If yes, can you please check with -fdump-tree-all
at which pass the dumps start to differ between compilation with stdc++.h.gch
and with just stdc++.h?
Wonder if this can be debugged just with a cross compiler...


-- 


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[jakub at gcc dot gnu dot org]

------- Comment #21 from jakub at gcc dot gnu dot org  2007-12-03 15:08 -------
Ping.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[hp at gcc dot gnu dot org]

------- Comment #22 from hp at gcc dot gnu dot org  2007-12-03 15:23 -------
Ping for me or John David Anglin?
I suppose it's for him, as I don't see the failure on currentish (130398)
trunk.


-- 


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #23 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-03 15:43 -------
Subject: Re:  [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related
verify_ssa failure

> Ping.

Sorry, I don't have an update and haven't had a chance to try the
suggestions in #20.  I've been spending all my time trying to fix
a reload bug.

The test still failed in my last build but that was sometime ago
(130380).

Dave


-- 


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

[Bug tree-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-06 00:28 -------
Subject: Re:  [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related
verify_ssa failure

> Ping.

I moved the gch headers.  Doesn't seem to be a pch problem:

(gdb) r
Starting program:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/testsuite/iterator.exe
warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.

Program received signal SIGBUS, Bus error.
__gnu_test::forward_iterator_wrapper<int>
std::__search_n<__gnu_test::forward_iterator_wrapper<int>, int, int, bool
(*)(int, int)>(__gnu_test::forward_iterator_wrapper<int>,
__gnu_test::forward_iterator_wrapper<int>, int, int const&, bool (*)(int, int),
std::forward_iterator_tag) (__first=@0x7eff0878,
    __last=@0x7eff0880, __count=2, __val=@0x7eff0654,
    __binary_pred=@0x4000155a: 0x3148 <_Z4predii>)
    at /test/gnu/gcc/gcc/libstdc++-v3/testsuite/util/testsuite_iterators.h:206
206         : ptr(in.ptr), SharedInfo(in.SharedInfo)
(gdb) bt
#0  __gnu_test::forward_iterator_wrapper<int>
std::__search_n<__gnu_test::forward_iterator_wrapper<int>, int, int, bool
(*)(int, int)>(__gnu_test::forward_iterator_wrapper<int>,
__gnu_test::forward_iterator_wrapper<int>, int, int const&, bool (*)(int, int),
std::forward_iterator_tag) (__first=@0x7eff0878,
    __last=@0x7eff0880, __count=2, __val=@0x7eff0654,
    __binary_pred=@0x4000155a: 0x3148 <_Z4predii>)
    at /test/gnu/gcc/gcc/libstdc++-v3/testsuite/util/testsuite_iterators.h:206
#1  0x00004128 in __gnu_test::forward_iterator_wrapper<int>
std::search_n<__gnu_test::forward_iterator_wrapper<int>, int, int, bool
(*)(int, int)>(__gnu_test::forward_iterator_wrapper<int>,
__gnu_test::forward_iterator_wrapper<int>, int, int const&, bool (*)(int, int))
(__first=@0x7eff0748, __last=@0x7eff0750,
    __count=1073747448, __val=@0x7eff0654,
    __binary_pred=@0x4000155a: 0x3148 <_Z4predii>)
    at
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stl_algo.h:4413
#2  0x00005ca4 in main ()
    at
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/25_algorithms/search_n/iterator.cc:90
(gdb) p/x $pc
$1 = 0x3a84
(gdb) disass 0x3a74 0x3a94
Dump of assembler code from 0x3a74 to 0x3a94:
0x00003a74
<_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT1_T2_St20forward_iterator_tag+1044>:
    ldw 4(r8),r20
0x00003a78
<_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT1_T2_St20forward_iterator_tag+1048>:
    ldo 4(r19),ret0
0x00003a7c
<_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT1_T2_St20forward_iterator_tag+1052>:
    b,l 0x36d4
<_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT1_T2_St20forward_iterator_tag+116>,r0
0x00003a80
<_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT1_T2_St20forward_iterator_tag+1056>:
    stw ret0,0(r8)
0x00003a84
<_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT1_T2_St20forward_iterator_tag+1060>:
    stw ret0,0(r14)
0x00003a88
<_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT1_T2_St20forward_iterator_tag+1064>:
    ldw 4(r6),ret0
0x00003a8c
<_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT1_T2_St20forward_iterator_tag+1068>:
    b,l 0x381c
<_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT1_T2_St20forward_iterator_tag+444>,r0
0x00003a90
<_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT1_T2_St20forward_iterator_tag+1072>:
    stw ret0,4(r14)
End of assembler dump.
(gdb) p/x $r14
$2 = 0x6000

r14 points to readpnly memory.

Dave


-- 


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

[Bug tree-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[jakub at gcc dot gnu dot org]

------- Comment #25 from jakub at gcc dot gnu dot org  2007-12-10 20:25 -------
Could you please attach the testcase preprocessed, so I can try to debug it
using a cross?  Thanks.


-- 


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

[Bug tree-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #26 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-11 00:06 -------
Subject: Re:  [4.3 Regression]
        25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

> Could you please attach the testcase preprocessed, so I can try to debug it
> using a cross?  Thanks.

Here it is.

Dave


------- Comment #27 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-11 00:06 -------
Created an attachment (id=14722)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14722&action=view)


-- 


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

[Bug tree-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled on hppa2.0w-hp-hpux11.11

[jakub at gcc dot gnu dot org]

------- Comment #28 from jakub at gcc dot gnu dot org  2007-12-11 10:02 -------
This smells dataflow related.  At least if I understood right, the problem is
that the
_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT1_T2_St20forward_iterator_tag
function is called with bogus %r28, right?

The final bogus value seems to be there because of dbr, which inserts load of
address of a string literal into %r28 into one delay slot, but that's because
%r28 was said to be REG_DEAD, even when it really wasn't.
But it seems there are problems much earlier (everything with just -O2 on the
attached iterator.ii with a x86_64-linux -> hppa2.0w-hp-hpux11.11 cross):

In *optimized dump:
<bb 20>:
  temp.573 = <retval>;
  D.54493.D.53815.ptr = __first->D.53815.ptr;
  D.54493.D.53815.SharedInfo = __first->D.53815.SharedInfo;
  D.54494.D.53815.ptr = __last->D.53815.ptr;
  D.54494.D.53815.SharedInfo = __last->D.53815.SharedInfo;
  D.54515 = {};
  *temp.573 = __search_n (&D.54493, &D.54494, __count, __val, __binary_pred,
  D.54515) [return slot optimization];

In *subreg dump (each ... relation is that previous insns dominate later from
what I can see):
(insn 2 9 3 2 libstdc++-v3/include/bits/stl_algo.h:4396 (set (reg/f:SI 107 [
<result> ])
        (reg:SI 28 %r28)) 37 {*pa.md:2542} (nil))
...
(call_insn 99 98 100 18 libstdc++-v3/include/bits/stl_algo.h:4408 (parallel [
            (set (reg:SI 28 %r28)
                (call (mem:SI (reg:SI 22 %r22) [0 S4 A32])
                    (const_int 16 [0x10])))
            (clobber (reg:SI 1 %r1))
            (clobber (reg:SI 2 %r2))
            (use (const_int 1 [0x1]))
        ]) 215 {call_val_reg} (nil)
    (expr_list:REG_DEP_TRUE (use (reg:SI 25 %r25))
        (expr_list:REG_DEP_TRUE (use (reg:SI 26 %r26))
            (nil))))
(insn 100 99 101 18 libstdc++-v3/include/bits/stl_algo.h:4408 (set (reg:SI 127)
        (reg:SI 28 %r28)) 37 {*pa.md:2542} (nil))
...
(insn 113 112 114 20 libstdc++-v3/include/bits/stl_algo.h:4413 (set (reg/f:SI
96 [ temp.573 ])
        (reg/f:SI 107 [ <result> ])) 37 {*pa.md:2542} (nil))
...
(insn 125 124 156 20 libstdc++-v3/include/bits/stl_algo.h:4413 (set (reg:SI 28
%r28)
        (reg/f:SI 96 [ temp.573 ])) 37 {*pa.md:2542} (nil))
...
(call_insn 130 129 135 20 libstdc++-v3/include/bits/stl_algo.h:4413 (parallel [
            (call (mem:SI (symbol_ref/v:SI
("@_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT1_T2_St20forward_iterator_tag")
[flags 0x3] <function_decl 0x2aaab0cf0820 __search_n>) [0 S4 A32])
                (const_int 24 [0x18]))
            (clobber (reg:SI 1 %r1))
            (clobber (reg:SI 2 %r2))
            (use (const_int 0 [0x0]))
        ]) 206 {call_symref} (nil)
    (expr_list:REG_DEP_TRUE (use (reg:SI 23 %r23))
        (expr_list:REG_DEP_TRUE (use (reg:SI 24 %r24))   
            (expr_list:REG_DEP_TRUE (use (reg:SI 25 %r25))
                (expr_list:REG_DEP_TRUE (use (reg:SI 26 %r26))
                    (expr_list:REG_DEP_TRUE (use (reg:SI 28 %r28))
                        (nil)))))))

In *cse1 dump:
(insn 2 9 3 2 libstdc++-v3/include/bits/stl_algo.h:4396 (set (reg/f:SI 107 [
<result> ])
        (reg:SI 28 %r28)) 37 {*pa.md:2542} (nil))
...
(call_insn 99 98 100 18 libstdc++-v3/include/bits/stl_algo.h:4408 (parallel [
            (set (reg:SI 28 %r28)
                (call (mem:SI (reg:SI 22 %r22) [0 S4 A32])
                    (const_int 16 [0x10])))
            (clobber (reg:SI 1 %r1))
            (clobber (reg:SI 2 %r2))
            (use (const_int 1 [0x1]))
        ]) 215 {call_val_reg} (nil)
    (expr_list:REG_DEP_TRUE (use (reg:SI 25 %r25))
        (expr_list:REG_DEP_TRUE (use (reg:SI 26 %r26))
            (nil))))
(insn 100 99 101 18 libstdc++-v3/include/bits/stl_algo.h:4408 (set (reg:SI 127)
        (reg:SI 28 %r28)) 37 {*pa.md:2542} (nil))
...
(insn 113 112 114 20 libstdc++-v3/include/bits/stl_algo.h:4413 (set (reg/f:SI
96 [ temp.573 ])
        (reg/f:SI 107 [ <result> ])) 37 {*pa.md:2542} (nil))
...
(insn 125 124 156 20 libstdc++-v3/include/bits/stl_algo.h:4413 (set (reg:SI 28
%r28 [ temp.573 ])
        (reg:SI 28 %r28 [ temp.573 ])) 37 {*pa.md:2542} (nil))

I hope I haven't missed any control flow that could be in the way, but assuming
for all ... snippets insns before it dominate those after it, cse1 change of 
insn 125 is not correct, %r28 is clobbered by call_insn 99.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
 GCC target triplet|cris-elf                    |hppa2.0w-hp-hpux11.11
           Keywords|ice-checking                |wrong-code
   Last reconfirmed|2007-07-07 15:17:58         |2007-12-11 10:02:49
               date|                            |
            Summary|[4.3 Regression]            |[4.3 Regression]
                   |25_algorithms/search_n/itera|25_algorithms/search_n/itera
                   |tor.cc: pch-related         |tor.cc: miscompiled on
                   |verify_ssa failure          |hppa2.0w-hp-hpux11.11


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

[Bug tree-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled on hppa2.0w-hp-hpux11.11

[jakub at gcc dot gnu dot org]

------- Comment #29 from jakub at gcc dot gnu dot org  2007-12-11 11:13 -------
Actually, I was wrong, that insn 99 is inside of the if (__count == 1) { ...
return ...; }
So it is dbr that messes this up.
Simplified testcase (only for visual inspection of the generated code, someone
with access to pa could turn that into an executable testcase):

extern "C" void __assert (const char *, const char *, int);

template<typename S, typename T>
S foo1 (S s1, S s2, int i1, const int &i2, T t);

template<typename S, typename T>
S foo (S s1, S s2, int i1, const int &i2, T t)
{
  if (i1 <= 0)
    return s1;
  if (i1 == 1)
    {
      while (s1 != s2 && !bool (t (*s1, i2)))
        ++s1;
      return s1;
    }
  return foo1 (s1, s2, i1, i2, t);
}

template<typename T>
struct B
{
  T *first;
  T *last;
  B (T *x, T *y) : first (x), last (y) { }
};

template<class T>
struct C
{
  C () { }

  typedef B<T> BT;
  T *t;
  BT *bt;

  C (T *x, BT *y) : t (x), bt (y) { (t >= bt->first && t <= bt->last) ? (void)
0 : __assert ("f", "y", 203); }
  C (const C &in) : t (in.t), bt (in.bt) { }

  bool
  operator!= (const C& in) const
  {
    (bt != __null && bt == in.bt) ? (void) 0 : __assert ("g", "y", 212);
    (t >= bt->first && in.t >= bt->first) ? (void) 0 : __assert ("h", "y",
213);
    return t != in.t;
  }

  C&
  operator= (const C& in)
  {
    t = in.t;
    bt = in.bt;
    return *this;
  }
};

template<class T>
struct D : public C<T>
{
  typedef B<T> BT;
  D (T *x, BT *y) : C<T> (x, y) { }
  D (const D &in) : C<T> (in) { }
  D () { this->t = __null; this->bt = __null; }

  T&
  operator* () const
  {
    (this->bt && this->t < this->bt->last) ? (void) 0 : __assert ("x", "y",
292);
    return *(this->t);
  }

  D&
  operator++ ()
  {
    (this->bt && this->t < this->bt->last) ? (void) 0 : __assert ("z", "y",
303);
    this->t++;
    return *this;
  }
};

bool
pred (int i, int j)
{
  return i == j;
}

int
main ()
{
  int a[2] = { 0, 0 };
  D<int>::BT ct (&a[0], &a[1]);
  foo (D<int> (&a[0], &ct), D<int> (&a[1], &ct), 0, 1, pred);
  return 0;
}

At -O2 this has:
        comib,>= 0,%r24,L$0025
        stw %r4,-72(%r30)
        comib,= 1,%r24,L$0026
        ldil LR'L$C0002,%r28
        stw %r7,-52(%r30)
        ldw 4(%r26),%r20
        ldo -112(%r30),%r25
        ldo -120(%r30),%r26
        stw %r20,-116(%r30)
        ldw 4(%r6),%r19
        ldw 0(%r3),%r20
        stw %r19,-108(%r30)
        stw %r20,-120(%r30)
        ldw 0(%r6),%r19
        .CALL ARGW0=GR,ARGW1=GR,ARGW2=GR,ARGW3=GR
        bl _Z4foo1I1DIiEPFbiiEET_S4_S4_iRKiT0_,%r2
        stw %r19,-112(%r30)
where the undesirable ldil LR'L$C0002,%r28 is in the delay slot of the
conditional branch.  %r28 should contain the original %r28 value passed to the
function.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at nildram dot co
                   |                            |dot uk
          Component|rtl-optimization            |tree-optimization


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

[Bug rtl-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled on hppa2.0w-hp-hpux11.11

[jakub at gcc dot gnu dot org]

------- Comment #30 from jakub at gcc dot gnu dot org  2007-12-11 15:07 -------
mark_target_live_regs doesn't recognize %r28 as live on the fallthrough insn
after the branch.  There are no BARRIER insns before that fallthrough insn (the
jump is conditional and there are no unconditional jumps before that), so
find_basic_block gives b == 2, i.e. ENTRY successor.  Basic block has:
;; basic block 2, loop depth 0, count 0
;; prev block 0, next block 3
;; pred:       ENTRY [100.0%]  (fallthru)
;; succ:       24 [26.7%]  (can_fallthru) 3 [73.3%]  (fallthru,can_fallthru)
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u-1(30){ }}
;; lr  in        2 [%r2] 3 [%r3] 4 [%r4] 5 [%r5] 6 [%r6] 7 [%r7] 8 [%r8] 9
[%r9] 10 [%r10] 11 [%r11] 12 [%r12] 23 [%r23] 24 [%r24] 25 [%r25] 26 [%r26] 28
[%r28] 30 [%r30]
;; lr  use       2 [%r2] 3 [%r3] 4 [%r4] 5 [%r5] 6 [%r6] 7 [%r7] 8 [%r8] 9
[%r9] 10 [%r10] 11 [%r11] 12 [%r12] 23 [%r23] 24 [%r24] 25 [%r25] 26 [%r26] 28
[%r28] 30 [%r30]
;; lr  def       3 [%r3] 5 [%r5] 6 [%r6] 7 [%r7] 8 [%r8] 30 [%r30]
;; live  in      2 [%r2] 3 [%r3] 4 [%r4] 5 [%r5] 6 [%r6] 7 [%r7] 8 [%r8] 9
[%r9] 10 [%r10] 11 [%r11] 12 [%r12] 23 [%r23] 24 [%r24] 25 [%r25] 26 [%r26]
;; live  gen     3 [%r3] 5 [%r5] 6 [%r6] 7 [%r7] 8 [%r8] 30 [%r30]
;; live  kill

In reality %r28 is live from the caller and used (multiple times) throughout
the function, but it is not among df_get_live_in (BASIC_BLOCK (2)), but e.g. in
lr in.  CCing dataflow maintainers if they have ideas what's wrong here.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zadeck at gcc dot gnu dot
                   |                            |org, spark at gcc dot gnu
                   |                            |dot org, bonzini at gnu dot
                   |                            |org


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

[Bug rtl-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled on hppa2.0w-hp-hpux11.11

[zadeck at naturalbridge dot com]

------- Comment #31 from zadeck at naturalbridge dot com  2007-12-11 15:23 -------
why should r28 be live at the top of block 2?  i do not know the pa at all, but
the only things that are live at the top of block 2, which can only be entered
by falling out of the entry.  Things that are defined at the bottom of the
entry block are defined in df-scan.c:df_get_entry_block_def_set.  

This code has been adapted (as best as we can figure) from the code that was in
flow.c.

The question is why is this code not adequate to get r28 into the entry block
defs? 


-- 


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

[Bug rtl-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled on hppa2.0w-hp-hpux11.11

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #32 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-11 16:52 -------
Subject: Re:  [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled
on hppa2.0w-hp-hpux11.11

> At -O2 this has:
>         comib,>= 0,%r24,L$0025
>         stw %r4,-72(%r30)
>         comib,= 1,%r24,L$0026
>         ldil LR'L$C0002,%r28
>         stw %r7,-52(%r30)
>         ldw 4(%r26),%r20
>         ldo -112(%r30),%r25
>         ldo -120(%r30),%r26
>         stw %r20,-116(%r30)
>         ldw 4(%r6),%r19
>         ldw 0(%r3),%r20
>         stw %r19,-108(%r30)
>         stw %r20,-120(%r30)
>         ldw 0(%r6),%r19
>         .CALL ARGW0=GR,ARGW1=GR,ARGW2=GR,ARGW3=GR
>         bl _Z4foo1I1DIiEPFbiiEET_S4_S4_iRKiT0_,%r2
>         stw %r19,-112(%r30)
> where the undesirable ldil LR'L$C0002,%r28 is in the delay slot of the
> conditional branch.  %r28 should contain the original %r28 value passed to the
> function.

%r28 is used as a function argument only struct values.  It looks to
me like the instruction to load the value from L$C0002 has been dropped.
This would be an insn like

        ldw RR'L$C0002(%r28),%r??

or possibly

        ldo RR'L$C0002(%r28),%r??

if we want the address of L$C0002.

If _Z4foo1I1DIiEPFbiiEET_S4_S4_iRKiT0_ expects a struct value, it might
be the call usage information is incorrect.  Of course,
_Z4foo1I1DIiEPFbiiEET_S4_S4_iRKiT0_ might not have a struct value argument.

Dave


-- 


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

[Bug rtl-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled on hppa2.0w-hp-hpux11.11

[pinskia at gcc dot gnu dot org]

------- Comment #33 from pinskia at gcc dot gnu dot org  2007-12-11 17:12 -------
I wonder if http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00506.html also fixes
this code too which mentions dbr.


-- 


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

[Bug rtl-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled on hppa2.0w-hp-hpux11.11

[jakub at gcc dot gnu dot org]

------- Comment #34 from jakub at gcc dot gnu dot org  2007-12-11 20:37 -------
Answers (note, I don't know PA at all either):
1) in a function that returns struct, %r28 is what
   targetm.calls.struct_value_rtx gives:
/* Register in which address to store a structure value
   is passed to a function.  */
#define PA_STRUCT_VALUE_REGNUM 28
static rtx
pa_struct_value_rtx (tree fntype ATTRIBUTE_UNUSED,
                     int incoming ATTRIBUTE_UNUSED)
{
  return gen_rtx_REG (Pmode, PA_STRUCT_VALUE_REGNUM);
}
2) the instruction to load lo_sum of the address has not been dropped, I posted
   only part of the function's assembly.  The bug is that dbr decides to put
   ldil LR'L$C0002,%r28 instruction from branch target (L$0026) into a delay
slot
   even when %r28 is in fact live (passed from caller, unmodified to foo1)
3) I have tried Richard Sandiford's dbr patch immediately when I noticed this
   is dbr related, but it doesn't help.

I guess we need to ensure somehow that df knows struct_value_rtx regs are live
at the beginning of function for functions that return struct.


-- 


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

[Bug rtl-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled on hppa2.0w-hp-hpux11.11

[jakub at gcc dot gnu dot org]

------- Comment #35 from jakub at gcc dot gnu dot org  2007-12-11 21:28 -------
df_get_entry_block_def_set has this:
  /* Once the prologue has been generated, all of these registers
     should just show up in the first regular block.  */
  if (HAVE_prologue && epilogue_completed)
    {
      /* Defs for the callee saved registers are inserted so that the
         pushes have some defining location.  */
      for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
        if ((call_used_regs[i] == 0) && (df_regs_ever_live_p (i)))
          bitmap_set_bit (entry_block_defs, i);
    }
  else
    {
...
      r = targetm.calls.struct_value_rtx (current_function_decl, true);
      if (r && REG_P (r))
        bitmap_set_bit (entry_block_defs, REGNO (r));
    }

So, apparently struct_value_rtx is already considered, but only before
prologues/epilogues are inserted (or the arch doesn't HAVE_prologue).
On PA call_used_regs[28] != 0, so the comment "Once the prologue ..."
doesn't make sense for it, because the if part won't ever set %r28 in
entry_block_defs, even when it is needed.  I've tried:
--- df-scan.c.jj        2007-10-26 13:45:44.000000000 +0200
+++ df-scan.c   2007-12-11 22:24:21.000000000 +0100
@@ -3530,12 +3530,12 @@ df_get_entry_block_def_set (bitmap entry
       bitmap_set_bit (entry_block_defs, STATIC_CHAIN_REGNUM);
 #endif
 #endif
-      
-      r = targetm.calls.struct_value_rtx (current_function_decl, true);
-      if (r && REG_P (r))
-       bitmap_set_bit (entry_block_defs, REGNO (r));
     }

+  r = targetm.calls.struct_value_rtx (current_function_decl, true);
+  if (r && REG_P (r))
+    bitmap_set_bit (entry_block_defs, REGNO (r));
+
   if ((!reload_completed) || frame_pointer_needed)
     {
       /* Any reference to any pseudo before reload is a potential
patch and it indeed probably cures this testcase.  The diff in assembly is:
...
        comib,>= 0,%r24,L$0025
        stw %r4,-72(%r30)
        comib,= 1,%r24,L$0026
-       ldil LR'L$C0002,%r28
+       ldil LR'L$C0003,%r19
        stw %r7,-52(%r30)
        ldw 4(%r26),%r20
        ldo -112(%r30),%r25
        ldo -120(%r30),%r26
        stw %r20,-116(%r30)
        ldw 4(%r6),%r19
        ldw 0(%r3),%r20
        stw %r19,-108(%r30)
        stw %r20,-120(%r30)
        ldw 0(%r6),%r19
        .CALL ARGW0=GR,ARGW1=GR,ARGW2=GR,ARGW3=GR
        bl _Z4foo1I1DIiEPFbiiEET_S4_S4_iRKiT0_,%r2
        stw %r19,-112(%r30)
...
 L$0026:
-       ldil LR'L$C0003,%r19
+       ldil LR'L$C0002,%r28
        ldw 4(%r26),%r20
        ldo RR'L$C0002(%r28),%r9
        ldil LR'L$C0001,%r28
...
which looks promissing (though of course without access to PA I can't be sure
it works).


-- 


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

[Bug rtl-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled on hppa2.0w-hp-hpux11.11

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #36 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-11 21:44 -------
Subject: Re:  [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled
on hppa2.0w-hp-hpux11.11

> 2) the instruction to load lo_sum of the address has not been dropped, I posted
>    only part of the function's assembly.  The bug is that dbr decides to put
>    ldil LR'L$C0002,%r28 instruction from branch target (L$0026) into a delay
> slot
>    even when %r28 is in fact live (passed from caller, unmodified to foo1)
> 
> I guess we need to ensure somehow that df knows struct_value_rtx regs are live
> at the beginning of function for functions that return struct.

I guess dbr must find a REG_DEAD note for %r28.

Dave


-- 


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

[Bug rtl-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled on hppa2.0w-hp-hpux11.11

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-12-11 10:02:49         |2007-12-13 08:20:27
               date|                            |


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

[Bug rtl-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled on hppa2.0w-hp-hpux11.11

[jakub at gcc dot gnu dot org]

------- Comment #37 from jakub at gcc dot gnu dot org  2007-12-13 19:05 -------
Subject: Bug 32636

Author: jakub
Date: Thu Dec 13 19:05:37 2007
New Revision: 130907

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130907
Log:
        PR rtl-optimization/32636
        * df-scan.c (df_get_entry_block_def_set): Set struct_value_rtx
        regno in entry_block_defs even if HAVE_prologue && epilogue_completed.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/df-scan.c


-- 


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

[Bug rtl-optimization/32636] [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled on hppa2.0w-hp-hpux11.11

[jakub at gcc dot gnu dot org]

------- Comment #38 from jakub at gcc dot gnu dot org  2007-12-13 19:07 -------
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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