--- Comment #6 from bonzini at gnu dot org 2007-06-11 06:54 ---
can you please show the difference in assembly code between the two?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-06-11 06:36 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00655.html
Patch was also checked with 0.0, __builtin_inf and __builtin_nan, and the
results were the same as for unpatched gcc for all combinations that were
thrown i
--- Comment #2 from stillzhang at tencent dot com 2007-06-11 06:07 ---
Thank you.
But if i compiled it without -O3, it work fine.
If I compiled it under gcc3.3 with -O3, it also work fine.
The same program with different optimize has different, so i think it should
not be like this.
--- Comment #2 from burnus at gcc dot gnu dot org 2007-06-11 06:04 ---
Seems to be fixed since 2007-06-07. -> Close PR.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #24 from tbptbp at gmail dot com 2007-06-11 05:58 ---
Yes, but there's some fuss at 0 when you pile up a NR round.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723
--- Comment #23 from ubizjak at gmail dot com 2007-06-11 05:51 ---
(In reply to comment #22)
> At some point icc did such transformations (for 1/x and sqrt) but, apparently,
> they're now removed. It didn't bother to plug every holes (ie wrt infinities)
> but at least got the case of 0
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-11 04:44 ---
I have a fix from our local tree which also fixes up the regression which we
found with a different patch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #113 from pinskia at gcc dot gnu dot org 2007-06-11 03:41
---
*** Bug 32281 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-11 03:41 ---
So packet is char*, and you are accessing it as uchar*, so this code is
violating C/C++ aliasing rules.
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
When I user gcc4.1.0 to compile mysql4.1.22, I find some errors. I¡¯m not sure
whether it¡¯s a gcc bug or not, so I need your help.
The version of gcc:
gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-l
--- Comment #22 from tbptbp at gmail dot com 2007-06-11 03:32 ---
I'm a bit late to the debate but...
At some point icc did such transformations (for 1/x and sqrt) but, apparently,
they're now removed. It didn't bother to plug every holes (ie wrt infinities)
but at least got the case of
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-06-11 03:06
---
Subject: Bug 32235
Author: jvdelisle
Date: Mon Jun 11 03:06:01 2007
New Revision: 125611
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125611
Log:
2007-06-10 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #1 from tbptbp at gmail dot com 2007-06-11 03:02 ---
s/gcc-4.3-20070105/gcc-4.3-20070608/
--
tbptbp at gmail dot com changed:
What|Removed |Added
S
I lack words to describe what happens on x86-64 to
<-->
#include
__m128i foo(__m128i a) { return _mm_srli_si128(a, 8); }
int main() { return 0; }
<-->
# /usr/local/gcc-4.2-20060916/bin/gcc -
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-06-11 00:53
---
the pointer_plus branch improves the code here (I can't tell if it fixes the
problem fully).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-11 00:48 ---
(In reply to comment #3)
> Interestingly the following code is optimized:
That is because we create a new may_alias variable for malloc to point to so we
know that it cannot alias anything.
--
http://gcc.gnu.org
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-11 00:47
---
There are a couple of issues here, first pointer_plus improves the aliasing set
issue, but then PRE comes around and messes it up because it does not add
pointer types which have DECL_BASED_ON_RESTRICT_P/DECL_GET_R
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-11 00:34
---
> The second case is the following loop:
This is just caused by how we represent pointer addition. I have a fix for
that one, we now get the correct aliasing sets for it.
--
pinskia at gcc dot gnu dot org cha
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-11 00:30 ---
Confirmed, this is only a tree level missed optimization.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-11 00:21 ---
Yes this is fixed on the pointer_plus branch, the pointer_plus branch is better
at keeping track of what the decl is the restrict pointer's base.
-;; *D.1537 = *D.1539 + *D.1537
+;; *D.1538 = *D.1541 + *D.1538
(ins
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-10 22:55 ---
This works on the pointer_plus branch :) Also Predictive commoning fixes it up
even without unrolling at the tree level so it works at -O3 (this is on the
pointer_plus branch I have not tried on the mainline).
--
--- Comment #4 from mckelvey at maskull dot com 2007-06-10 22:52 ---
Created an attachment (id=13674)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13674&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32089
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-06-10 22:50
---
Subject: Bug 32235
Author: jvdelisle
Date: Sun Jun 10 22:50:47 2007
New Revision: 125606
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125606
Log:
2007-06-10 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-06-10 22:41 ---
Complete guess:
alias.c relies not on TYPE_RESTRICT, but on DECL_BASED_ON_RESTRICT_P
I never noticed we even had such a thing :)
My guess is that loop unrolling makes new ssa names, and when they get
transformed du
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-06-10 21:48
---
The other issue is really about this bug, so not splitting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-06-10 21:46
---
PR32279 for 1/sqrt(x/y) to sqrt(y/x)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723
This may even work for -funsafe-math-optimizations only (we round differently).
One has to enumerate all interesting cases (mainly x == 0) and see if NaN/Inf
are properly preserved in all cases.
--
Summary: Fold 1.0/sqrt(x/y) to sqrt(y/x)
Product: gcc
Version: 4.
--- Comment #19 from rguenther at suse dot de 2007-06-10 21:39 ---
Subject: Re: Use reciprocal and reciprocal square root
with -ffast-math
On Sun, 10 Jun 2007, ubizjak at gmail dot com wrote:
>
>
> --- Comment #18 from ubizjak at gmail dot com 2007-06-10 17:34 ---
> (In re
--- Comment #5 from hjl at lucon dot org 2007-06-10 20:58 ---
I have verified that this patch:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00545.html
causes this regression.
--
hjl at lucon dot org changed:
What|Removed |Added
--
--- Comment #4 from hjl at lucon dot org 2007-06-10 20:42 ---
Revision 122761 is bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32275
--- Comment #3 from hjl at lucon dot org 2007-06-10 20:24 ---
Revision 122748 is good.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32275
--- Comment #2 from hjl at lucon dot org 2007-06-10 20:12 ---
(In reply to comment #1)
> Revision 122814 is bad and revision 122792 is good.
>
Correction. Revision 122780 is bad and revision 122738 is good.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32275
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-10 20:07 ---
Danny, as looked at restrict handling a few days ago - maybe you know instantly
why it doesn't work ;) (apart from us not recomputing aliasing after loop
optimizations on the tree level -- and the complete unrolling
--- Comment #28 from awl03 at doc dot ic dot ac dot uk 2007-06-10 19:35
---
Created an attachment (id=13673)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13673&action=view)
Patch for tree-mudflap.c
This is the patch mentioned in my explanation. It is against the 4.1.1 release
s
--- Comment #27 from awl03 at doc dot ic dot ac dot uk 2007-06-10 19:32
---
I have been writing my own bounds-checker based on Mudflap. While doing so I
had to tackle this same problem. My flatmate and I tracked it down to the fact
that, although function parameters and variables are
--- Comment #1 from hjl at lucon dot org 2007-06-10 19:18 ---
Revision 122814 is bad and revision 122792 is good.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32275
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-06-10 18:09 ---
Two points:
- The scoping is correct (i is indeed the same variable)
- i becomes undefined on exit of the implied do loop, so
the code is illegal.
http://groups.google.de/group/comp.lang.fortran/browse_thread/th
--- Comment #18 from ubizjak at gmail dot com 2007-06-10 17:34 ---
(In reply to comment #14)
> The interesting difference between sqrtss, divss and rcpss, rsqrtss is that
> the former have throughput of 1/16 while the latter are 1/1 (latencies compare
> 21 vs. 3). This is on K10. The o
FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect call -> direct
call.* AA transformation on insn
FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect call -> direct
call.* AA transformation on insn
FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect call ->
--- Comment #12 from eweddington at cso dot atmel dot com 2007-06-10 16:50
---
According to a comment in duplicate bug #24894, bug #19636 may be related.
Ralf, can you try the test case using a 4.3 snapshot?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786
FAIL: libmudflap.c++/pass41-frag.cxx execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-O2) execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-O3) execution test
FAIL: libmudflap.c++/pass41-frag.cxx ( -O) execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-static) execution test
--
--- Comment #17 from ubizjak at gmail dot com 2007-06-10 16:49 ---
(In reply to comment #0)
> /* Mathematically equivalent to 1/sqrt(b*(1/a)) */
> return sqrtf(a/b);
Whoa, this one is a little gem, but ATM in the opposite direction. At least for
-ffast-math we could optimize (a /
I got
varargs0: n[1] = 0 expected 1
varargs0: n[2] = 1 expected 2
FAIL: gcc.c-torture/execute/va-arg-24.c execution, -O3 -fomit-frame-pointer
-funroll-loops
varargs0: n[1] = 0 expected 1
varargs0: n[2] = 1 expected 2
FAIL: gcc.c-torture/execute/va-arg-24.c execution, -O3 -fomit-frame-pointe
--- Comment #11 from eweddington at cso dot atmel dot com 2007-06-10 16:43
---
*** Bug 24894 has been marked as a duplicate of this bug. ***
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
-
--- Comment #4 from eweddington at cso dot atmel dot com 2007-06-10 16:43
---
This looks like a duplicate of bug #31786. Closing this bug as #31786 has more
analysis in the comments and is confirmed.
*** This bug has been marked as a duplicate of 31786 ***
--
eweddington at cso dot
I got
Executing on host: /export/build/gnu/gcc/build-ia64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-ia64-linux/gcc/
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/pr31343.c -O2
-ftree-vectorize -fdump-tree-vect-details -fno-show-column -S -o pr31343.s
(timeout = 300)
PASS: g
--- Comment #16 from ubizjak at gmail dot com 2007-06-10 16:24 ---
(In reply to comment #13)
> > x1 = 0.5 X0 (3.0 - A x0 x0 x0)
Whops! One x0 too much above. Correct calcualtion reads:
rsqrt = 0.5 rsqrt(a) (3.0 - a rsqrt(a) rsqrt(a)).
> Well, I suppose it depends on the hardware. IIR
The following two functions are equivalent (especially after loop unrolling):
void
foo(const int *restrict a, int *restrict b, int *restrict c)
{
b[0] += a[0];
c[0] += a[0];
b[1] += a[1];
c[1] += a[1];
}
void
bar(const int *restrict a, int *restrict b, int *restrict c)
{
for (int i = 0
I started bash and ran
../gcc/configure --enable-threads
I then typed make
Here is the output:
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h config/i386/xm-cygwin.h" DEFINES="" \
/bin/sh ../gcc/mkconfig.sh config.h
TARGET_CPU_DEFAULT="" \
HEADERS="options.h con
--- Comment #6 from axel at freakout dot de 2007-06-10 13:00 ---
Subject: Re: gcc 4.2.0 compiled vanilla kernel
2.4.34.5 crashes when VIA C3 optimized -march=c3
please see:
http://www.bnhof.de/~ho1158/gcc-4.2.0-Bug-target-32264.tar.bz2
for the kernle files mentioned above. It is to
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-06-10 12:09
---
And of course optimizing division or square root this way violates IEEE 754
which
specifies these as intrinsic operations. So a separate flag from
-funsafe-math-optimization should be used for this optimization.
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-06-10 12:07
---
The interesting difference between sqrtss, divss and rcpss, rsqrtss is that
the former have throughput of 1/16 while the latter are 1/1 (latencies compare
21 vs. 3). This is on K10. The optimization guide only me
--- Comment #13 from jb at gcc dot gnu dot org 2007-06-10 11:06 ---
(In reply to comment #11)
Thanks for the work.
> First, please note that "divss" instruction is quite _fast_, clocking at 23
> cycles, where approximation with NR step would sum up to 20 cycles, not
> counting load of
--- Comment #12 from ubizjak at gmail dot com 2007-06-10 10:47 ---
Here are the results of mubench insn timings for various x86 processors:
http://mubench.sourceforge.net/results.html (target processor can be
benchmarked by downloading mubench from
http://mubench.sourceforge.net/index.ht
--- Comment #5 from axel at freakout dot de 2007-06-10 10:05 ---
Subject: Re: gcc 4.2.0 compiled vanilla kernel
2.4.34.5 crashes when VIA C3 optimized -march=c3
According to rguenth at gcc dot gnu dot org:
>
> --- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-09 10:27
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-10 09:34
---
*** Bug 32271 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-10 09:34 ---
Actually the warning is correct as the code is undefined at compile time and
this is documented:
# Do not use @code{#if 0} for comments which are not C code. Use a real
# comment, instead. The interior of @code{#i
--- Comment #1 from pcmoen at gmail dot com 2007-06-10 09:25 ---
Created an attachment (id=13672)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13672&action=view)
Test case that shows the error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32271
The preprocessor will report warnings when there is an unterminated ' or " in a
disabled section.
Example code that triggers two warnings:
Code begin
#if 0
This shouln"t cause a problem.
This shouln't cause a problem.
#endif
int
main()
{
return 0;
}
Code end
Output fr
--- Comment #8 from chris at bubblescope dot net 2007-06-10 08:57 ---
Hmm.. I thought I did have a good example, I had a function that looked like:
template
int count_unique(It begin, It end)
{
set counter(begin, end);
return counter.size();
}
But, while you might get multiple copi
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-10 08:38
---
*** Bug 32270 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-10 08:38 ---
Well that is because it was fixed on the trunk last December by:
2006-12-13 Ian Lance Taylor <[EMAIL PROTECTED]>
PR c++/19564
PR c++/19756
This is a dup of bug 19564.
*** This bug has been marked
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-10 08:34 ---
The warning works on the trunk:
[pinskia-laptop:gcc/mips/gcc] pinskia% ./cc1plus t.c -W -Wall
int f(int, int)
t.c:3: warning: suggest parentheses around comparison in operand of &
--
pinskia at gcc dot gnu dot o
--- Comment #11 from ubizjak at gmail dot com 2007-06-10 08:28 ---
I have experimented a bit with rcpss, trying to measure the effect of
additional NR step to the performance. NR step was calculated based on
http://en.wikipedia.org/wiki/N-th_root_algorithm, and for N=-1 (1/A) we can
simp
Hello,
i don't know whether this was already requested way back in 1985, and maybe
there is an evangelical answer to this.
This is a request to add a compiler option for warnings if the evaluation of
operator& and operator== (and similar) may be not 'as expected'. I personally
feel it in most ca
65 matches
Mail list logo
