--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-05-31 07:22
---
I think we have enough passes already and should try to stuff this in cse.c and
fwprop.c. See PR middle-end/33699 for related issues.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from carrot at google dot com 2009-05-31 08:05 ---
(In reply to comment #3)
> I think we have enough passes already and should try to stuff this in cse.c
> and
> fwprop.c. See PR middle-end/33699 for related issues.
>
It looks that patch solved some similar issues. But
--- Comment #2 from mikpe at it dot uu dot se 2009-05-31 08:10 ---
(In reply to comment #1)
> The one compiled with O2 has wrong binary code.
>
> The problem occurs when GCC compiles the following lines with O2 flag.
>
> "
> if (pdw && memcmp(a1, a2, pdw << 2))
>
--- Comment #8 from irar at il dot ibm dot com 2009-05-31 09:04 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from joachim dot zaers at web dot de 2009-05-31 09:29
---
Subject: Re: Use of --prefix and --exec-prefix breaks
compiler build with --with-headers
Hi Ramana!
I'm sorry I'm no longer hacking but just consulting. So I have no longer
all the infrastructure to verify th
--- Comment #2 from jakub at gcc dot gnu dot org 2009-05-31 09:36 ---
Subject: Bug 40304
Author: jakub
Date: Sun May 31 09:36:17 2009
New Revision: 148011
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148011
Log:
PR middle-end/40304
* config/i386/i386.c (pro_epi
--- Comment #4 from irar at il dot ibm dot com 2009-05-31 10:55 ---
So, will "too many basic blocks in loop" be good enough? Because this is what
it is, the reason that the loop form is not suitable for the vectorizer is that
there are too many basic blocks in it.
--
http://gcc.gnu.
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-31 12:14 ---
Definitely spelling out basic-block is an improvement. Though it would be nice
to use 'control-flow' when appropriate, if we can exclude the non-empty
latch case from this.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-31 12:25 ---
It works for me with
$ gcc-4.1 --version
gcc-4.1 (GCC) 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)
and all other GCC versions I try.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from irar at il dot ibm dot com 2009-05-31 12:33 ---
For non-empty latch block we actually print "not vectorized: unexpected loop
form." So I can change it to "not vectorized: non-empty latch block", and
instead of "too many BBs" I can write "control flow in loop".
--
Consider the program:
=
template
class Foo
{
public:
typedef double double3[3];
};
template
void doSomething(const typename Foo::double3)
{
}
template
void doSomething<2>(const Foo<2>::double3);
template
void doSomething<3>(const Foo<3>::double3
+++ This bug was initially created as a clone of Bug #40304 +++
On Linux/ia32, revision 147995:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00974.html
caused
FAIL: gcc.target/i386/lea.c scan-assembler leal
--
Summary: [4.5 Regression] Revision 147995 breaks
gcc.t
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-31 13:54 ---
I opened PR 40316 for
gcc.target/i386/lea.c
I am closing this one.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-31 15:27 ---
I see. Unexpected loop form is better for the user I guess, so just change
the other part. Thx.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39129
--- Comment #1 from kkojima at gcc dot gnu dot org 2009-05-31 21:45 ---
Subject: Bug 40313
Author: kkojima
Date: Sun May 31 21:45:18 2009
New Revision: 148017
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148017
Log:
PR target/40313
* config/sh/sh.c: Include deb
--- Comment #2 from kkojima at gcc dot gnu dot org 2009-05-31 21:57 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
When I compile this C code with an i686-unknown-linux-gnu native mainline
compiler, I get an ICE.
int
main ()
{
int f1 ()
{
__label__ lab;
int f2 ()
{
goto lab;
}
return f2 () + f2 ();
lab:
return 2;
}
if (f1 () != 2)
abort ();
exit (0);
}
foo.c:
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-06-01 06:02 ---
Remember to update the webpage:
http://gcc.gnu.org/gcc-4.5/changes.html
Add the MPC library dependency in the "Caveats" section, and add the benefits
of using MPC in the "General Optimizer Improvements" section.
--
Complex division by zero in gfortran returns NaN. This is expected for 0/0,
but other finite/zero should return Inf. This impacts the testcase
gfortran.dg/real_const_3.f90 in two values incorrectly computed:
complex :: z = (-0.1,-2.2)/(0.0,0.0)
complex :: z2 = (0.1,1)/0
See: http://gcc.gnu.
--- Comment #1 from kargl at gcc dot gnu dot org 2009-06-01 06:54 ---
(In reply to comment #0)
> Complex division by zero in gfortran returns NaN. This is expected for 0/0,
> but other finite/zero should return Inf. This impacts the testcase
> gfortran.dg/real_const_3.f90 in two values
20 matches
Mail list logo
