--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-10 21:29 ---
You can use -fno-builtin-strncpy or -ffreestanding to "fix" this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30785
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-10 21:24 ---
Actually, strncpy is a reserved name so we assume pDest and pSrc are non-null.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-03-10 20:55 ---
Reopening. It's fixed for 64bit systems but not 32bit ones!? vrp dump
difference:
Visiting statement:
-D.1617_3 = pDest_2 == 0B;
+D.1286_3 = pDest_2 == 0B;
-Found new range for D.1617_3: VARYING
+Found new range
--- Comment #4 from tg at mirbsd dot org 2007-03-10 20:31 ---
It's not fixed on 4.1 branch:
[EMAIL PROTECTED]:~/tmp $ cat _t.c
typedef unsigned size_t;
char *xxcpy( char *pDest, const char *pSrc, size_t n);
char *strncpy( char *pDest, const char *pSrc, size_t n) {
if (pDest == 0 ||
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-02-13 13:57 ---
This is indeed fixed on the branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from etienne_lorrain at yahoo dot fr 2007-02-13 13:44
---
Problem is fixed by -fno-tree-vrp and -O2
I am not a specialist of -fdump-tree-all, but it seems like that:
tmp.c.t35.copyprop1:
;; Function strncpy (strncpy)
strncpy (pDest, pSrc, n)
{
char * D.1282;
char
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-13 13:00 ---
I suppose this is done by the VRP pass (-f[no-]tree-vrp) so target independent.
If so, this is fixed on current 4.1 branch. Can you verify this indeed is
broken by VRP by looking at and before the vrp tree dumps? (
