From gary.adams at oracle.com  Fri Apr  1 14:22:54 2016
From: gary.adams at oracle.com (gary.adams at oracle.com)
Date: Fri, 01 Apr 2016 14:22:54 +0000
Subject: hg: mobile/dev/hotspot: 8153284: android-19 api support broken after
	b110 sync
Message-ID: <201604011422.u31EMstQ016654@aojmv0008.oracle.com>

Changeset: 9ec65e87a0ec
Author:    gadams
Date:      2016-04-01 10:22 -0400
URL:       http://hg.openjdk.java.net/mobile/dev/hotspot/rev/9ec65e87a0ec

8153284: android-19 api support broken after b110 sync
Reviewed-by: bobv

! src/os/linux/vm/os_linux.cpp


From ali.ebrahimi1781 at gmail.com  Sat Apr  2 18:21:21 2016
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Sat, 2 Apr 2016 22:51:21 +0430
Subject: Missing hotspot changes after Initial updates for ios x86_64 causes
	GCC error in linux build
Message-ID: <CAA0cW5DKfSk+VK3KkvJJ6WYp0O09xVfdmmuZAjD7yqy3uTpxdA@mail.gmail.com>

After first mobile-related push some changes missed specifically in file
hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp.

I restored these changes in following patch, with this patch GCC error
disappears.

diff -r 9ec65e87a0ec src/os_cpu/linux_x86/vm/os_linux_x86.cpp
--- a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Fri Apr 01 10:22:38 2016
-0400
+++ b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Sat Apr 02 22:34:02 2016
+0430
@@ -824,32 +824,32 @@
   const ucontext_t *uc = (const ucontext_t*)context;
   st->print_cr("Registers:");
 #ifdef AMD64
-  st->print(  "RAX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_AX);
-  st->print(", RBX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_BX);
-  st->print(", RCX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_CX);
-  st->print(", RDX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_DX);
+  st->print(  "RAX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_AX);
+  st->print(", RBX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_BX);
+  st->print(", RCX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_CX);
+  st->print(", RDX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_DX);
   st->cr();
-  st->print(  "RSP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_SP);
-  st->print(", RBP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_BP);
-  st->print(", RSI=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_SI);
-  st->print(", RDI=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_DI);
+  st->print(  "RSP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_SP);
+  st->print(", RBP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_BP);
+  st->print(", RSI=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_SI);
+  st->print(", RDI=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_DI);
   st->cr();
-  st->print(  "R8 =" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R8);
-  st->print(", R9 =" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R9);
-  st->print(", R10=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R10);
-  st->print(", R11=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R11);
+  st->print(  "R8 =" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R8);
+  st->print(", R9 =" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R9);
+  st->print(", R10=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R10);
+  st->print(", R11=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R11);
   st->cr();
-  st->print(  "R12=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R12);
-  st->print(", R13=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R13);
-  st->print(", R14=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R14);
-  st->print(", R15=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R15);
+  st->print(  "R12=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R12);
+  st->print(", R13=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R13);
+  st->print(", R14=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R14);
+  st->print(", R15=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R15);
   st->cr();
-  st->print(  "RIP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_PC);
-  st->print(", EFLAGS=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_FL);
-  st->print(", CSGSFS=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_CSGSFS);
-  st->print(", ERR=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_ERR);
+  st->print(  "RIP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_PC);
+  st->print(", EFLAGS=" INTPTR_FORMAT,
(intptr_t)uc->uc_mcontext.CTX_REG_FL);
+  st->print(", CSGSFS=" INTPTR_FORMAT,
(intptr_t)uc->uc_mcontext.CTX_REG_CSGSFS);
+  st->print(", ERR=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_ERR);
   st->cr();
-  st->print("  TRAPNO=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_TRAPNO);
+  st->print("  TRAPNO=" INTPTR_FORMAT,
(intptr_t)uc->uc_mcontext.CTX_REG_TRAPNO);
 #else
   st->print(  "EAX=" INTPTR_FORMAT, (int) uc->uc_mcontext.CTX_REG_AX);
   st->print(", EBX=" INTPTR_FORMAT, (int) uc->uc_mcontext.CTX_REG_BX);


-- 

Best Regards,
Ali Ebrahimi
-------------- next part --------------
diff -r 9ec65e87a0ec src/os_cpu/linux_x86/vm/os_linux_x86.cpp
--- a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp	Fri Apr 01 10:22:38 2016 -0400
+++ b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp	Sat Apr 02 22:34:02 2016 +0430
@@ -824,32 +824,32 @@
   const ucontext_t *uc = (const ucontext_t*)context;
   st->print_cr("Registers:");
 #ifdef AMD64
-  st->print(  "RAX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_AX);
-  st->print(", RBX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_BX);
-  st->print(", RCX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_CX);
-  st->print(", RDX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_DX);
+  st->print(  "RAX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_AX);
+  st->print(", RBX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_BX);
+  st->print(", RCX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_CX);
+  st->print(", RDX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_DX);
   st->cr();
-  st->print(  "RSP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_SP);
-  st->print(", RBP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_BP);
-  st->print(", RSI=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_SI);
-  st->print(", RDI=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_DI);
+  st->print(  "RSP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_SP);
+  st->print(", RBP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_BP);
+  st->print(", RSI=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_SI);
+  st->print(", RDI=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_DI);
   st->cr();
-  st->print(  "R8 =" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R8);
-  st->print(", R9 =" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R9);
-  st->print(", R10=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R10);
-  st->print(", R11=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R11);
+  st->print(  "R8 =" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R8);
+  st->print(", R9 =" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R9);
+  st->print(", R10=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R10);
+  st->print(", R11=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R11);
   st->cr();
-  st->print(  "R12=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R12);
-  st->print(", R13=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R13);
-  st->print(", R14=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R14);
-  st->print(", R15=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R15);
+  st->print(  "R12=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R12);
+  st->print(", R13=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R13);
+  st->print(", R14=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R14);
+  st->print(", R15=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R15);
   st->cr();
-  st->print(  "RIP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_PC);
-  st->print(", EFLAGS=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_FL);
-  st->print(", CSGSFS=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_CSGSFS);
-  st->print(", ERR=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_ERR);
+  st->print(  "RIP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_PC);
+  st->print(", EFLAGS=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_FL);
+  st->print(", CSGSFS=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_CSGSFS);
+  st->print(", ERR=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_ERR);
   st->cr();
-  st->print("  TRAPNO=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_TRAPNO);
+  st->print("  TRAPNO=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_TRAPNO);
 #else
   st->print(  "EAX=" INTPTR_FORMAT, (int) uc->uc_mcontext.CTX_REG_AX);
   st->print(", EBX=" INTPTR_FORMAT, (int) uc->uc_mcontext.CTX_REG_BX);

From cerebrasoft at gmail.com  Sun Apr  3 18:07:05 2016
From: cerebrasoft at gmail.com (cerebra soft)
Date: Sun, 3 Apr 2016 14:07:05 -0400
Subject: JavaFX on iOS w/OpenJDK Mobile?
Message-ID: <CAHy4YAgphyn3iHOM3Wms+O57b-5-zNL3snpsF=00kA9+kEcpXA@mail.gmail.com>

Hello all,

Great work on the mobile port of the JDK.  With some work I've been able to
successfully build the JDK and launch it in the iOS simulator and on an iOS
device.  I used the RunJava Xcode project and haven't attempted to use the
Java Launcher framework yet.

I see from the mobile project page that currently the goal is headless
support up to compact2 profile.  But of course I want more. ;)

I see that OpenJDK JavaFX builds are working on iOS using the RoboVM based
compiler and the Android Dalvik runtime.  With the recent purchase of
Xamarin by Microsoft the future of RoboVM is uncertain.  Also Android
itself is moving to OpenJDK instead of remaining on Dalvik.  So the future
of JavaFX on iOS via RoboVM is unsure for multiple reasons.

How far out would you guess (and I understand it would probably be a guess)
would it be for the mobile project to support full JRE functionality on
iOS? Is it a matter of just trying to build JavaFX on top of what the Java
Mobile project already has, or would that be a fools errand?

Presuming that may be far off and a great deal of work.  What options are
there for using the mobile JRE on the 'back end' of the application and
making the 'ui' in something else?  I'd love to keep as much of my
application logic in Java across platforms.  Primarily, I think I would
need a good way of calling into the JVM from the UI layer.  I'm somewhat
familiar with JNI and abstractions like JNA.  Would those work just as well
with the mobile JRE on iOS?

Thanks,
Rob

From bob.vandette at oracle.com  Mon Apr  4 11:52:06 2016
From: bob.vandette at oracle.com (Bob Vandette)
Date: Mon, 4 Apr 2016 07:52:06 -0400
Subject: JavaFX on iOS w/OpenJDK Mobile?
In-Reply-To: <CAHy4YAgphyn3iHOM3Wms+O57b-5-zNL3snpsF=00kA9+kEcpXA@mail.gmail.com>
References: <CAHy4YAgphyn3iHOM3Wms+O57b-5-zNL3snpsF=00kA9+kEcpXA@mail.gmail.com>
Message-ID: <FB53F7C8-ACF3-4353-A2DF-9BB7E50D970F@oracle.com>


> On Apr 3, 2016, at 2:07 PM, cerebra soft <cerebrasoft at gmail.com> wrote:
> 
> Hello all,
> 
> Great work on the mobile port of the JDK.  With some work I've been able to
> successfully build the JDK and launch it in the iOS simulator and on an iOS
> device.  I used the RunJava Xcode project and haven't attempted to use the
> Java Launcher framework yet.
> 
> I see from the mobile project page that currently the goal is headless
> support up to compact2 profile.  But of course I want more. ;)
> 
> I see that OpenJDK JavaFX builds are working on iOS using the RoboVM based
> compiler and the Android Dalvik runtime.  With the recent purchase of
> Xamarin by Microsoft the future of RoboVM is uncertain.  Also Android
> itself is moving to OpenJDK instead of remaining on Dalvik.  So the future
> of JavaFX on iOS via RoboVM is unsure for multiple reasons.
> 
> How far out would you guess (and I understand it would probably be a guess)
> would it be for the mobile project to support full JRE functionality on
> iOS? Is it a matter of just trying to build JavaFX on top of what the Java
> Mobile project already has, or would that be a fools errand?
It depends what you mean by a full JRE.

We?ve limited our focus to the modules contained in the compact2 profile specification
since it provides adequate support for a wide variety of mobile applications, can
support Java FX apps and it?s the set of packages used by our MAF (Mobile Applications
Framework product).  Limiting the Java support also provides a smaller application
binary size.

If you rule out Headful support , the work required to support the rest of the JDK 9 modules
isn?t really that bad since most of it is java code.  It is possible to provide a compliant 
implementation that is validated in headless mode.  The bulk of the remaining work involves 
validating and adapting the few remaining native libraries to iOS & Android where the testing
is probably the largest effort.

> 
> Presuming that may be far off and a great deal of work.  What options are
> there for using the mobile JRE on the 'back end' of the application and
> making the 'ui' in something else?
That?s what I assume you?d use JavaFX for, right?  We have no desire to
provide a Swing/AWT implementation for mobile platforms.

>  I'd love to keep as much of my
> application logic in Java across platforms.  Primarily, I think I would
> need a good way of calling into the JVM from the UI layer.  I'm somewhat
> familiar with JNI and abstractions like JNA.  Would those work just as well
> with the mobile JRE on iOS?
Yes, JNI is fully supported on iOS.  You do need to build native libraries as static
libs since iOS doesn?t support dynamic shared libraries but this is supported by
the JNI specification.

Bob.

> 
> Thanks,
> Rob


From johan at lodgon.com  Mon Apr  4 12:29:33 2016
From: johan at lodgon.com (Johan Vos)
Date: Mon, 4 Apr 2016 14:29:33 +0200
Subject: JavaFX on iOS w/OpenJDK Mobile?
In-Reply-To: <FB53F7C8-ACF3-4353-A2DF-9BB7E50D970F@oracle.com>
References: <CAHy4YAgphyn3iHOM3Wms+O57b-5-zNL3snpsF=00kA9+kEcpXA@mail.gmail.com>
	<FB53F7C8-ACF3-4353-A2DF-9BB7E50D970F@oracle.com>
Message-ID: <CABek58=78uivFmFoLPW74WRH-yyfLr_VQmRn+aHTmAV6BfnR0w@mail.gmail.com>

To make it very clear, the current set of modules already allows to run
JavaFX applications, e.g. see
https://twitter.com/johanvos/status/691724435175391233

The OpenJFX mobile builds (via http://javafxports.org) do not rely on
RoboVM. The libraries that are created (native + java) have no dependency
on RoboVM API's or tools. The IDE plugins (
http://gluonhq.com/products/mobile/trynow/) that we (Gluon) provide
currently provide a build-procedure that leverages the RoboVM AOT compiler,
but as shown in the screenshot we can also bundle the JavaFX libraries with
the Mobile OpenJDK runtime.

- Johan

2016-04-04 13:52 GMT+02:00 Bob Vandette <bob.vandette at oracle.com>:

>
> > On Apr 3, 2016, at 2:07 PM, cerebra soft <cerebrasoft at gmail.com> wrote:
> >
> > Hello all,
> >
> > Great work on the mobile port of the JDK.  With some work I've been able
> to
> > successfully build the JDK and launch it in the iOS simulator and on an
> iOS
> > device.  I used the RunJava Xcode project and haven't attempted to use
> the
> > Java Launcher framework yet.
> >
> > I see from the mobile project page that currently the goal is headless
> > support up to compact2 profile.  But of course I want more. ;)
> >
> > I see that OpenJDK JavaFX builds are working on iOS using the RoboVM
> based
> > compiler and the Android Dalvik runtime.  With the recent purchase of
> > Xamarin by Microsoft the future of RoboVM is uncertain.  Also Android
> > itself is moving to OpenJDK instead of remaining on Dalvik.  So the
> future
> > of JavaFX on iOS via RoboVM is unsure for multiple reasons.
> >
> > How far out would you guess (and I understand it would probably be a
> guess)
> > would it be for the mobile project to support full JRE functionality on
> > iOS? Is it a matter of just trying to build JavaFX on top of what the
> Java
> > Mobile project already has, or would that be a fools errand?
> It depends what you mean by a full JRE.
>
> We?ve limited our focus to the modules contained in the compact2 profile
> specification
> since it provides adequate support for a wide variety of mobile
> applications, can
> support Java FX apps and it?s the set of packages used by our MAF (Mobile
> Applications
> Framework product).  Limiting the Java support also provides a smaller
> application
> binary size.
>
> If you rule out Headful support , the work required to support the rest of
> the JDK 9 modules
> isn?t really that bad since most of it is java code.  It is possible to
> provide a compliant
> implementation that is validated in headless mode.  The bulk of the
> remaining work involves
> validating and adapting the few remaining native libraries to iOS &
> Android where the testing
> is probably the largest effort.
>
> >
> > Presuming that may be far off and a great deal of work.  What options are
> > there for using the mobile JRE on the 'back end' of the application and
> > making the 'ui' in something else?
> That?s what I assume you?d use JavaFX for, right?  We have no desire to
> provide a Swing/AWT implementation for mobile platforms.
>
> >  I'd love to keep as much of my
> > application logic in Java across platforms.  Primarily, I think I would
> > need a good way of calling into the JVM from the UI layer.  I'm somewhat
> > familiar with JNI and abstractions like JNA.  Would those work just as
> well
> > with the mobile JRE on iOS?
> Yes, JNI is fully supported on iOS.  You do need to build native libraries
> as static
> libs since iOS doesn?t support dynamic shared libraries but this is
> supported by
> the JNI specification.
>
> Bob.
>
> >
> > Thanks,
> > Rob
>
>

From ali.ebrahimi1781 at gmail.com  Sat Apr  9 08:40:32 2016
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Sat, 9 Apr 2016 13:10:32 +0430
Subject: Resend: Missing hotspot changes after Initial updates for ios x86_64
	causes GCC error in linux build
Message-ID: <CAA0cW5DZtqyEHusTesF0f_PN1MteUF53W2mt5-1rD1ycWH3CwQ@mail.gmail.com>

After first mobile-related push some changes missed specifically in file
hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp.

I restored these changes in following patch, with this patch GCC error
disappears.

diff -r 9ec65e87a0ec src/os_cpu/linux_x86/vm/os_linux_x86.cpp
--- a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Fri Apr 01 10:22:38 2016
-0400
+++ b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Sat Apr 02 22:34:02 2016
+0430
@@ -824,32 +824,32 @@
   const ucontext_t *uc = (const ucontext_t*)context;
   st->print_cr("Registers:");
 #ifdef AMD64
-  st->print(  "RAX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_AX);
-  st->print(", RBX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_BX);
-  st->print(", RCX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_CX);
-  st->print(", RDX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_DX);
+  st->print(  "RAX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_AX);
+  st->print(", RBX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_BX);
+  st->print(", RCX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_CX);
+  st->print(", RDX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_DX);
   st->cr();
-  st->print(  "RSP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_SP);
-  st->print(", RBP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_BP);
-  st->print(", RSI=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_SI);
-  st->print(", RDI=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_DI);
+  st->print(  "RSP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_SP);
+  st->print(", RBP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_BP);
+  st->print(", RSI=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_SI);
+  st->print(", RDI=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_DI);
   st->cr();
-  st->print(  "R8 =" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R8);
-  st->print(", R9 =" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R9);
-  st->print(", R10=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R10);
-  st->print(", R11=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R11);
+  st->print(  "R8 =" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R8);
+  st->print(", R9 =" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R9);
+  st->print(", R10=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R10);
+  st->print(", R11=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R11);
   st->cr();
-  st->print(  "R12=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R12);
-  st->print(", R13=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R13);
-  st->print(", R14=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R14);
-  st->print(", R15=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R15);
+  st->print(  "R12=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R12);
+  st->print(", R13=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R13);
+  st->print(", R14=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R14);
+  st->print(", R15=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R15);
   st->cr();
-  st->print(  "RIP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_PC);
-  st->print(", EFLAGS=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_FL);
-  st->print(", CSGSFS=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_CSGSFS);
-  st->print(", ERR=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_ERR);
+  st->print(  "RIP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_PC);
+  st->print(", EFLAGS=" INTPTR_FORMAT,
(intptr_t)uc->uc_mcontext.CTX_REG_FL);
+  st->print(", CSGSFS=" INTPTR_FORMAT,
(intptr_t)uc->uc_mcontext.CTX_REG_CSGSFS);
+  st->print(", ERR=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_ERR);
   st->cr();
-  st->print("  TRAPNO=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_TRAPNO);
+  st->print("  TRAPNO=" INTPTR_FORMAT,
(intptr_t)uc->uc_mcontext.CTX_REG_TRAPNO);
 #else
   st->print(  "EAX=" INTPTR_FORMAT, (int) uc->uc_mcontext.CTX_REG_AX);
   st->print(", EBX=" INTPTR_FORMAT, (int) uc->uc_mcontext.CTX_REG_BX);


-- 

Best Regards,
Ali Ebrahimi
-------------- next part --------------
diff -r 9ec65e87a0ec src/os_cpu/linux_x86/vm/os_linux_x86.cpp
--- a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp	Fri Apr 01 10:22:38 2016 -0400
+++ b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp	Sat Apr 02 22:34:02 2016 +0430
@@ -824,32 +824,32 @@
   const ucontext_t *uc = (const ucontext_t*)context;
   st->print_cr("Registers:");
 #ifdef AMD64
-  st->print(  "RAX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_AX);
-  st->print(", RBX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_BX);
-  st->print(", RCX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_CX);
-  st->print(", RDX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_DX);
+  st->print(  "RAX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_AX);
+  st->print(", RBX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_BX);
+  st->print(", RCX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_CX);
+  st->print(", RDX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_DX);
   st->cr();
-  st->print(  "RSP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_SP);
-  st->print(", RBP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_BP);
-  st->print(", RSI=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_SI);
-  st->print(", RDI=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_DI);
+  st->print(  "RSP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_SP);
+  st->print(", RBP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_BP);
+  st->print(", RSI=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_SI);
+  st->print(", RDI=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_DI);
   st->cr();
-  st->print(  "R8 =" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R8);
-  st->print(", R9 =" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R9);
-  st->print(", R10=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R10);
-  st->print(", R11=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R11);
+  st->print(  "R8 =" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R8);
+  st->print(", R9 =" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R9);
+  st->print(", R10=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R10);
+  st->print(", R11=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R11);
   st->cr();
-  st->print(  "R12=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R12);
-  st->print(", R13=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R13);
-  st->print(", R14=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R14);
-  st->print(", R15=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R15);
+  st->print(  "R12=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R12);
+  st->print(", R13=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R13);
+  st->print(", R14=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R14);
+  st->print(", R15=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R15);
   st->cr();
-  st->print(  "RIP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_PC);
-  st->print(", EFLAGS=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_FL);
-  st->print(", CSGSFS=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_CSGSFS);
-  st->print(", ERR=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_ERR);
+  st->print(  "RIP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_PC);
+  st->print(", EFLAGS=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_FL);
+  st->print(", CSGSFS=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_CSGSFS);
+  st->print(", ERR=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_ERR);
   st->cr();
-  st->print("  TRAPNO=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_TRAPNO);
+  st->print("  TRAPNO=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_TRAPNO);
 #else
   st->print(  "EAX=" INTPTR_FORMAT, (int) uc->uc_mcontext.CTX_REG_AX);
   st->print(", EBX=" INTPTR_FORMAT, (int) uc->uc_mcontext.CTX_REG_BX);

From gary.adams at oracle.com  Sat Apr  9 09:35:01 2016
From: gary.adams at oracle.com (gary.adams at oracle.com)
Date: Sat, 9 Apr 2016 05:35:01 -0400
Subject: Resend: Missing hotspot changes after Initial updates for ios
	x86_64 causes GCC error in linux build
In-Reply-To: <CAA0cW5DZtqyEHusTesF0f_PN1MteUF53W2mt5-1rD1ycWH3CwQ@mail.gmail.com>
References: <CAA0cW5DZtqyEHusTesF0f_PN1MteUF53W2mt5-1rD1ycWH3CwQ@mail.gmail.com>
Message-ID: <5708CCC5.4030203@oracle.com>

Those casts were removed back in Dec when we sync'ed with the mainstream 
jdk9/dev repos.
Which version of the compiler are you using that still complains?

On 4/9/16 4:40 AM, Ali Ebrahimi wrote:
> After first mobile-related push some changes missed specifically in file
> hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp.
>
> I restored these changes in following patch, with this patch GCC error
> disappears.
>
> diff -r 9ec65e87a0ec src/os_cpu/linux_x86/vm/os_linux_x86.cpp
> --- a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Fri Apr 01 10:22:38 2016
> -0400
> +++ b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Sat Apr 02 22:34:02 2016
> +0430
> @@ -824,32 +824,32 @@
>     const ucontext_t *uc = (const ucontext_t*)context;
>     st->print_cr("Registers:");
>   #ifdef AMD64
> -  st->print(  "RAX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_AX);
> -  st->print(", RBX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_BX);
> -  st->print(", RCX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_CX);
> -  st->print(", RDX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_DX);
> +  st->print(  "RAX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_AX);
> +  st->print(", RBX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_BX);
> +  st->print(", RCX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_CX);
> +  st->print(", RDX=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_DX);
>     st->cr();
> -  st->print(  "RSP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_SP);
> -  st->print(", RBP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_BP);
> -  st->print(", RSI=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_SI);
> -  st->print(", RDI=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_DI);
> +  st->print(  "RSP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_SP);
> +  st->print(", RBP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_BP);
> +  st->print(", RSI=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_SI);
> +  st->print(", RDI=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_DI);
>     st->cr();
> -  st->print(  "R8 =" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R8);
> -  st->print(", R9 =" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R9);
> -  st->print(", R10=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R10);
> -  st->print(", R11=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R11);
> +  st->print(  "R8 =" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R8);
> +  st->print(", R9 =" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R9);
> +  st->print(", R10=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R10);
> +  st->print(", R11=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R11);
>     st->cr();
> -  st->print(  "R12=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R12);
> -  st->print(", R13=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R13);
> -  st->print(", R14=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R14);
> -  st->print(", R15=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R15);
> +  st->print(  "R12=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R12);
> +  st->print(", R13=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R13);
> +  st->print(", R14=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R14);
> +  st->print(", R15=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_R15);
>     st->cr();
> -  st->print(  "RIP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_PC);
> -  st->print(", EFLAGS=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_FL);
> -  st->print(", CSGSFS=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_CSGSFS);
> -  st->print(", ERR=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_ERR);
> +  st->print(  "RIP=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_PC);
> +  st->print(", EFLAGS=" INTPTR_FORMAT,
> (intptr_t)uc->uc_mcontext.CTX_REG_FL);
> +  st->print(", CSGSFS=" INTPTR_FORMAT,
> (intptr_t)uc->uc_mcontext.CTX_REG_CSGSFS);
> +  st->print(", ERR=" INTPTR_FORMAT, (intptr_t)uc->uc_mcontext.CTX_REG_ERR);
>     st->cr();
> -  st->print("  TRAPNO=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_TRAPNO);
> +  st->print("  TRAPNO=" INTPTR_FORMAT,
> (intptr_t)uc->uc_mcontext.CTX_REG_TRAPNO);
>   #else
>     st->print(  "EAX=" INTPTR_FORMAT, (int) uc->uc_mcontext.CTX_REG_AX);
>     st->print(", EBX=" INTPTR_FORMAT, (int) uc->uc_mcontext.CTX_REG_BX);
>
>


From ali.ebrahimi1781 at gmail.com  Sat Apr  9 10:13:37 2016
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Sat, 9 Apr 2016 14:43:37 +0430
Subject: Resend: Missing hotspot changes after Initial updates for ios
	x86_64 causes GCC error in linux build
In-Reply-To: <5708CCC5.4030203@oracle.com>
References: <CAA0cW5DZtqyEHusTesF0f_PN1MteUF53W2mt5-1rD1ycWH3CwQ@mail.gmail.com>
	<5708CCC5.4030203@oracle.com>
Message-ID: <CAA0cW5DSDwzz8vKgxqUfU+C-c1G-eXCq9WctAP+zNwVpsDAvmQ@mail.gmail.com>

Hi,
These casts added by changest "8042893: compiler:
PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files"
and still remains in all other openjdk repos that I have locally: jake,
jdk9-dev, valhalla, panama,...

I have testing all of this in win, linux and macosx.
gcc is 5.2.1
VS 2013
Xcode 7.2

2016-04-09 14:05 GMT+04:30 gary.adams at oracle.com <gary.adams at oracle.com>:

> Those casts were removed back in Dec when we sync'ed with the mainstream
> jdk9/dev repos.
> Which version of the compiler are you using that still complains?
>
>
> On 4/9/16 4:40 AM, Ali Ebrahimi wrote:
>
>> After first mobile-related push some changes missed specifically in file
>> hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp.
>>
>> I restored these changes in following patch, with this patch GCC error
>> disappears.
>>
>> diff -r 9ec65e87a0ec src/os_cpu/linux_x86/vm/os_linux_x86.cpp
>> --- a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Fri Apr 01 10:22:38 2016
>> -0400
>> +++ b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Sat Apr 02 22:34:02 2016
>> +0430
>> @@ -824,32 +824,32 @@
>>     const ucontext_t *uc = (const ucontext_t*)context;
>>     st->print_cr("Registers:");
>>   #ifdef AMD64
>> -  st->print(  "RAX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_AX);
>> -  st->print(", RBX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_BX);
>> -  st->print(", RCX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_CX);
>> -  st->print(", RDX=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_DX);
>> +  st->print(  "RAX=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_AX);
>> +  st->print(", RBX=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_BX);
>> +  st->print(", RCX=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_CX);
>> +  st->print(", RDX=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_DX);
>>     st->cr();
>> -  st->print(  "RSP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_SP);
>> -  st->print(", RBP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_BP);
>> -  st->print(", RSI=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_SI);
>> -  st->print(", RDI=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_DI);
>> +  st->print(  "RSP=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_SP);
>> +  st->print(", RBP=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_BP);
>> +  st->print(", RSI=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_SI);
>> +  st->print(", RDI=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_DI);
>>     st->cr();
>> -  st->print(  "R8 =" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R8);
>> -  st->print(", R9 =" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R9);
>> -  st->print(", R10=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R10);
>> -  st->print(", R11=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R11);
>> +  st->print(  "R8 =" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_R8);
>> +  st->print(", R9 =" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_R9);
>> +  st->print(", R10=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_R10);
>> +  st->print(", R11=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_R11);
>>     st->cr();
>> -  st->print(  "R12=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R12);
>> -  st->print(", R13=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R13);
>> -  st->print(", R14=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R14);
>> -  st->print(", R15=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_R15);
>> +  st->print(  "R12=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_R12);
>> +  st->print(", R13=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_R13);
>> +  st->print(", R14=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_R14);
>> +  st->print(", R15=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_R15);
>>     st->cr();
>> -  st->print(  "RIP=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_PC);
>> -  st->print(", EFLAGS=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_FL);
>> -  st->print(", CSGSFS=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_CSGSFS);
>> -  st->print(", ERR=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_ERR);
>> +  st->print(  "RIP=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_PC);
>> +  st->print(", EFLAGS=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_FL);
>> +  st->print(", CSGSFS=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_CSGSFS);
>> +  st->print(", ERR=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_ERR);
>>     st->cr();
>> -  st->print("  TRAPNO=" INTPTR_FORMAT, uc->uc_mcontext.CTX_REG_TRAPNO);
>> +  st->print("  TRAPNO=" INTPTR_FORMAT,
>> (intptr_t)uc->uc_mcontext.CTX_REG_TRAPNO);
>>   #else
>>     st->print(  "EAX=" INTPTR_FORMAT, (int) uc->uc_mcontext.CTX_REG_AX);
>>     st->print(", EBX=" INTPTR_FORMAT, (int) uc->uc_mcontext.CTX_REG_BX);
>>
>>
>>
>


-- 

Best Regards,
Ali Ebrahimi

From ali.ebrahimi1781 at gmail.com  Sat Apr  9 10:26:30 2016
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Sat, 9 Apr 2016 14:56:30 +0430
Subject: Resend: Missing hotspot changes after Initial updates for ios x86_64
	causes GCC error in linux build
Message-ID: <CAA0cW5CrQb55CvaqKgpTmAgHJDy_rqSA8S6NNLT9cBHXppZ8cA@mail.gmail.com>

I should add I get GCC error when building for target linux 64bit not
android.

"
These casts added by changest "8042893: compiler:
PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files"
and still remains in all other openjdk repos that I have locally: jake,
jdk9-dev, valhalla, panama,...

I have testing all of this in win, linux and macosx.
gcc is 5.2.1
VS 2013
Xcode 7.2
"


-- 

Best Regards,
Ali Ebrahimi

From gary.adams at oracle.com  Mon Apr 11 12:12:08 2016
From: gary.adams at oracle.com (Gary Adams)
Date: Mon, 11 Apr 2016 08:12:08 -0400
Subject: Resend: Missing hotspot changes after Initial updates for ios
	x86_64 causes GCC error in linux build
In-Reply-To: <CAA0cW5CrQb55CvaqKgpTmAgHJDy_rqSA8S6NNLT9cBHXppZ8cA@mail.gmail.com>
References: <CAA0cW5CrQb55CvaqKgpTmAgHJDy_rqSA8S6NNLT9cBHXppZ8cA@mail.gmail.com>
Message-ID: <570B9498.4030004@oracle.com>

I found the missed merge and have created this issue to track the update 
to restore the casts.

   https://bugs.openjdk.java.net/browse/JDK-8153968


On 04/09/16 06:26, Ali Ebrahimi wrote:
> I should add I get GCC error when building for target linux 64bit not 
> android.
>
> "
> These casts added by changest "8042893: compiler: 
> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source 
> files" and still remains in all other openjdk repos that I have 
> locally: jake, jdk9-dev, valhalla, panama,...
>
> I have testing all of this in win, linux and macosx.
> gcc is 5.2.1
> VS 2013
> Xcode 7.2
> "
>
>
> -- 
>
> Best Regards,
> Ali Ebrahimi


From gary.adams at oracle.com  Mon Apr 11 13:08:36 2016
From: gary.adams at oracle.com (gary.adams at oracle.com)
Date: Mon, 11 Apr 2016 13:08:36 +0000
Subject: hg: mobile/dev/hotspot: 8153968: Missing casts after initial
	integration
Message-ID: <201604111308.u3BD8amo020621@aojmv0008.oracle.com>

Changeset: 301cfe5c53f5
Author:    gadams
Date:      2016-04-11 08:14 -0400
URL:       http://hg.openjdk.java.net/mobile/dev/hotspot/rev/301cfe5c53f5

8153968: Missing casts after initial integration
Reviewed-by: bobv

! src/os_cpu/linux_x86/vm/os_linux_x86.cpp


From bob.vandette at oracle.com  Tue Apr 26 14:36:36 2016
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 26 Apr 2016 10:36:36 -0400
Subject: JavaOne 2016 Call for Proposals
Message-ID: <E86E80EB-6500-406A-9649-B8E1BB88F1B8@oracle.com>

In case you haven?t heard, the JavaOne 2016 Call for Proposals is now open and will be
closing May 9th.  I encourage you all to get the word out and submit your ideas for talks.

https://www.oracle.com/javaone/call-for-proposals.html

I plan on proposing a talk on this OpenJDK Mobile project to the Java and Devices Track.

Thanks,
Bob.