[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

["pinskia at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-05-10 15:06 -------
(In reply to comment #5)
> To A Pinski
> While I am _not_ a C lawyer, the following seems pertinent:
Why do you think this is related to the C standard?

> 
> 1 __FUNCTION__  is _not_ a predefined macro. However __func__ a predefined
> identifier and I will take this up with the kernel people. However, even
> changing__FUNCTION__ to __func__ still produces an error. Let the language
> lawyer sort this out.

So what?


> 2 Taking __FUNCTION__ entirely out of the original Macro Definition and using
> all of the kernel paraphernalia produces valid code. Out of that context I can
> not get even __FILE__ to work properly; only __line__
> 
> 3 Your "Hi" misses the point  because it is certainly not a predefined macro
> and not even a predefined identifier. Therefore the comparison seems invalid to
> me.

HUH?  Look at how __FILE__ gets subsituted.
> 
> I am reopening this because I believe that the raised by "__func__" should be
> addressed. Also it is not the first time that the kernel people found ways to
> get GCC closer to the standards.

__func__ is a static variable and that is how the C standard defines it.  It
will be put into the section anchor.
You will also have issues with:

static int t;

void f(void)
{
  asm ("" : : "I"(&t));
}

=====
But all of that is undefined as explained by how the documentation is defined.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|dje at gcc dot gnu dot org  |
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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