--- 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
--
--- 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.
--
--- 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 #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.
--
--- 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.
--
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
--- 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
--- 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=revrevision=119779.
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
--
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
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
--- 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
)
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 20061214
(experimental)
---
/u01/var/tmp
--- 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
--- 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 #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 #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 #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
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
--- 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=12802action=view)
Test case
Fails to compile with gcc -O2 -o gcc-crash gcc-crash.c
--
--- 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 #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 #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=gccview=revrev=116213
Log:
PR tree-optimization/27865
*
--- 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 #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 #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;
--- 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 #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,
--- 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 #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
--- 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.
And
--- 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, trunc
--- 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
--- 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
--- 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...
--
--- 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 #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-unnesting
--- 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 #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
unroll
--- 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,
but
--- 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=12803action=view)
patch
This is the backport of the relevant parts. Seems to introduce some libjava
failures though.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Target Milestone|--- |4.1.2
--- 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 !=
--- 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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Target Milestone|--- |4.1.2
--- 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 and
--- 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
--- 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 #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, but
--- 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.
--
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
--- 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.
I can
--- 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=gccview=revrev=119867
Log:
PR 30194
* gcc.dg/pr19633-1.c: Increase
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
--- 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
--- 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=12804action=view)
Testcase that crashes for -DSIZE=1 (but not for SIZE = 4)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30213
--- 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
--- 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=12805action=view)
A fix for the PR that regtests OK
This is the patch referred to previously.
Paul
--
--- 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=12806action=view)
Patch for the problem that regtests OK
Daniel,
As our regular contributors of 'real' bugs, you have excelled on
--- 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
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â:
--- 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 string.h
This comes from the fact the implicit declaration causes different prototype
than what is declared for the builtin functions.
You can either
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
--- 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
--- 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
--- 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 #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 #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
--
--- 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=12807action=view)
patch (part 1 of 2) to fix this bug
This patch is from PR 28968.
--
--- 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
--- 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=12808action=view)
patch (part 2 of 2) to fix this bug
This patch (mh-interix.diff) and the previous one (interix-winnt.diff) let me
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
--- 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
73 matches
Mail list logo
