On 03/08/13 13:40, Iain Buclaw wrote:
> On 8 March 2013 11:46, Artur Skawina <[email protected]
> <mailto:[email protected]>> 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
