[Bug middle-end/44300] Spurious array subscript warning, b[0] == a[1] is not folded
--- Comment #11 from segher at kernel dot crashing dot org 2010-05-29
00:34 ---
(In reply to comment #5)
Can you recommend an elegant way to rewrite this code to avoid the warning?
static inline void
foo(int *p)
{
if ((uintptr_t)p - (uintptr_t)(a + 1) sizeof a - sizeof a[0]) {
p[-1] = 0;
}
}
--
segher at kernel dot crashing dot org changed:
What|Removed |Added
CC||segher at kernel dot
||crashing dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
[Bug target/43892] PowerPC suboptimal add with carry optimization
--- Comment #14 from segher at kernel dot crashing dot org 2010-05-26 16:46 --- (In reply to comment #13) Please see -mcpu= . Almost forgot, but how do I specify that at gcc build/configure ? You can configure with --with-cpu= to set a default for -mcpu= . Also, I haven't seen any progress on this issue You have no patience, now do you? even though it sounded that the initial fix was easy(addmodecc expander) The fix will be a few thousand lines of patch. Literally. In order to fix this problem (and a whole host of way more important missed optimisation opportunities) we need to expose the CA bit to the compiler as an actual register. Currently, whenever GCC uses the carry bit it does so by having the consumer and producer in a canned asm sequence; this is suboptimal for many reasons. Fixing it properly will take a while. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math
--- Comment #7 from segher at kernel dot crashing dot org 2010-01-05 15:57 --- With -fno-signed-zeroes, a-b*c is transformed to -(b*c-a), which is a machine instruction. If the result would have been +0 before, it now is -0. The code then takes the sqrt() of that; sqrt(-0) is -0. This then is passed to atan2(), which has a discontinuity at 0, and we get wildly diverging results. The compiler does nothing wrong here; the transformation is perfectly valid. A solution might be to transform e.g. atan2(x,y) into atan2(+0.+x,+0.+y) when -fno-signed-zeroes is in effect (and of course somehow make sure those additions aren't optimised away). Similar for other math library functions with discontinuities at +/- 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42286
[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math
--- Comment #8 from segher at kernel dot crashing dot org 2010-01-05 16:00 --- (In reply to comment #6) IIRC the problem is that using fma causes the -0 argument for fsqrt (which behaves 100% correct). Thus a more sensible fix would be to do the 0+ on the fma result. But a -0 result from fsqrt() is no problem /an sich/; problems only show up when you pass a +/- 0 to a function with a discontinuity there. Also, doing an extra addition on every fma is hugely expensive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42286
[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math
--- Comment #10 from segher at kernel dot crashing dot org 2010-01-05 16:42 --- (In reply to comment #9) Right. Just it might be simpler with -fno-signed-zeros to transform a-b*c to 0 + -(b*c-a). a-b*c is two machine instructions; -(b*c-a) is one. Adding zero again makes it two, no good :-( Of course if the result was -0 before then it will be +0 after either variant (and the atan2 discontinuity would still happen even with your fix). Sure, it's not a fix, more a band-aid: it will produce more intuitive results when -fno-signed-zeroes is in effect, since atan2() does care about the sign of zero, and that compiler flag says we do not want that. Thus whatever fix the underlying problem is surely that calculix is not really -fno-signed-zeros safe. Yes, certainly. It seems to me this will happen with more sloppy code though, not just calculix. Can't we get lucky again as before by trying to recover the PRE code change? Well, the code change actually improved the generated code here, do we want to undo that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42286
[Bug debug/41893] New: ICE with -combine and debug
[From https://bugzilla.redhat.com/show_bug.cgi?id=531385 ]
Testcase:
cat file1.c EOF
struct s1_s {
int v;
};
struct s1_s g1;
void __attribute__((externally_visible)) func1() {
struct s1_s *l1 = g1;
}
EOF
cat file2.c EOF
extern struct s1_s g1;
void func2() {
g1;
}
EOF
cc -O -g -fwhole-program -combine -c file1.c file2.c
Caused by SVN r152403:
PR debug/41404
PR debug/41353
* cfgexpand.c (expand_debug_expr) case STRING_CST: Don't create
CONST_STRING if STRING_CST contains embedded '\0's or doesn't end with
'\0'.
(expand_debug_expr) case VAR_DECL: For TREE_STATIC !DECL_EXTERNAL
vars use DECL_RTL with resetting it back to NULL afterwards.
* dwarf2out.c (same_dw_val_p): For dw_val_class_addr compare with
rtx_equal_p instead of asserting it is a SYMBOL_REF.
(value_format): For dw_val_class_addr only use DW_FORM_addr if
the attribute type allows it, otherwise use DW_FORM_dataN.
(mem_loc_descriptor): Handle CONST_STRING.
(add_const_value_attribute): Handle CONST_STRING using add_AT_addr.
Handle MEM with CONST_STRING address using add_AT_string.
(rtl_for_decl_init): Return MEM with CONST_STRING address instead of
CONST_STRING for const arrays initialized with a string literal.
(resolve_one_addr, resolve_addr_in_expr, resolve_addr): New functions.
(dwarf2out_finish): Call resolve_addr.
* gcc.dg/guality/pr41404-1.c: New test.
* gcc.dg/guality/pr41353-2.c: New test.
--
Summary: ICE with -combine and debug
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: segher at kernel dot crashing dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41893
[Bug middle-end/41741] New: -Os generates bigger code than -O2 for simple loops
Take the following example:
void *memset(void *b, int c, unsigned long len)
{
unsigned long i;
for (i = 0; i len; i++)
((unsigned char *)b)[i] = c;
return b;
}
-O2 generates:
memset:
cmpwi 0,5,0
beqlr 0
mtctr 5
rlwinm 4,4,0,0xff
li 9,0
.p2align 4,,15
.L3:
stbx 4,3,9
addi 9,9,1
bdnz .L3
blr
but -Os does:
memset:
cmpwi 7,5,0
li 9,0
addi 5,5,1
bne+ 7,.L2
li 5,1
b .L2
.L3:
stbx 4,3,9
addi 9,9,1
.L2:
addic. 5,5,-1
bne 0,.L3
blr
which is much worse and bigger.
--
Summary: -Os generates bigger code than -O2 for simple loops
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: segher at kernel dot crashing dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41741
[Bug middle-end/41742] New: Unnecessary zero-extension at -O2 but not -O1
Take the following example:
void *memset(void *b, int c, unsigned long len)
{
unsigned long i;
for (i = 0; i len; i++)
((unsigned char *)b)[i] = c;
return b;
}
-O2 generates:
memset:
cmpwi 0,5,0
beqlr 0
mtctr 5
rlwinm 4,4,0,0xff
li 9,0
.p2align 4,,15
.L3:
stbx 4,3,9
addi 9,9,1
bdnz .L3
blr
The zero-extension of GPR4 isn't needed, and in fact, -O1 doesn't
generate it:
memset:
cmpwi 0,5,0
beqlr 0
li 9,0
subf 5,9,5
mtctr 5
.L3:
stbx 4,3,9
addi 9,9,1
bdnz .L3
blr
(the subf here is superfluous though).
--
Summary: Unnecessary zero-extension at -O2 but not -O1
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: segher at kernel dot crashing dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41742
[Bug middle-end/41743] New: Missing loop optimisation
Take the following example code:
void *memset(void *b, int c, unsigned long len)
{
unsigned long i;
for (i = 0; i len; i++)
((unsigned char *)b)[i] = c;
return b;
}
-O2 generates:
memset:
cmpwi 0,5,0
beqlr 0
mtctr 5
rlwinm 4,4,0,0xff
li 9,0
.p2align 4,,15
.L3:
stbx 4,3,9
addi 9,9,1
bdnz .L3
blr
The use of GPR9 is unnecessary, the loop could increment
GPR3 instead.
--
Summary: Missing loop optimisation
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: segher at kernel dot crashing dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41743
[Bug tree-optimization/39804] [4.5 Regression] internal compiler error: in propagate_necessity, at tree-ssa-dce.c:754
--- Comment #8 from segher at kernel dot crashing dot org 2009-04-19 19:39 --- Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr39804.c Hi hjl, Why backport a single testcase from trunk to 4.4? This bug never existed on 4.4, it's not terribly useful as far as I can see. Also, I didn't see this on gcc-patches. Segher -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39804
[Bug tree-optimization/39804] New: internal compiler error: in propagate_necessity, at tree-ssa-dce.c:754
i386-linux-gcc -O1 -S probe_roms_32.i /home/segher/src/kernel/arch/x86/kernel/probe_roms_32.c: In function 'romchecksum': /home/segher/src/kernel/arch/x86/kernel/probe_roms_32.c:165: internal compiler error: in propagate_necessity, at tree-ssa-dce.c:754 -- Summary: internal compiler error: in propagate_necessity, at tree-ssa-dce.c:754 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: segher at kernel dot crashing dot org GCC host triplet: x86_64-linux GCC target triplet: i386-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39804
[Bug tree-optimization/39804] internal compiler error: in propagate_necessity, at tree-ssa-dce.c:754
--- Comment #1 from segher at kernel dot crashing dot org 2009-04-18 09:53 --- Created an attachment (id=17653) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17653action=view) testcase, not minimised -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39804
[Bug middle-end/39765] New: internal compiler error: in copyprop_hardreg_forward_1
This is with 4.4.0-RC-20090414, with --enable-checking=yes,rtl,tree if that
matters.
$ cris-linux-gcc -O2 -S buffer.i
/home/segher/src/kernel/fs/buffer.c: In function 'block_page_mkwrite':
/home/segher/src/kernel/fs/buffer.c:2409: error: insn does not satisfy its
constraints:
(insn 146 52 147 7 /home/segher/src/kernel/fs/buffer.c:2391 (set (reg/v:SI 1 r1
[orig:30 end ] [30])
(zero_extend:SI (reg:HI 16 srp))) 58 {zero_extendhisi2} (nil))
/home/segher/src/kernel/fs/buffer.c:2409: internal compiler error: in
copyprop_hardreg_forward_1, at regrename.c:1603
It needs -O2 or -O3 to fail, -Os is not enough.
--
Summary: internal compiler error: in copyprop_hardreg_forward_1
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: segher at kernel dot crashing dot org
GCC host triplet: x86_64-linux
GCC target triplet: cris-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39765
[Bug middle-end/39765] internal compiler error: in copyprop_hardreg_forward_1
--- Comment #1 from segher at kernel dot crashing dot org 2009-04-14 15:30 --- Created an attachment (id=17634) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17634action=view) testcase, not minimised -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39765
[Bug debug/39766] New: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:12179
This is with 4.4.0-RC-20090414, with --enable-checking=yes,rtl,tree if that matters. $ h8300-elf-gcc -mh -mint32 -g -fomit-frame-pointer -S read_write.i /home/segher/src/kernel/fs/read_write.c: In function 'sys_pwrite64': /home/segher/src/kernel/fs/read_write.c:455: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:12179 It needs all those options to fail. -- Summary: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:12179 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: segher at kernel dot crashing dot org GCC host triplet: x86_64-linux GCC target triplet: h8300-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39766
[Bug debug/39766] internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:12179
--- Comment #1 from segher at kernel dot crashing dot org 2009-04-14 15:50 --- Created an attachment (id=17635) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17635action=view) testcase, not minimised -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39766
[Bug bootstrap/39767] New: libgcc2.c:562: internal compiler error: RTL check: expected code 'reg', have 'ashiftrt' in rhs_regno, at rtl.h:1005
/home/segher/barc1/sh64/gcc/./gcc/xgcc -B/home/segher/barc1/sh64/gcc/./gcc/ -B/n/17/segher/cross-4.4.0-rc1/sh64-linux/bin/ -B/n/17/segher/cross-4.4.0-rc1/sh64-linux/lib/ -isystem /n/17/segher/cross-4.4.0-rc1/sh64-linux/include -isystem /n/17/segher/cross-4.4.0-rc1/sh64-linux/sys-include -g -O2 -mb -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -fpic -DNO_FPSCR_VALUES -I. -I. -I../../.././gcc -I/n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc -I/n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/. -I/n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/../gcc -I/n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/../include -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/../gcc/libgcc2.c \ /n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/../gcc/libgcc2.c: In function '__muldi3': /n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/../gcc/libgcc2.c:562: internal compiler error: RTL check: expected code 'reg', have 'ashiftrt' in rhs_regno, at rtl.h:1005 configured with: $ /n/17/segher/src/gcc-4.4.0-RC-20090414/configure --target=sh64-linux \ --enable-targets=all --prefix=/n/17/segher/cross-4.4.0-rc1 \ --with-mpfr=/opt/cfarm/mpfr-2.4.1 --enable-languages=c --without-headers \ --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads \ --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp \ --disable-decimal-float --enable-checking=yes,rtl,tree -- Summary: libgcc2.c:562: internal compiler error: RTL check: expected code 'reg', have 'ashiftrt' in rhs_regno, at rtl.h:1005 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: segher at kernel dot crashing dot org GCC host triplet: x86_64-linux GCC target triplet: sh64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39767
[Bug target/39768] New: internal compiler error: RTL check: expected code 'const_int', have 'reg' in gen_rotlsi3, at config/bfin/bfin.md:1616
This is with 4.4.0-RC-20090414, with --enable-checking=yes,rtl,tree . $ bfin-uclinux-gcc -S random.i In file included from /home/segher/src/kernel/include/linux/kernel.h:16, from /home/segher/src/kernel/include/linux/sched.h:53, from /home/segher/src/kernel/include/linux/utsname.h:36, from /home/segher/src/kernel/drivers/char/random.c:227: /home/segher/src/kernel/include/linux/bitops.h: In function 'mix_pool_bytes_extract': /home/segher/src/kernel/include/linux/bitops.h:55: internal compiler error: RTL check: expected code 'const_int', have 'reg' in gen_rotlsi3, at config/bfin/bfin.md:1616 -- Summary: internal compiler error: RTL check: expected code 'const_int', have 'reg' in gen_rotlsi3, at config/bfin/bfin.md:1616 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: segher at kernel dot crashing dot org GCC host triplet: x86_64-linux GCC target triplet: bfin-uclinux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39768
[Bug target/39768] internal compiler error: RTL check: expected code 'const_int', have 'reg' in gen_rotlsi3, at config/bfin/bfin.md:1616
--- Comment #1 from segher at kernel dot crashing dot org 2009-04-14 16:15 --- Created an attachment (id=17636) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17636action=view) testcase, not minimised -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39768
[Bug middle-end/35307] Missing Simplication for div op
--- Comment #3 from segher at kernel dot crashing dot org 2008-02-26 16:16 --- Not equivalent in the presence of overflow. You mean defined overflow :). No, I mean overflow. Let's assume int is 16-bit (just to keep the numbers smallish); now take i=1, j=1000, k=1000. i/j/k is perfectly well-defined, but i/(j*k) overflows in the j*k computation. Segher -- segher at kernel dot crashing dot org changed: What|Removed |Added CC||segher at kernel dot ||crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35307
[Bug middle-end/35306] Missing expression simplication for conditional OR
--- Comment #1 from segher at kernel dot crashing dot org 2008-02-23 19:51
---
(In reply to comment #0)
The following rule is not handled by GCC
(a x) || (a y) === a (x | y)
Perhaps that is because those two expressions aren't equivalent?
But, confirmed, assuming you meant to say that
int bla(int a, int x, int y)
{
return (a x) || (a y);
}
isn't transformed to the equivalent of
int blabla(int a, int x, int y)
{
return !!(a (x | y));
}
This _is_ handled for constant x, y though.
Segher
--
segher at kernel dot crashing dot org changed:
What|Removed |Added
CC||segher at kernel dot
||crashing dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35306
[Bug middle-end/35307] Missing Simplication for div op
--- Comment #1 from segher at kernel dot crashing dot org 2008-02-23 19:57 --- Not equivalent in the presence of overflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35307
[Bug inline-asm/33600] New: Breakage caused by the fix to PR33552
The fix to PR33552 unfortunately breaks the Linux kernel build.
Reduced testcase attached, but hey, I'll put it inline as well:
int f(int n)
{
int x;
asm( : =c(n), =r(x) : 1(n), 0(n));
return n;
}
And the error is:
usercopy.i:5: error: 'asm' operand has impossible constraints
--
Summary: Breakage caused by the fix to PR33552
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: segher at kernel dot crashing dot org
GCC target triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33600
[Bug inline-asm/33600] Breakage caused by the fix to PR33552
--- Comment #1 from segher at kernel dot crashing dot org 2007-09-30 10:39 --- Created an attachment (id=14272) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14272action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33600
[Bug inline-asm/33600] [4.3 Regression] Breakage caused by the fix to PR33552
--- Comment #4 from segher at kernel dot crashing dot org 2007-09-30 14:07
---
The original code is: (arch/i386/lib/usercopy.c):
/* Generic arbitrary sized copy. */
#define __copy_user(to,from,size) \
do {\
int __d0, __d1, __d2; \
__asm__ __volatile__( \
cmp $7,%0\n \
jbe 1f\n \
movl %1,%0\n \
negl %0\n \
andl $7,%0\n \
subl %0,%3\n \
4: rep; movsb\n \
movl %3,%0\n \
shrl $2,%0\n \
andl $3,%3\n \
.align 2,0x90\n\
0: rep; movsl\n \
movl %3,%0\n \
1: rep; movsb\n \
2:\n \
.section .fixup,\ax\\n \
5: addl %3,%0\n \
jmp 2b\n \
3: lea 0(%3,%0,4),%0\n\
jmp 2b\n \
.previous\n \
.section __ex_table,\a\\n \
.align 4\n \
.long 4b,5b\n \
.long 0b,3b\n \
.long 1b,2b\n \
.previous \
: =c(size), =D (__d0), =S (__d1), =r(__d2) \
: 3(size), 0(size), 1(to), 2(from) \
: memory);\
} while (0)
--
segher at kernel dot crashing dot org changed:
What|Removed |Added
CC||segher at kernel dot
||crashing dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33600
[Bug target/33360] New: cris build failure
/home/segher/src/gcc/libgcc/../gcc/libgcc2.c:93: error: unrecognizable insn: (call_insn 26 25 27 7 /home/segher/src/gcc/libgcc/../gcc/libgcc2.c:90 (parallel [ (call (mem:QI (symbol_ref:SI (abort) [flags 0x41] function_decl 0x2b1aae353900 abort) [0 S1 A8]) (const_int 0 [0x0])) (clobber (reg:SI 16 srp)) ]) -1 (expr_list:REG_NORETURN (const_int 0 [0x0]) (expr_list:REG_EH_REGION (const_int 0 [0x0]) (nil))) (nil)) /home/segher/src/gcc/libgcc/../gcc/libgcc2.c:93: internal compiler error: in extract_insn, at recog.c 1990 configured as: /home/segher/src/gcc/configure --target=cris-linux --enable-targets=all --prefix=/home/segher/cross --enable-languages=c --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=yes,rtl -- Summary: cris build failure Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: segher at kernel dot crashing dot org GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: cris-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33360
[Bug target/33360] cris build failure
--- Comment #1 from segher at kernel dot crashing dot org 2007-09-08 23:06 --- SVN revision 128276 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33360
[Bug c/33102] volatile excessively suppresses optimizations in range checks
--- Comment #3 from segher at kernel dot crashing dot org 2007-08-18 00:12 --- (In reply to comment #1) volatile != atomic. And that is relevant why? Paul is perfectly aware of this, btw. There might be other reasons why GCC doesn't want to do this optimisation, but this isn't one of them. Please reopen, bugzilla won't allow me to do that myself. Segher -- segher at kernel dot crashing dot org changed: What|Removed |Added CC||segher at kernel dot ||crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug c/33102] volatile excessively suppresses optimizations in range checks
--- Comment #5 from segher at kernel dot crashing dot org 2007-08-18 00:31 --- It is still the same issue. *** This bug has been marked as a duplicate of 3506 *** It isn't the same issue. The submitter of #3506 claimed the code that GCC currently generates is incorrect, which obviously is not the case. _This_ PR on the other hand merely asks for GCC to be enhanced to generate _better_ code for this; a wholly different thing. So do not close as a duplicate again, thank you. Segher -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug c/33053] New: adopt accesses through a volatile-casted pointer as a GNU C extension
...with the semantics that such accesses should work as-if the underlying object had a volatile-qualified type. Some GCC users (notably the Linux kernel) already depend on this behaviour; however since GCC never actually supported it their expectations keep breaking (see for example PR21568, PR22278, PR29753). I am not requesting that GCC implement any other semantics that people expect from volatile; only that GCC treat int x; ... *(volatile int *)x ...; as if it read volatile int x; ... x ...; === Please consider, Segher -- Summary: adopt accesses through a volatile-casted pointer as a GNU C extension Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: segher at kernel dot crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053
[Bug middle-end/31490] Compile error section type conflict
--- Comment #10 from segher at kernel dot crashing dot org 2007-05-18 14:57 --- Created an attachment (id=13578) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13578action=view) proposed patch still need to run the testsuite on it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug middle-end/31490] Compile error section type conflict
--- Comment #8 from segher at kernel dot crashing dot org 2007-05-15 13:07 --- Bisecting shows that the original bug (powerpc64 Linux build errors out) is caused by r122781. I didn't actually test on 4.2 but the same patch is applied there (as r122782). If the reduced testcase in comment #2 fails on older compilers, it is likely a different bug (or an invalid testcase); if a bug, please file a separate PR for it. -- segher at kernel dot crashing dot org changed: What|Removed |Added CC||segher at kernel dot ||crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug inline-asm/29808] [4.2 Regression] Error: suffix or operands invalid for `mov' when optimization is enabled
--- Comment #1 from segher at kernel dot crashing dot org 2006-11-12 11:10 --- Not a bug in GCC but in your code; g says immediate values are allowed, while this asm insn only takes registers (or 16-bit memory). -- segher at kernel dot crashing dot org changed: What|Removed |Added CC||segher at kernel dot ||crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29808
[Bug inline-asm/29808] [4.2 Regression] Error: suffix or operands invalid for `mov' when optimization is enabled
--- Comment #4 from segher at kernel dot crashing dot org 2006-11-12 14:01 --- If the code is invalid, the fact that it compiles with -O0 is probably a bug... No, GCC cannot in general detect whether your asm code is buggy. The assembler however can detect many asm bugs, as it did in this case. The reason it worked with -O0 is that with -O0 you get different generated code (namely, very inefficient code). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29808
[Bug c/24010] [4.0/4.1/4.2 Regression] Duplicate C99 dot initializer warning missing
--- Comment #3 from segher at kernel dot crashing dot org 2006-09-03 20:39 --- The overwriting behaviour is required by 6.7.8/18 and 19. A warning is certainly in order; long ago, GCC used to warn, and bugs were caught because of that. Not anymore... I'll see if I can do a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24010
[Bug rtl-optimization/26549] pointer truncation in arch/powerpc/kernel/prom_init.c
--- Comment #1 from segher at kernel dot crashing dot org 2006-03-03 16:58 --- Confirmed, bug is in combine... looking into it... -- segher at kernel dot crashing dot org changed: What|Removed |Added CC||segher at kernel dot ||crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26549
[Bug rtl-optimization/26549] [3.4/4.0/4.1/4.2 Regression] pointer truncation in arch/powerpc/kernel/prom_init.c
--- Comment #4 from segher at kernel dot crashing dot org 2006-03-03 18:34 --- Not a bug at all, actually. GCC thinks it can mask out the lower few bits, because GPR1 should always be 16-byte aligned. And it isn't in your prom_init testing, and that's the bug. Better figure out how _that_ happened :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26549
[Bug preprocessor/23779] '-C' option produces wrong output
--- Comment #3 from segher at kernel dot crashing dot org 2005-10-26 11:44 --- The (first) carriage return issue is a separate bug, though. Please reopen? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23779
[Bug preprocessor/24024] [3.4/4.0/4.1 Regression] gcc -E -C processes \ incorrectly inside C comments
--- Additional Comments From segher at kernel dot crashing dot org 2005-09-27 16:19 --- Looks like the issue is that lex.c:save_comment() doesn't look at line_note's. An analogous issue happens with trigraphs. Btw, the C standard _does_ require escaped newlines and trigrpahs to be processed in comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24024
[Bug preprocessor/21250] [4.1 Regression] line number 0 for built-in causes GAS to complain
--- Additional Comments From segher at kernel dot crashing dot org 2005-04-28 15:08 --- The C standard has this to say about line numbers, in 6.10.4/2: The line number of the current source line is one greater than the number of new-line characters read or introduced in translation phase 1 (5.1.1.2) while processing the source file to the current token. So, a line number of 0 is impossible. GAS is correct to complain about this. It would be nice to be consistent, yes; but consistently right, please, not consistently wrong ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
[Bug preprocessor/21250] New: line number 0 for built-in causes GAS to complain
powerpc64-linux-gcc -c -o any-file.o any-file.S results in any-file.S: Assembler messages: any-file.S:1: Warning: line numbers must be positive; line number 0 rejected as the pre-processed file looks like # 1 any-file.S # 0 built-in # 1 command line # 1 any-file.S ... This regression is caused by http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02132.html -- Summary: line number 0 for built-in causes GAS to complain Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: segher at kernel dot crashing dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
[Bug target/20781] 64 bit shift by non-constant implemented as libcall on PPC32
--- Additional Comments From segher at kernel dot crashing dot org 2005-04-07 23:34 --- Subject: Re: New: 64 bit shift by non-constant implemented as libcall on PPC32 (O5 will give slightly better code for both, but let's start somewhere :P) Well the code for the left shift can be replaced with subfic r6,r5,32 addir7,r5,-32 slw r3,r3,r5 srw r6,r4,r6 slw r7,r4,r7 slw r4,r4,r5 or r5,r6,r7 or r3,r3,r5 and similar for the right shift (and also for signed shift counts), as shift counts 0 and = 64 are undefined here in C. If you want to verify this, do take care with count == 32, as it's special; but you can also just look in Book I appendix C.1 and trust that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20781
[Bug c/20709] strict aliasing warning with float pointer pointing to int pointer
--- Additional Comments From segher at kernel dot crashing dot org
2005-04-05 23:32 ---
Subject: Re: strict aliasing warning with float pointer pointing to int pointer
Aka this is valid and defined (even though we warn):
float a(float b)
{
int i;
*(float*)i = b;
return *(float*)i;
}
Here, you access the object 'i' of type int, as an object of type
float. This is not allowed; see 6.5/7.
Perhaps you meant something like:
int a;
float *f(void)
{
return (float *)a;
}
int g(void)
{
return *(int *)f();
}
which is fine, but we indeed warn.
Note it doesn't matter for the validity of this code that float
fits in the same object as int; it is important that float * can
represent the address of an int, though (6.3.2.3/7).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20709
[Bug other/19082] [4.0 Regression] build/genattrtab: out of memory allocating 151568 bytes after a total of 4161651196 bytes
-- What|Removed |Added CC||segher at kernel dot ||crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19082
[Bug rtl-optimization/19055] Minor bit optimization with or and xor
-- What|Removed |Added CC||segher at kernel dot ||crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19055
