--- 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 #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 #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 #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 #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 #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 #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 #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 #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
/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
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
--- 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
--- 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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
101 - 129 of 129 matches
Mail list logo
