public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* 2.6.14-rt13 / minimum gcc  version
@ 2005-11-22 23:19 Darren Hart
  2005-11-23  8:32 ` Ingo Molnar
  0 siblings, 1 reply; 2+ messages in thread
From: Darren Hart @ 2005-11-22 23:19 UTC (permalink / raw)
  To: lkml, ; +Cc: Ingo Molnar

rt13 makes use of the gcc extension:
	int __builtin_types_compatible_p (type1, type2)
which from what I can tell was first introduced to gcc in version 3.1.1
	http://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/Other-Builtins.html

In any case, I am unable to compile rt13 with gcc-2.95.  I have tried various 
-std args as well, but the compiler dies on __builtin_types_compatible_p.

1) Is it acceptable to require >= gcc-3.1.1 to compile a Linux kernel?

2) Would a patch/work-around for gcc-2.95 compatibility be accepted if I provide 
one?  (assuming it is a sane implementation of course :-)

Thanks,


-- 
Darren Hart
IBM Linux Technology Center
Linux Kernel Team

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: 2.6.14-rt13 / minimum gcc  version
  2005-11-22 23:19 2.6.14-rt13 / minimum gcc version Darren Hart
@ 2005-11-23  8:32 ` Ingo Molnar
  0 siblings, 0 replies; 2+ messages in thread
From: Ingo Molnar @ 2005-11-23  8:32 UTC (permalink / raw)
  To: Darren Hart; +Cc: lkml, 


* Darren Hart <dvhltc@us.ibm.com> wrote:

> rt13 makes use of the gcc extension:
> 	int __builtin_types_compatible_p (type1, type2)
> which from what I can tell was first introduced to gcc in version 3.1.1
> 	http://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/Other-Builtins.html
> 
> In any case, I am unable to compile rt13 with gcc-2.95.  I have tried 
> various -std args as well, but the compiler dies on 
> __builtin_types_compatible_p.
> 
> 1) Is it acceptable to require >= gcc-3.1.1 to compile a Linux kernel?
> 
> 2) Would a patch/work-around for gcc-2.95 compatibility be accepted if 
> I provide one?  (assuming it is a sane implementation of course :-)

sure, i'll accept any sane patch. (quirky ones are OK too, as long as 
the effects are localized into an include file or so.)

but the type comparison feature is really essential to PREEMPT_RT. So 
unless gcc 2.95 has a comparable feature, i doubt it's doable.  

background: PREEMPT_RT relies on being able to implement build-time, 
"lock type dependent" function calls. I.e. 'down()' done on a semaphore 
will be built with a different function call than down() done on a 
compat semaphore. Or spin_lock() done on a raw spinlock leads to a 
different function call than spin_lock() done on a 'normal' spinlock.  
This solution implements a feature in C that is normally only found in 
object-oriented languages. It is an essential trick, as it reduces the 
size and impact of the -rt tree very significantly.

A completely type-unsafe (i.e. void * APIs with some runtime checking) 
solution is not acceptable - nor are separate per-type API namespaces.  
(such as compat_down(), etc.)

	Ingo

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-11-23  8:32 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-22 23:19 2.6.14-rt13 / minimum gcc version Darren Hart
2005-11-23  8:32 ` Ingo Molnar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox