current CVS version 'miscompiles' Linux kernel modules [1/2]

[Martin v. Loewis]

> If I compile the modules for 2.3.47, I get unresolved external references to
> memcpy in some of them. This shouldn't happen, as the files in question do
> include linux/string.h and thus get inline versions of __memcpy and suitable
> defines. I've singled out one of the files. If I compile this with egcs
> 1.1.2 or gcc 2.95.2 everything is OK, compiled with current CVS
> 'nm --undefined-only' shows memcpy as external reference.
> 
> The preprocessed versions done by egcs 1.1.2 is attached here, the one
> preprocessed by 2.96 follows in the next messages.
> 
> Could someone please have a look as to what the reason might be? I can only
> guess that it's because of the string ops optimizations added lately.

Thanks for your bug report. I'm not certain this is a bug in gcc: It
happens in the call

  isdn_net_find_icall(di, c->arg, i, c->parm.setup))

where parm.setup is of type

typedef struct setup_parm {
    unsigned char phone[32];	 
    unsigned char eazmsn[32];	 
    unsigned char si1;       
    unsigned char si2;       
    unsigned char plan;      
    unsigned char screen;    
} setup_parm;

Since this is a call-by-value, gcc has to copy the setup_parm onto the
stack. Since it is too large for MOVE_RATIO, gcc emits a library call,
instead of inlining the move instructions. The intention apparently is
that the library code will do a better job in moving such a large
piece of memory than the gcc inlining.

Apparently, there is no way of turning of the library call - that may
be a bug.

OTOH, I think that the ISDN driver has by-value 64 byte parameters is
also a bug.

Regards,
Martin