Richard, I've replaced this with a better test in r194249.
Please keep an eye on this, let's see if it works everywhere. Alp. On 08/11/2013 04:16, Alp Toker wrote: > On 07/11/2013 18:10, Richard Barton wrote: >> Hi all >> >> [Adding Alp - didn't realise he was missed off my original mail.] >> >> Looking at the code in lib/Parse/ParseStmt.cpp it looks as though this test >> can only be expected to pass when targeting x86 or x86_64. Any other >> architecture emits the "Unsupported architecture 'aarch64' for MS-style >> inline assembly" message. >> >> I'd like to XFAIL the test for all the other backends. I've committed the >> patch (r194211) Please holler if you disagree. > Hello Richard, thanks for CCing me in and for the XFAIL quick fix. > > Your suggestion to combine the two messages could be a good idea. > > Alternatively maybe we could move the err_msasm_unable_to_create_target > check before err_msasm_unsupported_arch, or maybe even remove > err_msasm_unsupported_arch completely and get the target ASM parser to > diagnose the condition? > > I haven't been able to try these out because c-index-test doesn't accept > a target triple as far as I can tell, so it's been difficult to work with. > > Open to suggestions here, and I've already got it on my long-term TODO > list to revisit this. > > Also the original reporter should file a bug regarding how to enable the > feature in libclang or it will be forgotten. I think that one is a > legitimate feature request. > > Alp. > > > >> Thanks, >> Rich >> >> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On >>> Behalf Of Richard Barton >>> Sent: 04 November 2013 15:25 >>> To: [email protected]; William Ledoux >>> Cc: [email protected] >>> Subject: Re: [cfe-dev] libclang crash when parsing MS-style inline >> assembly >>> Hi all >>> >>> Apologies in advance that I don't fully understand the technicalities of >> this area, >>> but could that regression test be made more robust? >>> >>> My clang build has LLVM_DEFAULT_TARGET=aarch64-none-eabi (Host is >>> x86_64-linux-gnueabi) and the error message that I get is slightly >> different >>> causing the test to fail: >>> >>> .../ms-asm-no-target.cpp:8:3: error: Unsupported architecture 'aarch64' >> for MS- >>> style inline assembly >>> >>> Again, I don't fully understand the area, but the test seems only to >> require that >>> an x86 backend is available. It doesn't account for cross-compiling or >> when the >>> default triple is not x86. If the test needs to be run on x86, shouldn't >> the >>> REQUIRES line be more strict? Alternatively, if my failure mode is equally >>> acceptable behaviour, could the two error messages be combined? >>> >>> Thanks, >>> Rich >>> >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] >>>> On Behalf Of [email protected] >>>> Sent: 30 October 2013 15:58 >>>> To: William Ledoux >>>> Cc: [email protected] >>>> Subject: Re: [cfe-dev] libclang crash when parsing MS-style inline >>> assembly >>>>> Hi Chad, >>>>> >>>>> So now I understand that there is no way to parse MS-style inline >>>>> assembly without a target asm parser. >>>>> But I still need to figure out if I can and how to tell libclang to >>>>> initialize a specific target. >>>> Unfortunately, I don't have an answer here. Perhaps Alp or another >>>> member >>> of >>>> the list has a solution. >>>> >>>>> On Wed, Oct 30, 2013 at 4:27 PM, <[email protected]> wrote: >>>>> >>>>>> Hi William, >>>>>> I can answer your second question. GCC style inline assembly does >>>>>> not require a target AsmParser. MS-style inline assembly requires >>>>>> a parser because this is how we discover the constraints. Hope >>>>>> this >>> helps. >>>>>> Chad >>>>>> >>>>>>> Hi Alp, >>>>>>> >>>>>>> Thanks for helping ! >>>>>>> >>>>>>> 1] Is there a way I could tell libclang which target to >>>>>>> initialize >>>>>> without >>>>>>> modifying it ? >>>>>>> 2] How does it work for gcc style assembly, is there a similar >>>>>>> error message or does it work without the need of any targets ? >>>>>>> 3] Since you decided to diagnose this, you might also want to >>>>>>> check >>>>>> the >>>>>>> case were the target have been initialized, but not the used >>>>>>> function pointers of this target >>>>>>> >>>>>>> William. >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 30, 2013 at 3:53 PM, Alp Toker <[email protected]> wrote: >>>>>>> >>>>>>>> Hello William, >>>>>>>> >>>>>>>> I've landed a fix in r193685 to diagnose this instead of crashing: >>>>>>>> >>>>>>>> clang/test/Index/ms-asm-no-target.cpp:8:3: error: MS-style >>>>>>>> inline assembly is not available: Unable to find target for this >>>>>>>> triple (no targets >>>>>> are >>>>>>>> registered) >>>>>>>> >>>>>>>> It's up to the embedder to decide what targets are linked in, so >>>>>>>> how >>>>>> the >>>>>>>> API exposes that is still an open question. >>>>>>>> >>>>>>>> Alp. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 30/10/2013 11:50, William Ledoux wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> The following minimal code that contain MS-style inline assembly >>>>>>>> will compile fine with clang, but libclang fails to parse it >>>>>>>> (clang_parseTranslationUnit will return NULL). >>>>>>>> >>>>>>>> void Break(){ __asm { int 3 } } >>>>>>>> >>>>>>>> In yesterday's llvm and clang sources, the problem occurs in >>>>>>>> ParseMicrosoftAsmStatement. >>>>>>>> In the code below, because no target have been registered, the >>>>>>>> first line will set TheTarget to NULL, and the second line will >>>>>>>> dereference TheTarget, thus causing the problem. >>>>>>>> >>>>>>>> const llvm::Target *TheTarget = >>>>>>>> llvm::TargetRegistry::lookupTarget(TT, >>>>>>>> Error); >>>>>>>> OwningPtr<llvm::MCRegisterInfo> >>>>>> MRI(TheTarget->createMCRegInfo(TT)); >>>>>>>> For what I understood, clang, in cc1_main, will initialize >>>>>>>> targets >>>>>> and >>>>>>>> targets' functions with the following 4 lines, whereas libclang >>>>>> won't. >>>>>>>> llvm::InitializeAllTargets(); >>>>>>>> llvm::InitializeAllTargetMCs(); >>>>>>>> llvm::InitializeAllAsmPrinters(); >>>>>>>> llvm::InitializeAllAsmParsers(); >>>>>>>> >>>>>>>> Just for testing purpose, adding those 4 lines somewhere in >>>>>>>> clang_createIndex fixes the problem. I know this is probably >>>>>>>> wrong, >>>>>> but >>>>>>>> did >>>>>>>> it just to see if more problems were hiding behind. >>>>>>>> >>>>>>>> So my questions are: >>>>>>>> 1] Is it wanted that libclang doesn't initialize any target ? >>>>>>>> 2] if yes, how shloud it behave with MS inline assembly ? >>>>>>>> 3] if no, what is the proper way to make it initialize targets ? >>>>>>>> >>>>>>>> Many thanks for you work ! >>>>>>>> William >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> View this message in context: >>>>>>>> >>>>>> http://clang-developers.42468.n3.nabble.com/libclang-crash-when-par >>>>>> si ng-MS-style-inline-assembly-tp4035432.html >>>>>>>> Sent from the Clang Developers mailing list archive at Nabble.com. >>>>>>>> _______________________________________________ >>>>>>>> cfe-dev mailing >>>>>>>> [email protected]:// >>>>>> lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >>>>>>>> -- http://www.nuanti.com >>>>>>>> the browser experts >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> cfe-dev mailing list >>>>>>> [email protected] >>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >>>>>>> >>>>>> >>>> _______________________________________________ >>>> cfe-dev mailing list >>>> [email protected] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >>> >>> >>> _______________________________________________ >>> cfe-dev mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >> -- http://www.nuanti.com the browser experts _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
