Closed
Bug 783505
Opened 12 years ago
Closed 12 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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: emorley, Assigned: espindola)
References
Details
Attachments
(1 file)
830 bytes,
patch
|
jorendorff
:
review+
|
Details | Diff | Splinter Review |
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•12 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?
Assignee | ||
Comment 3•12 years ago
|
||
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> >(); } };
Assignee | ||
Comment 4•12 years ago
|
||
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 | ||
Comment 5•12 years ago
|
||
Assignee: jimb → respindola
Attachment #652883 -
Flags: review?(jimb)
Assignee | ||
Comment 6•12 years ago
|
||
I pushed the patch + a hack to use gcc 4.2 to https://tbpl.mozilla.org/?tree=Try&rev=3c393fe37a76
Comment 7•12 years ago
|
||
Fwiw att #652883 fixes my openbsd/gcc 4.2 builds too.
Comment 8•12 years ago
|
||
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+
Assignee | ||
Comment 9•12 years ago
|
||
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=4d76ec905c11
Comment 10•12 years ago
|
||
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•12 years ago
|
||
As is birch (our gcc osx builds) :-) https://tbpl.mozilla.org/?tree=Birch&rev=716b48dbafe3
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/4d76ec905c11
Comment 13•12 years ago
|
||
This has also fixed the OS X nightly builds
Assignee | ||
Comment 14•12 years ago
|
||
(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•12 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"
Assignee | ||
Comment 16•12 years ago
|
||
(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.
Description
•