Re: about the gcc 3.4.x problems

Dan Nelson said:
>In the last episode (Jul 29), Paul Seniura said:
>> Scott Long wrote:
>> > -Os has never been a supported option for compiling the system on FreeBSD.
>> > There is an effort to make -O2 work, but that is also not officially
>> > supported yet.  Many of the problems are due to FreeBSD code, of course,
>> > but this is a long standing issue and has little bearing on the success
>> > of the gcc 3.4 import.
>> 
>> Okay I am also on record here about the -Os being the DEFAULT SETTING on
>> Apple's XCode "deployment" environment.  It _needs_ to be supported.  (I'm
>> wondering just how much history y'all have

>And that's not a problem.  There there are just X thousand lines of code in
>/usr/src that have never been tested with -Os.  That's the only reason that
>-Os and -O2 are not "officially" supported.  I have built worlds using -O2
>with absolutely no problems for a few years.  That may just be that I'm not
>using the programs that have bugs uncovered by -O2 (a libalias bug only seen
>under -O2 was recently fixed, I believe).  Build with -Os, and if you find
>bugs, send-pr them.

I've been building kernel+world and most apps with -Os and the
-Current system gcc for many months and continuing even today
(if/when I can kick off another system build, too).

After backing off the tests with lang/gcc34, we discovered a
bug with system gcc -Os and XFree86 libs.  I have a CFLAGS+=-O2
override in that Makefile now.  ;)

I'd mentioned in April that lang/gcc34 had known problems with
-Os i.e. known by the GCC team themselves, and provided a URL to
that discussion on their website.  I won't file a PR on a known
bug like that.  I wait 'til we get the fix, and in that msg
thread I was asking for a new snapshot with the fix once it's
available and when time allowed.

Yesterday right here on this list someone said he hit a -Os bug
after he'd CVSup'd and used the new system gcc.  So my mind is
going "oh no here we go again... it should've been fixed."

That earlier point-release of lang/gcc34 went final, but we never
got a final version of it.  -Os was a hot item at the GCC site
such that it should've been fixed on that final point-release
(3.4.1 IIRC).

Instead our lang/gcc34 port today is _another_ later point-
release snaphot (3.4.2).  BTW I can't start building
kernel+world just yet to see what the new system gcc says.

Now today I am completely perplexed: did the GCC team actually
ever fix that known bug, do _we_ have that fix in any of the three
gcc (system & two ports), or did the "FreeBSD system gcc custom
patches" break it?

It's making me paranoid, not being able to trust our most basic
tools.  I'm so nervous this time 'round that I'm doing full
system backups before even starting the buildworld.  ;)  I've
sweated thru a lot of -Current changes since last October, but
this one really has me worried.  Not that it might break, but
that we had actively tried to test it way in advance, and be
seemingly ignored in our reports here, because yesterday's post
mentioned hitting a -Os bug again after CVSup'ing the new gcc. 
"Oh no here we go again..."


>> >> Here, then, is a point I need to make:
>> >>
>> >> Why is Apple seemingly skipping GCC 3.4.x altogether?
>> >
>> > So is there a conspiracy against gcc 3.4 that we don't know about?  Do
>> > you have information that could help us here?  Or maybe Apple is just
>> > being prudent and targeting XCode and GCC releases to somewhat coincide. 
>> > That seems to satisfy occums razor a whole lot easier.
>> 
>> I said "seemingly".
>> It makes sense to me.[tm]
>> It is something to think about.
>
>I also suspect it's just a timing thing.  Apple is intensly interested in
>precompiled headers and other compiler speedups because their system uses a
>lots of complex templates.  3.5 is supposed to be the "go-faster" release.

Yes Apple did say Tiger will be available in the first half of
next year.  They got 11 more months.  ;)

The speedups were felt everywhere when upgrading from Jaguar to
Panther.  I'm on record here surmizing part of the speedup could
be due to -Os, as that will tighten loops to fit inside L1/L2
caches (G4 Sawtooth at home). 
-Os definitely helps this puny pentium2, too, more than -O2.

For other apps esp. mplayer, I will make sure they get -O3 and
the -f tweaks.  Both here & at home.

Can't wait to try the new -Current system gcc.  ;)


>> Have you searched the mail archives here to find out what's
>> been said during the past few months?  Again I'm sure some
>> of us including myself have mentioned the -fformat-extensions
>> problem at several points.  Having most modules linked with
>> libstdc(++) in the i386-portbld-freebsd5.2 subdir is not too
>> kosher, too.  I mentioned all kinds of things like that. 
>
>In general, C++ object files are not portable across different gcc releases,
>since they fix ABI bugs in every release.  Code built with 3.4 may not link
>to an old 3.3 libstdc++, thus the dependency on the port's own libstdc++.  I
>don't see a problem here.

Might want to look again at my tests back then. 
I'd mentioned having to do something to make the loader find
those libs because e.g. i386-portbld-freebsd5.2 is not in the
regular search path.  Mind you I was building kernel & world
with those lang/gcc* ports, not just any ol' app.  ;)  IIRC many
things started by /etc/rc.d bombed until we got that subdir into
the ldconfig_paths.  Oh tcsh bombed as well as simple cmds like
'ls' IIRC, too.  Fortunately the kernel and modules are built
'standalone'.  As for ldconfig_paths, you should see the long
string in my rc.conf file now, paranoia will do that.  ;)


>-- 
>	Dan Nelson
>	dnelson_at_allantgroup.com

  --  thx, Paul Seniura.