r185544 - Fix PR16454: Don't #include altivec.h when preprocessing assembly.

[Richard Smith]

On Wed, Jul 3, 2013 at 10:31 AM, Bill Schmidt
<wschmidt at linux.vnet.ibm.com> wrote:
> On Wed, 2013-07-03 at 10:19 -0700, Eli Friedman wrote:
>> On Wed, Jul 3, 2013 at 8:36 AM, Bill Schmidt
>> <wschmidt at linux.vnet.ibm.com> wrote:
>>         Author: wschmidt
>>         Date: Wed Jul  3 10:36:02 2013
>>         New Revision: 185544
>>
>>         URL: http://llvm.org/viewvc/llvm-project?rev=185544&view=rev
>>         Log:
>>         Fix PR16454: Don't #include altivec.h when preprocessing
>>         assembly.
>>
>>         When the -maltivec flag is present, altivec.h is auto-included
>>         for the
>>         compilation.  This is not appropriate when the job action is
>>         to
>>         preprocess a file containing assembly code.  So don't do that.
>>
>>         I was unable to convert the test in the bug report into a
>>         regression
>>         test.  The original symptom was exposed with:
>>
>>           % touch x.S
>>           % ./bin/clang -target powerpc64-unknown-linux-gnu -maltivec
>>         -S -o - x.S
>>
>>         I tried this test (and numerous variants) on a PPC64 system:
>>
>>         ----------------------------------------------------------------------------
>>         // RUN: touch %t
>>         // RUN: %clang -maltivec -S %t -o - | FileCheck %s
>>
>>         // Verify that assembling an empty file does not auto-include
>>         altivec.h.
>>
>>         // CHECK-NOT: static vector
>>         ----------------------------------------------------------------------------
>>
>>         However, this test passes for some reason even on a clang
>>         built
>>         without the fix.  I'd be happy to add a test case but at this
>>         point
>>         I'm not able to figure one out, and I don't want to hold up
>>         the patch
>>         unnecessarily.  Please let me know if you have ideas.
>>
>>
>> Umm, why are you committing a patch for an issue you can't reproduce?
>
> Sorry if I was unclear.  I can reproduce the issue by hand.  I can't
> find a way to automate the process successfully using FileCheck.  I
> don't know why it doesn't work as a test case when it works from the
> command line.  No doubt there is some small thing about the automatic
> testing process that I don't understand.
>
> I had posted this potential solution a couple of days ago in the bug,
> and asked for assistance with the test case.  After no response, I
> decided to go ahead with the patch and add a test case later if I can
> get some help in understanding why it doesn't work.

So... comments in bugs don't get attention from people who aren't
CC'd; even people subscribed to the llvmbugs@ list only see when bugs
are created and closed, not comments added to them. In future, please
send patches for which you want review or comments to cfe-commits@
(even if they're incomplete); you're vastly more likely to get a
response there. Also, as a general rule, please don't interpret a lack
of response as a signal to go ahead, the expectation within the
community is that you will ping a patch if you don't get an answer to
your initial mail (around once a week is typical).