fixincludes 2013-05-23

[Alexander Ivchenko]

Hi Bruce,

That was my original letter:
>Hi,
>
>Could you please take a look at the attached fixinclude patch
>that addresses the problem:
>
>"  We have test fail for gcc.dg/cpp/trad/include.c on Android. The
>reason for that is that
>-ftraditional-cpp is not expected to work on Android due to variadic
>macro (like #define __builtin_warning(x, y...))
>in standard headers and traditional preprocessor cannot handle them."
>
>is it ok for trunk?
>
>thanks,
>Alexander

So I did ask whether it is ok or not. And then I got:

> Be sure to ask, Ok? in your patch submittals.
>
> Ok.

>From Mike Stump, which was pretty misleading. Anyway, I had to
double-check the real
maintainer of fixincludes and I'm sorry that I didn't do that.

I'm happily addressing your complaints. I've changed the name of the
fix and have put it on the correct place (also had to change the place
of obstack_lvalue_cast - it was not alphabetically correct).

is the attached patch ok? All fixinclude tests pass.

best regards,
Alexander


2013/7/6 Bruce Korb <bruce.korb@gmail.com>:
>> Alexander Ivchenko Mon, 29 Apr 2013 23:24:55 -0700
>>
>> 2013/4/29 Mike Stump <mikest...@comcast.net>:
>>>
>>> On Jan 9, 2013, at 7:14 AM, Alexander Ivchenko <aivch...@gmail.com>
>>> wrote:
>>>>
>>>>  We have test fail for gcc.dg/cpp/trad/include.c on Android. The
>>>> reason for that is that
>>>> -ftraditional-cpp is not expected to work on Android due to variadic
>>>> macro (like #define __builtin_warning(x, y...))
>>>> in standard headers and traditional preprocessor cannot handle them.
>>>>  The attached patch disables that test.
>>>
>>>
>>> Be sure to ask, Ok? in your patch submittals.
>>>
>>> Ok.
>>
>>
>> thank you! I thought I did ask..
>>
>>> ...
>>> in standard headers and traditional preprocessor cannot handle them."
>>>
>>> is it ok for trunk?
>>
>>
>> could someone commit that patch please? I don't have commit access.
>
>
> Actually, Alexander, you did not ask.  And Kirill, you didn't verify
> before applying the patch.  Patches to fixincludes are generally safe,
> but it is protocol to ask.  Also, I prefer that the hacks get inserted
> alphabetically.  So, actually, there are a few small complaints.
>
>> $ fgrep -i fixincludes ../MAINTAINERS
>> fixincludes             Bruce Korb              bkorb@gnu.org
>
>
> The patch looks pretty reasonable, but I think someone else
> should verify the obsolescence.  I also think it should be renamed to
> something like "obsolete_builtin_warning" because the current
> name gives no clue about what it really is.
>
> /*
>  *  Old Linux kernel's <compiler.h> header breaks Traditional CPP
>  */
> fix = {
>     hackname  = complier_h_tradcpp;
>     files     = linux/compiler.h;
>
>     select    = "#define __builtin_warning\\(x, y\\.\\.\\.\\) \\(1\\)";
>     c_fix     = format;
>     c_fix_arg = "/* __builtin_warning(x, y...) is obsolete */";
>
>     test_text = "#define __builtin_warning(x, y...) (1)";
> };
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trad_cpp_fixincludes_03.patch
Type: application/octet-stream
Size: 12078 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20130708/8a8e3d80/attachment.obj>