[Bug libstdc++/16612] empty basic_strings can't live in shared memory
--- 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/bugzilla/show_bug.cgi?id=16612
[Bug libstdc++/30203] std::vector::size() 10x speedup (patch)
--- 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. -- pcarlini at suse dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30203
[Bug libstdc++/30204] std::vector operator[] 10x speedup (patch)
--- 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 |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30204
[Bug libstdc++/30204] std::vector operator[] 10x speedup (patch)
--- 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/show_bug.cgi?id=30204
[Bug c++/30209] C++ front-end rejects valid compound literal (with complex types)
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30209
[Bug target/30210] New: Altivec builtins return wrong types
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 with altivec builtins declaration. Ira -- Summary: Altivec builtins return wrong types Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: irar at il dot ibm dot com GCC build triplet: powerpc*-* GCC host triplet: powerpc*-* GCC target triplet: powerpc*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug tree-optimization/22372] Vectorizer produces mis-match types
--- 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
[Bug middle-end/28752] bootstrap comparision fails with -ftree-vectorize -maltivec on ppc
--- 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 GCC build triplet|powerpc64-linux and i386- |powerpc64-linux |linux | GCC host triplet|powerpc64-linux and i386- |powerpc64-linux |linux | GCC target triplet|powerpc64-linux and i386- |powerpc64-linux |linux | Summary|bootstrap comparision fails |bootstrap comparision fails |with -ftree-vectorize -|with -ftree-vectorize - |maltivec on ppc and i386 |maltivec on ppc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug target/30185] [4.1/4.2/4.3 Regression] ICE with struct and divide
-- 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 | Status|NEW |ASSIGNED Last reconfirmed|2006-12-13 06:40:57 |2006-12-14 12:18:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30185
[Bug target/30211] New: missed optimization: model missing vec_extract_even/odd idioms for ia64
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 efficient (http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01278.html): 2005-12-01 Richard Henderson [EMAIL PROTECTED] * targhooks.c (interleave_vectorize_builtin_extract_evenodd): New. (interleave_vectorize_builtin_extract_even): New. (interleave_vectorize_builtin_extract_odd): New. * targhooks.h: Declare them. * config/i386/i386.c (TARGET_VECTORIZE_BUILTIN_EXTRACT_EVEN): New. (TARGET_VECTORIZE_BUILTIN_EXTRACT_ODD): New. 2005-12-02 Richard Henderson [EMAIL PROTECTED] * config/ia64/ia64.c (TARGET_VECTORIZE_BUILTIN_EXTRACT_EVEN): New. (TARGET_VECTORIZE_BUILTIN_EXTRACT_ODD): New. 2006-09-28 Ira Rosen [EMAIL PROTECTED] * targhooks.c (interleave_vectorize_builtin_extract_evenodd): Fix to produce a correct instructions sequence. * tree-vect-transform.c (vect_permute_store_chain): Choose the correct instruction according to the endianness. Call mark_new_vars_to_rename. Once the above is merged, we can add ia64 to the list of targets that support check_effective_target_vect_extract_even_odd in testsuite/lib/target-support.exp. Ira -- Summary: missed optimization: model missing vec_extract_even/odd idioms for ia64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: irar at il dot ibm dot com GCC build triplet: ia64-*-* GCC host triplet: ia64-*-* GCC target triplet: ia64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30211
[Bug tree-optimization/29925] Wrong code with -ftree-vectorize
--- 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
[Bug tree-optimization/19633] local address incorrectly thought to escape
--- Comment #12 from brett dot albertson at stratech dot com 2006-12-14 12:55 --- This testcase started failing for me as of last night on trunk. 1c1 Test Run By root on Thu Dec 14 06:04:39 2006 --- Test Run By root on Wed Dec 13 06:04:24 2006 cut for space saving . 30945,30946c30909,30910 FAIL: gcc.dg/pr19633-1.c (test for excess errors) WARNING: gcc.dg/pr19633-1.c compilation failed to produce executable --- PASS: gcc.dg/pr19633-1.c (test for excess errors) PASS: gcc.dg/pr19633-1.c execution test 39056d39019 PASS: gcc.dg/tls/opt-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 20061214 (experimental) --- /u01/var/tmp/gcc_trunk_svn/gcc_20061213/gcc/xgcc version 4.3.0 20061213 (experimental) I run on Solaris 10 x86. I can provide more information as needed. Brett Albertson -- brett dot albertson at stratech dot com changed: What|Removed |Added CC||brett dot albertson at ||stratech dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19633
[Bug middle-end/30198] __real / __imag cexpi (x) can be folded to cos (x) / sin (x)
--- 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|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30198
[Bug middle-end/30172] Operations with partly constant complex values not folded
--- 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|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30172
[Bug middle-end/30197] cexp ( __complex__ ( 0, x ) ) can be folded to cexpi (x)
--- 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|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30197
[Bug tree-optimization/29925] Wrong code with -ftree-vectorize
--- 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
[Bug testsuite/30181] FAIL: gcc.dg/builtins-57.c scan-tree-dump trunc
--- 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
[Bug c/30212] New: C Compiler crash on loop optimization
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 (prerelease) (SUSE Linux) (i586-suse-linux) ) and Ubuntu 6.10 (gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) ) Here is the output from SuSE: [EMAIL PROTECTED]:~/projects/gcc-crash gcc -v -save-temps -O2 -o gcc-crash gcc-crash.c Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix=-4.1 --enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=i586-suse-linux Thread model: posix gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) /usr/lib/gcc/i586-suse-linux/4.1.2/cc1 -E -quiet -v gcc-crash.c -mtune=generic -O2 -fpch-preprocess -o gcc-crash.i #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc/i586-suse-linux/4.1.2/include /usr/lib/gcc/i586-suse-linux/4.1.2/../../../../i586-suse-linux/include /usr/include End of search list. /usr/lib/gcc/i586-suse-linux/4.1.2/cc1 -fpreprocessed gcc-crash.i -quiet -dumpbase gcc-crash.c -mtune=generic -auxbase gcc-crash -O2 -version -o gcc-crash.s GNU C version 4.1.2 20061115 (prerelease) (SUSE Linux) (i586-suse-linux) compiled by GNU C version 4.1.2 20061115 (prerelease) (SUSE Linux). GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64527 Compiler executable checksum: 56c778b1bb718636fb229d3eaf03526e gcc-crash.c: In function \u2018test_crash\u2019: gcc-crash.c:4: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugs.opensuse.org for instructions. -- Summary: C Compiler crash on loop optimization Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: suehring at hhi dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30212
[Bug c/30212] C Compiler crash on loop optimization
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30212
[Bug tree-optimization/30212] [4.1 Regression] C Compiler crash on loop optimization
--- 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 /space//rguenther/src/svn/gcc-4_1-branch/gcc/tree-vrp.c:431 431 gcc_assert (POINTER_TYPE_P (TREE_TYPE (val1)) This is a regression from 4.1.1. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.2 Known to work||4.1.0 4.1.1 Last reconfirmed|-00-00 00:00:00 |2006-12-14 14:12:09 date|| Summary|C Compiler crash on loop|[4.1 Regression] C Compiler |optimization|crash on loop optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30212
[Bug tree-optimization/30212] [4.1 Regression] C Compiler crash on loop optimization
--- 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) == 1
(gdb) print *vr1
$1 = {type = VR_RANGE, min = 0x2b0646d85d50, max = 0x0, equiv = 0xdf5978}
coming from
static void
adjust_range_with_scev (value_range_t *vr, struct loop *loop, tree stmt,
tree var)
{
...
else if (vr-type == VR_RANGE)
{
tree min = vr-min;
tree max = vr-max;
...
else
{
/* If INIT is bigger than VR-MIN, set VR-MIN to INIT. */
if (compare_values (init, min) == 1)
{
min = init;
/* If we just created an invalid range with the minimum
greater than the maximum, take the maximum all the
way to +INF. */
if (compare_values (min, max) == 1)
max = TYPE_MAX_VALUE (TREE_TYPE (max));
}
}
set_value_range (vr, VR_RANGE, min, max, vr-equiv);
where we set max to TYPE_MAX_VALUE (TREE_TYPE (max)), but the original
max of range has pointer type bounds which don't have TYPE_MIN/MAX_VALUEs set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30212
[Bug tree-optimization/30212] [4.1 Regression] C Compiler crash on loop optimization
--- 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
* tree-vrp.c (adjust_range_with_scev): Do not use TYPE_{MIN,MAX}_VALUE
for pointer types.
* tree-scalar-evolution.c (fold_used_pointer_cast, pointer_offset_p,
fold_used_pointer, pointer_used_p): New functions.
(analyze_scalar_evolution_1): Use fold_used_pointer.
* tree-chrec.c (convert_affine_scev): Convert no-op casts correctly.
* tree-ssa-loop-ivopts.c (generic_type_for): Return integral type
for pointers.
I'll backport the vrp changes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30212
[Bug fortran/30206] Fatal Error: Reading module: Bad name
--- 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
[Bug tree-optimization/30212] [4.1 Regression] C Compiler crash on loop optimization
--- 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 AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-12-14 14:12:09 |2006-12-14 14:51:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30212
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- 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++ )
{
#ifdef UNROLL
data[ 0 + 3 * 0 ] = factor;
data[ 1 + 3 * 0 ] = 0;
data[ 2 + 3 * 0 ] = 0;
data[ 0 + 3 * 1 ] = 0;
data[ 1 + 3 * 1 ] = factor;
data[ 2 + 3 * 1 ] = 0;
data[ 0 + 3 * 2 ] = 0;
data[ 1 + 3 * 2 ] = 0;
data[ 2 + 3 * 2 ] = factor;
#else
for( int i = 0; i 3; i++ )
for( int j = 0; j 3; j++ )
data[i + 3 * j] = (i == j) * factor;
#endif
}
}
-
For this, we get these results:
g/x gcc x.c -O3 -funroll-loops -std=c99
g/x time ./a.out
real0m9.380s
user0m9.381s
sys 0m0.000s
g/x gcc x.c -O3 -funroll-loops -std=c99 -DUNROLL
g/x time ./a.out
real0m0.420s
user0m0.420s
sys 0m0.000s
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- 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: pushl %edx// push 'factor' xorl%eax, %eax // eax=0 fildl (%esp) // st(0)=(double)factor addl$1, %edx// ++factor fstldata// data[0]=factor movl%eax, (%esp)// push 0 fildl (%esp) // st(0)=0 addl$4, %esp cmpl$10, %edx fstldata+24 // data[3]=0 fstldata+48 // data[6]=0 fstldata+8 // data[1]=0 fxch%st(1) // st(0)=factor fstldata+32 // data[4]=factor fxch%st(1) // st(0)=0 fstldata+56 // data[7]=0 fstldata+16 // data[2]=0 fstpl data+40 // data[5]=0; st(0)=factor fstpl data+64 // data[8]=factor jne .L2 - I can find several things wrong with this: a/ the sequence xorl%eax, %eax movl%eax, (%esp) fildl (%esp) could certainly be made more efficient by using fldz. b/ I find the use of fstpl at the end of the loop quite ingenious, since it avoids another fxch. However, the two uses of fxch in the middle may nevertheless be avoided if we manage to realize that we can reorder all those stores. So, in summary, it is not that gcc doesn't realize that it can unroll these loops -- it actually does that, the slowdown comes from other places. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- 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, though, and is not collapsed to anything reasonable, though). Of course, this is what should have happened with the original code as well. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- 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 movq$0, data+24(%rip) movq$0, data+48(%rip) movq$0, data+8(%rip) movq$0, data+56(%rip) movq$0, data+16(%rip) movq$0, data+40(%rip) movsd %xmm0, data(%rip) movsd %xmm0, data+32(%rip) movsd %xmm0, data+64(%rip) jne .L2 xorl%eax, %eax ret it doesn't look like we can do better w/o cheating and moving the benchmark-loop-invariant movq $0 out of the loop ;) The UNROLL variant looks like .L2: leal8(%rdx), %ecx addl$9, %edx movq$0, data+8(%rip) cmpl$10, %edx movq$0, data+16(%rip) movq$0, data+24(%rip) cvtsi2sd%ecx, %xmm0 movq$0, data+40(%rip) movq$0, data+48(%rip) movq$0, data+56(%rip) movsd %xmm0, data(%rip) movsd %xmm0, data+32(%rip) movsd %xmm0, data+64(%rip) jne .L2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- 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 understanding that it didn't need to loop 100,000,000 times? What happened to the idea that gcc didn't unroll nested loops? So does it unroll them after all? - Mr. Newbie -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- 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 the speed difference was only caused by the compiler understanding that it didn't need to loop 100,000,000 times? 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. W. - Wolfgang Bangerthemail:[EMAIL PROTECTED] www: http://www.math.tamu.edu/~bangerth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug testsuite/30181] FAIL: gcc.dg/builtins-57.c scan-tree-dump trunc
--- 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 is available on HP-UX 11. Does it pass if you add -std=c99? No. The test passes on the hppa-linux target where __builtin_trunc is used instead of __builtin_floor in function foo. Don't know why. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30181
[Bug testsuite/30181] FAIL: gcc.dg/builtins-57.c scan-tree-dump 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 not help I can only make this a link-time testcase like
(-ffinite-math-only to allow folding the FP comparison).
That does work, right?
/* { dg-do link } */
/* { dg-options -std=c99 -ffinite-math-only } */
#include builtins-config.h
extern void link_error (void);
extern double floor (double);
extern double trunc (double);
extern double fabs (double);
void test (double x)
{
#ifdef HAVE_C99_RUNTIME
if (floor (fabs (x)) != trunc (fabs (x)))
link_error ();
#endif
if (__builtin_lfloor (fabs (x)) != (long)fabs (x))
link_error ();
}
int main (void)
{
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30181
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- 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 understand well the problem that gcc doesn't unroll nested loops
exists only for C++, not for C ? That seems so strange to me, but then again I
don't know much about compilers.
So now I need to make a decision for my C++ project. I am planning to unfold
nested loops into normal loops, for instance replace
for( col = 0; col size(); col++)
for( row = 0; row size(); row++)
{
...
}
with
for( int foo = 0; foo size() * size(); foo++)
{
col = foo / size();
row = foo % size();
...
}
Do you think this will help solve my problem? Do you see a better solution?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- 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
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- 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 idea to see if you saw immediately something wrong with it, but since you seem to agree that loop-unnesting is the way to go, I'll go ahead with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug c++/30209] C++ front-end rejects valid compound literal (with complex types)
--- 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;
| }
|
| or
|
| _Complex double foo (double x)
| {
| return x;
| }
|
| does not work. But
|
| _Complex double foo (double x)
| {
| return x + 1.i;
| }
|
| does.
I believe there was a long thread about this for the C++ front-end.
The issue is that _Complex is a new fundamental type, ttherefore needs
elaboration about ordering conversion rules, including overload
resolution. The issue was coumponded by the fact that C++ has a class
template complex with slightly different rules.
I don't remember what the conclusion was.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30209
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- 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 loops with template metaprogramming. Then, no need to unnest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- 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 anyway... I can't do template unrolling, because actually my template classes are part of a complicated CRTP (curiously recurring template pattern) where size() is a wrapper around a method in a template parameter, and depending on this parameter, size() may or may not be known at compile time. The idea is that when you write a library for matrices/vectors, it's always a dilemma whether the size (dimension) of the matrices/vectors should be a template parameter(hence fixed at compile-time) or a variable. In the first approach the coords of the matrix/vector are stored in a T array[Size], in the second approach they are dynamically allocated with array=new T[Size]. Both approaches have their pro's and con's, and the killer feature of my library is that it allows both with the same underlying C++ code. This is where the CRTP is useful. So size() returns a compile-time constant in the first approach, and a variable in the second one. And I would like the loops to get unrolled only in the first approach (and, if possible, only if the size is not too large). So template metaprogramming for that, while probably possible, would be much hassle. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug tree-optimization/30212] [4.1 Regression] C Compiler crash on loop optimization
--- 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. === libjava tests === Running target unix FAIL: FileHandleGcTest execution - source compiled test FAIL: FileHandleGcTest execution - gij test FAIL: FileHandleGcTest -O3 execution - source compiled test FAIL: PR3096 execution - gij test FAIL: PR3096 execution - gij test FAIL: Thread_Monitor execution - gij test FAIL: Thread_Monitor execution - gij test FAIL: err4 execution - gij test FAIL: err4 execution - gij test FAIL: indirect execution - gij test FAIL: indirect execution - gij test FAIL: search_outer execution - gij test FAIL: search_outer execution - gij test FAIL: tp execution - gij test FAIL: tp execution - gij test FAIL: update_outer output - gij test FAIL: update_outer output - gij test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30212
[Bug tree-optimization/30212] [4.1 Regression] C Compiler crash on loop optimization
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30212
[Bug target/14899] [4.0 Regression] wrong code due to change in compatibility rules for vector types
--- 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 != convertiable. I think we should have committed the patch in comment #5 and fixed up the testsuite instead. This has now become a mess, it causes lots of bugs in both the back-end (PR 30210 for an example) and accepting of invalid code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14899
[Bug tree-optimization/30212] [4.1 Regression] C Compiler crash on loop optimization
--- 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 AssignedTo|rguenth at gcc dot gnu dot |dnovillo at redhat dot com |org | Severity|normal |major Target Milestone|4.1.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30212
[Bug target/30210] Altivec builtins return wrong types
--- 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 resolve_overloaded_builtin to add the appropriate casts on both the arguments and the results. The way to solve this bug could be to pass the two operands to rs6000_builtin_mul_widen_even, and get back the fully-built tree, including conversions to the appropriate return type. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug tree-optimization/30212] [4.1 Regression] C Compiler crash on loop optimization
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30212
[Bug target/30210] Altivec builtins return wrong types
--- 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 you will see it returns
vector unsigned short.
Take the following testcase:
#include altivec.h
vector unsigned short f(vector unsigned char a, vector unsigned char b)
{
return vec_vmuloub(a, b);
}
This should work even if we cannot assign from vector signed short to vector
unsigend short.
I think this whole type issue is a mess and needs some improvement.
Maybe next week I can get to that.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-12-14 17:29:55
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug target/14899] [4.0 Regression] wrong code due to change in compatibility rules for vector types
--- 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 different types with the same mode; yet, they must be differentiated by comptypes (at that time, this was done with __builtin_types_compatible_p, while now it is done in resolve_overloaded_builtin) or Altivec does not work. This is *absolutely* not related to PR30210, which looks to me more like a misunderstanding of the low-level Altivec builtins (i.e. those emitted by resolve_overloaded_builtin) by the vectorizer folks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14899
[Bug target/30210] Altivec builtins return wrong types
--- 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 parameter types are correct). The types of __builtin_altivec_vmuloub don't have anything to do with what the PIM manual says. And anyway, __builtin_altivec_vmuloub can have the wrong types because it is always decorated with the appropriate NOP_EXPRs: this may be bad from a memory usage point of view, but it is not incorrect. Also, note that it has always worked this way: what changed is *who* does the lowering (either a preprocessor macro vec_vmuloub, or resolve_overloaded_builtin starting from builtin __builtin_vec_vmuloub). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug libstdc++/30204] std::vector operator[] 10x speedup (patch)
--- 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 possibly not by 10x) Yes, you're right. Thanks for looking at this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30204
[Bug libstdc++/30203] std::vector::size() 10x speedup (patch)
--- 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.gnu.org/bugzilla/show_bug.cgi?id=30203
gcc.4.1.1 compile error
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.1.1/host-sparc-sun-solaris2.9/gcc/
-B/usr/local/gcc-4.1.1/sparc-sun-solaris2.9/bin/
-B/usr/local/gcc-4.1.1/sparc-sun-solaris2.9/lib/
-isystem /usr/local/gcc-4.1.1/sparc-sun-solaris2.9/include -isystem
/usr/local/gcc-4.1.1/sparc-sun-solaris2.9/sys-include -O2 -O2 -g -O2
-DIN_GCC-W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include
-fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared
-nodefaultlibs
-Wl,-h,libgcc_s.so.1 -Wl,-z,text -Wl,-z,defs -Wl,-M,libgcc/sparcv9/libgcc.map
-o
sparcv9/libgcc_s.so.1.tmp -m64 libgcc/sparcv9/_muldi3_s.o
libgcc/sparcv9/_negdi2_s.o
libgcc/sparcv9/_lshrdi3_s.o libgcc/sparcv9/_ashldi3_s.o
libgcc/sparcv9/_ashrdi3_s.o
libgcc/sparcv9/_cmpdi2_s.o libgcc/sparcv9/_ucmpdi2_s.o
libgcc/sparcv9/_floatdidf_s.o
libgcc/sparcv9/_floatdisf_s.o libgcc/sparcv9/_fixunsdfsi_s.o
libgcc/sparcv9/_fixunssfsi_s.o
libgcc/sparcv9/_fixunsdfdi_s.o libgcc/sparcv9/_fixdfdi_s.o
libgcc/sparcv9/_fixunssfdi_s.o
libgcc/sparcv9/_fixsfdi_s.o libgcc/sparcv9/_fixxfdi_s.o
libgcc/sparcv9/_fixunsxfdi_s.o
libgcc/sparcv9/_floatdixf_s.o libgcc/sparcv9/_fixunsxfsi_s.o
libgcc/sparcv9/_fixtfdi_s.o
libgcc/sparcv9/_fixunstfdi_s.o libgcc/sparcv9/_floatditf_s.o
libgcc/sparcv9/_clear_cache_s.o
libgcc/sparcv9/_enable_execute_stack_s.o libgcc/sparcv9/_trampoline_s.o
libgcc/sparcv9/__main_s.o
libgcc/sparcv9/_absvsi2_s.o libgcc/sparcv9/_absvdi2_s.o
libgcc/sparcv9/_addvsi3_s.o
libgcc/sparcv9/_addvdi3_s.o libgcc/sparcv9/_subvsi3_s.o
libgcc/sparcv9/_subvdi3_s.o
libgcc/sparcv9/_mulvsi3_s.o libgcc/sparcv9/_mulvdi3_s.o
libgcc/sparcv9/_negvsi2_s.o
libgcc/sparcv9/_negvdi2_s.o libgcc/sparcv9/_ctors_s.o
libgcc/sparcv9/_ffssi2_s.o
libgcc/sparcv9/_ffsdi2_s.o libgcc/sparcv9/_clz_s.o libgcc/sparcv9/_clzsi2_s.o
libgcc/sparcv9/_clzdi2_s.o libgcc/sparcv9/_ctzsi2_s.o
libgcc/sparcv9/_ctzdi2_s.o
libgcc/sparcv9/_popcount_tab_s.o libgcc/sparcv9/_popcountsi2_s.o
libgcc/sparcv9/_popcountdi2_s.o
libgcc/sparcv9/_paritysi2_s.o libgcc/sparcv9/_paritydi2_s.o
libgcc/sparcv9/_powisf2_s.o
libgcc/sparcv9/_powidf2_s.o libgcc/sparcv9/_powixf2_s.o
libgcc/sparcv9/_powitf2_s.o
libgcc/sparcv9/_mulsc3_s.o libgcc/sparcv9/_muldc3_s.o
libgcc/sparcv9/_mulxc3_s.o
libgcc/sparcv9/_multc3_s.o libgcc/sparcv9/_divsc3_s.o
libgcc/sparcv9/_divdc3_s.o
libgcc/sparcv9/_divxc3_s.o libgcc/sparcv9/_divtc3_s.o
libgcc/sparcv9/_divdi3_s.o
libgcc/sparcv9/_moddi3_s.o libgcc/sparcv9/_udivdi3_s.o
libgcc/sparcv9/_umoddi3_s.o
libgcc/sparcv9/_udiv_w_sdiv_s.o libgcc/sparcv9/_udivmoddi4_s.o
libgcc/sparcv9/unwind-dw2_s.o
libgcc/sparcv9/unwind-dw2-fde_s.o libgcc/sparcv9/unwind-sjlj_s.o
libgcc/sparcv9/gthr-gnat_s.o
libgcc/sparcv9/unwind-c_s.o -lc rm -f sparcv9/libgcc_s.so if [ -f
sparcv9/libgcc_s.so.1 ];
then mv -f sparcv9/libgcc_s.so.1 sparcv9/libgcc_s.so.1.backup; else true; fi
mv
sparcv9/libgcc_s.so.1.tmp sparcv9/libgcc_s.so.1 ln -s libgcc_s.so.1
sparcv9/libgcc_s.so
ld: warning: option -YP appears more than once, first setting taken
ld: fatal: file /usr/ccs/lib/values-Xa.o: wrong ELF class: ELFCLASS32
ld: fatal: File processing errors. No output written to
sparcv9/libgcc_s.so.1.tmp
collect2: ld returned 1 exit status
make[3]: *** [sparcv9/libgcc_s.so] Error 1
make[3]: Leaving directory
`/usr/local/src/gcc-4.1.1/host-sparc-sun-solaris2.9/gcc'
make[2]: *** [stmp-multilib] Error 2
make[2]: Leaving directory
`/usr/local/src/gcc-4.1.1/host-sparc-sun-solaris2.9/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/usr/local/src/gcc-4.1.1'
make: *** [all] Error 2
I have found in the GCC Bugzilla Bug 13291 a recommendation
to use the configure with --disable-multilib (not to build
64-bit target libraries). I am using these configure options
./configure --prefix=/usr/local/gcc.4.1.1 --disable-multilib --disable-nls
I am attaching the config.log and config.status
Thanks for your help
--
Ivan Matousek, CSTS Email:matousek{at}cs{dot}sfu{dot}ca
School of Computing Science
Simon Fraser University Phone: (604) 291-4422
Burnaby, B.C. V5A 1S6 Canada Fax: (604) 291-3045
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
configure:600: checking host system type
configure:621: checking target system type
configure:639: checking build system type
configure:694: checking for a BSD compatible install
configure:747: checking whether ln works
configure:771: checking whether ln -s works
configure:1825: checking for gcc
configure:1938: checking whether the C
[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline
--- 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 reproduce it at @119761 which is the same revision for the trunk as
119761 was a revision on a branch.
OK, I'll take a look. FX mind sending me that data about the test? I can't
reproduce it locally.
Oh, boy. Now I see it. We are making different partitioning decisions because
the order of the symbols in the partitioned alias set changed. So, sometimes
we get one SFT into a partition which just happens to cross a call-site, and if
it's added to the partition, we miss the optimization. In this case, the SFT
associated with b.s.w is added to MPT.69.
L1:;
# MPT.69_8 = VDEF MPT.69_7(D) { MPT.69 }
b.s.w = 3;
# VUSE SFT.54_9(D), SFT.55_10(D), SFT.56_11(D) { SFT.54 SFT.55 SFT.56
SFT.62 }
# SFT.62_13 = VDEF SFT.62_12(D)
# MPT.69_14 = VDEF MPT.69_8 { SFT.62 MPT.69 }
x = bar1 (*c_1, *c_1);
# VUSE MPT.69_14 { MPT.69 }
D.1993_6 = b.s.w;
But if aliases are stored in different order in the alias set (different
DECL_UID assignment), we just happen not to choose this SFT for partitioning,
leaving the IL as:
L1:;
# SFT.61_8 = VDEF SFT.61_7(D) { SFT.61 }
b.s.w = 3;
# VUSE SFT.58_9(D), SFT.59_10(D), SFT.60_11(D), SFT.61_8 { SFT.58 SFT.59
SFT.60 SFT.61 }
# MPT.69_13 = VDEF MPT.69_12(D) { MPT.69 }
x = bar1 (*c_1, *c_1);
# VUSE SFT.61_8 { SFT.61 }
D.1990_6 = b.s.w;
I will workaround this by increasing partitioning thresholds on this test, for
now, but I will leave the PR assigned to me while I figure out better
partitioning heuristics.
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-12-14 19:29:22
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline
--- 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 threshold for partitioning temporarily. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr19633-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug rtl-optimization/30213] New: Wrong code with optimized memset() (possible bug in RTL bbro optimizer)
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 cleared in BB4, and dies in BB5. This dump is from
_.148r.rnreg:
--cut here--
;; Start of basic block 4, registers live: 0 [ax] 1 [dx] 4 [si] 5 [di] 6 [bp] 7
[sp] 20 [frame]
;; Pred edge 3 [40.0%] (fallthru)
(note:HI 72 29 119 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 119 72 31 4 (parallel [
(set (reg:SI 3 bx [68])
(const_int 0 [0x0]))
(clobber (reg:CC 17 flags))
]) 38 {*movsi_xor} (nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(note:HI 31 119 89 4 NOTE_INSN_DELETED)
(insn 89 31 33 4 (set (reg:CCZ 17 flags)
(compare:CCZ (and:SI (reg:SI 0 ax [orig:59 block ] [59])
(const_int 1 [0x1]))
(const_int 0 [0x0]))) 286 {testsi_1} (nil)
(expr_list:REG_DEAD (reg:SI 0 ax [orig:59 block ] [59])
(nil)))
(jump_insn:HI 33 89 73 4 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 36)
(pc))) 530 {*jcc_1} (insn_list:REG_DEP_TRUE 32 (nil))
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(expr_list:REG_BR_PROB (const_int 9000 [0x2328])
(nil
;; End of basic block 4, registers live: 1 [dx] 3 [bx] 4 [si] 5 [di] 6 [bp] 7
[sp] 20 [frame]
;; Succ edge 6 [90.0%]
;; Succ edge 5 [10.0%] (fallthru)
;; Start of basic block 5, registers live: 1 [dx] 3 [bx] 4 [si] 5 [di] 6 [bp] 7
[sp] 20 [frame]
;; Pred edge 4 [10.0%] (fallthru)
(note:HI 73 33 95 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 95 73 34 5 (set (reg:QI 0 ax)
(reg:QI 3 bx)) 55 {*movqi_1} (nil)
(nil))
(insn:HI 34 95 35 5 (parallel [
(set (mem:QI (reg/f:SI 5 di [orig:67 block ] [67]) [0 S1 A8])
(reg:QI 0 ax))
(set (reg/f:SI 5 di [orig:67 block ] [67])
(plus:SI (reg/f:SI 5 di [orig:67 block ] [67])
(const_int 1 [0x1])))
]) 720 {*strsetqi_1} (nil)
(expr_list:REG_DEAD (reg:QI 0 ax)
(nil)))
--cut here--
However, _.149.bbro renames BB4 and BB5 into BB12 and BB17 respectively, where
BB12 can be reached _conditionally_ from BB3.
This produces wrong code for pov_calloc():
--cut here--
movl%eax, %esi #, block
testl %eax, %eax # block
je .L4 #, check for NULL
movl%ebx, %edx # actsize, actsize
movl%eax, %edi # block, block
cmpl$3, %ebx#, actsize memset check for 4
ja .L13#, jump only for 4
testb $2, %dl #, actsize
jne .L14#, here we go with wrong %ebx
.L9:
andb$1, %dl #, actsize
jne .L15#, here too.
.L4:
movl%esi, %eax # block, result
addl$16, %esp #,
popl%ebx#
popl%esi#
popl%edi#
popl%ebp#
ret
.L15:
movl%ebx, %eax #, wrong %ebx moved to %eax
stosb FUBAR 2.
movl%esi, %eax # block, result
addl$16, %esp #,
popl%ebx#
popl%esi#
popl%edi#
popl%ebp#
ret
.L14:
movl%ebx, %eax #, wrong %ebx moved to %eax
stosw FUBAR 1.
andb$1, %dl #, actsize
je .L4 #,
jmp .L15#
.L13:
xorl%ebx, %ebx # tmp68 %ebx is cleared here!!
testb $1, %al #, block
jne .L16#,
.L7:
testl $2, %edi#, block
.p2align 4,,5
jne .L17#,
.L8:
movl%edx, %ecx # actsize, tmp71
shrl$2, %ecx#, tmp71
movl%ebx, %eax # tmp68,
rep
stosl
testb $2, %dl #, actsize
je .L9 #,
jmp .L14#
.L16:
movl%ebx, %eax #, this part is OK, but for size 4
stosb
subl$1, %edx#, actsize
jmp .L7 #
.L17:
movl%ebx, %eax #, this part is OK, but for size 4
stosw
subl$2, %edx#, actsize
jmp .L8 #
--cut here--
This can be confirmed by running the testcase:
gcc -O2 -m32 -march=pentium4 -minline-all-stringops -DSIZE=1 mem.c
./a.out
Aborted
gcc -O2 -m32 -march=pentium4 -minline-all-stringops -DSIZE=2 mem.c
./a.out
Aborted
gcc -O2 -m32 -march=pentium4 -minline-all-stringops -DSIZE=4 mem.c
./a.out
echo $?
0
--
Summary: Wrong
[Bug testsuite/30181] FAIL: gcc.dg/builtins-57.c scan-tree-dump trunc
--- 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 floor (x) to trunc (x) if x is known to be positive. If I understand correctly, the transformation only occurs when TARGET_C99_FUNCTIONS is true. In the linux case, this depends on OPTION_GLIBC. Can't figure out how OPTION_GLIBC gets defined... It would be really nice if there was a way for a target to say which C99 functions are implicitly available when it has a partial set. Possibly, this code could be modified to add a target callback: if (implicit_p) implicit_built_in_decls[(int) fncode] = decl; For example, something like: if (implicit_p targetm.implicit_built_in_p (fncode)) implicit_built_in_decls[(int) fncode] = decl; Doing this might create a few problems for the libraries and testsuite, but it should improve code optimization. Now if std=c99 does not help I can only make this a link-time testcase like (-ffinite-math-only to allow folding the FP comparison). That does work, right? The test program works. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30181
[Bug rtl-optimization/30213] Wrong code with optimized memset() (possible bug in RTL bbro optimizer)
--- 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
[Bug fortran/30081] Interface bug overloading random_seed, random_number
--- 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 cure and regtests OK. I will submit it with a suitable rendition of your testscase, as soon as I am back home. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-12-07 18:49:57 |2006-12-14 21:12:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30081
[Bug fortran/30081] Interface bug overloading random_seed, random_number
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30081
[Bug fortran/29992] INTERFACE equivalent to MODULE PROCEDURE?!
--- 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 this one. Thanks! It turns out that we do not have any means to identify a 'module procedure'. The attribute PROC_MODULE defines any procedure defined in a module. I have added a proc_mod attribute that marks a specific procedure that is so declared to overcome this. If anybody has a nifty way around this, please let me know. The attached does the right thing, regtests OK and, in addition, prevents such interfaces from being use associated. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29992
[Bug target/29867] [4.3 Regression] building libgfortran fails because of multiple definitions gcc-4.3-20061111
--- 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 x86_64:
$ find /usr -name stat.h
/usr/include/asm/stat.h
/usr/include/sys/stat.h
/usr/include/bits/stat.h
/usr/include/linux/stat.h
/usr/include/i386-linux/asm/stat.h
/usr/include/x86_64-linux/sys/stat.h
/usr/include/x86_64-linux/bits/stat.h
/usr/include/i486-linux/sys/stat.h
/usr/include/i486-linux/bits/stat.h
$ grep extern __inline__ int /usr/include/sys/stat.h
[no output]
$ grep extern __inline__ int /usr/include/x86_64-linux/sys/stat.h
extern __inline__ int stat (__const char *__path,
[6 more lines snipped]
(extern __inline__ int is the SELECT statement in fix glibc_c99_inline_2)
For me, compilation bails out because of header files included from
/usr/include/x86_64-linux/.
Below, a verbose log of `make stmp-fixinc` (pwd=$(top_builddir)/gcc):
$ rm -rf include/ stmp-fixinc
$ VERBOSE=9
$ make stmp-fixinc
rm -rf include; mkdir include
chmod a+rx include
if [ -d ../prev-gcc ]; then \
cd ../prev-gcc \
make real-install-headers-tar DESTDIR=`pwd`/../gcc/ \
libsubdir=. ; \
else \
(TARGET_MACHINE='x86_64-pc-linux-gnu'; srcdir=`cd ../../../svn/gcc-head/gcc;
${PWDCMD-pwd}`; \
SHELL='/bin/sh'; MACRO_LIST=`${PWDCMD-pwd}`/macro_list ; \
export TARGET_MACHINE srcdir SHELL MACRO_LIST \
cd ../build-x86_64-linux/fixincludes \
/bin/sh ./fixinc.sh ../../gcc/include \
`echo /usr/include | sed -e :a -e s,[^/]*/\.\.\/,, -e ta` ); \
rm -f include/syslimits.h; \
if [ -f include/limits.h ]; then \
mv include/limits.h include/syslimits.h; \
else \
cp ../../../svn/gcc-head/gcc/gsyslimits.h include/syslimits.h; \
fi; \
fi
Fixing headers into /data/home/daniel/svn-build/gcc-head/gcc/include for
x86_64-pc-linux-gnu target
Forbidden identifiers: linux unix
Finding directories and links to directories
Searching /usr/include/.
Searching /usr/include/./X11
Searching /usr/include/./mpi
Searching /usr/include/./i386-linux/linux
Searching /usr/include/./i386-linux/asm-generic
Making symbolic directory links
Fixing directory /usr/include into
/data/home/daniel/svn-build/gcc-head/gcc/include
Applying io_quotes_defto asm/apicdef.h
Applying io_quotes_useto asm/mtrr.h
Applying glibc_c99_inline_4 to sys/sysmacros.h
Applying glibc_c99_inline_3 to bits/string2.h
Applying io_quotes_useto linux/dn.h
Applying io_quotes_useto linux/fd.h
Applying io_quotes_useto linux/fs.h
Applying io_quotes_useto linux/raid/md_u.h
Applying io_quotes_useto linux/umsdos_fs.h
Applying io_quotes_useto linux/atmbr2684.h
Applying io_quotes_useto linux/nbd.h
Applying io_quotes_useto linux/raw.h
Applying io_quotes_useto linux/auto_fs4.h
Applying io_quotes_useto linux/i2o-dev.h
Applying io_quotes_useto linux/if_pppox.h
Applying io_quotes_defto linux/ppp-comp.h
Applying io_quotes_defto linux/completion.h
Applying io_quotes_defto linux/soundcard.h
Applying io_quotes_defto linux/netfilter_ipv4/ip_conntrack_tuple.h
Applying io_quotes_useto linux/ite_gpio.h
Applying io_quotes_useto linux/uinput.h
Applying io_quotes_defto linux/isapnp.h
Applying machine_name to linux/flat.h
Fixed: linux/flat.h
Applying io_quotes_useto linux/random.h
Applying io_quotes_useto linux/ipmi.h
Applying io_quotes_useto linux/jffs.h
Applying io_quotes_useto linux/dm-ioctl-v1.h
Applying io_quotes_useto linux/dm-ioctl-v4.h
Applying io_quotes_useto linux/agpgart.h
Applying io_quotes_useto linux/auto_fs.h
Applying io_quotes_useto linux/watchdog.h
Applying io_quotes_defto linux/reiserfs_fs.h
Applying io_quotes_useto linux/reiserfs_fs.h
Applying io_quotes_defto linux/modsetver.h
Applying io_quotes_useto linux/cciss_ioctl.h
Applying io_quotes_useto linux/blkpg.h
Applying io_quotes_useto linux/synclink.h
Applying machine_name to linux/a.out.h
Fixed: linux/a.out.h
Applying io_quotes_defto linux/version.h
Applying io_quotes_useto linux/input.h
Applying io_quotes_useto linux/ppdev.h
Applying io_quotes_useto linux/devfs_fs.h
Applying io_quotes_defto i386-linux/asm/apicdef.h
Applying io_quotes_useto i386-linux/asm/mtrr.h
Applying avoid_wchar_t_type to intel-icc64-8.1/stddef.h
Fixed: intel-icc64-8.1/stddef.h
Applying avoid_wchar_t_type to intel-icc64-9.0/stddef.h
Fixed: intel-icc64-9.0/stddef.h
Applying sun_malloc
[Bug c/30214] New: warning: incompatible implicit declaration of built-in function 'strcpy'
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/source/swap/ts/pgm/swap_ts.c:4301: warning: incompatible implicit declaration of built-in function âstrlenâ /auexes/autra_prod/source/swap/ts/pgm/swap_ts.c:4312: warning: incompatible implicit declaration of built-in function âstrlenâ /auexes/autra_prod/source/swap/ts/pgm/swap_ts.c:4327: warning: incompatible implicit declaration of built-in function âstrlenâ /auexes/autra_prod/source/swap/ts/pgm/swap_ts.c:4350: warning: incompatible implicit declaration of built-in function âstrcpyâ /auexes/autra_prod/source/swap/ts/pgm/swap_ts.c:4361: warning: incompatible implicit declaration of built-in function âstrlenâ /auexes/autra_prod/source/swap/ts/pgm/swap_ts.c:4369: warning: incompatible implicit declaration of built-in function âstrlenâ /auexes/autra_prod/source/swap/ts/pgm/swap_ts.c:4382: warning: incompatible implicit declaration of built-in function âmemcpyâ /auexes/autra_prod/source/swap/ts/pgm/swap_ts.c:4405: warning: incompatible implicit declaration of built-in function âstrlenâ /auexes/autra_prod/source/swap/ts/pgm/swap_ts.c:4407: warning: incompatible implicit declaration of built-in function âstrcpyâ /auexes/autra_prod/source/swap/ts/pgm/swap_ts.c:4417: warning: incompatible implicit declaration of built-in function âmemcpyâ but the compile finish OK. As I can correct this error? Thanks -- Summary: warning: incompatible implicit declaration of built-in function 'strcpy' Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jmendoza at bancodebogota dot com dot co http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30214
[Bug c/30214] warning: incompatible implicit declaration of built-in function 'strcpy'
--- 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 use -fno-builtins or including the correct headers. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary| warning: incompatible |warning: incompatible |implicit declaration of |implicit declaration of |built-in function 'strcpy' |built-in function 'strcpy' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30214
[Bug middle-end/30215] New: FAIL: gcc.dg/pr23818.c (internal compiler error)
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 function 'foo':
/home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.dg/pr23818.c:20: internal compiler
erro
r: in output_address, at final.c:3182
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
compiler exited with status 1
output is:
/home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.dg/pr23818.c: In function 'foo':
/home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.dg/pr23818.c:20: internal compiler
erro
r: in output_address, at final.c:3182
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
FAIL: gcc.dg/pr23818.c (internal compiler error)
FAIL: gcc.dg/pr23818.c (test for excess errors)
Starting program: /home/dave/gcc-4.3/objdir/gcc/cc1 `cat xx.sh`
GNU C version 4.3.0 20061213 (experimental) (hppa-linux)
compiled by GNU C version 4.3.0 20061213 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
options passed: -iprefix
/home/dave/gcc-4.3/objdir/gcc/../lib/gcc/hppa-linux/4.3.0/ -isystem
/home/dave/gcc-4.3/objdir/gcc/include
/home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.dg/pr23818.c -auxbase-strip
./pr23818.s -O2 -fno-tree-dominator-opts -fno-show-column
options enabled: -falign-loops -fargument-alias -fbranch-count-reg
-fcaller-saves -fcommon -fcprop-registers -fcrossjumping
-fcse-follow-jumps -fdefer-pop -fdelayed-branch
-fdelete-null-pointer-checks -fearly-inlining
-feliminate-unused-debug-types -femit-class-debug-always
-fexpensive-optimizations -fforward-propagate -ffunction-cse -fgcse
-fgcse-lm -fguess-branch-probability -fident -fif-conversion
-fif-conversion2 -finline-functions-called-once -fipa-pure-const
-fipa-reference -fipa-type-escape -fivopts -fkeep-static-consts
-fleading-underscore -fmath-errno -fmerge-constants -fmove-loop-invariants
-fomit-frame-pointer -foptimize-register-move -foptimize-sibling-calls
-fpeephole -fpeephole2 -freg-struct-return -fregmove -freorder-blocks
-freorder-functions -frerun-cse-after-loop -fsched-interblock -fsched-spec
-fsched-stalled-insns-dep -fschedule-insns -fschedule-insns2
-fsplit-ivs-in-unroller -fstrict-aliasing -fthread-jumps
-ftoplevel-reorder -ftrapping-math -ftree-ccp -ftree-ch -ftree-copy-prop
-ftree-copyrename -ftree-dce -ftree-dse -ftree-fre -ftree-loop-im
-ftree-loop-ivcanon -ftree-loop-optimize -ftree-pre -ftree-salias
-ftree-sink -ftree-sra -ftree-store-ccp -ftree-store-copy-prop -ftree-ter
-ftree-vect-loop-version -ftree-vrp -funit-at-a-time -fvar-tracking
-fzero-initialized-in-bss -mbig-switch -mgas -mglibc -mno-space-regs
Compiler executable checksum: f865cc56161569c8f9e4f97e8e9517f1
foo main
Analyzing compilation unit
Performing interprocedural optimizations
Assembling functions:
foo
/home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.dg/pr23818.c: In function 'foo':
/home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.dg/pr23818.c:20: internal compiler
error: in output_address, at final.c:3182
Breakpoint 1, output_address (x=0x400aadd0) at ../../gcc/gcc/final.c:3182
3182 PRINT_OPERAND_ADDRESS (asm_out_file, x);
(gdb) p debug_rtx (x)
(plus:SI (const_int 0 [0x0])
(reg/v/f:SI 26 %r26 [orig:144 p ] [144]))
(gdb) p debug_rtx (insn)
(insn 75 78 87 (set (reg:SI 28 %r28 [151])
(mem:SI (plus:SI (const_int 0 [0x0])
(reg/v/f:SI 26 %r26 [orig:144 p ] [144])) [5 S4 A32])) 37
{*pa.md:2482} (nil)
(expr_list:REG_EQUIV (mem:SI (plus:SI (const_int 0 [0x0])
(reg/v/f:SI 26 %r26 [orig:144 p ] [144])) [5 S4 A32])
(nil)))
Seems to have been created by expand:
;; MEM[base: q, index: 0B] = MEM[base: p, index: 0B] + 10
(insn 75 73 76 (set (reg:SI 151)
(mem:SI (plus:SI (const_int 0 [0x0])
(reg/v/f:SI 144 [ p ])) [5 S4 A32])) -1 (nil)
(nil))
The PLUS isn't in canonical form.
#define PRINT_OPERAND_ADDRESS(FILE, ADDR) \
{ rtx addr = ADDR; \
switch (GET_CODE (addr)) \
{ \
case REG: \
fprintf (FILE, 0(%s), reg_names [REGNO (addr)]);\
break;\
case PLUS: \
gcc_assert (GET_CODE (XEXP (addr, 1)) == CONST_INT); \
fprintf (FILE, %d(%s), (int)INTVAL (XEXP (addr, 1)),\
reg_names [REGNO (XEXP (addr, 0))]); \
break;\
[Bug c/30183] FAIL: gcc.dg/noncompile/pr16876.c -O0 (test for errors, line 10)
--- 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 Summary|FAIL: |FAIL: |gcc.dg/noncompile/pr16876.c |gcc.dg/noncompile/pr16876.c |-O0 (test for errors, line|-O0 (test for errors, line |10) |10) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30183
[Bug middle-end/30215] FAIL: gcc.dg/pr23818.c (internal compiler error)
--- 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=0x400aadf0, operand1=0x400aade0) at ../../gcc/gcc/config/pa/pa.md:2428 #2 0x00246aa4 in emit_move_insn_1 (x=0x400aadf0, y=0x400aade0) at ../../gcc/gcc/expr.c:3090 #3 0x00246fd0 in emit_move_insn (x=0x400aadf0, y=0x400aade0) at ../../gcc/gcc/expr.c:3318 #4 0x0021e214 in copy_to_mode_reg (mode=SImode, x=0x400aade0) at ../../gcc/gcc/explow.c:644 #5 0x002fa0bc in expand_binop (mode=value optimized out, binoptab=0x400151e0, op0=0x400aade0, op1=0x4000f260, target=0x400aadc0, unsignedp=0, methods=OPTAB_LIB_WIDEN) at ../../gcc/gcc/optabs.c:1361 #6 0x0023ad30 in expand_expr_real_1 (exp=0x400a9e38, target=0x400aadc0, tmode=SImode, modifier=EXPAND_NORMAL, alt_rtl=0xc002d048) at ../../gcc/gcc/expr.c:8845 #7 0x002467f0 in expand_expr_real (exp=0x400a9e38, target=0x400aade0, tmode=SImode, modifier=1074442600, alt_rtl=0xc002d048) at ../../gcc/gcc/expr.c:6717 #8 0x002366e0 in store_expr (exp=0x400a9e38, target=0x400aadc0, call_param_p=0) at ../../gcc/gcc/expr.c:4371 #9 0x002377fc in expand_assignment (to=0x400a4508, from=0x400a9e38) at ../../gcc/gcc/expr.c:4250 ---Type return to continue, or q return to quit--- #10 0x0023bb98 in expand_expr_real_1 (exp=0x400a57b0, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc/gcc/expr.c:8620 #11 0x002466d4 in expand_expr_real (exp=0x400a57b0, target=0x400aade0, tmode=VOIDmode, modifier=1074442600, alt_rtl=0x0) at ../../gcc/gcc/expr.c:6711 #12 0x00364ed0 in expand_expr_stmt (exp=0xc002d508) at ../../gcc/gcc/expr.h:496 #13 0x003b2374 in expand_gimple_basic_block (bb=0x400a03f0) at ../../gcc/gcc/cfgexpand.c:1530 #14 0x003b31dc in tree_expand_cfg () at ../../gcc/gcc/cfgexpand.c:1800 #15 0x003ad398 in execute_one_pass (pass=0x5c9424) at ../../gcc/gcc/passes.c:858 #16 0x003ad528 in execute_pass_list (pass=0x5c9424) at ../../gcc/gcc/passes.c:903 #17 0x000c6290 in tree_rest_of_compilation (fndecl=0x400948c0) at ../../gcc/gcc/tree-optimize.c:463 #18 0x0002a4d0 in c_expand_body (fndecl=0xc002d508) at ../../gcc/gcc/c-decl.c:6855 #19 0x003fa850 in cgraph_expand_function (node=0x40013280) at ../../gcc/gcc/cgraphunit.c:1096 #20 0x003fdd28 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1161 #21 0x00033454 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:7968 #22 0x00370d8c in toplev_main (argc=value optimized out, ---Type return to continue, or q return to quit--- argv=value optimized out) at ../../gcc/gcc/toplev.c:1040 #23 0x40721340 in __libc_start_main () from /lib/libc.so.6 #24 0x0001cca8 in _start () at ../sysdeps/hppa/elf/start.S:84 (gdb) frame 8 #8 0x002366e0 in store_expr (exp=0x400a9e38, target=0x400aadc0, call_param_p=0) at ../../gcc/gcc/expr.c:4371 4371 temp = expand_expr_real (exp, target, GET_MODE (target), (gdb) p debug_rtx (target) (mem:SI (plus:SI (const_int 0 [0x0]) (reg/v/f:SI 142 [ q ])) [5 S4 A32]) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30215
[Bug middle-end/30174] [4.3 Regression] FAIL: g++.old-deja/g++.abi/cxa_vec.C execution test
--- 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
[Bug middle-end/30151] [4.3 Regression] /usr/ccs/bin/ld: Duplicate symbol global destructors keyed to _ZNSt3tr112_GLOBAL__N_16ignoreE
--- 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
[Bug c/19977] overflow in non-static initializer should not be pedwarn
--- 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/show_bug.cgi?id=19977
[Bug bootstrap/15212] [4.0/4.1/4.2/4.3 Regression] bootstrap fails on interix3
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
[Bug libfortran/30200] write(*,myfmt=(1X,a,'xyz')) A prints Az' instead of Axyz
--- 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 AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-12-13 19:47:50 |2006-12-15 02:16:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30200
[Bug bootstrap/15212] [4.0/4.1/4.2/4.3 Regression] bootstrap fails on interix3
--- 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 successfully make bootstrap gcc-4.2-20061212 on Win2K/Interix3.5, without manual intervention, with the following configuration and no environment variables such as CFLAGS set: ../src/configure \ --enable-languages=c,c++ \ --enable-threads=posix \ --with-stabs \ --disable-nls \ --enable-shared \ --disable-libssp \ --with-gnu-as \ --with-gnu-ld \ --disable-werror \ --program-suffix=-4.2 make bootstrap -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
Re: [Bug libstdc++/30203] 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
[EMAIL PROTECTED] wrote:
vector::size() in bits/stl_vector.h is currently implemented as
size_type
size() const
{ return size_type(end() - begin()); }
A faster implementation is
size_type
size() const
{ return _M_impl._M_finish - _M_impl._M_start; }
Which avoids the temporary iterators' life cycles
and operator- calls.
I tried a simple timing test on both implementations,
and the latter appears to be 10x faster:
(11:35:56)(charles xyzzy)(~): cat test.cc
#include vector
int main () {
std::vectorint x (100);
unsigned long l = 0;
const unsigned long iterations = 1;
for (unsigned long i=0; iiterations; ++i)
l += x.size ();
return 0;
}
(11:35:58)(charles xyzzy)(~): g++ -o test test.cc -lstdc++
(11:36:05)(charles xyzzy)(~): time ./test
real0m3.692s
user0m3.676s
sys 0m0.004s
(11:36:10)(charles xyzzy)(~): cat test2.cc
#include vector
int main () {
std::vectorint x (100);
unsigned long l = 0;
const unsigned long iterations = 1;
for (unsigned long i=0; iiterations; ++i)
l += x._M_impl._M_finish - x._M_impl._M_start;
return 0;
}
(11:36:13)(charles xyzzy)(~): g++ -o test2 test2.cc -lstdc++
(11:36:19)(charles xyzzy)(~): time ./test2
real0m0.342s
user0m0.336s
sys 0m0.004s
--
Summary: std::vector::size() 10x speedup (patch)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: charles at rebelbase dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30203
[Bug libstdc++/30203] std::vector::size() 10x speedup (patch)
--- 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
[EMAIL PROTECTED] wrote:
vector::size() in bits/stl_vector.h is currently implemented as
size_type
size() const
{ return size_type(end() - begin()); }
A faster implementation is
size_type
size() const
{ return _M_impl._M_finish - _M_impl._M_start; }
Which avoids the temporary iterators' life cycles
and operator- calls.
I tried a simple timing test on both implementations,
and the latter appears to be 10x faster:
(11:35:56)(charles xyzzy)(~): cat test.cc
#include vector
int main () {
std::vectorint x (100);
unsigned long l = 0;
const unsigned long iterations = 1;
for (unsigned long i=0; iiterations; ++i)
l += x.size ();
return 0;
}
(11:35:58)(charles xyzzy)(~): g++ -o test test.cc -lstdc++
(11:36:05)(charles xyzzy)(~): time ./test
real0m3.692s
user0m3.676s
sys 0m0.004s
(11:36:10)(charles xyzzy)(~): cat test2.cc
#include vector
int main () {
std::vectorint x (100);
unsigned long l = 0;
const unsigned long iterations = 1;
for (unsigned long i=0; iiterations; ++i)
l += x._M_impl._M_finish - x._M_impl._M_start;
return 0;
}
(11:36:13)(charles xyzzy)(~): g++ -o test2 test2.cc -lstdc++
(11:36:19)(charles xyzzy)(~): time ./test2
real0m0.342s
user0m0.336s
sys 0m0.004s
--
Summary: std::vector::size() 10x speedup (patch)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: charles at rebelbase dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30203
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30203
