Re: [PATCH] D17741: adds __FILE_BASENAME__ builtin macro

[Alex Rosenberg via cfe-commits]

alexr added a subscriber: alexr.
alexr added a comment.

There are multiple features in this patch that should be considered separately. 
Please split the patch.

That said, I don't think we want to add a fundamental new preprocessor feature 
like __FILE_BASENAME__ without at least getting some early buy-in from the WG14 
and WG21 committees. I suspect they’d not want to add to the preprocessor at 
all.

The flag concept seems much more tractable. Please split it into two flags, one 
to force __FILE__ to only be the basename, and one that handles the prefix 
stripping. That is, a magic value of __ALL_DIR__ seems like the wrong choice 
here.


http://reviews.llvm.org/D17741



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Alex Rosenberg via cfe-commits]

On Oct 15, 2015, at 2:20 PM, Adrian Prantl via cfe-commits 
 wrote:

>> 
>> On Oct 15, 2015, at 2:09 PM, Adrian Prantl via cfe-commits 
>>  wrote:
>> 
>>> 
>>> On Oct 15, 2015, at 1:42 PM, Richard Smith  wrote:
>>> 
>>> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  wrote:
>>> 
 On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
 
 Ack, there are non-modular headers in the Darwin module. =( I seem to 
 recall that they're not version-locked to your compiler, so we've got to 
 support them as-is?
 
 If we can't turn on local submodule visibility, then we need a module map 
 for libc++ that covers all of its headers. I'll look into pruning the 
 include path when building a module from an implicitly-loaded module map.
>>> 
>>> The attached patch implements this in the most hacky way; with it I can 
>>> successfully compile the first few hundred files of LLVM.
>>> 
>>> Great, it looks like this plan should work then. What failure do you 
>>> eventually hit? Does it look related to these  changes?
>> 
>> So far I fixed 250446  and 250459 which were both just missing include 
>> files. I’m puzzled by 250459 though, as there is nothing Darwin-specific 
>> about the change. I’ll keep iterating and will let you know if there are any 
>> libc++-related problems.
>> 
>>> 
>>> I'm working on a more refined version of the approach I described earlier; 
>>> I'll mail you a patch to test when I have it finished.
>> 
>> That sounds great.
>> 
>> thanks,
>> adrian
> 
> Here’s a weird one:
> 
> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: 'SROA' is 
> not a class, namespace, or enumeration
> bool SROA::runOnFunction(Function ) {
>  ^
> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: reference to 
> 'SROA' is ambiguous
> ../include/llvm/Transforms/Scalar/SROA.h:54:7: note: candidate found by name 
> lookup is 'llvm::SROA'
> class SROA {
>   ^
> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:63:10: note: candidate 
> found by name lookup is '(anonymous namespace)::SROA'
>   struct SROA : public FunctionPass {
>  ^
> 
> this doesn’t look Darwin-specific at all. Assuming that the Linux module 
> build works, why am I seeing this?

The Linux bot has the same problem: 
http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/7331/steps/compile.llvm.stage2/logs/stdio

++
| Alexander M. Rosenberg |
| Nobody cares what I say, so no disclaimer appears here.|

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13351: [Power PC] add soft float support for ppc32

[Alex Rosenberg via cfe-commits]

alexr added a subscriber: alexr.
alexr added a comment.

PowerPC has floating point hardware by definition. Is this some new variant?


http://reviews.llvm.org/D13351



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits