On Tue, Aug 9, 2016 at 9:18 AM, Serge Pavlov wrote:
> Whether enable this warning or not should be determined by user feedback.
> The warning was implemented to help users in complicated cases that arise
> in module-enabled builds. It seems however that it makes troubles for other
> users. Based
Whether enable this warning or not should be determined by user feedback.
The warning was implemented to help users in complicated cases that arise
in module-enabled builds. It seems however that it makes troubles for other
users. Based on feedback on this list I feel that it is better to make this
With 3.9 coming around, I'd like to suggest that we pull this warning from
3.9 and maybe trunk. It sounds like Sean found it only possible to deploy
this warning since they already had a workaround for a different compiler
bug (!). In Chromium, we can't enable this warning since one of our
(admitte
On Thu, May 19, 2016 at 12:13 PM, Serge Pavlov wrote:
> In this case moving implementation of `Singleton::getInstance()` into a
> .cpp file would prevent compiler from instantiation of the method body when
> it sees `Singleton::getInstance()`. In this case
> `Singleton::getInstance()` must be ins
In this case moving implementation of `Singleton::getInstance()` into a
.cpp file would prevent compiler from instantiation of the method body when
it sees `Singleton::getInstance()`. In this case
`Singleton::getInstance()` must be instantiated in some source file
either explicitly or implicitly. I
On Thu, Apr 21, 2016 at 12:44 AM, Serge Pavlov wrote:
> Let me demonstrate the problem using excerpt from v8 sources:
>
> -- lithium.h
> template
> struct LSubKindOperand {
> static int* Create(int index) { return &cache[index]; }
> st
Let me demonstrate the problem using excerpt from v8 sources:
-- lithium.h
template
struct LSubKindOperand {
static int* Create(int index) { return &cache[index]; }
static void SetUpCache();
static int* cache;
};
struct LOperand {
On Tue, Apr 19, 2016 at 7:28 AM, Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> (sorry, accidentally sent this mid-mail)
>
> ../../v8/src/crankshaft/lithium.h:322:45: error: instantiation of variable
> 'v8::internal::LSubKindOperand 128>::cache' required here, but no definition
On Tue, Apr 19, 2016 at 7:28 AM, Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> (sorry, accidentally sent this mid-mail)
>
> ../../v8/src/crankshaft/lithium.h:322:45: error: instantiation of variable
> 'v8::internal::LSubKindOperand 128>::cache' required here, but no definition
Hi Nico,
This message indicates that compiler sees a reference to static member
'cache' of some specialization of template 'LSubKindOperand' (namely
'LSubKindOperand').
This is a static member, so compiler needs corresponding template
definition to instantiate it, but there is no such in the file
(sorry, accidentally sent this mid-mail)
../../v8/src/crankshaft/lithium.h:322:45: error: instantiation of variable
'v8::internal::LSubKindOperand::cache' required here, but no definition is available
[-Werror,-Wundefined-var-template]
if (index < kNumCachedOperands) return &cache[index];
Hi Serge,
this complains on this snippet from v8:
template
class LSubKindOperand final : public LOperand {
public:
static LSubKindOperand* Create(int index, Zone* zone) {
if (index < kNumCachedOperands) return &cache[index];
return new(zone) LSubKindOperand(index);
}
private:
sta
12 matches
Mail list logo
