Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
GCC 4.5 testing
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 6, 7, 8 ... 13, 14, 15  Next  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
Da Fox
Guru
Guru


Joined: 06 Jul 2005
Posts: 341

PostPosted: Wed Jun 02, 2010 9:12 am    Post subject: Reply with quote

Genewb wrote:
Da Fox wrote:

One thing I am not sure about is setting CFLAGS as LDFLAGS (the second line of
/etc/portage/env/media-video/ffmpeg), however without this the compilation aborts
at link time with 'error: invalid LTO mode'.
Is this the proper way to set LDFLAGS for link time optimization?

No, no LDFLAGS are required for lto.

I believe that setting -flto in LDFLAGS is correct, the documentation states:
To use the link-timer optimizer, -flto needs to be specified at compile time and
during the final link
. Also, if you add -flto-report to your LDFLAGS you get
some extra output during linking about what the lto-optimizer is doing.
If I don't specify -flto in LDFLAGS, I also don't get this extra output, indicating
that the compiler is performing a regular link.

The thing I'm not sure about is whether (or why) I need to pass my CFLAGS in
LDFLAGS. As I stated before, without passing CFLAGS in LDFLAGS I get an
'error: invalid LTO mode'. I think the cause for this may be that somehow the
compilation options during link-time are different enough for GCC to decide that
they are 'incompatible', as hinted at somewhat here, under Conflicting Command
Line Options
.


Genewb wrote:
Da Fox wrote:

Also, can anyone please explain how to use -fwhopr? Is it just a matter of replacing
'lto' with 'whopr' everywhere? I.e. does it need to be specified at the linking stage also,
or do I then use only lto? Or do you always need to specify both -flto and -fwhopr?

Just -fwhopr.

Ok, that seems logical, I'll give it a try then as soon as regular -flto works. It
seems that -fwhopr is very similar to -flto, but is designed to require much less memory
than -flto. So I should be able to use -flto the same as -fwhopr, unless I run out of
memory, I think.


cruzki123 wrote:
/etc/portage/env/media-video/ffmpeg:
CFLAGS="${CFLAGS} -flto -flto-report"
LDFLAGS="${CFLAGS} -Wl,-flto,--as-needed"


I think that you have a typo here. Is LDFLAGS="${_LD_FLAGS} -Wl,-flto,--as-needed" (without _)

No, writing CFLAGS there was intentional, but you are correct, I should also still specify
the old LDFLAGS. I think it should then read:
/etc/portage/env/media-video/ffmpeg:
CFLAGS="${CFLAGS} -flto -flto-report"
LDFLAGS="${LDFLAGS} ${CFLAGS} -Wl,-flto,--as-needed"

_________________
"Man fears the darkness, and so he scrapes away at the edges of it with fire."
- Rei Ayanami

JGBE, a Java based GameBoy Emulator
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6293

PostPosted: Wed Jun 02, 2010 11:48 am    Post subject: Reply with quote

Da Fox wrote:
No, writing CFLAGS there was intentional

From my understanding of the documentation (haven't looked at the source) there should not be a need to specify CFLAGS in LDFLAGS: The CFLAGS relevant to flto should be stored automatically by gcc in the .o file.
Quote:
Code:
LDFLAGS="${LDFLAGS} ${CFLAGS} -Wl,-flto,--as-needed"

I would suggest to write the latter as "-Wl,-flto -Wl,--as-needed"; then it is easier to filter one such option (in an ebuild or in /etc/portage/bashrc or wherever). However, -flto alone actually suffices (and is perhaps even better for some scripts):
Code:
LDFLAGS="${LDFLAGS} -flto -Wl,--as-needed"
Back to top
View user's profile Send private message
cruzki123
Apprentice
Apprentice


Joined: 16 May 2008
Posts: 249

PostPosted: Wed Jun 02, 2010 2:40 pm    Post subject: Reply with quote

I'm ussing this in a Makefile of a personal proyect. Just replace += with = ${CFLAGS} or ${LDFLAGS} depending of the case. an try.

CXXFLAGS = -O2 -Wextra -march=native -pipe -pedantic -ftracer # base
CXXFLAGS += -flto -fwhole-program -combine # global optimization


LDFLAGS = -O1 -Wl,-znow -Wl,--hash-style=gnu -Wl,--enable-new-dtags # base
LDFLAGS += -Wl,--as-needed # as-needed
LDFLAGS += -flto
Back to top
View user's profile Send private message
Genewb
Apprentice
Apprentice


Joined: 09 Jan 2007
Posts: 165

PostPosted: Wed Jun 02, 2010 3:31 pm    Post subject: Reply with quote

mv wrote:
Da Fox wrote:
No, writing CFLAGS there was intentional

From my understanding of the documentation (haven't looked at the source) there should not be a need to specify CFLAGS in LDFLAGS: The CFLAGS relevant to flto should be stored automatically by gcc in the .o file.

Exactly.
_________________
I don't give a darn about "experience", just functional copyleft software.
Back to top
View user's profile Send private message
rhill
Retired Dev
Retired Dev


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Thu Jun 03, 2010 12:34 am    Post subject: Reply with quote

-fwhopr is implemented using LTO, but I don't think it's the same thing. It's extremely experimental at this point (I think the name is even being changed for 4.6). Use it if you like but any bugs are yours to keep.

I haven't played w/ LTO but I imagine things will get better when libtool supports it automatically.
_________________
by design, by neglect
for a fact or just for effect
Back to top
View user's profile Send private message
cruzki123
Apprentice
Apprentice


Joined: 16 May 2008
Posts: 249

PostPosted: Thu Jun 03, 2010 6:49 am    Post subject: Reply with quote

dirtyepic wrote:
-fwhopr is implemented using LTO, but I don't think it's the same thing. It's extremely experimental at this point (I think the name is even being changed for 4.6). Use it if you like but any bugs are yours to keep.

I haven't played w/ LTO but I imagine things will get better when libtool supports it automatically.


In what version is planed to happend?
Back to top
View user's profile Send private message
rhill
Retired Dev
Retired Dev


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Thu Jun 03, 2010 9:08 pm    Post subject: Reply with quote

I'm not sure what the status is. See:
http://lists.gnu.org/archive/html/libtool-patches/2010-04/msg00001.html
http://lists.gnu.org/archive/html/libtool-patches/2010-04/msg00002.html

This talks about the issue of passing CFLAGS at link time w/ -flto:
http://lists.gnu.org/archive/html/libtool/2010-03/msg00017.html
_________________
by design, by neglect
for a fact or just for effect
Back to top
View user's profile Send private message
Genewb
Apprentice
Apprentice


Joined: 09 Jan 2007
Posts: 165

PostPosted: Fri Jun 04, 2010 2:04 am    Post subject: Reply with quote

dirtyepic wrote:
I'm not sure what the status is. See:
http://lists.gnu.org/archive/html/libtool-patches/2010-04/msg00001.html
http://lists.gnu.org/archive/html/libtool-patches/2010-04/msg00002.html

This talks about the issue of passing CFLAGS at link time w/ -flto:
http://lists.gnu.org/archive/html/libtool/2010-03/msg00017.html

I adapted patch 1--which seems to be the only one needed--for libtool-2.2.7 and output didn't differ in size, only sha256 hashes altered for some binaries. :?
_________________
I don't give a darn about "experience", just functional copyleft software.
Back to top
View user's profile Send private message
spielc
Guru
Guru


Joined: 20 Apr 2004
Posts: 452

PostPosted: Thu Jun 10, 2010 3:24 pm    Post subject: Reply with quote

Just a heads up:

I went down the gcc-4.5 road and i have to say i don't regret it. As always it was not without glitches but by now i was able to build almost everything with gcc-4.5.0 and i even compiled a working kernel with gcc-4.5.0. The only thing that really broke with gcc-4.5.0 was grub-2 just as was mentioned earlier. Recompiling it with gcc-4.3 brought it back to life.
_________________
Raise your beers up high...
Back to top
View user's profile Send private message
Kingoftherings
Guru
Guru


Joined: 04 May 2008
Posts: 328

PostPosted: Fri Jun 11, 2010 3:54 pm    Post subject: Reply with quote

Anyone else having problems with glibc-2.11.2?
On my amd64 box, it appears to get to the install portion and then something segfaults.
Portage doesn't output the typical "emerge failed" message, all I get is something like:
Code:

zsh: Segmentation Fault


There was more to that error, but I don't remember at the moment as I'm at work.
But the really odd thing is that after 30 seconds of the segfault, X freezes and I can't do anything except hard reset.

I'm using gcc-4.5.0, but I don't know if it's the cause; it might be zsh or portage. I'll be able to post more info when I get home.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6293

PostPosted: Fri Jun 11, 2010 5:08 pm    Post subject: Reply with quote

glibc-2.11.2 works fine here with gcc-4.5. If X freezes after a non-related segfault, I suppose it is a hardware problem, possibly related with your RAM.
Back to top
View user's profile Send private message
Kingoftherings
Guru
Guru


Joined: 04 May 2008
Posts: 328

PostPosted: Fri Jun 11, 2010 9:33 pm    Post subject: Reply with quote

Tried it again now that I'm home. It got to installing glibc after compiling it, and it stopped at:

Code:
 
>>> /usr/lib/debug/usr/lib32/gconv/ISO8859016.so.debug
zsh: segmentation fault  emerge -uavDN world


And it's not just X that's froze; I can't ssh in from my laptop to kill X. So I'm guessing there was a kernel panic.

Edit: I don't see anything in /var/log/messages at the ime of the crash.
Back to top
View user's profile Send private message
Kingoftherings
Guru
Guru


Joined: 04 May 2008
Posts: 328

PostPosted: Fri Jun 11, 2010 11:13 pm    Post subject: Reply with quote

After further testing it looks like a btrfs bug in linux 2.6.35-rc.
Not a GCC bug at all then.
Back to top
View user's profile Send private message
ComaWhite
Tux's lil' helper
Tux's lil' helper


Joined: 07 Oct 2008
Posts: 125

PostPosted: Sat Jun 12, 2010 5:11 am    Post subject: Reply with quote

Blah I wish GCC-4.5.0 would become stable, but might have to wait til 4.5.1 :(
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6293

PostPosted: Sun Jun 13, 2010 4:29 pm    Post subject: Reply with quote

cruzki123 wrote:
ICXXFLAGS += -flto -fwhole-program
[...]
LDFLAGS += -flto
This makes no sense: -fwhole-program is ignored when used together with -flto as a compile flag. Moreover, you must specify -fwhole-program at link time if you want it:
Code:
CXXFLAGS += -flto
[...]
LDFLAGS += -flto -fwhole-program

should be right. (Please correct me, if I misunderstood something).

A related question which I do not know: Where to replace -flto by -fwhopr if you want it? In CXXFLAG or in LDFLAGS or in both?
Back to top
View user's profile Send private message
cruzki123
Apprentice
Apprentice


Joined: 16 May 2008
Posts: 249

PostPosted: Sun Jun 13, 2010 5:31 pm    Post subject: Reply with quote

used what you suggest I can't link: I have undefined symbol.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6293

PostPosted: Sun Jun 13, 2010 6:43 pm    Post subject: Reply with quote

cruzki123 wrote:
used what you suggest I can't link: I have undefined symbol.

Well, many programs are not written to work with -fwhole-program: This requires some care in coding (exported symbols must be explicitly exported). However, specifying -fwhole-program only in CXXFLAGS (together with -lto) is like not specifying it at all.
Back to top
View user's profile Send private message
Genewb
Apprentice
Apprentice


Joined: 09 Jan 2007
Posts: 165

PostPosted: Sat Jun 19, 2010 2:55 pm    Post subject: Reply with quote

Here's a patch for Linux killing init when booting, after being compiled with -Os (by GCC 4.5).
_________________
I don't give a darn about "experience", just functional copyleft software.
Back to top
View user's profile Send private message
Colt45
Tux's lil' helper
Tux's lil' helper


Joined: 05 Sep 2007
Posts: 102
Location: Central Washington

PostPosted: Thu Jun 24, 2010 6:52 am    Post subject: Reply with quote

Colt45 wrote:
Problem discovered. With -march=atom gcc-4.5.0 fails during bootstrap comparison between stage 2 and 3 when compiling with gcc-4.5.0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43921
I am testing the patch listed at http://gcc.gnu.org/viewcvs?view=revision&revision=158900
Patch fixes the issue.

This does not appear to be fixed. gcc wants to rebuild after a mpfr upgrade and failed this way again. Looks like Im going to have to modify the ebuild again.
_________________
"Hopps" - AMD Athlon X2 4450B, 4GB, 128GB Samsung SSD, (Gentoo Hardened amd64; gcc-4.9.3; 4.4.8-hardened-r1)
"Dash" - 2x Intel Xeon 5148, 12GB FB-DIMM, 3x Samsung 1TB (mdadm RAID 5), AMD HD6950, (Gentoo amd64-multilib; gcc-5.3.0; 4.4.0-pf4)
Back to top
View user's profile Send private message
rhill
Retired Dev
Retired Dev


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Sat Jun 26, 2010 5:18 am    Post subject: Reply with quote

Bug 317755. I should be putting out a new patchset this weekend.
_________________
by design, by neglect
for a fact or just for effect
Back to top
View user's profile Send private message
Colt45
Tux's lil' helper
Tux's lil' helper


Joined: 05 Sep 2007
Posts: 102
Location: Central Washington

PostPosted: Sat Jun 26, 2010 9:37 pm    Post subject: Reply with quote

dirtyepic wrote:
Bug 317755. I should be putting out a new patchset this weekend.

Cool, Ill wait for it, then.
_________________
"Hopps" - AMD Athlon X2 4450B, 4GB, 128GB Samsung SSD, (Gentoo Hardened amd64; gcc-4.9.3; 4.4.8-hardened-r1)
"Dash" - 2x Intel Xeon 5148, 12GB FB-DIMM, 3x Samsung 1TB (mdadm RAID 5), AMD HD6950, (Gentoo amd64-multilib; gcc-5.3.0; 4.4.0-pf4)
Back to top
View user's profile Send private message
rhill
Retired Dev
Retired Dev


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Sun Jun 27, 2010 4:18 am    Post subject: Reply with quote

Released.

Code:
  27 Jun 2010; Ryan Hill <dirtyepic@gentoo.org> gcc-4.5.0.ebuild:
  Bump patchset. This release fixes the following bugs:

    #317187 - Wrong code w/ -foptimize-sibling-calls (enabled at -O2)
    #317269 - Link shared libs to libc on FreeBSD
    #317513 - Core i? CPUs misdetected as Atom with -march=native
    #317755 - Bootstrap failure with -march=atom


There's no revision bump since this is an unkeyworded version. Just sync in an hour and rebuild.
_________________
by design, by neglect
for a fact or just for effect
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6108
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sun Jun 27, 2010 9:53 am    Post subject: Reply with quote

dirtyepic wrote:
Released.

Code:
  27 Jun 2010; Ryan Hill <dirtyepic@gentoo.org> gcc-4.5.0.ebuild:
  Bump patchset. This release fixes the following bugs:

    #317187 - Wrong code w/ -foptimize-sibling-calls (enabled at -O2)
    #317269 - Link shared libs to libc on FreeBSD
    #317513 - Core i? CPUs misdetected as Atom with -march=native
    #317755 - Bootstrap failure with -march=atom


There's no revision bump since this is an unkeyworded version. Just sync in an hour and rebuild.


finally !

now I can use march=native again :D

thanks a lot dirtyepic & the others :)
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
ComaWhite
Tux's lil' helper
Tux's lil' helper


Joined: 07 Oct 2008
Posts: 125

PostPosted: Sun Jun 27, 2010 10:54 am    Post subject: Reply with quote

dirtyepic wrote:
Released.

Code:
  27 Jun 2010; Ryan Hill <dirtyepic@gentoo.org> gcc-4.5.0.ebuild:
  Bump patchset. This release fixes the following bugs:

    #317187 - Wrong code w/ -foptimize-sibling-calls (enabled at -O2)
    #317269 - Link shared libs to libc on FreeBSD
    #317513 - Core i? CPUs misdetected as Atom with -march=native
    #317755 - Bootstrap failure with -march=atom


There's no revision bump since this is an unkeyworded version. Just sync in an hour and rebuild.


Vielen dank dirtyepic ^_____________^.
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3253
Location: Gainesville, Florida

PostPosted: Mon Jul 26, 2010 3:33 am    Post subject: Reply with quote

Are we getting closer with 4.5.0? I've been following this thread, and no posts for almost a month, so I chose to unmask the portage version, and ran into problems. I did re-read this entire thread carefully, and tried to apply things here to the portage version. Guess the portage ebuild must be lacking some patches? Maybe that's my problem. I was trying to move an ~amd64 install to gcc-4.5.0.

I could build gcc-4.5.0 OK using gcc-4.4.4 and my normal flags, but then ran into trouble when trying to first rebuild the toolchain with 4.5.0, even with a bare set of cflags/ldflags, and without the -flto and -ftree-vectorize flags. Failed on libtool, which apparently is a known problem with -flto, among others, and on my system even without -flto.

I wouldn't mind trying the overlay (if it's still pretty active), but figured since 4.5.0 was in portage masked, things were getting closer. If the portage version is going to remain masked for a while longer before being released to ~Arch, I'd be ready to go with the overlay and spend some time testing.

Can we get an update as to the status of this thread and overlay? Is there a consensus as to which flags and procedures which should work, and or any new info/tips since the last post of June 27?
I was figuring for a basic procedure something like emerge gcc-4.5.0 (which I did), change make.conf flags, rebuild toolchain with 4.5.0 and the new flags, then do an emerge -e @system, and if that worked try an emerge -e @world --keep-going.

EDIT: Is the lto USE FLAG mandatory or recommended? Set globally in make.conf, or for gcc only in /etc/portage package.use?

Use it when first emerging gcc-4.5.0 with gcc-4.4.4, or enable it after 4.5.0 is installed and set as default gcc??
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.29-r5, gcc-9.2.0 kernel-5.2.10-gentoo USE=experimental
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2, 3 ... 6, 7, 8 ... 13, 14, 15  Next
Page 7 of 15

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum