--- Comment #10 from ubizjak at gmail dot com 2009-07-16 06:56 ---
(In reply to comment #6)
> Thus with the GLIBC (with AMD patches) or with the AMCL, one gets only a
> slowdown of 25%, which is still acceptable. Why the Intel routines are so slow
> on my AMD, I do not know.
See [1], s
--- Comment #9 from kargl at gcc dot gnu dot org 2009-07-16 05:06 ---
(In reply to comment #8)
> compilation is also very slow, isn't it?
>
It's due to the initialization expression.
How much memory do you have? You're most likely swapping.
Your code when compiled with 4.5.0 shows
--- Comment #8 from linuxl4 at sohu dot com 2009-07-16 04:37 ---
compilation is also very slow, isn't it?
can anybody confirm my results of only with or without -O3 option?
I think the difference of sse or x87 is 4 times at most.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-07-16 03:23
---
Taking myself off of this one.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-07-16 01:31
---
I was trying to do it in hit_eof after the return from the error. I have not
figured it out yet. I will keep trying, but hope you find it first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714
--- Comment #5 from amylaar at gcc dot gnu dot org 2009-07-16 00:11 ---
(In reply to comment #3)
> Hi Steven,
>
> Maybe I'm missing something, but what do patches talking about
> SMALL_REGISTER_CLASSES have to do with this issue? For ARM, the registers
> involved are general purpose an
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-15 21:46
---
Fixed for 4.4.1 and mainline.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from jb at gcc dot gnu dot org 2009-07-15 21:42 ---
Ok, so the problem is that due to the EOF the first read hits, the
current_record marker is not properly reset to 0 at the end of the data
transfer, and from that it follows that stuff isn't correctly initialized at
the n
--- Comment #16 from steven at gcc dot gnu dot org 2009-07-15 21:35 ---
*** Bug 40768 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
--- Comment #4 from steven at gcc dot gnu dot org 2009-07-15 21:35 ---
I have a patch for PPRE to stop inserting this much (want_to_ppre_p).
Basically make it insert only once.
*** This bug has been marked as a duplicate of 38785 ***
--
steven at gcc dot gnu dot org changed:
--- Comment #4 from kkojima at gcc dot gnu dot org 2009-07-15 21:32 ---
Subject: Bug 40710
Author: kkojima
Date: Wed Jul 15 21:32:46 2009
New Revision: 149696
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149696
Log:
PR rtl-optimization/40710
* resource.c (mark_
--- Comment #3 from drow at gcc dot gnu dot org 2009-07-15 21:30 ---
Hi Steven,
Maybe I'm missing something, but what do patches talking about
SMALL_REGISTER_CLASSES have to do with this issue? For ARM, the registers
involved are general purpose and ! SMALL_REGISTER_CLASSES. There's a
--- Comment #2 from steven at gcc dot gnu dot org 2009-07-15 21:12 ---
I will re-test and submit my PRE patches this weekend (richi: including the -Os
PRE patch unless you already put yours in first -- but mine is nicer ;-)
*** This bug has been marked as a duplicate of 38785 ***
--
--- Comment #15 from steven at gcc dot gnu dot org 2009-07-15 21:12 ---
*** Bug 40768 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janis at gcc dot gnu dot org 2009-07-15 21:07 ---
Subject: Bug 40691
Author: janis
Date: Wed Jul 15 21:07:07 2009
New Revision: 149695
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149695
Log:
PR libstdc++/40691
* include/bits/valarray_after.
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-15 21:02 ---
There's a dup for this somewhere. Steven for sure knows.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-15 21:00 ---
icc can vectorize the function, gcc cannot. Use an operating system which
has sincos available and you'll get at least that bit.
You definitely want -O3 -ffast-math. That we can't vectorize sin/cos/tan
is RMS faul
--- Comment #6 from burnus at gcc dot gnu dot org 2009-07-15 20:27 ---
You should also add -march=native to the command line; it probably does not
help much, bit it should help a bit. I recall also the standard GLIBC misses
some optimized version for math on x86-64 while AMD provides pat
PRE in GCC-4.4 and mainline appears to backfire.
Consider:
void
foo (unsigned int n, unsigned int *p)
{
*p = 0;
if (0x01 & n) *p |= 0x0101;
if (0x02 & n) *p |= 0x0202;
if (0x04 & n) *p |= 0x0404;
if (0x08 & n) *p |= 0x0808;
if (0x10 & n) *p |= 0x1010;
if (0x20 & n) *p |= 0x2020;
i
/home/joel/test-gcc/b-gcc2-m68k/./gcc/xgcc
-B/home/joel/test-gcc/b-gcc2-m68k/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-gcc2-m68k/m68k-rtems4.10/newlib/ -isystem
/home/joel/test-gcc/b-gcc2-m68k/m68k-rtems4.10/newlib/targ-include -isystem
/home/joel/test-gcc/gcc-svn/newlib/libc/include
-B/home/joel/te
--- Comment #5 from dominiq at lps dot ens dot fr 2009-07-15 18:50 ---
> can anybody confirm?
On a 2.1Ghz core2duo, i686-apple-darwin, I get:
[ibook-dhum] bug/timing% gfc -m64 -O3 -ffast-math pr40766_db.f90
[ibook-dhum] bug/timing% time a.out
4.36921651E+09
157.568u 0.454s 2:38.39 99
--- Comment #4 from linuxl4 at sohu dot com 2009-07-15 18:35 ---
-O3 also very slow.
4.28173363E+09
real81m50.845s
user81m50.587s
sys 0m0.444s
can anybody confirm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766
--- Comment #14 from photon at seznam dot cz 2009-07-15 18:24 ---
(In reply to comment #13)
> Or rather from SCHAR_MAX + 1 to SCHAR_MIN :). Since it is 0x7F + 1 ==
> (int)0x80. So we have a negative value now from a positive value.
>
This occurs regardless of the implicit conversion.
--- Comment #3 from ubizjak at gmail dot com 2009-07-15 17:58 ---
(In reply to comment #1)
> if I call the functions(sin,cos,tan) from intel's libimf.so, then
> gfortran 1.f90 -limf
> 4.31716608E+09
>
> real6m39.177s
> user6m38.289s
> sys 0m0.512s
This is probably libra
--- Comment #5 from jb at gcc dot gnu dot org 2009-07-15 17:19 ---
I don't get it; for some reason bytes_left_subrecord has been set to 0, hence
the seek gets messed up.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-07-15 17:00
---
Or rather from SCHAR_MAX + 1 to SCHAR_MIN :). Since it is 0x7F + 1 ==
(int)0x80. So we have a negative value now from a positive value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-07-15 16:58
---
Except it does alter its value from 0x100 to 0x00 :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
--- Comment #11 from photon at seznam dot cz 2009-07-15 16:55 ---
(In reply to comment #8)
> For:
>
> c += (char) 1;
>
> The value can change as you have a wrapping if c is CHAR_MAX.
>
> Likewise with:
> c += c2;
>
The value cannot change even if an overflow occurs.
{
--- Comment #1 from ro at gcc dot gnu dot org 2009-07-15 16:51 ---
I've rebuilt lto1 with just -g and re-run it under gdb. This is not a
NULL-pointer
dereference, but an improperly aligned pointer:
Starting program:
/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/gcc/testsuite/g++/lto1 -quiet
--- Comment #13 from bonzini at gnu dot org 2009-07-15 16:20 ---
For the record, it's actually somewhat related to PR39726 (a m68k
pessimization), not PR39715. However, because of the way combine canonicalizes
the resulting expression, the patch for that bug does not fix the testcase.
--- Comment #3 from ro at gcc dot gnu dot org 2009-07-15 16:05 ---
Sorry, my Comment #1 was directed at the wrong bug. mkdtemp is still used
unconditionally, and this would e.g. affect Solaris 10 where it is missing.
--
ro at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from ro at gcc dot gnu dot org 2009-07-15 16:03 ---
I don't think this is a duplicate: even if the bootstrap compiler is gcc, it
may still lack visibility support (as it did on Solaris until recently or on
IRIX where ld/rld lack the necessary support). At least, this requ
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-15 15:55 ---
What is the timing when adding -O3 to the command line. GCC defaults to no
optimizations turned on. This is unlike ifort which defaults to having
optimizations turned on.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #1 from linuxl4 at sohu dot com 2009-07-15 15:49 ---
My server is an atom330/gentoo
gfortran -v
GNU Fortran (GCC) 4.5.0 20090715 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.
gfortran 1.f90; time ./a.out
4.28173363E+09
real120m30.599s
user
program main
implicit none
integer :: i,j
integer,parameter :: N=5000
real :: x(N)=0.0
do j=1,20
do i=1,N
x(i)=x(i)+sin(real(i))+cos(real(i))-tan(real(i))
enddo
enddo
print *, sum(x)
end program main
--
Summary: this fortran program is too slow
Pro
--- Comment #9 from jv244 at cam dot ac dot uk 2009-07-15 15:32 ---
(In reply to comment #8)
> > I pointed this out to Paul already, but appearantly it is still stuck in
> > his
> > whole-file patch queue.
>
> Last incarnation of that patch (containing this fix) is at:
> http://gcc.
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-15 15:17 ---
Confirmed. (even with the first testcase, I messed things up)
Maybe non-LTO related.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 15:15 ---
Confirmed. Maybe as well LTO unrelated.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from joerg dot richter at pdv-fs dot de 2009-07-15 15:13
---
If you mean that i.e. libgomp.so.1.0.0 and libssp.so.0.0.0 have the same bug.
Than yes. They reference libgcc_s.so.1 without setting RPATH to '$ORIGIN'.
So this issue isn't libstdc++ specific. Changing compon
--- Comment #26 from rguenther at suse dot de 2009-07-15 15:00 ---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
On Wed, 15 Jul 2009, dberlin at dberlin dot org wrote:
> Subject: Re: [4.4/4.5 Regression] internal
> compi
--- Comment #25 from dberlin at gcc dot gnu dot org 2009-07-15 14:29
---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
On Wed, Jul 15, 2009 at 9:58 AM, rguenther at suse dot
de wrote:
>
>
> --- Comment #24 from rguenth
--- Comment #7 from paolo dot carlini at oracle dot com 2009-07-15 14:18
---
At minimum, somebody should check if it's still true that this possible issue
isn't limited to libstdc++. Then the course of action will be very simple:
again invalid or not a libstdc++ proper issue or a fix to
--- Comment #10 from joseph at codesourcery dot com 2009-07-15 14:15
---
Subject: Re: -Wconversion: do not warn for operands not larger
than target type
On Wed, 15 Jul 2009, ian at airs dot com wrote:
> Sure, it can wrap, but -Wconversion is not for wrapping warnings.
It's for warn
--- Comment #9 from ian at airs dot com 2009-07-15 14:00 ---
Sure, it can wrap, but -Wconversion is not for wrapping warnings.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
--- Comment #24 from rguenther at suse dot de 2009-07-15 13:58 ---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
On Wed, 15 Jul 2009, dberlin at dberlin dot org wrote:
> --- Comment #23 from dberlin at gcc dot gnu dot org 200
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
I did a quick scan for misuse of pointer values after failed
asprintf-style function uses and spotted a few. Here's a patch
for one of them:
[this patch is relative to just-updated "trunk"]
>From 1f71a26ec38860d863ca751aef049d314a4f34b4 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 6 J
--- Comment #23 from dberlin at gcc dot gnu dot org 2009-07-15 13:46
---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
a_1 shouldn't be in the maximal set. If it is, that's a bug.
The history here:
We didn't use to have
--- Comment #22 from dberlin at gcc dot gnu dot org 2009-07-15 13:37
---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
Phi uses can be in the maximum set as long as they are not phi's themselves.
There is a comment above a
--- Comment #6 from joerg dot richter at pdv-fs dot de 2009-07-15 13:15
---
I stumpled across the same problem recently.
Executable references both libstdc++.so and libgcc_s.so.
libstdc++.so references libgcc_s.so.
Both executable dependencies will be correctly resolved (due to RPATH)
--- Comment #4 from mikpe at it dot uu dot se 2009-07-15 13:15 ---
mpfr-2.4.1 compiles and tests Ok for me on an Ultra5 (USIIi) running
sparc64-linux, with gmp-4.2.4 (compiled by gcc-4.3.4) and gcc 4.3.4, 4.4.0, and
4.4.1 20090630.
I don't have a T2, but could possibly do some tests on
--- Comment #4 from rmansfield at qnx dot com 2009-07-15 13:02 ---
Created an attachment (id=18202)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18202&action=view)
2nd preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40758
--- Comment #3 from rmansfield at qnx dot com 2009-07-15 12:58 ---
I was able to the ICE using different source. Same usage:
r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. ice2.i -O -flto -c
r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. ice2.o -flto -shared
In file included from :935:0:
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-07-15 12:54
---
Correction - only b_2 is missing from the maximal set, a_1 is there because
it is used in non-PHI nodes. The fix indeed looks quite obvious to me now ...
For reference, here is the function before PRE again:
:
--- Comment #6 from dje at gcc dot gnu dot org 2009-07-15 12:50 ---
The fix for this actually is more involved. Nathan had a patch last October
which exposed similar bootstrap problems. He posted a revised patch
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01103.html
--
dje at gcc
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-07-15 12:42
---
One thing that is odd is that the maximal set misses a_1 and b_2 (but it does
have the default defs). Adding PHI arguments to the maximal set fixes this
PR...
Index: tree-ssa-pre.c
===
--- Comment #5 from dje at gcc dot gnu dot org 2009-07-15 12:38 ---
The patch seems reasonable, but it exposes a latent bug in Nathan's mmultiple
patch that was not tested because of this bug.
This patch should have been tested and posted to the GCC mailinglist
referencing this PR.
--
--- Comment #1 from rmansfield at qnx dot com 2009-07-15 11:44 ---
Created an attachment (id=18201)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18201&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40765
--- Comment #3 from vielhaber at gmail dot com 2009-07-15 11:43 ---
Created an attachment (id=18200)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18200&action=view)
The C++ source with comments.
Comments in lines 180 describe the erroneous behaviour.
Output line starting with 135
r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c --enable-lto
--disable-bootstrap
Thread model: posix
gcc version 4.5.0 20090714 (experimental) [lto revision 149644] (lto merged
with re
--- Comment #19 from rguenther at suse dot de 2009-07-15 11:33 ---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
On Wed, 15 Jul 2009, ich at az2000 dot de wrote:
> --- Comment #18 from ich at az2000 dot de 2009-07-15 11:31 --
--- Comment #2 from vielhaber at gmail dot com 2009-07-15 11:32 ---
Created an attachment (id=18199)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18199&action=view)
The .i file without optimization
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40764
--- Comment #1 from vielhaber at gmail dot com 2009-07-15 11:31 ---
Created an attachment (id=18198)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18198&action=view)
The .i with -O3 on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40764
--- Comment #18 from ich at az2000 dot de 2009-07-15 11:31 ---
Will this workaround-patch be included in 4.4.1? Because otherwise the whole
4.4.1 release will be pretty much useless for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
--- Comment #3 from hubicka at ucw dot cz 2009-07-15 11:29 ---
Subject: Re: [4.5 Regression] segfault in useless_type_conversion_p
I hope that patch for PR40676 should cure those problems. I am just on
the way to Prague, but I will try to look into it tomorrow.
Honza
--
http://g
Without -O3, code works as expected.
With -O3, varible is reset to 0.
Also, probably index overflow.
Where goes the .cc or .i ??
Bugzilla: Horribly scarce "user" interface!
g++ -v outputs:
Es werden eingebaute Spezifikationen verwendet.
Ziel: i486-linux-gnu
Konfiguriert mit: ../src/configure -v
--- Comment #10 from jakub at gcc dot gnu dot org 2009-07-15 11:26 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from jakub at gcc dot gnu dot org 2009-07-15 11:23 ---
Subject: Bug 40747
Author: jakub
Date: Wed Jul 15 11:23:22 2009
New Revision: 149681
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149681
Log:
PR middle-end/40747
* fold-const.c (fold_cond_exp
--- Comment #7 from reichelt at gcc dot gnu dot org 2009-07-15 11:19
---
This is really fixed.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gnu dot org 2009-07-15 11:11 ---
do while does not have the same behavior, so the loop "shape" is important.
the following is as bad and does not have function calls.
#define ONE while (x-- > y)
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 10:54 ---
For me
./xgcc -B. -shared ice.o -flto
takes ages because iterative_hash_gimple_type seems to be exponential in time!?
Called from gimple_register_type on
>
QI
size
unit size
a
--- Comment #12 from rearnsha at gcc dot gnu dot org 2009-07-15 10:31
---
Fixed with:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00848.html
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot
|dot org
--- Comment #8 from jakub at gcc dot gnu dot org 2009-07-15 10:18 ---
Subject: Bug 40747
Author: jakub
Date: Wed Jul 15 10:17:54 2009
New Revision: 149675
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149675
Log:
PR middle-end/40747
* fold-const.c (fold_cond_exp
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 10:17 ---
We have wrong SSA form before FRE:
;; Function func_36 (func_36)
func_36 ()
{
uint8_t g_64.8;
int64_t g_10.5;
:
# .MEM_17 = VDEF <.MEM_16(D)>
g_10 = 1;
# VUSE <.MEM_17>
g_10.5_2 = g_10;
if (g_10.5_2
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 10:09 ---
Confirmed. With -O2 -fno-inline we get in .optimized
func_36 ()
{
:
g_10 = 1;
func_53 ();
g_64 = 1;
return 1;
FRE does this. I'll check.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:56 ---
Is it the nesting of loops or really the number of function calls that is
important?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 09:55 ---
I would also recommend to try a newer snapshot from the gcc 4.4 release branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:53 ---
Program received signal SIGSEGV, Segmentation fault.
0x086e621a in useless_type_conversion_p (outer_type=0xb7cd43f0, inner_type=0x0)
at /home/richard/src/trunk/gcc/tree-ssa.c:1003
1003 if (POINTER_TYPE_P (in
--- Comment #7 from jakub at gcc dot gnu dot org 2009-07-15 09:48 ---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00842.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 09:47 ---
That redundant move has to be a separate issue, indeed. I would expect the
register allocator to coalesce those registers.
I hadn't expected this. I thought the result would be just the removal of the
redundant loa
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||memory-ho
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40755
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-15 09:44 ---
DF time on this testcase is already big, and the testcase has lots of function
calls which would explain the difference between targets (DF needs to track all
call-used/clobbered regs).
--
http://gcc.gnu.org/bug
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-15 09:43 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #28 from burnus at gcc dot gnu dot org 2009-07-15 09:41 ---
(In reply to comment #24)
> So maybe approach the question differently. Which element in an array of NaNs
> is the smallest one and what is its value? If I pick any one element, its
> "value" is NaN. It does not m
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-15 09:41 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-15 09:37 ---
Confirmed. 4.2 reports
g++-4.2 -Wall t.C
t.C: In function const A a():
t.C:6: warning: control reaches end of non-void function
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:34 ---
switch-conversion could try to handle this. Generally perfect hashing during
switch expansion is another thing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 09:25 ---
Subject: Bug 40753
Author: rguenth
Date: Wed Jul 15 09:25:34 2009
New Revision: 149664
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149664
Log:
2009-07-15 Richard Guenther
PR middle-end/40753
--- Comment #9 from janus at gcc dot gnu dot org 2009-07-15 08:47 ---
Fixed with r149662. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from janus at gcc dot gnu dot org 2009-07-15 08:41 ---
Subject: Bug 40743
Author: janus
Date: Wed Jul 15 08:41:29 2009
New Revision: 149662
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149662
Log:
2009-07-15 Janus Weil
PR fortran/40743
* reso
--- Comment #17 from jakub at gcc dot gnu dot org 2009-07-15 08:32 ---
Retargetting to 4.4.2, this doesn't seem to get to resolution soon enough.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--- Comment #6 from jakub at gcc dot gnu dot org 2009-07-15 08:28 ---
I'm already bootstrapping/regtesting a fix, will post afterwards.
If it gets approved quickly, I'll include it in 4.4.1-rc1 I plan to roll today.
--
jakub at gcc dot gnu dot org changed:
What|Remove
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
--- Comment #5 from sezeroz at gmail dot com 2009-07-15 08:19 ---
This bug may result in unreliable binary outputs, why is it targeted for fixing
in 4.4.2 and not in 4.4.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--- Comment #1 from ubizjak at gmail dot com 2009-07-15 08:19 ---
Confirmed on i686 (x86_64 with -m32):
Program received signal SIGSEGV, Segmentation fault.
useless_type_conversion_p (outer_type=0x2ac18624b240, inner_type=0x0)
at ../../gcc-svn/trunk/gcc/tree-ssa.c:1003
1003 if
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-07-15 08:13 ---
For:
c += (char) 1;
The value can change as you have a wrapping if c is CHAR_MAX.
Likewise with:
c += c2;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
1 - 100 of 129 matches
Mail list logo
