[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #28 from jason at gcc dot gnu dot org 2010-08-31 17:26 --- (In reply to comment #18) The optimization question in Comment #11 was answered incorrectly. The C++ standard in fact requires that Y be initialized before the constructor is run; see [basic.start.init]. I disagree. In C++03, [basic.start.init] says Objects of POD types (3.9) with static storage duration initialized with constant expressions (5.19) shall be initialized before any dynamic initialization takes place. 5.19 [expr.const] says An arithmetic constant expression shall satisfy the requirements for an integral constant expression, except that floating literals need not be cast to integral or enumeration type, and conversions to floating point types are permitted. Note that this does not allow an arithmetic constant expression to involve const variables of floating point type, so X + 2.0 is not an arithmetic constant expression, so Y is not required to have static initialization. But it is allowed to, as explained in comment #14. I think this distinction is not observable in C++03. But with C++0x constexpr it is; declaring Y as constexpr would be ill-formed unless X is also declared constexpr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #29 from mmitchel at gcc dot gnu dot org 2010-08-31 17:41 --- Jason -- I can't argue with that as a literal reading of the standard, but is there any reason why the standard doesn't allow const float variables in (not necessarily integral) constant expressions just as we allow const int variables? -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #18 from mmitchel at gcc dot gnu dot org 2005-10-11 16:49 --- The optimization question in Comment #11 was answered incorrectly. The C++ standard in fact requires that Y be initialized before the constructor is run; see [basic.start.init]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #19 from sabre at nondot dot org 2005-10-11 16:58 --- To clarify: you are saying that the response in comment #12 is wrong? -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #20 from mark at codesourcery dot com 2005-10-11 17:00 --- Subject: Re: [4.0/4.1 Regression] C++ front-end does not inline the static const double sabre at nondot dot org wrote: --- Comment #19 from sabre at nondot dot org 2005-10-11 16:58 --- To clarify: you are saying that the response in comment #12 is wrong? I don't understand Comment #12. However, Comment #13 says that You are correct Chris, this was an invalid optimization; that's incorrect, it is in fact a required optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #21 from sabre at nondot dot org 2005-10-11 17:03 --- required optimization doesn't make sense to me. To put it more clearly, do you agree that this: In particular, I think the C++ standard specifies that memory is zero initialized and then ctors (within a translation unit) are run in order. statement is true, and that the code in comment 11 is valid? If so, an attempt to implement this optimization just needs to be careful not the break this sort of case. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #22 from mark at codesourcery dot com 2005-10-11 17:05 --- Subject: Re: [4.0/4.1 Regression] C++ front-end does not inline the static const double sabre at nondot dot org wrote: --- Comment #21 from sabre at nondot dot org 2005-10-11 17:03 --- required optimization doesn't make sense to me. To put it more clearly, do you agree that this: In particular, I think the C++ standard specifies that memory is zero initialized and then ctors (within a translation unit) are run in order. statement is true, and that the code in comment 11 is valid? Initializers are not constructors. You'll have to go read the section of the standard I cited. The code in comment #11 is valid -- but it must print 3.0, which may not be what you expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #23 from sabre at nondot dot org 2005-10-11 17:10 --- Ah, very interesting. Thanks for the clarification. Should I file another PR about cases where this is mishandled? -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #24 from sabre at nondot dot org 2005-10-11 17:15 --- At pinskia's request, I filed Bug 24312 to show the miscompilation due to mishandling this. I thought it would be better to keep this PR focused on the missed-optimization aspect. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #25 from cvs-commit at gcc dot gnu dot org 2005-10-11 20:58 --- Subject: Bug 21089 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED]2005-10-11 20:58:46 Modified files: gcc/cp : call.c init.c typeck.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/init: float1.C Log message: PR c++/21089 * call.c (convert_like_real): Use decl_constant_value, not integral_constant_value. * init.c (constant_value_1): New function. (integral_constant_value): Use it. (decl_constant_value): Likewise. * typeck.c (decay_conversion): Use decl_constant_value, not integral_constant_value. PR c++/21089 * g++.dg/init/float1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gccr1=1.555r2=1.556 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gccr1=1.430r2=1.431 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gccr1=1.653r2=1.654 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4919r2=1.4920 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/float1.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6168r2=1.6169 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #26 from cvs-commit at gcc dot gnu dot org 2005-10-11 20:59 --- Subject: Bug 21089 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED]2005-10-11 20:59:53 Modified files: gcc/cp : call.c init.c typeck.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/init: float1.C Log message: PR c++/21089 * call.c (convert_like_real): Use decl_constant_value, not integral_constant_value. * init.c (constant_value_1): New function. (integral_constant_value): Use it. (decl_constant_value): Likewise. * typeck.c (decay_conversion): Use decl_constant_value, not integral_constant_value. PR c++/21089 * g++.dg/init/float1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.531.2.9r2=1.531.2.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.412.2.10r2=1.412.2.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.616.2.19r2=1.616.2.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.4648.2.124r2=1.4648.2.125 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/float1.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.445r2=1.5084.2.446 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #27 from mmitchel at gcc dot gnu dot org 2005-10-11 21:05 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
-- What|Removed |Added Target Milestone|4.0.2 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20 14:33 --- *** Bug 23975 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||lidaobing at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
-- What|Removed |Added Target Milestone|4.0.1 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Additional Comments From nathan at gcc dot gnu dot org 2005-04-28 08:02 --- the example test case is invalid even with the gnu extension. As with static const int members, you must have a single out-of-class definition of the member EVEN IF the member is initialized in class. [9.4.2/4] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Additional Comments From matz at suse dot de 2005-04-28 09:24 --- Yes, I determined that already in the initial report; to cite myself: It's invalid for two reasons I think, first the missing definition, instead of the declaration. [the second reason being the use of the GNU extension]. But it can be trivially made valid (just provide a definition), and I assumed this to be done for sake of this bugreport. Using the GNU extension this would then be valid, and _then_ the value is still not propagated to the method body. _That_'s what I'm complaining about, the missed optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28 02:09 --- (In reply to comment #11) Is this optimization valid? Note that it will change the behavior of this c++ program: You are correct Chris, this was an invalid optimization. This is a dup of bug 19320. Though we still have a wrong code bug with respect with const still being on the decl but that is PR 20912. *** This bug has been marked as a duplicate of 19320 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Additional Comments From matz at suse dot de 2005-04-28 02:46 --- Uhm, wait. Perhaps the optimization would be invalid for your changed example from comment #5, but see below. But it will not be invalid for my initial testcase, where it missed to propagate 20.0 into setPosition. Why I think the transformation is valid _also_ for comment #5: See 3.6.2 #2: --- An implementation is permitted to perform the initialization of an object of namespace scope with static storage duration as a static initialization even if such initialization is not required to be done statically, provided that * the dynamic version of the initialization does not change the value of any other object of namespace scope with static storage duration prior to its initialization, and * the static version of the initialization produces the same value in the initialized object as would be produced by the dynamic initialization if all objects not required to be initialized statically were initialized dynamically. - It then goes on to provide an example which uses an inline function to dynamically initialize something, where comment #5 uses an arithmetic expression. So I think we are permitted to do this optimization, in both, by initial example, and Andrews example from comment #5. Reopening. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
-- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double members
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 17:50 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.0.0 4.1.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2005-04-18 17:50:29 date|| Summary|C++ front-end does not |[4.0/4.1 Regression] C++ |inline the static const |front-end does not inline |double members |the static const double ||members Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
17:53 ---
It has nothing to do with members of classes either, see the following code:
static const double a = 1.0;
static const double b = a+1.0;
double c()
{
return b;
}
We now longer inline 2.0 into c.
--
What|Removed |Added
Summary|[4.0/4.1 Regression] C++|[4.0/4.1 Regression] C++
|front-end does not inline |front-end does not inline
|the static const double |the static const double
|members |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Additional Comments From matz at suse dot de 2005-04-18 17:59 --- With -O0 we also don't inline 'a'. I thought in the past this already was done in the frontend, so the -O option didn't matter? If yes, this has changed (if not, well, I'm wrong ;-) ). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:04 --- (In reply to comment #6) With -O0 we also don't inline 'a'. I thought in the past this already was done in the frontend, so the -O option didn't matter? If yes, this has changed (if not, well, I'm wrong ;-) ). The code for 3.4.0 at -O0 for the example in comment #5: .LC0: .long 0 .long 1073741824 .text .align 2 .globl _Z1cv .type _Z1cv, @function _Z1cv: pushl %ebp movl%esp, %ebp fldl.LC0 popl%ebp ret .size _Z1cv, .-_Z1cv .section.rodata .align 8 .type a, @object .size a, 8 a: .long 0 .long 1072693248 .align 8 .type b, @object .size b, 8 b: .long 0 .long 1073741824 so we did inline 2.0 before. The code for 4.0.0 and above is even worse: _Z1cv: pushl %ebp movl%esp, %ebp fldlb popl%ebp ret .size _Z1cv, .-_Z1cv .text .align 2 .type _Z41__static_initialization_and_destruction_0ii, @function _Z41__static_initialization_and_destruction_0ii: pushl %ebp movl%esp, %ebp subl$8, %esp movl%eax, -4(%ebp) movl%edx, -8(%ebp) cmpl$65535, -8(%ebp) jne .L7 cmpl$1, -4(%ebp) jne .L7 fldla fld1 faddp %st, %st(1) fstpl b .L7: leave ret .size _Z41__static_initialization_and_destruction_0ii, .- _Z41__static_initialization_and_destruction_0ii .text .align 2 .type _GLOBAL__I__Z1cv, @function _GLOBAL__I__Z1cv: pushl %ebp movl%esp, %ebp movl$65535, %edx movl$1, %eax call_Z41__static_initialization_and_destruction_0ii popl%ebp ret We dymanically initialize b too which is what partly PR 20912 is about, Diego filed after seeing eon fail because the front-end was still marking b as constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:06 --- Also note this worked with 4.0.0 2004121, so something after that date changed the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:19 --- (In reply to comment #8) Also note this worked with 4.0.0 20041211, so something after that date changed the problem. And it was broken by 4.0.0 20050113. so there is only a month time which it could have changed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:34 --- Looks like this was caused by: 2004-12-16 Nathan Sidwell [EMAIL PROTECTED] PR c++/18905 * cp-tree.h (integral_constant_value): Declare. * call.c (null_ptr_cst_p): Use integral_constant_value, not decl_constant_value. (convert_like_real): Likewise. * class.c (check_bitfield_decl): Likewise. * cvt.c (ocp_convert): Likewise. (convert): Remove unnecessary decl_constant_value call. * decl.c (compute_array_index_type): Use integral_constant_value, not decl_constant_value. (build_enumerator): Likewise. * decl2.c (grokfield): Likewise. * init.c (decl_constant_value): Simplify. (integral_constant_value): New. * pt.c (fold_decl_constant_value): Use integral_constant_value, remove subsequent check. (tsubst): Use integral_constant_value, not decl_constant_value. (tsubst_copy, unify): Likewise. * typeck.c (decay_conversion): Likewise. (build_compound_expr): Remove unnecessary decl_constant_value calls. (build_static_cast_1, build_reinterpret_cast_1): (convert_for_assignment): Remove comment about not calling decl_constant_value. -- What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Additional Comments From sabre at nondot dot org 2005-04-18 18:41
---
Is this optimization valid? Note that it will change the behavior of this c++
program:
#include stdio.h
static const double X = 1.0;
static struct S { S(); } s;
static const double Y = X+2.0;
S::S() {
printf(%f\n, Y);
}
int main() {}
In particular, I think the C++ standard specifies that memory is zero
initialized and then ctors (within a translation unit) are run in order. IANALL
though.
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Additional Comments From schlie at comcast dot net 2005-04-18 19:36 --- (In reply to comment #11) I believe the optimization necessitates the variable's declaration be changed (either explicitly, or by implication): static const double b = a+1.0; = const double b = a+1.0; If it's static-const value can't be pre-computed at compile time. (as opposed to allowing a non-const-literal value to initialize a global static const object). (as with: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912 ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
