On Wed, Jul 3, 2019 at 12:49 PM Torbjörn Granlund wrote:
>
> Richard Biener writes:
>
> So yes, building a shared object with the data exported is probably
> more future-proof ;)
>
> Indded. But I don't know how to do that portably.
>
> Let the perfect not be the enemy of the good here.
>
Marc Glisse writes:
Without #include , some compilers reject it. Also, the string
should be "%d %f" (or replace '+' with ',' in the arguments).
Thanks, fixed!
--
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmpli
Richard Biener writes:
So yes, building a shared object with the data exported is probably
more future-proof ;)
Indded. But I don't know how to do that portably.
Let the perfect not be the enemy of the good here.
Don't tease Vincent like that! :-)
--
Torbjörn
Please encrypt, key id 0x
Vincent Lefevre writes:
C99 says: "An object that has volatile-qualified type may be modified
in ways unknown to the implementation or have other unknown side
effects. Therefore any expression referring to such an object shall
be evaluated strictly according to the rules of the abstract m
On 2019-07-03 10:45:24 +0200, Richard Biener wrote:
> On Wed, Jul 3, 2019 at 9:49 AM Vincent Lefevre wrote:
> > Here, after loop enrolling, the compiler could see that the arguments
> > are known and generate a fixed puts(). This kind of optimization must
> > not be done with a structure declared
On Wed, Jul 3, 2019 at 9:49 AM Vincent Lefevre wrote:
>
> On 2019-07-02 12:41:15 +0200, Torbjorn Granlund wrote:
> > Richard Biener writes:
> >
> > On Mon, Jul 1, 2019 at 11:13 PM Torbjörn Granlund wrote:
> > >
> > > Vincent Lefevre writes:
> > >
> > > Yes, with LTO, the object file
On 2019-07-02 12:41:15 +0200, Torbjorn Granlund wrote:
> Richard Biener writes:
>
> On Mon, Jul 1, 2019 at 11:13 PM Torbjörn Granlund wrote:
> >
> > Vincent Lefevre writes:
> >
> > Yes, with LTO, the object file does not contain the structure as is.
> > Thus the detection from "
On Tue, 2 Jul 2019, Torbjörn Granlund wrote:
The main funcion is needed as we create an executable, its references to
foo are needed, else LTO will remove foo altogether.
*** /tmp/extdiff.MsIr0g/gmp-main.3300fbb5d615/acinclude.m4 Mon Jun 17
00:11:50 2019
--- /home/tege/prec/gmp-main/acinc
Richard Biener writes:
Yes, this should work. It probably has a slightly higher chance of
mismatching the start/end patterns elsewhere in the file, but well...
Thanks for checking my proposed patch!
Yes, I realise that we could get unlucky now, something which really
shouldn't happen with
On Tue, Jul 2, 2019 at 12:41 PM Torbjörn Granlund wrote:
>
> Richard Biener writes:
>
> On Mon, Jul 1, 2019 at 11:13 PM Torbjörn Granlund wrote:
> >
> > Vincent Lefevre writes:
> >
> > Yes, with LTO, the object file does not contain the structure as is.
> > Thus the detection fr
On Mon, Jul 1, 2019 at 11:13 PM Torbjörn Granlund wrote:
>
> Vincent Lefevre writes:
>
> Yes, with LTO, the object file does not contain the structure as is.
> Thus the detection from "od -b conftest.$OBJEXT" does not work.
>
> That could be solved by generating a final executable, right?
Ye
Richard Biener writes:
On Mon, Jul 1, 2019 at 11:13 PM Torbjörn Granlund wrote:
>
> Vincent Lefevre writes:
>
> Yes, with LTO, the object file does not contain the structure as is.
> Thus the detection from "od -b conftest.$OBJEXT" does not work.
>
> That could be solved by
On 7/1/19 6:38 PM, Richard Biener wrote:
> On Mon, Jul 1, 2019 at 5:27 PM Vincent Lefevre wrote:
>>
>> On 2019-07-01 16:59:06 +0200, Marc Glisse wrote:
>>> On Mon, 1 Jul 2019, Vincent Lefevre wrote:
I suggest another solution:
First try like now. If the format is unknown, check whet
On Mon, Jul 1, 2019 at 5:27 PM Vincent Lefevre wrote:
>
> On 2019-07-01 16:59:06 +0200, Marc Glisse wrote:
> > On Mon, 1 Jul 2019, Vincent Lefevre wrote:
> > > I suggest another solution:
> > >
> > > First try like now. If the format is unknown, check whether the
> > > object file contains the str
Vincent Lefevre writes:
Yes, with LTO, the object file does not contain the structure as is.
Thus the detection from "od -b conftest.$OBJEXT" does not work.
That could be solved by generating a final executable, right?
--
Torbjörn
Please encrypt, key id 0xC8601622
_
On 2019-07-01 16:59:06 +0200, Marc Glisse wrote:
> On Mon, 1 Jul 2019, Vincent Lefevre wrote:
> > I suggest another solution:
> >
> > First try like now. If the format is unknown, check whether the
> > object file contains the string ".gnu.lto" (which should mean
> > that GCC was used with LTO), a
On 2019-07-01 16:36:23 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre writes:
>
> I suggest another solution:
>
> First try like now. If the format is unknown, check whether the
> object file contains the string ".gnu.lto" (which should mean
> that GCC was used with LTO), and in this
On Mon, 1 Jul 2019, Vincent Lefevre wrote:
On 2019-07-01 13:44:04 +0200, Marc Glisse wrote:
On Mon, 1 Jul 2019, Martin Liška wrote:
> On 6/24/19 8:57 PM, Marc Glisse wrote:
> > On Mon, 24 Jun 2019, Martin Liška wrote:
> >
> > > Using -flto one can see a test failure:
> >
> > This is well kno
Vincent Lefevre writes:
I suggest another solution:
First try like now. If the format is unknown, check whether the
object file contains the string ".gnu.lto" (which should mean
that GCC was used with LTO), and in this case, try again with
"-fno-lto" as the patch was doing.
That might
On 2019-07-01 13:44:04 +0200, Marc Glisse wrote:
> On Mon, 1 Jul 2019, Martin Liška wrote:
>
> > On 6/24/19 8:57 PM, Marc Glisse wrote:
> > > On Mon, 24 Jun 2019, Martin Liška wrote:
> > >
> > > > Using -flto one can see a test failure:
> > >
> > > This is well known, see the archives for detail
On Mon, 1 Jul 2019, Martin Liška wrote:
On 6/24/19 8:57 PM, Marc Glisse wrote:
On Mon, 24 Jun 2019, Martin Liška wrote:
Using -flto one can see a test failure:
This is well known, see the archives for details. It is a combination of 2
issues:
- (thin) LTO prevents configure from guessing t
On 6/24/19 8:57 PM, Marc Glisse wrote:
> On Mon, 24 Jun 2019, Martin Liška wrote:
>
>> Using -flto one can see a test failure:
>
> This is well known, see the archives for details. It is a combination of 2
> issues:
> - (thin) LTO prevents configure from guessing the floating point format
> - a
On 6/24/19 8:57 PM, Marc Glisse wrote:
> On Mon, 24 Jun 2019, Martin Liška wrote:
>
>> Using -flto one can see a test failure:
>
> This is well known, see the archives for details. It is a combination of 2
> issues:
> - (thin) LTO prevents configure from guessing the floating point format
I fou
On Mon, 24 Jun 2019, Martin Liška wrote:
Using -flto one can see a test failure:
This is well known, see the archives for details. It is a combination of 2
issues:
- (thin) LTO prevents configure from guessing the floating point format
- a bug in the generic GMP code (fixed in master IIRC)
Hi.
Using -flto one can see a test failure:
abuild@marxinbox:~/rpmbuild/BUILD/gmp-6.1.2/tests/mpz> ./t-get_d_2exp
mpz_get_d_2exp wrong on 2**54-1
result out of range, expect 0.5 <= got < 1.0
rnd_mode = 0
data[i] = 54
z=0x3F
got =[00 00 00 00 00 00 F0 3F] 1
got ex
25 matches
Mail list logo
