> -----Original Message-----
> From: David Coakley [mailto:dcoak...@gmail.com]
> Sent: Thursday, August 02, 2012 2:02 AM
> To: Gilmore, Doug
> Cc: open64-devel
> Subject: Re: [Open64-devel] Review request: fixing issues when building
> the compiler as 64-bit binaries
> 
> Hi Doug,
> 
> Nice job collecting all these changes.  Building the compiler in
> 64-bit mode is the way forward.
> 
> I took a look at the build changes and didn't see any problems.  A few
> suggestions:
> 
> In patch 3, is there a Linux distro that defaults to GNU Gold that
> prompted this change?  That would be a useful item to add to the
> commit log.
I don't think that any release yet.   We just uncovered the issue
on a system where it was being manually installed.
> 
> In patch 13, the "Removed default 32 bit build..." comment seems
> unnecessary.  This is information that is more appropriate for the
> commit log.
> 
> -David
I'll the patch 13 and comment accordingly.

I'll be sending out another set of patches in the near future with more
breakout of the FFE changes.

Thanks!

Doug
> 
> On Sat, Jul 28, 2012 at 10:51 PM, Gilmore, Doug <doug.gilm...@amd.com>
> wrote:
> > I have put together a patch set that fixes various issues when
> > building X86 targeting compiler as 64-bit binaries.
> >
> > With these changes the code generated by the 32-bit or 64-bit build
> of
> > the compiler should be the same, whether the compiler is built for
> > release or debug.
> >
> > Except for the register allocation stability issues, getting the
> > 32-bit and 64-bit builds of the compiler to generate the same code
> for
> > C and C++ programs required little change.  However for Fortran
> > a good deal of cleanup was needed in the FFE.
> >
> > I also added some configuration cleanup that made it easier to enable
> > FFE debugging/tracing, and adding the debug ID field in a WHIRL Node
> > that made it easier to track down the cause of different code being
> > generated by the 32-bit and 64-bit builds of the compiler.
> >
> > Also included in the patch set is an update of the constant folding
> of
> > intrinsics patch that I sent out a while back that just handled the
> > real intrinsic.  The updated version of this change (patch 5)
> includes
> > changes made by Shivarama Rao which handles more intrinsics.  I
> > included this change in the patch set since by applying it first, the
> > the patch associated with the commit to our internal source tree for
> > the 64-bit cleanup applies much more cleanly to the main Open64
> trunk.
> >
> > Sun had an issue with constant folding and FP rounding modes.  I have
> > looked into this and I believe that this is not a concern since the
> > FP rounding mode interface routines to get and set the FP rounding
> > mode was an SGI extension and AFAICS the implementation was never
> > completed for Open64.
> >
> > To apply the patch set run:
> >
> > tar xf m64_trunk_v3.tar.bz2
> > for i in m64_trunk_v3/* ; do patch -p1 < $i ; done
> >
> > Here is how patches are broken up among various sub-systems:
> >
> > build subsystem:
> > 0001-Add-configure-option-with-build-ffe-optimize.patch
> > 0002-Add-configuration-option-enable-whirl-id.patch
> > 0003-Configure-fix-to-handle-GNU-Gold-linker.patch
> > 0012-Host-related-configure-settings-should-not-be-determ.patch
> > 0013-Default-X8664-build-is-now-64-bit-when-building-on-a.patch
> >
> > Fortran FE:
> > 0004-Allow-constant-folding-of-Intrinsic-in-parameter-sta.patch
> > 0005-Allow-count-intrinsic-to-be-used-in-a-F90-specificat.patch
> > 0006-Cleanup-64-bit-compilation-issues-in-FFE.patch
> >
> > CG:
> > 0007-Fix-stability-issues-in-register-allocator.patch
> > 0008-Fixed-bug-in-expand_strcmp_bb-exposed-by-64-bit-buil.patch
> > 0010-Fixed-bug-in-Targ_Print-for-X8664-when-printing-C10-.patch
> > 0011-Fixed-bug-999-C10-constant-emission-problem.patch
> >
> > WOPT:
> > 0009-Fixed-typo-in-warning-string-for-error-message-type-.patch
> >
> > Note that patch 5 and 9 are trivial fixes to separate problems,
> > That I probably should have sent out separate messages for their
> review.
> >
> > Also it would be good to test builds to check that nothing
> > has been broken on other architectures.
> >
> > Could gatekeepers take a look at these changes (and others that can
> > build on other architectures test them) when they have the chance?
> >
> > Thanks,
> >
> > Doug
> >
> > ---------------------------------------------------------------------
> ---------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> Discussions
> > will include endpoint security, mobile security and the latest in
> malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Open64-devel mailing list
> > Open64-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/open64-devel
> >



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel

Reply via email to