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).