[Bug c++/19878] [4.0 Regression] ICE in import_export_decl
--- Additional Comments From jgrimm2 at us dot ibm dot com 2005-03-07 16:01 --- Verified. Thanks. -- What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19878
[Bug c++/19916] [3.4/4.0/4.1 Regression] Segmentation fault in __static_initialization_and_destruction_0
--- Additional Comments From jgrimm2 at us dot ibm dot com 2005-03-07 16:04 --- Verified. Thanks. -- What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19916
[Bug target/20776] New: FE_DOWNWARD testcase results differ in -m32 and -m64. OK or bug?
Might not be a bug even, but I haven't had much luck in finding a definitive
answer. I get different output depending on whether I compile the following
testcase as 32-bit vs 64-bit on linux-ppc64 (gcc-3.4 and gcc-4).
include
#include
int main()
{
int x=1023, y=1023;
double z;
fesetround(FE_DOWNWARD);
z = (double)(x-y);
printf ("z = %e\n", z);
return 0;
}
If I compile this as '-O0 -m32' I get a result of:
z = -0.00e+00
But compiling for 64-bit, '-O0 -m64' I get result of:
z = 0.00e+00
This was noticed by someone testing linux-ppc glibc::logb(1) after having set
the rounding mode to FE_DOWNWARD and getting a -0.0 result (glibc has similar
code as testcase above).
GCC bug vs GLIBC bug vs User Error?
--
Summary: FE_DOWNWARD testcase results differ in -m32 and -m64. OK
or bug?
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jgrimm2 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ppc64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20776
[Bug tree-optimization/18650] [4.0 Regression] Failure in tree-ssa/loop-2.c with powerpc64 with biarch
--- Additional Comments From jgrimm2 at us dot ibm dot com 2005-01-06 23:22 --- Seems fixed? Last broken here: http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00804.html Not failing here: http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00844.html Maybe fixed by??: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01554.html Probably can close this out as WORKSFORME or something like that?? or dup to 19078 or if there is a PR + fix that this can concretely be attributed to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18650
[Bug c++/11224] [3.3/3.4 regression] warning "value computed is not used" no longer emitted
--- Additional Comments From jgrimm2 at us dot ibm dot com 2005-01-10
19:01 ---
FWIW, the xfail on Wunused-9.C :
...
+f(); // { dg-warning "not used" "" { xfail *-*-* } }
...
is no longer failing, per:
http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg01344.html
http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg01354.html
no longer an xfail?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11224
[Bug c++/19878] New: ICE in import_export_decl
ICE on mainline (20050210) when compiling the the attached file f1.c
Compiles fine on 3.4.
> g++ -o f1.o f1.c
f1.c: In function 'void __static_initialization_and_destruction_0(int, int)':
f1.c:7: internal compiler error: in import_export_decl, at cp/decl2.c:1718
Please submit a full bug report,
with preprocessed source if appropriate.
Here's the source:
# 1 "f1.c"
# 1 ""
# 1 ""
# 1 "f1.c"
# 1 "T14264.h" 1
struct S {
char k;
};
template void f(T const volatile S::* const volatile);
# 2 "f1.c" 2
char const volatile S::* volatile p00 = &S::k;
char const volatile S::* const p01 = &S::k;
int main(void)
{
return 0;
}
--
Summary: ICE in import_export_decl
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jgrimm2 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ppc64-unknown-linux
GCC host triplet: ppc64-unknown-linux
GCC target triplet: ppc64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19878
[Bug c++/19916] New: Segmentation fault in __static_initialization_and_destruction_0
The following testcase segfaults on 3.4.4 and 3.4.0, but runs to completion on
3.2.3.
Note this test won't even compile on mainline, so I don't know if the same
problem exists there. See:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19878
//test.c
struct S {
char k;
};
char const volatile S::* const p01 = &S::k;
int main(void)
{
return 0;
}
/opt/gcc-nightly/3.4-20050211/bin/g++ -o test test.c
./test
Segmentation fault
$ gdb ./test
(gdb) run
Starting program: /home/jgrimm/tmp/13930/test
Program received signal SIGSEGV, Segmentation fault.
0x1474 in __static_initialization_and_destruction_0 (__initialize_p=1,
__priority=65535) at g.c:5
5 char const volatile S::* const p01 = &S::k;
---
$ /opt/gcc-nightly/3.4-20050211/bin/g++ -v
Reading specs from
/home/gcc-nightly/3.4-20050211/bin/../lib/gcc/powerpc64-linux/3.4.4/specs
Configured with: /home/gccbuild/gcc_3.4_anoncvs/gcc/configure
--prefix=/opt/gcc-nightly/3.4-20050211 --build=powerpc64-linux
--host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32
--with-as=/opt/gcc-nightly/binutils/bin/as
--with-ld=/opt/gcc-nightly/binutils/bin/ld --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f77,java,objc
Thread model: posix
gcc version 3.4.4 20050211 (prerelease)
--
Summary: Segmentation fault in
__static_initialization_and_destruction_0
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jgrimm2 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: ppc64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19916
[Bug libstdc++/19955] New: Second std::ctype::narrow() does not call std::ctype::do_narrow()
Software Environment:
Linux 2.6.9-5.EL #1 SMP Wed Jan 5 19:23:58 EST 2005 ppc64 ppc64 ppc64
GNU/Linux
gcc version 3.4.3 20041212
(**but seems to be in 3.4.4 and 4.0 code too).
Steps to Reproduce:
1. Source File:
t.C
---
#include
class myctype : public std::ctype
{
protected:
const char* do_narrow(const char* lo, const char* hi, char dflt, char* to)
const
{
for (int i=0;lo!=hi;++lo,++to,++i)
{
*to=*lo+i;
}
return hi;
}
};
int main()
{
myctype mc;
const char input [] = "abcd";
const char input1 [] = "abcd";
char tmp[sizeof(input)] = {0};
char tmp1[sizeof(input1)]= {0};
mc.narrow(input, input + sizeof(input), '*', tmp);
printf("tmp is: %s\n",tmp);
mc.narrow(input1, input1 + sizeof(input1), '*', tmp1);
printf("tmp1 is: %s\n",tmp1);
return 0;
}
---
2. Execute command:
/usr/bin/g++ t.C
a.out
Actual Results:
tmp is: aceg
tmp1 is: abcd
Expected Results:
tmp is: aceg
tmp1 is: aceg
---
This change in behavior seems to have come in via this patch:
http://gcc.gnu.org/ml/gcc-patches/2003-12/msg01106.html
,with the changes to locale_facet2.h
Now, there is a protected _M_narrow_ok member that seems to control whether that
memcpy path should be taken. Maybe the logic for setting _M_narrow_ok needs a
fixing. The memcpy path should only be taken when it is discovered that the
narrowing operation does not do anything. Otherwise, it should use the
narrowing cache (or just call do_narrow())
--
Summary: Second std::ctype::narrow() does not call
std::ctype::do_narrow()
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jgrimm2 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19955
[Bug libstdc++/19955] Second std::ctype::narrow() does not call std::ctype::do_narrow()
--- Additional Comments From jgrimm2 at us dot ibm dot com 2005-02-14 18:34 --- >,with the changes to locale_facet2.h typo -> meant locale_facets.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19955
[Bug libstdc++/19955] [3.4/4.0 regression] Second std::ctype::narrow() does not call std::ctype::do_narrow()
--- Additional Comments From jgrimm2 at us dot ibm dot com 2005-02-14
23:41 ---
Trivial patch. Set _M_narrow_ok to 1 only when memcpy would have given the same
results as do_narrow().
Index: locale_facets.h
===
RCS file: /opt/gcc-cvs/gcc/libstdc++-v3/include/bits/locale_facets.h,v
retrieving revision 1.85.2.4.2.2
diff -c -3 -p -r1.85.2.4.2.2 locale_facets.h
*** locale_facets.h 9 Jun 2004 12:31:52 - 1.85.2.4.2.2
--- locale_facets.h 14 Feb 2005 20:30:27 -
*** namespace std
*** 1170,1177
}
// Fill in the narrowing cache and flag whether all values are
! // valid or not. _M_narrow_ok is set to 1 if the whole table is
! // narrowed, 2 if only some values could be narrowed.
void _M_narrow_init() const
{
char __tmp[sizeof(_M_narrow)];
--- 1170,1176
}
// Fill in the narrowing cache and flag whether all values are
! // valid or not. _M_narrow_ok is set to 1 if memcpy can be used.
void _M_narrow_init() const
{
char __tmp[sizeof(_M_narrow)];
*** namespace std
*** 1179,1199
__tmp[__i] = __i;
do_narrow(__tmp, __tmp + sizeof(__tmp), 0, _M_narrow);
! // Check if any default values were created. Do this by
! // renarrowing with a different default value and comparing.
! bool __consecutive = true;
! for (size_t __j = 0; __j < sizeof(_M_narrow); ++__j)
! if (!_M_narrow[__j])
! {
! char __c;
! do_narrow(__tmp + __j, __tmp + __j + 1, 1, &__c);
! if (__c == 1)
! {
! __consecutive = false;
! break;
! }
! }
! _M_narrow_ok = __consecutive ? 1 : 2;
}
};
--- 1178,1188
__tmp[__i] = __i;
do_narrow(__tmp, __tmp + sizeof(__tmp), 0, _M_narrow);
! _M_narrow_ok = 1;
! // Set _M_narrow_ok to 2 if memcpy can't be used.
! if (memcmp(__tmp, _M_narrow, sizeof(_M_narrow)))
! _M_narrow_ok = 2;
!
}
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19955
[Bug pch/14940] PCH largefile test fails on various platforms
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-10-12 19:56 --- patch for powerpc64-linux-gnu: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01037.html Index: gcc/config/host-linux.c === RCS file: /home/jgrimm/gcc-cvs/gcc/gcc/config/host-linux.c,v retrieving revision 1.2 diff -c -3 -p -r1.2 host-linux.c *** gcc/config/host-linux.c 24 Apr 2004 00:33:18 - 1.2 --- gcc/config/host-linux.c 12 Oct 2004 21:35:47 - *** *** 75,80 --- 75,82 # define TRY_EMPTY_VM_SPACE 0x80 #elif defined(__s390__) # define TRY_EMPTY_VM_SPACE 0x6000 + #elif defined(__powerpc__) + # define TRY_EMPTY_VM_SPACE 0x6000 #else # define TRY_EMPTY_VM_SPACE 0 #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-10-19 21:25 --- I see this too. Or rather, I see what Michael is describing. Should there be a new bug for the problem as described by Michael? My test scenario was from desire to build 64-bit biarch compiler that defaults to m64. The system compiler was 32-bit biarch compiler that defaults to m32. Here's how I had configured: /home/jgrimm/gcc_priv_mline_anoncvs/gcc/configure --prefix=/home/jgrimm/tools/gcc-work --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default64 --with-as=/home/jgrimm/tools/binutils/bin/as --with-ld=/home/jgrimm/tools/binutils/bin/ld --enable-threads=\posix --enable-shared --enable-__cxa_atexit --enable-languages=c --enable-biarch Error output: ... stage1/xgcc -Bstage1/ -B/home/jgrimm/tools/gcc-work/powerpc64-linux/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genmodes \ build/genmodes.o build/errors.o ../build-powerpc64-linux/libiberty/libiberty.a /home/jgrimm/tools/binutils/bin/ld: warning: powerpc:common architecture of input file `../build-powerpc64-linux/libiberty/libiberty.a(hashtab.o)' is incompatible with powerpc:common64 output /home/jgrimm/tools/binutils/bin/ld: warning: powerpc:common architecture of input file `../build-powerpc64-linux/libiberty/libiberty.a(xmalloc.o)' is incompatible with powerpc:common64 output /home/jgrimm/tools/binutils/bin/ld: warning: powerpc:common architecture of input file `../build-powerpc64-linux/libiberty/libiberty.a(xstrdup.o)' is incompatible with powerpc:common64 output /home/jgrimm/tools/binutils/bin/ld: warning: powerpc:common architecture of input file `../build-powerpc64-linux/libiberty/libiberty.a(xexit.o)' is incompatible with powerpc:common64 output /home/jgrimm/tools/binutils/bin/ld: can not size stub section: Bad value -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17646
[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-10-27 15:38 --- What I've finally done to get my 64-bit biarch default64 compiler is to first build a 32-bit biarch default64 compiler. I can then make bootstrap using this intermediate compiler as the host compiler to build all stages 64-bit. I'd classify my earlier attempts as user error, though still think it should be possible to do this eventually in one swoop on ppc64. Otherwise, i've been able to bootstrap just fine, though obviously I'm configuring my build a bit differently than below. I just wanted to post back in case others runs across my comments in sometime in the future and wanted to close out those comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17646
[Bug fortran/18218] Miscompare in sixtrack benchmark caused by loss of precision
-- What|Removed |Added CC||jgrimm2 at us dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18218
[Bug middle-end/18420] New: ICE compiling mesa at -O2
I'll add more details as they unfold, but wanted to get this posted into
bugzilla. The autotester has been pretty flaky lately that I don't have a good
idea when this broke, but looks to have broken somewhere between Oct 29 and Nov
4. I don't have data between those dates, but Nov 4. build did not compile
mesa. SegFault doesn't happen at -O1.
SegFault Building mesa.
/opt/gcc-nightly/gcc/libexec/gcc/powerpc64-linux/4.0.0/cc1 -O2 context.c
context.c: In function gl_create_visual:
context.c:1082: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Watching in GDB shows.
Analyzing compilation unit
Performing intraprocedural optimizations
Assembling functions:
free_shared_state
init_material
gl_create_visual
Program received signal SIGSEGV, Segmentation fault.
note_stores (x=0x403d62f0, fun=0x10325090 , data=0x0)
at /home/gccbuild/gcc_mline_anoncvs/gcc/gcc/rtlanal.c:1405
1405/home/gccbuild/gcc_mline_anoncvs/gcc/gcc/rtlanal.c: No such file or
directory.
in /home/gccbuild/gcc_mline_anoncvs/gcc/gcc/rtlanal.c
--
Summary: ICE compiling mesa at -O2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jgrimm2 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug middle-end/18420] ICE compiling mesa at -O2
-- What|Removed |Added GCC target triplet||powerpc64-linux Summary|ICE compiling mesa at -O2 |ICE compiling mesa at -O2 Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-10
22:50 ---
Testcase reduced from the mesa context.c file.
Compiling this with -O2 segfaults on linux-powerpc64 segfaults.
typedef unsigned int size_t;
extern void *malloc (size_t __size) __attribute__ ((__malloc__));
extern void abort(void);
struct _abc {
int ebc;
};
void xxx ( float rscale,
float gscale,
float bscale,
float ascale)
{
struct _abc *vis;
if (rscale > 255.0) abort();
if (gscale > 255.0) abort();
if (bscale > 255.0) abort();
if (ascale > 255.0) abort();
vis = (struct _abc *) malloc(sizeof(struct _abc) );
if (rscale==255.0F && gscale==255.0F
&& bscale==255.0F && ascale==255.0F) {
vis->ebc = 1;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug bootstrap/18486] [4.0 Regression] fixincl fails with make -jN profilebootstrap
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-15 15:02 --- This showed up in linux-powerpc64 builds over the weekend on build machine's belonging to Janis and myself. I'm just doing a normal bootstrap, not profiledbootstrap. The build machines are both SMP machines (one with 4proc, one with 2). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18486
[Bug bootstrap/18486] [4.0 Regression] fixincl fails with make -jN profilebootstrap
-- What|Removed |Added CC||jgrimm2 at us dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18486
[Bug bootstrap/18486] [4.0 Regression] fixincl fails with make -jN profilebootstrap
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-15 16:46 --- Hmmm in Makefile.in macro_list : $(GCC_PASSES) echo | $(GCC_FOR_TARGET) -E -dM - | \ sed -n 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p ; \ s/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \ sort -u > tmp-$@ $(SHELL) $(srcdir)/../move-if-change tmp-$@ $@ Looks bogus. Maybe meant: macro_list : $(GCC_PASSES) echo | $(GCC_FOR_TARGET) -E -dM - | \ sed -n 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' | \ sort -u > tmp-$@ $(SHELL) $(srcdir)/../move-if-change tmp-$@ $@ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18486
[Bug bootstrap/18486] [4.0 Regression] fixincl fails with make -jN profilebootstrap
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-15 18:40 --- seems like this may just be a race on tmp-macro_list?? the macro_list code looks bogus, but really doesn't account for the behavior. not sure how parallel build races are protected against gcc build machinery. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18486
[Bug bootstrap/18486] [4.0 Regression] fixincl fails with make -jN profilebootstrap
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-15 19:04 --- Just noticed there is thread on gcc-patches on this: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01232.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18486
[Bug bootstrap/18486] [4.0 Regression] fixincl fails with make -jN profilebootstrap
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-16 02:55 --- Hmmm... the following patch seems to have allowed my build to complete. Changed sed line and created s-macro_list target/timestamp'd file, similar to what is done throughout Makefile.in. Dropping into bugzilla in offchance this helps someone who actually understand the gcc build system. Index: gcc/gcc/Makefile.in === RCS file: /home/jgrimm/gcc-cvs/gcc/gcc/Makefile.in,v retrieving revision 1.1422 diff -c -3 -p -r1.1422 Makefile.in *** gcc/gcc/Makefile.in 14 Nov 2004 16:24:28 - 1.1422 --- gcc/gcc/Makefile.in 16 Nov 2004 01:24:53 - *** stmp-int-hdrs: $(STMP_FIXINC) $(USER_H) *** 2792,2803 install-gcc-tooldir: $(mkinstalldirs) $(DESTDIR)$(gcc_tooldir) ! macro_list : $(GCC_PASSES) echo | $(GCC_FOR_TARGET) -E -dM - | \ ! sed -n 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p ; \ ! s/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \ ! sort -u > tmp-$@ ! $(SHELL) $(srcdir)/../move-if-change tmp-$@ $@ # Build fixed copies of system files. stmp-fixinc: gsyslimits.h macro_list \ --- 2792,2804 install-gcc-tooldir: $(mkinstalldirs) $(DESTDIR)$(gcc_tooldir) ! macro_list: s-macro_list; @true ! s-macro_list : $(GCC_PASSES) echo | $(GCC_FOR_TARGET) -E -dM - | \ ! sed -n 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' | \ ! sort -u > tmp-macro_list ! $(SHELL) $(srcdir)/../move-if-change tmp-macro_list macro_list ! $(STAMP) s-macro_list # Build fixed copies of system files. stmp-fixinc: gsyslimits.h macro_list \ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18486
[Bug rtl-optimization/17950] Over Aggressive Use of Data Cache Touch Instructions During FDO
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-18 01:32 --- Hmmm... looks like a couple things (maybe more) come in to play here. First, value-profile code doesn't seem to merge prefetches (among other things). That is, it should be pretty easy (crude?) to track the last prefetch and not prefetch addresses that look close. Doing so seems to help this test case quite a bit (96 prefetches down to 24), but probably not enough. as it seems that the loop unroller comes through afterwards and does its damage too. Might need to teach the unroller about prefetch a bit too?? -- What|Removed |Added CC||jgrimm2 at us dot ibm dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17950
[Bug rtl-optimization/17950] Over Aggressive Use of Data Cache Touch Instructions During FDO
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-23 01:43 --- Finally got SPEC set up w/profiling to do a little comparison. Its not done yet (and only running c,c++ tests) but first glance through the initials results, it appears that -fspeculative-prefetching is damaging to spec results at least on ppc64 (-m32). I wanted to do this to guage whether this bug entry was some pathological testcase or this would also show up in regularly looked at tests. I'm currently comparing -O2 -funroll-loops -fno-speculative-prefetching vs -O2 -funroll-loops -fspeculative-prefetching and using profiling for both runs. I'll run again to see if I can get those results. Additionally, I'd like to see what the behavior is when I limit the prefetches (don't emit prefetch if just prefetched from near address + crudely limit maximum number of prefetches), I just uploaded a patch for that, but haven't tested how it affects spec yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17950
[Bug tree-optimization/18650] New: Failure in tree-ssa/loop-2.c with powerpc64 with biarch
I didn't find a bug report for this yet.
This regressoin roughly started happening Oct 26-27. as it shows up in
testresults from Janis Johson here. (32-bit default32 compiler. Regression
only at -m64)
http://gcc.gnu.org/ml/gcc-testresults/2004-10/msg01382.html
Interestingly, this also shows up in my 64-bit default64 compiler but at -m32:
http://gcc.gnu.org/ml/gcc-testresults/2004-10/msg01391.html
The check that is failing in the test case is:
/* { dg-final { scan-tree-dump-times " \\* 17" 0 "vars" } } */
/* { dg-final { scan-tree-dump-times " \\+ 17" 1 "vars" } } */
as 17 * iter is not getting reduced.
I played with the testcase a bit using a 32-bit biarch compiler w/ -m64 and
noticed a couple things.
1) Changing the iter var from 'int' to a 'long' seems to let the test pass again
. The test case is tiny so I'll original code here:
struct bla
{
char x[187];
int y;
char z[253];
} arr_base[100];
void xxx(void)
{
int iter;
for (iter = 0; iter < 100; iter++)
arr_base[iter].y = 17 * iter;
}
2) Dumps of t52.ivopts pass (from dump-tree-all-all), look funny:
(add_to_evolution
(loop_nb = 1)
(chrec_before = 100)
(to_add = 1)
(res = {100, +, 4294967295}_1))
(evolution_function = {100, +, 4294967295}_1))
(set_scalar_evolution
(scalar = ivtmp.1_5)
(scalar_evolution = {100, +, 4294967295}_1))
)
,as 4294967295 looks quite peculiar.and would have expected 0 there.
I'll attach the entire loop-2.c.t52.ivopts for 32 bit and for 64 bit, in case
someone wise in the ways of tree/loops/scalarev has interest.
--
Summary: Failure in tree-ssa/loop-2.c with powerpc64 with biarch
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jgrimm2 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18650
[Bug tree-optimization/18650] Failure in tree-ssa/loop-2.c with powerpc64 with biarch
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-24 16:14 --- Created an attachment (id=7596) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7596&action=view) ivopts dump at -m32 (when testcase passes) ivopts dump at -m32 (when testcase passes) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18650
[Bug tree-optimization/18650] Failure in tree-ssa/loop-2.c with powerpc64 with biarch
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-24 16:15 --- Created an attachment (id=7597) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7597&action=view) ivopts dump at -m64 (when testcase fails) ivopts dump at -m64 (when testcase fails) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18650
[Bug tree-optimization/18650] Failure in tree-ssa/loop-2.c with powerpc64 with biarch
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-24 22:08 --- Ugh. Ignore my comments on add_to_evolution comment, I was sleepy when I wrote up notes. The dumps still may be useful though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18650
[Bug tree-optimization/18650] Failure in tree-ssa/loop-2.c with powerpc64 with biarch
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-24 22:59 --- This set of changes seems to have caused the regression: http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg01561.html Or more specifically http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&r1=2.20&r2=2.21 If I re-enable walking all of the candidates (as opposed to just the "important" ones" I get back the optimizations that were present before and this test case will pass again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18650
[Bug tree-optimization/18650] [4.0 Regression] Failure in tree-ssa/loop-2.c with powerpc64 with biarch
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-29 19:02 --- adding cc for awareness. -- What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18650
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-30 14:49 --- Verified this fixed mesa too. -- What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
