--- Comment #5 from dberlin at gcc dot gnu dot org 2006-12-15 05:27 ---
Subject: Re: New: std::vector::size() 10x speedup (patch)
And what are the timings with a recent version of g++ and actually
turning on optimization?
On 13 Dec 2006 17:38:06 -, charles at rebelbase dot com
<[
And what are the timings with a recent version of g++ and actually
turning on optimization?
On 13 Dec 2006 17:38:06 -, charles at rebelbase dot com
<[EMAIL PROTECTED]> wrote:
vector::size() in bits/stl_vector.h is currently implemented as
size_type
size() const
{ return s
--- Comment #25 from mkoeppe at gmx dot de 2006-12-15 02:44 ---
Created an attachment (id=12808)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12808&action=view)
patch (part 2 of 2) to fix this bug
This patch (mh-interix.diff) and the previous one (interix-winnt.diff) let me
succe
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-12-15 02:16
---
I will take this on.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
A
--- Comment #24 from mkoeppe at gmx dot de 2006-12-15 02:15 ---
Created an attachment (id=12807)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12807&action=view)
patch (part 1 of 2) to fix this bug
This patch is from PR 28968.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15
--- Comment #4 from patchapp at dberlin dot org 2006-12-15 01:15 ---
Subject: Bug number PR c/19977
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01068.html
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from danglin at gcc dot gnu dot org 2006-12-15 01:12 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01086.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30151
--- Comment #1 from danglin at gcc dot gnu dot org 2006-12-15 01:11 ---
Patch here
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01086.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30174
--- Comment #1 from danglin at gcc dot gnu dot org 2006-12-14 23:21 ---
This is the backtrace that creates the insn:
(gdb) bt
#0 emit_move_sequence (operands=0xc002d508, mode=SImode, scratch_reg=0x0)
at ../../gcc/gcc/config/pa/pa.c:1331
#1 0x002d4fa0 in gen_movsi (operand0=0x400aa
--- Comment #1 from danglin at gcc dot gnu dot org 2006-12-14 23:00 ---
Also fails on hppa-unknown-linux-gnu.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
---
Executing on host: /home/dave/gcc-4.3/objdir/gcc/xgcc
-B/home/dave/gcc-4.3/objdi
r/gcc/ /home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.dg/pr23818.c -O2
-fno-tree-dom
inator-opts -fno-show-column -lm -o ./pr23818.exe(timeout = 300)
/home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.dg/pr23818.c: In functio
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-14 22:34 ---
> How I can correct this error?
Add to the source file:
#include
This comes from the fact the implicit declaration causes different prototype
than what is declared for the builtin functions.
You can either use -fno
I was compiled my aplication correctly with gcc 3.3 on SUSE 9, but now upgrade
SUSE to version 10 and the gcc now is the version 4.1. With the new version
when compile display more warning, example:
/auexes/autra_prod/source/swap/ts/pgm/swap_ts.c: In function âload_track_2â:
/auexes/autra_prod/sou
--- Comment #11 from dfranke at gcc dot gnu dot org 2006-12-14 21:41
---
In reply to comment #1:
Hack "glibc_c99_inline_2" was meant to fix sys/stat.h: but while I have a fixed
$(top_builddir)/gcc/include/sys/stat.h on i686, there is no such file on
x86_64.
These commands where run on
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-14 21:41 ---
Created an attachment (id=12806)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12806&action=view)
Patch for the problem that regtests OK
Daniel,
As our regular contributors of 'real' bugs, you have excelled on
--- Comment #5 from pault at gcc dot gnu dot org 2006-12-14 21:14 ---
Created an attachment (id=12805)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12805&action=view)
A fix for the PR that regtests OK
This is the patch referred to previously.
Paul
--
http://gcc.gnu.org/bugz
--- Comment #4 from pault at gcc dot gnu dot org 2006-12-14 21:12 ---
Harald,
As usual, you provide us with the good ones. This problem arises because the
resolution of intrinsics, if there is no matching specific interface, has been
restricted to generics only. The following effects a
--- Comment #1 from ubizjak at gmail dot com 2006-12-14 19:57 ---
Created an attachment (id=12804)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12804&action=view)
Testcase that crashes for -DSIZE=1 (but not for SIZE >= 4)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30213
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-14
19:55 ---
Subject: Re: FAIL: gcc.dg/builtins-57.c scan-tree-dump trunc
> trunc maybe available in the library, but gcc thinks it is not. Otherwise the
> testcase wouldn't fail - it tests for the transformation of f
The code in attached testcase is taken from povray-3.6.1 and produces a nasty
regression, exposed by new optimized string functions. Please note, that
expanded RTL of pov_calloc() function is OK, but subsequent RTL optimization
(bbro) mixes BBs in the wrong order.
It is evident, that %ebx is clear
--- Comment #12 from dnovillo at gcc dot gnu dot org 2006-12-14 19:50
---
Subject: Bug 30194
Author: dnovillo
Date: Thu Dec 14 19:50:11 2006
New Revision: 119867
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119867
Log:
PR 30194
* gcc.dg/pr19633-1.c: Increase
--- Comment #11 from dnovillo at gcc dot gnu dot org 2006-12-14 19:29
---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > There must be. mem-ssa is @119760. If you can reproduce with @119760,
> > > then
> > > let me know and I'll take a look.
>
Hello gcc bugzilla,
I cannot resolve a problem with gcc.4.1.1 installation
on our server.
At one point during the compile I am getting this error
.
.
mv 'libgcc/sparcv9/tmp-libgcc.map' libgcc/sparcv9/libgcc.map
/usr/local/src/gcc-4.1.1/host-sparc-sun-solaris2.9/gcc/xgcc
-B/usr/local/src/gcc-4
--- Comment #4 from charles at rebelbase dot com 2006-12-14 17:59 ---
(In reply to comment #2)
> Can you test with -O1 or above?
> As mentioned in comment #1, this should remove all advatages gained from the
> "inlined" version.
It does indeed. Thanks for your time.
--
http://gcc.
--- Comment #5 from charles at rebelbase dot com 2006-12-14 17:58 ---
(In reply to comment #1)
> -O1 is enough to remove all advantages of this patch.
>
> Also, that isn't really a fair timing comparison, as you've removed the
> function call altogether (I still expect it to be faster,
--- Comment #3 from bonzini at gnu dot org 2006-12-14 17:46 ---
Don't confuse __builtin_altivec_vmuloub (only used by middle-end, has the
"wrong" types) with __builtin_vec_vmuloub (cannot be created by middle-end,
lowered by the C front-end to __builtin_altivec_vmuloub after checking the
--- Comment #17 from bonzini at gnu dot org 2006-12-14 17:41 ---
It was a mess before too. Anyway, you are confusing compatibility with
"convertible without added casts".
comptypes needs to recur in order to unbreak Altivec builtins. "vector int" and
"vector bool int" for example are d
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-14 17:29 ---
(In reply to comment #1)
> Builtin vmuloub has always returned "wrong" types, because it derives its
> types
> simply from the modes of the altivec_vmuloub pattern.
Except that is wrong. Look at the altivec PIM an
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Target Milestone|--- |4.1.2
http:/
--- Comment #1 from bonzini at gnu dot org 2006-12-14 17:23 ---
Builtin vmuloub has always returned "wrong" types, because it derives its types
simply from the modes of the altivec_vmuloub pattern. For this reason, the C
front-end uses vec_vmuloub instead: this one is expanded by
resolv
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-12-14 17:22 ---
Needs further investigation -> dnovillo (or myself in a few weeks).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-12-14 17:12
---
I think this patch is incorrect in saying vector unsigned int and vector signed
int are compatiable. They are not.
In fact JSM's comment summaries up what __builtin_types_compatible_p means:
compatible != converti
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Target Milestone|--- |4.1.2
http:/
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-12-14 17:02 ---
Created an attachment (id=12803)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12803&action=view)
patch
This is the backport of the relevant parts. Seems to introduce some libjava
failures though.
--- Comment #18 from jacob at math dot jussieu dot fr 2006-12-14 16:47
---
(In reply to comment #15)
> If the loop bounds are compile-time constants you can use template
> metaprogramming to unroll them.
>
I shouldn't elaborate on this as this is not the subject of this bug report,
bu
--- Comment #17 from jacob at math dot jussieu dot fr 2006-12-14 16:34
---
(In reply to comment #15)
> If the loop bounds are compile-time constants you can use template
> metaprogramming to unroll them.
>
ah right, I initially misread "unroll" as "unnest", but it is true that I can
u
--- Comment #2 from gdr at cs dot tamu dot edu 2006-12-14 16:30 ---
Subject: Re: C++ front-end rejects valid compound literal (with complex types)
"rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Even
|
| _Complex double foo (double x)
| {
| return (_Complex double) x
--- Comment #16 from jacob at math dot jussieu dot fr 2006-12-14 16:28
---
(In reply to comment #15)
> If the loop bounds are compile-time constants you can use template
> metaprogramming to unroll them.
>
That is true, I will think about that.
I was also mentionning my loop-unnestin
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-12-14 16:24
---
If the loop bounds are compile-time constants you can use template
metaprogramming to unroll them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
--- Comment #14 from jacob at math dot jussieu dot fr 2006-12-14 16:24
---
I forgot to say that size() is an inline function returning a constant that is
known at compile-time (a template parameter). Otherwise, of course, I wouldn't
expect these loops to get unrolled...
--
http://g
--- Comment #13 from jacob at math dot jussieu dot fr 2006-12-14 16:22
---
(In reply to comment #12)
> Yes. However, all this is only for my reduced testcase without the use of
> the C++ class. For the original testcase, the issues Andrew P. identified
> are still true.
OK, so if I und
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-12-14 16:18 ---
trunc maybe available in the library, but gcc thinks it is not. Otherwise the
testcase wouldn't fail - it tests for the transformation of floor (x) to trunc
(x)
if x is known to be positive.
Now if std=c99 does not
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-14
16:12 ---
Subject: Re: FAIL: gcc.dg/builtins-57.c scan-tree-dump trunc
> It looks like the target does not have trunc (a C99 function). floor (C89)
> and
> lfloor (GCC builtin) are always available.
Actually, tru
--- Comment #12 from bangerth at math dot tamu dot edu 2006-12-14 16:08
---
Subject: Re: gcc doesn't unroll nested loops
> Very interesting, thanks... so does it mean that gcc did loop unrolling after
> all? (sorry, I'm a newbie when it comes to compiler/assembler stuff).
Yes.
> A
--- Comment #11 from jacob at math dot jussieu dot fr 2006-12-14 15:56
---
Very interesting, thanks... so does it mean that gcc did loop unrolling after
all? (sorry, I'm a newbie when it comes to compiler/assembler stuff).
And the speed difference was only caused by the compiler unders
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-12-14 15:46
---
I get on the trunk with -O2 -funroll-loops
main:
.LFB2:
xorl%eax, %eax
.p2align 4,,7
.L2:
cvtsi2sd%eax, %xmm0
addl$1, %eax
cmpl$10, %eax
--- Comment #9 from bangerth at dealii dot org 2006-12-14 15:41 ---
Hm, now, with -DUNROLL, gcc realizes that it writes to data[] all the
times with no reads and moves all the writes out of the loop. I suppose
it's no surprise that the code is fast (the loop looks pretty atrocious,
thoug
--- Comment #8 from bangerth at dealii dot org 2006-12-14 15:35 ---
Here is an analysis of the assembler code we get when using
my first command line in my previous comment, i.e. no hand unrolling.
I'm using 4.1.0, btw.
The main loop looks like this:
--
.L2:
--- Comment #7 from bangerth at dealii dot org 2006-12-14 15:16 ---
I've reduced the code a bit by stripping all C++isms and collapsing
everything into a single function:
---
double data[9];
int main()
{
for( int factor = 0; factor < 10; factor+
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-12-14 14:51 ---
Mine. Bootstrap & regtest running.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dmcr at Princeton dot EDU 2006-12-14 14:51 ---
Thanks for the quick test and reply.
Will upgrade.
Thanks again.
Dennis
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30206
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-12-14 14:39 ---
This was fixed on trunk by
Author: rakdver
Date: Thu Aug 17 08:22:05 2006
New Revision: 116213
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116213
Log:
PR tree-optimization/27865
* tree-vrp
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-12-14 14:28 ---
#2 0x00830b2f in value_ranges_intersect_p (vr0=0x7fff642afd40,
vr1=0x7fff642afd20)
at /space//rguenther/src/svn/gcc-4_1-branch/gcc/tree-vrp.c:625
625 return (value_inside_range (vr1->min, vr0)
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-14 14:12 ---
Confirmed.
Starting program: /abuild/rguenther/gcc41-g/gcc/cc1 -quiet -O2 /tmp/bug.c
Program received signal SIGSEGV, Segmentation fault.
0x00830372 in compare_values (val1=0x0, val2=0x2afe6fd01db0)
at
--- Comment #1 from suehring at hhi dot de 2006-12-14 14:04 ---
Created an attachment (id=12802)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12802&action=view)
Test case
Fails to compile with "gcc -O2 -o gcc-crash gcc-crash.c"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
The C compiler crashes while compilation of a simple test program with
optimizaion -O2 and above.
The bug seems to be triggered by unrolling a loop which contains a "?" operator
inside an array index.
The crash occured on the gcc versions shipped with SuSE 10.2 (GNU C version
4.1.2 20061115 (prer
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-12-14 13:52 ---
It looks like the target does not have trunc (a C99 function). floor (C89) and
lfloor (GCC builtin) are always available.
Does it pass if you add -std=c99?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30181
--- Comment #7 from jean-marc dot valin at usherbrooke dot ca 2006-12-14
13:28 ---
Could be x86-64 only, I don't know. I don't have a plain x86 with gcc 4.1 to
test on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29925
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-14 13:14 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-12-14 13:12 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-14 13:10 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
13.c (test for excess errors)
42919,42920c42882,42883
< # of expected passes 42352
< # of unexpected failures 12
---
> # of expected passes 42317
> # of unexpected failures 11
42926c42889
< /u01/var/tmp/gcc_trunk_svn/gcc_20061214/gcc/xgcc version 4.3.0 20
--- Comment #6 from irar at il dot ibm dot com 2006-12-14 12:41 ---
I couldn't reproduce the problem on x86. I ran it with valgrind
--leak-check=yes, is it correct?
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29925
vec_extract_even/odd are not implemented on ia64. They are used in
vectorization of strided loads, and are implemented only on powerpc (patch
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01679.html (revision 119088)).
The implementation exists on autovect-branch, but it possibly can be more
effici
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #35 from irar at il dot ibm dot com 2006-12-14 11:58 ---
Th problem was solved for i386 by
http://gcc.gnu.org/viewcvs?view=rev&revision=119779.
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #7 from irar at il dot ibm dot com 2006-12-14 11:53 ---
So, it is an altivec bug and not vectorizer's. I opened a new PR 30210 instead.
I think, this PR can be closed.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22372
The return value of builtin function rs6000_builtin_mul_widen_even
for Altivec is always signed, while it should be signed/unsigned
as relevant (builtin vmuloub returns vector signed short, instead of vector
unsigned short, as defined by the altivec PIM).
It seems to be a more general problem wit
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-14 11:21 ---
Even
_Complex double foo (double x)
{
return (_Complex double) x;
}
or
_Complex double foo (double x)
{
return x;
}
does not work. But
_Complex double foo (double x)
{
return x + 1.i;
}
does.
--
htt
--- Comment #4 from pcarlini at suse dot de 2006-12-14 11:18 ---
By the way, forgot that in mainline and 4.2 branch the issue simply doesn't
exist anymore: for completely different reasons, we are *already* using
directly _M_start, _M_finish, and co.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #3 from pcarlini at suse dot de 2006-12-14 10:33 ---
Likewise...
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|WAITING
--- Comment #3 from pcarlini at suse dot de 2006-12-14 10:19 ---
Of course. Please, let's not go along this route: it's very well known that an
efficient and clean implementation on the library (in particular the "STL"
part) relies on very many tiny functions being inlined.
--
pcarli
--- Comment #33 from bkoz at gcc dot gnu dot org 2006-12-14 10:01 ---
FYI:
-fvisibility is broken on 4.0.x.
If you want to use this option, I suggest you use 4.2.x. Both the compiler and
library can handle it, or should be able to handle it.
-benjamin
--
http://gcc.gnu.org/bugzil
73 matches
Mail list logo
