public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Derek Wildstar <dwild@nin.org>
To: law@cygnus.com
Cc: egcs@cygnus.com, pcg@goof.com
Subject: Re: egcs v970828 builds fine on linux-i586libc1 =)
Date: Thu, 04 Sep 1997 20:10:00 -0000	[thread overview]
Message-ID: <Pine.LNX.3.96.970903033226.7480A-100000@argo.starforce.com> (raw)
In-Reply-To: <3242.873239639@hurl.cygnus.com>

On Tue, 2 Sep 1997, Jeffrey A Law wrote:

>   In message <Pine.LNX.3.96.970830045114.9291A-100000@argo.starforce.com> you write:
>   > Built the whole dist with CFLAGS='-O6 -mpentium -pipe' CXXFLAGS='-O6 -mpentium
>   > -pipe' LDFLAGS='-m486 -s -Xlinker -n'....the whole package built fine.  I then
>   > went into the gcc dir and built stage1, stage2, stage3 in the normal fashion
>   > to test the compiler.  Everything appears to be working, even with '-O6 -mpentium'.  
> Good.  Thanks for the info.

Not a problem =)

>   > On a side note, it may be worth mentioning that XFree86 should _not_ be built
>   > with -O6.  The package builds, but some strange runtime problems pop up...the
>   > most annoying of which is a keyboard mapping problem that causes certain keys
>   > to send characters when they are released instead of when they are pressed.
>   > After rebuilding the package with -O2 the problems went away.  (not saying
>   > this is a compiler problem, just for your reference if you end up building X ;)
> Can you investigate this further?  Unlike pgcc, egcs should be producing correct
> code regardless of what optimization level is used.
> 
> One way to do this would be to at least identify the file which is mis-compiled
> at -O6, then we can dive in further to figure out why that file is mis-compiled.
> 

OK, here's the story....turns out the compiler I was using at the time was the
pcg compiler...I had gotten the source for egcs, but forgot that I applied the
pcg patch.  egcs version 2.90.03 compiled X just fine with -mpentium -O6.
Sorry I jumped the gun a bit by assuming egcs and pcg had been completely
combined bt that version.

Another thing that is interesting...this system is an i586-pc-linux-gnulibc1,
but the whole release also built just fine configured to cross from my
platform to both sparc-sun-sunos4.1.4 and sparc-sun-linux-gnulibc1.  The thing
that surprised me was that I did not need to move libgcc1.a into the gcc
subdirectory.  I had a copy in /usr/$ARCH and it somehow found it.  I have
tested both cross compilers, and they seem to be working as well (if not
better) than the stock gcc-2.7.2.2+f77.  The only thing I found with the build
was that it failed to find "../move-if-change". (once on each linux version
and several times on the sunos version, because of the deeper build path).  It
looks like the subdirs want to go one level further up the directory tree to
find move-if-change (instead of  $(srcdir)/move-if-change,
$(srcdir)/../move-if-change  ), but also symlinking ../move-if-change into the
build tree worked.  I tried to follow the makefiles, but couldn't really
figure it out =/  These problems happen near the end of the build, when we're
using .../egcsXXXXXX/gcc/xgcc to build stuff and putting the objects into the
libraries directory....looks like everything it needs except move-if-change is
getting symlinked into that directory (and the subdirs for sunos builds).

>   > The last thing...honest...I was just wondering how up-to-date the
>   > pentium-specific stuff is in egcs (ie if i have 970828, is this reasonably
>   > close to 970821+the pcgg patch)
> No, no significant parts of pgcc have been integrated; pgcc needs a lot of work
> and integrating useful pieces won't happen for a little while (ie no change
> they'll go in before the first release).

Seems like egcs is producing more optimized code than pgcc, I've gotten a few
random compiler exits on sig11 that look like a hardware problem, but havn't
noticed it before...just need to check the RAM timings, thinking i'm running a
little over-optimized with the ram speeds =)

hope some of this helped....looks good!  (Oh yeah...after I wrote the part
above about the compiler finding libgcc1.a, I did RTFM and found the part
about it not needing libgcc1.a anymore....but I can verify that the two cross
compilers are still working properly =)

-joel

> 
> Thanks,
> jeff
> 



  reply	other threads:[~1997-09-04 20:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.3.96.970830045114.9291A-100000@argo.starforce.com>
1997-09-02 15:34 ` Jeffrey A Law
1997-09-04 20:10   ` Derek Wildstar [this message]
1997-09-04 20:26     ` Jeffrey A Law
1997-09-04 20:37     ` Jim Wilson
1997-08-30 11:27 libg++? Chip Salzenberg
1997-08-30 12:00 ` egcs v970828 builds fine on linux-i586libc1 =) Derek Wildstar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.3.96.970903033226.7480A-100000@argo.starforce.com \
    --to=dwild@nin.org \
    --cc=egcs@cygnus.com \
    --cc=law@cygnus.com \
    --cc=pcg@goof.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).