This is the mail archive of the gcc-prs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

From: "Araneda, Dorian" <dorian.araneda@intel.com>
To: "'Richard Henderson'" <rth@redhat.com>
Cc: "'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 11:31:58 -0800 

 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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]