Re: [cfe-users] Linking problem with implicit instantiation of constructor/destructor

[Richard Smith via cfe-users]

In the latest draft, this is [temp.pre]/10:

"""
A definition of a function template, member function of a class template,
variable template, or static data member of a class template shall be
reachable from the end of every definition domain (6.3) in which it is
implicitly instantiated (13.9.1) unless the corresponding specialization is
explicitly instantiated (13.9.2) in some translation unit; no diagnostic is
required.
"""

... which might be slightly easier to read in the pre-C++20 version
(without the modules-awareness), where it is [temp]/7:

"""
A function template, member function of a class template, variable
template, or static data member of a class template shall be defined in
every translation unit in which it is implicitly instantiated unless the
corresponding specialization is explicitly instantiated in some translation
unit; no diagnostic is required.
"""

On Sun, 19 Apr 2020 at 12:00, David Blaikie  wrote:

> Yeah, can't seem to divine the concrete wording here either - perhaps
> Richard will have a moment to chime in.
>
> On Sun, Apr 19, 2020 at 6:10 AM Jaroslav Zeman via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
>> >
>> > What happens if you change the order of the .cpp files, putting
>> > template.cpp first; is it stil unresolved?
>> >
>> > clang++ -o test template.cpp main.cpp
>>
>> The order doesn't matter.
>>
>> > I don't believe this code is valid according to C++. I believe it would
>> > require an explicit instantiation of the ctor/dtor somewhere to make
>> that
>> > code valid - though I don't have chapter and verse on the spec at hand
>> just
>> > now to back that up.
>>
>> I tried to read the c++ specs, but didn't find anything, that would
>> clearly
>> state, if this is correct or incorrect. But the specs are too complicated
>> for
>> me to understand.
>>
>> My opinion is that it is bad to rely on implicit instantiation to happen
>> somewhere and don't do the explicit one. So I've already fixed all these
>> problems in our code and now I am just curious, what others think about
>> it.
>>
>> JZ.
>>
>>
>>
>> ___
>> cfe-users mailing list
>> cfe-users@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

[cfe-users] Why clang doesn't generate fmla instruction for vmlaq_f32 intrinsics for armv8-a?

[Liang Jian via cfe-users]

I use clang9 to build code which has many arm64 intrinsics. I
use vmlaq_f32 to perform multiply accumulate operations on float32x4_t data
type. I have expected fmla instruction will be generated but instead clang
generate a fmul and a fadd instruction for me. For simple function this is
not an issue but for function which use a lot of neon registers clang9 will
generate inefficient code which will store/load neon register to/from stack
frequently. But if clang generate  fmla instruction 32 neon register is
more than enough.
BTW: I have tested a function which use  vmlaq_f32 heavily, If I build
it for armv7-a it will generate very  efficient code(it will generate vmla
instruction in this case), but if I build it for armv8-a the generated code
looks very inefficient with many store/load to/from stack.
Is there a way to force clang9 generate  fmla  instruction for
vmlaq_f32? Thanks.
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users