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


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

Re: kernel-2.2.1-undefined references.



> And no, very few others are complaining, because the breakage only
> happened when you used two gcc extensions together ("inline" and address
> of a label). Linux is probably the only thing that actually uses a lot of
> the extensions. 

Unfortunately, this makes it more likely that the egcs development will
occasionally break Linux; we just don't have that many test cases for
interaction between gcc extensions.  When these are encountered we'll
just have to fix them.

I think that it's perfectly reasonable to ask that the change that broke
this be reverted enough so that you can get the function in question
inlined again, and I'm sure that folks like Jeff are eager to assist you
with just that.  I only hope that in the future it can be handled without
so many insults.  The change in question was not "for no good reason", it
was an attempt to decrease the virtual memory consumption of gcc (I don't
know how much it helped).  If the change has limited value and harms the
Linux kernel, that may be a good reason to revert the change.  It has not
gone into a release, only a snapshot.

In the future if a change to a snapshot breaks Linux, please report it as
a bug, and I'm sure it will be treated as high priority.  To avoid another
round of flamage, it's best to indicate clearly that the code relies on
GNU extensions, so that the (rather large) group of people whose main
interest is a good compiler for conforming code won't get bent out of
shape and fill the list with "but the standard doesn't guarantee that
you can do that" mailings.







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