Closed Bug 783505 Opened 8 years ago Closed 8 years ago

OS X gcc builds failing with "jstypedarray.cpp:1427: error: template parameter 'ValueGetter' of type 'JS::Value (*)(JSObject*)' is not allowed in an integral constant expression because it is not of integral or enumeration type"

Categories

(Core :: JavaScript Engine, defect, major)

x86_64
macOS
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: emorley, Assigned: espindola)

References

Details

Attachments

(1 file)

Latest birch (where we ensure OS X still builds with gcc, now that trunk has switched to clang) merge is failing with:

{
../../../../js/src/jstypedarray.cpp:1427: error: template parameter 'ValueGetter' of type 'JS::Value (*)(JSObject*)' is not allowed in an integral constant expression because it is not of integral or enumeration type
}

https://hg.mozilla.org/projects/birch/pushloghtml?startID=117&endID=118

-> bug 777174
Also:
B2G macosx64_gecko mozilla-central nightly
https://tbpl.mozilla.org/php/getParsedLog.php?id=14463451&tree=Firefox

{
/builds/slave/m-cen-osx64-gecko-ntly/build/js/src/jstypedarray.cpp: In static member function 'static JSBool TypedArrayTemplate<NativeType>::Getter(JSContext*, unsigned int, JS::Value*)':
/builds/slave/m-cen-osx64-gecko-ntly/build/js/src/jstypedarray.cpp:1427: error: template parameter 'ValueGetter' of type 'JS::Value (*)(JSObject*)' is not allowed in an integral constant expression because it is not of integral or enumeration type
}

Are B2G builds supposed to be using gcc?
CCing espindola for last part of comment 1.
It looks like this was caused by 777174. The problem reduces to gcc 4.2 not accepting

typedef bool (*NativeImpl)();
template<NativeImpl Impl> inline bool CallNonGenericMethod() {
}
template<typename NativeType> class TypedArrayTemplate  {
  typedef TypedArrayTemplate<NativeType> ThisTypeArray;
  template<int ValueGetter()>
  static bool     GetterImpl()     {
    return CallNonGenericMethod<  ThisTypeArray::GetterImpl<ValueGetter> >();
  }
};
git bisect found this to be fixed by http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39608. Which is strange, since is marked as a regression fix. Looking a bit more to see if there is a way to avoid the bug.
Assignee: jimb → respindola
Attachment #652883 - Flags: review?(jimb)
Fwiw att #652883 fixes my openbsd/gcc 4.2 builds too.
Comment on attachment 652883 [details] [diff] [review]
fix gcc 4.2 build.

Review of attachment 652883 [details] [diff] [review]:
-----------------------------------------------------------------

Oh, I don't know that that hack is "really bad". It's the circumstances that are bad; the workaround is sensible enough.

r=me.
Attachment #652883 - Flags: review?(jimb) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/4d76ec905c11
http://hg.mozilla.org/mozilla-central/rev/3a0f4470276f

not 100% sure but i think this one can be marked as fixed. my openbsd/gcc 4.2 builds are green again.
As is birch (our gcc osx builds) :-)
https://tbpl.mozilla.org/?tree=Birch&rev=716b48dbafe3
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
This has also fixed the OS X nightly builds
(In reply to John Ford [:jhford] from comment #13)
> This has also fixed the OS X nightly builds

Are they using gcc? :-(
What mozconfig are they using. They should have switched to clang.
The original code fails to compile with gcc 4.3.2 on Linux (Fedora release 10 (Cambridge))

I got it to compile by changing the "2" in the patch to a "3"
(In reply to Eric Promislow from comment #15)
> The original code fails to compile with gcc 4.3.2 on Linux (Fedora release
> 10 (Cambridge))
> 
> I got it to compile by changing the "2" in the patch to a "3"

Oops. Sorry about that.  The ifdef was removed on bug 784029.
You need to log in before you can comment on or make changes to this bug.