Re: ctor/dtor priorities ignored when function is pre-declared
On Thu, Oct 28, 2021 at 1:26 PM Rasmus Villemoes
wrote:
>
> Hi
>
> I was wondering why the vx_crtbegin.o file had a .init_array section and
> not a .init_array.00101, when the function is defined with
> __attribute__((constructor (101))) (see libgcc/config/vxcrtstuff.c).
>
> After a lot of digging, including making sure that EH_CTOR_ATTRIBUTE
> actually gets defined as I expect and adding -frecord-gcc-switches to
> the build to see if any of those made ctor priorities ignored, it turns
> out that the problem is the declarations preceding the definitions. This
> can easily be reproduced by
>
> #define ac(prio) __attribute__((constructor(prio)))
>
> unsigned x = 987;
>
> static void f101(void);
> void f102(void);
>
> static void ac(101) f101(void) { x += 101; }
> void ac(102) f102(void) { x *= 102; }
>
> static void ac(103) f103(void) { x -= 103; }
> void ac(104) f104(void) { x /= 104; }
>
> This results in a .init_array section with two pointers, plus the
> expected .init_array.00103 and .init_array.00104 with one each.
>
> This is rather unexpected, especially since the attribute is not
> entirely ignored, just the priority part.
Probably a bug in decl merging, failing to copy DECL_HAS_INIT_PRIORITY_P
and altering the on-the-side init priority mapping
(decl_{init,fini}_priority_insert).
I suggest to file a bugreport or try to fix it yourself
(gcc/c/c-decl.c:merge_decls)
Richard.
>
> Rasmus
Re: [PATCH] Bump required minimum DejaGnu version to 1.5.3
On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
Gcc-patches wrote:
>
> From: Bernhard Reutner-Fischer
>
> Bump required DejaGnu version to 1.5.3 (or later).
> Ok for trunk?
OK.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * doc/install.texi: Bump required minimum DejaGnu version.
> ---
> gcc/doc/install.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index 36c8280d7da..094469b9a4e 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -452,7 +452,7 @@ Necessary when modifying @command{gperf} input files,
> e.g.@:
> @file{gcc/cp/cfns.gperf} to regenerate its associated header file, e.g.@:
> @file{gcc/cp/cfns.h}.
>
> -@item DejaGnu 1.4.4
> +@item DejaGnu version 1.5.3 (or later)
> @itemx Expect
> @itemx Tcl
> @c Once Tcl 8.5 or higher is required, remove any obsolete
> --
> 2.33.0
>
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)
Hi Michael, I tried this out on the one POWER machine where I can get something installed :-) It runs Ubuntu 20.04, but does not appear to have the right glibc version; it has $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04.1 LTS Release:20.04 Codename: focal $ ldd --version ldd (Ubuntu GLIBC 2.31-0ubuntu9.1) 2.31 Configure was ./trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran --with-advance-toolchain=at15.0 --with-native-system-header-dir=/opt/at15.0/include --with-long-double-format=ieee and the error message msgfmt -o fr.mo ../../../../trunk/libstdc++-v3/po/fr.po msgfmt: /lib/powerpc64le-linux-gnu/libm.so.6: version `GLIBC_2.32' not found (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/ig25/trunk-bin/./gcc/libgcc_s.so.1) and so on. Since gcc135 is also too old, that exhausts my possibilities at testing. Any hints on how best to proceed? Best regards Thomas
GCC DWARF unwinder _Unwind_Find_FDE acceleration
I've got a mostly-complete implementation of a faster _Unwind_Find_FDE
implementation which lock-free and async-signal-safe. The core idea is
to turn into effectively this.
const fde *
_Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
{
struct unw_eh_callback_data data;
const fde *ret;
ret = _Unwind_Find_registered_FDE (pc, bases);
if (ret != NULL)
return ret;
void *eh_frame = _dl_find_eh_frame (pc);
if (eh_frame == NULL)
return NULL;
struct find_fde_tail_result result
= find_fde_tail ((_Unwind_Ptr) pc, eh_frame, NULL);
if (result.entry != NULL)
{
bases->tbase = NULL;
bases->dbase = NULL;
bases->func = result.func;
}
return result.entry;
}
_dl_find_eh_frame is implemented by glibc and is very similar to
__gnu_Unwind_Find_exidx, except that it returns the PT_GNU_EH_FRAME
address. The real implementation of _Unwind_Find_FDE (not the
simplified one above) can use a weak symbol for _dl_find_eh_frame and
has still the old dl_iterate_phdr-based implementation as a fallback
(for non-glibc older glibc). There's also some hackery for passing
around the dbase value for DW_EH_PE_datarel.
I split the common tail of the old and new implementations into
find_fde_tail, included below for reference. Previously, the tail was
covered by the loader lock implied by dl_iterate_phdr. With the new
implementation, that's no longer true. I do not think this matters
because in the current implement in trunk, we continue DWARF parsing
after _Unwind_Find_FDE returns, relative to the returned FDE pointer. A
concurrent dlclose will proceed to unmap the data while it is being
read. So the race condition already exists on trunk, and we can have
crashes due to concurrent dlclose of code for a stack frame that is
processed by unwinding.
The new implementation I have is as fast as the trunk implementation for
the best case for the trunk implementation: when there are no threads
and we achieve 100% cache hit rate. Even with 1000 shared objects (of
which less than 8 participate in unwinding, to achieve 100% cache hits),
my new implementation seems to be 10% faster. Once the cache isn't 100%
effective, performance is really bad on the trunk, and likewise for
multi-threading. (There are no writes to shared data in my new
implementation and only two 64-bit acquire-MO loads (worst case), so
benchmarking multi-threaded workloads against the trunk implementation
isn't very interesting. 32-bit support will likely need 4 acquire-MO
loads.) There is a slight performance regression with lots and lots of
dlopen calls because the new data structures for the EH frame location
are somewhat costly to upgrade (but dlopen still spends twice as much
time in strcmp for soname matching, so I'm not worried).
There's room for one more straightforward optimization: move
_Unwind_Find_FDE into glibc, and not just its PT_GNU_EH_FRAME lookup.
We would have to teach glibc a little bit about the PT_GNU_EH_FRAME
layout (the parts parsed in find_fde_tail below). Once in glibc, we can
easily cache the presence and location of the table of FDEs used in the
binary search inside find_fde_tail. This means we can start the search
right away. But maybe this isn't necessary given that my new
implementation is already as fast as the old one even in the cases most
benefiting the old implementation.
A future implementation of _Unwind_Find_FDE inside glibc could also
cache the PC-to-FDE mapping inside glibc, skipping the binary search for
the FDE and taking advantage of efficient cache invalidation during
dlopen and dlclose. For an object of 20,000 functions, the binary
search in find_fde_tail takes about 10% to 15% of the time during
unwinding, so it's not insignificant. But it's also unclear if we can
actually a achieve a decent cache hit rate for any useful cache size.
So I would like to stick to my current approach, with a function like
_dl_find_eh_frame.
I will hopefully complete 32-bit support and tests next week, so that I
have patches to post.
Comments? Thoughts?
Thanks,
Florian
/* Result type of find_fde_tail below. */
struct find_fde_tail_result
{
const fde *entry;
void *func;
};
/* Find the FDE for the program counter PC, in a previously located
PT_GNU_EH_FRAME data region. */
static struct find_fde_tail_result
find_fde_tail (_Unwind_Ptr pc,
const struct unw_eh_frame_hdr *hdr,
_Unwind_Ptr dbase)
{
const unsigned char *p = (const unsigned char *) (hdr + 1);
_Unwind_Ptr eh_frame;
struct object ob;
if (hdr->version != 1)
return (struct find_fde_tail_result) { NULL, };
p = read_encoded_value_with_base (hdr->eh_frame_ptr_enc,
base_from_cb_data (hdr->eh_frame_ptr_enc,
dbase),
p, &eh_frame);
/* We require here specific table encoding to speed thin
GNU OMPD implementation
hello everyone, we read chapter 5 and the paper proposed RWTH Aachen University and the others They worked on the same project. some of us will work on OMPD, somebody will work on GDB plugin python script and somebody will work on GDB support as jakub said , but i have some clarifications that might seem silly what do you mean by GDB support and the header file specified in chapter 5 will be written easily but we have a problem with the implementation itself where to start?, do we miss something?, what are the basic knowledge we know C/C++ python and we have good understanding in Algorithms and Datastructures some of the team members will compete in the regional ICPC contest this year we understood the for gimple files I am sorry if my questions might seem very basic or not? What is the next step? We are 6 students. How can the work be divided ? Mohamed
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)
On Fri, Oct 29, 2021 at 09:07:38PM +0200, Thomas Koenig wrote: > Hi Michael, > > I tried this out on the one POWER machine where I can get something > installed :-) It runs Ubuntu 20.04, but does not appear to have the > right glibc version; it has > > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description:Ubuntu 20.04.1 LTS > Release:20.04 > Codename: focal > $ ldd --version > ldd (Ubuntu GLIBC 2.31-0ubuntu9.1) 2.31 > > Configure was > > ./trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran > --with-advance-toolchain=at15.0 > --with-native-system-header-dir=/opt/at15.0/include > --with-long-double-format=ieee > > and the error message > > msgfmt -o fr.mo ../../../../trunk/libstdc++-v3/po/fr.po > msgfmt: /lib/powerpc64le-linux-gnu/libm.so.6: version `GLIBC_2.32' not found > (required by > /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) > msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not found > (required by > /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) > msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found > (required by > /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) > msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found > (required by > /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) > msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found > (required by /home/ig25/trunk-bin/./gcc/libgcc_s.so.1) > > and so on. > > Since gcc135 is also too old, that exhausts my possibilities at testing. > > Any hints on how best to proceed? > > Best regards As I've delved into it, it looks glibc 2.34 is really only needed for switching long double over to IEEE 128-bit, since it has all of the F128 functions that would be needed. That is because Fortran uses the 'q' names which are in libquadmath (that should be built). I built the original version with: --prefix=/home/meissner/fsf-install-ppc64le/fortran-orig \ --enable-languages=c,c++,fortran \ --disable-plugin \ --enable-checking \ --enable-stage1-checking \ --enable-gnu-indirect-function \ --disable-libgomp \ --enable-decimal-float \ --enable-secureplt \ --enable-threads=posix \ --enable-__cxa_atexit \ --with-long-double-128 \ --with-long-double-format=ibm \ --with-cpu=power9 \ --with-as=/opt/at12.0/bin/as \ --with-ld=/opt/at12.0/bin/ld \ --with-gnu-as=/opt/at12.0/bin/as \ --with-gnu-ld=/opt/at12.0/bin/ld \ --with-gmp=/home/meissner/tools-compiler/ppc64le \ --with-mpfr=/home/meissner/tools-compiler/ppc64le \ --with-mpc=/home/meissner/tools-compiler/ppc64le \ --without-ppl \ --without-cloog \ --without-isl I needed to build my own version of mpfs, mpc, and gmp. I built them without shared libraries, because I get messages like you get. I have a new version of the patch that makes new target hooks to allow the backend to specify KIND numbers for types. I choose kind=16 to always be IEEE 128-bit, and kind=15 to be long double if long double is IBM (since I discovered yesterday, Fortran needs to be able to deal with long double). I'm in the middle of the build an on internal IBM system, and I will start the build on gcc135 shortly. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
gcc-10-20211029 is now available
Snapshot gcc-10-20211029 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20211029/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision 8be01524a1f502e6ef87e28d900967b3a29ee85f You'll find: gcc-10-20211029.tar.xz Complete GCC SHA256=1a541edaf4919e4612631aa53bd228bc1ac28a3ddcbc9b3b809548f335c8c47a SHA1=883064b6be7995e0082b1bb7ec51a82f4cf01d27 Diffs from 10-20211022 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch)
This patch replaces the first patch.
Instead of disallowing long double and only dealing with float128 types, this
patch tries to accommodate the two.
It adds target hooks so the back end can overwrite the kind number for types.
I made the IBM long double type use KIND=15 instead of KIND=16, and Float128
uses KIND=16 as we've discussed. The tests for long double are still
failing, so I suspect we will need some way of signalling about the long double
which uses a funky kind (king=15).
Again, this patch may be completely wild and crazy, as I don't really grok the
Fortran internals. But perhaps it will help somebody to take the concepts and
come up with a more workable solution.
Note, the fleshing out of full F128 support is only partially done. I
discovered that we don't have a complete set of FLOAT128 built-in functions
defined, so I couldn't just add code to DO_DEFINE_MATH_BUILTIN to make every
math function have the float128 counterpart declared. Note, that code is
probably not used right now, since the float128 support uses the 'q' functions
in libquadmath. Too fully utilize the f128 functions, you will need glibc 2.34
or later.
> From 80d617264d80eb86806aecb2db5f37adb9b37ff6 Mon Sep 17 00:00:00 2001
> From: Michael Meissner
> Date: Fri, 29 Oct 2021 18:35:42 -0400
> Subject: [PATCH] Second patch for PowerPC Fortran KIND=16.
This replaces the first patch, and it is a work in progress. This patch
adds three target hooks to allow the backend to control the fortran KIND
numbers. I have modified the PowerPC back end so that KIND==16 is always
IEEE 128-bit on systems support IEEE 128-bit, and KIND=15 is the long
double type if long double is IBM 128-bit.
gcc/
2021-10-29 Michael Meissner
* config/rs6000/rs6000.c (TARGET_FORTRAN_REAL_KIND_NUMBER): Set
target hook.
(TARGET_FORTRAN_REAL_KIND_TYPE): Likewise.
(TARGET_FORTRAN_REAL_KIND_FLOAT128_P): Likewise.
(rs6000_fortran_real_kind_number): New target hook.
(rs6000_fortran_real_kind_type): Likewise.
(rs6000_fortran_real_kind_float128_p): Likewise.
* target.def (fortran_real_kind_number): New target hook.
(fortran_real_kind_type): Likewise.
(fortran_real_kind_float128_p): Likewise.
* targhooks.c (default_fortran_real_kind_number): New default
target hooks for Fortran kind support.
(default_fortran_real_kind_type): Likewise.
(default_fortran_real_kind_float128_p): Likewise.
* targhooks.h (default_fortran_real_kind_number): New
declaration.
(default_fortran_real_kind_type): Likewise.
(default_fortran_real_kind_float128_p): Likewise.
* tree.h (complex_float128_type_node): New define.
* doc/tm.texi.in (TARGET_FORTRAN_REAL_KIND_*): Document new target
hooks.
* doc/tm.texi: Regenerate.
gcc/fortran/
2021-10-29 Michael Meissner
* f95-lang.c (gfc_init_builtin_functions): Flesh out more Float128
support.
* trans-types.c (gfc_init_kinds): Add support for using target
hooks to allow the backend to control KIND numbers.
(gfc_build_real_type): Likewise.
(gfc_build_complex_type): Add support for complex Float128.
---
gcc/config/rs6000/rs6000.c | 101 +
gcc/doc/tm.texi| 17 +++
gcc/doc/tm.texi.in | 6 +++
gcc/fortran/f95-lang.c | 28 ++
gcc/fortran/trans-types.c | 32
gcc/target.def | 22 +++-
gcc/targhooks.c| 37 ++
gcc/targhooks.h| 3 ++
gcc/tree.h | 2 +
9 files changed, 236 insertions(+), 12 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 22f5d701908..70595e58ac2 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -1787,6 +1787,15 @@ static const struct attribute_spec
rs6000_attribute_table[] =
#undef TARGET_INVALID_CONVERSION
#define TARGET_INVALID_CONVERSION rs6000_invalid_conversion
+
+#undef TARGET_FORTRAN_REAL_KIND_NUMBER
+#define TARGET_FORTRAN_REAL_KIND_NUMBER rs6000_fortran_real_kind_number
+
+#undef TARGET_FORTRAN_REAL_KIND_TYPE
+#define TARGET_FORTRAN_REAL_KIND_TYPE rs6000_fortran_real_kind_type
+
+#undef TARGET_FORTRAN_REAL_KIND_FLOAT128_P
+#define TARGET_FORTRAN_REAL_KIND_FLOAT128_P rs6000_fortran_real_kind_float128_p
/* Processor table. */
@@ -28376,6 +28385,98 @@ rs6000_globalize_decl_name (FILE * stream, tree decl)
}
#endif
+
+
+/* PowerPC support for Fortran KIND support. Given a MODE, return a kind
+ number to be used for real modes. If we support IEEE 128-bit, make KIND=16
+ always be IEEE 128-bit, and make KIND=15 be the IBM 128-bit double-double
+ format. */
+
+static int
+rs6000_fortran_real_kind_number (machine_mode mode)
+{
+ if (TARGET_FLOAT128_TYPE)
+{
+ /* If long double is IEEE 128-bit, return 16 for long double and 15 for
+__ibm128,
