Bug 32878 - FAIL: 23_containers/bitset/cons/16020.cc execution test
Summary: FAIL: 23_containers/bitset/cons/16020.cc execution test
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: alias, wrong-code
Depends on:
Blocks:
 
Reported: 2007-07-24 14:48 UTC by John David Anglin
Modified: 2007-10-13 21:40 UTC (History)
4 users (show)

See Also:
Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
Build: hppa-unknown-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2007-07-25 21:58:05


Attachments
16020.ii (49.98 KB, text/plain)
2007-07-24 19:30 UTC, dave
Details
16020.cc.168r.asmcons (4.13 KB, text/plain)
2007-07-25 21:31 UTC, dave
Details
16020.cc.170r.sched1 (5.49 KB, text/plain)
2007-07-25 21:31 UTC, dave
Details
16020.cc.127r.expand (4.01 KB, text/plain)
2007-07-25 21:53 UTC, dave
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John David Anglin 2007-07-24 14:48:20 UTC
Executing on host: /home/dave/gnu/gcc-4.3/objdir/./gcc/g++ -shared-libgcc -B/hom
e/dave/gnu/gcc-4.3/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc-4.3/objdir/hppa
-linux/libstdc++-v3/src -L/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/
src/.libs -B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/ -B/home/dave/opt/gn
u/gcc/gcc-4.3.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-l
inux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/sys-include -g
 -O2 -D_GLIBCXX_ASSERT -ffunction-sections -fdata-sections -fmessage-length=0 -g
 -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gnu/gcc-4.3/objdir/h
ppa-linux/libstdc++-v3/include/hppa-linux -I/home/dave/gnu/gcc-4.3/objdir/hppa-l
inux/libstdc++-v3/include -I/home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/libsupc++ -I
/home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc-4.
3/gcc/libstdc++-v3/testsuite/util -Wl,--gc-sections /home/dave/gnu/gcc-4.3/gcc/l
ibstdc++-v3/testsuite/23_containers/bitset/cons/16020.cc    -include bits/stdc++
.h ./libtestc++.a  -lm   -o ./16020.exe    (timeout = 600)
PASS: 23_containers/bitset/cons/16020.cc (test for excess errors)
Setting LD_LIBRARY_PATH to :/home/dave/gnu/gcc-4.3/objdir/gcc:/home/dave/gnu/gcc
-4.3/objdir/hppa-linux/./libstdc++-v3/src/.libs::/home/dave/gnu/gcc-4.3/objdir/g
cc:/home/dave/gnu/gcc-4.3/objdir/hppa-linux/./libstdc++-v3/src/.libs:/home/dave/
gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/.libs:/home/dave/gnu/gcc-4.3/objdir/h
ppa-linux/libmudflap/.libs:/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libssp/.libs
:/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libgomp/.libs:/home/dave/gnu/gcc-4.3/o
bjdir/./gcc:/home/dave/gnu/gcc-4.3/objdir/./prev-gcc
FAIL: 23_containers/bitset/cons/16020.cc execution test

This fail appeared between 20070715 (revision 126659) and 20070716 (revision 126694).
Comment 1 Paolo Carlini 2007-07-24 15:00:47 UTC
I think there is no reason to categorize as libstdc++: almost nothing changed in the library in that timespan (and definitely nothing related) and, AFAICS, all the other targets are fine. Also, I would suggest adding to the report a miminum of additional info about the failure, for the benefit of interested people not having available an hppa-linux system.
Comment 2 dave 2007-07-24 15:40:50 UTC
Subject: Re:  FAIL: 23_containers/bitset/cons/16020.cc execution test

> I think there is no reason to categorize as libstdc++: almost nothing changed
> in the library in that timespan (and definitely nothing related) and, AFAICS,
> all the other targets are fine. Also, I would suggest adding to the report a
> miminum of additional info about the failure, for the benefit of interested
> people not having available an hppa-linux system.

I'm forced to pick a category when reporting a bug.  The bug occurred
in the libstdc++ testsuite, so I picked that...

Personally, I don't like having to categorize bugs on the initial
report as this tends to assign responsibility.  I avoid picking
"target" as essentially all bugs then become the responsibility
of the target maintainer.  At least 90% of the time, the bug isn't
in the backend but the target maintainer has to do the leg work
to debug and categorize the bug.

On review of the changes in the period, I agree that nothing in
libstdc++ changed in the timespan.  The only GCC change that might
have had an effect is revision 126692.  It's possible that this
failure was introduced by an update to Debian libc6 version 2.6-2.
That could explain why others aren't seeing this problem.  I'm not
seeing the failure on hpux.

I'll provide more info when available.

Dave
Comment 3 John David Anglin 2007-07-24 16:01:20 UTC
The program is segfaulting when compiled at -O2.  It doesn't fail at
-O0 or -O1.  I added -static to make debugging easier.

Starting program: /home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/testsuite/16020.xg

Program received signal SIGSEGV, Segmentation fault.
0x00010450 in __gnu_debug::_Safe_iterator_base::_M_detach_single (
    this=0xc016a081) at ../../../../gcc/libstdc++-v3/src/debug.cc:245
245             if (_M_next)
(gdb) bt
#0  0x00010450 in __gnu_debug::_Safe_iterator_base::_M_detach_single (
    this=0xc016a081) at ../../../../gcc/libstdc++-v3/src/debug.cc:245
#1  0x00010690 in __gnu_debug::_Safe_sequence_base::_M_detach_all (
    this=0xc016ab2c) at ../../../../gcc/libstdc++-v3/src/debug.cc:127
#2  0x0001037c in test01 ()
    at /home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/debug/safe_base.h:185
#3  0x00010408 in main ()
    at /home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/testsuite/23_containers/bitset/cons/16020.cc:40
(gdb) p/x $pc
$1 = 0x10450
(gdb) disass 0x10440 0x10460
Dump of assembler code from 0x10440 to 0x10460:
0x00010440 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+16>:     ldw c(r26),ret0
0x00010444 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+20>:     stw ret0,c(r19)
0x00010448 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+24>:     ldw c(r26),r20
0x0001044c <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+28>:     cmpiclr,= 0,r20,r0
0x00010450 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+32>:     stw r19,8(r20)
0x00010454 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+36>:     ldw 4(r21),ret0
0x00010458 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+40>:     cmpb,=,n r26,ret0,0x10494 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+100>
0x0001045c <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+44>:     ldw 0(r21),ret0
End of assembler dump.
(gdb) p/x $r20
$3 = 0x61736800
Comment 4 John David Anglin 2007-07-24 17:27:37 UTC
(gdb) p _M_iterators
$20 = (__gnu_debug::_Safe_iterator_base *) 0xd4820
(gdb) p *_M_iterators
$21 = {_M_sequence = 0x0, _M_version = 0, _M_prior = 0x0, _M_next = 0x0}
(gdb) p _M_const_iterators
$19 = (__gnu_debug::_Safe_iterator_base *) 0xc06be750
(gdb) p *_M_const_iterators
$18 = {_M_sequence = 0xc06be000, _M_version = 0, _M_prior = 0xc06be049,
  _M_next = 0xc06be081}

It looks like _M_const_iterators may not be properly initialized.
Comment 5 John David Anglin 2007-07-24 19:22:09 UTC
test01 is miscompiled at O2:

(gdb) disass _Z6test01v
Dump of assembler code for function _Z6test01v:
0x0001030c <_Z6test01v+0>:      ldi 7,ret0
0x00010310 <_Z6test01v+4>:      stw rp,-14(sp)
0x00010314 <_Z6test01v+8>:      ldo c0(sp),sp
0x00010318 <_Z6test01v+12>:     ldw -b0(sp),r21
0x0001031c <_Z6test01v+16>:     ldw -ac(sp),r22
0x00010320 <_Z6test01v+20>:     stw ret0,-b8(sp)
0x00010324 <_Z6test01v+24>:     ldi 1,ret0
0x00010328 <_Z6test01v+28>:     ldw -b8(sp),r19
0x0001032c <_Z6test01v+32>:     ldw -b4(sp),r20
0x00010330 <_Z6test01v+36>:     stw ret0,-ac(sp)
0x00010334 <_Z6test01v+40>:     stw r19,-98(sp)
0x00010338 <_Z6test01v+44>:     stw r20,-94(sp)
0x0001033c <_Z6test01v+48>:     ldw -98(sp),ret0
0x00010340 <_Z6test01v+52>:     stw r3,-88(sp)
0x00010344 <_Z6test01v+56>:     stw r0,-b4(sp)
0x00010348 <_Z6test01v+60>:     stw r19,-a8(sp)
0x0001034c <_Z6test01v+64>:     stw r20,-a4(sp)
0x00010350 <_Z6test01v+68>:     stw r21,-a0(sp)
0x00010354 <_Z6test01v+72>:     stw r22,-9c(sp)
0x00010358 <_Z6test01v+76>:     stw r0,-b0(sp)
0x0001035c <_Z6test01v+80>:     stw r21,-90(sp)
0x00010360 <_Z6test01v+84>:     stw r22,-8c(sp)
---Type <return> to continue, or q <return> to quit---
0x00010364 <_Z6test01v+88>:     cmpib,<> 7,ret0,0x1039c <_Z6test01v+144>
0x00010368 <_Z6test01v+92>:     ldw -a8(sp),ret0
0x0001036c <_Z6test01v+96>:     cmpib,<> 7,ret0,0x103bc <_Z6test01v+176>
0x00010370 <_Z6test01v+100>:    ldil L%a6800,r25
0x00010374 <_Z6test01v+104>:    b,l 0x1061c <_ZN11__gnu_debug19_Safe_sequence_base13_M_detach_allEv>,rp
0x00010378 <_Z6test01v+108>:    ldo -94(sp),r26

The order of the ldw at 0x0001032c and the stw at 0x00010344 is
interchanged from what's in the O1 code.  As a result, r20 and the stack
slot at -94(sp) contain garbage.  Also, the ldw instructions at
0x00010318 and 0x0001031c are totally bogus.  Changing this
to a middle-end bug.
Comment 6 dave 2007-07-24 19:30:08 UTC
Subject: Re:  FAIL: 23_containers/bitset/cons/16020.cc execution test

> 0x00010318 and 0x0001031c are totally bogus.  Changing this
> to a middle-end bug.

Here is preprocessed source.

Dave
Comment 7 dave 2007-07-24 19:30:08 UTC
Created attachment 13964 [details]
16020.ii
Comment 8 dave 2007-07-25 21:31:33 UTC
Subject: Re:  FAIL: 23_containers/bitset/cons/16020.cc execution test

The appears to be a problem with the sched passes.  If I compile with
-fno-schedule-insns and -fno-schedule-insns2, the test doesn't fault.

Attached is the rtl from the asmcons and sched1 passes.  It can be
seen that sched1 goes very wrong in moving insn 18 before some of
the initializations for b.

Dave
Comment 9 dave 2007-07-25 21:31:33 UTC
Created attachment 13977 [details]
16020.cc.168r.asmcons
Comment 10 dave 2007-07-25 21:31:33 UTC
Created attachment 13978 [details]
16020.cc.170r.sched1
Comment 11 Andrew Pinski 2007-07-25 21:36:51 UTC
So we have:
(insn 6 5 7 2 /home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bitset:572 (set (mem/s/c:SI (plus:SI (reg/f:SI 3 %r3)
                (const_int 8 [0x8])) [10 b.D.57473.D.57333._M_w+0 S4 A64])
        (reg:SI 94)) 37 {*pa.md:2543} (expr_list:REG_DEAD (reg:SI 94)
        (expr_list:REG_EQUAL (const_int 7 [0x7])
            (nil))))

And:
(insn 16 10 17 2 /home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/testsuite/23_containers/bitset/cons/16020.cc:31 (set (reg:DI 97 [ b ])
        (mem/s/c:DI (plus:SI (reg/f:SI 3 %r3)
                (const_int 8 [0x8])) [88 b+0 S8 A64])) 77 {*pa.md:4550} (nil))

and aliasing sets 88 and 10 but I don't know if they conflict or not.
Comment 12 Andrew Pinski 2007-07-25 21:49:03 UTC
Can you attach the dump of -fdump-rtl-expand-details ?
Comment 13 dave 2007-07-25 21:53:09 UTC
Subject: Re:  FAIL: 23_containers/bitset/cons/16020.cc execution test

> Can you attach the dump of -fdump-rtl-expand-details ?

Attached.

Dave
Comment 14 dave 2007-07-25 21:53:09 UTC
Created attachment 13979 [details]
16020.cc.127r.expand
Comment 15 Paolo Carlini 2007-07-25 21:56:20 UTC
By the way, s390x-linux apparently is also affected...
Comment 16 Andrew Pinski 2007-07-25 21:58:04 UTC
;; b.D.57473.D.57333._M_w = 7
(insn 5 4 6 /home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bitset:572 (set (reg:SI 94)
        (const_int 7 [0x7])) -1 (nil))

(insn 6 5 0 /home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bitset:572 (set (mem/s/c:SI (reg/f:SI 90 virtual-stack-vars) [10 b.D.57473.D.57333._M_w+0 S4 A64])
        (reg:SI 94)) -1 (nil))


;; bb = b
(insn 16 15 17 /home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/testsuite/23_containers/bitset/cons/16020.cc:31 (set (reg:DI 97)
        (mem/s/c:DI (reg/f:SI 90 virtual-stack-vars) [88 b+0 S8 A64])) -1 (nil))

(insn 17 16 18 /home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/testsuite/23_containers/bitset/cons/16020.cc:31 (set (mem/s/c:DI (plus:SI (reg/f:SI 90 virtual-stack-vars)
                (const_int 32 [0x20])) [88 bb+0 S8 A64])
        (reg:DI 97)) -1 (nil))

(insn 18 17 19 /home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/testsuite/23_containers/bitset/cons/16020.cc:31 (set (reg:DI 98)
        (mem/s/c:DI (plus:SI (reg/f:SI 90 virtual-stack-vars)
                (const_int 8 [0x8])) [88 b+8 S8 A64])) -1 (nil))

(insn 19 18 0 /home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/testsuite/23_containers/bitset/cons/16020.cc:31 (set (mem/s/c:DI (plus:SI (reg/f:SI 90 virtual-stack-vars)
                (const_int 40 [0x28])) [88 bb+8 S8 A64])
        (reg:DI 98)) -1 (nil))

So the aliasing set of bitset<5> is 88 and the store for b.D.57473.D.57333._M_w is done in aliasing set 10.  Someone has to debug further if aliasing set 88 is being set up correctly.
Comment 17 dave 2007-07-25 22:07:15 UTC
Subject: Re:  FAIL: 23_containers/bitset/cons/16020.cc execution test

> So the aliasing set of bitset<5> is 88 and the store for b.D.57473.D.57333._M_w
> is done in aliasing set 10.  Someone has to debug further if aliasing set 88 is
> being set up correctly.

Part of the initialization of b is done using set 97.  Only the first
word is done using set 10.

Is there an easy way to check whether these sets are correctly setup?

Dave
Comment 18 dave 2007-07-25 23:34:55 UTC
Subject: Re:  FAIL: 23_containers/bitset/cons/16020.cc execution test

> > So the aliasing set of bitset<5> is 88 and the store for b.D.57473.D.57333._M_w
> > is done in aliasing set 10.  Someone has to debug further if aliasing set 88 is
> > being set up correctly.
> 
> Part of the initialization of b is done using set 97.  Only the first
> word is done using set 10.

In schedule_insns for test01:

(gdb) p alias_sets_conflict_p (10, 88)
$17 = 1
(gdb) p alias_sets_conflict_p (10, 97)
$16 = 0
(gdb) p alias_sets_conflict_p (88, 97)
$15 = 0

Dave
Comment 19 John David Anglin 2007-07-30 20:31:06 UTC
Introduced in revision 126326.
Comment 20 H.J. Lu 2007-07-30 20:41:42 UTC
Is this related to PR32921? Can you try the patch in comment 6:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921#c6

Comment 21 dave 2007-07-31 15:30:14 UTC
Subject: Re:  FAIL: 23_containers/bitset/cons/16020.cc execution test

> ------- Comment #20 from hjl at lucon dot org  2007-07-30 20:41 -------
> Is this related to PR32921? Can you try the patch in comment 6:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921#c6

The patch didn't resolve the problem reported in this PR.

Dave
Comment 22 John David Anglin 2007-10-13 21:40:24 UTC
This test stopped failing at revision 127720.