--- Comment #37 from rth at gcc dot gnu dot org 2005-11-16 23:47 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #36 from rth at gcc dot gnu dot org 2005-11-16 23:43 ---
Subject: Bug 23497
Author: rth
Date: Wed Nov 16 23:43:39 2005
New Revision: 107107
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107107
Log:
PR middle-end/23497
* tree-ssa.c (warn_uninitialized
--- Comment #35 from schwab at suse dot de 2005-11-16 20:42 ---
__imag__ a = b looks like a simple assignment, thus it should act like a simple
assignment. You can pack a struct { short a,b; } in a single register, but
that should not result in a warning when assigning a part of it, eve
--- Comment #34 from gdr at integrable-solutions dot net 2005-11-16 20:29
---
Subject: Re: [4.1 regression] Bogus 'is used uninitialized...' warning about
std::complex
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I should also note that:
| http://gcc.gnu.org/onlined
--- Comment #33 from mark at codesourcery dot com 2005-11-16 20:08 ---
Subject: Re: [4.1 regression] Bogus 'is used uninitialized...'
warning about std::complex
pinskia at gcc dot gnu dot org wrote:
> --- Comment #32 from pinskia at gcc dot gnu dot org 2005-11-16 19:58
> ---
--- Comment #32 from pinskia at gcc dot gnu dot org 2005-11-16 19:58
---
(In reply to comment #31)
> This is not a valid argument.
What would you consider a valid argument for an extension which is not that
well documented?
> The point of warnings is not to tell the user how the compil
--- Comment #31 from mark at codesourcery dot com 2005-11-16 18:58 ---
Subject: Re: [4.1 regression] Bogus 'is used uninitialized...'
warning about std::complex
pinskia at gcc dot gnu dot org wrote:
> From the C perspective the warning is correct as you are loading piece wise
> which
--- Comment #30 from rth at gcc dot gnu dot org 2005-11-16 18:56 ---
Clearly the only way to stop getting mail in this thread is to fix it.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #29 from pinskia at gcc dot gnu dot org 2005-11-16 18:54
---
(In reply to comment #27)
> From libstdc++ perspective, __imag__ ought to be an lvalue. This is a recurent
> issue for C++ complex<>.
Of course the lvalue is moot, I never said __imag__ should not be lvalue, I
do
--- Comment #28 from gdr at gcc dot gnu dot org 2005-11-16 18:47 ---
(In reply to comment #25)
> Subject: Re: [4.1 regression] Bogus 'is used uninitialized...'
> warning about std::complex
>
> schwab at suse dot de wrote:
> > --- Comment #23 from schwab at suse dot de 2005-11-16
--- Comment #27 from gdr at gcc dot gnu dot org 2005-11-16 18:44 ---
(In reply to comment #19)
> There are only two choices: either __imag__ is an lvalue, and the code in
> Comment #1 is valid, or __imag__ is not an lvalue, and the compiler should
> issue an error.
>
> Nobody wants to s
--- Comment #26 from gdr at gcc dot gnu dot org 2005-11-16 18:40 ---
(In reply to comment #17)
> (In reply to comment #13)
> > It's nice to see that PR bouncing between you all. Although I don't know
> > anything about C++, I want to add my non-constructive comment to this
> > discussion
--- Comment #25 from mark at codesourcery dot com 2005-11-16 16:53 ---
Subject: Re: [4.1 regression] Bogus 'is used uninitialized...'
warning about std::complex
schwab at suse dot de wrote:
> --- Comment #23 from schwab at suse dot de 2005-11-16 14:20 ---
> (In reply to comme
--- Comment #24 from rth at gcc dot gnu dot org 2005-11-16 16:47 ---
We tried that. You get suckier optimization that way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
--- Comment #23 from schwab at suse dot de 2005-11-16 14:20 ---
(In reply to comment #22)
> Note I never said __imag__ a should not act like an lvalue. I just said that
> __imag__ a = b; acts like a = COMPLEX, b> which is just like what
> a = (a&0x)|(b&0x) does.
IMHO it
--- Comment #22 from pinskia at gcc dot gnu dot org 2005-11-16 13:36
---
(In reply to comment #21)
> For the libgfortran issue (libgfortran uses __imag__ as a lvalue) what should
> be done? Who can decide whether __imag__ is or isn't a lvalue? Sorry to ask
> for
> the obvious, but I'm
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2005-11-16 13:19
---
(In reply to comment #19)
> There are only two choices: either __imag__ is an lvalue, and the code in
> Comment #1 is valid, or __imag__ is not an lvalue, and the compiler should
> issue an error.
For the libgfo
--- Comment #20 from pcarlini at suse dot de 2005-11-15 22:16 ---
About the optimization issue, maybe we should file a separate enhancement PR,
if there isn't already one. Really, we should be able to optimize well any
variant of this kind of code.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #19 from mmitchel at gcc dot gnu dot org 2005-11-15 22:10
---
There are only two choices: either __imag__ is an lvalue, and the code in
Comment #1 is valid, or __imag__ is not an lvalue, and the compiler should
issue an error.
Nobody wants to see a warning about an uninitia
--- Comment #18 from pcarlini at suse dot de 2005-11-15 22:00 ---
(In reply to comment #16)
> Here is the current patch so for libstdc++ (I did not test it yet):
Before patching this and that in the runtime library, don't you believe that:
1- If, as Mark said, (__imag__ t) is an lvalue,
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-15 21:57
---
(In reply to comment #13)
> It's nice to see that PR bouncing between you all. Although I don't know
> anything about C++, I want to add my non-constructive comment to this
> discussion: I don't understand how a bu
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-15 21:51
---
Here is the current patch so for libstdc++ (I did not test it yet):
Index: include/std/std_complex.h
===
--- include/std/std_complex.h (revision 106
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-15 21:42
---
(In reply to comment #14)
> There is nothing wrong with the code in Comment #1; __imag__ is an
> lvalue-yielding operator. If, for some reason, we wanted to make __imag__
> yield an rvalue, then this code would be
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-11-15 19:23
---
There is nothing wrong with the code in Comment #1; __imag__ is an
lvalue-yielding operator. If, for some reason, we wanted to make __imag__
yield an rvalue, then this code would be rejected with an error; under
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2005-11-15 16:55
---
It's nice to see that PR bouncing between you all. Although I don't know
anything about C++, I want to add my non-constructive comment to this
discussion: I don't understand how a bug which has a C-only testcase
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-15 16:47
---
(In reply to comment #9)
> Certainly, the test-case in Comment #1 does depend on libstdc++ at all.
> Let's fix this.
The testcase in comment #1 shows the issue with what libstdc++ is doing. Since
complex is sca
--- Comment #11 from pcarlini at suse dot de 2005-11-15 16:39 ---
(In reply to comment #10)
> And my comment in #6 still holds for this bug. I think libstdc++ should
> rethink about this.
libstdc++ can rething anything, in principle, but if you change the component
to libstdc++, nobody
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 05:28
---
Certainly, the test-case in Comment #1 does depend on libstdc++ at all. Let's
fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-26 22:51 ---
Note in the mathematical sense complex numbers are scalars, I know in the
compiler world this is different.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-12 00:32 ---
Hmm, we also have a missed optimization on the tree level too.
For the following code:
__complex__ double t1;
void f() {
__complex__ double t;
__imag__ t = 0;
__real__ t = 0;
t1 = t;
}
we get:
t1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12
19:21 ---
(In reply to comment #5)
> Agree with Gaby.
I disagree but what do I know.
It would be like doing:
int f(void)
{
int i;
i = (i&0x) | 0x;
i = (i&0x) | 0x;
return i;
}
31 matches
Mail list logo
