On 10/12/2013 19:47, Jim Grosbach wrote:> > On Dec 10, 2013, at 11:26 AM, Alp Toker <alp at nuanti.com > <mailto:alp at nuanti.com>> wrote: > >> >> On 10/12/2013 18:03, Jim Grosbach wrote: >>>> That causes dissonance between what the compiler sees and what >>>> lit.py sees for no particularly good reason. One of the nice >>>> properties of lit tests is that they're also valid compiler inputs, >>>> so trailing slash is a bit unfortunate. >>>> >>> >>> How does the backslash break this in any way? >> >> The backslash is interpreted by lit and the compiler in different and >> incompatible ways. > > I disagree that this is different or incompatible. > > In any case, you didn’t answer the more important of my two questions. > What compilers interpret this code differently?Hi Jim, There are lots of ways line continuations are interpreted differently between compilers and even different versions from the same vendor. This is inherent because each frontend has a different take on fundamental issues like where lines and comments begin and end, and even the semantics of what translation phases are vary between compilers. Here's one quick example of how compilers interpret this code differently: |*$* printf '//\\ \nint x=0;\nint x=0;' > f.c||| |||| |||*$* cat f.c||| |||//\ ||| |||int x=0;||| |||int x=0;||| |||| |||*$* clang -fsyntax-only f.c||| |||| |||*$* gcc-4.9 -fsyntax-only f.c||| |||| |||*$* cl f.c||| |||Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x64||| |||Copyright (C) Microsoft Corporation. All rights reserved.||| |||| ||*|f.c(3) : |**|error C2374|**|: 'x' : redefinition; multiple initialization|**||** **||**| f.c(2) : see declaration of 'x'|* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131210/307378f3/attachment.html>
On Dec 10, 2013, at 1:24 PM, Alp Toker <alp at nuanti.com> wrote:> > On 10/12/2013 19:47, Jim Grosbach wrote: >> >> On Dec 10, 2013, at 11:26 AM, Alp Toker <alp at nuanti.com> wrote: >> >>> >>> On 10/12/2013 18:03, Jim Grosbach wrote: >>>>> That causes dissonance between what the compiler sees and what lit.py sees for no particularly good reason. One of the nice properties of lit tests is that they're also valid compiler inputs, so trailing slash is a bit unfortunate. >>>>> >>>> >>>> How does the backslash break this in any way? >>> >>> The backslash is interpreted by lit and the compiler in different and incompatible ways. >> >> I disagree that this is different or incompatible. >> >> In any case, you didn’t answer the more important of my two questions. What compilers interpret this code differently? > > Hi Jim, > > There are lots of ways line continuations are interpreted differently between compilers and even different versions from the same vendor.\> > This is inherent because each frontend has a different take on fundamental issues like where lines and comments begin and end, and even the semantics of what translation phases are vary between compilers. >No, they really don’t, modulo bugs. This is standards compliance territory. If the compilers aren’t conformant implementations, I have zero sympathy.> Here's one quick example of how compilers interpret this code differently: > > $ printf '//\\ \nint x=0;\nint x=0;' > f.c > > $ cat f.c > //\ > int x=0; > int x=0; > > $ clang -fsyntax-only f.c > > $ gcc-4.9 -fsyntax-only f.c > > $ cl f.c > Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x64 > Copyright (C) Microsoft Corporation. All rights reserved. > > f.c(3) : error C2374: 'x' : redefinition; multiple initialization > f.c(2) : see declaration of 'x’That’s a bug in either MSVC or in whatever you’re using to get a bash prompt on windows. Probably line-ending related. It’s incorrectly not recognizing the continuation character at all. -Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131210/6c3e3583/attachment.html>
Caldarale, Charles R
2013-Dec-10 21:43 UTC
[LLVMdev] lit: deprecating trailing \ in RUN lines
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Alp Toker > Subject: Re: [LLVMdev] lit: deprecating trailing \ in RUN lines> //\ > int x=0; > int x=0;> $ gcc-4.9 -fsyntax-only f.cTry gcc with -Wall, and you'll see the appropriate warning. Also try the MS compiler after removing the trailing space after the backslash; I don't have one available to play with, so I don't know if it makes any difference. - Chuck
On 10/12/2013 21:43, Caldarale, Charles R wrote:>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Alp Toker >> Subject: Re: [LLVMdev] lit: deprecating trailing \ in RUN lines >> //\ >> int x=0; >> int x=0; >> $ gcc-4.9 -fsyntax-only f.c > Try gcc with -Wall, and you'll see the appropriate warning. Also try the MS compiler after removing the trailing space after the backslash; I don't have one available to play with, so I don't know if it makes any difference.Exactly. EDG and MSVC parse this one way, and gcc/clang do it another way depending on various factors like whitespace. It may be a bug like Jim says but to me the EDG/MSVC handling is closer to the spec. Not a big deal either way. For directives in a C/C++ test suite to rely on something contentious like trailing newlines that have a dual meaning depending on whether they're being parsed by the compiler or the testing tool is problematic though. Alp.> > - Chuck >-- http://www.nuanti.com the browser experts
On Dec 10, 2013, at 1:43 PM, Caldarale, Charles R <Chuck.Caldarale at unisys.com> wrote:>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Alp Toker >> Subject: Re: [LLVMdev] lit: deprecating trailing \ in RUN lines > >> //\ >> int x=0; >> int x=0; > >> $ gcc-4.9 -fsyntax-only f.c > > Try gcc with -Wall, and you'll see the appropriate warning. Also try the MS compiler after removing the trailing space after the backslash; I don't have one available to play with, so I don't know if it makes any difference.Doh. I missed the trailing space. That makes it a bit odd, to say the least. If we have any files with that construct in it, we should totally just run a regex over them to fix it. That’s just broken. This would also totally have been prevented if we had a post-commit hook to strip trailing whitespace. </trollchris>