On Fri, Apr 25, 2014, LRN wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 25.04.2014 20:31, Adrien Nader wrote:
> > On Fri, Apr 25, 2014, JonY wrote:
> >> On 4/25/2014 21:17, Dongsheng Song wrote:
> >>> On Fri, Apr 25, 2014 at 6:50 PM, JonY <[email protected]> 
> >>> wrote:
> >>>> On 4/25/2014 17:47, Dongsheng Song wrote:
> >>>>> I'm glad to upload my daily builds to mingw-w64, if someone 
> >>>>> intersting and give me (dongsheng) permission.
> >>>>> 
> >>>> 
> >>>> What is your configuration like? And what exactly do you have in 
> >>>> your download?
> >>>> 
> >>> 
> >>> For win64: ${GCC_SRC_ROOT}/configure \ --prefix=${SYS_ROOT} \ 
> >>> --with-sysroot=${SYS_ROOT} \ --build=${BUILD_TRIPLET} 
> >>> --host=${TARGET_TRIPLET} --target=${TARGET_TRIPLET} \ 
> >>> --disable-multilib --disable-nls --disable-win32-registry \ 
> >>> --enable-checking=release --enable-languages=c,c++,fortran \ 
> >>> --with-arch=core2 --with-tune=generic
> >>> 
> >>> For win32: ${GCC_SRC_ROOT}/configure \ --prefix=${SYS_ROOT} \ 
> >>> --with-sysroot=${SYS_ROOT} \ --build=${BUILD_TRIPLET} 
> >>> --host=${TARGET_TRIPLET} --target=${TARGET_TRIPLET} \ 
> >>> --disable-multilib --disable-nls --disable-win32-registry \ 
> >>> --enable-checking=release --enable-languages=c,c++,fortran \ 
> >>> --with-arch=i686 --with-tune=generic
> >>> 
> >> 
> >> Add --enable-fully-dynamic-string and 
> >> --enable-version-specific-runtime-libs and everything is good.
> >> 
> >> You may need to use winpthread if you want to use --enable-libgomp.
> >> 
> >> I have now added your login to allow uploads, please upload to somewhere
> >> like "Toolchains targetting Win{32,64}/Personal Builds/dongsheng-daily".
> >> probably a good idea to rotate the files weekly to prevent uploads from
> >> getting too big (if there is such a thing as too big).
> >> 
> > 
> > I believe --with-arch=core2 is a big issue for generic toolchains. It
> > will create troubles which will be very annoying to pinpoint.
> > 
> > Any x86_64/amd64/EM64T (I love how Intel always makes up awful names) 
> > already has SSE2 and there is little value in restricting this except in 
> > very specific situation which are better dealt on a case-by-case basis.
> > 
> 
> [un-]related:
> 
> desrt: https://bugzilla.gnome.org/show_bug.cgi?id=722604#c7
> Services: Bug 722604: normal, Normal, ---, gtkdev, NEW, Various tests are
> failing with 2.39.3
> desrt: mclasen: the test is failing because of a gcc bug
> desrt: but gcc is 'buggy by design' according to upstream
> desrt: since following the spec would be expensive on machines that don't
> have SSE instructions
> desrt: (ie: chips made in the 1990s)
> desrt: and since most distros have -march=i686 or worse, gcc has no choice
> but to either (a) be slow or (b) violate spec
> desrt: and they pick (b)
> desrt: imho we should insist on a standards-complying C compiler -- and it's
> quite possible to get gcc to do the right thing with a CFLAG or two...
> desrt: upshot is that we will get distros providing some custom CFLAGS when
> building glib -- but hopefully eventually evaluating their choice of default
> CFLAGS and making changes there
> desrt: either that or they just patch out the failing testcases...
> mclasen: so, you're expecting distros to choose correct over fast, when
> upstream gcc does ?
> mclasen: does not, I should say
> desrt: i'm expecting distros to reevaluate if they still want to support
> chips from the 90s
> desrt: i don't honestly think anyone would want to pick the "let's be slow"
> choice
> desrt: but i also think people are generally unaware of the issue...
> desrt: so mostly i aim to raise the visibility of the problem
> desrt: also making people fully aware of the costs of supporting correct ISO
> C on these old chips...
> LRN: so, -match=i686 is expensive?
> desrt: LRN: expensive or incorrect. take your pick.
> desrt: LRN: gcc picks 'incorrect', for the record
> LRN: i build glib with -march=i686 :(
> desrt: LRN: ya... so do all the distros...
> ***desrt thinks that nobody really knows about this issue
> ***desrt recommends -march=pentium4 -mfpmath=sse
> LRN: no, i mean i *specifically* build *glib* with -march=i686, because it
> won't compile without that (i.e. with the default). At least it didn't back
> when i made a first build
> desrt: LRN: i think we depend on at least -march=i486 for atomic
> compare-and-exchange instructions
> LRN: yes, that's the reason.
> daniels: desrt: ouch, if you have -march=pentium4, you probably want a -mtune
> for a less-horrific microarch
> desrt: daniels: ya.. -mtune=generic might make sense
> desrt: in general, having access to sse/sse2 would be wonderful

I think --with-arch=pentium3 is fine for that and it has SSE. If I
checked correctly last time, you won't find XP machines without at least
that.

-- 
Adrien Nader

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to