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 14:00:42 -0800 

 In reference to my last post i also came across this in 
 the file Linux/include/asm-mips/string.h 
 *
 2  * This file is subject to the terms and conditions of the GNU General
 Public
 3  * License.  See the file "COPYING" in the main directory of this archive
 4  * for more details.
 5  *
 6  * Copyright (c) 1994, 1995, 1996, 1997, 1998, 2001 Ralf Baechle
 7  * Copyright (c) 2001 MIPS Technologies, Inc.
 8  */
 9 
 
 I did not see an asm-i386  version. and some of the other platforms
 had different headers.
 
 this is why i believe linux kernel memcpy is GNU open source and 
 could inadvertently cause a programer who wishes for thier code
 to be independent and closed, to form a dependency to GNU open source.
 
 please dont assume that i have something against GNU open source.
 I think it is a great service to society.
 But people should have a right to make a totatly independent
 closed source program.
 
 Now if i cant use gcc as suggested by an other person (again
 in response to this thread) because
 of GNU, I will have to present that issue to the intel lawers
 to see if i need to start just compiling the closed source with the
 intel compiler for linux.
 
 -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~
 >
 >