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

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

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: "Araneda, Dorian" <dorian.araneda@intel.com>
Cc: "'Joseph S. Myers'" <jsm28@cam.ac.uk>,
   "'rth@gcc.gnu.org'" <rth@gcc.gnu.org>,
   "'gcc-bugs@gcc.gnu.org'" <gcc-bugs@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:43:00 -0800

 On Tue, Apr 02, 2002 at 02:33:46PM -0800, Araneda, Dorian wrote:
 > Is -ffrestanding a gcc argument?
 
 Yes, but it doesn't do what you think.
 
 "Freestanding" is a term used by the ISO C standard in
 contrast with "hosted".  There are more constraints on
 "hosted" environments.
 
 Please read the standard for complete details.
 
 
 r~

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

[Araneda, Dorian]

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 16:13:38 -0800 

 ok
 
 lets stop talking about this as it is getting 
 nowhere and agrivating myself and others.
 
 I am sorry i tried to help with this product.
 I dont even know why i even try to contribute.
 I try to argue in the defense of the benifits
 and rewards of developing for the linux os to my 
 coworkers. I try contribute to and explain that closed
 source can exist without problems in a dynamic
 open source environment to the linux community.
 
 I take risks an bust my butt for this 
 OS and linux work and all i get is
 rude, unhelpul, junk from both sides.
 But who care's about what i think or do right?
 
 I am sorry for sounding sarcastic in my response
 to the issue dismissal.
 I just felt that the dismissal came very late
 and without even answering my question.
 
 please dont bother responding. messages
 about this subject or people related to 
 this subject will just be automaticaly 
 deleted without being read.
 
 ----------
 
 
 
 
  
 

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

[Daniel Berlin]

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

From: Daniel Berlin <dan@dberlin.org>
To: "Araneda, Dorian" <dorian.araneda@intel.com>
Cc: "'Richard Henderson'" <rth@redhat.com>,
   "'Andrew Pinski'" <pinskia@physics.uc.edu>,
   "'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 18:45:33 -0500 (EST)

 On Tue, 2 Apr 2002, Araneda, Dorian wrote:
 
 > Berlin,
 > which standard?  if it is an ansi c standard then
 > I should bring the issue up with them.
 
 C99.
 
 > 
 > but regarding your other unnecessary comments.
 Unnecessary?
 
 Anything you don't agree with seems to be categorized as  unnecessary or 
 unprofessional.
 
 > you may argue that I am selfish and 
 > only care about what I think.
 > I am trying to argue in favor 
 > of allowing users to decide for themselves 
 > if they need to use kernel memcpy.
 
 And, as I, and others have said, , we all understand, and find your 
 argument unpersuasive.
 > 
 > I argue that in your
 > own selfish way you couldn't care less 
 > (I corrected my grammar Mr. Niel Booth)
 > what other would want. It is either "your way
 > the highway", "so what", "I have no sympathies".
 
 You could argue this, but you have zero evidence to back it up.  I can 
 point to the standard, and say what we do is perfectly fine and normal, 
 not discrimination or "my way or the highway".
 > 
 > 
 > handicapped people are not the majority. Does
 > that still make it right to be rude
 > and just do things for them without
 > their permission?
 Please don't try to make analogies to disabled/otherwise challenged people 
 here. It has nothing to do with the topic at hand.
 As a person with disabilities, you probably don't want to broach this 
 topic with me.  I'm perfectly fine with my girlfriend doing some things 
 for me without my permission, they wouldn't get done otherwise.
 
  > 
 > if the majority doesn't care and you don't care then
 > whets all the resistance to making the change?
 Because it will set a precedent that should not be followed.
 > it is a typical reaction, "if it does not offend me
 > then it is not offensive and we need not change"
 No, it's not.
 It's a "you are the only one, ever, to complain about this, there is no 
 good technical reason for the change, and you have convinced exactly 0 
 developers that the change should be made. Therefore, it will not be made"
 > 
 > Isn't your indifference to user suggestion for gcc 
 > ANTI-open source. 
 Nope.
 There has been no indifference here.
 Everyone seems to be united *against* it.
 > 
 > fine. rude people will be rude people
 > irregardless of what I may suggest or
 > say.
 
 Nobody, including Richard, has been rude to you. The original message was 
 not a public flame. He did not misunderstand. He simply disagreed with 
 you, as I have.  You interpret disagreement with you as rudeness.
 

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

[Araneda, Dorian]

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

From: "Araneda, Dorian" <dorian.araneda@intel.com>
To: "'Daniel Berlin'" <dan@dberlin.org>
Cc: "'Richard Henderson'" <rth@redhat.com>,
   "'Andrew Pinski'"<pinskia@physics.uc.edu>,
   "'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 15:20:50 -0800 

 Berlin,
 which standard?  if it is an ansi c standard then
 I should bring the issue up with them.
 
 but regarding your other unnecessary comments.
 you may argue that I am selfish and 
 only care about what I think.
 I am trying to argue in favor 
 of allowing users to decide for themselves 
 if they need to use kernel memcpy.
 
 I argue that in your
 own selfish way you couldn't care less 
 (I corrected my grammar Mr. Niel Booth)
 what other would want. It is either "your way
 the highway", "so what", "I have no sympathies".
 
 and what if the "majority of programmers don't care"?
 
 handicapped people are not the majority. Does
 that still make it right to be rude
 and just do things for them without
 their permission?
 
 if the majority doesn't care and you don't care then
 whets all the resistance to making the change?
 it is a typical reaction, "if it does not offend me
 then it is not offensive and we need not change"
 
 Isn't your indifference to user suggestion for gcc 
 ANTI-open source.  what you are saying is "it is open
 source as long as it does everything my way irregardless
 if I care about the change or not. I am incapable of being wrong
 And if the idea is unimportant to me then the suggestion 
 is unimportant and I see no reason to consider it.
 The submitter can just go read a FAQ".
 
 fine. rude people will be rude people
 irregardless of what I may suggest or
 say.
 
 I would have preferred to have been told
 to buzz off a little earlier than a year.
 -Dorian 
 
 
 
 
 -----Original Message-----
 From: Daniel Berlin [mailto:dan@dberlin.org]
 Sent: Tuesday, April 02, 2002 5:38 PM
 To: Araneda, Dorian
 Cc: 'Richard Henderson'; 'Andrew Pinski'; '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, 2002-04-02 at 17:29, Araneda, Dorian wrote:
 > 
 > this may be the case, but I don't think 
 > a developer should know the kernel-hacking tricks 
 > to get their code to be portable across kernels.
 > 
 > x=y; 
 > is not intuitively interpreted as 
 > memcpy(&x,y,sizeof(x));
 > 
 According to the standard, it's perfectly normal.
 It says specifically that structure assignments may be implemented with
 memcpy. (footnote 38)
 In fact, it says that all assignments > 1 byte could be implemented by
 memcpy.
 
 > I can assure you that if gcc did a survey of all
 > the developers using gcc, the vast majority
 > would not have realized this was occurring
 > in their code.
 The vast majority wouldn't care, i'd wager.
 > 
 > if this is not the case and I am a twink when 
 > it comes to kernel development, gcc should still
 > be idiot proof.the compiler  should not make
 > assumptions that the user is ok with linking
 > unapproved kernel function calls.
 > 
 > is simple, I don't appreciate a compiler feature
 > that goes behind my back to include code I did not
 > ask for.
 But you did! We have done nothing the standard says we can't do.
 If you want to modify your compiler to not do this, feel free.
 After all, you have the source.
 
 > 
 > It is like someone who thinks they are being
 > polite by pushing someone in a wheelchair because
 > they feel that they need the help.
 > It is not good etiquette to do that when that
 > person neither asked for help or gave permission
 > to be pushed.
 >  
 > gcc may have had good intentions but is still
 > not right to override the user's intent in that
 > way.
 
 What intent?
 You keep making this assumption that what you think is right is what
 other people think is right.
 I would wager most users either don't care, or don't have a problem with
 it.
 
 > 
 > I do not see why it is so hard to understand
 > what I am trying to explain.  It is not about
 > what method is better.  It's about common courtesy
 > to the user.
 No it's not.
 It's about you being annoyed that we emit memcpy, and trying to come up
 with reasons why we shouldn't do it.
 None of which are persuasive, at least to me.
 
 > 
 > -Dorian
 > 
 > -----Original Message-----
 > From: Richard Henderson [mailto:rth@redhat.com]
 > Sent: Tuesday, April 02, 2002 5:02 PM
 > To: Araneda, Dorian
 > Cc: 'Andrew Pinski'; '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.
 > 
 > 
 > There are two markups that export symbols from the kernel:
 > 
 >  (1) EXPORT_SYMBOL
 > 
 > 	This is used for symbols with which there are no
 > 	restrictions for use.
 > 
 >  (2) EXPORT_SYMBOL_GPL
 > 
 > 	This is used for symbols that may only be used with
 > 	modules that carry a GPL compatible license.
 > 
 > See linux/Documentation/DocBook/kernel-hacking.tmpl or
 > some post-processing thereof.
 > 
 > You will find that memcpy and all of the other gcc support
 > routines are exported with EXPORT_SYMBOL, and thus do not
 > contaminate your code.
 > 
 > 
 > r~

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

[Karl Günter Wünsch]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

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

From: Karl =?iso-8859-1?q?G=FCnter=20W=FCnsch?= <kgw@mineralien-verkauf.de>
To: "Araneda, Dorian" <dorian.araneda@intel.com>,
 "'Joseph S. Myers'" <jsm28@cam.ac.uk>,
 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-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: Wed, 3 Apr 2002 02:51:43 +0200

 On Wednesday 03 April 2002 00:33, Araneda, Dorian wrote:
 > Is -ffrestanding a gcc argument?
 >
 > Is this the recommended compiler argument for any code that
 > wishes to be "freestanding" and still use gcc?
 >
 > even though I stripped all operating system dependent calls
 > from the code, I still want to be absolutely sure that
 > I am not including someone else's code.
 >
 Then you shouldn't be using any compiler but your own or hand code your driver 
 in assembler. 
 
 That's the difference between calling a library function and inlining that 
 functionality through the compiler. If that routine were inlined - as you 
 suggest it should be - then you would truly be including someone else's code 
 instead of just relying that it's there. There is nothing stopping you from 
 reinventing the wheel :-) but you'd have to do it yourself...
 
 > -Dorian
 >
 regards
 Karl Günter Wünsch
 

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

[Daniel Berlin]

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

From: Daniel Berlin <dan@dberlin.org>
To: "Araneda, Dorian" <dorian.araneda@intel.com>
Cc: "'Richard Henderson'" <rth@redhat.com>,
   "'Andrew Pinski'"
	 <pinskia@physics.uc.edu>,
   "'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: 02 Apr 2002 17:38:14 -0500

 On Tue, 2002-04-02 at 17:29, Araneda, Dorian wrote:
 > 
 > this may be the case, but I don't think 
 > a developer should know the kernel-hacking tricks 
 > to get their code to be portable across kernels.
 > 
 > x=y; 
 > is not intuitively interpreted as 
 > memcpy(&x,y,sizeof(x));
 > 
 According to the standard, it's perfectly normal.
 It says specifically that structure assignments may be implemented with
 memcpy. (footnote 38)
 In fact, it says that all assignments > 1 byte could be implemented by
 memcpy.
 
 > I can assure you that if gcc did a survey of all
 > the developers using gcc, the vast majority
 > would not have realized this was occurring
 > in their code.
 The vast majority wouldn't care, i'd wager.
 > 
 > if this is not the case and I am a twink when 
 > it comes to kernel development, gcc should still
 > be idiot proof.the compiler  should not make
 > assumptions that the user is ok with linking
 > unapproved kernel function calls.
 > 
 > is simple, I don't appreciate a compiler feature
 > that goes behind my back to include code I did not
 > ask for.
 But you did! We have done nothing the standard says we can't do.
 If you want to modify your compiler to not do this, feel free.
 After all, you have the source.
 
 > 
 > It is like someone who thinks they are being
 > polite by pushing someone in a wheelchair because
 > they feel that they need the help.
 > It is not good etiquette to do that when that
 > person neither asked for help or gave permission
 > to be pushed.
 >  
 > gcc may have had good intentions but is still
 > not right to override the user's intent in that
 > way.
 
 What intent?
 You keep making this assumption that what you think is right is what
 other people think is right.
 I would wager most users either don't care, or don't have a problem with
 it.
 
 > 
 > I do not see why it is so hard to understand
 > what I am trying to explain.  It is not about
 > what method is better.  It's about common courtesy
 > to the user.
 No it's not.
 It's about you being annoyed that we emit memcpy, and trying to come up
 with reasons why we shouldn't do it.
 None of which are persuasive, at least to me.
 
 > 
 > -Dorian
 > 
 > -----Original Message-----
 > From: Richard Henderson [mailto:rth@redhat.com]
 > Sent: Tuesday, April 02, 2002 5:02 PM
 > To: Araneda, Dorian
 > Cc: 'Andrew Pinski'; '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.
 > 
 > 
 > There are two markups that export symbols from the kernel:
 > 
 >  (1) EXPORT_SYMBOL
 > 
 > 	This is used for symbols with which there are no
 > 	restrictions for use.
 > 
 >  (2) EXPORT_SYMBOL_GPL
 > 
 > 	This is used for symbols that may only be used with
 > 	modules that carry a GPL compatible license.
 > 
 > See linux/Documentation/DocBook/kernel-hacking.tmpl or
 > some post-processing thereof.
 > 
 > You will find that memcpy and all of the other gcc support
 > routines are exported with EXPORT_SYMBOL, and thus do not
 > contaminate your code.
 > 
 > 
 > r~
 

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

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: "Araneda, Dorian" <dorian.araneda@intel.com>
Cc: "'Andrew Pinski'" <pinskia@physics.uc.edu>,
   "'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:38:16 -0800

 On Tue, Apr 02, 2002 at 02:29:35PM -0800, Araneda, Dorian wrote:
 > x=y; 
 > is not intuitively interpreted as 
 > memcpy(&x,y,sizeof(x));
 
 Neither is
 
 	long long x, y, r;
 	r = x / y;
 
 "intuitively" interpreted as a call to __divdi3.
 Nevertheless that is what will happen.
 
 There are a collection of routines that are designated
 "compiler support routines", against which the compiler
 is *designed* to generate calls.
 
 We *could* have invented our own symbol name for performing
 out-of-line block copies, but that would have been silly
 considering the amount of effort that is spent making the
 standard memcpy function as efficient as possible.
 
 Therefore we "adopted" memcpy, memmove, memset, and memcmp
 as honorary compiler support routines.
 
 > I do not see why it is so hard to understand
 > what I am trying to explain.
 
 I understand very will what you are trying to explain.
 However, I do not agree.
 
 
 r~

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

[Araneda, Dorian]

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

From: "Araneda, Dorian" <dorian.araneda@intel.com>
To: "'Joseph S. Myers'" <jsm28@cam.ac.uk>, 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-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:33:46 -0800 

 Is -ffrestanding a gcc argument?
 
 Is this the recommended compiler argument for any code that
 wishes to be "freestanding" and still use gcc?
 
 even though I stripped all operating system dependent calls
 from the code, I still want to be absolutely sure that 
 I am not including someone else's code.
 
 -Dorian
 
 -----Original Message-----
 From: Joseph S. Myers [mailto:jsm28@cam.ac.uk]
 Sent: Tuesday, April 02, 2002 4:23 PM
 To: Richard Henderson
 Cc: Araneda, Dorian; 'rth@gcc.gnu.org'; 'gcc-bugs@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, 2 Apr 2002, Richard Henderson wrote:
 
 > Then you can't use gcc at all.  We reserve the right to generate
 > code that calls into any of the compiler support routines in libgcc,
 > plus a select number of ISO C routines from libc.  (The fact that
 
 The documentation for -ffreestanding should detail what ISO C library
 functions may be used (apart from __builtin functions potentially becoming
 calls to the non-__builtin versions of those functions or others).
 
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk

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

[Araneda, Dorian]

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: "'Andrew Pinski'" <pinskia@physics.uc.edu>,
   "'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:29:35 -0800 

 this may be the case, but I don't think 
 a developer should know the kernel-hacking tricks 
 to get their code to be portable across kernels.
 
 x=y; 
 is not intuitively interpreted as 
 memcpy(&x,y,sizeof(x));
 
 I can assure you that if gcc did a survey of all
 the developers using gcc, the vast majority
 would not have realized this was occurring
 in their code.
 
 if this is not the case and I am a twink when 
 it comes to kernel development, gcc should still
 be idiot proof. the compiler  should not make
 assumptions that the user is ok with linking
 unapproved kernel function calls.
 
 is simple, I don't appreciate a compiler feature
 that goes behind my back to include code I did not
 ask for.
 
 It is like someone who thinks they are being
 polite by pushing someone in a wheelchair because
 they feel that they need the help.
 It is not good etiquette to do that when that
 person neither asked for help or gave permission
 to be pushed.
  
 gcc may have had good intentions but is still
 not right to override the user's intent in that
 way.
 
 I do not see why it is so hard to understand
 what I am trying to explain.  It is not about
 what method is better.  It's about common courtesy
 to the user.
 
 -Dorian
 
 -----Original Message-----
 From: Richard Henderson [mailto:rth@redhat.com]
 Sent: Tuesday, April 02, 2002 5:02 PM
 To: Araneda, Dorian
 Cc: 'Andrew Pinski'; '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.
 
 
 There are two markups that export symbols from the kernel:
 
  (1) EXPORT_SYMBOL
 
 	This is used for symbols with which there are no
 	restrictions for use.
 
  (2) EXPORT_SYMBOL_GPL
 
 	This is used for symbols that may only be used with
 	modules that carry a GPL compatible license.
 
 See linux/Documentation/DocBook/kernel-hacking.tmpl or
 some post-processing thereof.
 
 You will find that memcpy and all of the other gcc support
 routines are exported with EXPORT_SYMBOL, and thus do not
 contaminate your code.
 
 
 r~

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

[Araneda, Dorian]

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~
 >
 >

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

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: "Araneda, Dorian" <dorian.araneda@intel.com>
Cc: "'Andrew Pinski'" <pinskia@physics.uc.edu>,
   "'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:01:33 -0800

 There are two markups that export symbols from the kernel:
 
  (1) EXPORT_SYMBOL
 
 	This is used for symbols with which there are no
 	restrictions for use.
 
  (2) EXPORT_SYMBOL_GPL
 
 	This is used for symbols that may only be used with
 	modules that carry a GPL compatible license.
 
 See linux/Documentation/DocBook/kernel-hacking.tmpl or
 some post-processing thereof.
 
 You will find that memcpy and all of the other gcc support
 routines are exported with EXPORT_SYMBOL, and thus do not
 contaminate your code.
 
 
 r~

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

[Araneda, Dorian]

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~
 >
 >

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

[Araneda, Dorian]

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 13:20:49 -0800 

 Henderson,
 
 you dismissal without consideration was NOT civil.
 and you can not point out any reason for your flame.
 your response did not address my question so I felt
 you did not understand what I was suggesting and I emailed
 a more detailed description of  the bug.
 
 could you please point out where in that email did
 I say something to deserve such a inflammatory reply from you
 and to have it CC'ed to everyone in the world?
 
 I do not feel like I have to be apologetic for either disagreeing 
 with you or being upset at your response aimed at publicly
 flaming me because I disagreed with your decision.
 
 and I do not think I have to be apologetic for defending myself
 publicly when I had been flamed publicly.
 
 -Dorian
 
 -----Original Message-----
 From: Richard Henderson [mailto:rth@redhat.com]
 Sent: Tuesday, April 02, 2002 3:12 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 11:31:58AM -0800, Araneda, Dorian wrote:
 > 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.
 
 No, that's incorrect.  Not all symbols are created equal.
 Some of them are marked as GPL-only, some of them are not.
 
 You should go back and review the licences involved.
 
 > 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.
 
 Then you can't use gcc at all.  We reserve the right to generate
 code that calls into any of the compiler support routines in libgcc,
 plus a select number of ISO C routines from libc.  (The fact that
 these symbols are packaged differently in the kernel than in userland
 is immaterial.)
 
 > 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.
 [...]
 > As far as I am concerned this issue OVER along with 
 > the FLAME thread you decided to initiate.
 
 Well, gee, I thought MY first message was pretty civil.
 You're the one telling me I don't know what I'm talking about.
 
 
 r~

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

[Joseph S. Myers]

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

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Richard Henderson <rth@redhat.com>
Cc: "Araneda, Dorian" <dorian.araneda@intel.com>, 
    "'rth@gcc.gnu.org'" <rth@gcc.gnu.org>, 
    "'gcc-bugs@gcc.gnu.org'" <gcc-bugs@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 22:22:33 +0100 (BST)

 On Tue, 2 Apr 2002, Richard Henderson wrote:
 
 > Then you can't use gcc at all.  We reserve the right to generate
 > code that calls into any of the compiler support routines in libgcc,
 > plus a select number of ISO C routines from libc.  (The fact that
 
 The documentation for -ffreestanding should detail what ISO C library
 functions may be used (apart from __builtin functions potentially becoming
 calls to the non-__builtin versions of those functions or others).
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 

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

[Richard Henderson]

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

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

 On Tue, Apr 02, 2002 at 11:31:58AM -0800, Araneda, Dorian wrote:
 > 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.
 
 No, that's incorrect.  Not all symbols are created equal.
 Some of them are marked as GPL-only, some of them are not.
 
 You should go back and review the licences involved.
 
 > 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.
 
 Then you can't use gcc at all.  We reserve the right to generate
 code that calls into any of the compiler support routines in libgcc,
 plus a select number of ISO C routines from libc.  (The fact that
 these symbols are packaged differently in the kernel than in userland
 is immaterial.)
 
 > 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.
 [...]
 > As far as I am concerned this issue OVER along with 
 > the FLAME thread you decided to initiate.
 
 Well, gee, I thought MY first message was pretty civil.
 You're the one telling me I don't know what I'm talking about.
 
 
 r~

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

[Neil Booth]

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

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: "Araneda, Dorian" <dorian.araneda@intel.com>
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 21:06:21 +0100

 Araneda, Dorian wrote:-
 
 > is totally unrelated to my question.  I could care less about 
                                           ^^^^^
 Nit: you mean "couldn't".
 
 Neil.

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

[Andrew Pinski]

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

From: Andrew Pinski <pinskia@physics.uc.edu>
To: "Araneda, Dorian" <dorian.araneda@intel.com>
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:52:36 -0500

 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~
 >
 >
 

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

[Araneda, Dorian]

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~

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

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: "Araneda, Dorian" <dorian.araneda@intel.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 10:17:41 -0800

 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~

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

[Araneda, Dorian]

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

From: "Araneda, Dorian" <dorian.araneda@intel.com>
To: "'rth@gcc.gnu.org'" <rth@gcc.gnu.org>,
   "Araneda, Dorian"<dorian.araneda@intel.com>,
   "'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>
Cc:  
Subject: RE: optimization/3329: optimization large memory copies uses kern
	el memcpy function without user's knowledge.
Date: Tue, 2 Apr 2002 09:59:45 -0800 

 I dont think you understand what i am talking about.
 
 if i say,
 
 static const some_struct_type x = { "data of some sort, in my case about 85
 bytes};
 some_struct_type y;
 y = x;
 
 The assembly output shows that memcopy is being used
 when optimizations are turned on even a the minimum level.
 The code above is a legitamate call which does not
 need memcopy in place of optimized assembly code.
 
 This is not intuitive to the normal programmer.
 If the programmer wanted the external symbol memcopy() in
 their code they would add it themselves. 
 
 It is an annoying feature to debug when
 a programmer is unaware of the latest
 gcc optimization techniques and is trying to write
 a kernel independent, closed source, device driver library.
 Or any code that needs to be kernel independent.
 
 gcc should only be optimizing the assembly code, not introducing
 external dependencies the programmer did not ask for.
 
 I had to add a hack to my code and write my own memcopy just
 to be able to execute the code above.
 
 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.
 
 I hope that in the future gcc does not expand this optimization
 to include other kernel symbols.  I would prefer to see this
 feature removed, and i believe the gcc maintainers will find 
 that many other normal kernel mode programers would like 
 to see it removed if they knew it was there.
 
 ---
 Dorian S. Araneda
 Product Engineer,
 Intel Residential Access Division (RAD)
 http://developer.intel.com/design/modems/
 www.intel.com   www.intc.com  (ticker: INTC)
 110 Horizon Dr., Suite 300, Raleigh, NC  27615
 
 
 -----Original Message-----
 From: rth@gcc.gnu.org [mailto:rth@gcc.gnu.org]
 Sent: Tuesday, April 02, 2002 5:10 AM
 To: dorian.araneda@intel.com; gcc-bugs@gcc.gnu.org; gcc-prs@gcc.gnu.org;
 nobody@gcc.gnu.org
 Subject: Re: optimization/3329: optimization large memory copies uses
 kernel memcpy function without user's knowledge.
 
 
 Synopsis: optimization large memory copies uses kernel memcpy function
 without user's knowledge.
 
 State-Changed-From-To: open->closed
 State-Changed-By: rth
 State-Changed-When: Tue Apr  2 02:09:39 2002
 State-Changed-Why:
     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.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p
 r=3329