public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 14:06 Araneda, Dorian
0 siblings, 0 replies; 20+ messages in thread
From: Araneda, Dorian @ 2002-04-02 14:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 16:16 Araneda, Dorian
0 siblings, 0 replies; 20+ messages in thread
From: Araneda, Dorian @ 2002-04-02 16:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
----------
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 15:46 Daniel Berlin
0 siblings, 0 replies; 20+ messages in thread
From: Daniel Berlin @ 2002-04-02 15:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 15:26 Araneda, Dorian
0 siblings, 0 replies; 20+ messages in thread
From: Araneda, Dorian @ 2002-04-02 15:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 14:56 Karl Günter Wünsch
0 siblings, 0 replies; 20+ messages in thread
From: Karl Günter Wünsch @ 2002-04-02 14:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
[-- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 14:46 Daniel Berlin
0 siblings, 0 replies; 20+ messages in thread
From: Daniel Berlin @ 2002-04-02 14:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 14:46 Richard Henderson
0 siblings, 0 replies; 20+ messages in thread
From: Richard Henderson @ 2002-04-02 14:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 14:46 Richard Henderson
0 siblings, 0 replies; 20+ messages in thread
From: Richard Henderson @ 2002-04-02 14:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 14:36 Araneda, Dorian
0 siblings, 0 replies; 20+ messages in thread
From: Araneda, Dorian @ 2002-04-02 14:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 14:36 Araneda, Dorian
0 siblings, 0 replies; 20+ messages in thread
From: Araneda, Dorian @ 2002-04-02 14:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 14:06 Richard Henderson
0 siblings, 0 replies; 20+ messages in thread
From: Richard Henderson @ 2002-04-02 14:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 13:46 Araneda, Dorian
0 siblings, 0 replies; 20+ messages in thread
From: Araneda, Dorian @ 2002-04-02 13:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 13:26 Araneda, Dorian
0 siblings, 0 replies; 20+ messages in thread
From: Araneda, Dorian @ 2002-04-02 13:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 13:26 Joseph S. Myers
0 siblings, 0 replies; 20+ messages in thread
From: Joseph S. Myers @ 2002-04-02 13:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 12:16 Richard Henderson
0 siblings, 0 replies; 20+ messages in thread
From: Richard Henderson @ 2002-04-02 12:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 12:16 Neil Booth
0 siblings, 0 replies; 20+ messages in thread
From: Neil Booth @ 2002-04-02 12:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 11:56 Andrew Pinski
0 siblings, 0 replies; 20+ messages in thread
From: Andrew Pinski @ 2002-04-02 11:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 11:36 Araneda, Dorian
0 siblings, 0 replies; 20+ messages in thread
From: Araneda, Dorian @ 2002-04-02 11:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 10:26 Richard Henderson
0 siblings, 0 replies; 20+ messages in thread
From: Richard Henderson @ 2002-04-02 10:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
@ 2002-04-02 10:06 Araneda, Dorian
0 siblings, 0 replies; 20+ messages in thread
From: Araneda, Dorian @ 2002-04-02 10:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2002-04-03 0:16 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-02 14:06 optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge Araneda, Dorian
-- strict thread matches above, loose matches on Subject: below --
2002-04-02 16:16 Araneda, Dorian
2002-04-02 15:46 Daniel Berlin
2002-04-02 15:26 Araneda, Dorian
2002-04-02 14:56 Karl Günter Wünsch
2002-04-02 14:46 Richard Henderson
2002-04-02 14:46 Richard Henderson
2002-04-02 14:46 Daniel Berlin
2002-04-02 14:36 Araneda, Dorian
2002-04-02 14:36 Araneda, Dorian
2002-04-02 14:06 Richard Henderson
2002-04-02 13:46 Araneda, Dorian
2002-04-02 13:26 Joseph S. Myers
2002-04-02 13:26 Araneda, Dorian
2002-04-02 12:16 Neil Booth
2002-04-02 12:16 Richard Henderson
2002-04-02 11:56 Andrew Pinski
2002-04-02 11:36 Araneda, Dorian
2002-04-02 10:26 Richard Henderson
2002-04-02 10:06 Araneda, Dorian
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).