On 8 March 2013 11:46, Artur Skawina <art.08.09@gmail.com> wrote:

> I've been using "gdc (GCC) 4.6.3 20120106 (gdc 0.31 - r748:ab99d67f04c2,
> dmd 2.057)"
> as my only D compiler for the last months, and it's been doing great,
> almost everything
> including LTO works. There have been a few ices/crashes, but mostly with
> invalid code
> or looking front-end related (didn't want to report them until the 4.8
> merge is done).
> But still using that old compiler means working with a different language,
> so I finally
> decided to try out the current GDC versions, and started with the 4.7
> branch.
>
> First difference that i noticed - the frontend version no longer shows up
> in '--version'
> output - is there a way to retrieve it, preferably as a git hash?
>
>
You can patch it in the gcc/BASE-VER or gcc/DEV-PHASE files, but other than that no.  Alternatively you can use pragma(msg) to get the __VENDOR__ and __VERSION__ strings though...


Then the very first app that i tried to compile didn't - failed with an LTO
> related
> error. I need LTO for that one, at least i used to with my old compiler.
> Decided to try the head (4.8) based tree - with similar results;
> apparently LTO no
> longer works at all, even for trivial 'void main(){}' programs. At least
> the error,
> which appears to be the same, got a bit better reported on that branch [1].
> One difference between my old working setup and the new ones is that the
> former is
> not a multilib one; haven't tried a new build w/o multilibs yet.
>
>
LTO hasn't been tested, and has changed much between 4.6 and 4.8.  Can only really deal with problems on a case-by-case basis.



> Then I wanted to try to build some other programs using master, w/o LTO.
> Didn't
> really work - the problem is that gcc-pragma-attributes are now /errors/.
> So I'd
> have to modify the sources just to build with the newer compiler - which
> isn't a
> big problem; the fact that I can't then easily go back to using an older
> one is.
> I tried modifying some trivial sources, which were using only
> 'pragma(attribute, noinline)', but couldn't get them to work; the compiler
> keeps
> complaining, 'cc1d: error: unknown attribute noinline'.
> Is 'import gcc.attribute; @attribute("noinline") void f() {}' supposed to
> work?
>
>

Yes and no.

Yes that is the proposed new way.  No, because no attributes have been hooked into it yet.  This is something that we'll build on in the coming months.


[1]
> $ gdc -flto main.d -o main
> lto1: internal compiler error: in streamer_get_pickled_tree, at
> tree-streamer-in.c:1050
> Please submit a full bug report,
>

The problem with this is it is not easy to tell whether it genuinely is a bug in LTO, or LTO expects GDC to generate code in a peculiar way.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 03/08/13 13:40, Iain Buclaw wrote:
> On 8 March 2013 11:46, Artur Skawina <art.08.09@gmail.com <mailto:art.08.09@gmail.com>> wrote:
> 
>     I've been using "gdc (GCC) 4.6.3 20120106 (gdc 0.31 - r748:ab99d67f04c2, dmd 2.057)"
>     as my only D compiler for the last months, and it's been doing great, almost everything
>     including LTO works. There have been a few ices/crashes, but mostly with invalid code
>     or looking front-end related (didn't want to report them until the 4.8 merge is done).
>     But still using that old compiler means working with a different language, so I finally
>     decided to try out the current GDC versions, and started with the 4.7 branch.
> 
>     First difference that i noticed - the frontend version no longer shows up in '--version'
>     output - is there a way to retrieve it, preferably as a git hash?
> 
> 
> You can patch it in the gcc/BASE-VER or gcc/DEV-PHASE files, but other than that no.  Alternatively you can use pragma(msg) to get the __VENDOR__ and __VERSION__ strings though...

I have many builds installed, was looking for a way to easily identify which one is currently used. Previously i could run 'gdc --version'. It's not a problem, just something that was nice to have.


>     Then the very first app that i tried to compile didn't - failed with an LTO related
>     error. I need LTO for that one, at least i used to with my old compiler.
>     Decided to try the head (4.8) based tree - with similar results; apparently LTO no
>     longer works at all, even for trivial 'void main(){}' programs. At least the error,
>     which appears to be the same, got a bit better reported on that branch [1].
>     One difference between my old working setup and the new ones is that the former is
>     not a multilib one; haven't tried a new build w/o multilibs yet.
> 
> 
> LTO hasn't been tested, and has changed much between 4.6 and 4.8.  Can only really deal with problems on a case-by-case basis.

The only bit of info i can add is that the 4.6 based build works, but a 4.7 based one already fails (in the same place as the 4.8 version, only w/o the nice backtrace). It happens with an empty main, which would be the simplest testcase.


>     Then I wanted to try to build some other programs using master, w/o LTO. Didn't
>     really work - the problem is that gcc-pragma-attributes are now /errors/. So I'd
>     have to modify the sources just to build with the newer compiler - which isn't a
>     big problem; the fact that I can't then easily go back to using an older one is.
>     I tried modifying some trivial sources, which were using only
>     'pragma(attribute, noinline)', but couldn't get them to work; the compiler keeps
>     complaining, 'cc1d: error: unknown attribute noinline'.
>     Is 'import gcc.attribute; @attribute("noinline") void f() {}' supposed to work?
> 
> 
> 
> Yes and no.
> 
> Yes that is the proposed new way.  No, because no attributes have been hooked into it yet.  This is something that we'll build on in the coming months.

That unfortunately means that in the mean time there's no way to access the built-in attributes. While typing this email I tried reverting d47d5d864a, but that's not enough (pragma-attributes are accepted, but silently ignored); I'm afraid that reverting more would result in conflicts with the /new way/; if not now, then in the future, so it's not something I'd like to have to carry locally. Would it be possible to postpone the pragma removal to after a working alternative exists?

artur