[cfe-dev] Odd behaviour with '-save-temps' and OpenCL files

[mats petersson via cfe-dev]

On 7 November 2016 at 16:34, Martin J. O'Riordan <
martin.oriordan at movidius.com> wrote:

> @Martin: Have you tried to run `clang -v ...` to show the actual
> processing, and assuming it gives a sensible output, try to re-run the
> failing step (which I think is `cc1 ... filename.i`) with `-x cl`, and see
> if that resolves it?
>
>
>
> This is interesting.  So I used ‘-v’ and I see ‘-x cpp-output’ in the
> command-line - didn’t even know that value existed! - and if I replace it
> with ‘-x cl’ is works perfectly, so your hunch is spot-on.  But is also
> means that the ‘-x cpp-output’ option is determining source language
> based on the extension (‘.i’ or ‘.ii’).
>
>
>
>             MartinO
>

Good to know that at least SOMETIMES my "gut feel" points in the right
general direction.

I'm not sure what the best solution for actually solving the next step -
communicating the actual language. Using `.icl` or some such would work,
but my personal feeling is that this is a slipperly slope that just gets
worse and worse the more languages and flavours of languages that you want
to support... the #pragma solution may work, but it kind of requires the
preprocessor to add stuff to the output - I'm sure it does already, but I'm
not sure it's the right place either.

In short, I'm sure it can be resolved, I'm not sure what is the RIGHT WAY,
and I also don't know where in the code this should be done (for any of the
suggested solutions), or who would be the right person to discuss this.
Maybe Joerg has some ideas?

--
Mats

>
>
> *From:* mats.o.petersson at googlemail.com [mailto:mats.o.petersson@
> googlemail.com] *On Behalf Of *mats petersson
> *Sent:* 07 November 2016 15:30
> *To:* Martin J. O'Riordan <Martin.ORiordan at movidius.com>
> *Cc:* Joerg Sonnenberger <joerg at bec.de>; cfe-dev <cfe-dev at lists.llvm.org>
> *Subject:* Re: [cfe-dev] Odd behaviour with '-save-temps' and OpenCL files
>
>
>
> Assuming `#pragma clang language OpenCL` works, that seems like a neat
> thing that can be inserted as a "pre-include header" (as a constant string
> in the compiler). However, I'm not sure that clang does this in conjunction
> with the preprocessor as it is now - or that there is a simple way to
> achieve it - in which case, the other solution is to add some code to
> "remember" the language picked from the extension, and passing that to the
> parser step (cc1?) after preprocessing.
>
>
> --
>
> Mats
>
>
>
> On 7 November 2016 at 12:57, Martin J. O'Riordan <
> martin.oriordan at movidius.com> wrote:
>
> When the source is a C file, the pre-processed file has the extension ‘.i’,
> and when it is a C++ file the pre-processed file has the extension ‘.ii’.
> Perhaps CL files need a 3rd convention for naming the pre-processed file,
> and eventually something similar if the FORTRAN front-end is available?  I
> don’t compile CUDA files, and they may have a similar problem.
>
>
>
> Even passing ‘-x cl -c -save-temps’ does not solve it, so the knowledge
> that it is an OpenCL source appears to be lost.
>
>
>
>             MartinO
>
>
>
> *From:* cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] *On Behalf Of *mats
> petersson via cfe-dev
> *Sent:* 07 November 2016 10:56
> *To:* Joerg Sonnenberger <joerg at bec.de>; Clang Dev <cfe-dev at lists.llvm.org
> >
> *Subject:* Re: [cfe-dev] Odd behaviour with '-save-temps' and OpenCL files
>
>
>
> And how does the parser know from the preprocessed output that it is CL
> rather than C that it's parsing? I suspect it's the ".cl" part of the name
> of "filename.cl" that determines that it's CL code in the first place, if
> that gets replaced with "filename.i", the parser will just say "Ah, it's
> C-code and has already been preprocessed".
>
> Maybe the parser needs a `-x cl` or similar to ensure that the parser
> knows it's CL-code?
>
> I know that many of the CL parsing things have `if (langOpts.OpenCL) ...`
> in the parser and various other places. If we have a multi-pass way of
> running the compiler, it will potentially lose that information when it
> gets to the next step, is my thinking. I may of course be wrong, and the
> problem is with something else.
>
>
> --
>
> Mats
>
>
>
> On 6 November 2016 at 11:04, Joerg Sonnenberger via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> On Sun, Nov 06, 2016 at 10:01:05AM +0000, mats petersson via cfe-dev wrote:
> > My guess, and it's only a guess, is that -save-temps causes the compiler
> to
> > run each step on those files, by executing independent processes, rather
> > than the usual "run all steps in parallel" - in my understanding, Clang
> > doesn't actually work in the "old style cc way" and running several
> > processes with files produced between each step.
>
> Yes and no. -svae-temps will run the parser on the preprocessed output,
> so all macro-expansion knowledge is missing. That changes the impact of
> a number of warnings like redundant braces. Pragmas are still preserved
> in the code though. It would be a bug in the OpenCL integration if the
> pragmas are no longer processed OR if pragmas are silently attached to
> macros by position.
>
> Joerg
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161107/6cd00946/attachment.html>