[Bug c++/37922] New: code generation error

[Bug c++/37922] New: code generation error

[rwgk at yahoo dot com]

Platform:
  Fedora release 8 (Werewolf)
  Linux chevy.lbl.gov 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008
x86_64 x86_64 x86_64 GNU/Linux

% g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /net/chevy/raid1/rwgk/gcc_trunk/configure
--prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_141361_fc8_x86_64
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.4.0 20081025 (experimental) (GCC) 


Problematic C++ code fragment:

    rot_mx proper_r = r;
    int proper_order = type_;
    if (proper_order < 0) {
      std::cout << "A branch" << std::endl;
      proper_order *= -1;
      proper_r = -proper_r;
    }
    if (proper_order > 1) {
      std::cout << "B branch" << std::endl;
      ...
    }

Compiled with (just to show optimization options; please ignore the rest):

g++ -o cctbx/sgtbx/rot_mx_info.o -c -fno-strict-aliasing -fPIC
-ftemplate-depth-120 -w -DNDEBUG -O3 -ffast-math -fno-associative-math
-ftrapping-math -DBOOST_DISABLE_THREADS -fopenmp -Iinclude
-I/net/chevy/raid1/rwgk/hot/include -I/net/chevy/raid1/rwgk/as_in_cvs/include
"-I/net/chevy/raid1/rwgk/hot/b u f/include" -I/net/chevy/raid1/rwgk/as_in_cvs
-I/net/chevy/raid1/rwgk/hot/boost
/net/chevy/raid1/rwgk/as_in_cvs/cctbx/sgtbx/rot_mx_info.cpp

Given type_ = -2, the print statements should show

A branch
B branch

but only "B branch" is actually shown.

I can work around this problem either by compiling without optimizations, or by
replacing the code above with:

    rot_mx proper_r;
    int proper_order;
    if (type_ < 0) {
      std::cout << "A branch" << std::endl;
      proper_order = -type_;
      proper_r = -r;
    }
    else {
      std::cout << "A else branch" << std::endl;
      proper_order = type_;
      proper_r = r;
    }
    if (proper_order > 1) {
      std::cout << "B branch" << std::endl;
      ...
    }


I tried to reduce the problem, but it turns out to be tricky. The code above is
part of a shared library (.so). Simply moving it into the same translation unit
as the calling code makes the error go away.

Before I spend more time on this, does the problem look familiar? (I.e. could
it be that this bug was reported already?)

I could give you a self-contained but very large reproducer. This would enable
you to inspect the generated code, and maybe give us a clue how to construct a
minimal reproducer.


-- 
           Summary: code generation error
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rwgk at yahoo dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/37922] code generation error

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-10-27 00:18 -------
With out a testcase, it is hard to tell if it was reported before or not.  Also
does -fwrapv allows for the code to work?

what type is rot_mx?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug c++/37922] code generation error

[rwgk at yahoo dot com]

------- Comment #2 from rwgk at yahoo dot com  2008-10-27 02:18 -------
(In reply to comment #1)
> With out a testcase, it is hard to tell if it was reported before or not.  Also
> does -fwrapv allows for the code to work?

Yes!

(FWIW: -ftrapv doesn't help.)

> what type is rot_mx?

A user-defined type with an array of nine int plus another separate int.
The whole thing is here:

 
http://cctbx.svn.sourceforge.net/viewvc/cctbx/trunk/cctbx/sgtbx/rot_mx.h?view=markup

Let me know if you have an interested in the large but self-contained
reproducer. You'd have to get one file, run one command to build everything
(takes a few minutes), then one command to demonstrate the problem. The
reproducer is a simple main().


-- 


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

[Bug c++/37922] code generation error

[rwgk at yahoo dot com]

------- Comment #3 from rwgk at yahoo dot com  2008-12-07 07:34 -------
Created an attachment (id=16844)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16844&action=view)
reproducer, no dependencies, no includes


-- 


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

[Bug c++/37922] code generation error

[rwgk at yahoo dot com]

------- Comment #4 from rwgk at yahoo dot com  2008-12-07 07:44 -------
Testing with:
  g++ (GCC) 4.4.0 20081206 (experimental)
  svn revision 142514

pr37922repro1.cpp should always exit with status 0.
However, it fails this test when compiling with -O3 and -O2:

g++ -Wall -fPIC -O3 pr37922repro1.cpp
./a.out ; echo $status
2
g++ -Wall -fPIC -O2 pr37922repro1.cpp
./a.out ; echo $status
2
g++ -Wall -fPIC -O1 pr37922repro1.cpp
./a.out ; echo $status
0
g++ -Wall -fPIC -O0 pr37922repro1.cpp
./a.out ; echo $status
0


The -fPIC is critical.

The problem region in the reproducer is marked with comments:

    // THE PROBLEM IS AROUND HERE
    if (proper_order < 0) {
      proper_order *= -1;
      proper_r = -proper_r; // THIS FAILS ...
    }
    if (proper_order > 1) {
      rot_mx rmi = proper_r.minus_unit_mx(); // ... THEREFORE WRONG HERE


Sorry it is still 556 lines long, but I already spent 2 1/2 hours
reducing it this far. At least, it is completely self-contained and
compiles in fractions of a second.


-- 


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

[Bug c++/37922] code generation error

[rwgk at yahoo dot com]

------- Comment #5 from rwgk at yahoo dot com  2008-12-13 22:09 -------
The bug is still present in svn revsion 140355 from last night.

I ran an automatic search through the svn history. The result is that
revision 129269 (svn log below) introduced the bug.

Could someone please confirm the bug with the reproducer I posted
last weekend? It should only take a second.


------------------------------------------------------------------------
r129269 | rsandifo | 2007-10-12 09:54:38 -0700 (Fri, 12 Oct 2007) | 14 lines

gcc/
        * dse.c (find_shift_sequence): Reinstate "<= UNITS_PER_WORD" condition.
        * var-tracking.c (micro_operation_def): Update comment on u.loc.
        (mode_for_reg_attrs, var_lowpart): New functions.
        (add_uses): Consider recording a lowpart of LOC for MO_USE.
        (add_stores): Likewise MO_SET and MO_COPY.  If the source of a set
        or copy is known, set LOC to the SET that performs the set, instead
        of the destination.
        (find_src_status, find_src_set_src): Remove LOC parameter.
        Replace INSN with the source value.
        (compute_bb_dataflow, emit_notes_in_bb): Check for a SET u.loc when
        handling MO_SET and MO_COPY.  Update the calls to find_src_status
        and find_src_set_src.

------------------------------------------------------------------------


-- 


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

[Bug c++/37922] [4.4 Regression] code generation error

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2008-12-16 00:08 -------
Does -fno-strict-aliasing work?


-- 


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

[Bug c++/37922] [4.4 Regression] code generation error

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|code generation error       |[4.4 Regression] code
                   |                            |generation error
   Target Milestone|---                         |4.4.0


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

[Bug c++/37922] [4.4 Regression] code generation error

[rwgk at yahoo dot com]

------- Comment #7 from rwgk at yahoo dot com  2008-12-16 02:17 -------
(In reply to comment #6)
> Does -fno-strict-aliasing work?
> 

Nope. I just tried it with svn revisions 129269 and 142737.
Adding -fno-strict-aliasing does not change the (wrong) result.

Thanks for looking at this!


-- 


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

[Bug c++/37922] [4.4 Regression] code generation error

[hjl dot tools at gmail dot com]

------- Comment #8 from hjl dot tools at gmail dot com  2008-12-16 04:01 -------
Gcc 4.3 20080428 behaves the same. -m32 returns 0.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl dot tools at gmail dot
                   |                            |com


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

[Bug c++/37922] [4.4 Regression] code generation error

[jakub at gcc dot gnu dot org]

------- Comment #9 from jakub at gcc dot gnu dot org  2008-12-16 12:08 -------
Indeed, -O2 -fpic returns 2, -O2 -fpic -fno-dse returns 0.  The difference
between the two are just 4 successful replace_read changes, like:
        movq    %rdx, 224(%rsp) # D.4704, proper_r
-       shrq    $32, %rdx       #, proper_r$den_
+       movl    228(%rsp), %edx # proper_r.den_, proper_r$den_
(- is without -fno-dse, + is with -fno-dse).  These look good, unless the
original %rdx is needed somewhere else.  I'll try to debug this.


-- 


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

[Bug c++/37922] [4.4 Regression] code generation error

[jakub at gcc dot gnu dot org]

------- Comment #10 from jakub at gcc dot gnu dot org  2008-12-16 12:48 -------
Created an attachment (id=16912)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16912&action=view)
pr37922.C

Testcase with a bunch of unneeded namespaces removed.


-- 


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

[Bug c++/37922] [4.4 Regression] code generation error

[jakub at gcc dot gnu dot org]

------- Comment #11 from jakub at gcc dot gnu dot org  2008-12-16 13:09 -------
The problem is that CSE2 extends the live range of CC register, so before DSE1
we have in _ZN11rot_mx_infoC1ERK6rot_mx function:
(insn 15 14 16 2 pr37922.C:469 (set (reg:CC 17 flags)
        (compare:CC (reg/v:SI 75 [ proper_order ])
            (const_int 0 [0x0]))) 5 {*cmpsi_1_insn} (nil))

(jump_insn 16 15 17 2 pr37922.C:469 (set (pc)
        (if_then_else (eq (reg:CC 17 flags)
                (const_int 0 [0x0]))
            (label_ref:DI 128)
            (pc))) 618 {*jcc_1} (expr_list:REG_DEAD (reg:CC 17 flags)
        (expr_list:REG_BR_PROB (const_int 3900 [0xf3c])
            (nil))))
...
(insn 28 27 30 3 pr37922.C:472 (set (reg:SI 71 [ proper_r$den_ ])
        (mem/s/c:SI (plus:DI (reg/f:DI 20 frame)
                (const_int -60 [0xffffffffffffffc4])) [7 proper_r.den_+0 S4
A32])) 47 {*movsi_1} (nil))

(jump_insn 30 28 31 3 pr37922.C:475 (set (pc)
        (if_then_else (lt (reg:CC 17 flags)
                (const_int 0 [0x0]))
            (label_ref 35)
            (pc))) 618 {*jcc_1} (expr_list:REG_DEAD (reg:CC 17 flags)
        (expr_list:REG_BR_PROB (const_int 2700 [0xa8c])
            (nil))))

and no insn in between jump_insn 16 and 30 touch the flags register (insn 29
which was comparing (reg:SI 75) and (const_int 0) was eliminated during CSE2).

DSE in 4.3/4.4 then attempts to optimize the store of a 64-bit value in insn 27
followed by 32-bit read from the upper 32-bits of that value in insn 28, but
the
sequence it inserts for it (shift down by 32 bytes) unfortunately clobbers CC
register, but replace_read doesn't check for that.
Also, the REG_DEAD note which wasn't removed during CSE2 looks weird.
I guess in replace_read before calling validate_change we should check if insns
don't clobber or modify any hard registers that are live at that point, but am
not sure if DF is initialized for such kind of query at this point.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zadeck at gcc dot gnu dot
                   |                            |org
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-12-16 13:09:52
               date|                            |


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

[Bug c++/37922] [4.4 Regression] code generation error

[steven at gcc dot gnu dot org]

------- Comment #12 from steven at gcc dot gnu dot org  2008-12-16 13:45 -------
Looks like something along the lines of gcse.c:can_assign_to_reg_p() is called
for here in replace_read.


-- 


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

[Bug c++/37922] [4.4 Regression] code generation error

[jakub at gcc dot gnu dot org]

------- Comment #13 from jakub at gcc dot gnu dot org  2008-12-16 15:05 -------
Not doing this optimization if added_clobbers_hard_reg_p would basically kill
it on i386/x86_64 except for constant values, all the shifts clobber hard
registers.  But typically flags register is only live for very short range
between compare and (usually the next insn) following conditional jump.  Given
how many insns clobber the flags it is very rare to have the setter and user
many insns appart.


-- 


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

[Bug c++/37922] [4.3/4.4 Regression] code generation error

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.0                       |4.3.3
            Version|4.4.0                       |4.3.2


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

[Bug c++/37922] [4.3/4.4 Regression] code generation error

[hjl dot tools at gmail dot com]

------- Comment #14 from hjl dot tools at gmail dot com  2008-12-16 17:18 -------
Here is the original patch which caused this regression:

http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01582.html

Here is the one checked in:

http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00744.html


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|rsandifo at gcc dot gnu dot |rsandifo at nildram dot co
                   |org                         |dot uk


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

[Bug c++/37922] [4.3/4.4 Regression] code generation error

[hjl dot tools at gmail dot com]

------- Comment #15 from hjl dot tools at gmail dot com  2008-12-16 18:41 -------
Is that safe to call find_shift_sequence when CC register is live?


-- 


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

[Bug c++/37922] [4.3/4.4 Regression] code generation error

[zadeck at naturalbridge dot com]

------- Comment #16 from zadeck at naturalbridge dot com  2008-12-16 18:43 -------
and how would you ask that question in a machine independent way?

I am going to find the shift sequence and if it has a set or clobber of any
currently live hard reg, i will reject the sequence.

I am working on a fix now.
kenny


-- 

zadeck at naturalbridge dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |zadeck at naturalbridge dot
                   |dot org                     |com
             Status|NEW                         |ASSIGNED


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

[Bug c++/37922] [4.3/4.4 Regression] code generation error

[hjl dot tools at gmail dot com]

------- Comment #17 from hjl dot tools at gmail dot com  2008-12-17 15:45 -------
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00943.html


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2008-
                   |                            |12/msg00943.html


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

[Bug c++/37922] [4.3/4.4 Regression] code generation error

[rwgk at yahoo dot com]

------- Comment #18 from rwgk at yahoo dot com  2008-12-17 19:01 -------
(In reply to comment #17)
> A patch is posted at
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00943.html
> 

I tried this patch locally and I'm happy to report that it fixes
the original problem.
Thanks!


-- 


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

[Bug c++/37922] [4.3/4.4 Regression] code generation error

[zadeck at gcc dot gnu dot org]

------- Comment #19 from zadeck at gcc dot gnu dot org  2008-12-18 13:40 -------
Subject: Bug 37922

Author: zadeck
Date: Thu Dec 18 13:38:39 2008
New Revision: 142809

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142809
Log:
2008-12-18  Kenneth Zadeck <zadeck@naturalbridge.com>

        PR rtl-optimization/37922
        * dse.c (bb_info): Added regs_live field.
        (look_for_hardregs): New function.
        (replace_read): Added regs_live parameter and code to check that
        shift sequence does not clobber live hardregs.
        (check_mem_read_rtx): Added parameter to replace_read.
        (dse_step1): Added regs_live bitmap and initialize it.
        (rest_of_handle_dse): Added DF_NOTES problem and earlier call to
        df_analyze.
        * df-problems.c Renamed to 
        df_simulate_initialize_backwards.
        (df_simulate_one_insn): Renamed to
        df_simulate_one_insn_backwards.
        (df_simulate_artificial_refs_at_top): Renamed to 
        df_simulate_finalize_backwards.
        (df_simulate_initialized_forwards,
        df_simulate_one_insn_forwards,
        df_simulate_finalize_backwards): New functions.
        * df.h (df_simulate_artificial_refs_at_end): Renamed to 
        df_simulate_initialize_backwards.
        (df_simulate_one_insn): Renamed to
        df_simulate_one_insn_backwards.
        (df_simulate_artificial_refs_at_top): Renamed to 
        df_simulate_finalize_backwards.
        (df_simulate_initialized_forwards,
        df_simulate_one_insn_forwards,
        df_simulate_finalize_backwards): New functions.
        * ra-conflict.c (global_conflicts): Renamed
        df_simulate_artificial_refs_at_end to
        df_simulate_initialize_backwards.
        * sel-sched.c (propagate_lv_set): Renamed df_simulate_one_insn to
        df_simulate_one_insn_backwards.
        * ifcvt.c (dead_or_predicable): Renamed
        df_simulate_artificial_refs_at_end to
        df_simulate_initialize_backwards. Renamed df_simulate_one_insn to
        df_simulate_one_insn_backwards.
        * recog.c (peephole2_optimize): Ditto.
        * rtl-factoring (collect_pattern_seqs, clear_regs_live_in_seq): Ditto.

2008-12-18  Kenneth Zadeck <zadeck@naturalbridge.com>

        PR rtl-optimization/37922
        * g++.dg/torture/pr37922.C: New test.


Added:
    trunk/gcc/testsuite/g++.dg/torture/pr37922.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dce.c
    trunk/gcc/df-problems.c
    trunk/gcc/df.h
    trunk/gcc/dse.c
    trunk/gcc/ifcvt.c
    trunk/gcc/ra-conflict.c
    trunk/gcc/recog.c
    trunk/gcc/rtl-factoring.c
    trunk/gcc/sel-sched.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/37922] [4.3/4.4 Regression] code generation error

[zadeck at naturalbridge dot com]

------- Comment #20 from zadeck at naturalbridge dot com  2008-12-18 14:23 -------
committed patch to fix this.


-- 

zadeck at naturalbridge dot com changed:

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


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

[Bug c++/37922] [4.3/4.4 Regression] code generation error

[hjl dot tools at gmail dot com]

------- Comment #21 from hjl dot tools at gmail dot com  2008-12-18 14:32 -------
It is only fixed on trunk. 4.3 is still broken.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
      Known to fail|                            |4.3.2
      Known to work|                            |4.4.0
         Resolution|FIXED                       |


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

[Bug c++/37922] [4.3 Regression] code generation error

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
           Priority|P3                          |P2


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

[Bug c++/37922] [4.3 Regression] code generation error

[rguenth at gcc dot gnu dot org]

------- Comment #22 from rguenth at gcc dot gnu dot org  2009-01-24 10:20 -------
GCC 4.3.3 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.3                       |4.3.4


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

[Bug c++/37922] [4.3 Regression] code generation error

[rguenth at gcc dot gnu dot org]

------- Comment #23 from rguenth at gcc dot gnu dot org  2009-08-04 12:29 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


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

[Bug rtl-optimization/37922] [4.3 Regression] code generation error

[rguenth at gcc dot gnu dot org]

------- Comment #24 from rguenth at gcc dot gnu dot org  2010-05-22 18:12 -------
GCC 4.3.5 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.5                       |4.3.6


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