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

[Bill Schmidt]

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.

Thanks,
Bill

> 
> 
> -Eli 
> 
>