Update of git-hooks (uses Python 3.x)?
Hello. Note that binutils updated the git-hooks, which now uses Python 3: https://github.com/AdaCore/git-hooks I'm asking because we're facing again an encoding issue (spotted by Jakub): remote: Traceback (most recent call last): remote: File "hooks/post_receive.py", line 118, in remote: post_receive(refs_data, args.submitter_email) remote: File "hooks/post_receive.py", line 65, in post_receive remote: submitter_email) remote: File "hooks/post_receive.py", line 47, in post_receive_one remote: update.send_email_notifications() remote: File "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 189, in send_email_notifications remote: self.__email_new_commits() remote: File "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 1031, in __email_new_commits remote: commit, self.get_standard_commit_email(commit)) remote: File "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 1011, in __send_commit_email remote: default_diff=email.diff) remote: File "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 946, in __maybe_get_email_custom_contents remote: hook_input=json.dumps(hooks_data), remote: File "/usr/lib64/python2.7/json/__init__.py", line 244, in dumps remote: return _default_encoder.encode(obj) remote: File "/usr/lib64/python2.7/json/encoder.py", line 207, in encode remote: chunks = self.iterencode(o, _one_shot=True) remote: File "/usr/lib64/python2.7/json/encoder.py", line 270, in iterencode remote: return _iterencode(o, 0) remote: UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 7675115: invalid continuation byte So can we please update the hooks? Thanks, Martin
Re: [power-iee128] How to specify linker flags
On 02.01.22 23:58, Thomas Koenig wrote: Hi Michael, If you are building libraries that contain modules with multiple long double types, you must use the '-mno-gnu-attribute'. We also use the '-Wno-psabi' option, which silences the warning that you are switching long double types (if glibc is not 2.34 or newer). We may need to tweak -Wno-psabi for use with Fortran. I am now at the point where the object files are also compiled correctly for the gfortran specifics: <_gfortran_specific__abs_r17>: 0: 09 00 43 f4 lxv vs34,0(r3) 4: 48 16 40 fc xsabsqp v2,v2 8: 20 00 80 4e blr However, the linker complains, as you said it would, about the different formats: /opt/at15.0/bin/ld: .libs/maxloc0_4_r16.o uses IBM long double, .libs/_abs_r17.o uses IEEE long double /opt/at15.0/bin/ld: failed to merge target specific data of file .libs/_abs_r17.o I know next to nothing about libtool, so I do not know how to add the flags so the linker can find them. Any pointers? One additional point. The linker does not understand -mno-gnu-attribute: $ /opt/at15.0/bin/ld -mno-gnu-attribute /opt/at15.0/bin/ld: unrecognised emulation mode: no-gnu-attribute Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim elf64ppc elf32ppc elf32ppclinux elf32ppcsim So, waiting for info to proceed. Best regards Thomas
Re: [power-iee128] How to specify linker flags
On Mon, Jan 03, 2022 at 11:19:21AM +0100, Thomas Koenig wrote: > > > If you are building libraries that contain modules with multiple > > > long double > > > types, you must use the '-mno-gnu-attribute'. We also use the > > > '-Wno-psabi' > > > option, which silences the warning that you are switching long > > > double types (if > > > glibc is not 2.34 or newer). We may need to tweak -Wno-psabi for > > > use with > > > Fortran. > > > > I am now at the point where the object files are also compiled correctly > > for the gfortran specifics: > > > > <_gfortran_specific__abs_r17>: > > 0: 09 00 43 f4 lxv vs34,0(r3) > > 4: 48 16 40 fc xsabsqp v2,v2 > > 8: 20 00 80 4e blr > > > > However, the linker complains, as you said it would, about the different > > formats: > > > > /opt/at15.0/bin/ld: .libs/maxloc0_4_r16.o uses IBM long double, > > .libs/_abs_r17.o uses IEEE long double > > /opt/at15.0/bin/ld: failed to merge target specific data of file > > .libs/_abs_r17.o > > > > I know next to nothing about libtool, so I do not know how to > > add the flags so the linker can find them. > > > > Any pointers? > > One additional point. The linker does not understand > -mno-gnu-attribute: > > $ /opt/at15.0/bin/ld -mno-gnu-attribute > /opt/at15.0/bin/ld: unrecognised emulation mode: no-gnu-attribute > Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim > elf64ppc elf32ppc elf32ppclinux elf32ppcsim > > So, waiting for info to proceed. -mno-gnu-attribute isn't a linker flag, but a compiler flag. And e.g. libstdc++ configure uses it while compiling itself on powerpc*linux: LONG_DOUBLE_COMPAT_FLAGS="$LONG_DOUBLE_COMPAT_FLAGS -mno-gnu-attribute" # Check for IEEE128 support in libm: AC_CHECK_LIB(m, __frexpieee128, [ac_ldbl_ieee128_in_libc=yes], [ac_ldbl_ieee128_in_libc=no]) if test $ac_ldbl_ieee128_in_libc = yes; then # Determine which long double format is the compiler's default: AC_TRY_COMPILE(, [ #ifndef __LONG_DOUBLE_IEEE128__ #error compiler defaults to ibm128 #endif ], [ac_ldbl_ieee128_default=yes], [ac_ldbl_ieee128_default=no]) # Library objects should use default long double format. if test "$ac_ldbl_ieee128_default" = yes; then LONG_DOUBLE_128_FLAGS="-mno-gnu-attribute" # Except for the ones that explicitly use these flags: LONG_DOUBLE_ALT128_COMPAT_FLAGS="-mabi=ibmlongdouble -mno-gnu-attribute -Wno-psabi" else LONG_DOUBLE_128_FLAGS="-mno-gnu-attribute" LONG_DOUBLE_ALT128_COMPAT_FLAGS="-mabi=ieeelongdouble -mno-gnu-attribute -Wno-psabi" fi AC_DEFINE([_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT],1, [Define if compatibility should be provided for alternative 128-bit long double formats.]) port_specific_symbol_files="$port_specific_symbol_files \$(top_srcdir)/config/os/gnu-linux/ldbl-ieee128-extra.ver" ac_ldbl_alt128_compat=yes else ac_ldbl_alt128_compat=no fi ;; The idea behind this is that libstdc++ is written such that it can handle both IBM extended and IEEE quad long double, so its object files are compatible with both. So I think we want: 2022-01-03 Jakub Jelinek * configure.ac (Use -mno-gnu-attribute together with -mabi=ibmlongdouble or -mabi=ieeelongdouble. --- libgfortran/configure.ac2021-12-31 11:08:19.032835533 + +++ libgfortran/configure.ac2022-01-03 10:32:16.927834682 + @@ -163,9 +163,9 @@ if test "x$GCC" = "xyes"; then #error long double is double #endif]], [[(void) 0;]])], -[AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble"; -AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble"; -CFLAGS="$CFLAGS -mabi=ibmlongdouble"; +[AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; +AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; +CFLAGS="$CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; have_real_17=yes]) ;; *) Jakub
Re: [power-iee128] How to specify linker flags
Hi! On Mon, Jan 03, 2022 at 11:19:21AM +0100, Thomas Koenig wrote: > One additional point. The linker does not understand > -mno-gnu-attribute: That is a GCC option, not an ld one. If you use it to compile some file there will be no .gnu.attributes section generated for that translation unit. Segher
Re: Why do these two trees print differently
On Wed, Dec 15, 2021 at 7:10 AM Gary Oblock via Gcc wrote: > > This is one of those things that has always puzzled > me so I thought I break down and finally ask. > > There are two ways a memory reference (tree) prints: > > MEM[(struct arc_t *)_684].flow > > and > > _684->flow > > Poking under the hood of them, the tree codes and > operands are identical so what am I missing? Try dumping with -gimple, that should show you the difference. > > Thanks, > > Gary > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and contains information that > is confidential and proprietary to Ampere Computing or its subsidiaries. It > is to be used solely for the purpose of furthering the parties' business > relationship. Any unauthorized review, copying, or distribution of this email > (or any attachments thereto) is strictly prohibited. If you are not the > intended recipient, please contact the sender immediately and permanently > delete the original and any copies of this email and any attachments thereto.
Re: Why do these two trees print differently
Richard, I was able figure it out by looking for "MEM" is tree-pretty-print.c. There is the condition included at the end of the email (mostly to provoke a chuckle) necessary for the "p->f" format. If it's not true then the MEM form is emitted. What is most interesting from this whole exercise the question of why am I seeing offsets in the GIMPLE form? I'm seeing offsets where the symbolic form using field seems to make more sense. I'm also seeing accesses with offsets that are multiples of the structure size. That kind of idiom seems more appropriate at the RTL level. Thanks, Gary TREE_CODE (node) == MEM_REF && integer_zerop (TREE_OPERAND (node, 1)) /* Dump the types of INTEGER_CSTs explicitly, for we can't infer them and MEM_ATTR caching will share MEM_REFs with differently-typed op0s. */ && TREE_CODE (TREE_OPERAND (node, 0)) != INTEGER_CST /* Released SSA_NAMES have no TREE_TYPE. */ && TREE_TYPE (TREE_OPERAND (node, 0)) != NULL_TREE /* Same pointer types, but ignoring POINTER_TYPE vs. REFERENCE_TYPE. */ && (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 0))) == TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1 && (TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 0))) == TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 1 && (TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 0))) == TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 1 /* Same value types ignoring qualifiers. */ && (TYPE_MAIN_VARIANT (TREE_TYPE (node)) == TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1) && (!(flags & TDF_ALIAS) || MR_DEPENDENCE_CLIQUE (node) == 0)) From: Richard Biener Sent: Monday, January 3, 2022 5:49 AM To: Gary Oblock Cc: gcc@gcc.gnu.org Subject: Re: Why do these two trees print differently [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.] On Wed, Dec 15, 2021 at 7:10 AM Gary Oblock via Gcc wrote: > > This is one of those things that has always puzzled > me so I thought I break down and finally ask. > > There are two ways a memory reference (tree) prints: > > MEM[(struct arc_t *)_684].flow > > and > > _684->flow > > Poking under the hood of them, the tree codes and > operands are identical so what am I missing? Try dumping with -gimple, that should show you the difference. > > Thanks, > > Gary > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and contains information that > is confidential and proprietary to Ampere Computing or its subsidiaries. It > is to be used solely for the purpose of furthering the parties' business > relationship. Any unauthorized review, copying, or distribution of this email > (or any attachments thereto) is strictly prohibited. If you are not the > intended recipient, please contact the sender immediately and permanently > delete the original and any copies of this email and any attachments thereto.
Re: Why do these two trees print differently
On Mon, Jan 3, 2022 at 9:16 PM Gary Oblock wrote: > > Richard, > > I was able figure it out by looking for "MEM" is > tree-pretty-print.c. There is the condition included > at the end of the email (mostly to provoke a chuckle) > necessary for the "p->f" format. If it's not true then > the MEM form is emitted. Yes, there's some loss of information so we don't "pretty" print the MEM. > > What is most interesting from this whole exercise > the question of why am I seeing offsets in > the GIMPLE form? I'm seeing offsets where > the symbolic form using field seems to make > more sense. I'm also seeing accesses with > offsets that are multiples of the structure size. > That kind of idiom seems more appropriate at the > RTL level. That seems to be an unrelated question? Note that GIMPLE is much closer to RTL than you think - GIMPLE is _not_ an AST. You see offsets whenever symbolic (COMPONENT_REF I suppose) is eventually not semantically correct. Richard. > > Thanks, > > Gary > > TREE_CODE (node) == MEM_REF > && integer_zerop (TREE_OPERAND (node, 1)) > /* Dump the types of INTEGER_CSTs explicitly, for we can't > infer them and MEM_ATTR caching will share MEM_REFs > with differently-typed op0s. */ > && TREE_CODE (TREE_OPERAND (node, 0)) != INTEGER_CST > /* Released SSA_NAMES have no TREE_TYPE. */ > && TREE_TYPE (TREE_OPERAND (node, 0)) != NULL_TREE > /* Same pointer types, but ignoring POINTER_TYPE vs. > REFERENCE_TYPE. */ > && (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 0))) > == TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1 > && (TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 0))) > == TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 1 > && (TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 0))) > == TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 1 > /* Same value types ignoring qualifiers. */ > && (TYPE_MAIN_VARIANT (TREE_TYPE (node)) > == TYPE_MAIN_VARIANT > (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1) > && (!(flags & TDF_ALIAS) > || MR_DEPENDENCE_CLIQUE (node) == 0)) > > > From: Richard Biener > Sent: Monday, January 3, 2022 5:49 AM > To: Gary Oblock > Cc: gcc@gcc.gnu.org > Subject: Re: Why do these two trees print differently > > [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please > be mindful of safe email handling and proprietary information protection > practices.] > > > On Wed, Dec 15, 2021 at 7:10 AM Gary Oblock via Gcc wrote: > > > > This is one of those things that has always puzzled > > me so I thought I break down and finally ask. > > > > There are two ways a memory reference (tree) prints: > > > > MEM[(struct arc_t *)_684].flow > > > > and > > > > _684->flow > > > > Poking under the hood of them, the tree codes and > > operands are identical so what am I missing? > > Try dumping with -gimple, that should show you the difference. > > > > > Thanks, > > > > Gary > > > > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > > for the sole use of the intended recipient(s) and contains information that > > is confidential and proprietary to Ampere Computing or its subsidiaries. It > > is to be used solely for the purpose of furthering the parties' business > > relationship. Any unauthorized review, copying, or distribution of this > > email (or any attachments thereto) is strictly prohibited. If you are not > > the intended recipient, please contact the sender immediately and > > permanently delete the original and any copies of this email and any > > attachments thereto.
