[jdk22] Integrated: 8322647: Short name for the `Europe/Lisbon` time zone is incorrect
On Thu, 4 Jan 2024 17:26:37 GMT, Naoto Sato wrote: > 8322647: Short name for the `Europe/Lisbon` time zone is incorrect This pull request has now been integrated. Changeset: a72afb38 Author:Naoto Sato URL: https://git.openjdk.org/jdk22/commit/a72afb3845a7d245d462904e75b9368efefc0d39 Stats: 94 lines in 3 files changed: 72 ins; 2 del; 20 mod 8322647: Short name for the `Europe/Lisbon` time zone is incorrect Reviewed-by: joehw Backport-of: ad31ec5c5f120082cedd7b9ece45b6b44147c0c5 - PR: https://git.openjdk.org/jdk22/pull/30
Re: [jdk22] RFR: 8322647: Short name for the `Europe/Lisbon` time zone is incorrect
On Thu, 4 Jan 2024 17:26:37 GMT, Naoto Sato wrote: > 8322647: Short name for the `Europe/Lisbon` time zone is incorrect Marked as reviewed by joehw (Reviewer). - PR Review: https://git.openjdk.org/jdk22/pull/30#pullrequestreview-1804685583
[jdk22] RFR: 8322647: Short name for the `Europe/Lisbon` time zone is incorrect
8322647: Short name for the `Europe/Lisbon` time zone is incorrect - Commit messages: - Backport ad31ec5c5f120082cedd7b9ece45b6b44147c0c5 Changes: https://git.openjdk.org/jdk22/pull/30/files Webrev: https://webrevs.openjdk.org/?repo=jdk22=30=00 Issue: https://bugs.openjdk.org/browse/JDK-8322647 Stats: 94 lines in 3 files changed: 72 ins; 2 del; 20 mod Patch: https://git.openjdk.org/jdk22/pull/30.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/30/head:pull/30 PR: https://git.openjdk.org/jdk22/pull/30
RE: OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option
>> >> It looks like there is code to attempt to deal with that sort of thing in our >> build system. See TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4. >> That >> dates back to JDK 9. However, that only deals with CFLAGS and CXXFLAGS. The >> AC_PROG_CC/CXX feature affects the CC/CXX variables. Bleh! > > Looks like we need to extend this functionality and filter out any > "-std*" flags added by autoconf from CC/CXX. Even if later "-std=c++14" > on the command line overrides correctly, it would be good for > sanitation. I think such a fix should be done in mainline to avoid > different behavior with different versions of autoconf. It can then be > backported to openjdk 11 to fix the more severe issue described here. Hi Erik, I created : https://bugs.openjdk.org/browse/JDK-8323008 8323008: filter out any -std* flags added by autoconf from CC/CXX Feel free to add additional info to this JBS issue . Best regards, Matthias
RE: OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option
Btw. Is there already something at make/autoconf that does similar filtering of unwanted flags ? The mentioned TOOLCHAIN_POST_DETECTION seems just to reset some variables like CXX_CFLAGS to old values , not sure if this is what we want here ? >Hi Erik, I created : > >https://bugs.openjdk.org/browse/JDK-8323008 >8323008: filter out any -std* flags added by autoconf from CC/CXX > >Feel free to add additional info to this JBS issue . >
Re: OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option
On 1/3/24 13:03, Kim Barrett wrote: On Jan 3, 2024, at 7:16 AM, Baesken, Matthias wrote: Btw. I found this rather recent discussion about reverting the forcing of setting -std=gnu++11 in autoconf : https://urldefense.com/v3/__https://mail.gnu.org/archive/html/bug-autoconf/2023-12/msg00073.html__;!!ACWV5N9M2RV99hQ!KfFeVOARPmr8RlTN3t2qMgkljzWkcpqA_NwxnyMtkaHzz3dwDxZjVsZZZvQLEXP-Rd6rngZKnovzj0C6Uzn-XF_4Gw$ https://urldefense.com/v3/__https://savannah.gnu.org/support/?110879__;!!ACWV5N9M2RV99hQ!KfFeVOARPmr8RlTN3t2qMgkljzWkcpqA_NwxnyMtkaHzz3dwDxZjVsZZZvQLEXP-Rd6rngZKnovzj0C6Uzk4Umn7ug$ revert forcing/setting -std=gnu++11 by default (introduced in Autoconf 2.70) So autoconf forcibly selects a -std= option, possibly overriding either an explicit option or the compiler's default. Who thought that was a good idea? There are even comments from the time that question that "feature". It looks like there is code to attempt to deal with that sort of thing in our build system. See TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4. That dates back to JDK 9. However, that only deals with CFLAGS and CXXFLAGS. The AC_PROG_CC/CXX feature affects the CC/CXX variables. Bleh! Looks like we need to extend this functionality and filter out any "-std*" flags added by autoconf from CC/CXX. Even if later "-std=c++14" on the command line overrides correctly, it would be good for sanitation. I think such a fix should be done in mainline to avoid different behavior with different versions of autoconf. It can then be backported to openjdk 11 to fix the more severe issue described here. /Erik
RE: OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option
>So autoconf forcibly selects a -std= option, possibly overriding either an >explicit option or the compiler's default. Who thought that was a good idea? >There are even comments from the time that question that "feature". > >It looks like there is code to attempt to deal with that sort of thing in our >build system. See TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4. That >dates back to JDK 9. However, that only deals with CFLAGS and CXXFLAGS. The >AC_PROG_CC/CXX feature affects the CC/CXX variables. Bleh! Hi Kim, it is not a nice thing; probably the CXX could be overwritten when settings the CXX env variable before running configure ? >But I wonder why our explicit -std=gnu++98 (or whatever we were using) doesn't >override that. In the command lines are you seeing > > "g++ ... -std=gnu++11 ... -std=c++14" It is Openjdk11 ; I only see the -std=gnu++11 in the Hotspot compilation units. Only the harfbuzz files have the -std=gnu++11 ... -std=c++11 so there it is overwritten , but looks like it compiles without issues with those settings in Hotspot (as long as PCH is disabled) . >I have no idea why disabling PCH might change things in this area. Good question, seems there is something 'special' with PCH . Best regards, Matthias
Re: RFR: 8322936: Update blessed-modifier-order.sh for default, sealed, and non-sealed
On Thu, 4 Jan 2024 07:15:32 GMT, Martin Buchholz wrote: > Thanks ... now I see ... FWIW, @jddarcy thinks we can still improve `Modifier.toString(int)`. See this comment and its parent thread: https://github.com/openjdk/jdk/pull/17239#discussion_r1441050656 - PR Review Comment: https://git.openjdk.org/jdk/pull/17242#discussion_r1441537018
