- User Since
- Jul 12 2012, 2:19 PM (374 w, 5 d)
Mon, Sep 16
Thu, Sep 12
This patch doesn't work, and the ARM NEON intrinsic header emitter is too opaque and mysterious for me to be able to fix this, and it's not even clear that the generator knows what the actual parameter types of the compiler builtins are. For now I think the best I can do is to leave ARM targets with lax vector conversions enabled, and disable it for all the other targets. :-(
Seems very surprising to me that the gnu_inline attribute has different behavior in their C and C++ frontends. That said, it looks like it's a behavior that they document; their documentation says "In C++, this attribute does not depend on extern in any way, but it still requires the inline keyword to enable its special behavior." and that matches their observed behavior. And they behave this way even for functions in extern "C" blocks. The question for us, then, is do we want to be compatible with C source code built as C++ (that is, the status quo) and C++ source code using this attribute and targeting older versions of Clang, or with g++?
Tue, Sep 10
Just one thing I missed before, otherwise this looks good. Thanks!
Mon, Sep 9
Sun, Sep 8
Fri, Sep 6
Wed, Sep 4
Tue, Sep 3
Mon, Sep 2
Fri, Aug 30
Thu, Aug 29
I'm taking this over to finish it off and submit.
LGTM: while this isn't a solution to the root cause of the issues here, it puts us in a better situation than the status quo.
Tue, Aug 27
Do we need KnownModules at all? It seems to serve a very similar purpose to the Modules string map on ModuleMap. (The main difference seems to be that KnownModules can cache module load failures.) If we can keep only a single data structure tracking this, owned by the ModuleMap (which also owns the modules), that should remove the possibility for dangling module pointers.
This isn't the right approach: instead of re-instantiating the parameter when we encounter a use of it, we should inject the parameters into the local instantiation scope before trying to instantiate a default argument (Sema::CheckCXXDefaultArgExpr should call addInstantiatedParametersToScope to populate the LocalInstantiationScope before calling SubstInitializer).
Mon, Aug 26
I think we're past the point of large-scale structural comments that are better addressed before the first commit, and it'd be much better to make incremental improvements from here.
Fri, Aug 23
Thu, Aug 22
This seems subtle, but I believe it is correct.
Wed, Aug 21
- Address review comments from Aaron.
Ping. Is there any interest in pursuing this, or is the preprocessor complexity too great?
The ALPHA_OFFSET code seems to be unnecessarily "clever" to me. I think the warning can be suppressed by reversing the operands:
Mon, Aug 19
Aug 16 2019
_Thread_local is a reserved identifier; we generally don't produce extension warnings for uses of reserved identifiers. (Eg, there's no warning for _Atomic in C++ or _Bool in C89, and no warning for uses of __type_traits or __builtins.)
- Disable stack exhaustion test if threads are disabled.
- Review feedback: use _AddressOfReturnAddress with MSVC, and simplify
Aug 15 2019
LGTM with minor adjustments to the test.
Aug 14 2019
Aug 13 2019
Aug 12 2019
I would like to better understand the big picture for descriptors, pointers, and so on. I'm not yet seeing how the pieces are going to fit together and not frequently require expensive operations. For example, pointer arithmetic requires determining the array bound of the pointee; pointer subtraction requires determining whether two pointers point into the same array; pointer comparisons require determining the divergence point in the access paths between two pointers. These path-based operations were easy in the old representation, and seem to be difficult in the new representation, so I want to make sure that they've been properly considered. It's also not clear to me how you'll model pointers that have lost their designator (through constant folding), where you have a runtime offset but no compile-time offset, or pointers that point to objects whose values are not part of the evaluation (for example, extern globals), or pointers that have a designator but no base (for __builtin_object_size handling).