mutex destruction in libgcc/unwind-dw2-fde.c

[Rasmus Villemoes]

Hi

The unwind code initializes an object_mutex, but it is never destroyed.
On VxWorks 5 at least, that's a problem, because it means that module
load+unload leaks a resource. I don't know about other VxWorks versions.

I'm wondering what the best fix is (insofar as upstream gcc wants to fix
it, we've used an out-of-tree patch for the past few years, and can
continue to do that).

One option is to destroy it right after the __gthread_mutex_unlock()
call in __deregister_frame_info_bases(), but that assumes that
_Unwind_Find_FDE can no longer get called at that point (which is
true?). We could make it dependent on the target's gthr header file
defining a __GTHREAD_MUTEX_DESTROY_FUNCTION macro as an indication that
the target has some non-trivial work to do for destroying a mutex.

Rasmus

Question on calling possible_polymorphic_call_targets, side effects, and virtual tables.

[Erick Ochoa via Gcc]

Hello,

I have a SIMPLE_IPA_PASS that parses the program multiple times. As it
parses gimple, it builds a data structure with the information
collected that will provide some invariants to future iterations over
the program.

I was looking into adding a new feature that would take advantage of
devirtualization by calling possible_polymorphic_call_targets. All
looks good, a large program that I use for verifying changes seems to
compile nicely. However, as I generate a test file in which I discard
most optimizations (except the one I am currently working on) I
realize that an assertion on my pass is triggered.

I dig in and it looks like I am ignoring error_mark_nodes in varpools'
DECL_INITIAL. The first passes essentially encode the information that
these are error_mark_nodes. On the pass in which I call
possible_polymorphic_call_targets I find that suddenly, these
error_mark_nodes are gone and replaced with a virtual table, thus
triggering the assertion.

Is there a way I can get rid of the error_mark_nodes from the earlier
passes to match the changes brought by
possible_polymorphic_call_targets? I suppose that finding
polymorphic_call_targets at an earlier stage is a possibility, but I
was wondering exactly which function/statement is able to fix these
error_mark_nodes so that I can also learn about this.

Thanks!

Re: Question on calling possible_polymorphic_call_targets, side effects, and virtual tables.

[Jan Hubicka via Gcc]

> Hello,
> 
> I have a SIMPLE_IPA_PASS that parses the program multiple times. As it
> parses gimple, it builds a data structure with the information
> collected that will provide some invariants to future iterations over
> the program.
> 
> I was looking into adding a new feature that would take advantage of
> devirtualization by calling possible_polymorphic_call_targets. All
> looks good, a large program that I use for verifying changes seems to
> compile nicely. However, as I generate a test file in which I discard
> most optimizations (except the one I am currently working on) I
> realize that an assertion on my pass is triggered.
> 
> I dig in and it looks like I am ignoring error_mark_nodes in varpools'
> DECL_INITIAL. The first passes essentially encode the information that
> these are error_mark_nodes. On the pass in which I call
> possible_polymorphic_call_targets I find that suddenly, these
> error_mark_nodes are gone and replaced with a virtual table, thus
> triggering the assertion.
> 
> Is there a way I can get rid of the error_mark_nodes from the earlier
> passes to match the changes brought by
> possible_polymorphic_call_targets? I suppose that finding
> polymorphic_call_targets at an earlier stage is a possibility, but I
> was wondering exactly which function/statement is able to fix these
> error_mark_nodes so that I can also learn about this.

Like function bodies the initializers are read on demand.
If you call get_constructor (varpool_node) you will trigger the lazy
stream in.

Honza
> 
> Thanks!

How to run C++ IPA tests?

[Erick Ochoa via Gcc]

Hi,

I have been adding tests to the gcc/testsuite/gcc.dg/ipa folder
successfully for a while now. I am starting to add some tests into
gcc/testsuite/g++.dg/ipa now but I am having some issues.

1. Using `make check-g++` returns the following error message "No rule
to make target 'check-g++'".
2. While `make check-gcc` works, this seems to be only for C tests
(which is correct).
3. When I type `make check RUNTESTS="ipa.exp"`  but the section "g++
Summary" looks empty.
4. I have added a test that I know will fail, but I don't see it
(because I don't think I have run g++ tests correctly).

To make sure that I haven't changed anything with my transformation I
actually checked out releases/gcc-11.2.0

Can someone tell me how to run the C++ IPA tests? I'm sure there is
something silly that I'm doing wrong, but can't find out what it is.

Thanks!

Re: How to run C++ IPA tests?

[Marek Polacek via Gcc]

On Wed, Oct 27, 2021 at 04:29:32PM +0200, Erick Ochoa via Gcc wrote:
> Hi,
> 
> I have been adding tests to the gcc/testsuite/gcc.dg/ipa folder
> successfully for a while now. I am starting to add some tests into
> gcc/testsuite/g++.dg/ipa now but I am having some issues.
> 
> 1. Using `make check-g++` returns the following error message "No rule
> to make target 'check-g++'".
> 2. While `make check-gcc` works, this seems to be only for C tests
> (which is correct).
> 3. When I type `make check RUNTESTS="ipa.exp"`  but the section "g++
> Summary" looks empty.
> 4. I have added a test that I know will fail, but I don't see it
> (because I don't think I have run g++ tests correctly).
> 
> To make sure that I haven't changed anything with my transformation I
> actually checked out releases/gcc-11.2.0
> 
> Can someone tell me how to run the C++ IPA tests? I'm sure there is
> something silly that I'm doing wrong, but can't find out what it is.

There's no ipa.exp in gcc/testsuite/g++.dg/ipa.  Instead you probably
want

make check-c++ RUNTESTFLAGS=dg.exp=ipa/*

Marek

Re: How to run C++ IPA tests?

[Prathamesh Kulkarni via Gcc]

On Wed, 27 Oct 2021 at 20:09, Marek Polacek via Gcc  wrote:
>
> On Wed, Oct 27, 2021 at 04:29:32PM +0200, Erick Ochoa via Gcc wrote:
> > Hi,
> >
> > I have been adding tests to the gcc/testsuite/gcc.dg/ipa folder
> > successfully for a while now. I am starting to add some tests into
> > gcc/testsuite/g++.dg/ipa now but I am having some issues.
> >
> > 1. Using `make check-g++` returns the following error message "No rule
> > to make target 'check-g++'".
> > 2. While `make check-gcc` works, this seems to be only for C tests
> > (which is correct).
> > 3. When I type `make check RUNTESTS="ipa.exp"`  but the section "g++
> > Summary" looks empty.
> > 4. I have added a test that I know will fail, but I don't see it
> > (because I don't think I have run g++ tests correctly).
> >
> > To make sure that I haven't changed anything with my transformation I
> > actually checked out releases/gcc-11.2.0
> >
> > Can someone tell me how to run the C++ IPA tests? I'm sure there is
> > something silly that I'm doing wrong, but can't find out what it is.
>
> There's no ipa.exp in gcc/testsuite/g++.dg/ipa.  Instead you probably
> want
>
> make check-c++ RUNTESTFLAGS=dg.exp=ipa/*
Perhaps make check-gcc-c++ would be slightly better (to avoid running
tests for libitm, libgomp etc) ?

Thanks,
Prathamesh
>
> Marek
>

Re: LPC and other questions ?

[Martin Jambor]

Hi,

On Mon, Oct 25 2021, Joseph Watanabe wrote:
> Hello and good morning,
>
> Recently I had the privilege of stumbling upon a few of the videos on
> youtube. I really found them helpful, and learned quite a bit. I will
> say I probably have to watch them a few more times to even begin to
> have a level of understanding that everyone had years ago Anyway,
> there are a few things I noticed and wanted to reach out.
>
> From the list of sponsors, I thought the company that I work with
> would be one as well, but more than likely there are no one aware.. I
> am not in any position to make any decisions on that level at all, but
> I don't think it would hurt if you could describe to me the process
> and I could forward that information to someone.. somewhere..

The toolchain track at the LPC has started as a replacement of an
otherwise in-person conference called GNU Tools Cauldron in times when
in-person events are difficult to organize.  Many of us hope that we
will have a Cauldron again next year, I am not sure what it will mean
for the track at LPC.  It might not happen.

If you think your employer would be interested in sponsoring the
Cauldron, please reach out to tools-cauldron-ad...@googlegroups.com.

If you are interested in an LPC track only, you'll have to find some
equivalent contact at the https://linuxplumbersconf.org page.

> Anyway, I was also wondering about rust ? I have not used it yet,
> usually I use gcc/gcc-c++/gcc-gfortran for most cases. Is there
> another webpage I could check out also?

The rust FE team publishes a regular (monthly?) report on their
progress, the last one is at:

https://github.com/Rust-GCC/Reporting/blob/main/2021-10-25-report.org

Hope this helps,

Martin

__builtin_addc support??

[sotrdg sotrdg via Gcc]

79173 – add-with-carry and subtract-with-borrow support (x86_64 and others) 
(gnu.org)

What I find quite interesting is things like this.

Since llvm clang provides __builtin_addc __builtin_subc for all targets. Can we 
provide something similar? Since currently no solutions we can access carry 
flag besides x86

Sent from Mail for Windows

Re: __builtin_addc support??

[Paul Koning via Gcc]

> On Oct 27, 2021, at 12:12 PM, sotrdg sotrdg via Gcc  wrote:
> 
> 79173 – add-with-carry and subtract-with-borrow support (x86_64 and others) 
> (gnu.org)
> 
> What I find quite interesting is things like this.
> 
> Since llvm clang provides __builtin_addc __builtin_subc for all targets. Can 
> we provide something similar? Since currently no solutions we can access 
> carry flag besides x86

Certainly some other targets could do this.  The LLVM builtins explicitly 
expose carry, which isn't actually what you want (you'd want the carry flag in 
the condition code to be propagated).  Presumably optimization would eliminate 
those explicit arguments and reduce them to CC references.

paul

RE: __builtin_addc support??

[sotrdg sotrdg via Gcc]

I just want a portable version of __builtin_addcarry and __builtin_subborrow. 
Of course if we have things __builtin_rcl and __builtin_rcr would be even 
better.

Sent from Mail for Windows

From: Paul Koning
Sent: Wednesday, October 27, 2021 12:36
To: sotrdg sotrdg
Cc: GCC Development; 
gcc-requ...@gcc.gnu.org; 
gcc-h...@gcc.gnu.org
Subject: Re: __builtin_addc support??



> On Oct 27, 2021, at 12:12 PM, sotrdg sotrdg via Gcc  wrote:
>
> 79173 – add-with-carry and subtract-with-borrow support (x86_64 and others) 
> (gnu.org)
>
> What I find quite interesting is things like this.
>
> Since llvm clang provides __builtin_addc __builtin_subc for all targets. Can 
> we provide something similar? Since currently no solutions we can access 
> carry flag besides x86

Certainly some other targets could do this.  The LLVM builtins explicitly 
expose carry, which isn't actually what you want (you'd want the carry flag in 
the condition code to be propagated).  Presumably optimization would eliminate 
those explicit arguments and reduce them to CC references.

paul

Re: dejagnu version update?

[Bernhard Reutner-Fischer via Gcc]

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' ?

Just asking patiently and politely.
I don't want to rush anybody into such a bump :)

But as you may remember, folks routinely run afoul of using too old
versions (without the 5256bd8 multilib prepending for example, recently
someone doing ARM stuff IIRC) so a bump would just be fair IMHO.

Maybe now, for gcc-12, is the time to bump prerequisites to 1.5.3?

thanks and sorry for my impatience (and, once again, the noise).
cheers,

Re: __builtin_addc support??

[Segher Boessenkool]

On Wed, Oct 27, 2021 at 04:12:27PM +, sotrdg sotrdg via Gcc-help wrote:
> 79173 – add-with-carry and subtract-with-borrow support (x86_64 and others) 
> (gnu.org)
> 
> What I find quite interesting is things like this.
> 
> Since llvm clang provides __builtin_addc __builtin_subc for all targets. Can 
> we provide something similar? Since currently no solutions we can access 
> carry flag besides x86

Why?  We have __builtin_add_overflow, which is a smaller factor, and
enough to build up any bigger factors with.  You can easily write the
same thing in standard C of course, which often is a better plan.

If you want exact machine insns as output, write those, i.e., write
assembler code, not C.  Builtins are not there to please the "C is a
portable assembler" crowd: they are there to expose functionality you
cannot (conveniently) get using just pure standard C.


Segher

RE: __builtin_addc support??

[sotrdg sotrdg via Gcc]

LOL

https://github.com/tearosccebe/fast_io/blob/4ca355fcbf31aa26a0259ad09671eaab899930fc/include/fast_io_core_impl/intrinsics.h#L366

You are wrong dude.
Give me solution for addcarry

Sent from Mail for Windows


From: Segher Boessenkool 
Sent: Wednesday, October 27, 2021 7:16:41 PM
To: sotrdg sotrdg 
Cc: gcc@gcc.gnu.org ; gcc-requ...@gcc.gnu.org 
; gcc-h...@gcc.gnu.org 
Subject: Re: __builtin_addc support??

On Wed, Oct 27, 2021 at 04:12:27PM +, sotrdg sotrdg via Gcc-help wrote:
> 79173 – add-with-carry and subtract-with-borrow support (x86_64 and others) 
> (gnu.org)
>
> What I find quite interesting is things like this.
>
> Since llvm clang provides __builtin_addc __builtin_subc for all targets. Can 
> we provide something similar? Since currently no solutions we can access 
> carry flag besides x86

Why?  We have __builtin_add_overflow, which is a smaller factor, and
enough to build up any bigger factors with.  You can easily write the
same thing in standard C of course, which often is a better plan.

If you want exact machine insns as output, write those, i.e., write
assembler code, not C.  Builtins are not there to please the "C is a
portable assembler" crowd: they are there to expose functionality you
cannot (conveniently) get using just pure standard C.


Segher

RE: __builtin_addc support??

[sotrdg sotrdg via Gcc]

HEY. ZERO COST ABSTRACTIONS lol

Sent from Mail for Windows

From: Segher Boessenkool
Sent: Wednesday, October 27, 2021 19:17
To: sotrdg sotrdg
Cc: gcc@gcc.gnu.org; 
gcc-requ...@gcc.gnu.org; 
gcc-h...@gcc.gnu.org
Subject: Re: __builtin_addc support??

On Wed, Oct 27, 2021 at 04:12:27PM +, sotrdg sotrdg via Gcc-help wrote:
> 79173 – add-with-carry and subtract-with-borrow support (x86_64 and others) 
> (gnu.org)
>
> What I find quite interesting is things like this.
>
> Since llvm clang provides __builtin_addc __builtin_subc for all targets. Can 
> we provide something similar? Since currently no solutions we can access 
> carry flag besides x86

Why?  We have __builtin_add_overflow, which is a smaller factor, and
enough to build up any bigger factors with.  You can easily write the
same thing in standard C of course, which often is a better plan.

If you want exact machine insns as output, write those, i.e., write
assembler code, not C.  Builtins are not there to please the "C is a
portable assembler" crowd: they are there to expose functionality you
cannot (conveniently) get using just pure standard C.


Segher

[PATCH] Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[H.J. Lu via Gcc]

Motivations:

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.

Here is a proposal to encode glibc version dependencies in relocatable
objects:

/* The glibc 2 minor versions needed by the object file. */
 #define GNU_PROPERTY_1_GLIBC_2_NEEDED   (GNU_PROPERTY_UINT32_OR_LO + 1)

/* The lowest glibc 2 minor version.  */
 #define GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_BASE 35

/* Set if the object file requires glibc 2 minor version M.  */
 #define GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_VERSION(m)  \
  (1U << ((m) - GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_BASE))

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.

[hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n x.o

Displaying notes found in: .note.gnu.property
  OwnerData sizeDescription
  GNU  0x0020   NT_GNU_PROPERTY_TYPE_0
  Properties: x86 ISA used:
x86 feature used: x86
[hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n glibc-2-minor-1.o

Displaying notes found in: .note.gnu.property
  OwnerData sizeDescription
  GNU  0x0010   NT_GNU_PROPERTY_TYPE_0
  Properties: 1_glibc_2_needed: 2.35, 2.38
  GNU  0x0020   NT_GNU_PROPERTY_TYPE_0
  Properties: x86 ISA used:
x86 feature used: x86
[hjl@gnu-cfl-2 elfvers-1]$ make x
gcc -B./ -o x x.o glibc-2-minor-1.o
[hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n --version-info x
Version symbols section '.gnu.version' contains 4 entries:
 Addr: 0x004004ae  Offset: 0x0004ae  Link: 6 (.dynsym)
  000:   0 (*local*)   2 (GLIBC_2.34)3 (GLIBC_2.2.5)   1 (*global*)

Version needs section '.gnu.version_r' contains 1 entry:
 Addr: 0x004004b8  Offset: 0x0004b8  Link: 7 (.dynstr)
  00: Version: 1  File: libc.so.6  Cnt: 4
  0x0010:   Name: GLIBC_2.38  Flags: none  Version: 5
  0x0020:   Name: GLIBC_2.35  Flags: none  Version: 4
  0x0030:   Name: GLIBC_2.2.5  Flags: none  Version: 3
  0x0040:   Name: GLIBC_2.34  Flags: none  Version: 2
...
[hjl@gnu-cfl-2 elfvers-1]$ ./x
./x: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by ./x)
./x: /lib64/libc.so.6: version `GLIBC_2.35' not found (required by ./x)
[hjl@gnu-cfl-2 elfvers-1]$
---
 object-files.tex | 50 
 1 file changed, 50 insertions(+)

diff --git a/object-files.tex b/object-files.tex
index 834f508..41a434c 100644
--- a/object-files.tex
+++ b/object-files.tex
@@ -444,6 +444,7 @@ The following program property types are defined:
   \texttt{GNU_PROPERTY_UINT32_AND_HI} & \texttt{0xb0007fff} \\
   \texttt{GNU_PROPERTY_UINT32_OR_LO} & \texttt{0xb0008000} \\
   \texttt{GNU_PROPERTY_1_NEEDED} & \texttt{GNU_PROPERTY_UINT32_OR_LO + 0} 
\\
+  \texttt{GNU_PROPERTY_1_GLIBC_2_NEEDED} & 
\texttt{GNU_PROPERTY_UINT32_OR_LO + 1} \\
   \texttt{GNU_PROPERTY_UINT32_OR_HI} & \texttt{0xb000} \\
   \texttt{GNU_PROPERTY_LOPROC} & \texttt{0xc000} \\
   \texttt{GNU_PROPERTY_HIPROC} & \texttt{0xdfff} \\
@@ -492,6 +493,11 @@ The following program property types are defined:
  \item[GNU_PROPERTY_1_NEEDED]
The \code{pr_data} field contains a 4-byte integer to indicate the
properties needed by object file.
+ \item[GNU_PROPERTY_1_GLIBC_2_NEEDED]
+   The \code{pr_data} field contains a 4-byte integer to indicate the
+   minor versions of the GNU C library version 2 needed by object file.
+   This property is only valid in relocatable object files.  Linker
+   should not add it to executables nor shared libraries.
  \item[GNU_PROPERTY_LOPROC through GNU_PROPERTY_HIPROC]
Values in this inclusive range are reserved for processor-specific
semantics.
@@ -528,6 +534,50 @@ The following bits are defined for 
\code{GNU_PROPERTY_1_NEEDED}:
\end{sloppypar}
 \end{description}
 
+The following values are defined for \code{GNU_PROPERTY_1_GLIBC_2_NEEDED}:
+
+\begin{table}[H]
+\Hrule
+  \caption{GNU_PROPERTY_1_GLIBC_2_NEEDED Values}
+  \begin{center}
+\begin{footnotesize}
+  \begin{tabular}[t]{l|l}
+\multicolumn{1}{c}{Name} & \multicolumn{1}{c}{Value} \\
+\hline
+ \texttt{GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_BASE} & \texttt{35} \\
+ \texttt{GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_VERSION(m)}
+   & \texttt{1U << (m - 35)} \\
+  \end{tabular}
+\end{footnotesize}
+  \end{center}
+\Hrule
+\end{table}
+
+\begin{description}
+ \item[GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_BASE]
+   \begin{sloppypar}
+   This specifies the oldes

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Michael Meissner via Gcc]

I've played with some patches to PowerPC to set the defaults for fortran.  But
without doing a full rebuild like you would do with a new distribution, I think
it will be problematical, unless you build everything with the default long
double set to IEEE 128-bit.

First off all, libquadmath is currently built on Linux 64-bit systems.  I never
removed building libquadmath once we got the official glibc 2.34 support

So to go in more detail of what I've tried.

I added an undocumented switch -mfortran that says set the defaults for
Fortran.  This switch would be used to build libgfortran, and also set with
TARGET_F951_OPTIONS for all Fortran invocations.

I tried to switch to float128_type_node instead of long_double_type_node.  I
ran into problems with gimplify in that it could not do a conversion from
_Float128 to float.  I suspect I didn't actually use the right type.

I then went to patches where -mfortran silently switches the long double type
to IEEE 128-bit.  There you get into various compatibility issues where the
linker complains that you are calling between the different long double types.

For instance because we are still building libquadmath, libquadmath is marked
as having long double being IBM 128-bit, but it is called from Fortran modules
that have long double being IEEE 128-bit.  I then did a build supressing
building libquadmath since I was using LE with glibc 2.34, and I got much
further.  This time instead of a lot of failures, I got 29 failures, due to
libgfortran still being marked as IBM long double and the fortran modules are
marked as IEEE long double.

Right now, the only way to avoid these things is to build the entire toolchain
defaulting to IEEE 128-bit.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

Re: [llvm-dev] [PATCH] Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[Florian Weimer via Gcc]

* 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.

Thanks,
Florian