[Bug tree-optimization/27159] New: ICE when using -fipa-pta
A recent build (4.2.0 20060413) ICEs when compiling this:
#include
class bar {
public:
float e[1];
};
istream &operator>>(istream &is, bar &t)
{
is >> t.e[1];
return is;
}
with the following options:
g++ -c -fipa-pta fail1.cc
The error is:
fail1.cc:15: internal compiler error: in collapse_rest_of_var, at
tree-ssa-structalias.c:2820
--
Summary: ICE when using -fipa-pta
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27159
[Bug tree-optimization/27210] New: ICE on c++ template
Using a recent gcc build (4.2.0 20060418) the following code:
template class junk {
void bar(int a)
{
unsigned char *c = new unsigned char[a*sizeof(foo)];
}
};
gets an ICE:
foo.c: In member function 'void junk::bar(int)':
foo.c:4: internal compiler error: tree check: did not expect class 'type', have
'type' (template_type_parm) in contains_placeholder_p, at tree.c:2139
However 4.0 and 4.1 dont.
--
Summary: ICE on c++ template
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27210
[Bug c/25572] New: ppc64 -mminimal-toc trashes r30
We found this problem when building a ppc64 Linux kernel. It turns out r30 was
not preserved in a function that was using a local TOC. The compiler used was:
gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)
Although it seems to reproduce on older toolchains too (eg 3.4).
pinskia cut the original test case down to:
/* Compile with -m64 -O2 -mminimal-toc */
int per_cpu__kstat;
int *f()
{
int *__ptr;
asm volatile(";%0":"=g"(__ptr):"0"(&per_cpu__kstat));
return __ptr;
}
/*
.f:
ld 30,[EMAIL PROTECTED](2)
ld 9,.LC0-.LCTOC1(30)
mr 3,9
#APP
;3
#NO_APP
*/
--
Summary: ppc64 -mminimal-toc trashes r30
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25572
[Bug regression/20276] New: 64bit target uses __adddi3
I just tried out a CVS copy of gcc and found problems with the following code:
long foo()
{
long int word;
word += 2147483647UL;
return word;
}
When compiled as 64bit uses the __adddi3 helper function:
mflr 0
li 4,-1
rldicl 4,4,0,33
std 0,16(1)
stdu 1,-112(1)
bl __adddi3
nop
addi 1,1,112
ld 0,16(1)
mtlr 0
blr
gcc 3.4.4 did a much better job:
li 3,-1
rldicl 3,3,0,33
add 3,0,3
blr
--
Summary: 64bit target uses __adddi3
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20276
[Bug fortran/20467] New: Bad fortran code causes ICE
Im no fortran coder but Im pretty sure this isnt valid: SUBROUTINE a(b) b(c) = 0 END SUBROUTINE a Using todays cvs: GNU Fortran 95 (GCC 4.0.0 20050313 (prerelease)) We ICE: /usr/local/ppc64-4.0/libexec/gcc/powerpc64-linux/4.0.0/f951 f.f90 -quiet -dumpbase f.f90 -m64 -auxbase f -version -o /tmp/cccadl1s.s (gdb) backtrace #0 resolve_formal_arglist (proc=0x105cfaa0) at /scratch/anton/toolchain/new2/gcc-4.0/gcc/fortran/resolve.c:123 #1 0x10054bf0 in traverse_ns (st=0x105ba360, func=0x10041710 ) at /scratch/anton/toolchain/new2/gcc-4.0/gcc/fortran/symbol.c:2298 #2 0x10054c18 in traverse_ns (st=0x105ba4f0, func=0x10041710 ) at /scratch/anton/toolchain/new2/gcc-4.0/gcc/fortran/symbol.c:2301 #3 0x10046d9c in gfc_resolve (ns=0x105cf750) at /scratch/anton/toolchain/new2/gcc-4.0/gcc/fortran/resolve.c:247 #4 0x1003db64 in gfc_parse_file () at /scratch/anton/toolchain/new2/gcc-4.0/gcc/fortran/parse.c:2612 #5 0x100570a8 in gfc_be_parse_file (set_yydebug=Variable "set_yydebug" is not available. ) at /scratch/anton/toolchain/new2/gcc-4.0/gcc/fortran/f95-lang.c:265 #6 0x102d09c4 in toplev_main (argc=Variable "argc" is not available. ) at /scratch/anton/toolchain/new2/gcc-4.0/gcc/toplev.c:996 #7 0x1007ae40 in main (argc=Variable "argc" is not available. ) at /scratch/anton/toolchain/new2/gcc-4.0/gcc/main.c:35 sym->result is NULL: (gdb) print sym->result $3 = (struct gfc_symbol *) 0x0 and line 123 is: /* Set the type of the RESULT, then copy. */ if (sym->result->ts.type == BT_UNKNOWN) -- Summary: Bad fortran code causes ICE Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anton at samba dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20467
[Bug tree-optimization/14886] strength reduction on floating point
--- Additional Comments From anton at samba dot org 2005-03-16 20:54 --- FYI this is still present in 4.0.0 20050313 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14886
[Bug c/21017] New: ppc 64bit target not using rlwinm
Using a recent 4.0 CVS:
gcc version 4.0.0 20050412 (prerelease)
Compiling the following as 64bit:
unsigned int foo(unsigned int x)
{
return ((x >> 16) & 0x) | ((x & 0x) << 16);
}
Results in:
.L.foo:
slwi 0,3,16
srwi 3,3,16
or 3,3,0
rldicl 3,3,0,32
blr
Compiling for 32bit results in:
foo:
rlwinm 3,3,16,0x
blr
It looks like the 64bit case could be done in 2 instructions if we masked the
top 32bits of the rlwinm result.
--
Summary: ppc 64bit target not using rlwinm
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21017
[Bug regression/37456] New: gcc4.4 ICE: verify_flow_info failed
I get an ICE on PowerPC with the following code on a gcc svn checkout from this morning: gcc version 4.4.0 20080909 (experimental) (GCC) # /root/gcc-installed/bin/g++ -O -ffast-math -c foo.cpp foo.cpp: In member function void testcase::foo::doit(double, double, double): foo.cpp:16: error: control flow in the middle of basic block 3 foo.cpp:16: error: control flow in the middle of basic block 3 foo.cpp:16: error: BB 3 can not throw but has EH edges foo.cpp:16: internal compiler error: verify_flow_info failed It compiles OK if the -ffast-math flag is not specified. -- Summary: gcc4.4 ICE: verify_flow_info failed Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anton at samba dot org GCC host triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37456
[Bug regression/37456] gcc4.4 ICE: verify_flow_info failed
--- Comment #1 from anton at samba dot org 2008-09-10 07:35 --- Created an attachment (id=16280) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16280&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37456
[Bug regression/37640] New: Misuse of __sync_lock_test_and_set causes ICE
A gcc build from today (gcc version 4.4.0 20080924) gets an ICE on PowerPC when
building this (admittedly broken) code:
# gcc -m64 -O2 -c test.c
struct foo {
int a;
char lock;
};
struct foo *foo;
void testcase()
{
__sync_lock_test_and_set(&(foo->lock), 0);
}
It compiles if building 32bit. Even so, I wonder if gcc should warn when the
variable is incompatible with __sync_* builtins.
--
Summary: Misuse of __sync_lock_test_and_set causes ICE
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37640
[Bug target/37640] Misuse of __sync_lock_test_and_set causes ICE
--- Comment #2 from anton at samba dot org 2008-09-24 20:07 --- After reading the gcc documentation I guess it is valid, and the 32bit lwarx/stwcx will overlap but not change surrounding memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37640
[Bug regression/37824] funroll-loops miscompiles php
--- Comment #1 from anton at samba dot org 2008-10-14 11:59 --- Alan Modra points out the cast is not required and removing it does fix the issue. BTW -Wstrict-aliasing (or -Wstrict-aliasing=2) doesn't warn about the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37824
[Bug regression/37824] New: funroll-loops miscompiles php
A gcc checkout from yesterday (4.4.0 20081013) is miscompiling php when built
with 64bit and funroll-loops. A cut down test case is below but at this stage
im not sure if its a violation of the aliasing rules.
good:
# gcc -m64 -O2 -o /tmp/foo /tmp/foo.c
# /tmp/foo
0xfabef50
0xfabef50
0xfabef50
0xfabef50
0xfabef50
0xfabef50
bad:
# gcc -m64 -funroll-loops -O2 -o /tmp/foo /tmp/foo.c
# /tmp/foo
0xfacef50
0xfacef50
(nil)
(nil)
(nil)
0xfacef50
code:
#include
#include
void foo(int count, void **p)
{
while (--count >= 0) {
long *q = *(long **)(--p);
*p = 0;
printf("%p\n", q);
}
}
int main()
{
int i;
long a;
long *b = malloc(8 * sizeof(long));
for (i = 0; i < 8; i++)
*b++ = (unsigned long)&a;
b--;
foo(6, (void **)b);
return 0;
}
--
Summary: funroll-loops miscompiles php
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37824
[Bug middle-end/57134] New: ICE with -mstrict-align and inline assembly on ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134
Bug #: 57134
Summary: ICE with -mstrict-align and inline assembly on ppc64
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: an...@samba.org
Created attachment 29987
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29987
Testcase that ICE's with -mstrict-align on ppc64
The following testcase passes on a ppc64 4.7.2 build but fails on a 4.9.0
20130501 build:
# gcc -m64 -O2 -S -mstrict-align testcase.c
testcase.c: In function 'rb_remove_pages':
testcase.c:16:2: internal compiler error: in expand_asm_operands, at stmt.c:910
__asm__ __volatile__("# %0,%1" : "=r"(t) : "m"(v->counter));
^
0x10604437 expand_asm_operands
../../gcc/gcc/stmt.c:910
0x10604b3b expand_asm_stmt(gimple_statement_d*)
../../gcc/gcc/stmt.c:1151
0x1022f357 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:2154
0x1022f357 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:2309
0x10230b77 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:4143
0x10233f7b gimple_expand_cfg
../../gcc/gcc/cfgexpand.c:4662
Please submit a full bug report,
[Bug middle-end/57161] New: ICE in in check_probability, at basic-block.h:941
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57161 Bug #: 57161 Summary: ICE in in check_probability, at basic-block.h:941 Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: an...@samba.org I'm getting an ICE with the following testcase on a ppc64 target. passes on gcc version 4.9.0 20130501 (experimental) (GCC) fails on gcc version 4.9.0 20130503 (experimental) (GCC) # gcc -O2 -c foo.c foo.c: In function 'testcase': foo.c:40:1: internal compiler error: in check_probability, at basic-block.h:941 } ^ 0x105bb57b check_probability ../../gcc/gcc/basic-block.h:941 0x105bb57b check_probability ../../gcc/gcc/sched-rgn.c:3247 0x105bb57b combine_probabilities ../../gcc/gcc/basic-block.h:950 0x105bb57b compute_dom_prob_ps ../../gcc/gcc/sched-rgn.c:1444 0x105bb57b sched_rgn_local_init(int) ../../gcc/gcc/sched-rgn.c:3291 0x105bd393 schedule_region ../../gcc/gcc/sched-rgn.c:2984 0x105bd393 schedule_insns ../../gcc/gcc/sched-rgn.c:3384 0x105bd393 schedule_insns() ../../gcc/gcc/sched-rgn.c:3363 0x105bdbb3 rest_of_handle_sched ../../gcc/gcc/sched-rgn.c:3577
[Bug middle-end/57161] ICE in in check_probability, at basic-block.h:941
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57161 --- Comment #1 from Anton Blanchard 2013-05-03 12:53:49 UTC --- Created attachment 30021 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30021 Testcase
[Bug middle-end/57161] ICE in in check_probability, at basic-block.h:941
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57161 --- Comment #2 from Anton Blanchard 2013-05-03 13:17:31 UTC --- A bisect hit this commit: 2013-05-02 Teresa Johnson * loop-unswitch.c (unswitch_loop): Use helper routines with rounding divides. * cfg.c (update_bb_profile_for_threading): Ditto. * tree-inline.c (copy_bb): Ditto. (copy_edges_for_bb): Ditto. (initialize_cfun): Ditto. (copy_cfg_body): Ditto. (expand_call_inline): Ditto. * ipa-inline-analysis.c (estimate_edge_size_and_time): Ditto. (estimate_node_size_and_time): Ditto. (inline_merge_summary): Ditto. * cgraphclones.c (cgraph_clone_edge): Ditto. (cgraph_clone_node): Ditto. * sched-rgn.c (compute_dom_prob_ps): Ditto. (compute_trg_info): Ditto.
[Bug tree-optimization/47286] New: Invalid code when using register ... asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47286
Summary: Invalid code when using register ... asm
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: an...@samba.org
Target: powerpc64-unknown-linux-gnu
A gcc build from yesterday (4.6.0 20110113) fails when building a ppc64 Linux
kernel. A cut down testcase:
struct thread_info {
int preempt_count;
};
static inline struct thread_info *current_thread_info(void)
{
register struct thread_info *sp asm("r1");
return sp;
}
void testcase(void)
{
current_thread_info()->preempt_count += 1;
}
compiled with -O2:
# gcc -O2 -S testcase.s
has the add optimised away:
.L.testcase:
blr
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274
--- Comment #3 from Anton Blanchard 2011-01-15
02:04:04 UTC ---
I'm seeing this too:
# cat test1.c
void *ptr;
# cat test2.c
extern void *ptr;
void foo()
{
ptr = 0;
}
# gcc -flto -c test1.c
# gcc -flto -c test2.c
# gcc -flto test1.o test2.o
lto1: internal compiler error: in lto_varpool_replace_node, at lto-symtab.c:306
Please submit a full bug report
-v output:
Using built-in specs.
COLLECT_GCC=/root/gcc-installed/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc-installed/libexec/gcc/powerpc64-linux/4.6.0/lto-wrapper
Target: powerpc64-linux
Configured with: ../gcc/configure --build=powerpc64-linux
--enable-targets=powerpc64-linux --prefix=/root/gcc-installed --disable-nls
--with-gmp=/root/gcc-installed --with-mpfr=/root/gcc-installed
--with-libelf=/root/gcc-installed --with-cloog=/root/gcc-installed
--with-ppl=/root/gcc-installed --disable-werror
--with-ld=/root/gcc-installed/bin/ld --with-as=/root/gcc-installed/bin/as
--enable-languages=c,c++,fortran --enable-lto : (reconfigured) ../gcc/configure
--build=powerpc64-linux --enable-targets=powerpc64-linux
--prefix=/root/gcc-installed --disable-nls --with-gmp=/root/gcc-installed
--with-mpfr=/root/gcc-installed --with-libelf=/root/gcc-installed
--with-cloog=/root/gcc-installed --with-ppl=/root/gcc-installed
--disable-werror --with-ld=/root/gcc-installed/bin/ld
--with-as=/root/gcc-installed/bin/as --enable-lto build_alias=powerpc64-linux
--enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
gcc version 4.6.0 20110114 (experimental) (GCC)
COMPILER_PATH=/root/gcc-installed/libexec/gcc/powerpc64-linux/4.6.0/:/root/gcc-installed/libexec/gcc/powerpc64-linux/4.6.0/:/root/gcc-installed/libexec/gcc/powerpc64-linux/:/root/gcc-installed/lib/gcc/powerpc64-linux/4.6.0/:/root/gcc-installed/lib/gcc/powerpc64-linux/:/root/gcc-installed/lib/gcc/powerpc64-linux/4.6.0/../../../../powerpc64-linux/bin/
LIBRARY_PATH=/root/gcc-installed/lib/gcc/powerpc64-linux/4.6.0/:/root/gcc-installed/lib/gcc/powerpc64-linux/4.6.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/root/gcc-installed/lib/gcc/powerpc64-linux/4.6.0/../../../../powerpc64-linux/lib/:/root/gcc-installed/lib/gcc/powerpc64-linux/4.6.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-flto'
/root/gcc-installed/libexec/gcc/powerpc64-linux/4.6.0/collect2 -plugin
/root/gcc-installed/libexec/gcc/powerpc64-linux/4.6.0/liblto_plugin.so
-plugin-opt=/root/gcc-installed/libexec/gcc/powerpc64-linux/4.6.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccSsas7e.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -flto
--eh-frame-hdr -V -Qy -m elf64ppc -dynamic-linker /lib64/ld64.so.1
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/root/gcc-installed/lib/gcc/powerpc64-linux/4.6.0/crtbegin.o
-L/root/gcc-installed/lib/gcc/powerpc64-linux/4.6.0
-L/root/gcc-installed/lib/gcc/powerpc64-linux/4.6.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/root/gcc-installed/lib/gcc/powerpc64-linux/4.6.0/../../../../powerpc64-linux/lib
-L/root/gcc-installed/lib/gcc/powerpc64-linux/4.6.0/../../.. test1.o test2.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /root/gcc-installed/lib/gcc/powerpc64-linux/4.6.0/crtend.o
/usr/lib/../lib64/crtn.o
GNU ld (GNU Binutils) 2.21.51.20110113
Supported emulations:
elf64ppc
elf32ppclinux
elf32ppc
elf32ppcsim
/root/gcc-installed/bin/gcc @/tmp/ccgYtfeo.args
Using built-in specs.
COLLECT_GCC=/root/gcc-installed/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc-installed/libexec/gcc/powerpc64-linux/4.6.0/lto-wrapper
Target: powerpc64-linux
Configured with: ../gcc/configure --build=powerpc64-linux
--enable-targets=powerpc64-linux --prefix=/root/gcc-installed --disable-nls
--with-gmp=/root/gcc-installed --with-mpfr=/root/gcc-installed
--with-libelf=/root/gcc-installed --with-cloog=/root/gcc-installed
--with-ppl=/root/gcc-installed --disable-werror
--with-ld=/root/gcc-installed/bin/ld --with-as=/root/gcc-installed/bin/as
--enable-languages=c,c++,fortran --enable-lto : (reconfigured) ../gcc/configure
--build=powerpc64-linux --enable-targets=powerpc64-linux
--prefix=/root/gcc-installed --disable-nls --with-gmp=/root/gcc-installed
--with-mpfr=/root/gcc-installed --with-libelf=/root/gcc-installed
--with-cloog=/root/gcc-installed --with-ppl=/root/gcc-installed
--disable-werror --with-ld=/root/gcc-installed/bin/ld
--with-as=/root/gcc-installed/bin/as --enable-lto build_alias=powerpc64-linux
--enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
gcc version 4.6.0 20110114 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-c' '-v' '-fltrans-output-list=/tmp/ccd96jEi.ltrans.out'
'-fwpa' '-fresolution=/tmp/ccSsas7e.res'
/root/gcc-installed/libexec/gcc/powerpc64-linux/4.6.0/lto1 -quiet -dumpbase
test1.o -auxbase test1 -version -fltrans-output-list=/tmp/ccd96jEi.ltr
[Bug middle-end/57134] [4.9 Regression] ICE with -mstrict-align and inline assembly on ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134
--- Comment #3 from Anton Blanchard ---
Created attachment 30607
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30607&action=edit
Compilation failure with -mstrict-align on ppc64
The original testcase isn't failing, but this test fails to compile with
-mstrict-align:
/tmp/testcase.c: In function 'testcase':
/tmp/testcase.c:12:2: error: output number 0 not directly addressable
asm volatile("# %0": "+m" (b->zot));
^
and passes without -mstrict-align.
[Bug middle-end/58330] New: powerpc64 atomic store split in two
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58330
Bug ID: 58330
Summary: powerpc64 atomic store split in two
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
We found an issue when building the powerpc64 little endian kernel where a 64
bit store was split into two 32 bit stores. Since there is no 64 bit byte
reversed store on POWER6 and earlier, gcc decided to use two 32 bit byte
reversed stores. We were unable to fix this, even with atomic builtins.
I think splitting the store even in the non atomic builtin case is suspect
since we have lots of places in the kernel that rely on naturally aligned loads
and stores being done atomically.
An example:
static inline void __raw_writeq (unsigned long v, void *addr)
{
#if 1
__atomic_store_n ((unsigned long *) addr, v, __ATOMIC_RELAXED);
#else
*(volatile unsigned long *)addr = v;
#endif
}
void foo (void *addr, unsigned long start)
{
unsigned long reverse = __builtin_bswap64 (start);
__raw_writeq (reverse, addr);
}
gives:
li 9,4
srdi 10,4,32
stwbrx 4,0,3
stwbrx 10,9,3
[Bug target/88965] New: powerpc64le vector builtin hits ICE in verify_gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
Bug ID: 88965
Summary: powerpc64le vector builtin hits ICE in verify_gimple
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
CC: segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux
The following (admittedly odd) code results in an ICE on trunk, target
powerpc64le:
unsigned int a[1];
void b(void) { __builtin_vec_vsx_ld(0, &a[0]); }
...
blake.i: In function 'b':
blake.i:2:6: error: invalid address operand in MEM_REF
2 | void b(void) { __builtin_vec_vsx_ld(0, &a[0]); }
| ^
MEM[(void *)&a[0]];
_1 = MEM[(void *)&a[0]];
during GIMPLE pass: lower
blake.i:2:6: internal compiler error: verify_gimple failed
0x10a7ddfb verify_gimple_in_seq(gimple*)
../../gcc/gcc/tree-cfg.c:5082
0x108dcff7 execute_function_todo
../../gcc/gcc/passes.c:1979
0x108de5bb do_per_function
../../gcc/gcc/passes.c:1638
0x108de7cb execute_todo
../../gcc/gcc/passes.c:2031
[Bug target/88965] powerpc64le vector builtin hits ICE in verify_gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
--- Comment #1 from Anton Blanchard ---
Here's something more representative. Passing the address via an explicit
pointer makes the issue go away.
#include
#include
#define LOADU(p)vec_vsx_ld(0, (vector unsigned long *)(p))
static uint64_t blake2b_IV[8] =
{
0x6a09e667f3bcc908ULL, 0xbb67ae8584caa73bULL,
0x3c6ef372fe94f82bULL, 0xa54ff53a5f1d36f1ULL,
0x510e527fade682d1ULL, 0x9b05688c2b3e6c1fULL,
0x1f83d9abfb41bd6bULL, 0x5be0cd19137e2179ULL
};
vector unsigned long ret;
int main(void)
{
#ifdef GOOD
unsigned long *p = &blake2b_IV[0];
ret = LOADU(p);
#else
ret = LOADU(&blake2b_IV[0]);
#endif
}
[Bug target/88965] powerpc64le vector builtin hits ICE in verify_gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965 --- Comment #5 from Anton Blanchard --- Martin: "gcc -c x.c" was enough to hit it on a build of trunk on my POWER9 ppc64le box. Jakub: Thanks, that fixes it for me.
[Bug middle-end/86554] New: Incorrect code generation with signed/unsigned comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86554
Bug ID: 86554
Summary: Incorrect code generation with signed/unsigned
comparison
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
The test case below fails on both ppc64le and x86_64 when built with -O2, I
see:
ret is 1017
ret is < 1
Looking at the code, the < 1 comparison is removed completely.
--
#include
#include
struct foo
{
uint32_t x;
};
typedef struct foo foo;
static inline int zot(foo *f)
{
int ret;
if (f->x > 0x7FFF)
ret = (int)(f->x - 0x7FFF);
else
ret = (int)f->x - 0x7FFF;
return ret;
}
void bar(foo *f)
{
int ret = zot(f);
printf("ret is %d\n", ret);
if (ret < 1)
printf("ret is < 1\n");
}
int main(void)
{
foo f;
f.x = 0x83f8;
bar(&f);
}
[Bug target/87059] New: internal compiler error: in set_value_range, at tree-vrp.c:289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87059
Bug ID: 87059
Summary: internal compiler error: in set_value_range, at
tree-vrp.c:289
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
CC: meissner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux
The following test case:
#include
void d(void);
char *a, *b;
void c(void) {
if (b == a)
return;
if (strncmp(a, "", b - a))
d();
}
hits an ICE on trunk:
gcc -O2 test.c
during RTL pass: expand
test.c: In function ‘c’:
test.c:9:7: internal compiler error: in set_value_range, at tree-vrp.c:289
9 | if (strncmp(a, "", b - a))
| ^
0x10d3ceb7 set_value_range(value_range*, value_range_type, tree_node*,
tree_node*, bitmap_head*)
../../gcc/gcc/tree-vrp.c:289
0x10d4106f extract_range_from_binary_expr_1(value_range*, tree_code,
tree_node*, value_range*, value_range*)
../../gcc/gcc/tree-vrp.c:1893
0x10d43a2b determine_value_range_1
../../gcc/gcc/tree-vrp.c:6866
0x10d43cbf determine_value_range(tree_node*,
generic_wide_int*, generic_wide_int*)
../../gcc/gcc/tree-vrp.c:6901
0x1036385b get_size_range(tree_node*, tree_node**, bool)
../../gcc/gcc/calls.c:1258
0x10369c5b maybe_warn_nonstring_arg(tree_node*, tree_node*)
../../gcc/gcc/calls.c:1617
0x1036c003 initialize_argument_information
../../gcc/gcc/calls.c:2197
0x1036d367 expand_call(tree_node*, rtx_def*, int)
../../gcc/gcc/calls.c:3577
0x103454ef expand_builtin_strncmp
../../gcc/gcc/builtins.c:4793
0x10355f5b expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/gcc/builtins.c:7445
0x1052816f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10943
0x10542cc3 expand_expr
../../gcc/gcc/expr.h:279
0x10542cc3 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/gcc/expr.c:8456
0x10528703 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:11230
0x1053958f expand_expr
../../gcc/gcc/expr.h:279
0x1053958f store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/gcc/expr.c:5556
0x1053b6a3 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5420
0x10388133 expand_call_stmt
../../gcc/gcc/cfgexpand.c:2685
0x10388133 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3575
0x10388133 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3734
The CI that tripped up on this started failing at:
commit 9e4ef9eec6c786e3edbdcb7f26a1d735c9d7f4b9
Author: aldyh
Date: Tue Aug 21 06:27:14 2018 +
* wide-int-range.cc (wide_int_range_abs): New.
(wide_int_range_order_set): Rename from wide_int_range_min_max.
* wide-int-range.h (wide_int_range_abs): New.
(wide_int_range_min_max): New.
* tree-vrp.c (extract_range_from_unary_expr): Rewrite ABS_EXPR
case to call wide_int_range_abs.
Rewrite MIN/MAX_EXPR to call wide_int_range_min_max.
(extract_range_from_abs_expr): Delete.
[Bug target/69567] New: PowerPC64: cstore optimisation produces bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69567 Bug ID: 69567 Summary: PowerPC64: cstore optimisation produces bad code Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org Target Milestone: --- Created attachment 37528 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37528&action=edit Testcase I hit this fail in csmith. Looks like another issue with our cstore optimisation. It fails at -O1.
[Bug target/69810] New: PowerPC64: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69810
Bug ID: 69810
Summary: PowerPC64: unrecognizable insn
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
Another csmith fail on trunk:
int a, b;
void fn1(void)
{
signed char c;
long d;
int e;
repeat:
{
int f = fn1;
e = f == 0 ? : 0 / f;
d = e ? : a;
c = -d;
}
unsigned short g = c;
b = g == 0 ? : 0 / g;
if (b)
goto repeat;
}
# gcc -O1 testcase.c
...
testcase.c:22:1: error: unrecognizable insn:
}
^
(insn 72 71 35 5 (set (reg:CC 75 7 [179])
(compare:CC (reg:HI 7 7)
(const_int 0 [0]))) crash1b.i:19 -1
(nil))
crash1b.i:22:1: internal compiler error: in extract_insn, at recog.c:2287
0x108128f3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x10812957 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:116
0x107d67e7 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2287
0x107d68af extract_insn_cached(rtx_insn*)
../../gcc/gcc/recog.c:2178
0x104d24b7 cleanup_subreg_operands(rtx_insn*)
../../gcc/gcc/final.c:3104
0x107d39b7 split_insn
../../gcc/gcc/recog.c:2901
0x107d9aeb split_all_insns()
../../gcc/gcc/recog.c:2955
0x107d9c2b rest_of_handle_split_after_reload
../../gcc/gcc/recog.c:3891
0x107d9c2b execute
../../gcc/gcc/recog.c:3920
[Bug target/70098] New: PowerPC64: eigen hits ICE in reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098
Bug ID: 70098
Summary: PowerPC64: eigen hits ICE in reload
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
I hit the following ICE when building eigen:
# g++ -O3 -c test2.cpp
test2.cpp: In function ‘void fn3(Matrix)’:
test2.cpp:59:1: error: unable to generate reloads for:
}
^
(jump_insn 17 12 18 2 (parallel [
(set (pc)
(if_then_else (ne (reg:DI 3 3)
(const_int 1 [0x1]))
(label_ref 25)
(pc)))
(set (reg:DI 156 [ _4 ])
(plus:DI (reg:DI 3 3)
(const_int -1 [0x])))
(clobber (reg:CC 172))
(clobber (reg:DI 173))
]) test2.cpp:46 775 {*ctrdi_internal1}
(expr_list:REG_UNUSED (reg:DI 173)
(expr_list:REG_UNUSED (reg:CC 172)
(expr_list:REG_DEAD (reg:DI 3 3)
(int_list:REG_BR_PROB 2900 (nil)
-> 25)
test2.cpp:59:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3552
0x10a711b3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x1093d313 curr_insn_transform
../../gcc/gcc/lra-constraints.c:3552
0x1093e4df lra_constraints(bool)
../../gcc/gcc/lra-constraints.c:4494
0x10923513 lra(_IO_FILE*)
../../gcc/gcc/lra.c:2286
0x108c3ffb do_reload
../../gcc/gcc/ira.c:5396
0x108c3ffb execute
../../gcc/gcc/ira.c:5580
[Bug target/70098] PowerPC64: eigen hits ICE in reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 --- Comment #1 from Anton Blanchard --- Created attachment 37876 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37876&action=edit Test case
[Bug target/70098] PowerPC64: eigen hits ICE in reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 --- Comment #7 from Anton Blanchard --- Sorry, blame my limited understanding of gcc. It fails with both with and without -mlra.
[Bug target/70568] New: PowerPC64: union of floating and fixed doesn't use POWER8 GPR/VSR moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70568
Bug ID: 70568
Summary: PowerPC64: union of floating and fixed doesn't use
POWER8 GPR/VSR moves
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
The following test case from both glibc and openlibm:
typedef union
{
float value;
/* FIXME: Assumes 32 bit int. */
unsigned int word;
} ieee_float_shape_type;
/* Get a 32 bit int from a float. */
#define GET_FLOAT_WORD(i,d) \
do {\
ieee_float_shape_type gf_u; \
gf_u.value = (d); \
(i) = gf_u.word; \
} while (0)
int foo(float d)
{
int i;
GET_FLOAT_WORD(i, d);
return i;
}
Uses the stack to do the conversion:
foo:
stfs 1,-16(1)
ori 2,2,0
lwa 3,-16(1)
LLVM does what I expect:
foo:
xscvdpspn 0, 1
xxsldwi 0, 0, 0, 3
mfvsrwz 3, 0
extsw 3, 3
[Bug target/71186] New: PowerPC64: Autovectorised code hits ICE with -O3 -mpower9 -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71186
Bug ID: 71186
Summary: PowerPC64: Autovectorised code hits ICE with -O3
-mpower9 -mlra
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
The following testcase:
static unsigned short x[(16384/sizeof(unsigned short))] __attribute__ ((aligned
(16)));
static unsigned short y[(16384/sizeof(unsigned short))] __attribute__ ((aligned
(16)));
static unsigned short a;
void obfuscate(void *a, ...);
static void __attribute__((noinline)) do_one(void)
{
unsigned long i;
obfuscate(x, y, &a);
for (i = 0; i < (16384/sizeof(unsigned short)); i++)
y[i] = a * x[i];
obfuscate(x, y, &a);
}
int main(void)
{
unsigned long i;
for (i = 0; i < 100; i++)
do_one();
return 0;
}
built with:
gcc -O3 -Wall -mcpu=power9 -mlra testcase.c
gets an ICE:
scale_unsigned_short.c: In function ‘do_one’:
scale_unsigned_short.c:17:1: error: insn does not satisfy its constraints:
}
^
(insn 81 43 86 3 (set (reg:V8HI 77 0 [199])
(vec_duplicate:V8HI (const_int 0 [0]))) scale_unsigned_short.c:14 1045
{xxspltib_v8hi_nosplit}
(expr_list:REG_EQUIV (const_vector:V8HI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
])
(nil)))
scale_unsigned_short.c:17:1: internal compiler error: in
extract_constrain_insn, at recog.c:2190
0x108211f3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x1082124b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:119
0x107e6f57 extract_constrain_insn(rtx_insn*)
../../gcc/gcc/recog.c:2190
0x106d5137 check_rtl
../../gcc/gcc/lra.c:2022
0x106daa8f lra(_IO_FILE*)
../../gcc/gcc/lra.c:2432
0x1067abab do_reload
../../gcc/gcc/ira.c:5381
0x1067abab execute
../../gcc/gcc/ira.c:5565
[Bug tree-optimization/71309] New: Copying fields within a struct followed by use results in load hit store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71309
Bug ID: 71309
Summary: Copying fields within a struct followed by use results
in load hit store
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
When chasing down a LHS on ppc64le, I found the following issue:
struct path {
void *mnt;
void *dentry;
};
struct nameidata {
struct path path;
struct path root;
};
void *foo(struct nameidata *nd)
{
void *d;
nd->path = nd->root;
d = nd->path.dentry;
return d;
}
On little endian we get:
ld 11,24(3)
ld 10,16(3)
std 11,8(3)
std 10,0(3)
ori 2,2,0
ld 3,8(3)
blr
Strangely big endian is fine:
ld 3,24(3)
ld 10,16(9)
std 3,8(9)
std 10,0(9)
blr
[Bug target/71310] New: Bitfields cause load hit store with smaller store and larger load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71310
Bug ID: 71310
Summary: Bitfields cause load hit store with smaller store and
larger load
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
The following testcase built on ppc64le:
typedef unsigned char __u8;
struct sk_buff {
void*junk;
__u8pkt_type:3;
__u8pfmemalloc:1;
__u8ignore_df:1;
__u8nfctinfo:3;
__u8nf_trace:1;
__u8ip_summed:2;
__u8ooo_okay:1;
__u8l4_hash:1;
__u8sw_hash:1;
__u8wifi_acked_valid:1;
__u8wifi_acked:1;
__u8no_fcs:1;
__u8encapsulation:1;
__u8encap_hdr_csum:1;
__u8csum_valid:1;
};
int foo(struct sk_buff *skb)
{
skb->csum_valid = 1;
if (skb->ip_summed)
return 1;
return 0;
}
Results in a LHS, where the load is larger than the previous store:
lwz 9,8(3)
ori 9,9,0x1000
stw 9,8(3)
ori 2,2,0
ld 9,8(3)
rldicr 9,9,9,54
rldicr 9,9,55,10
addic 3,9,-1
subfe 3,3,9
blr
This may trip up the load hit store forwarding and require the store to hit the
L2 before the load can proceed.
[Bug target/71310] Bitfields cause load hit store with smaller store and larger load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71310
--- Comment #3 from Anton Blanchard ---
Another case found in the kernel:
struct mmu_gather {
long end;
int fullmm : 1;
};
void __tlb_reset_range(struct mmu_gather *p1)
{
if (p1->fullmm)
p1->end = 0;
}
void tlb_gather_mmu(struct mmu_gather *p1)
{
p1->fullmm = 1;
__tlb_reset_range(p1);
}
30: 08 00 23 89 lbz r9,8(r3)
34: 01 00 29 61 ori r9,r9,1
38: 08 00 23 99 stb r9,8(r3)
3c: 00 00 42 60 ori r2,r2,0
40: 08 00 23 e9 ld r9,8(r3)
44: 01 00 2a 71 andi. r10,r9,1
48: 0c 00 82 41 beq 54
4c: 00 00 20 39 li r9,0
50: 00 00 23 f9 std r9,0(r3)
54: 20 00 80 4e blr
[Bug tree-optimization/71509] New: Bitfield causes load hit store with larger store than load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509
Bug ID: 71509
Summary: Bitfield causes load hit store with larger store than
load
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
I notice a nasty load hit store in the following test case built with -O2 on
ppc64le. The load is larger than the store, which means on many CPUs the store
cannot be forwarded and it has to wait until it completes in the cache.
struct sk_buff a;
struct sk_buff {
long blah;
char csum_level:2;
};
void __skb_decr_checksum_unnecessary(struct sk_buff *p1)
{
p1->csum_level--;
}
void func(void);
void tcp_v4_rcv(void)
{
struct sk_buff *b = &a;
func();
__skb_decr_checksum_unnecessary(b);
func();
__skb_decr_checksum_unnecessary(b);
}
We end up with this odd situation where we do both a byte and a double
word load:
# objdump -d testcase.o | grep r31
58: 08 00 5f e9 ld r10,8(r31)
5c: 08 00 3f 89 lbz r9,8(r31)
70: 08 00 3f 99 stb r9,8(r31)
7c: 08 00 5f e9 ld r10,8(r31)
84: 08 00 3f 89 lbz r9,8(r31)
a0: 08 00 3f 99 stb r9,8(r31)
[Bug target/81348] New: PowerPC64: Code built with -mcpu=power9 hits SEGV in RTL split2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81348
Bug ID: 81348
Summary: PowerPC64: Code built with -mcpu=power9 hits SEGV in
RTL split2
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
CC: meissner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux
I hit a SEGV with csmith, a cut down test case:
int a;
short b;
float ***c;
void d(void)
{
int e = 3;
if (a)
e = b;
***c = e;
}
# gcc -Og -mcpu=power9 crash1b.c
during RTL pass: split2
crash1b.c: In function ‘d’:
crash1b.c:13:1: internal compiler error: Segmentation fault
}
^
0x109452d3 crash_signal
../../gcc/gcc/toplev.c:338
0x10440568 df_install_refs
../../gcc/gcc/df-scan.c:2379
0x10440707 df_refs_add_to_chains
../../gcc/gcc/df-scan.c:2424
0x10448ed3 df_insn_rescan(rtx_insn*)
../../gcc/gcc/df-scan.c:1091
0x104d8387 emit_insn_after_1
../../gcc/gcc/emit-rtl.c:4492
0x104d8387 emit_pattern_after_noloc
../../gcc/gcc/emit-rtl.c:4541
0x104d8603 emit_pattern_after_setloc
../../gcc/gcc/emit-rtl.c:4694
0x104d9a77 emit_insn_after_setloc(rtx_def*, rtx_def*, int)
../../gcc/gcc/emit-rtl.c:4739
0x104d9a77 try_split(rtx_def*, rtx_insn*, int)
../../gcc/gcc/emit-rtl.c:3839
0x10871d97 split_insn
../../gcc/gcc/recog.c:2889
0x10878107 split_all_insns()
../../gcc/gcc/recog.c:2978
0x10878177 rest_of_handle_split_before_sched2
../../gcc/gcc/recog.c:4018
0x10878177 execute
../../gcc/gcc/recog.c:4057
[Bug target/78560] New: powerpc64le ICE with -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78560
Bug ID: 78560
Summary: powerpc64le ICE with -mcpu=power9
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
CC: meissner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux
The following test case:
int a, b, d;
short *const c = (short *)&b;
void e(void)
{
d = 3;
for (; d < 100; d++) {
a = 0;
for (; a != 30; a = a + 5)
*c |= 4;
}
}
when built with:
gcc -O3 -mcpu=power9 testcase.c
fails with:
testcase.c: In function ‘e’:
testcase.c:13:1: error: unrecognizable insn:
}
^
(insn 7 6 8 2 (set (reg:V8HI 166)
(unspec:V8HI [
(reg:V8HI 166)
(mem/c:HI (reg/f:DI 167) [2 MEM[(short int *)&b]+0 S2 A32])
(const_int 0 [0])
] UNSPEC_VSX_SET)) -1
(nil))
testcase.c:13:1: internal compiler error: in extract_insn, at recog.c:2311
0x1086b173 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x1086b1d7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:116
0x1082f137 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2311
0x10564c5b instantiate_virtual_regs_in_insn
../../gcc/gcc/function.c:1589
0x10564c5b instantiate_virtual_regs
../../gcc/gcc/function.c:1956
0x10564c5b execute
../../gcc/gcc/function.c:2005
[Bug target/78658] New: powerpc64le: ICE with -mcpu=power9 -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78658
Bug ID: 78658
Summary: powerpc64le: ICE with -mcpu=power9 -Og
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
CC: meissner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux
The following test case:
float a;
char b;
void c(void) { a = b = a; }
when built with:
gcc -Og -mcpu=power9 crash1.i
hits an ICE:
crash1.i: In function ‘c’:
crash1.i:3:1: error: unrecognizable insn:
void c(void) { a = b = a; }
^~~~
(insn 20 10 21 2 (set (scratch:DI)
(zero_extend:DI (reg:QI 32 0 [159]))) "crash1.i":3 -1
(nil))
crash1.i:3:1: internal compiler error: in extract_insn, at recog.c:2311
0x1086d6d3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x1086d737 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:116
0x108316b7 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2311
0x1083177f extract_insn_cached(rtx_insn*)
../../gcc/gcc/recog.c:2201
0x10514737 cleanup_subreg_operands(rtx_insn*)
../../gcc/gcc/final.c:3138
0x1082e817 split_insn
../../gcc/gcc/recog.c:2925
0x108349bf split_all_insns()
../../gcc/gcc/recog.c:2978
0x10834aa7 rest_of_handle_split_before_sched2
../../gcc/gcc/recog.c:4019
0x10834aa7 execute
../../gcc/gcc/recog.c:4058
[Bug target/79179] New: PowerPC64: -mcpu=power9 creates stxsd with bad offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79179
Bug ID: 79179
Summary: PowerPC64: -mcpu=power9 creates stxsd with bad offset
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
CC: meissner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
The following test case:
#pragma pack(1)
struct {
signed : 1;
unsigned long a;
} b;
void c(void)
{
b.a = 0;
for (; b.a <= 45; b.a = (long)b.a + 1)
;
}
built with:
# gcc -O3 -mcpu=power9 crash1.i
Creates an stxsd instruction with a bad offset:
/tmp/cckULtLs.s: Assembler messages:
/tmp/cckULtLs.s:32: Error: operand out of domain (1 is not a multiple of 4)
which is:
stxsd 12,1(9)
[Bug target/77613] New: Powerpc64le: redundant swaps in autovectorised loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77613
Bug ID: 77613
Summary: Powerpc64le: redundant swaps in autovectorised loop
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
CC: meissner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux
The following test case:
void testcase(signed short a, signed short *x, signed short *y)
{
unsigned long i;
for (i = 0; i < 1024; i++)
y[i] = a * x[i] + y[i];
}
has redundant swaps on the way in and out:
lxvd2x 32,8,9
lxvd2x 33,10,9
xxpermdi 32,32,32,2
xxpermdi 33,33,33,2
vmladduhm 0,13,0,1
xxpermdi 0,32,32,2
stxvd2x 0,10,9
[Bug middle-end/71509] Bitfield causes load hit store with larger store than load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509 --- Comment #4 from Anton Blanchard --- Created attachment 39683 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39683&action=edit Another bitop LHS test case Here's another issue found in the Linux kernel. Seems like this should be a single lwz/stw since the union of counter and the bitops completely overlap. The half word store followed by word load is going to prevent it from store forwarding. : 0: 00 00 03 81 lwz r8,0(r3) 4: 20 00 89 78 clrldi r9,r4,32 8: c2 0f 2a 79 rldicl r10,r9,33,31 c: 00 f8 48 51 rlwimi r8,r10,31,0,0 10: 5e 00 2a 55 rlwinm r10,r9,0,1,15 14: 00 00 03 91 stw r8,0(r3) 18: 00 00 83 b0 sth r4,0(r3) 1c: 00 00 42 60 ori r2,r2,0 20: 00 00 23 81 lwz r9,0(r3) 24: 00 04 29 55 rlwinm r9,r9,0,16,0 28: 78 53 29 7d or r9,r9,r10 2c: 00 00 23 91 stw r9,0(r3) 30: 20 00 80 4e blr
[Bug middle-end/60737] New: rs6000 expand_block_clear uses word stores on double word pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60737
Bug ID: 60737
Summary: rs6000 expand_block_clear uses word stores on double
word pointer
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
The following code:
#include
void foo(long *p)
{
memset(p, 0, 16);
}
When built with a 64bit target:
gcc -mcpu=power8 -O2 -S foo.c
Ends up using 32 byte stores:
foo:
li 9,0
stw 9,0(3)
stw 9,4(3)
stw 9,8(3)
stw 9,12(3)
blr
expand_block_move has a similar issue
[Bug middle-end/60737] rs6000 expand_block_clear uses word stores on double word pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60737 --- Comment #1 from Anton Blanchard --- It looks like by the time we get to expand_block_clear we don't have any alignment info (align_rtx == 1).
[Bug go/60870] New: go interface methods broken on ppc64le (bug296.go)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60870 Bug ID: 60870 Summary: go interface methods broken on ppc64le (bug296.go) Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: anton at samba dot org bug296.go is failing on a checkout from today. The caller is putting the 9th argument in r1+32 instead of r1+96 where we expect: 0x1000195c <+140>:std r27,32(r1) <- 0x10001960 <+144>:li r10,22 0x10001964 <+148>:std r2,24(r1) 0x10001968 <+152>:addir31,r31,1 0x1000196c <+156>:mtctr r11 The failure bisected to: 2c809f8f2584460a5207662cc8e064486cb0ec30 (Sync to current external repository)
[Bug go/60870] go interface methods broken on ppc64le (bug296.go)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60870 --- Comment #1 from Anton Blanchard --- I just realised I gave a git commit id from the mirror. The ChangeLog entry is: +2014-04-14 Chris Manghane + + * go-gcc.cc: Include "convert.h". + (Gcc_backend::string_constant_expression): New function. + (Gcc_backend::real_part_expression): Likewise. + (Gcc_backend::imag_part_expression): Likewise. + (Gcc_backend::complex_expression): Likewise. + (Gcc_backend::constructor_expression): Likewise. + (Gcc_backend::array_constructor_expression): Likewise. + (Gcc_backend::pointer_offset_expression): Likewise. + (Gcc_backend::array_index_expression): Likewise. + (Gcc_backend::call_expression): Likewise. + (Gcc_backend::exception_handler_statement): Likewise. + (Gcc_backend::function_defer_statement): Likewise. + (Gcc_backend::function_set_parameters): Likewise. + (Gcc_backend::function_set_body): Likewise. + (Gcc_backend::convert_expression): Handle various type + conversions.
[Bug go/60931] New: libgo has issues when page size is not 4k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931 Bug ID: 60931 Summary: libgo has issues when page size is not 4k Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: anton at samba dot org Created attachment 32659 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32659&action=edit Bump page size to 64kB We are seeing random failures with go programs on a 64kB page size ppc64 box. It looks like garbage collection issues - sometimes we SEGV in timer code, sometimes we SEGV in the code that wraps a kernel read syscall. If I prevent the garbage collector from running, the programs work. The libgo malloc hard codes the page size so I wrote a quick hack to bump this (and a few other dependent variables). This makes the problem go away, but we will need to come up with a better way to do this at runtime.
[Bug go/60931] libgo has issues when page size is not 4k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931 --- Comment #2 from Anton Blanchard --- I agree, but when I tried this I found a few places that expect PageSize to be a compile time constant so it is not as trivial as I had hoped.
[Bug go/60931] libgo has issues when page size is not 4k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931 Anton Blanchard changed: What|Removed |Added Attachment #32659|0 |1 is obsolete|| --- Comment #4 from Anton Blanchard --- Created attachment 32669 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32669&action=edit Don't use madvise(DONT_NEED) on sub pages
[Bug go/60931] libgo has issues when page size is not 4k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931 --- Comment #5 from Anton Blanchard --- I think I see it: 19112 madvise(0xc21103, 4096, MADV_DONTNEED) = 0 That 4kB madvise(MADV_DONTNEED) gets rounded up to the system page size of 64kB and we end up covering still in use memory. The following patch fixes it for me, but it just ignores any sub pages. We should keep them around so later calls have a chance at consolidating regions up to a system page size.
[Bug go/60931] libgo has issues when page size is not 4k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931 Anton Blanchard changed: What|Removed |Added Attachment #32669|0 |1 is obsolete|| --- Comment #7 from Anton Blanchard --- Created attachment 32679 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32679&action=edit runtime: Fix garbage collector issue with non 4kB system page size The go garbage collector tracks memory in terms of 4kB pages. Most of the code checks getpagesize() at runtime and does the right thing. On a 64kB ppc64 box I see SEGVs in long running processes which has been diagnosed as a bug in scavengelist. scavengelist does a madvise(MADV_DONTNEED) without rounding the arguments to the system page size. A strace of one of the failures shows the problem: madvise(0xc21103, 4096, MADV_DONTNEED) = 0 The kernel rounds the length up to 64kB and we mark 60kB of valid data as no longer needed. Round start up to a system page and end down before calling madvise.
[Bug target/65456] New: powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 Bug ID: 65456 Summary: powerpc64le autovectorized copy loop missed optimization Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org Created attachment 35049 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35049&action=edit Testcase pulled from valgrind The attached copy loop (out of valgrind) produces some pretty bad code: df8: e4 06 9e 78 rldicr r30,r4,0,59 dfc: e4 26 df 78 rldicr r31,r6,4,59 e00: 10 00 84 38 addir4,r4,16 e04: 01 00 c6 38 addir6,r6,1 e08: 99 f6 20 7c lxvd2x vs33,0,r30 e0c: 57 0a 21 f0 xxswapd vs33,vs33 e10: 2b 03 a1 11 vperm v13,v1,v0,v12 e14: 97 0c 01 f0 xxlor vs32,vs33,vs33 e18: 56 6a 0d f0 xxswapd vs0,vs45 e1c: 98 4f 1f 7c stxvd2x vs0,r31,r9 e20: d8 ff 00 42 bdnzdf8 Since we are using VSX storage ops, we should just align the source and do unaligned stores. That will remove the permute, and then the gcc pass to remove redundant swaps should kick in and remove them too.
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 --- Comment #7 from Anton Blanchard --- Thanks Martin. Bill: the swaps pass isn't catching our vectorised copy, I guess because of the adds in the loop: lxvd2x 0,9,4 addi 28,1,-48 add 6,9,10 xxpermdi 12,0,0,2 xxpermdi 12,12,12,2 stxvd2x 12,0,28
[Bug target/59814] New: powerpc64le ICE with -O2 -mpower8 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59814
Bug ID: 59814
Summary: powerpc64le ICE with -O2 -mpower8 -ffast-math
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
The following test case:
/* -O2 -mcpu=power8 -ffast-math */
float val;
int verbose;
void bar(float x);
void foo(void)
{
if (val < 0.0) {
val = 1.0;
if (!verbose)
zot();
bar(val);
}
}
fails with:
# gcc -c -O2 -mcpu=power8 -ffast-math testcase.c
testcase.c: In function ‘foo’:
testcase.c:16:1: error: unrecognizable insn:
}
^
(insn 52 16 3 3 (parallel [
(set (reg:SF 33 1 [orig:125 D.2152 ] [125])
(unspec:SF [
(reg:SF 9 9 [131])
] UNSPEC_P8V_RELOAD_FROM_GPR))
(clobber (reg:DI 8 8))
]) -1
(nil))
testcase.c:16:1: internal compiler error: in extract_insn, at recog.c:2154
[Bug tree-optimization/59817] New: ICE in extract_affine_chrec with -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59817 Bug ID: 59817 Summary: ICE in extract_affine_chrec with -O2 -ftree-loop-linear Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org The following testcase: c -O2 -ftree-loop-linear SUBROUTINE PREPD(ICAST,ICAS,ICASX,ICAS1,ICAS2,NDET,NM,III,IMP, * CASMIN) LOGICAL CASMIN DIMENSION ICAST(NDET,NM),IMP(NM) IF(CASMIN) THEN DO K=1,NDET DO L=1,NM IF(L.EQ.K-1) ICAST(K,L) = 1 END DO END DO END IF fails on a powerpc64-linux build from today with: # gfortran -c -O2 -ftree-loop-linear testcase.f testcase.f: In function ‘prepd’: testcase.f:3:0: internal compiler error: in extract_affine_chrec, at graphite-sese-to-poly.c:620 SUBROUTINE PREPD(ICAST,ICAS,ICASX,ICAS1,ICAS2,NDET,NM,III,IMP, ^ 0x10cf684f extract_affine_chrec ../../gcc/gcc/graphite-sese-to-poly.c:619 0x10cf684f extract_affine ../../gcc/gcc/graphite-sese-to-poly.c:803 0x10cf62fb extract_affine ../../gcc/gcc/graphite-sese-to-poly.c:842 0x10cf843f pdr_add_memory_accesses ../../gcc/gcc/graphite-sese-to-poly.c:1486 0x10cf843f build_poly_dr ../../gcc/gcc/graphite-sese-to-poly.c:1583 0x10cf843f build_pbb_drs ../../gcc/gcc/graphite-sese-to-poly.c:1846 0x10cf843f build_scop_drs ../../gcc/gcc/graphite-sese-to-poly.c:1929 0x10cfa8d7 build_poly_scop(scop*) ../../gcc/gcc/graphite-sese-to-poly.c:3171 0x10cdcabb graphite_transform_loops() ../../gcc/gcc/graphite.c:300 0x10cdd227 graphite_transforms ../../gcc/gcc/graphite.c:332 0x10cdd227 execute ../../gcc/gcc/graphite.c:416
[Bug tree-optimization/68140] New: ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1413
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68140
Bug ID: 68140
Summary: ICE in vect_get_vec_def_for_operand, at
tree-vect-stmts.c:1413
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
I'm seeing an ICE on powerpc64le with a checkout from last night:
# cat testcase.c
int a, b, d, e, f;
static int c;
static void fn1(void)
{
int b = 3;
for (; b >= 0; b--) {
e ^= f;
d = 0;
for (; d <= 3; d++) {
e |= f;
for (; c;)
for (;;) ;
}
}
}
int main(void)
{
if (a)
fn1();
return 0;
}
# gcc -O3 testcase.c -Wall
testcase.c: In function ‘main’:
testcase.c:18:5: internal compiler error: in vect_get_vec_def_for_operand, at
tree-vect-stmts.c:1413
int main(void)
^
0x10aed307 vect_get_vec_def_for_operand(tree_node*, gimple*)
../../gcc/gcc/tree-vect-stmts.c:1413
0x10aedab7 vect_get_vec_defs(tree_node*, tree_node*, gimple*, vec*, vec*, _slp_tree*, int)
../../gcc/gcc/tree-vect-stmts.c:1574
0x10af441b vectorizable_operation
../../gcc/gcc/tree-vect-stmts.c:4894
0x10b0420f vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*,
_slp_tree*, _slp_instance*)
../../gcc/gcc/tree-vect-stmts.c:7693
0x10b0bedf vect_transform_loop(_loop_vec_info*)
../../gcc/gcc/tree-vect-loop.c:6452
0x10b2c70b vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:512
0x10a0c6fb execute
../../gcc/gcc/tree-ssa-loop.c:278
[Bug middle-end/68393] New: internal compiler error: in convert_move, at expr.c:286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68393
Bug ID: 68393
Summary: internal compiler error: in convert_move, at
expr.c:286
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
I'm seeing an ICE on powerpc64le when building trunk:
x.c:3:9: internal compiler error: in convert_move, at expr.c:286
return __builtin_clzll(x);
^~
0x104a8907 convert_move(rtx_def*, rtx_def*, int)
../../gcc/gcc/expr.c:286
0x105c12ab expand_direct_optab_fn
../../gcc/gcc/internal-fn.c:2114
0x105c1f17 expand_internal_call(internal_fn, gcall*)
../../gcc/gcc/internal-fn.c:2245
0x10348443 expand_call_stmt
../../gcc/gcc/cfgexpand.c:2565
0x10348443 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3525
0x10348443 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3688
0x1034a5df expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5694
0x10351c87 execute
../../gcc/gcc/cfgexpand.c:6309
A testcase:
unsigned long foo(x)
{
return __builtin_clzll(x);
}
[Bug middle-end/68393] internal compiler error: in convert_move, at expr.c:286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68393 Anton Blanchard changed: What|Removed |Added CC||richard.guenther at gmail dot com, ||rsandifo at gcc dot gnu.org --- Comment #1 from Anton Blanchard --- Bisected to r230487 "Short-cut generation of simple built-in functions"
[Bug tree-optimization/66949] [6 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu in tree_ssa_phiopt_worker, at tree-ssa-phiopt.c:335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66949
Anton Blanchard changed:
What|Removed |Added
CC||anton at samba dot org
--- Comment #3 from Anton Blanchard ---
I'm seeing this on powerpc64le with the following testcase:
char a;
int b, c, d;
short fn1(short p1, short p2)
{
return p2 == 0 ? p1 : p1 / p2;
}
int main(void)
{
char e = 1;
int f = 7;
c = a >> f;
b = fn1(c, 0 < d <= e && fn2());
return 0;
}
# gcc -O3 -c crash1.i
crash1.i: In function ‘main’:
crash1.i:14:27: warning: implicit declaration of function ‘fn2’
[-Wimplicit-function-declaration]
b = fn1(c, 0 < d <= e && fn2());
^~~
crash1.i:9:5: internal compiler error: in tree_ssa_phiopt_worker, at
tree-ssa-phiopt.c:322
int main(void)
^~~~
0x10a46a23 tree_ssa_phiopt_worker
../../gcc/gcc/tree-ssa-phiopt.c:322
[Bug middle-end/68393] internal compiler error: in convert_move, at expr.c:286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68393 --- Comment #3 from Anton Blanchard --- No problems Richard! Thanks for the quick fix, it works for me.
[Bug ipa/64550] New: IPA fixes cause ICE in tree-ssa.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64550 Bug ID: 64550 Summary: IPA fixes cause ICE in tree-ssa.c:939 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org I just hit the following ICE on our autobuilder: /var/lib/jenkins/workspace/gcc_kernel_build/linux/net/core/dev.c: In function ‘dev_change_net_namespace.part.23’: /var/lib/jenkins/workspace/gcc_kernel_build/linux/net/core/dev.c:7435:1: internal compiler error: in verify_ssa, at tree-ssa.c:939 subsys_initcall(net_dev_init); ^ 0x10a5c9c7 verify_ssa(bool, bool) ../../gcc/gcc/tree-ssa.c:939 0x1070531b execute_function_todo ../../gcc/gcc/passes.c:1947 0x10705f63 do_per_function ../../gcc/gcc/passes.c:1639 0x10706127 execute_todo ../../gcc/gcc/passes.c:1997 Please submit a full bug report, The two changes are: Commit 04478c40f34f1b104f0281393b950020ddafdf82 by marxin Fix for ipa/PR64503 PR ipa/64503 * sreal.c (sreal::dump): Change unsigned format to signed for m_exp value. (sreal::to_double): Replace exp2 with scalbln. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219378 138bc75d-0d04-0410-961f-82ee72b054a4 and: Commit 05e3f0539fbe21709229cd34e1fa0d6ead1b0d2f by marxin IPA ICF: compare_operand is split to multiple functions. * ipa-icf-gimple.c (func_checker::compare_ssa_name): Enhance SSA name comparison. (func_checker::compare_memory_operand): New function. (func_checker::compare_operand): Split case to newly added functions. (func_checker::compare_cst_or_decl): New function. (func_checker::compare_gimple_call): Identify memory operands. (func_checker::compare_gimple_assign): Likewise. * ipa-icf-gimple.h: New function.
[Bug ipa/64550] [5 Regression] IPA fixes cause ICE in tree-ssa.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64550 --- Comment #2 from Anton Blanchard --- The testcase in bug #64090 hits it, but for some reason the testcase in the bug it was duped to does not.
[Bug ipa/64550] [5 Regression] IPA fixes cause ICE in tree-ssa.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64550 --- Comment #5 from Anton Blanchard --- Thanks Martin, the patch fixes the issue for me.
[Bug target/64624] New: ppc64 build failure, ISA_2_7_MASKS_SERVER not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64624 Bug ID: 64624 Summary: ppc64 build failure, ISA_2_7_MASKS_SERVER not declared Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org I'm seeing this build error as of: * config/rs6000/default64.h (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8). g++ -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o options.o -MT options.o -MMD -MP -MF ./.deps/options.TPo options.c In file included from tm.h:30:0, from options.c:7: ../../gcc/gcc/config/rs6000/default64.h:23:25: error: ‘ISA_2_7_MASKS_SERVER’ was not declared in this scope #define TARGET_DEFAULT (ISA_2_7_MASKS_SERVER | MASK_POWERPC64 | MASK_64BIT | MASK_LITTLE_ENDIAN) ^ options.c:828:3: note: in expansion of macro ‘TARGET_DEFAULT’ TARGET_DEFAULT, /* rs6000_isa_flags */ ^
[Bug target/64624] ppc64 build failure, ISA_2_7_MASKS_SERVER not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64624 Anton Blanchard changed: What|Removed |Added Target||powerpc64le- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Anton Blanchard --- Network issues during submit, ended up with two identical bugs. *** This bug has been marked as a duplicate of bug 64623 ***
[Bug target/64623] New: ppc64 build failure, ISA_2_7_MASKS_SERVER not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64623 Bug ID: 64623 Summary: ppc64 build failure, ISA_2_7_MASKS_SERVER not declared Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org I'm seeing this build error as of: * config/rs6000/default64.h (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8). g++ -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o options.o -MT options.o -MMD -MP -MF ./.deps/options.TPo options.c In file included from tm.h:30:0, from options.c:7: ../../gcc/gcc/config/rs6000/default64.h:23:25: error: ‘ISA_2_7_MASKS_SERVER’ was not declared in this scope #define TARGET_DEFAULT (ISA_2_7_MASKS_SERVER | MASK_POWERPC64 | MASK_64BIT | MASK_LITTLE_ENDIAN) ^ options.c:828:3: note: in expansion of macro ‘TARGET_DEFAULT’ TARGET_DEFAULT, /* rs6000_isa_flags */ ^ --- Comment #1 from Anton Blanchard --- *** Bug 64624 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/64090] New: internal compiler error: in verify_ssa, at tree-ssa.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64090 Bug ID: 64090 Summary: internal compiler error: in verify_ssa, at tree-ssa.c:939 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org Created attachment 34128 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34128&action=edit Testcase that ICE's A powerpc64le-linux build gets the following ICE with the attached testcase: internal compiler error: in verify_ssa, at tree-ssa.c:939 } ^ 0x10a76c97 verify_ssa(bool, bool) ../../gcc/gcc/tree-ssa.c:939 0x1072377b execute_function_todo ../../gcc/gcc/passes.c:1947 0x107243c3 do_per_function ../../gcc/gcc/passes.c:1639 0x10724587 execute_todo ../../gcc/gcc/passes.c:1997 gcc version 5.0.0 20141126 (experimental) (GCC)
[Bug target/63281] New: powerpc64le creates 64 bit constants from scratch instead of loading them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
Bug ID: 63281
Summary: powerpc64le creates 64 bit constants from scratch
instead of loading them
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
The following testcase:
#define CONST1 0x1234567812345678
#define CONST2 0x2345678123456781
#define CONST3 0x3456781234567812
#define CONST4 0x4567812345678123
#define CONST5 0x5678123456781234
#define CONST6 0x6781234567812345
#define CONST7 0x7812345678123456
#define CONST8 0x8123456781234567
void foo(unsigned long *a, unsigned long *b, unsigned long *c,
unsigned long *d, unsigned long *e, unsigned long *f,
unsigned long *g, unsigned long *h)
{
*a = CONST1;
*b = CONST2;
*c = CONST3;
*d = CONST4;
*e = CONST5;
*f = CONST6;
*g = CONST7;
*h = CONST8;
}
produces some pretty horrible code. We really should be loading the constants.
This looks to be present on 4.8, 4.9 and 5.0.
foo:
std 27,-40(1)
std 28,-32(1)
lis 27,0x1234
lis 28,0x2345
std 29,-24(1)
std 30,-16(1)
lis 29,0x3456
lis 30,0x4567
std 31,-8(1)
lis 31,0x5678
ori 27,27,0x5678
ori 28,28,0x6781
ori 29,29,0x7812
ori 30,30,0x8123
ori 31,31,0x1234
sldi 27,27,32
sldi 28,28,32
sldi 29,29,32
sldi 30,30,32
sldi 31,31,32
lis 12,0x6781
lis 0,0x7812
lis 11,0x8123
oris 27,27,0x1234
oris 28,28,0x2345
oris 29,29,0x3456
oris 30,30,0x4567
oris 31,31,0x5678
ori 27,27,0x5678
ori 28,28,0x6781
ori 29,29,0x7812
ori 30,30,0x8123
ori 31,31,0x1234
std 27,0(3)
ld 27,-40(1)
ori 12,12,0x2345
ori 0,0,0x3456
std 28,0(4)
std 29,0(5)
ori 11,11,0x4567
sldi 12,12,32
std 30,0(6)
ld 28,-32(1)
ld 29,-24(1)
sldi 0,0,32
sldi 11,11,32
std 31,0(7)
ld 30,-16(1)
ld 31,-8(1)
oris 12,12,0x6781
oris 0,0,0x7812
oris 11,11,0x8123
ori 12,12,0x2345
ori 0,0,0x3456
ori 11,11,0x4567
std 12,0(8)
std 0,0(9)
std 11,0(10)
blr
[Bug target/63354] New: -pg -mprofile-kernel creates unused stack frames on leaf functions on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63354
Bug ID: 63354
Summary: -pg -mprofile-kernel creates unused stack frames on
leaf functions on ppc64le
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
The following testcase:
int foo(void)
{
return 1;
}
compiled with:
gcc -O2 -pg -mprofile-kernel -S foo.c
produces an unused stack frame:
foo:
mflr 0
std 0,16(1)
bl _mcount
mflr 0
li 3,1
std 0,16(1)
stdu 1,-32(1)
addi 1,1,32
ori 2,2,0
ld 0,16(1)
mtlr 0
blr
Note that older gcc versions allowed -mprofile-kernel to used on its own. While
there are issues with that (eg ignoring attribute no_instrument_function), it
does show the expected behaviour:
gcc -O2 -mprofile-kernel -S foo.c
foo:
mflr 0
std 0,16(1)
bl _mcount
li 3,1
blr
So it seems to be something to do with -pg.
[Bug target/63354] gcc -pg -mprofile-kernel creates unused stack frames on leaf functions on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63354 --- Comment #2 from Anton Blanchard --- Created attachment 33555 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33555&action=edit Avoid an unused stack frame for -mprofile-kernel profiling on leaf functions.
[Bug target/68609] New: PowerPC reciprocal estimate missed opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68609
Bug ID: 68609
Summary: PowerPC reciprocal estimate missed opportunities
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
gcc.target/i386/recip-sqrtf.c shows some missed opportunities for the
reciprocal estimate instructions. One example:
float t3(float a)
{
return sqrtf(a);
}
On x86 (and PowerPC clang), we use the square root reciprocal estimate
instructions, but PowerPC gcc does not.
[Bug target/68664] New: PowerPC: speculative sqrt in c-ray main loop causes large slow down
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664 Bug ID: 68664 Summary: PowerPC: speculative sqrt in c-ray main loop causes large slow down Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org Target Milestone: --- c-ray (a tiny ray tracer) can be found at: http://www.sgidepot.co.uk/depot/c-ray-1.1.tar.gz When built and run with the following args: gcc -mcpu=power8 -O3 -ffast-math -o c-ray-mt c-ray-mt.c -lpthread -lm ./c-ray-mt -t 1 -s 768x432 -r 8 -i sphfract -o sphfract.ppm a speculative sqrt is scheduled inside the hottest loop: 2.46 :10001a44: ld r9,72(r9) 0.00 :10001a48: cmpdi cr7,r9,0 0.00 :10001a4c: beq cr7,10001be0 0.05 :10001a50: lfd f8,0(r9) 0.00 :10001a54: lfd f9,8(r9) 0.00 :10001a58: lfd f0,16(r9) 0.00 :10001a5c: lfd f7,24(r9) 2.74 :10001a60: fmadd f2,f8,f8,f1 0.05 :10001a64: fmulf12,f9,f5 0.00 :10001a68: fsubf11,f5,f9 0.00 :10001a6c: fsubf6,f4,f8 0.00 :10001a70: fsubf10,f3,f0 5.34 :10001a74: fmadd f9,f9,f9,f2 0.08 :10001a78: fnmadd f8,f8,f4,f12 0.00 :10001a7c: xsmuldp vs11,vs11,vs33 0.00 :10001a80: fmadd f9,f0,f0,f9 9.99 :10001a84: fnmsub f12,f0,f3,f8 0.10 :10001a88: xsmaddadp vs11,vs32,vs6 0.00 :10001a8c: fnmsub f0,f7,f7,f9 0.00 :10001a90: xsmaddadp vs11,vs45,vs10 11.32 :10001a94: xsmaddadp vs0,vs12,vs43 0.16 :10001a98: faddf12,f11,f11 0.00 :10001a9c: xsmuldp vs0,vs0,vs44 0.01 :10001aa0: fmsub f0,f12,f12,f0 64.34 :10001aa4: fcmpu cr7,f0,f31 0.97 :10001aa8: fsqrt f11,f0 <- here I am 0.00 :10001aac: blt cr7,10001a44 Building with -fno-sched-spec improves performance by almost 2x: gcc -mcpu=power8 -O3 -ffast-math -fno-sched-spec -o c-ray-mt c-ray-mt.c -lpthread -lm
[Bug lto/68685] New: LTO build hits ICE in copy_to_mode_reg, at explow.c:595
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68685 Bug ID: 68685 Summary: LTO build hits ICE in copy_to_mode_reg, at explow.c:595 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org Target Milestone: --- Created attachment 36905 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36905&action=edit Test case On a powerpc64le-linux target, the attached test case when built with: gcc -O2 -flto -mno-vsx -mno-altivec -c pgtable_64.i gcc -O2 -flto -mno-vsx -maltivec -c xor_vmx.i gcc -O2 -flto -mno-vsx -maltivec pgtable_64.o xor_vmx.o fails with: arch/powerpc/lib/xor_vmx.c:127:0: internal compiler error: in copy_to_mode_reg, at explow.c:595 XOR(v1, v2); 0x1036578f copy_to_mode_reg(machine_mode, rtx_def*) ../../gcc/gcc/explow.c:595 0x10b12e03 rs6000_expand_binop_builtin ../../gcc/gcc/config/rs6000/rs6000.c:12746 0x10b4e047 rs6000_expand_builtin ../../gcc/gcc/config/rs6000/rs6000.c:14798 0x102025ff expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) ../../gcc/gcc/builtins.c:5610 0x1038484b expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:10578 0x1039264b store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, tree_node*) ../../gcc/gcc/expr.c:5405 0x103945a3 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/gcc/expr.c:5174 0x102302eb expand_call_stmt ../../gcc/gcc/cfgexpand.c:2635 0x102302eb expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3525 0x102302eb expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:3688 0x10232abf expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:5694 0x1023a167 execute ../../gcc/gcc/cfgexpand.c:6309
[Bug target/68690] New: PowerPC64: TOC save in PHP core loop results in load hit store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68690
Bug ID: 68690
Summary: PowerPC64: TOC save in PHP core loop results in load
hit store
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
We see a load hit store issue in the core loop of the PHP interpreter. A simple
test case:
$ cat test.c
void (*fn)(void);
void do_nothing(void) { }
int main(void)
{
unsigned long i;
fn = do_nothing;
for (i = 0; i < 10; i++)
fn();
return 0;
}
$ gcc -O2 -o test test.c
We continually save the TOC on each call:
13f0: 00 00 3e e9 ld r9,0(r30)
13f4: a6 03 29 7d mtctr r9
13f8: 78 4b 2c 7d mr r12,r9
13fc: 18 00 41 f8 std r2,24(r1) <-- save it again!
1400: 21 04 80 4e bctrl
1404: 18 00 41 e8 ld r2,24(r1)
1408: 01 00 3f 2c cmpdi r31,1
140c: ff ff ff 3b addir31,r31,-1
1410: e0 ff 82 40 bne 13f0
This should be moved out of the loop. One way to force that is via the
-msave-toc-indirect option:
gcc -msave-toc-indirect -O2 -o test test.c
Which is over 2x faster on this (admittedly worst case) test. For something
more real world, we also see a 20% speedup on PHP7 on various microbenchmarks.
[Bug middle-end/26724] __builtin_constant_p fails to recognise function with constant return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26724
--- Comment #2 from Anton Blanchard ---
This issue is still present. The workaround Andrew suggests is good:
static inline int baz(void)
{
return 0;
}
void bad()
{
int i = baz();
if (!__builtin_constant_p(i))
FAIL();
}
[Bug target/68752] New: PowerPC: vector reciprocal square root estimate missed optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68752 Bug ID: 68752 Summary: PowerPC: vector reciprocal square root estimate missed optimisations Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org Target Milestone: --- Created attachment 36938 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36938&action=edit Test cases This test case (based on the existing x86 one) shows places we could be using vector reciprocal square root estimate instructions but aren't.
[Bug target/68753] New: PowerPC: double precision reciprocal estimate missed optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68753 Bug ID: 68753 Summary: PowerPC: double precision reciprocal estimate missed optimisations Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org Target Milestone: --- Created attachment 36939 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36939&action=edit Test cases POWER6 and above should use reciprocal estimate instructions for double precision. Attached is a set of test cases based on our single precision ones. Some of them fail.
[Bug target/68879] New: PowerPC: SImode cstore optimisation produces bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68879 Bug ID: 68879 Summary: PowerPC: SImode cstore optimisation produces bad code Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org Target Milestone: --- Created attachment 37017 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37017&action=edit Test case csmith found an issue that bisects to "rs6000: Optimise SImode cstore on 64-bit" Attached is a simplified test case. A diff shows: - addi 9,10,2 - orc 9,9,10 - srwi 9,9,31 + subf 9,9,6 + srdi 9,9,63 + xori 9,9,0x1
[Bug target/69143] New: PowerPC64: aggregate results are badly handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69143
Bug ID: 69143
Summary: PowerPC64: aggregate results are badly handled
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
This testcase:
struct foo1 {
float x;
float y;
};
struct foo1 blah1(struct foo1 y)
{
struct foo1 x;
x.x = y.y;
x.y = y.x;
return x;
}
Compiled with:
gcc -fno-stack-protector -mcpu=power8 -O2
Results in the following code:
blah1:
xscvdpspn 12,2
stfs 1,-16(1)
ori 2,2,0
lwz 8,-16(1)
mfvsrd 10,12
mr 9,8
rldicl 9,9,0,32
srdi 10,10,32
sldi 10,10,32
or 9,9,10
rotldi 9,9,32
mr 10,9
srdi 9,9,32
sldi 8,10,32
sldi 10,9,32
mtvsrd 1,8
mtvsrd 2,10
xscvspdpn 1,1
xscvspdpn 2,2
blr
I was expecting a couple of FPR moves. Clang does what I expected:
blah1:
fmr 0, 1
fmr 1, 2
fmr 2, 0
blr
[Bug lto/68685] LTO build hits ICE in copy_to_mode_reg, at explow.c:595
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68685 Anton Blanchard changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Anton Blanchard --- The original testcase now makes it past the failure.
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
Anton Blanchard changed:
What|Removed |Added
CC||anton at samba dot org
--- Comment #12 from Anton Blanchard ---
I hit this when building MariaDB. Reduced testcase:
typedef struct bn_gencb_st BN_GENCB;
struct bn_gencb_st {
void *arg;
union {
int (*cb_2)(int, int, BN_GENCB *);
};
};
g++ -O0 -g -c testcase.i
testcase.i:5:15: error: TYPE_CANONICAL is not compatible
union {
^
public unsigned DI
size
unit size
align 64 symtab 0 alias set -1 canonical type 0x3fff76e01110
pointer_to_this >
decl_3 VOID file testcase.i line 4 col 15
align 1 offset_align 1 context
chain
nonlocal decl_4 VOID file testcase.i line 3 col 20
align 1 context result
chain >> context
full-name "struct bn_gencb_st"
n_parents=0 use_template=0 interface-unknown
pointer_to_this chain >
full-name "BN_GENCB"
n_parents=0 use_template=0 interface-unknown
pointer_to_this chain >
testcase.i:5:15: internal compiler error: verify_type failed
0x10dd6617 verify_type(tree_node const*)
../../gcc/gcc/tree.c:13570
0x1067fc67 gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20685
0x10680887 gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20783
0x10681d97 gen_type_die
../../gcc/gcc/dwarf2out.c:20879
0x1067f3d3 gen_formal_types_die
../../gcc/gcc/dwarf2out.c:18225
0x1067f91b gen_subroutine_type_die
../../gcc/gcc/dwarf2out.c:20505
0x1068046f gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20812
0x10680887 gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20783
0x10681d97 gen_type_die
../../gcc/gcc/dwarf2out.c:20879
0x1067538f gen_decl_die
../../gcc/gcc/dwarf2out.c:21519
0x106786bb gen_member_die
../../gcc/gcc/dwarf2out.c:20356
0x106786bb gen_struct_or_union_type_die
../../gcc/gcc/dwarf2out.c:20461
0x106786bb gen_tagged_type_die
../../gcc/gcc/dwarf2out.c:20662
0x1068079f gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20824
0x10681d97 gen_type_die
../../gcc/gcc/dwarf2out.c:20879
0x10675b9b gen_decl_die
../../gcc/gcc/dwarf2out.c:21465
0x1067681f dwarf2out_decl
../../gcc/gcc/dwarf2out.c:21915
0x10676c77 dwarf2out_type_decl
../../gcc/gcc/dwarf2out.c:21625
0x1098065f rest_of_type_compilation(tree_node*, int)
../../gcc/gcc/passes.c:336
0x102c2223 finish_struct_1(tree_node*)
../../gcc/gcc/cp/class.c:6747
[Bug rtl-optimization/67201] New: PowerPC -mlra hits ICE: Max. number of generated reload insns per insn is achieved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67201
Bug ID: 67201
Summary: PowerPC -mlra hits ICE: Max. number of generated
reload insns per insn is achieved
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
I'm seeing an ICE on ppc64le when using -O1 -mlra:
# gcc -O1 -mlra testcase.i
testcase.i:31:1: internal compiler error: Max. number of generated reload insns
per insn is achieved (90)
}
^
0x1067d093 lra_constraints(bool)
../../gcc/gcc/lra-constraints.c:4345
0x10661c8b lra(_IO_FILE*)
../../gcc/gcc/lra.c:2300
0x1060286b do_reload
../../gcc/gcc/ira.c:5394
0x1060286b execute
../../gcc/gcc/ira.c:5565
# cat testcase.i
typedef struct {
} cGH;
typedef int (*reduction_fn_t) (cGH * GH, int proc, int num_dims, int from[],
int to[], int iterator[], int points_per_dim[],
int num_points, int num_inarrays, int intypes[],
void *inarrays[], int num_outvals,
double outvals[]);
static int copy_real_to_outtype(int num_elems, double inarray[], int outtype,
void *outarray);
int PUGH_ReductionGVs(cGH * GH, int proc, int num_invars, int invars[],
int outtype, int num_outvals, void *outvals,
reduction_fn_t reduction_fn)
{
int i, myproc, outtypesize, this_retval, retval;
double result;
for (i = 0; i < num_invars; i++) {
switch (CCTK_GroupTypeFromVarI(invars[i])) {
case 2:
case 3:
this_retval =
PUGH_ReductionGA(GH, invars[i], proc, &result,
reduction_fn);
}
if (this_retval == 0 && (proc < 0 || proc == myproc)) {
this_retval =
copy_real_to_outtype(1, &result, outtype,
(char *)outvals +
i * outtypesize);
}
}
}
static int copy_real_to_outtype(int num_elems, double inarray[], int outtype,
void *outarray)
{
int i, retval;
if (outtype == 1) {
long double *_outarray = (long double *)outarray;
for (i = 0; i < num_elems; i++) {
_outarray[i] = (long double)inarray[i];
}
}
}
[Bug rtl-optimization/67344] New: PowerPC unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67344
Bug ID: 67344
Summary: PowerPC unrecognizable insn
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
The following testcase:
# cat testcase.c
int a, b, c;
void fn2(void);
int fn1(char p1)
{
short d;
for (;;)
for (; c <= 3;) {
fn2();
d = p1 / 2;
b = d & 11 && a;
}
}
hits an ICE:
# gcc -O1 -c testcase.i
testcase2.i: In function ‘fn1’:
testcase2.i:13:1: error: unrecognizable insn:
}
^
(insn 74 4 75 2 (set (reg:DI 9 9)
(and:DI (lshiftrt:DI (reg:DI 3 3 [ p1 ])
(const_int 1 [0x1]))
(const_int 11 [0xb]))) testcase2.i:11 -1
(nil))
testcase2.i:13:1: internal compiler error: in extract_insn, at recog.c:2297
0x107923e3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:109
0x1079245f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:117
0x10755a87 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2297
0x10755b4f extract_insn_cached(rtx_insn*)
../../gcc/gcc/recog.c:2188
0x1049f37b cleanup_subreg_operands(rtx_insn*)
../../gcc/gcc/final.c:3112
0x10751dd7 split_insn
../../gcc/gcc/recog.c:2910
0x10758d77 split_all_insns()
../../gcc/gcc/recog.c:2964
0x10758eab rest_of_handle_split_after_reload
../../gcc/gcc/recog.c:3904
0x10758eab execute
../../gcc/gcc/recog.c:3933
[Bug rtl-optimization/67346] New: PowerPC: could not split insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67346
Bug ID: 67346
Summary: PowerPC: could not split insn
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
The following testcase:
# cat testcase.i
struct {
long f1;
} c;
int a, d, e;
volatile int b;
void fn2()
{
a = 3;
for (; a <= 8; a++) {
unsigned long *f = &c.f1;
e = 5 + 1;
*f |= d &= e;
b ? : b;
}
}
void fn1()
{
c.f1 = -2;
fn2();
}
hits an ICE:
# gcc -O3 testcase.i
testcase.i: In function ‘fn1’:
testcase.i:22:1: error: could not split insn
}
^
(insn 24 23 28 (set (reg:DI 6 6 [168])
(ior:DI (reg:DI 6 6 [196])
(const_int -2 [0xfffe]))) testcase.i:13 243
{*iordi_mask}
(nil))
testcase.i:22:1: internal compiler error: in final_scan_insn, at final.c:2995
0x107923e3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:109
0x104a3d6b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/gcc/final.c:2995
0x104a4267 final(rtx_insn*, _IO_FILE*, int)
../../gcc/gcc/final.c:2058
0x104a46d7 rest_of_handle_final
../../gcc/gcc/final.c:4449
0x104a46d7 execute
../../gcc/gcc/final.c:4524
[Bug target/67344] PowerPC unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67344 --- Comment #2 from Anton Blanchard --- I've been trying out csmith, then passing the failing tests through creduce. Even I do not write code like that :)
[Bug target/67356] New: PowerPC insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67356
Bug ID: 67356
Summary: PowerPC insn does not satisfy its constraints
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
The following testcase:
# cat testcase.i
int a, b, d, e;
static int *c = &a;
void fn1()
{
long f = 18446744073709551608UL;
b = 0;
for (; b <= 0; b++) {
long *g = &f;
e || (*c = (*g)++ | d);
}
}
Hits an ICE when built with -Os:
gcc -Os testcase.i
testcase.i: In function 'fn1':
testcase.i:11:1: error: insn does not satisfy its constraints:
}
^
(insn 94 93 30 3 (set (reg:SI 9 9 [173])
(ior:SI (and:SI (rotate:SI (reg:SI 8 8)
(const_int 3 [0x3]))
(const_int -8 [0xfff8]))
(and:SI (reg:SI 10 10 [orig:163 d ] [163])
(const_int 7 [0x7] testcase.i:9 235 {*rotlsi3_insert}
(expr_list:REG_DEAD (reg:SI 10 10 [orig:163 d ] [163])
(expr_list:REG_DEAD (reg:SI 8 8)
(nil
testcase.i:11:1: internal compiler error: in extract_constrain_insn, at
recog.c:2200
0x10795563 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:109
0x107955c7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:120
0x1075a397 extract_constrain_insn(rtx_insn*)
../../gcc/gcc/recog.c:2200
0x1075f58b copyprop_hardreg_forward_1
../../gcc/gcc/regcprop.c:778
0x107606ab execute
../../gcc/gcc/regcprop.c:1268
[Bug target/67378] New: PowerPC unrecognizable insn (ICE in in extract_insn, at recog.c:2297)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67378 Bug ID: 67378 Summary: PowerPC unrecognizable insn (ICE in in extract_insn, at recog.c:2297) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org Target Milestone: --- Created attachment 36262 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36262&action=edit Testcase csmith hit another ICE. This testcase is still quite complex even after reducing it unfortunately. # gcc -O3 -c testcase.i testcase4.i: In function 'f3': testcase4.i:23:1: error: unrecognizable insn: } ^ (insn 486 484 487 2 (set (mem/c:DI (plus:DI (reg/f:DI 1 1) (const_int 144 [0x90])) [7 %sfp+144 S8 A64]) (plus:DI (reg:DI 8 8) (const_int 18 [0x12]))) testcase4.i:19 -1 (nil)) testcase4.i:23:1: internal compiler error: in extract_insn, at recog.c:2297 0x107894b3 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc/gcc/rtl-error.c:109 0x10789517 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc/gcc/rtl-error.c:117 0x1074cde7 extract_insn(rtx_insn*) ../../gcc/gcc/recog.c:2297 0x1074ceaf extract_insn_cached(rtx_insn*) ../../gcc/gcc/recog.c:2188 0x104ad837 cleanup_subreg_operands(rtx_insn*) ../../gcc/gcc/final.c:3112 0x107862af reload(rtx_insn*, int) ../../gcc/gcc/reload1.c:1255 0x105fc99b do_reload ../../gcc/gcc/ira.c:5405 0x105fc99b execute ../../gcc/gcc/ira.c:5564
[Bug c/23197] New: Improve documentation on -fprofile-generate, -fprofile-use
I noticed -fprofile-generate and -fprofile-use dont have an up to date summary of the options they enable. Patch follows. -- Summary: Improve documentation on -fprofile-generate, -fprofile- use Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anton at samba dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23197
[Bug middle-end/23197] Improve documentation on -fprofile-generate, -fprofile-use
--- Additional Comments From anton at samba dot org 2005-08-02 14:25 --- Created an attachment (id=9411) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9411&action=view) Update profile option documentation Document all options that -fprofile-generate/-fprofile-usr select: -fprofile-generate selects -fspeculative-prefetching -fprofile-use selects -fprofile-values and -fspeculative-prefetching I noticed -fprofile-generate does select -funroll-loops but I dont know why it does (so didnt document it) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23197
[Bug middle-end/23197] Improve documentation on -fprofile-generate, -fprofile-use
--- Additional Comments From anton at samba dot org 2005-08-02 14:42 --- Created an attachment (id=9414) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9414&action=view) Updated patch As pinskia pointed out, -fspeculative-prefetching is not selected. -- What|Removed |Added Attachment #9411 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23197
[Bug c/23422] New: Sign extension removed even when inline assembly uses variable
When using the recent debian 4.0 build (gcc version 4.0.2 20050806 (prerelease)
(Debian 4.0.1-4)) I had some problems with a 64bit kernel.
A cut down test case is:
#define BUG_ON(x) asm volatile("tdnei %0,0" : : "r" (x));
static inline int bar(int val)
{
return val + 1;
}
int foo;
void baz()
{
BUG_ON(bar(foo));
}
gcc 3.4 sign extends before passing it to the inline assembly:
.baz:
ld 11,[EMAIL PROTECTED](2)
lwa 9,0(11)
addi 9,9,1
extsw 9,9
tdnei 9,0
But gcc 4.0 has removed the sign extension:
.baz:
ld 11,[EMAIL PROTECTED](2)
lwz 9,0(11)
addi 9,9,1
tdnei 9,0
gcc 4.0 does get it right with -fno-inline.
--
Summary: Sign extension removed even when inline assembly uses
variable
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23422
[Bug c/23422] Sign extension removed even when inline assembly uses variable
--- Additional Comments From anton at samba dot org 2005-08-17 01:04 --- Thanks, after applying the suggested fix the kernel works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23422
[Bug lto/42528] New: ICE with -flto and -fsigned-char
A gcc build from svn today (20091228) gets an ICE on the following code when
using -flto and -fsigned-char:
char *foo;
int main()
{
foo = "bar";
}
# /gcc-test/bin/gcc -flto -fsigned-char foo.c
In function 'main':
lto1: error: type mismatch in address expression
*
foo = &"bar"[0];
lto1: internal compiler error: verify_stmts failed
It passes with either option on its own.
--
Summary: ICE with -flto and -fsigned-char
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc64-linux-gnu-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42528
[Bug other/42530] New: ICE in verify_ssa when using -O -g -ffast-math -floop-parallelize-all
An svn build from 20091229 is getting an ICE when building the following code:
int array[2][2];
void foo(int *a)
{
int i, j;
int sum, tmp = 0;
for (i=0; i<2; i++)
for (j=0; j<2; j++)
sum += array[i][j];
if (sum > 0) {
tmp = sum;
*a = tmp;
}
}
# /test/bin/gcc -c -O -g -ffast-math -floop-parallelize-all test.c
test.c: In function foo:
test.c:3:6: error: missing definition
for SSA_NAME: sum_8 in statement:
# DEBUG tmp => sum_8
test.c:3:6: internal compiler error: verify_ssa failed
It seems all of "-O -g -ffast-math -floop-parallelize-all" needs to be
specified to make it fail.
--
Summary: ICE in verify_ssa when using -O -g -ffast-math -floop-
parallelize-all
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc64-linux-gnu-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42530
[Bug lto/42534] New: ICE with -flto when using __attribute__((__aligned__(X)))
I'm hitting an ICE on gcc svn from 20091229 when building the Linux kernel with
-flto. A cutdown test case:
struct zot
{
void *p;
int *padding;
} __attribute__((__aligned__(128)));
void foo(struct zot *buf)
{
int i;
for (i = 0; i < 4; i++)
buf->padding[i] = 0;
}
# gcc -m64 -O2 -flto -c -o test.o test.c
# gcc -m64 -O2 -flto -r -o test2.o test.o -nostdlib
In file included from :0:0:
test.c: In function 'foo':
test.c:7:6: 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.
lto-wrapper: /root/gcc-installed/bin/gcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status
--
Summary: ICE with -flto when using
__attribute__((__aligned__(X)))
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc64-linux-gnu-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42534
[Bug lto/42528] ICE with -flto and -fsigned-char
--- Comment #6 from anton at samba dot org 2010-01-07 11:01 --- Thanks Richard, it passes my tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42528
[Bug middle-end/45274] New: __restrict__ type qualifier does not work on pointers to bitfields
I tested an svn build from 20100813 with the following code:
struct bar {
unsigned int a:1, b:1, c:1, d:1, e:28;
};
void foo(struct bar * __restrict__ src, struct bar * __restrict__ dst)
{
dst->a = src->a;
dst->b = src->b;
dst->c = src->c;
dst->d = src->d;
dst->e = src->e;
}
Built as 32bit, we see loads and stores as if the compiler is following pointer
aliasing rules:
# gcc -m32 -O2 -S foo.c
foo:
lwz 9,0(3)
lwz 0,0(4)
rlwimi 0,9,0,0,0
stw 0,0(4)
lwz 9,0(3)
rlwimi 0,9,0,1,1
stw 0,0(4)
lwz 9,0(3)
rlwimi 0,9,0,2,2
stw 0,0(4)
lwz 9,0(3)
rlwimi 0,9,0,3,3
stw 0,0(4)
lwz 9,0(3)
rlwimi 0,9,0,4,31
stw 0,0(4)
blr
Apologies if I am misusing or misinterpreting the use of __restrict__ here.
Also, when built as 64bit things are considerably more complex. Is there a
reason why we can't use the same code as 32bit?
# gcc -m64 -O2 -S foo.c
...
.L.foo:
lwz 9,0(4)
lwz 0,0(3)
rlwinm 9,9,0,1,31
rlwinm 0,0,0,0,0
or 0,9,0
stw 0,0(4)
rlwinm 0,0,1,1,31
rlwinm 0,0,31,0x
lwz 9,0(3)
rldicl 9,9,34,63
slwi 9,9,30
or 0,0,9
stw 0,0(4)
rlwinm 9,0,2,1,31
rlwinm 9,9,30,0x
lwz 0,0(3)
rldicl 0,0,35,63
slwi 0,0,29
or 0,9,0
stw 0,0(4)
rlwinm 0,0,3,1,31
rlwinm 0,0,29,0x
lwz 9,0(3)
rldicl 9,9,36,63
slwi 9,9,28
or 0,0,9
stw 0,0(4)
rlwinm 0,0,0,0,3
lwz 9,0(3)
rlwinm 9,9,0,4,31
or 0,0,9
stw 0,0(4)
blr
--
Summary: __restrict__ type qualifier does not work on pointers to
bitfields
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45274
[Bug tree-optimization/49601] New: ICE at ipa-inline-analysis.c:1188
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49601
Summary: ICE at ipa-inline-analysis.c:1188
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: an...@samba.org
Target: powerpc64-linux-gnu-gnu
A recent powerpc64-linux build of gcc:
gcc version 4.7.0 20110630 (experimental) (GCC)
gets an ICE with the following testcase (originally from a kernel compile):
static inline __attribute__((always_inline)) void zot(unsigned a, unsigned b)
{
if (__builtin_constant_p(a > 4096 || b > 0))
asm volatile("":::"memory");
}
int foo(unsigned long a)
{
unsigned b = 4096 - a;
zot(a + b, 0);
return 1;
}
# gcc -O2 -c fs/buffer.i
fs/buffer.i:13:1: internal compiler error: tree check: expected ssa_name, have
integer_cst in set_cond_stmt_execution_predicate, at ipa-inline-analysis.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug tree-optimization/26026] New: power of 2 mod missing optimisation
gcc is using a divide and multiply where it could be using shift/ands:
unsigned long f1(unsigned long x, unsigned long n)
{
return x % (1UL << n);
}
produces:
f1:
li 9,1
slw 9,9,4
divwu 0,3,9
mullw 0,0,9
subf 3,0,3
blr
--
Summary: power of 2 mod missing optimisation
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26026
