[Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining??

[Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining??

[ctsa at u dot washington dot edu]

I'm getting a segfault on what I believe to be valid code using gcc 4.0 but not
when using gcc 3.4 or 3.3. I've reduced this situation down to a relatively
short testcase file, details follow.

testcase.cc:
"""
#include <cstring>
#include <map>
#include <utility>

using namespace std;

struct ltstr
{
  bool operator()(const char* s1, const char* s2) const
  {
    return strcmp(s1, s2) < 0;
  }
};


char codon_trans_known(const char*c){
  typedef map<const char*,char,ltstr> lup_map;

  const static pair<const char*,char> tab_tmp[] = {
   
make_pair("TTT",'F'),make_pair("TCT",'S'),make_pair("TAT",'Y'),make_pair("TGT",'C'),
   
make_pair("TTC",'F'),make_pair("TCC",'S'),make_pair("TAC",'Y'),make_pair("TGC",'C'),
   
make_pair("TTA",'L'),make_pair("TCA",'S'),make_pair("TAA",'*'),make_pair("TGA",'*'),
   
make_pair("TTG",'L'),make_pair("TCG",'S'),make_pair("TAG",'*'),make_pair("TGG",'W'),

   
make_pair("CTT",'L'),make_pair("CCT",'P'),make_pair("CAT",'H'),make_pair("CGT",'R'),
   
make_pair("CTC",'L'),make_pair("CCC",'P'),make_pair("CAC",'H'),make_pair("CGC",'R'),
   
make_pair("CTA",'L'),make_pair("CCA",'P'),make_pair("CAA",'Q'),make_pair("CGA",'R'),
   
make_pair("CTG",'L'),make_pair("CCG",'P'),make_pair("CAG",'Q'),make_pair("CGG",'R'),

   
make_pair("ATT",'I'),make_pair("ACT",'T'),make_pair("AAT",'N'),make_pair("AGT",'S'),
   
make_pair("ATC",'I'),make_pair("ACC",'T'),make_pair("AAC",'N'),make_pair("AGC",'S'),
   
make_pair("ATA",'I'),make_pair("ACA",'T'),make_pair("AAA",'K'),make_pair("AGA",'R'),
   
make_pair("ATG",'M'),make_pair("ACG",'T'),make_pair("AAG",'K'),make_pair("AGG",'R'),

   
make_pair("GTT",'V'),make_pair("GCT",'A'),make_pair("GAT",'D'),make_pair("GGT",'G'),
   
make_pair("GTC",'V'),make_pair("GCC",'A'),make_pair("GAC",'D'),make_pair("GGC",'G'),
   
make_pair("GTA",'V'),make_pair("GCA",'A'),make_pair("GAA",'E'),make_pair("GGA",'G'),
   
make_pair("GTG",'V'),make_pair("GCG",'A'),make_pair("GAG",'E'),make_pair("GGG",'G')};

  const static int tsize = sizeof(tab_tmp)/sizeof(tab_tmp[0]);

  const static lup_map codon_table1(tab_tmp,tab_tmp+tsize);

  lup_map::const_iterator s=codon_table1.find(c);
  if( s != codon_table1.end() ){
    return s->second;
  } else {
    return 'X';
  }
}


main(){
  char a = codon_trans_known("AAA");
}
"""

when I build with the following optimizations:
g++ -O2 -finline-functions -finline-limit=604 testcase.cc

...I get a segfault with any value of inline-limit =< 604 . This only occurs
with -O2 or -O3, so I haven't been able to get a meaningful backtrace either.
All I can tell is that an invalid char pointer has been passed to the strcmp
call in ltstr.


I'm using this week's gcc snapshot:

$ gcc -v
Using built-in specs.
Configured with: /home/ctsa/tmp/gcc-4.0-20050130/configure --disable-checking
--prefix=/home/ctsa/opt/i686-linux/gcc-4.0-20050130 --enable-concept-checks
--enable-languages=c,c++ --enable-__cxa_atexit
Thread model: posix
gcc version 4.0.0 20050130 (experimental)

I've also observed this problem with last week's snapshot build of 4.0
(20050123), but cannot replicate this with 3.4.3 or 3.3.5

-- 
           Summary: gcc 4.0 regression: bad code generation?? due to
                    inlining??
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ctsa at u dot washington dot edu
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/19813] gcc 4.0 regression: bad code generation?? due to inlining??

[ctsa at u dot washington dot edu]

------- Additional Comments From ctsa at u dot washington dot edu  2005-02-07 23:12 -------
(In reply to comment #0)
> I'm getting a segfault on what I believe to be valid code using gcc 4.0 but not
> when using gcc 3.4 or 3.3. I've reduced this situation down to a relatively
> short testcase file, details follow.
> 
> testcase.cc:
> """
> #include <cstring>
> #include <map>
> #include <utility>
> 
> using namespace std;
> 
> struct ltstr
> {
>   bool operator()(const char* s1, const char* s2) const
>   {
>     return strcmp(s1, s2) < 0;
>   }
> };
> 
> 
> char codon_trans_known(const char*c){
>   typedef map<const char*,char,ltstr> lup_map;
> 
>   const static pair<const char*,char> tab_tmp[] = {
>    
>
make_pair("TTT",'F'),make_pair("TCT",'S'),make_pair("TAT",'Y'),make_pair("TGT",'C'),
>    
>
make_pair("TTC",'F'),make_pair("TCC",'S'),make_pair("TAC",'Y'),make_pair("TGC",'C'),
>    
>
make_pair("TTA",'L'),make_pair("TCA",'S'),make_pair("TAA",'*'),make_pair("TGA",'*'),
>    
>
make_pair("TTG",'L'),make_pair("TCG",'S'),make_pair("TAG",'*'),make_pair("TGG",'W'),
> 
>    
>
make_pair("CTT",'L'),make_pair("CCT",'P'),make_pair("CAT",'H'),make_pair("CGT",'R'),
>    
>
make_pair("CTC",'L'),make_pair("CCC",'P'),make_pair("CAC",'H'),make_pair("CGC",'R'),
>    
>
make_pair("CTA",'L'),make_pair("CCA",'P'),make_pair("CAA",'Q'),make_pair("CGA",'R'),
>    
>
make_pair("CTG",'L'),make_pair("CCG",'P'),make_pair("CAG",'Q'),make_pair("CGG",'R'),
> 
>    
>
make_pair("ATT",'I'),make_pair("ACT",'T'),make_pair("AAT",'N'),make_pair("AGT",'S'),
>    
>
make_pair("ATC",'I'),make_pair("ACC",'T'),make_pair("AAC",'N'),make_pair("AGC",'S'),
>    
>
make_pair("ATA",'I'),make_pair("ACA",'T'),make_pair("AAA",'K'),make_pair("AGA",'R'),
>    
>
make_pair("ATG",'M'),make_pair("ACG",'T'),make_pair("AAG",'K'),make_pair("AGG",'R'),
> 
>    
>
make_pair("GTT",'V'),make_pair("GCT",'A'),make_pair("GAT",'D'),make_pair("GGT",'G'),
>    
>
make_pair("GTC",'V'),make_pair("GCC",'A'),make_pair("GAC",'D'),make_pair("GGC",'G'),
>    
>
make_pair("GTA",'V'),make_pair("GCA",'A'),make_pair("GAA",'E'),make_pair("GGA",'G'),
>    
>
make_pair("GTG",'V'),make_pair("GCG",'A'),make_pair("GAG",'E'),make_pair("GGG",'G')};
> 
>   const static int tsize = sizeof(tab_tmp)/sizeof(tab_tmp[0]);
> 
>   const static lup_map codon_table1(tab_tmp,tab_tmp+tsize);
> 
>   lup_map::const_iterator s=codon_table1.find(c);
>   if( s != codon_table1.end() ){
>     return s->second;
>   } else {
>     return 'X';
>   }
> }
> 
> 
> main(){
>   char a = codon_trans_known("AAA");
> }
> """
> 
> when I build with the following optimizations:
> g++ -O2 -finline-functions -finline-limit=604 testcase.cc
> 
> ...I get a segfault with any value of inline-limit =< 604 . This only occurs
> with -O2 or -O3, so I haven't been able to get a meaningful backtrace either.
> All I can tell is that an invalid char pointer has been passed to the strcmp
> call in ltstr.
> 
> 
> I'm using this week's gcc snapshot:
> 
> $ gcc -v
> Using built-in specs.
> Configured with: /home/ctsa/tmp/gcc-4.0-20050130/configure --disable-checking
> --prefix=/home/ctsa/opt/i686-linux/gcc-4.0-20050130 --enable-concept-checks
> --enable-languages=c,c++ --enable-__cxa_atexit
> Thread model: posix
> gcc version 4.0.0 20050130 (experimental)
> 
> I've also observed this problem with last week's snapshot build of 4.0
> (20050123), but cannot replicate this with 3.4.3 or 3.3.5



Note that that's any value for inline-limit equal to or GREATER than 604.

-- 


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

[Bug regression/19813] [4.0 Regression] gcc 4.0 regression: bad code generation?? due to inlining??

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |regression
           Keywords|                            |wrong-code
            Summary|gcc 4.0 regression: bad code|[4.0 Regression] gcc 4.0
                   |generation?? due to         |regression: bad code
                   |inlining??                  |generation?? due to
                   |                            |inlining??
   Target Milestone|---                         |4.0.0


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

[Bug regression/19813] [4.0 Regression] gcc 4.0 regression: bad code generation?? due to inlining??

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-07 23:16 -------
*** Bug 19814 has been marked as a duplicate of this bug. ***

-- 


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

[Bug regression/19813] [4.0 Regression] gcc 4.0 regression: bad code generation?? due to inlining??

[neroden at gcc dot gnu dot org]

------- Additional Comments From neroden at gcc dot gnu dot org  2005-02-08 18:58 -------
Isn't this most likely to be an out-of-memory issue? 

-- 


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

[Bug regression/19813] [4.0 Regression] gcc 4.0 regression: bad code generation?? due to inlining??

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-02-08 19:58 -------
I can confirm this: 
 
tmp/xxx> c++ x.cc 
tmp/xxx> ./a.out 
tmp/xxx> c++ x.cc -O2 -finline-functions -finline-limit=604 
tmp/xxx> ./a.out 
Segmentation fault 
 
tmp/xxx> c++ -v 
Using built-in specs. 
Target: i686-pc-linux-gnu 
Configured with: ../gcc/configure --enable-languages=c,c++ 
--prefix=/ticam/bangerth/tmp/build-gcc/gcc-install --enable-checking 
Thread model: posix 
gcc version 4.0.0 20050203 (experimental) 
 
I'll try to find a shorter testcase. 
 
W. 

-- 


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

[Bug regression/19813] [4.0 Regression] wrong code with -finline-limit

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-02-08 20:13 -------
This is somewhat shorter, though maybe not much: 
-------------------- 
#include <cstring> 
#include <set> 
 
struct ltstr { 
    bool operator()(const char* s1, const char* s2) const 
      { return strcmp(s1, s2) < 0; } 
}; 
 
 
int main(){ 
  char* tab_tmp[2] = { "1", "2"}; 
 
  const static std::set<const char*,ltstr> 
    codon_table1 (tab_tmp, tab_tmp+2); 
 
  *codon_table1.find("1"); 
} 
----------------------- 
 
tmp/xxx> c++ x.cc -O2 -finline-functions -finline-limit=603 && ./a.out 
tmp/xxx> c++ x.cc -O2 -finline-functions -finline-limit=604 && ./a.out 
Segmentation fault 
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
      Known to fail|                            |4.0.0
   Last reconfirmed|0000-00-00 00:00:00         |2005-02-08 20:13:47
               date|                            |
            Summary|[4.0 Regression] gcc 4.0    |[4.0 Regression] wrong code
                   |regression: bad code        |with -finline-limit
                   |generation?? due to         |
                   |inlining??                  |


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

[Bug regression/19813] [4.0 Regression] wrong code with -finline-limit

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-09 00:48 -------
(In reply to comment #5)
> This is somewhat shorter, though maybe not much: 

Does -fno-strict-aliasing make this compile and run correctly?


-- 


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

[Bug regression/19813] [4.0 Regression] wrong code with -finline-limit

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-09 00:51 -------
(In reply to comment #6)
> (In reply to comment #5)
> > This is somewhat shorter, though maybe not much: 
> 
> Does -fno-strict-aliasing make this compile and run correctly?

Because if it does then this is not tree optimization problem because the tree dumps look the same 
with and without -fno-strict-aliasing.  This would then either be a RTL, a C++ or a libstdc++ problem, 
I don't know which yet.

-- 


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

[Bug regression/19813] [4.0 Regression] wrong code with -finline-limit

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-02-15 14:14 -------
The bug is present even with -O2 -finline-functions -finline-limit=604
-fno-strict-aliasing.
strcmp is passed main::b._M_t._M_impl._M_node_count
as one of its arguments.
Looking into it.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2005-02-08 20:13:47         |2005-02-15 14:14:03
               date|                            |


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

[Bug regression/19813] [4.0 Regression] wrong code with -finline-limit

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-02-15 15:53 -------
The bug is the infamous RTX_UNCHANGING_P, apparently still not dead.
Well, now under the MEM_READONLY_P name.

The problem is that set_mem_attributes_minus_bitpos:

1532          tree base = get_base_address (t);
1533          if (base && DECL_P (base)
1534              && TREE_READONLY (base)
1535              && (TREE_STATIC (base) || DECL_EXTERNAL (base)))
1536            MEM_READONLY_P (ref) = 1;

marks as MEM_READONLY_P even something that definitely is not readonly
in the sense now documented in rtl.texi.
main::b is TREE_READONLY, TREE_STATIC, but also e.g. TYPE_NEEDS_CONSTRUCTING.
This variable is initialized to all zeros and then constructed
(several fields to 0 which perhaps could be optimized out) and
main::b._M_t._M_impl._M_header._M_left plus
main::b._M_t._M_impl._M_header._M_right initially to &main::b._M_t.
Then insert_unique is called 2 times to add fields to it.
But because of the MEM_READONLY_P flag the RTL optimizers
just assume that because it was initially set as
main::b._M_t._M_impl._M_header._M_right = &main::b._M_t;
then it will always have that value, so
  struct _Rb_tree_node_base * D.14743;
  D.14743 = b._M_t._M_impl._M_header._M_right;
  if (strcmp (*&((struct _Rb_tree_node<const char*> *) D.14743)->_M_value_field,
D.14710) >= 0) goto <L39>; else goto <L40>;
is mis-optimized into
strcmp (main::b._M_t._M_impl._M_node_count, something);
(_M_value_field is in the same position in _RB_tree_node's as in
_M_node_count in _Rb_tree).

Now, I wonder if we want a target hook here that will be called in
addition to the above checks for MEM_READONLY_P setting and if so, what
exact C++ classes with non-trivial constructors are guaranteed to not
modify memory after relocation processing.


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


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

[Bug regression/19813] [4.0 Regression] wrong code with -finline-limit

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-02-15 15:55 -------
s/target hook/langhook/.

-- 


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

[Bug regression/19813] [4.0 Regression] wrong code with -finline-limit

[jakub at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|nobody at gcc dot gnu dot   |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug c++/19813] [4.0 Regression] wrong code with -finline-limit

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-02-15 17:24 -------
The front end isn't supposed to set TREE_READONLY for variables that need
constructing at runtime.  That's been the way we've handled this case from
day one.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|regression                  |c++


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

[Bug c++/19813] [4.0 Regression] wrong code with -finline-limit

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-02-16 12:31 -------
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00923.html>

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
           Keywords|                            |patch
   Last reconfirmed|2005-02-15 14:14:03         |2005-02-16 12:31:53
               date|                            |


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

[Bug c++/19813] [4.0 Regression] wrong code with -finline-limit

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-18 06:58 -------
Subject: Bug 19813

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	jakub@gcc.gnu.org	2005-02-18 06:58:40

Modified files:
	gcc            : ChangeLog emit-rtl.c 
	gcc/cp         : ChangeLog 

Log message:
	PR c++/19813
	* emit-rtl.c (set_mem_attributes_minus_bitpos): Add assertion
	that ref to be marked MEM_READONLY_P doesn't have base that needs
	constructing.
	
	* decl.c (start_decl_1): Clear TREE_READONLY flag if
	its type has TYPE_NEEDS_CONSTRUCTING.
	(complete_vars): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7520&r2=2.7521
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/emit-rtl.c.diff?cvsroot=gcc&r1=1.433&r2=1.434
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4633&r2=1.4634



-- 


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

[Bug c++/19813] [4.0 Regression] wrong code with -finline-limit

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-02-18 08:37 -------
Fixed.

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


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