[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code

["malitzke at metronets dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #11 from malitzke at metronets dot com  2006-06-15 03:03 -------
Hans-Peter!

Thanks for shedding _some_ light on this murky corner. Perhaps, the "i"
constraint is now really inapropriate. 

First of all, a kernel header appropriately replaces __FUNCTION__ with
__func__. Therefore the leftover __FUNCTION__ (probably from non GCC compilers)
is not an issue.
Second, __LINE__, __FILE__, and __func__ are all known to the compiler, because
the compiler definitely knows what __FILE__ it is compiling and just emits the
appropriate string. Same argument line pertains to the __LINE__ in the __FILE__
and the name of the __func__ (function) it is trying to compile. The whole idea
is akin to an "assert". Therefore it is not up to the linker or assembler.
Third, if putting __FILE__ in place of the of either __FUNCTION__ or __func__
it works fine as can be seen in the "-S option" output (e.g. file.s).
Fourth, and this might be mine and others misunderstanding, I had thought that
"i" really referred to the assembly file address of the string. This address,
naturally is an address subject to relocation by the linker.
To an _old_ assembly language programmer this appears just like a storm in a
waterglass. This particular __asm construct is only used for powerpc (and
perhaps ppc) It must be left as a holdover for the original AIX compiler or AIX
binutils.

In my bugzilla PR to kernel.org I pointed out that knowing the __FILE__ and
__LINE__ is really quite sufficient and that perhaps, according to my patch to  
asm-powerpc/bug.h the particular item could be dropped. See bugzilla.kernel.org
PR 6533. They have not taken it up as it only pertains to gcc-4.2.0
(experimental) 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528