On Wed, Feb 01, 2023 at 12:29:02PM +0100, Florian Weimer via Gcc wrote:
> >> This impacts most (all?) Fortran code on GNU/Linux because libgfortran
> >> depends on libquadmath.
> >
> > Not anymore.
> > If GCC is configured against new enough glibc (with _Float
* Jakub Jelinek:
> On Wed, Feb 01, 2023 at 11:56:42AM +0100, Florian Weimer via Gcc wrote:
>> I recently discovered that libquadmath registers custom printf callbacks
>> on load. As far as I can tell, this is done so that the Q format flag
>> can be used to print floating
On Wed, Feb 01, 2023 at 11:56:42AM +0100, Florian Weimer via Gcc wrote:
> I recently discovered that libquadmath registers custom printf callbacks
> on load. As far as I can tell, this is done so that the Q format flag
> can be used to print floating point numbers, using format strings
I recently discovered that libquadmath registers custom printf callbacks
on load. As far as I can tell, this is done so that the Q format flag
can be used to print floating point numbers, using format strings such
as "%Qf". To enable Q flag processing, libquadmath has to register
re
On Mon, Dec 13, 2021 at 09:29:16PM +0100, Thomas Koenig wrote:
>
> Hi,
>
> looking at what the REAL(KIND=17) numbers should be compiled for, I see
> the following options that should be considered:
>
> a) xsaddqp and friends are not supported by the CPU; libquadmath shou
Hi,
looking at what the REAL(KIND=17) numbers should be compiled for, I see
the following options that should be considered:
a) xsaddqp and friends are not supported by the CPU; libquadmath should
be called for all operations, including simple arithmetic.
b) xsaddqp and friends are
>> The following works for me:
>>
>> __float128 *x = calloc(sizeof(__float128), 8);
>
> Well, this does not work for me. The code compiles, but during execution
> the program crashes in this place.
You will need to investigate the crash in detail, then. Maybe it is due to
memory alignment, and
Hello Bienisaz,
> I have managed to compile the program using the quadmath, but the
> program works only if the libquadmath-0.dll is supplied in a working
> directory. I notice that there were some controversies on the internet,
> concerning the issue of static linking of the quad
On 8/8/2017 4:17 PM, Joseph Myers wrote:
On Tue, 8 Aug 2017, Joel Sherrill wrote:
This may be a stupid question but with the focus of this
discussionon glibc, what does this all mean for non-glibc
targets?
Well, Jakub recently updated parts of libquadmath from glibc (only the
functions
On Tue, 8 Aug 2017, Joel Sherrill wrote:
> This may be a stupid question but with the focus of this
> discussionon glibc, what does this all mean for non-glibc
> targets?
Well, Jakub recently updated parts of libquadmath from glibc (only the
functions coming from the ldbl-128 direc
On 8/8/2017 12:44 PM, Joseph Myers wrote:
On Tue, 8 Aug 2017, Janne Blomqvist wrote:
On a semi-related note, it seems the recently released glibc 2.26
contains quad math functions. Does that mean we should change to use
those in preference to libquadmath when available? I suppose
libquadmath
On Tue, 8 Aug 2017, Janne Blomqvist wrote:
> On a semi-related note, it seems the recently released glibc 2.26
> contains quad math functions. Does that mean we should change to use
> those in preference to libquadmath when available? I suppose
> libquadmath cannot be deprecated e
On Tue, Aug 8, 2017 at 3:10 PM, Manfred Schwarb wrote:
> Am 27.07.2017 um 15:24 schrieb Manfred Schwarb:
>> Hi,
>>
>> there is the long standing annoyance that it is very hard to
>> statically compile in libquadmath.
>> See https://gcc.gnu.org/bugzilla/s
On Wed, 15 Oct 2014, FX wrote:
> I sent my last “driver/options” patch to Neil Booth, listed as “option
> handling” maintainer, but the email bounced back from his
> daikokuya.co.uk address. Given that he did not commit to the tree since
> January 2005 (almost 10 years), and that his last commit
Hi,
I sent my last “driver/options” patch to Neil Booth, listed as “option
handling” maintainer, but the email bounced back from his daikokuya.co.uk
address. Given that he did not commit to the tree since January 2005 (almost 10
years), and that his last commit was to the toplevel ChangeLog:
2
Syed Bilal Mehdi writes:
> I am not sure where to put this message, but can anyone tell me where I can
> find source for libquadmath.
It's in the libquadmath directory in the gcc sources. If you don't know
what that means, then, for future reference, this message should have
be
Hello,
I am not sure where to put this message, but can anyone tell me where I can
find source for libquadmath. Furthermore, is it possible to build it using
old version of gcc (gcc4.1 to be precise)?
Thanks in advance
--
View this message in context:
http://old.nabble.com/how-to-get
Jakub, Tobias --
The GCC SC has appointed you as maintainers of libquadmath within GCC.
Please update the MAINTAINERS file to reflect your new positions.
Congratulations!
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
On 12/21/2010 03:44 PM, Tobias Burnus wrote:
Joel Sherrill wrote:
I was experimenting with adding microblaze-rtems*
and got this error:
>
checking for sqrtl in -lm... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libquadmath] Erro
Joel Sherrill wrote:
I was experimenting with adding microblaze-rtems*
and got this error:
>
checking for sqrtl in -lm... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libquadmath] Error 1
I am puzzled: While this issue existed,
sers/joel/test-gcc/install-svn/microblaze-rtems4.11/include -isystem
> /users/joel/test-gcc/install-svn/microblaze-rtems4.11/sys-include-E
> checking for sqrtl in -lm... configure: error: Link tests are not
> allowed after GCC_NO_EXECUTABLES.
> make[1]: *** [configure-target-libquadmath]
/test-gcc/install-svn/microblaze-rtems4.11/include -isystem
/users/joel/test-gcc/install-svn/microblaze-rtems4.11/sys-include-E
checking for sqrtl in -lm... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libquadmath] Error 1
This looks like
Hello,
given that the has been quite some libquadmath-related configure work:
Are there still build problems due to link tests if one cross-builds for
bare-iron targets? Or not? (Cf. PR 46520)
If so, I would start to tackle them next.
(As work around, one can now use --disable-libquadmath
files are used only by the driver - and neither by the
proper compiler (f951, cc1, etc.) nor by the generated executable.
However, besides the compiled in files, the driver also reads spec files
when it is run. That happens, e.g., for linking OpenMP (-fopenmp) or
since the addition of libquadmath
the right (64-bit) libgcc_s.so.1 at runtime, due to a bug in the
>> construction of LD_LIBRARY_PATH in the testsuite. This worked before
>> and is broken now, due to the libquadmath patch.
>
> I am not sure the bug is the same, but they are related. Both are about
> finding t
Ralf Wildenhues writes:
>> the Automake manual can be read otherwise: ch. 8.3.7 `_LIBADD',
>> `_LDFLAGS', and `_LIBTOOLFLAGS' states:
>>
>> As shown in previous sections, the `LIBRARY_LIBADD' variable should be
>> used to list extra libtool objects (`.lo' files) or libtool libraries
>> (`.
construction of LD_LIBRARY_PATH in the testsuite. This worked before
and is broken now, due to the libquadmath patch.
I am not sure the bug is the same, but they are related. Both are about
finding the .spec file at run time; once for the installed system and
once for the test-suite run. My plan is f
* Rainer Orth wrote on Thu, Nov 18, 2010 at 06:32:59PM CET:
> Ralf Wildenhues writes:
> > * Rainer Orth wrote on Wed, Nov 17, 2010 at 09:15:55PM CET:
> >>
> >> * One cannot -lm to libquadmath_la_LIBADD since that gets passed to nm,
> >> which doesn't know (and doesn't need to be run) -lm.
> >
>
Ralf Wildenhues writes:
> * Rainer Orth wrote on Wed, Nov 17, 2010 at 09:15:55PM CET:
>>
>> * One cannot -lm to libquadmath_la_LIBADD since that gets passed to nm,
>> which doesn't know (and doesn't need to be run) -lm.
>
> That's a bug in the rule using nm then, though.
I'm not completely su
think so: this seems to be an issue finding libgfortran.spec at
compile time (which seems to work for me), while my issue is about
finding the right (64-bit) libgcc_s.so.1 at runtime, due to a bug in the
construction of LD_LIBRARY_PATH in the testsuite. This worked before
and is brok
stion?
And, do you have time to review my patch at:
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01851.html
Regarding the first part, i.e. whether libquadmath should only be build
with Fortran or always, there is no consensus; so far I only saw two
definite statements and a couple of no-opini
* Rainer Orth wrote on Wed, Nov 17, 2010 at 09:15:55PM CET:
>
> * One cannot -lm to libquadmath_la_LIBADD since that gets passed to nm,
> which doesn't know (and doesn't need to be run) -lm.
That's a bug in the rule using nm then, though.
> Again, as in
> libjava/Makefile.am, I've moved it
Rainer Orth wrote:
While the build completed with the patch I've posted, fortran testing
for the non-default multilib is completely broken, e.g.
That's in a way the a duplicate of PR 46516. Or at least the solution is
similar: Getting rid of libgfortran.spec and fall back (again) to having
th
_PATH to
.:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libgfortran/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libgfortran/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libquadmath/.libs:/var/gcc/regression/trunk/
Ralf Wildenhues writes:
> * Tobias Burnus wrote on Wed, Nov 17, 2010 at 08:20:39PM CET:
>> b) Building with a cross compiler is not supported by the
>> libquadmath configure script
>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520
>
> You should probably
* Tobias Burnus wrote on Wed, Nov 17, 2010 at 08:20:39PM CET:
> b) Building with a cross compiler is not supported by the
> libquadmath configure script
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520
You should probably try out GCC_NO_EXECUTABLES in configure.ac
and check with a
Art Haas wrote:
My build this morning failed when libquadmath was being built. Things
failed when configuring in the 'amd64' subdirectory - the bits below
are taken from the 'config.log' in that directory:
There are two known problems:
a) libquadmath should - at least for
Hi.
My build this morning failed when libquadmath was being built. Things
failed when configuring in the 'amd64' subdirectory - the bits below
are taken from the 'config.log' in that directory:
configure:3040: /export/home/arth/gnu/gcc-1117/./gcc/xgcc
-B/export/home/arth/gnu
38 matches
Mail list logo
