[Bug c/33096] New: Internal compiler error with register global variables

2007-08-17 Thread slava at factorcode dot org
Compile the following program with -O3 on FreeBSD or Linux, x86:

///

#include 
#include 

register long foo asm("esi");
register long bar asm("edi");

char * crash_me_baby(char *str) {
char *path = malloc(1024 + strlen(str));
return path;
}

///

This results in an error like the following:

test.c:10: error: unable to find a register to spill in class 'DIREG'
test.c:10: error: this is the insn:
(insn:HI 16 83 17 2 (parallel [
(set (reg:SI 2 cx [66])
(unspec:SI [
(mem:BLK (reg/v/f:SI 63 [ suffix ]) [0 A8])
(reg:QI 0 ax [70])
(const_int 1 [0x1])
(reg:SI 2 cx [69])
] 20))
(use (reg:SI 19 dirflag))
(clobber (reg/f:SI 68 [ suffix ]))
(clobber (reg:CC 17 flags))
]) 530 {*strlenqi_1} (insn_list:REG_DEP_TRUE 6 (insn_list:REG_DEP_TRUE
12 (insn_list:REG_DEP_TRUE 14 (insn_list:REG_DEP_TRUE 15 (nil)
(expr_list:REG_DEAD (reg:SI 19 dirflag)
(expr_list:REG_DEAD (reg:SI 2 cx [69])
(expr_list:REG_DEAD (reg:QI 0 ax [70])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg/f:SI 68 [ suffix ])
(expr_list:REG_EQUAL (unspec:SI [
(mem:BLK (reg/v/f:SI 63 [ suffix ]) [0 A8])
(reg:QI 0 ax [70])
(const_int 1 [0x1])
(reg:SI 2 cx [69])
] 20)
(nil


-- 
   Summary: Internal compiler error with register global variables
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: slava at factorcode dot org
 GCC build triplet: i386-unknown-freebsd6.2
  GCC host triplet: i386-unknown-freebsd6.2
GCC target triplet: i386-unknown-freebsd6.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33096



[Bug c/33096] Internal compiler error with register global variables

2007-08-17 Thread slava at factorcode dot org


--- Comment #1 from slava at factorcode dot org  2007-08-17 07:56 ---
Created an attachment (id=14068)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14068&action=view)
Test case

This is a test case for the bug. Compile with -O1, -O2 or -O3 to trigger it.

With -O0, it compiles fine.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33096



[Bug c/36753] New: Forward propagation interacts badly with global register variable

2008-07-07 Thread slava at factorcode dot org
The attached test case is supposed to print '31337' when run.

Correct output:

[EMAIL PROTECTED] factor]$ gcc -O1 testcase.c
[EMAIL PROTECTED] factor]$ ./a.out
31337

Correct output:

[EMAIL PROTECTED] factor]$ gcc -O2 -fno-forward-propagate testcase.c
[EMAIL PROTECTED] factor]$ ./a.out
31337

*Incorrect* output:

[EMAIL PROTECTED] factor]$ gcc -O2 testcase.c
[EMAIL PROTECTED] factor]$ ./a.out
0

We can plainly see the problem in the disassemble for the broken() function.
With -O2 -fno-forward-propagate,

broken:
leaq8(%r14), %rax
movq%rax, %r14
movq$31337, (%rax)
ret

With -O2:

broken:
addq$8, %r14
movq$31337, 8(%r14)
ret

===
#include 
#include 

register unsigned long *ds asm("r14");

__attribute__((noinline)) void broken(bool value)
{
*++ds = 31337;
}

int main()
{
unsigned long stack[2];
stack[0] = 0;
stack[1] = 0;
ds = stack;
broken(true);
printf("%ld\n",*ds);
}
===


-- 
   Summary: Forward propagation interacts badly with global register
variable
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: slava at factorcode dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36753



[Bug middle-end/36753] [4.3/4.4 Regression] Forward propagation interacts badly with global register variable

2008-07-07 Thread slava at factorcode dot org


--- Comment #3 from slava at factorcode dot org  2008-07-07 22:41 ---
So is this extension bad/deprecated or not? I'd appreciate a clarification from
the gcc team. If the resolution is that this feature should simply not be used,
I would strongly suggest removing it. Otherwise I'm not sure what to think; do
I invest the effort in refactoring my code to not rely on this extension, or
can I count on it being supported going forward?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36753