[Bug c/35427] New: pointer subtraction in very big array

2008-03-03 Thread akr at m17n dot org 
I found that an result of pointer subtraction in a big array is negative when
it is expected to be positive.

% cat t.i
typedef int ptrdiff_t;
typedef unsigned int size_t;
extern void *malloc (size_t __size) __attribute__ ((__malloc__));
extern void exit (int __status) __attribute__ ((__noreturn__));
extern int printf (__const char *__restrict __format, ...);
extern void perror (__const char *__s);

int main(int argc, char **argv)
{
  long *p, *q;
  int nelem;
  ptrdiff_t s;

  printf(sizeof(long) = %d\n, sizeof(long));
  printf(sizeof(size_t) = %d\n, sizeof(size_t));
  printf(sizeof(ptrdiff_t) = %d\n, sizeof(ptrdiff_t));

  nelem = 513 * 1024 * 1024;
  printf(nelem: %d\n, nelem);

  q = malloc(sizeof(long) * nelem);
  if (!q) { perror(malloc); exit(1); }

  p = q + (nelem-1);
  s = p - q;
  printf(result: %d\n, s);

  return 0;
}
% bin/gcc -Wall t.i
% ./a.out 
sizeof(long) = 4
sizeof(size_t) = 4
sizeof(ptrdiff_t) = 4
nelem: 537919488
result: -535822337
% uname -srv
Linux 2.6.23.12 #3 SMP PREEMPT Thu Dec 27 21:28:19 JST 2007

This program allocates a big array, 513  * 1024 * 1024 elements of longs.

After that, the program subtracts the pointer to the first element from the
last element.

Then the subtraction from the pointer to one after the last element by the
pointer to the first element.
It's result should be 513 * 1024 * 1024 - 1. 
But -535822337 is printed.

Note that the expected result is representable in int because it is counted as
number of longs, not chars.


-- 
   Summary: pointer subtraction in very big array
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akr at m17n dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/35427] pointer subtraction in very big array

2008-03-03 Thread akr at m17n dot org 


--- Comment #2 from akr at m17n dot org  2008-03-03 23:45 ---
(In reply to comment #1)
 nelem*sizeof(long)
 
 Wraps so what do you expect?  This is the correct behavior really.

Oops.  It wrapped.

But changing the type of nelem to size_t doesn't change the situation.

nelem * sizeof(long)  2**32, so it doesn't wraps size_t.

Anyway malloc's argument is size_t.
So we can pass a size bigger than 2**31 bytes and malloc can allocates it.


-- 


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

[Bug c/35427] pointer subtraction in very big array

2008-03-03 Thread akr at m17n dot org 


--- Comment #4 from akr at m17n dot org  2008-03-04 00:17 ---
The result can be representable by ptrdiff_t
because the result is number of longs.

The array is bit larger than 2**31 bytes.
So the result is bit larger than 2**29.
It is representable in signed.


-- 


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

[Bug target/31907] isnan builtin doesn't work

2007-11-22 Thread akr at m17n dot org 


--- Comment #1 from akr at m17n dot org  2007-11-23 07:52 ---
(In reply to comment #0)
 isnan(0.0/0.0) returns false.
 It returns true if -fno-builtin.

I found it is a problem of FPU emulation in Linux kernel.

The problem is caused by FASTFPE.
NWFPE doesn't have the problem.


-- 

akr at m17n dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/33663] New: local register variable and memcmp

2007-10-04 Thread akr at m17n dot org 
I found unable to find a register to spill in class 'SIREG' error by
following example.

% cat tst.c
void fun(void)
{
  register int val1 asm(esi);
  int val2;

  if (val2) {
val2 = memcmp((void*)1, (void*)2, 3);
  }
  baz(val1, val2);
}

% gcc -v -O2 -c tst.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.1/configure --prefix=/home/src/gcc/gcc-4.2.1
--enable-languages=c
Thread model: posix
gcc version 4.2.1
 /home/src/gcc/gcc-4.2.1/libexec/gcc/i686-pc-linux-gnu/4.2.1/cc1 -quiet -v
tst.c -quiet -dumpbase tst.c -mtune=generic -auxbase tst -O2 -version -o
/tmp/cctXZKrk.s
ignoring nonexistent directory
/home/src/gcc/gcc-4.2.1/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 /usr/local/include
 /home/src/gcc/gcc-4.2.1/include
 /home/src/gcc/gcc-4.2.1/lib/gcc/i686-pc-linux-gnu/4.2.1/include
 /usr/include
End of search list.
GNU C version 4.2.1 (i686-pc-linux-gnu)
compiled by GNU C version 4.2.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 192e817f7ff889e169228e9a0338c840
tst.c: In function 'fun':
tst.c:10: error: unable to find a register to spill in class 'SIREG'
tst.c:10: error: this is the insn:
(insn:HI 21 20 22 3 (parallel [
(set (reg:CC 17 flags)
(compare:CC (mem:BLK (reg/f:SI 0 ax [62]) [0 S3 A8])
(mem:BLK (reg/f:SI 5 di [63]) [0 S3 A8])))
(use (reg:SI 2 cx [64]))
(use (const_int 1 [0x1]))
(use (reg:SI 19 dirflag))
(clobber (reg/f:SI 0 ax [62]))
(clobber (reg/f:SI 5 di [63]))
(clobber (reg:SI 2 cx [64]))
]) 528 {*cmpstrnqi_nz_1} (insn_list:REG_DEP_TRUE 17
(insn_list:REG_DEP_TRUE 18 (insn_list:REG_DEP_TRUE 19 (insn_list:REG_DEP_TRUE
20 (nil)
(expr_list:REG_DEAD (reg:SI 19 dirflag)
(expr_list:REG_DEAD (reg:SI 2 cx [64])
(expr_list:REG_DEAD (reg/f:SI 0 ax [62])
(expr_list:REG_DEAD (reg/f:SI 5 di [63])
(expr_list:REG_UNUSED (reg:SI 2 cx [64])
(expr_list:REG_UNUSED (reg/f:SI 5 di [63])
(expr_list:REG_UNUSED (reg/f:SI 0 ax [62])
(expr_list:REG_EQUAL (compare:CC (mem:BLK
(const_int 1 [0x1]) [0 S3 A8])
(mem:BLK (const_int 2 [0x2]) [0 S3
A8]))
(nil))
tst.c:10: confused by earlier errors, bailing out


-- 
   Summary: local register variable and memcmp
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akr at m17n dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/31907] New: isnan builtin doesn't work

2007-05-12 Thread akr at m17n dot org 
isnan(0.0/0.0) returns false.
It returns true if -fno-builtin.

KUROBOX-PRO(22:33:53)% cat tst.c 
extern void abort(void);
extern int isnan(double v);

int main()
{
  if (!isnan(0.0/0.0))
abort();
  return 0;
}
KUROBOX-PRO(22:34:02)% ~/src/gcc/bin/gcc -v tst.c  
Using built-in specs.
Target: armv5tejl-unknown-linux-gnu
Configured with: ../gcc-4.1.2/configure --prefix=/home/akr/src/gcc
--enable-languages=c
Thread model: posix
gcc version 4.1.2
 /home/akr/src/gcc/libexec/gcc/armv5tejl-unknown-linux-gnu/4.1.2/cc1 -quiet -v
tst.c -quiet -dumpbase tst.c -auxbase tst -version -o /tmp/ccBo6vhT.s
ignoring nonexistent directory
/home/akr/src/gcc/lib/gcc/armv5tejl-unknown-linux-gnu/4.1.2/../../../../armv5tejl-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 /usr/local/include
 /home/akr/src/gcc/include
 /home/akr/src/gcc/lib/gcc/armv5tejl-unknown-linux-gnu/4.1.2/include
 /usr/include
End of search list.
GNU C version 4.1.2 (armv5tejl-unknown-linux-gnu)
compiled by GNU C version 4.1.2.
GGC heuristics: --param ggc-min-expand=38 --param ggc-min-heapsize=15791
Compiler executable checksum: 332d6ae8f800e7865f327fc747ec5bd6
 as -o /tmp/cc8FEJCO.o /tmp/ccBo6vhT.s
 /home/akr/src/gcc/libexec/gcc/armv5tejl-unknown-linux-gnu/4.1.2/collect2
--eh-frame-hdr -dynamic-linker /lib/ld-linux.so.2 -X -m armelf_linux -p
/usr/lib/crt1.o /usr/lib/crti.o
/home/akr/src/gcc/lib/gcc/armv5tejl-unknown-linux-gnu/4.1.2/crtbegin.o
-L/home/akr/src/gcc/lib/gcc/armv5tejl-unknown-linux-gnu/4.1.2
-L/home/akr/src/gcc/lib/gcc/armv5tejl-unknown-linux-gnu/4.1.2/../../..
/tmp/cc8FEJCO.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed
/home/akr/src/gcc/lib/gcc/armv5tejl-unknown-linux-gnu/4.1.2/crtend.o
/usr/lib/crtn.o
KUROBOX-PRO(22:34:09)% ./a.out 
zsh: abort  ./a.out

It doesn't abort if -fno-builtin is used.

KUROBOX-PRO(22:34:18)% ~/src/gcc/bin/gcc -fno-builtin tst.c
KUROBOX-PRO(22:34:22)% ./a.out


-- 
   Summary: isnan builtin doesn't work
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akr at m17n dot org
 GCC build triplet: armv5tejl-unknown-linux-gnu
  GCC host triplet: armv5tejl-unknown-linux-gnu
GCC target triplet: armv5tejl-unknown-linux-gnu


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

[Bug target/28197] longjmp and alloca cause bus error at -O0

2007-05-06 Thread akr at m17n dot org 


--- Comment #4 from akr at m17n dot org  2007-05-07 06:56 ---
I think the problem can be fixed by alloca or setjmp.

* alloca extends a stack as the old stack backchain will not crashed, or
* setjmp saves the stack backchain and longjmp restore it.

I'm not sure that which should be done.


-- 


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

[Bug c/28197] New: longjmp and alloca cause bus error

2006-06-28 Thread akr at m17n dot org 
I got a bus error by following program which use longjmp and __builtin_alloca
with -O0.

% cat z.c
#include setjmp.h

jmp_buf env;

void f(int a1, int a2, int a3, int a4, int a5, int a6, int a7, int a8)
{
  longjmp(env, 1);
}

int main()
{
  if (setjmp(env) == 0) {
void *p = __builtin_alloca(4);
f(1,2,3,4,5,6,7,8);
  }
  return 0;
}
% ~/src/gcc/bin/gcc -E z.c  z.i
% cat z.i   
# 1 z.c
# 1 built-in
# 1 command line
# 1 z.c
# 1 /usr/include/setjmp.h 1 3 4
# 26 /usr/include/setjmp.h 3 4
# 1 /usr/include/machine/setjmp.h 1 3 4
# 29 /usr/include/machine/setjmp.h 3 4
# 1 /usr/include/ppc/setjmp.h 1 3 4
# 31 /usr/include/ppc/setjmp.h 3 4
# 1 /usr/include/sys/cdefs.h 1 3 4
# 32 /usr/include/ppc/setjmp.h 2 3 4
# 1 /usr/include/machine/signal.h 1 3 4
# 27 /usr/include/machine/signal.h 3 4
# 1 /usr/include/ppc/signal.h 1 3 4
# 29 /usr/include/ppc/signal.h 3 4
# 1 /usr/include/sys/appleapiopts.h 1 3 4
# 30 /usr/include/ppc/signal.h 2 3 4


typedef int sig_atomic_t;
# 50 /usr/include/ppc/signal.h 3 4
typedef enum {
 REGS_SAVED_NONE,
 REGS_SAVED_CALLER,


 REGS_SAVED_ALL
} regs_saved_t;
# 66 /usr/include/ppc/signal.h 3 4
struct sigcontext32 {
int sc_onstack;
int sc_mask;
int sc_ir;
int sc_psw;
int sc_sp;
void *sc_regs;
};

struct sigcontext64 {
int sc_onstack;
int sc_mask;
long long sc_ir;
long long sc_psw;
long long sc_sp;
void *sc_regs;
};





struct sigcontext {
int sc_onstack;
int sc_mask;
int sc_ir;
int sc_psw;
int sc_sp;
void *sc_regs;
};
# 28 /usr/include/machine/signal.h 2 3 4
# 33 /usr/include/ppc/setjmp.h 2 3 4

struct _jmp_buf {
 struct sigcontext sigcontext;
 unsigned int vmask __attribute__((aligned(8)));
 unsigned int vreg[32 * 4] __attribute__((aligned(16)));

};
# 82 /usr/include/ppc/setjmp.h 3 4
typedef int jmp_buf[(26 + 18*2 + 129 + 1)];
typedef int sigjmp_buf[(26 + 18*2 + 129 + 1) + 1];



extern int setjmp(jmp_buf env);
extern void longjmp(jmp_buf env, int val);


int _setjmp(jmp_buf env);
void _longjmp(jmp_buf, int val);
int sigsetjmp(sigjmp_buf env, int val);
void siglongjmp(sigjmp_buf env, int val);



void longjmperror(void);


# 30 /usr/include/machine/setjmp.h 2 3 4
# 27 /usr/include/setjmp.h 2 3 4
# 2 z.c 2

jmp_buf env;

void f(int a1, int a2, int a3, int a4, int a5, int a6, int a7, int a8)
{
  longjmp(env, 1);
}

int main()
{
  if (setjmp(env) == 0) {
void *p = __builtin_alloca(4);
f(1,2,3,4,5,6,7,8);
  }
  return 0;
}
% ~/src/gcc/bin/gcc -O0 -g -v z.i
Using built-in specs.
Target: powerpc-apple-darwin8.6.0
Configured with: ../gcc-4.1.1/configure --prefix=/Users/akr/src/gcc
--enable-languages=c --with-as=/Users/akr/src/odcctools/bin/as
--with-ld=/Users/akr/src/odcctools/bin/ld
Thread model: posix
gcc version 4.1.1
 /Users/akr/src/gcc/libexec/gcc/powerpc-apple-darwin8.6.0/4.1.1/cc1
-fpreprocessed z.i -feliminate-unused-debug-symbols -fPIC -quiet -dumpbase z.i
-auxbase z -g -O0 -version -o /var/tmp//ccD20CPP.s
GNU C version 4.1.1 (powerpc-apple-darwin8.6.0)
compiled by GNU C version 4.1.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 060081fe4c432c1f8e1af4cf790a4da4
 /Users/akr/src/odcctools/bin/as -arch ppc -o /var/tmp//cck0sLjz.o
/var/tmp//ccD20CPP.s
 /Users/akr/src/gcc/libexec/gcc/powerpc-apple-darwin8.6.0/4.1.1/collect2
-dynamic -arch ppc -weak_reference_mismatches non-weak -o a.out -lcrt1.o
/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1/crt2.o
-L/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1
-L/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1/../../..
/var/tmp//cck0sLjz.o -lgcc -lSystemStubs -lSystem
% ./a.out 
zsh: bus error  ./a.out
% uname -a
Darwin ppc64.tky.aist.go.jp 8.6.0 Darwin Kernel Version 8.6.0: Tue Mar  7
16:58:48 PST 2006; root:xnu-792.6.70.obj~1/RELEASE_PPC Power Macintosh powerpc


-- 
   Summary: longjmp and alloca cause bus error
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akr at m17n dot org
 GCC build triplet: powerpc-apple-darwin8.6.0
  GCC host triplet: powerpc-apple-darwin8.6.0
GCC target triplet: powerpc-apple-darwin8.6.0


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

[Bug target/28197] longjmp and alloca cause bus error at -O0

2006-06-28 Thread akr at m17n dot org 


--- Comment #1 from akr at m17n dot org  2006-06-29 01:49 ---
I found a way to reproduce the bus error with -O2 as well as -O0.

% cat z.c
#include setjmp.h

jmp_buf env;
int i;

int main()
{
  if (setjmp(env) == 0) {
char *p = __builtin_alloca(1024);
for (i = 0; i  1024; i++) {
  p[i] = 0;
}
longjmp(env, 1);
  }
  return 0;
}
Z:[EMAIL PROTECTED] ~/src/gcc/bin/gcc -O2 -v z.c
Using built-in specs.
Target: powerpc-apple-darwin8.6.0
Configured with: ../gcc-4.1.1/configure --prefix=/Users/akr/src/gcc
--enable-languages=c --with-as=/Users/akr/src/odcctools/bin/as
--with-ld=/Users/akr/src/odcctools/bin/ld
Thread model: posix
gcc version 4.1.1
 /Users/akr/src/gcc/libexec/gcc/powerpc-apple-darwin8.6.0/4.1.1/cc1 -quiet -v
-D__DYNAMIC__ z.c -fPIC -quiet -dumpbase z.c -auxbase z -O2 -version -o
/var/tmp//ccCHTcUf.s
ignoring nonexistent directory
/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1/../../../../powerpc-apple-darwin8.6.0/include
#include ... search starts here:
#include ... search starts here:
 /usr/local/include
 /Users/akr/src/gcc/include
 /Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1/include
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
GNU C version 4.1.1 (powerpc-apple-darwin8.6.0)
compiled by GNU C version 4.1.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 060081fe4c432c1f8e1af4cf790a4da4
 /Users/akr/src/odcctools/bin/as -arch ppc -o /var/tmp//ccsOCM5w.o
/var/tmp//ccCHTcUf.s
 /Users/akr/src/gcc/libexec/gcc/powerpc-apple-darwin8.6.0/4.1.1/collect2
-dynamic -arch ppc -weak_reference_mismatches non-weak -o a.out -lcrt1.o
/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1/crt2.o
-L/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1
-L/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1/../../..
/var/tmp//ccsOCM5w.o -lgcc -lSystemStubs -lSystem
% ./a.out 
zsh: bus error  ./a.out
% ~/src/gcc/bin/gcc -O0 z.c   
% ./a.out 
zsh: bus error  ./a.out


-- 


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

[Bug c/22429] New: -1073741824 = n n = 1073741823 is true where n is 1073741824

2005-07-12 Thread akr at m17n dot org 
I found that following program exits with 1 instead of 0.

% cat z.c
int f(int n)
{
  if (-1073741824 = n  n = 1073741823)
return 1;
  return 0;
}

int main()
{
  return f(1073741824);
}
% /home/src/chkbuild-tmp/build/gcc-trunk/20050712T134449/bin/gcc -v -O  z.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../gcc/configure
--prefix=/home/akr/ruby/chkbuild/tmp/build/gcc-trunk/20050712T134449
--enable-languages=c
Thread model: posix
gcc version 4.1.0 20050712 (experimental)
 
/home/src/chkbuild-tmp/build/gcc-trunk/20050712T134449/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1
-quiet -v -iprefix
/home/src/chkbuild-tmp/build/gcc-trunk/20050712T134449/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0/
z.c -quiet -dumpbase z.c -mtune=pentiumpro -auxbase z -O -version -o 
/tmp/cc3anyqv.s
ignoring nonexistent directory
/home/src/chkbuild-tmp/build/gcc-trunk/20050712T134449/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include
ignoring duplicate directory
/home/akr/ruby/chkbuild/tmp/build/gcc-trunk/20050712T134449/lib/gcc/i686-pc-linux-gnu/4.1.0/include
ignoring nonexistent directory
/home/akr/ruby/chkbuild/tmp/build/gcc-trunk/20050712T134449/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 
/home/src/chkbuild-tmp/build/gcc-trunk/20050712T134449/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0/include
 /usr/local/include
 /home/akr/ruby/chkbuild/tmp/build/gcc-trunk/20050712T134449/include
 /usr/include
End of search list.
GNU C version 4.1.0 20050712 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20050712 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: cab36206423b633931a3bd43d355747c
 as -V -Qy -o /tmp/ccUCeuxU.o /tmp/cc3anyqv.s
GNU assembler version 2.15 (i386-linux) using BFD version 2.15
 
/home/src/chkbuild-tmp/build/gcc-trunk/20050712T134449/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.0/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o
/usr/lib/crti.o
/home/src/chkbuild-tmp/build/gcc-trunk/20050712T134449/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0/crtbegin.o
-L/home/src/chkbuild-tmp/build/gcc-trunk/20050712T134449/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0
-L/home/src/chkbuild-tmp/build/gcc-trunk/20050712T134449/bin/../lib/gcc
-L/home/akr/ruby/chkbuild/tmp/build/gcc-trunk/20050712T134449/lib/gcc/i686-pc-linux-gnu/4.1.0
-L/home/src/chkbuild-tmp/build/gcc-trunk/20050712T134449/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0/../../..
-L/home/akr/ruby/chkbuild/tmp/build/gcc-trunk/20050712T134449/lib/gcc/i686-pc-linux-gnu/4.1.0/../../..
/tmp/ccUCeuxU.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed
/home/src/chkbuild-tmp/build/gcc-trunk/20050712T134449/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0/crtend.o
/usr/lib/crtn.o
% ./a.out   
zsh: exit 1 ./a.out

It exists with 0 if optimization is disabled.

% /home/src/chkbuild-tmp/build/gcc-trunk/20050712T134449/bin/gcc z.c
% ./a.out

-- 
   Summary: -1073741824 = n  n = 1073741823 is true where n is
1073741824
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akr at m17n dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu


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

[Bug middle-end/21957] IA-64 register stack is not preserved after getcontext call

2005-06-28 Thread akr at m17n dot org 

--- Additional Comments From akr at m17n dot org  2005-06-29 03:50 ---
I think getcontext should return twice because getcontext is similar to setjmp.

First, getcontext returns from usual function call.
Second, getcontext returns from setcontext.

-- 


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

[Bug c/22127] New: SPARC register window is not preserved after getcontext call

2005-06-20 Thread akr at m17n dot org 
.
| first flag=0
| 
| Breakpoint 2, g () at tst.i:85
| 85ret = flag;
| 1: x/i $pc  0x10904 g+24: ld  [ %l0 + 0x228 ], %i0
| (gdb) p $l0
| $3 = 135168
| (gdb) x $l0 + 0x228
| 0x21228:0x

%l0 is changed to 135168 after second return from getcontext.
It is intended to reference flag but actually reference other address.
The address accessed is 135168 + 0x228 which value is zero.

| (gdb) x 134144 + 0x228
| 0x20e28 flag: 0x0001

The value of flag is one.

| (gdb) p $i0
| $4 = 0
| (gdb) si
| 86if (ret == 0) {
| 1: x/i $pc  0x10908 g+28: cmp  %i0, 0
| (gdb) p $i0
| $5 = 0
| (gdb) 

The condition doesn't work as intended because the compared value is different
from flag.

I think this is similar to GCC Bug 21957.

Note that the source program is follows.

| % cat tst.c 
| #include stdlib.h
| #include stdio.h
| #include ucontext.h
| 
| int flag;
| ucontext_t cont;
| int pad[100];
| typedef void (*fun_t)(int);
| fun_t p0,p1,p2,p3,p4,p5,p6,p7,p8,p9,p10,p11,p12;
| 
| void h(int v)
| {
|   printf(%d\n, v);
| }
| 
| void f(void)
| {
|   flag = 1;
|   setcontext(cont);
| }
| 
| static int
| g(void)
| {
|   int ret;
| 
|   flag = 0;
|   getcontext(cont);
|   ret = flag;
|   if (ret == 0) {
| printf(first flag=%d\n, flag);
| p0 = p1 = p2 = p3 = p4 = p5 = p6 = p7 = p8 = h;
| f();
| p0(ret); p1(ret); p2(ret); p3(ret); p4(ret); p5(ret); p6(ret); p7(ret);
p8(ret); 
|   }
|   else {
| printf(second flag=%d\n, flag);
|   }
|   return ret;
| }
| 
| int main(int argc, char **argv)
| {
|   g();
|   return 0;
| }

-- 
   Summary: SPARC register window is not preserved after getcontext
call
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akr at m17n dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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

[Bug c/22127] SPARC register window is not preserved after getcontext call

2005-06-20 Thread akr at m17n dot org 

--- Additional Comments From akr at m17n dot org  2005-06-20 17:22 ---
It's because getcontext is similar to setjmp.

Since setjmp/getcontext doesn't save registers in register window, modifications
to the registers between first setjmp/getcontext return and longjmp/setcontext
call is retained for second return from setjmp/getcontext via  
longjmp/setcontext.

It seems that gcc knows setjmp is special but doesn't know about getcontext.

Note that getcontext is defined by Single Unix Specification.

-- 
   What|Removed |Added

  Component|target  |c


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

[Bug c/22127] [3.4/4.0/4.1 Regression] register window not preserved after getcontext call

2005-06-20 Thread akr at m17n dot org 

--- Additional Comments From akr at m17n dot org  2005-06-20 17:36 ---
Although I have no Sun's Compiler, I found some pragmas about header file in 
SunOS:

#pragma unknown_control_flow(setjmp)
#pragma unknown_control_flow(_setjmp)
#pragma unknown_control_flow(sigsetjmp)
#pragma unknown_control_flow(getcontext)

So I guess Sun's Compiler can know getcontext is special. 

-- 


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

[Bug c/21957] New: IA-64 register stack is not preserved after getcontext call

2005-06-08 Thread akr at m17n dot org 
 is zero after second getcontext 
return. Note that this return is from setcontext, like longjmp to setjmp.  | 
(gdb) si |  | Program received signal SIGSEGV, Segmentation fault. | g () at 
tst.i:85 | 85ret = flag; | 1: x/i $pc  0x4901 g+65:   
   ld4 r32=[r32]  I think the getcontext behavior is not a bug because 
setjmp behaves like so.  Intel(R) Itanium(R) Software Conventions  Runtime 
Architecture Guide's section 10.3 describes setjmp may not preserve the 
contents of registers in  register stack (r32 to r127). 
http://www.intel.com/design/itanium/downloads/245358.htm  It seems that setjmp 
has no such problem because  gcc knows setjmp may return twice.  | rx1620% cd 
/home/src/gcc/4.0/gcc  | rx1620% grep -C8 'setjmp' gcc/calls.c | 
tname += 2; |   else | tname += 1; | } |  |   
if (tname[0] == 's') | { |   if ((tname[1] == 'e' | 
(! strcmp (tname, setjmp) ||| ! strcmp (tname, 
setjmp_syscall))) |   || (tname[1] == 'i' |
! strcmp (tname, sigsetjmp)) |   || (tname[1] == 'a' |
! strcmp (tname, savectx))) | flags |= 
ECF_RETURNS_TWICE; |  |   if (tname[1] == 'i'  So I guess the problem 
can be fixed if gcc knows getcontext returns twice.

-- 
   Summary: IA-64 register stack is not preserved after getcontext
call
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akr at m17n dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ia64-unknown-linux-gnu
  GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu


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

[Bug c/21957] IA-64 register stack is not preserved after getcontext call

2005-06-08 Thread akr at m17n dot org 

--- Additional Comments From akr at m17n dot org  2005-06-08 06:19 ---
Oops. The newlines are squashed.  I repeat the report as this comment.

I found that following code causes SEGV on IA-64 Debian GNU/Linux (sarge)
with gcc-4.0 -O1.
The code uses getcontext and setcontext which is defined by
Single Unix Specification.

rx1620% cat tst.i 
typedef long unsigned int size_t;

struct ia64_fpreg {
union {
unsigned long bits[2];
long double __dummy;
} u;
};

typedef struct sigaltstack
  {
void * ss_sp;
int ss_flags;
size_t ss_size;
  } stack_t;

struct sigcontext
{
  unsigned long int sc_flags;
  unsigned long int sc_nat;
  stack_t sc_stack;

  unsigned long int sc_ip;
  unsigned long int sc_cfm;
  unsigned long int sc_um;
  unsigned long int sc_ar_rsc;
  unsigned long int sc_ar_bsp;
  unsigned long int sc_ar_rnat;
  unsigned long int sc_ar_ccv;
  unsigned long int sc_ar_unat;
  unsigned long int sc_ar_fpsr;
  unsigned long int sc_ar_pfs;
  unsigned long int sc_ar_lc;
  unsigned long int sc_pr;
  unsigned long int sc_br[8];
  unsigned long int sc_gr[32];
  struct ia64_fpreg sc_fr[128];
  unsigned long int sc_rbs_base;
  unsigned long int sc_loadrs;
  unsigned long int sc_ar25;
  unsigned long int sc_ar26;
  unsigned long int sc_rsvd[12];

  unsigned long int sc_mask;
};

typedef struct sigcontext mcontext_t;

typedef struct ucontext
  {
union
  {
mcontext_t _mc;
struct
  {
unsigned long _pad[(((char *) ((struct sigcontext *) 0)-sc_gr[0])
- (char *) 0)/8];
struct ucontext *_link;
  }
_uc;
  }
_u;
  }
ucontext_t;

extern int getcontext (ucontext_t *__ucp) ;

extern int setcontext (__const ucontext_t *__ucp) ;

int flag;
ucontext_t cont;

static void f(void)
{
  flag = 1;
  setcontext(cont);
}

static int
g(void)
{
  int ret;

  flag = 0;
  getcontext(cont);
  ret = flag;
  if (ret == 0) {
f();
  }
  return ret;
}

int main(int argc, char **argv)
{
  g();
  return 0;
}
rx1620% /home/src/gcc/4.0/bin/gcc -v -g -O1 tst.i
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/src/gcc/4.0 
--enable-languages=c
Thread model: posix
gcc version 4.0.1 20050607 (prerelease)
 /home/src/gcc/4.0/libexec/gcc/ia64-unknown-linux-gnu/4.0.1/cc1 -fpreprocessed
tst.i -quiet -dumpbase tst.i -auxbase tst -g -O1 -version -o /tmp/ccGs6ixv.s
GNU C version 4.0.1 20050607 (prerelease) (ia64-unknown-linux-gnu)
compiled by GNU C version 4.0.1 20050607 (prerelease).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 as -x -o /tmp/ccgROVXU.o /tmp/ccGs6ixv.s
 /home/src/gcc/4.0/libexec/gcc/ia64-unknown-linux-gnu/4.0.1/collect2
-dynamic-linker /lib/ld-linux-ia64.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/home/src/gcc/4.0/lib/gcc/ia64-unknown-linux-gnu/4.0.1/crtbegin.o
-L/home/src/gcc/4.0/lib/gcc/ia64-unknown-linux-gnu/4.0.1
-L/home/src/gcc/4.0/lib/gcc/ia64-unknown-linux-gnu/4.0.1/../../..
/tmp/ccgROVXU.o -lgcc --as-needed -lgcc_s -lunwind --no-as-needed -lc -lgcc
--as-needed -lgcc_s -lunwind --no-as-needed
/home/src/gcc/4.0/lib/gcc/ia64-unknown-linux-gnu/4.0.1/crtend.o /usr/lib/crtn.o
rx1620% ./a.out  
zsh: segmentation fault (core dumped)  ./a.out
rx1620% uname -a
Linux rx1620 2.4.25-hpe-9-mckinley-smp #1 SMP Wed Aug 11 11:59:05 UTC 2004 ia64
GNU/Linux


The generated assembly code is follows.

| rx1620% /home/src/gcc/4.0/bin/gcc -O1 -S tst.i   
| rx1620% cat tst.s 
| .file   tst.i
| .pred.safe_across_calls p1-p5,p16-p63
| .text
| .align 16
| .proc f#
| f:
| .prologue 12, 32
| .save ar.pfs, r33
| alloc r33 = ar.pfs, 0, 3, 1, 0
| mov r34 = r1
| .save rp, r32
| mov r32 = b0
| .body
| addl r15 = 1, r0
| addl r14 = @ltoffx(flag#), r1
| ;;
| ld8.mov r14 = [r14], flag#
| ;;
| st4 [r14] = r15
| addl r35 = @ltoffx(cont#), r1
| ;;
| ld8.mov r35 = [r35], cont#
| br.call.sptk.many b0 = setcontext#
| mov r1 = r34
| ;;
| mov ar.pfs = r33
| mov b0 = r32
| br.ret.sptk.many b0
| ;;
| .endp f#
| .align 16
| .proc g#
| g:
| .prologue 12, 33
| .save ar.pfs, r34
| alloc r34 = ar.pfs, 0, 4, 1, 0
| mov r35 = r1
| .save rp, r33
| mov r33 = b0
| .body
| addl r32 = @ltoffx(flag#), r1
| ;;
| ld8.mov r32 = [r32], flag#

r32 is set.

| ;;
| st4 [r32] = r0
| addl r36 = @ltoffx(cont#), r1
| ;;
| ld8.mov r36 = [r36], cont#
| br.call.sptk.many b0 = getcontext#

getcontext is called.

| mov r1 = r35
| ld4 r32 = [r32]

r32 is used.
This means that the code

[Bug c/21332] New: -O2 makes a loop doesn't execute a body

2005-05-02 Thread akr at m17n dot org 
4.1.0 20050502 (experimental) seems have a problem with optimization.
The for loop in the else clause in the main doesn't execute the loop body. 

% cat t.c
extern int printf (__const char *__restrict __format, ...);

int f()
{
  return -2;
}

int main(int argc, char **argv)
{
  int c = f();
  long i;
  if (c  0) {
for (i=0;ic;i++) {
  f();
}
  }
  else {
c = -c;
printf(beg %d\n, c);
for (i=0;ic;i++) {
  printf(%d\n, i);
}
printf(end %d\n, i);
  }
  return 0;
}

% gcc -v -O2 t.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/src/gcc/trunk 
--enable-languages=c
Thread model: posix
gcc version 4.1.0 20050502 (experimental)
 /home/src/gcc/trunk/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -quiet -v t.c
-quiet -dumpbase t.c -mtune=pentiumpro -auxbase t -O2 -version -o 
/tmp/cc6LaTqE.s
ignoring nonexistent directory
/home/src/gcc/trunk/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 /usr/local/include
 /home/src/gcc/trunk/include
 /home/src/gcc/trunk/lib/gcc/i686-pc-linux-gnu/4.1.0/include
 /usr/include
End of search list.
GNU C version
 4.1.0 20050502 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20050502 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -V -Qy -o /tmp/cc6jWNoa.o /tmp/cc6LaTqE.s
GNU assembler version 2.15 (i386-linux) using BFD version 2.15
 /home/src/gcc/trunk/libexec/gcc/i686-pc-linux-gnu/4.1.0/collect2 --eh-frame-hdr
-m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/home/src/gcc/trunk/lib/gcc/i686-pc-linux-gnu/4.1.0/crtbegin.o
-L/home/src/gcc/trunk/lib/gcc/i686-pc-linux-gnu/4.1.0
-L/home/src/gcc/trunk/lib/gcc/i686-pc-linux-gnu/4.1.0/../../.. /tmp/cc6jWNoa.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /home/src/gcc/trunk/lib/gcc/i686-pc-linux-gnu/4.1.0/crtend.o
/usr/lib/crtn.o
% ./a.out   
beg 2
end 0

It works well without optimization as follows.

% gcc t.c   
% ./a.out 
beg 2
0
1
end 2

-- 
   Summary: -O2 makes a loop doesn't execute a body
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akr at m17n dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/21297] New: buf[i+i]=0 stores buf[i] when -O2

2005-04-30 Thread akr at m17n dot org 
gcc 4.0.0 optimization seems to have a problem.
In the f function in following source, buf[i+i] = '\0' stores '\0' to buf[2].
But it should store to buf[4]. 

% cat t.c
extern int printf (__const char *__restrict __format, ...);

void
f(char *buf)
{
  int i;
  for (i = 0; i  2; i++) ;
  printf(i=%d\n, i);
  buf[i+i] = '\0';
}

int main(int argc, char **argv)
{
  char buf[] = 0123456789;
  f(buf);
  printf(%s\n, buf);
  return 0;
}
% gcc -v -O2 t.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/home/src/gcc
Thread model: posix
gcc version 4.0.0
 /home/src/gcc/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1 -quiet -v t.c -quiet
-dumpbase t.c -mtune=pentiumpro -auxbase t -O2 -version -o /tmp/ccKF4bLU.s
ignoring nonexistent directory
/home/src/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 /usr/local/include
 /home/src/gcc/include
 /home/src/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/include
 /usr/include
End of search list.
GNU C version 4.0.0 (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 as -V -Qy -o /tmp/ccm6JTQG.o /tmp/ccKF4bLU.s
GNU assembler version 2.15 (i386-linux) using BFD version 2.15
 /home/src/gcc/libexec/gcc/i686-pc-linux-gnu/4.0.0/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/home/src/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/crtbegin.o
-L/home/src/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0
-L/home/src/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../.. /tmp/ccm6JTQG.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/home/src/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/crtend.o /usr/lib/crtn.o
% ./a.out 
i=2
01

The binary produces 01.  But it should be 0123.
If gcc 3.3.5 is used, the binary produces 0123.

-- 
   Summary: buf[i+i]=0 stores buf[i] when -O2
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akr at m17n dot org
CC: gcc-bugs at gcc dot gnu dot org


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