Bug 10338 - [3.3 regression?] [Cygwin -> tic4x | avr] cross target compilation error
Summary: [3.3 regression?] [Cygwin -> tic4x | avr] cross target compilation error
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.3
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-04-07 12:56 UTC by svein.seldal
Modified: 2003-07-25 17:33 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description svein.seldal 2003-04-07 12:56:01 UTC
Compilation of cross target fails on cygwin. Tested cross targets are tic4x and avr. Tested gcc-3.3 versions are 20030407, 20030404, 20030315 and 20030302. Please note that this bug does not occur when building a native compiler.

I configure gcc with:
configure --target=tic4x --disable-nls --enable-languages="c,c++"

configure detect that mempcpy exists, but fails when it tries to link fixincl.exe. The cause of the error is located in gcc/fixinc/gnu-regex.c:5723. 

    #if defined HAVE_MEMPCPY || defined _LIBC
        *((char *) __mempcpy (errbuf, msg, errbuf_size - 1)) = '\0';
    #else
          memcpy (errbuf, msg, errbuf_size - 1);
          errbuf[errbuf_size - 1] = 0;
    #endif

configure tests and detects that mempcpy() exists (which it does). However in the gcc/fixinc/gnu-regex.c file the function __mempcpy() is used (which does _not_ exist in cygwin).

I need to comment that this bug is likely a bug or change in the cygwin libc, because the gcc-3.3 20030315 and 20030302 *has* worked on cygwin earlier. I dont know what changes I have made to my local cygwin installation that causes the failures. -- In either cases either cygwin or gcc need to change some code to get this up and working.

Release:
gcc version 3.3 release 20030407

Environment:
Windows XP/Cygwin 1.3.22. Native compiler gcc 3.2 20020907

How-To-Repeat:
configure --target=tic4x --disable-nls --enable-languages="c,c++"
make
Comment 1 svein.seldal 2003-04-07 12:56:01 UTC
Fix:
Comment out the #if section in gcc/fixinc/gnu-regex.c:5723, and use the code in the #else section instead.
Comment 2 garen 2003-04-10 18:12:59 UTC
From: Garen <garen@wsu.edu>
To: gcc-gnats@gcc.gnu.org, Svein.Seldal@solidas.com,
	gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org
Cc:  
Subject: Re: target/10338: [3.3 regression?] [Cygwin -> tic4x | avr] cross target compilation error
Date: Thu, 10 Apr 2003 18:12:59 -0700

 I ran into the same problem here (PR10198):
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10198
 
 So I don't think it's a regression.  It seems to be present on all of the 
 3.2.x branches, so I'm guessing it's a Cygwin problem.  I worked around it 
 similarly by just not using __memcpy(), and instead memcpy() in the #else 
 branch.
 
 

Comment 3 DJ Delorie 2003-04-10 22:08:55 UTC
From: DJ Delorie <dj@redhat.com>
To: garen@wsu.edu
Cc: gcc-gnats@gcc.gnu.org, Svein.Seldal@solidas.com, gcc-bugs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org
Subject: Re: target/10338: [3.3 regression?] [Cygwin -> tic4x | avr] cross target compilation error
Date: Thu, 10 Apr 2003 22:08:55 -0400

 > So I don't think it's a regression.  It seems to be present on all of the 
 > 3.2.x branches, so I'm guessing it's a Cygwin problem.  I worked around it 
 > similarly by just not using __memcpy(), and instead memcpy() in the #else 
 > branch.
 
 It looks like it's always been a bug, but until now there hasn't been
 an OS that defined mempcpy (not memcpy) and not also __mempcpy, so we
 just didn't trip over it.

Comment 4 svein.seldal 2003-04-11 03:57:02 UTC
From: "Svein E. Seldal" <Svein.Seldal@solidas.com>
To: Garen <garen@wsu.edu>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org,
   gcc-prs@gcc.gnu.org
Subject: Re: target/10338: [3.3 regression?] [Cygwin -> tic4x | avr] cross
 target compilation error
Date: Fri, 11 Apr 2003 03:57:02 +0200

 Garen wrote:
 > I ran into the same problem here (PR10198):
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10198
 > 
 > So I don't think it's a regression.  It seems to be present on all of the 
 > 3.2.x branches, so I'm guessing it's a Cygwin problem.  I worked around it 
 > similarly by just not using __memcpy(), and instead memcpy() in the #else 
 > branch.
 > 
 
 Yes its the same bug...
 
 Well it depend on how you define regression. It seems like this is a 
 Cygwin regression and not a gcc one, because it *did* work on the 
 gcc-3.3-branch at 20030315, and now it dont (using that date's 
 snapshot). The same applies to the 3.2.x branches.
 
 But my point is, that if this is caused by a Cygwin thing, what approach 
 should we take to fix it? Fix Cygwin or fix gcc?
 
 
 Svein
 

Comment 5 Kaveh Ghazi 2003-04-15 14:24:26 UTC
From: ghazi@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: target/10338
Date: 15 Apr 2003 14:24:26 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Changes by:	ghazi@gcc.gnu.org	2003-04-15 14:24:26
 
 Modified files:
 	gcc            : ChangeLog 
 	libiberty      : ChangeLog getopt.c regex.c 
 	gcc/fixinc     : gnu-regex.c 
 
 Log message:
 	gcc:
 	PR target/10338
 	PR bootstrap/10198
 	PR bootstrap/10140
 	* fixinc/gnu-regex.c (regerror): Use mempcpy not __mempcpy.
 	
 	libiberty:
 	PR target/10338
 	PR bootstrap/10198
 	PR bootstrap/10140
 	* getopt.c (exchange, _getopt_initialize): Use mempcpy not
 	__mempcpy.
 	* regex.c (regerror): Likewise.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.17456&r2=1.17457
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libiberty/ChangeLog.diff?cvsroot=gcc&r1=1.431&r2=1.432
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libiberty/getopt.c.diff?cvsroot=gcc&r1=1.7&r2=1.8
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libiberty/regex.c.diff?cvsroot=gcc&r1=1.13&r2=1.14
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/gnu-regex.c.diff?cvsroot=gcc&r1=1.15&r2=1.16
 

Comment 6 Kaveh Ghazi 2003-04-15 14:24:26 UTC
From: ghazi@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: target/10338
Date: 15 Apr 2003 14:24:26 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Changes by:	ghazi@gcc.gnu.org	2003-04-15 14:24:26
 
 Modified files:
 	gcc            : ChangeLog 
 	libiberty      : ChangeLog getopt.c regex.c 
 	gcc/fixinc     : gnu-regex.c 
 
 Log message:
 	gcc:
 	PR target/10338
 	PR bootstrap/10198
 	PR bootstrap/10140
 	* fixinc/gnu-regex.c (regerror): Use mempcpy not __mempcpy.
 	
 	libiberty:
 	PR target/10338
 	PR bootstrap/10198
 	PR bootstrap/10140
 	* getopt.c (exchange, _getopt_initialize): Use mempcpy not
 	__mempcpy.
 	* regex.c (regerror): Likewise.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.17456&r2=1.17457
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libiberty/ChangeLog.diff?cvsroot=gcc&r1=1.431&r2=1.432
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libiberty/getopt.c.diff?cvsroot=gcc&r1=1.7&r2=1.8
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libiberty/regex.c.diff?cvsroot=gcc&r1=1.13&r2=1.14
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/gnu-regex.c.diff?cvsroot=gcc&r1=1.15&r2=1.16
 

Comment 9 Kaveh Ghazi 2003-04-25 15:15:07 UTC
State-Changed-From-To: open->closed
State-Changed-Why: Fixed in 3.3, too late for 3.2.3.