[Bug c++/33521] New: -m128bit-long-double and printf don't mix

[Bug c++/33521] New: -m128bit-long-double and printf don't mix

[Raf_Schietekat at ieee dot org]

[#include <stdlib.h> // EXIT_SUCCESS
#include <stdio.h> // printf

int main(int argc, char** argv) {
    long double ld = 1.0;
    printf("ld = %Lg, string = %s\n", ld, "foo");
    return (EXIT_SUCCESS);
}]

[g++ -m128bit-long-double -Wall main.cpp -o test && ./test]

With the wider long double, a corrupted value is printed at %s. If the ld
declaration is changed to [long double ld = 1.0, lda[10];], nothing is printed,
and if the declaration is changed to [long double ld = 1.0, lda[10000];],
"(null)" is printed (without the quotes). If the -m128bit-long-double flag is
omitted, or if the %Lg is omitted (and its corresponding argument), no problems
occur (although I have not tested all 12 combinations). If this shouldn't be
tried at all (printf is in a library that was compiled with normal-width long
doubles), it would be nice to at least have a warning about it, but there seems
to be more than that going on. I may have no further interest in this issue,
which was encountered during some experiments.


-- 
           Summary: -m128bit-long-double and printf don't mix
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: Raf_Schietekat at ieee dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33521

[Bug c++/33521] -m128bit-long-double and printf don't mix

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-09-21 19:18 -------
And -m128bit-long-double is an ABI change so what do you expect???


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33521

[Bug c++/33521] -m128bit-long-double and printf don't mix

[Raf_Schietekat at ieee dot org]

------- Comment #2 from Raf_Schietekat at ieee dot org  2007-09-21 21:36 -------
If anything, not to be snapped at.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33521

[Bug c++/33521] -m128bit-long-double and printf don't mix

[bangerth at dealii dot org]

------- Comment #3 from bangerth at dealii dot org  2007-09-22 04:10 -------
It seems rather hard to diagnose this. If you change the ABI by using
a floating point representation using a different size of builtin types,
you probably have to build all libraries that you link with with the same
flags or the kind of wreak that you describe will happen.

Now, the bigger question is of course whether the compiler can help you
detect the case where you ignore that rule, i.e. compile an object file 
created with -m128bit-long-double with a libc that was compiled without.
The compiler is, in this case, actually the wrong tool to do so -- if
anything, the linker could do that, but it would have to have some sort
of clue that the object files (or libraries) that you link together were
created with incompatible flags -- and worse that you also intend to call
functions that will be incompatible with each other if called across
object file boundaries.

I think that we don't want to go down this avenue. It probably amounts to
solving the halting problem if the linker had to make that determination.
For example, it may be that you didn't re-compile your libc but never intended
to call any libc functions that take floating point arguments. Then there is
no danger. Or you intend to call printf which takes all arguments through ...
and therefore transparently to the linker. So if you call printf only ever with
integer arguments, then your program is ok, but if you call it with fp args
then you're in trouble.

I guess this is a case where we simply have to trust that you know what you're
doing because trying to second guess will just lead to an incredible complex
code that will be wrong too often...

So I concur with Andrew, though I think he could have explained things a bit
nicer :-)

W.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at dealii dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33521

[Bug c++/33521] -m128bit-long-double and printf don't mix

[Raf_Schietekat at ieee dot org]

------- Comment #4 from Raf_Schietekat at ieee dot org  2007-09-22 19:47 -------
Thanks. Somehow I had managed to miss that warning in the flag's documentation
and came up with some of it on my own, but at the same time I thought that each
object file would/could be marked with how it was compiled so that the linker
could check this whenever a long double is involved (even for arguments to
"..." if a place is found to store that information, given that gcc can do
other fancy things like comparing an argument list with the format string), to
warn and/or to juggle things around where possible using some ad-hoc glue code.
I was also thinking that this should instead be done with pragma's so that the
compiler is aware of all the issues (for anything else than bare long doubles,
linker glue code would become expensive or impossible). Anyway, I'll probably
give this flag a wide berth and my only suggestion is for some more guidance on
its use.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33521

[Bug c++/33521] -m128bit-long-double and printf don't mix

[bangerth at math dot tamu dot edu]

------- Comment #5 from bangerth at math dot tamu dot edu  2007-09-22 22:14 -------
Subject: Re:  -m128bit-long-double and printf don't mix


> and came up with some of it on my own, but at the same time I thought that each
> object file would/could be marked with how it was compiled so that the linker
> could check this whenever a long double is involved (even for arguments to

The linker would have to learn about gcc options, but even if it did it
wouldn't be able to diagnose the problem since all it sees is that data is
being moved through a register or from memory to memory -- it has no idea
any more about the semantic meaning of this data.

I think there really isn't very much one can do here except say "be
careful with this option" in the manual. This is, as I believe, what we
do, when we say in the manual:
------------------------
@strong{Warning:} if you override the default value for your target ABI, the
structures and arrays containing @code{long double} variables will change
their size as well as function calling convention for function taking
@code{long double} will be modified.  Hence they will not be binary
compatible with arrays or structures in code compiled without that switch.
------------------------

W.

-------------------------------------------------------------------------
Wolfgang Bangerth                email:            bangerth@math.tamu.edu
                                 www: http://www.math.tamu.edu/~bangerth/


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33521

[Bug c++/33521] -m128bit-long-double and printf don't mix

[Raf_Schietekat at ieee dot org]

------- Comment #6 from Raf_Schietekat at ieee dot org  2007-09-23 00:29 -------
I don't know, for a debug build with symbolic information a GNU linker just
might be able to make sense of it... but I accept it would not be worthwhile.
As for the documentation, it seems the "additional 32 bit zero" actually
contains garbage, unlike the first 16 bit zero.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33521