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.k...@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 bk...@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)";
> };
trad_cpp_fixincludes_03.patch
Description: Binary data
