--- Comment #17 from rguenth at gcc dot gnu dot org 2007-11-19 12:53
---
Subject: Bug 34099
Author: rguenth
Date: Mon Nov 19 12:52:58 2007
New Revision: 130290
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130290
Log:
2007-11-19 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-11-19 12:52
---
Subject: Bug 34099
Author: rguenth
Date: Mon Nov 19 12:52:09 2007
New Revision: 130289
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130289
Log:
2007-11-19 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-11-16 10:36
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-11-16 10:10
---
Subject: Bug 34099
Author: rguenth
Date: Fri Nov 16 10:10:05 2007
New Revision: 130222
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130222
Log:
2007-11-16 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-11-15 17:10
---
Trivial testcase we get wrong with the current scheme:
int foo (int b, int c)
{
int x;
if (b)
return x & c;
else
return 1;
}
extern void abort (void);
int main()
{
if (foo(1, 0) != 0)
abort ();
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-11-15 17:17
---
I think this has been caused by the fix for PR29738.
Author: rakdver
Date: Thu Nov 9 00:09:43 2006
New Revision: 118602
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118602
Log:
PR tree-optimizat
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-11-15 16:38
---
Oh, trivial error. Looking again tomorrow.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-11-15 15:44
---
> That is, a certain class of operations (like COMPLEX_EXPR) do not fulfil the
> constraint that if one operand is UNDEFINED the result is UNDEFINED as well.
Is the problem somehow related to PR middle-end/33088?
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-11-15 16:08
---
Created an attachment (id=14558)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14558&action=view)
new broken patch
Err, that was an old patch.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-11-15 16:06 ---
Created an attachment (id=14557)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14557&action=view)
broken patch
It miscompiles gengtype. I remember problems with changing likely_value in
similar ways back in t
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-15 16:04 ---
Which doesn't work :( Unassigning.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenther at suse dot de 2007-11-15 15:51 ---
Subject: Re: [4.3 Regression] optimizer problem
On Thu, 15 Nov 2007, ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-11-15 15:44
> ---
> > That is, a certain
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-15 15:40 ---
That is, a certain class of operations (like COMPLEX_EXPR) do not fulfil the
constraint that if one operand is UNDEFINED the result is UNDEFINED as well.
For example MIN_EXPR , or MAX_EXPR
are of such kind as well.
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-15 15:08 ---
This looks like this old bug that evaluate_stmt() sets results to UNDEFINED.
As
we visit
D.26933_16 = __t_14 * D.26932_15;
the result should become VARYING, but we make it UNDEFINED. Because also
likely_value ()
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-15 14:56 ---
Uhm, this goes wrong in CCP. (w/o SRA the failure doesn't trigger though)
Before CCP we have:
void multiply(NumType, NumType, unsigned int, NumType&) (a, b, ac, ab)
{
double s$_M_value$real;
double s$_M_value
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-15 10:21 ---
Confirmed. Shorter testcase:
#include
#include
typedef std::complex NumType;
void
multiply(NumType a, NumType b, unsigned ac, NumType &ab)
{
NumType s;
for (unsigned j=0; jhttp://gcc.gnu.org/bugzilla/show_b
16 matches
Mail list logo
