public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? @ 2005-02-08 10:42 ctsa at u dot washington dot edu 2005-02-08 12:00 ` [Bug c++/19813] " ctsa at u dot washington dot edu ` (15 more replies) 0 siblings, 16 replies; 17+ messages in thread From: ctsa at u dot washington dot edu @ 2005-02-08 10:42 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c++/19813] gcc 4.0 regression: bad code generation?? due to inlining?? 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu @ 2005-02-08 12:00 ` ctsa at u dot washington dot edu 2005-02-08 13:24 ` [Bug regression/19813] [4.0 Regression] " pinskia at gcc dot gnu dot org ` (14 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: ctsa at u dot washington dot edu @ 2005-02-08 12:00 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/19813] [4.0 Regression] gcc 4.0 regression: bad code generation?? due to inlining?? 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu 2005-02-08 12:00 ` [Bug c++/19813] " ctsa at u dot washington dot edu @ 2005-02-08 13:24 ` pinskia at gcc dot gnu dot org 2005-02-08 13:27 ` pinskia at gcc dot gnu dot org ` (13 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: pinskia at gcc dot gnu dot org @ 2005-02-08 13:24 UTC (permalink / raw) To: gcc-bugs -- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/19813] [4.0 Regression] gcc 4.0 regression: bad code generation?? due to inlining?? 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu 2005-02-08 12:00 ` [Bug c++/19813] " ctsa at u dot washington dot edu 2005-02-08 13:24 ` [Bug regression/19813] [4.0 Regression] " pinskia at gcc dot gnu dot org @ 2005-02-08 13:27 ` pinskia at gcc dot gnu dot org 2005-02-09 4:11 ` neroden at gcc dot gnu dot org ` (12 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: pinskia at gcc dot gnu dot org @ 2005-02-08 13:27 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/19813] [4.0 Regression] gcc 4.0 regression: bad code generation?? due to inlining?? 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu ` (2 preceding siblings ...) 2005-02-08 13:27 ` pinskia at gcc dot gnu dot org @ 2005-02-09 4:11 ` neroden at gcc dot gnu dot org 2005-02-09 6:42 ` bangerth at dealii dot org ` (11 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: neroden at gcc dot gnu dot org @ 2005-02-09 4:11 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/19813] [4.0 Regression] gcc 4.0 regression: bad code generation?? due to inlining?? 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu ` (3 preceding siblings ...) 2005-02-09 4:11 ` neroden at gcc dot gnu dot org @ 2005-02-09 6:42 ` bangerth at dealii dot org 2005-02-09 6:51 ` [Bug regression/19813] [4.0 Regression] wrong code with -finline-limit bangerth at dealii dot org ` (10 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: bangerth at dealii dot org @ 2005-02-09 6:42 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/19813] [4.0 Regression] wrong code with -finline-limit 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu ` (4 preceding siblings ...) 2005-02-09 6:42 ` bangerth at dealii dot org @ 2005-02-09 6:51 ` bangerth at dealii dot org 2005-02-09 8:51 ` pinskia at gcc dot gnu dot org ` (9 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: bangerth at dealii dot org @ 2005-02-09 6:51 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/19813] [4.0 Regression] wrong code with -finline-limit 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu ` (5 preceding siblings ...) 2005-02-09 6:51 ` [Bug regression/19813] [4.0 Regression] wrong code with -finline-limit bangerth at dealii dot org @ 2005-02-09 8:51 ` pinskia at gcc dot gnu dot org 2005-02-09 9:19 ` pinskia at gcc dot gnu dot org ` (8 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: pinskia at gcc dot gnu dot org @ 2005-02-09 8:51 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/19813] [4.0 Regression] wrong code with -finline-limit 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu ` (6 preceding siblings ...) 2005-02-09 8:51 ` pinskia at gcc dot gnu dot org @ 2005-02-09 9:19 ` pinskia at gcc dot gnu dot org 2005-02-15 21:09 ` jakub at gcc dot gnu dot org ` (7 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: pinskia at gcc dot gnu dot org @ 2005-02-09 9:19 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/19813] [4.0 Regression] wrong code with -finline-limit 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu ` (7 preceding siblings ...) 2005-02-09 9:19 ` pinskia at gcc dot gnu dot org @ 2005-02-15 21:09 ` jakub at gcc dot gnu dot org 2005-02-15 21:15 ` jakub at gcc dot gnu dot org ` (6 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: jakub at gcc dot gnu dot org @ 2005-02-15 21:09 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/19813] [4.0 Regression] wrong code with -finline-limit 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu ` (8 preceding siblings ...) 2005-02-15 21:09 ` jakub at gcc dot gnu dot org @ 2005-02-15 21:15 ` jakub at gcc dot gnu dot org 2005-02-15 21:18 ` jakub at gcc dot gnu dot org ` (5 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: jakub at gcc dot gnu dot org @ 2005-02-15 21:15 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/19813] [4.0 Regression] wrong code with -finline-limit 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu ` (9 preceding siblings ...) 2005-02-15 21:15 ` jakub at gcc dot gnu dot org @ 2005-02-15 21:18 ` jakub at gcc dot gnu dot org 2005-02-15 21:20 ` jakub at gcc dot gnu dot org ` (4 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: jakub at gcc dot gnu dot org @ 2005-02-15 21:18 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/19813] [4.0 Regression] wrong code with -finline-limit 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu ` (10 preceding siblings ...) 2005-02-15 21:18 ` jakub at gcc dot gnu dot org @ 2005-02-15 21:20 ` jakub at gcc dot gnu dot org 2005-02-15 21:46 ` [Bug c++/19813] " rth at gcc dot gnu dot org ` (3 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: jakub at gcc dot gnu dot org @ 2005-02-15 21:20 UTC (permalink / raw) To: gcc-bugs -- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c++/19813] [4.0 Regression] wrong code with -finline-limit 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu ` (11 preceding siblings ...) 2005-02-15 21:20 ` jakub at gcc dot gnu dot org @ 2005-02-15 21:46 ` rth at gcc dot gnu dot org 2005-02-16 16:59 ` jakub at gcc dot gnu dot org ` (2 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: rth at gcc dot gnu dot org @ 2005-02-15 21:46 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c++/19813] [4.0 Regression] wrong code with -finline-limit 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu ` (12 preceding siblings ...) 2005-02-15 21:46 ` [Bug c++/19813] " rth at gcc dot gnu dot org @ 2005-02-16 16:59 ` jakub at gcc dot gnu dot org 2005-02-18 16:16 ` cvs-commit at gcc dot gnu dot org 2005-02-18 16:27 ` jakub at gcc dot gnu dot org 15 siblings, 0 replies; 17+ messages in thread From: jakub at gcc dot gnu dot org @ 2005-02-16 16:59 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c++/19813] [4.0 Regression] wrong code with -finline-limit 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu ` (13 preceding siblings ...) 2005-02-16 16:59 ` jakub at gcc dot gnu dot org @ 2005-02-18 16:16 ` cvs-commit at gcc dot gnu dot org 2005-02-18 16:27 ` jakub at gcc dot gnu dot org 15 siblings, 0 replies; 17+ messages in thread From: cvs-commit at gcc dot gnu dot org @ 2005-02-18 16:16 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c++/19813] [4.0 Regression] wrong code with -finline-limit 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu ` (14 preceding siblings ...) 2005-02-18 16:16 ` cvs-commit at gcc dot gnu dot org @ 2005-02-18 16:27 ` jakub at gcc dot gnu dot org 15 siblings, 0 replies; 17+ messages in thread From: jakub at gcc dot gnu dot org @ 2005-02-18 16:27 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2005-02-18 8:38 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-02-08 10:42 [Bug c++/19813] New: gcc 4.0 regression: bad code generation?? due to inlining?? ctsa at u dot washington dot edu 2005-02-08 12:00 ` [Bug c++/19813] " ctsa at u dot washington dot edu 2005-02-08 13:24 ` [Bug regression/19813] [4.0 Regression] " pinskia at gcc dot gnu dot org 2005-02-08 13:27 ` pinskia at gcc dot gnu dot org 2005-02-09 4:11 ` neroden at gcc dot gnu dot org 2005-02-09 6:42 ` bangerth at dealii dot org 2005-02-09 6:51 ` [Bug regression/19813] [4.0 Regression] wrong code with -finline-limit bangerth at dealii dot org 2005-02-09 8:51 ` pinskia at gcc dot gnu dot org 2005-02-09 9:19 ` pinskia at gcc dot gnu dot org 2005-02-15 21:09 ` jakub at gcc dot gnu dot org 2005-02-15 21:15 ` jakub at gcc dot gnu dot org 2005-02-15 21:18 ` jakub at gcc dot gnu dot org 2005-02-15 21:20 ` jakub at gcc dot gnu dot org 2005-02-15 21:46 ` [Bug c++/19813] " rth at gcc dot gnu dot org 2005-02-16 16:59 ` jakub at gcc dot gnu dot org 2005-02-18 16:16 ` cvs-commit at gcc dot gnu dot org 2005-02-18 16:27 ` jakub at gcc dot gnu dot org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).