This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
- From: "Araneda, Dorian" <dorian dot araneda at intel dot com>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 2 Apr 2002 19:36:01 -0000
- Subject: RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
- Reply-to: "Araneda, Dorian" <dorian dot araneda at intel dot com>
The following reply was made to PR optimization/3329; it has been noted by GNATS.
From: "Araneda, Dorian" <dorian.araneda@intel.com>
To: "'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~