halfmoon does not compile on windows

RESOLVED FIXED in Q3 12 - Dolores

Status

RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: brbaker, Assigned: wmaddox)

Tracking

(Blocks: 1 bug)

unspecified
Q3 12 - Dolores
All
Windows 7
Dependency tree / graph
Bug Flags:
flashplayer-qrb +

Details

Attachments

(3 attachments)

(Reporter)

Description

7 years ago
Compiling halfmoon enabled shell on windows and windows64 fails with the following error:

nanojit\Allocator.h(126) : error C2512: 'halfmoon::TypeKey' : no appropriate default constructor available
build/rules.mk:62: recipe for target `halfmoon/hm-instrgraph.obj' failed

This happens either with the current tip of tamarin and using the --enable-halfmoon switch, or using the initial checkin of the halfmoon code (rev 7316:a6cded0538e7) and adding -DAVMFEATURE_HALFMOON=1 to the Makefile
(Reporter)

Updated

7 years ago
Flags: flashplayer-qrb?

Updated

7 years ago
Assignee: nobody → wmaddox
Status: NEW → ASSIGNED
Flags: flashplayer-qrb? → flashplayer-qrb+
Target Milestone: --- → Q3 12 - Dolores

Comment 1

7 years ago
changeset: 7385:7324cae3a421
user:      Brent Baker <brbaker@adobe.com>
summary:   Bug 750694: do not try to compile halfmoon on windows in the deep phase of the build as it currently doesn't compile and is causing the build to fail (r+brbaker)

http://hg.mozilla.org/tamarin-redux/rev/7324cae3a421
(Reporter)

Updated

6 years ago
Blocks: 639475
(Reporter)

Updated

6 years ago
See Also: → bug 772512
(Reporter)

Updated

6 years ago
Blocks: 779468
(Reporter)

Comment 2

6 years ago
Bump, this needs to be fixed so that we can start building and testing the halfmoon code in the sandbox and in the main tamarin-redux Jenkins builders.
(Assignee)

Comment 3

6 years ago
Created attachment 648188 [details] [diff] [review]
Fixes for win32 and linux32 builds

Work in progress -- builds ok in local builds of 32-bit Windows, Linux, MacOSX.
(Assignee)

Comment 4

6 years ago
Created attachment 648596 [details] [diff] [review]
Build fixes for Win32, Linux, and ARM-architecture platforms

This is a bit unpolished and some follow-up is warranted, but I'd like to get this going in automated builds before messing around with it anymore.
Attachment #648596 - Flags: review?(throdrig)
(Reporter)

Comment 5

6 years ago
(In reply to William Maddox from comment #4)
> Created attachment 648596 [details] [diff] [review]
> Build fixes for Win32, Linux, and ARM-architecture platforms
> 
> This is a bit unpolished and some follow-up is warranted, but I'd like to
> get this going in automated builds before messing around with it anymore.

Patch is really close to compiling release and debug-debugger on all platforms. These are the current holdouts (Android and WindowsRT):

** Android: debug-debugger build **
cc1plus: warnings being treated as errors
../halfmoon/hm-typeanalyzer.cpp: In function 'bool halfmoon::isCastCall(halfmoon::Lattice*, const halfmoon::Type*, uint32_t, const halfmoon::Type**)':
../halfmoon/hm-typeanalyzer.cpp:627: error: logical '&&' with non-zero constant will always evaluate as true
cc1plus: warnings being treated as errors
../halfmoon/hm-check.cpp: In member function 'bool halfmoon::TypeChecker::do_default(halfmoon::Instr*)':
../halfmoon/hm-check.cpp:245: error: logical '&&' with non-zero constant will always evaluate as true

** WindowsRT **
../halfmoon/hm-deoptimizer.cpp(522) : error C2220: warning treated as error - no 'object' file generated
../halfmoon/hm-deoptimizer.cpp(522) : warning C4244: 'return' : conversion from 'nanojit::NIns' to 'uint8_t', possible loss of data
../build/rules.mk:62: recipe for target `halfmoon/hm-deoptimizer.obj' failed

Comment 6

6 years ago
In NativeARM.cpp, there isn't really a bug but the optimizer isn't able to figure it out.  dm may be uninitialzed if !qwordPrecision and !ARM_VFP and there's an assert that guards against case, so that path should never be reached.  Initializing it seems ok to fix the warning but I think you should drop the comment.  Any reason not to simply delete the FIXME stuff in Deopt-CL.cpp?  Otherwise it looks like.  Even without the changes it looks ok.

Comment 7

6 years ago
(In reply to Brent Baker from comment #5)
> (In reply to William Maddox from comment #4)
> > Created attachment 648596 [details] [diff] [review]
> > Build fixes for Win32, Linux, and ARM-architecture platforms
> > 
> > This is a bit unpolished and some follow-up is warranted, but I'd like to
> > get this going in automated builds before messing around with it anymore.
> 
> Patch is really close to compiling release and debug-debugger on all
> platforms. These are the current holdouts (Android and WindowsRT):
> 
> ** Android: debug-debugger build **
> cc1plus: warnings being treated as errors
> ../halfmoon/hm-typeanalyzer.cpp: In function 'bool
> halfmoon::isCastCall(halfmoon::Lattice*, const halfmoon::Type*, uint32_t,
> const halfmoon::Type**)':
> ../halfmoon/hm-typeanalyzer.cpp:627: error: logical '&&' with non-zero
> constant will always evaluate as true

This is trying to null test a GCMember which is an object.  Converting it to != NULL would probably make the message go away.

> cc1plus: warnings being treated as errors
> ../halfmoon/hm-check.cpp: In member function 'bool
> halfmoon::TypeChecker::do_default(halfmoon::Instr*)':
> ../halfmoon/hm-check.cpp:245: error: logical '&&' with non-zero constant
> will always evaluate as true

This is trying to null check a reference, so it probably needs to be &use != NULL.

> 
> ** WindowsRT **
> ../halfmoon/hm-deoptimizer.cpp(522) : error C2220: warning treated as error
> - no 'object' file generated
> ../halfmoon/hm-deoptimizer.cpp(522) : warning C4244: 'return' : conversion
> from 'nanojit::NIns' to 'uint8_t', possible loss of data

This should just be cast to uint8_t for the moment.  There's a big abuse of NIns going here as noted in the comments.

  // Pointer to next byte to be written.
  // TODO: Fix abuse of NIns*.
  NIns* mdins_;

I can give these a try in the shelf builder

> ../build/rules.mk:62: recipe for target `halfmoon/hm-deoptimizer.obj' failed

Comment 8

6 years ago
Created attachment 648780 [details] [diff] [review]
android and windowsrt fixes

The android build is done with these fixes but windows rt is still working.  it should be done soon.
Attachment #648780 - Flags: review?(wmaddox)

Comment 9

6 years ago
(In reply to Tom Rodriguez from comment #8)
> Created attachment 648780 [details] [diff] [review]
> android and windowsrt fixes
> 
> The android build is done with these fixes but windows rt is still working. 
> it should be done soon.

Actually I suspect it didn't build it right since it will require some configuration changes to build halfmoon by default, which I don't have.  So the patch should be right but it will require confirmation.
(Reporter)

Comment 10

6 years ago
(In reply to Tom Rodriguez from comment #9)
> Actually I suspect it didn't build it right since it will require some
> configuration changes to build halfmoon by default, which I don't have.  So
> the patch should be right but it will require confirmation.

I tweaked the sandbox for you change and resubmitted the build. It looks good but I have to wait for the WIndowsRT build to finish another build to know for certain that it is compiling cleanly. I'll inform Dan Schaffer about the change that I made so that he can revert it once your build is complete (and later commit the change once the code fix is checked in)
Comment on attachment 648780 [details] [diff] [review]
android and windowsrt fixes

(swipe; I think even I can vouch for these changes.)
Attachment #648780 - Flags: review?(wmaddox) → review+
(Reporter)

Comment 12

6 years ago
(In reply to Brent Baker from comment #10)
> I tweaked the sandbox for you change and resubmitted the build. It looks
> good but I have to wait for the WIndowsRT build to finish another build to
> know for certain that it is compiling cleanly. I'll inform Dan Schaffer
> about the change that I made so that he can revert it once your build is
> complete (and later commit the change once the code fix is checked in)

Update: Halfmoon compilation of release and debug-debugger has completed on all supported platforms with the latest code changes.

Comment 13

6 years ago
Fixed as CL 1096510.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Duplicate of this bug: 692084

Comment 15

6 years ago
changeset: 7523:5b15da1e8285
user:      Tom Rodriguez <throdrig@adobe.com>
summary:   750694: halfmoon does not compile on windows (p=wmaddox, r=fklockii, r=throdrig)

http://hg.mozilla.org/tamarin-redux/rev/5b15da1e8285

Updated

6 years ago
Attachment #648596 - Flags: review?(throdrig) → review+

Comment 16

6 years ago
I enabled compiling halfmoon in jenkins for all shell platforms ( debug and release).  I added running release halfmoon acceptance tests for desktop platforms.  They all pass but I assume this is due to halfmoon falling back to interp.

Updated

6 years ago
Duplicate of this bug: 694418

Updated

6 years ago
Duplicate of this bug: 772516

Updated

6 years ago
Duplicate of this bug: 772514
You need to log in before you can comment on or make changes to this bug.