RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.

["Araneda, Dorian" <dorian dot araneda at intel dot com>]

The following reply was made to PR optimization/3329; it has been noted by GNATS.

From: "Araneda, Dorian" <dorian.araneda@intel.com>
To: "'Andrew Pinski'" <pinskia@physics.uc.edu>
Cc: "'Richard Henderson'" <rth@redhat.com>,
   "'rth@gcc.gnu.org'"<rth@gcc.gnu.org>,
   "'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>,
   "'gcc-prs@gcc.gnu.org'" <gcc-prs@gcc.gnu.org>,
   "'nobody@gcc.gnu.org'"<nobody@gcc.gnu.org>,
   "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Subject: RE: optimization/3329: optimization large memory copies uses kern
	 el memcpy function without user's knowledge.
Date: Tue, 2 Apr 2002 13:40:04 -0800 

 Mr Pinski,
 
 that is fine if memcpy is std c or gnu.
 
 but like I said. I don't want the legal problems with gnu.
 
 the file header that defines memcpy states:
 /*
 2  *  linux/lib/string.c
 3  *
 4  *  Copyright (C) 1991, 1992  Linus Torvalds
 5  */
 6 
 7 /*
 8  * stupid library routines.. The optimized versions should generally be
 found
 9  * as inline code in <asm-xx/string.h>
 10  *
 11  * These are buggy as well..
 12  *
 13  * * Fri Jun 25 1999, Ingo Oeser <ioe@informatik.tu-chemnitz.de>
 14  * -  Added strsep() which will replace strtok() soon (because strsep()
 is
 15  *    reentrant and should be faster). Use only strsep() in new code,
 please.
 16  */
 17
 
 whereas the file arch/i386/lib/memcpy.c has no header.
 I assume it inherits the Linus copyright. I dont know and
 I don't want to find out the hard way.
 
 either way,
 It does not seem necessary to 
 call a kernel memcpy symbol when optimizing a simple assignment.
 Let the individuals decide for themselves if they want
 to use it or not. Isn't the gcc compiler supposed to keep it simple and
 unimposing?
 
 Kernel versioning prevents portability of this optimization
 across different kernel configurations.
 
 I was told by an other user (in response to the ugly thread that
 has erupted), that the intel compiler did the same.
 
 I hope this is not the case.  If it is I will contact them.
 we have been working with developers who are directly related
 to that project.
 
 
 and btw. i prefere to discuss the issue in this way.
 non derogatory. thank you for your professional response.
 
 -dorian
 
 -----Original Message-----
 From: Andrew Pinski [mailto:pinskia@physics.uc.edu]
 Sent: Tuesday, April 02, 2002 2:53 PM
 To: Araneda, Dorian
 Cc: 'Richard Henderson'; 'rth@gcc.gnu.org'; 'gcc-bugs@gcc.gnu.org';
 'gcc-prs@gcc.gnu.org'; 'nobody@gcc.gnu.org'; 'gcc-gnats@gcc.gnu.org'
 Subject: Re: optimization/3329: optimization large memory copies uses
 kern el memcpy function without user's knowledge.
 
 
 No the problem is that it requires a STD C library to compile C code and 
 that is it.
 IF memcpy is defined to be using the GNU licenses, this is wrong because 
 it is part of the STD C (89 at least).
 
 
 Thanks,
 Andrew Pinski
 
 
 On Tuesday, April 2, 2002, at 02:31 , Araneda, Dorian wrote:
 
 > Mr. Henderson,
 >
 > I would expect such a response from a certain
 > large Linux nemesis company that I will not name.
 >
 > 1. NO, you did not appear to understand what I was talking about or at
 > least that's what it seemed like from your email.  And now,
 > judging by the tone of your email, I suspect that you did not
 > even care.
 > your response:
 > "    GCC requires that the memcpy symbol (among others) exist.
 >     I believe you'll find that at some point the x86 Linux kernel
 >     maintainers were convinced of this, and now that symbol does
 >     exist to be exported to your module."
 >
 > is totally unrelated to my question.  I could care less about
 > why the kernel exports a memcpy symbol and why it is  popular
 > amongst the kernel developers.
 >
 > MY COMPLAINT IS:
 > gcc adds OPEN SOURCE KERNEL DEPENDENT calls to my close
 > source binary without me EXPLICITLY calling for it.
 >
 > your comment that Linux memcpy is not open source code is
 > INCORRECT.  If closed source code has to depend on gnu open
 > source code(linux memcpy), whether in binary form or not,
 > the close source falls under the gnu license and must
 > be distributed as gnu open source.
 >
 > IRREGARDLESS IF I AM RIGHT OR WRONG, I don't care to even give
 > the chance of accidentally creating a dependency within our
 > proprietary closed source code to gnu open source.
 >
 >
 > the fact that I have to put:
 >   #if defined(LINUX)
 >   my_memcopy(&x, y, sizeof(x));
 >   #else
 >   x    = y;
 >   #endif
 >
 > because of a gcc optimization
 > is absurd.
 >
 > I sure hope you are not anyone important at redhat
 > with that "So what, I have no sympathy" elitist
 > attitude that you exhibited.  It shows poor character.
 > And this is not the only time I have had the
 > displeasure of dealing with arrogant people comming
 > from redha.
 >
 > FYI: I have NEVER had this sort of experience with
 > Mandrake or SuSE employees.
 >
 > I submitted this issue a year ago and had to
 > hack my code to resolve it.  As far as I am
 > concerned this issue OVER along with
 > the FLAME thread you decided to initiate.
 >
 > -Dorian
 >
 >
 >
 > -----Original Message-----
 > From: Richard Henderson [mailto:rth@redhat.com]
 > Sent: Tuesday, April 02, 2002 1:18 PM
 > To: Araneda, Dorian
 > Cc: 'rth@gcc.gnu.org'; 'gcc-bugs@gcc.gnu.org'; 'gcc-prs@gcc.gnu.org';
 > 'nobody@gcc.gnu.org'; 'gcc-gnats@gcc.gnu.org'
 > Subject: Re: optimization/3329: optimization large memory copies uses
 > kern el memcpy function without user's knowledge.
 >
 >
 > On Tue, Apr 02, 2002 at 09:59:45AM -0800, Araneda, Dorian wrote:
 >> I dont think you understand what i am talking about.
 >
 > I'm pretty sure I do.
 >
 >> The assembly output shows that memcopy is being used
 >> when optimizations are turned on even a the minimum level.
 >
 > Yes.
 >
 >> The code above is a legitamate call which does not
 >> need memcopy in place of optimized assembly code.
 >
 > "Need"?  Well, sure.  We could also expand printf inline
 > every time we saw it, but we don't.  What we want is to
 > generate efficient code, and that often involves this
 > curious invention called "subroutines", particularly for
 > larger, more complicated hunks of code.
 >
 >> This is not intuitive to the normal programmer.
 >
 > So?
 >
 >> I have no problem with memcopy being an exported kernel symbol.
 >> Memcopy may be superduper wonderfuly optimized but I do not want
 >> it or any other open source symbols in our closed source library.
 >
 > "memcpy" is hardly an "open source symbol".  It's an ISO C
 > sanctioned library entry point.
 >
 > I have no sympathy.
 >
 >
 > r~
 >
 >