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
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
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
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
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
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?
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 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
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),
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
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
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
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
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 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)
19 matches
Mail list logo
