1 |
On Thursday 23 November 2006 12:39, Peter Humphrey wrote: |
2 |
> On Wednesday 22 November 2006 16:28, I wrote: |
3 |
> > So now I suppose I have a lot of CFLAGS to juggle to find out which one |
4 |
> > hurts gnupg so that I can report it. |
5 |
> |
6 |
> It didn't take too long after all. I found that omitting, or |
7 |
> removing, -fmerge-all-constants from CFLAGS enabled gnupg to compile |
8 |
> with -ldap. I don't think gnupg uses C++ so I didn't play with CXXFLAGS. |
9 |
> |
10 |
> # grep FLAGS /etc/make.conf |
11 |
> CFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks \ |
12 |
> -freorder-blocks-and-partition -combine -funit-at-a-time \ |
13 |
> -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants" |
14 |
> CXXFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks \ |
15 |
> -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload |
16 |
> -fmerge-all-constants" |
17 |
> |
18 |
> #cat /etc/portage/env/app-crypt/gnupg |
19 |
> CFLAGS=${CFLAGS//-fmerge-all-constants} |
20 |
> |
21 |
> I haven't decided whether it's worth reporting a bug; perhaps it's enough |
22 |
> that people here know what's needed. |
23 |
> |
24 |
> -- |
25 |
> Rgds |
26 |
> Peter |
27 |
Sorry, but using that flag is just asking for trouble. |
28 |
From the GCC man-page: |
29 |
|
30 |
-fmerge-all-constants |
31 |
"Languages like C or C++ require each non-automatic variable to have distinct |
32 |
location, so using this option will result in non-conforming behavior. " |
33 |
|
34 |
Also, have you benchmarked in any way the effect of all these optimizations on |
35 |
the programs you run? You basically do -Os and then turn almost everything on |
36 |
which differs -O2 from -Os, negating the size difference, plus some extra |
37 |
very experimental flags, which might increase or decrease performance (sorry, |
38 |
but GCC works that way, extra optimizations could actually by |
39 |
pessimizations), and probably break some programs. |
40 |
|
41 |
Playing on your own computer is fine, but don't be surprised if something |
42 |
breaks, and please don't bother other people with it. It certainly is not a |
43 |
GCC 4.x problem. |
44 |
|
45 |
Jan Jitse |