dblaikie added a comment. (pulling this out from an inline comment, because it's hard to quote/smaller than it needs to be for more complex discussions):
> Oh, thanks for finding this. It is pretty bad that I didn't image we can > specify multiple input module units in one command line. > >> What if you specify multiple source files on the command line without -c? >> Without -o you get test1.pcm and test2.pcm, but with -o foo you get foo.pcm >> overwriting foo.pcm. Perhaps if the output file specified isn't a .o file, >> we should ignore the -o and use the input-filename based naming? I guess we >> could reject this situation outright, and require the user to run multiple >> separate compilations. Though keeping features composable is nice. > > Now the name of the module file will be the same with the input file no > matter if we specified -o or not. With -o specified, the module files will be > generated into the same directory with the output file. Without -o specified, > the module files will be generated in the working directory. It'll still be > problematic if the user specify two inputs with the same name in two > different directory, the module file of the latter will overwrite the former > one. But I guess we don't need to handle such cases? > >> For instance - how does this interact with Apple's multiarch support (eg: >> clang++ test.cppm -fmodule-output -arch i386 -arch x86_64 -target >> x86_64_apple_darwin) - from my testing, without specifying an output file, >> you get something semi-usable/not simply incorrect: test-i386.pcm and >> test-x86_64.pcm. But if you try to name the output file you get foo.pcm and >> then another foo.pcm that overwrites the previous one. I think this could be >> taken care of if the suffix handling code was delegated down towards the >> else block that starts with SmallString<128> Output(getDefaultImageName()); > > In the new implementation, I image we'll generate test-i386.pcm and > test-x86_64.pcm even if we specified -o with -fmodule-output. But the weird > thing is that when I tried to reproduce your example, the compiler told me > the other archs are ignored. I'm not sure if I set something wrong or I must > do it in Apple machine. > > BTW, I am not sure if I misunderstand you, but the else block that starts > with SmallString<128> Output(getDefaultImageName()); handles about IMAGE > types, which looks irreverent to me. >> how does this interact with Apple's multiarch support > > Good question. What does split dwarf do in this case? Are differently named > outputs generated or is a multi-arch dwarf file produced (assuming they > exist)? Split DWARF isn't supported on Darwin/MacOS/whatever it's called - the MachO debug info distribution model looks more like, but isn't quite, Split DWARF already (it keeps the debug info in .o files, doesn't link them into the final executable - and you can make a separate debug info archive with `dsymutil`). > Rejecting the command line if it specifies multiple -arch options with > -fmodule-output= seems fair to me (unless/until support for multi-arch .pcm > files is added). Yeah, trying to see if >> I'm not sure if I set something wrong or I must do it in Apple machine. > > I don't recall for sure, but I think Apple Clang is needed. We noticed > differences between community Clang and Apple Clang while I was at Coverity, > but I don't recall the details. I don't think this needs Apple Clang, but it does need a Darwin triple. I was reproducing/examining the behavior with `clang++ test.cppm -fmodule-output -arch i386 -arch x86_64 -### -target x86_64-apple-darwin`. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137058/new/ https://reviews.llvm.org/D137058 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
