ctor/dtor priorities ignored when function is pre-declared
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.
Rasmus
Re: [llvm-dev] [PATCH] Add GNU_PROPERTY_1_GLIBC_2_NEEDED
On Wed, Oct 27, 2021 at 11:52 PM Florian Weimer wrote: > > * H. J. Lu via llvm-dev: > > > 1. Some binaries which require new ELF features, like DT_RELR, only > > work with the new glibc binary. They crash at run-time with the older > > glibc binaries. > > 2. Somes binaries compiled with the new language features, like C2X > > printf specifiers, only generate correct results with the new glibc > > binary. Since we don't add new glibc versions to the printf function > > family, they generate incorrect results at run-time with the older > > glibc binaries. > > Solaris uses SHT_SUNW_verneed sections for this, not a property note. > Property notes seem the wrong approach for this. And there is no reason > to make this specific to glibc. > > However, I still very much dislike this proposal. > Can you share your concerns? Thanks. -- H.J.
Re: [llvm-dev] [PATCH] Add GNU_PROPERTY_1_GLIBC_2_NEEDED
* H. J. Lu: > On Wed, Oct 27, 2021 at 11:52 PM Florian Weimer wrote: >> >> * H. J. Lu via llvm-dev: >> >> > 1. Some binaries which require new ELF features, like DT_RELR, only >> > work with the new glibc binary. They crash at run-time with the older >> > glibc binaries. >> > 2. Somes binaries compiled with the new language features, like C2X >> > printf specifiers, only generate correct results with the new glibc >> > binary. Since we don't add new glibc versions to the printf function >> > family, they generate incorrect results at run-time with the older >> > glibc binaries. >> >> Solaris uses SHT_SUNW_verneed sections for this, not a property note. >> Property notes seem the wrong approach for this. And there is no reason >> to make this specific to glibc. >> >> However, I still very much dislike this proposal. >> > > Can you share your concerns? See the other thread (mostly on libc-alpha I think). Florian
Re: [llvm-dev] [PATCH] Add GNU_PROPERTY_1_GLIBC_2_NEEDED
On Thu, Oct 28, 2021 at 6:43 AM Florian Weimer wrote: > > * H. J. Lu: > > > On Wed, Oct 27, 2021 at 11:52 PM Florian Weimer wrote: > >> > >> * H. J. Lu via llvm-dev: > >> > >> > 1. Some binaries which require new ELF features, like DT_RELR, only > >> > work with the new glibc binary. They crash at run-time with the older > >> > glibc binaries. > >> > 2. Somes binaries compiled with the new language features, like C2X > >> > printf specifiers, only generate correct results with the new glibc > >> > binary. Since we don't add new glibc versions to the printf function > >> > family, they generate incorrect results at run-time with the older > >> > glibc binaries. > >> > >> Solaris uses SHT_SUNW_verneed sections for this, not a property note. > >> Property notes seem the wrong approach for this. And there is no reason > >> to make this specific to glibc. > >> > >> However, I still very much dislike this proposal. > >> > > > > Can you share your concerns? > > See the other thread (mostly on libc-alpha I think). > OK. Let's resolve it in the glibc community first. Thanks. -- H.J.
Quote 5379163
New Quotation For gcc@gcc.gnu.org Yoυ haνe a new fax docυment from Xerox Scanner. Pages 16 Full scanned PDF/ᎻTMᏞ File. Ꭱeceived2021 Remote ID 34456191 To view Quotation messages, open the attachment and login with yoυr gcc@gcc.gnu.org email to aυthenticate νieѡer and enable instant access to all yoυr fax messages on the go.
Re: [PATCH] Add GNU_PROPERTY_1_GLIBC_2_NEEDED
On Wed, 27 Oct 2021, H.J. Lu via Libc-alpha wrote: > Linker adds glibc versions in GNU_PROPERTY_1_GLIBC_2_NEEDED to the > .gnu.version_r section and removes GNU_PROPERTY_1_GLIBC_2_NEEDED note > when generating shared libraries and executables. Note that there is no guarantee that a new glibc version actually has any symbols in libc at the corresponding symbol version (there are no GLIBC_2.20 symbols in any ABI test baseline for any architecture, for example). If it happens not to, will the symbol version exist at all to satisfy this check? -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Add GNU_PROPERTY_1_GLIBC_2_NEEDED
On Thu, Oct 28, 2021 at 10:43 AM Joseph Myers wrote: > > On Wed, 27 Oct 2021, H.J. Lu via Libc-alpha wrote: > > > Linker adds glibc versions in GNU_PROPERTY_1_GLIBC_2_NEEDED to the > > .gnu.version_r section and removes GNU_PROPERTY_1_GLIBC_2_NEEDED note > > when generating shared libraries and executables. > > Note that there is no guarantee that a new glibc version actually has any > symbols in libc at the corresponding symbol version (there are no > GLIBC_2.20 symbols in any ABI test baseline for any architecture, for > example). If it happens not to, will the symbol version exist at all to > satisfy this check? > Then we need to add a new glibc version if it happens. -- H.J.
Re: dejagnu version update?
On 10/27/2021 5:00 PM, Bernhard Reutner-Fischer wrote: On Sat, 4 Aug 2018 18:32:24 +0200 Bernhard Reutner-Fischer wrote: On Tue, 16 May 2017 at 21:08, Mike Stump wrote: On May 16, 2017, at 5:16 AM, Jonathan Wakely wrote: The change I care about in 1.5.3 So, we haven't talked much about the version people want most. If we update, might as well get something that more people care about. 1.5.3 is in ubuntu LTS 16.04 and Fedora 24, so it's been around awhile. SUSU is said to be using 1.6, in the post 1.4.4 systems. People stated they want 1.5.2 and 1.5.3, so, I'm inclined to say, let's shoot for 1.5.3 when we do update. As for the machines in the FSF compile farm, nah, tail wagging the dog. I'd rather just update the requirement, and the owners or users of those machines can install a new dejagnu, if they are using one that is too old and they want to support testing gcc. So.. let me ping that, again, now that another year has passed :) or another 3 or 4 :) PS: Recap: https://gcc.gnu.org/ml/fortran/2012-03/msg00094.html was later applied as http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5481f29161477520c691d525653323b82fa47ad7 and was part of the dejagnu-1.5.2 release from 2015. Jonathan requires 1.5.3 for libstdc++ testing. (i.e. http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347 ) The libdirs fix would allow us to remove the 150 occurrences of the load_gcc_lib hack, refer to the patch to the fortran list back then. AFAIR this is still not fixed: +# BUG: gcc-dg calls gcc-set-multilib-library-path but does not load gcc-defs! debian-stable (i think 9 ATM), Ubuntu LTS ship versions recent enough to contain both fixes. Commercial distros seem to ship fixed versions, too. It seems in May 2020 there was a thread on gcc with about the same subject: https://gcc.gnu.org/pipermail/gcc/2020-May/232427.html where Mike suggests to have approved to bump the required minimum version to 1.5.3. So who's in the position to update the https://gcc.gnu.org/install/prerequisites.html to s/1.4.4/1.5.3/g && git commit -m 'bump dejagnu required version' ? All kinds of people. Submit a patch and I bet it'll get approved. More than anything I suspect it's out-of-sight-out-of-mind at this point holding us back. jeff
gcc-9-20211028 is now available
Snapshot gcc-9-20211028 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20211028/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 9f5ce97030c541227f00588b3858de63f7ec1dad You'll find: gcc-9-20211028.tar.xzComplete GCC SHA256=a5c5441071758b15ff93783c7dbfeb5ae244b95c75f062166897edec70539590 SHA1=98428b19537b3d795562913219065f25ac5de54c Diffs from 9-20211021 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 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.
[PATCH] Bump required minimum DejaGnu version to 1.5.3
From: Bernhard Reutner-Fischer
Bump required DejaGnu version to 1.5.3 (or later).
Ok for trunk?
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)
Here are the patches I worked on today. It does seem to fix KIND=16 to use
Float128, but by not considering long double for KIND processing, it breaks the
tests that want to do ISO C binding to long double.
Feel free to completely ignore the patches and go off in a different
direction. But I thought it would be useful to share what I've done.
> From 443773ac040383311384577b48ecc0bd957ff328 Mon Sep 17 00:00:00 2001
> From: Michael Meissner
> Date: Thu, 28 Oct 2021 23:23:53 -0400
> Subject: [PATCH] Initial patch for PowerPC Fortran KIND=16
This is a work in progress patch. It attempts to make Fortran KIND=16 to
always mean Float128 on PowerPC VSX systems. Unfortunately, in changing
KIND=16 to Float128, it breaks all of the ISO C bindings for long double
support in Fortran.
gcc/
2021-10-28 Michael Meissner
* config/rs6000/rs6000.h (FORTRAN_USE_FLOAT128): New macro.
(FORTRAN_USE_LONG_DOUBLE): New macro.
* tree.h (complex_float128_type_node): Define.
* doc/tm.texi.in (FORTRAN_USE_FLOAT128): Add documentation.
(FORTRAN_USE_LONG_DOUBLE): Likewise.
* doc/tm.texi: Regenerate.
gcc/fortran/
2021-10-28 Michael Meissner
* f95-lang.c (gfc_init_builtin_functions): Flesh out more Float128
support.
* gfortran.h (FORTRAN_USE_LONG_DOUBLE): Provide default
definition.
(FORTRAN_USE_FLOAT128): Likewise.
* trans-types.c (gfc_init_kinds): Add support for
FORTRAN_USE_LONG_DOUBLE and FORTRAN_USE_FLOAT128.
(gfc_build_real_type): Likewise.
(gfc_build_complex_type): Add support for Float128 complex.
---
gcc/config/rs6000/rs6000.h | 10 ++
gcc/doc/tm.texi| 13 +
gcc/doc/tm.texi.in | 13 +
gcc/fortran/f95-lang.c | 28
gcc/fortran/gfortran.h | 13 +
gcc/fortran/trans-types.c | 24 +---
gcc/tree.h | 2 ++
7 files changed, 96 insertions(+), 7 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 3eba1c072cf..4e016e548db 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -2691,3 +2691,13 @@ while (0)
rs6000_asm_output_opcode (STREAM); \
} \
while (0)
+
+/* Whether Fortran should use long double or __float128 for KIND=16. If we
+ support IEEE 128-bit and long double is not IEEE 128-bit, then use the
+ _Float128 type for KIND=16. Otherwise use long double. */
+#undef FORTRAN_USE_FLOAT128
+#define FORTRAN_USE_FLOAT128 (TARGET_FLOAT128_TYPE && !TARGET_IEEEQUAD)
+
+#undef FORTRAN_USE_LONG_DOUBLE
+#define FORTRAN_USE_LONG_DOUBLE(!FORTRAN_USE_FLOAT128)
+
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 902402d7503..13ecca2605c 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -12612,3 +12612,16 @@ counters are incremented using atomic operations.
Targets not supporting
64-bit atomic operations may override the default value and request a 32-bit
type.
@end deftypefn
+
+@defmac FORTRAN_USE_LONG_DOUBLE
+Define this macro to return true if Fortran should enable @code{long
+double} support for @code{KIND} processing. If you do not define this
+macro, Fortran always uses the @code{long double} type.
+@end defmac
+
+@defmac FORTRAN_USE_LONG_DOUBLE
+Define this macro to return true if Fortran should enable
+@code{_Float128} support for @code{KIND} processing. If you do not
+define this macro, Fortran will enable @code{_Float128} support if the
+quadmath library is built, and the mode @code{TFmode} is enabled.
+@end defmac
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 86352dc9bd2..012ef1ecc98 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -8187,3 +8187,16 @@ maintainer is familiar with.
@hook TARGET_MEMTAG_UNTAGGED_POINTER
@hook TARGET_GCOV_TYPE_SIZE
+
+@defmac FORTRAN_USE_LONG_DOUBLE
+Define this macro to return true if Fortran should enable @code{long
+double} support for @code{KIND} processing. If you do not define this
+macro, Fortran always uses the @code{long double} type.
+@end defmac
+
+@defmac FORTRAN_USE_LONG_DOUBLE
+Define this macro to return true if Fortran should enable
+@code{_Float128} support for @code{KIND} processing. If you do not
+define this macro, Fortran will enable @code{_Float128} support if the
+quadmath library is built, and the mode @code{TFmode} is enabled.
+@end defmac
diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index 58dcaf01d75..b8117dc72b4 100644
--- a/gcc/fortran/f95-lang.c
+++ b/gcc/fortran/f95-lang.c
@@ -674,9 +674,11 @@ gfc_init_builtin_functions (void)
tree mfunc_float[6];
tree mfunc_double[6];
tree mfunc_longdouble[6];
+ tree mfunc_float128[6];
tree mfunc_cfloat[6];
tree mfunc_cdouble[6];
tree mfunc_clongdouble[6];
+ tree mfunc_cfloat128[6];
tree func_cfloat_float, func_flo
