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"

RESOLVED FIXED

Status

()

Core
JavaScript Engine
--
major
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: emorley, Assigned: espindola)

Tracking

Trunk
x86_64
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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
(Reporter)

Comment 1

5 years ago
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?
(Reporter)

Comment 2

5 years ago
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> >();
  }
};
Blocks: 781562
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.
Created attachment 652883 [details] [diff] [review]
fix gcc 4.2 build.
Assignee: jimb → respindola
Attachment #652883 - Flags: review?(jimb)
I pushed the patch + a hack to use gcc 4.2 to
https://tbpl.mozilla.org/?tree=Try&rev=3c393fe37a76
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://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=4d76ec905c11
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.
(Reporter)

Comment 11

5 years ago
As is birch (our gcc osx builds) :-)
https://tbpl.mozilla.org/?tree=Birch&rev=716b48dbafe3
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Reporter)

Comment 12

5 years ago
https://hg.mozilla.org/mozilla-central/rev/4d76ec905c11
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.

Comment 15

5 years ago
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.