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

[mats petersson via cfe-dev]

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/c2acbecd/attachment.html>