This is the mail archive of the
gcc-bugs@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: "'Daniel Berlin'" <dan at dberlin dot org>
- Cc: "'Richard Henderson'" <rth at redhat dot com>, "'Andrew Pinski'"<pinskia at physics dot uc dot edu>, "'rth at gcc dot gnu dot org'" <rth at gcc dot gnu dot org>, "'gcc-bugs at gcc dot gnu dot org'" <gcc-bugs at gcc dot gnu dot org>, "'gcc-prs at gcc dot gnu dot org'"<gcc-prs at gcc dot gnu dot org>, "'nobody at gcc dot gnu dot org'" <nobody at gcc dot gnu dot org>, "'gcc-gnats at gcc dot gnu dot org'" <gcc-gnats at gcc dot gnu dot org>
- Date: Tue, 2 Apr 2002 15:20:50 -0800
- Subject: RE: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
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~