> I'm very wary of that approach. Surely the use case for inline assembly, > almost by *definition*, is that we're doing something that the compiler > doesn't understand and/or doesn't get right. > > We don't want it looking inside and thinking it knows best, even in the > case where it *is* going to see instructions that it actually knows > about. Perhaps *especially* in that case. > > But I suppose the specific case you mention, of checking constraints, > could have some merit. Even if the compiler takes a strictly "hands-off" > approach and doesn't screw with the output in any way, it could still > *see* that it's using instructions which clobber certain registers, and > then give a warning if those clobbers are missing. > > But unless it's actually *using* the integrated assembler, if it can't > parse what's in the inline asm, the failure mode should be that it just > does nothing and doesn't manage to emit any such warnings. > > It certainly shouldn't bail out with an error, which is the subject of > bug 18891.
OK, this is going a bit off topic for this code review. What this patch does is disable the integrated assembler completely when -no-integrated-as is given. Both for -S and -c. I think you agree that that is the correct behavior. Another possible change would be for the driver to make -S imply -no-integrated assembler. That is far more contentious and should have a code review of its own. Cheers, Rafael _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
