From: Keith M. <kei...@us...> - 2012-06-17 17:15:01
|
On 14/06/12 14:16, Chris Sutcliffe wrote: > I can roll-out a new '-2' release of the existing versions fairly > quickly. Doing another sweep of open issues on each existing version > and looking at addressing them will take me at least a couple of weeks > given my current workload. > > Any preference? A new -2 release, rebuilt from *currently released* source tarballs, please. Eli has pointed out a potentially ABI breaking change in the dirent.c implementation in mingwrt. Yeah, mea culpa. The old implementation was broken, and I fixed it, but in so doing I changed the internal layout of the dirent struct, (and thus, also the DIR reference type), without considering the possibility of third-party libraries compiled against the old version failing, unless they too are recompiled. I'm reluctant to revert to the old, broken implementation, but we do need to agree how we move forward, even if that is to accept the ABI change, bumping the major version from 3.x to 4.x, and advising users of third-party libraries that the may need to recompile them, in order to maintain ABI consistency. (The alternative may be to try to rework the new implementation around a backwardly compatible, but necessarily grossly vulgar and inefficient, alternative dirent struct declaration). -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2012-06-18 01:12:50
|
On 17 June 2012 13:14, Keith Marshall <kei...@us...> wrote: > On 14/06/12 14:16, Chris Sutcliffe wrote: >> I can roll-out a new '-2' release of the existing versions fairly >> quickly. Doing another sweep of open issues on each existing version >> and looking at addressing them will take me at least a couple of weeks >> given my current workload. >> >> Any preference? > > A new -2 release, rebuilt from *currently released* source tarballs, please. Fair enough, I will work on them shortly and hopefully will have them out mid-week. > Eli has pointed out a potentially ABI breaking change in the dirent.c > implementation in mingwrt. Yeah, mea culpa. The old implementation was > broken, and I fixed it, but in so doing I changed the internal layout of > the dirent struct, (and thus, also the DIR reference type), without > considering the possibility of third-party libraries compiled against > the old version failing, unless they too are recompiled. > > I'm reluctant to revert to the old, broken implementation, but we do > need to agree how we move forward, even if that is to accept the ABI > change, bumping the major version from 3.x to 4.x, and advising users of > third-party libraries that the may need to recompile them, in order to > maintain ABI consistency. (The alternative may be to try to rework the > new implementation around a backwardly compatible, but necessarily > grossly vulgar and inefficient, alternative dirent struct declaration). I think we should bump to 4.x as opposed to try and maintain backward compatibility. Cheers, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Earnie B. <ea...@us...> - 2012-06-18 11:41:52
|
On Sun, Jun 17, 2012 at 9:12 PM, Chris Sutcliffe wrote: > I think we should bump to 4.x as opposed to try and maintain backward > compatibility. I agree. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Chris S. <ir0...@gm...> - 2012-06-18 12:48:23
|
On 17 June 2012 21:12, Chris Sutcliffe wrote: > On 17 June 2012 13:14, Keith Marshall > <kei...@us...> wrote: >> On 14/06/12 14:16, Chris Sutcliffe wrote: >>> I can roll-out a new '-2' release of the existing versions fairly >>> quickly. Doing another sweep of open issues on each existing version >>> and looking at addressing them will take me at least a couple of weeks >>> given my current workload. >>> >>> Any preference? >> >> A new -2 release, rebuilt from *currently released* source tarballs, please. > > Fair enough, I will work on them shortly and hopefully will have them > out mid-week. The new builds have been uploaded to FRS. As per Earnie's point, not sure what to do about the xml files in mingw-dist. Do I need to tie them to gcc 4.7.0 and if so, how do I do it? Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Cesar S. <ces...@gm...> - 2012-06-19 04:00:10
|
On 6/18/2012 9:48 AM, Chris Sutcliffe wrote: > On 17 June 2012 21:12, Chris Sutcliffe wrote: >> On 17 June 2012 13:14, Keith Marshall >> <kei...@us...> wrote: >>> On 14/06/12 14:16, Chris Sutcliffe wrote: >>>> I can roll-out a new '-2' release of the existing versions fairly >>>> quickly. Doing another sweep of open issues on each existing version >>>> and looking at addressing them will take me at least a couple of weeks >>>> given my current workload. >>>> >>>> Any preference? >>> >>> A new -2 release, rebuilt from *currently released* source tarballs, please. >> >> Fair enough, I will work on them shortly and hopefully will have them >> out mid-week. > > The new builds have been uploaded to FRS. It seems gcc 4.7.0 miscompiles the startup code. I'm experiencing a crash every time I run a minimal "do nothing" application compiled with gcc 4.7.0 and the new runtime. $ cd /mingw $ tar -xf /c/Temp/mingwrt-3.20-2-mingw32-dev.tar.lzma $ tar -xf /c/Temp/mingwrt-3.20-2-mingw32-dll.tar.lzma $ cat hel.c int main() { return 0; } $ gcc -o hel.exe hel.c $ ./hel [ hel.exe has stopped working ] $ gcc -v Using built-in specs. COLLECT_GCC=C:\rascunho\msys\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/rascunho/msys/mingw/bin/../libexec/gcc/mingw32/4.7.0/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.7.0/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.7.0 (GCC) Cesar |
From: Chris S. <ir0...@gm...> - 2012-06-19 14:50:23
|
On 18 June 2012 23:59, Cesar Strauss wrote: > On 6/18/2012 9:48 AM, Chris Sutcliffe wrote: >> On 17 June 2012 21:12, Chris Sutcliffe wrote: >>> On 17 June 2012 13:14, Keith Marshall >>> <kei...@us...> wrote: >>>> On 14/06/12 14:16, Chris Sutcliffe wrote: >>>>> I can roll-out a new '-2' release of the existing versions fairly >>>>> quickly. Doing another sweep of open issues on each existing version >>>>> and looking at addressing them will take me at least a couple of weeks >>>>> given my current workload. >>>>> >>>>> Any preference? >>>> >>>> A new -2 release, rebuilt from *currently released* source tarballs, please. >>> >>> Fair enough, I will work on them shortly and hopefully will have them >>> out mid-week. >> >> The new builds have been uploaded to FRS. > > It seems gcc 4.7.0 miscompiles the startup code. I'm experiencing a > crash every time I run a minimal "do nothing" application compiled with > gcc 4.7.0 and the new runtime. > > $ cd /mingw > > $ tar -xf /c/Temp/mingwrt-3.20-2-mingw32-dev.tar.lzma > > $ tar -xf /c/Temp/mingwrt-3.20-2-mingw32-dll.tar.lzma > > $ cat hel.c > int main() > { > return 0; > } > > $ gcc -o hel.exe hel.c > > $ ./hel > [ hel.exe has stopped working ] I can confirm this behaviour. Guess it wasn't as simple as a recompile. I'll take these builds down and I'll have to try and take a look as my time permits. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Chris S. <ir0...@gm...> - 2012-06-19 22:28:03
|
Hi Guys, On 19 June 2012 10:50, Chris Sutcliffe wrote: > On 18 June 2012 23:59, Cesar Strauss wrote: >> It seems gcc 4.7.0 miscompiles the startup code. I'm experiencing a >> crash every time I run a minimal "do nothing" application compiled with >> gcc 4.7.0 and the new runtime. >> >> $ cd /mingw >> >> $ tar -xf /c/Temp/mingwrt-3.20-2-mingw32-dev.tar.lzma >> >> $ tar -xf /c/Temp/mingwrt-3.20-2-mingw32-dll.tar.lzma >> >> $ cat hel.c >> int main() >> { >> return 0; >> } >> >> $ gcc -o hel.exe hel.c >> >> $ ./hel >> [ hel.exe has stopped working ] > > I can confirm this behaviour. Guess it wasn't as simple as a > recompile. I'll take these builds down and I'll have to try and take > a look as my time permits. It looks like we have yet another issue with compiler optimization. With no optimization everything works fine, anything above "-O0" causes things to break badly. Hard to debug because a debug build works fine - anyone have any ideas on how to dig in to this further? Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Greg C. <gch...@sb...> - 2012-06-20 00:29:27
|
On 2012-06-19 22:27Z, Chris Sutcliffe wrote: [... problems in the startup code with gcc-4.7.0 ...] > It looks like we have yet another issue with compiler optimization. > With no optimization everything works fine, anything above "-O0" > causes things to break badly. Hard to debug because a debug build > works fine - anyone have any ideas on how to dig in to this further? (1) Just to be sure--have you tried building with both optimization and debugging enabled together? (2) Run the optimized non-debug build under gdb, to get a backtrace. It won't have symbols, but 'addr2line' should help you localize the problem. If it doesn't crash when run under gdb, try drmingw (or any other debugger you have handy). (3) This may be laborious, but you could toggle individual optimization options instead of combinations such as '-O2' represents, to try to figure out which optimization is misbehaving. Similarly, if you have more than one source file, then toggling '-O2' for one file at a time might pin the problem down to one file. (4) I think prior discussions suggested that the problem occurs when (and only when?) the startup code is compiled with optimization. Would programs be noticeably slower if the startup code were built with '-O0', at least for the moment, just to get a release out there? |
From: Chris S. <ir0...@gm...> - 2012-06-20 12:13:33
|
On 19 June 2012 20:29, Greg Chicares wrote: > On 2012-06-19 22:27Z, Chris Sutcliffe wrote: > [... problems in the startup code with gcc-4.7.0 ...] >> It looks like we have yet another issue with compiler optimization. >> With no optimization everything works fine, anything above "-O0" >> causes things to break badly. Hard to debug because a debug build >> works fine - anyone have any ideas on how to dig in to this further? > > (1) Just to be sure--have you tried building with both optimization > and debugging enabled together? Yes, it didn't make a difference, the test app still crashed. > (2) Run the optimized non-debug build under gdb, to get a backtrace. > It won't have symbols, but 'addr2line' should help you localize the > problem. If it doesn't crash when run under gdb, try drmingw (or any > other debugger you have handy). It unfortunately didn't provide anything useful: (gdb) bt #0 0x00408fff in ?? () #1 0x77bd377b in ntdll!RtlInsertElementGenericTableAvl () from C:\Windows\system32\ntdll.dll #2 0x77bd374e in ntdll!RtlInsertElementGenericTableAvl () from C:\Windows\system32\ntdll.dll #3 0x00000000 in ?? () > (3) This may be laborious, but you could toggle individual optimization > options instead of combinations such as '-O2' represents, to try to > figure out which optimization is misbehaving. Similarly, if you have > more than one source file, then toggling '-O2' for one file at a time > might pin the problem down to one file. This would likely track down the particular optimization, unfortunately I don't have the time to compile and test each optimization individually. If someone else was willing to do so it would be greatly appreciated. > (4) I think prior discussions suggested that the problem occurs when > (and only when?) the startup code is compiled with optimization. > Would programs be noticeably slower if the startup code were built > with '-O0', at least for the moment, just to get a release out there? This is the only option I can accommodate in the short term. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Chris S. <ir0...@gm...> - 2012-06-20 12:23:29
|
On 20 June 2012 08:13, Chris Sutcliffe wrote: > On 19 June 2012 20:29, Greg Chicares wrote: >> (3) This may be laborious, but you could toggle individual optimization >> options instead of combinations such as '-O2' represents, to try to >> figure out which optimization is misbehaving. Similarly, if you have >> more than one source file, then toggling '-O2' for one file at a time >> might pin the problem down to one file. > > This would likely track down the particular optimization, > unfortunately I don't have the time to compile and test each > optimization individually. If someone else was willing to do so it > would be greatly appreciated. If someone is interested, you can find out the list of enabled optimizations with 'gcc -Q -help=optimizers'. Running this command and piping it through grep for enabled flags I count 50 optimizations that are enabled. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Chris S. <ir0...@gm...> - 2012-06-22 12:16:15
|
On 20 June 2012 08:13, Chris Sutcliffe wrote: > On 19 June 2012 20:29, Greg Chicares wrote: >> (4) I think prior discussions suggested that the problem occurs when >> (and only when?) the startup code is compiled with optimization. >> Would programs be noticeably slower if the startup code were built >> with '-O0', at least for the moment, just to get a release out there? > > This is the only option I can accommodate in the short term. Should I proceed? Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Cesar S. <ces...@gm...> - 2012-06-29 03:52:14
|
On 6/19/2012 12:59 AM, Cesar Strauss wrote: > It seems gcc 4.7.0 miscompiles the startup code. I'm experiencing a > crash every time I run a minimal "do nothing" application compiled with > gcc 4.7.0 and the new runtime. The crash occurs in __dyn_tls_init (tlssup.c). I found it by setting a breakpoint in __mingw_CRTStartup() and executing the startup code (compiled with optimizations) line by line. Looking at the function in CVS, I see that it was updated since the last release. In particular, one of the changes included this comment: /* Use the nfuncs variable to iterate the TLS functions instead of pfunc to avoid nasty compiler optimizations when comparing two global pointers. */ In fact, the CVS version of the mingwrt no longer crashes when compiled with optimizations in gcc 4.7.0. So, the choices are: 1) A new '-2' release of the existing version, with the startup code built with '-O0', as suggested by Greg; 2) A new '-2' release of the existing version, with the following patch applied: http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/tlssup.c.diff?r1=1.4&r2=1.5&cvsroot=src 3) A new release from CVS. My personal preference is 3, followed by 2, then 1. Cesar |
From: Chris S. <ir0...@gm...> - 2012-06-29 11:04:00
|
On 28 June 2012 23:52, Cesar Strauss wrote: > On 6/19/2012 12:59 AM, Cesar Strauss wrote: >> It seems gcc 4.7.0 miscompiles the startup code. I'm experiencing a >> crash every time I run a minimal "do nothing" application compiled with >> gcc 4.7.0 and the new runtime. > > The crash occurs in __dyn_tls_init (tlssup.c). I found it by setting a > breakpoint in __mingw_CRTStartup() and executing the startup code > (compiled with optimizations) line by line. > > Looking at the function in CVS, I see that it was updated since the last > release. In particular, one of the changes included this comment: > > /* Use the nfuncs variable to iterate the TLS functions instead of pfunc > to avoid nasty compiler optimizations when comparing two global pointers. */ > > In fact, the CVS version of the mingwrt no longer crashes when compiled > with optimizations in gcc 4.7.0. Excellent, thank you for taking the time to dig into this. > So, the choices are: > > 1) A new '-2' release of the existing version, with the startup code > built with '-O0', as suggested by Greg; > > 2) A new '-2' release of the existing version, with the following patch > applied: > > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/tlssup.c.diff?r1=1.4&r2=1.5&cvsroot=src > > 3) A new release from CVS. > > My personal preference is 3, followed by 2, then 1. Agreed, I will focus on creating a new mingwrt release based on CVS. I'll also do a sweep of the bug reports, patches, etc. prior to making the release. I should hopefully have it out in about a week. Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Keith M. <kei...@us...> - 2012-06-29 20:07:27
|
On 29/06/12 12:03, Chris Sutcliffe wrote: > > 2) A new '-2' release of the existing version, with the following patch > > applied: > > > > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/tlssup.c.diff?r1=1.4&r2=1.5&cvsroot=src > > > > 3) A new release from CVS. > > > > My personal preference is 3, followed by 2, then 1. > > Agreed, I will focus on creating a new mingwrt release based on CVS. > I'll also do a sweep of the bug reports, patches, etc. prior to making > the release. I should hopefully have it out in about a week. I'm still inclined to favour (2), as an interim step; remember that (3) will break ABI for any pre-compiled clients depending on dirent.[ch], so the next build from CVS should be at version 4.0, and not 3.21. The prime motivation for the ABI break, (besides fixing several POSIX non-conformances), was to support the new glob(3) API, which isn't yet in CVS, but can be found at http://tinyurl.com/cgkckca This will be a prerequisite to fixing aspect (2) of bug #3482704, (see http://tinyurl.com/clhlmu3), per http://tinyurl.com/cykazyx It would be kind of nice to include this glob(3) implementation, and its associated start-up code hooks, into an upcoming mingwrt-4.0, but Eli has raised some further concerns: http://tinyurl.com/bncxwpn I've been too busy, with day-job issues, to follow up on this, but I do think we need some further discussion before jumping in with an ABI breaking release, especially if there's a possibility we may want to break it again in the foreseeable future. -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2012-06-29 23:27:33
|
On 29 June 2012 16:07, Keith Marshall wrote: > On 29/06/12 12:03, Chris Sutcliffe wrote: >> > 2) A new '-2' release of the existing version, with the following patch >> > applied: >> > >> > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/tlssup.c.diff?r1=1.4&r2=1.5&cvsroot=src >> > >> > 3) A new release from CVS. >> > >> > My personal preference is 3, followed by 2, then 1. >> >> Agreed, I will focus on creating a new mingwrt release based on CVS. >> I'll also do a sweep of the bug reports, patches, etc. prior to making >> the release. I should hopefully have it out in about a week. > > I'm still inclined to favour (2), as an interim step; remember that (3) > will break ABI for any pre-compiled clients depending on dirent.[ch], so > the next build from CVS should be at version 4.0, and not 3.21. Fair enough, I've uploaded a new '-2' release with the patch applied. As per Earnie's earlier emails, I'd appreciate some guidance as to how the xml files should be updated to reflect that the '-2' release required GCC 4.7.0 or above. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Keith M. <kei...@us...> - 2012-06-30 13:51:10
|
On 30/06/12 00:27, Chris Sutcliffe wrote: > Fair enough, I've uploaded a new '-2' release with the patch applied. Thanks. > As per Earnie's earlier emails, I'd appreciate some guidance as to how > the xml files should be updated to reflect that the '-2' release > required GCC 4.7.0 or above. What are its dependencies? You may have used GCC-4.7 to build it, (and GCC-4.7 may need to declare <requires ge="mingwrt-3.20-2-... />), but is there any component, provided by GCC-4.7, which mingwrt-3.20-2-dev cannot live without? If "yes", then you need to add the appropriate <requires ge="..." /> specs, (and earlier GCC may need complementary <requires lt="mingwrt-3.20-2... /> specs). -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2012-06-30 14:19:27
|
On 30 June 2012 09:50, Keith Marshall wrote: > On 30/06/12 00:27, Chris Sutcliffe wrote: >> As per Earnie's earlier emails, I'd appreciate some guidance as to how >> the xml files should be updated to reflect that the '-2' release >> required GCC 4.7.0 or above. > > What are its dependencies? You may have used GCC-4.7 to build it, (and > GCC-4.7 may need to declare <requires ge="mingwrt-3.20-2-... />), but is > there any component, provided by GCC-4.7, which mingwrt-3.20-2-dev > cannot live without? If "yes", then you need to add the appropriate > <requires ge="..." /> specs, (and earlier GCC may need complementary > <requires lt="mingwrt-3.20-2... /> specs). Good point, I guess the dependency is on the GCC side. I'll update the mingwrt xml accordingly and upload it later today. Cheers, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Chris S. <ir0...@gm...> - 2012-06-30 17:49:36
|
Hi Cesar, On 30 June 2012 10:19, Chris Sutcliffe wrote: > Good point, I guess the dependency is on the GCC side. I'll update > the mingwrt xml accordingly and upload it later today. I've uploaded an updated mingw32-runtime.xml file, please update the GCC xml file accordingly. Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Keith M. <kei...@us...> - 2012-06-30 20:45:29
|
Hi Chris, On 30/06/12 18:49, Chris Sutcliffe wrote: > I've uploaded an updated mingw32-runtime.xml file, please update the > GCC xml file accordingly. I notice you added a bunch of redundant source and licence references, at release level, where a pair of generic references at package level would have sufficed. I guess you were concerned about matching differing compression types, and didn't realise that you could use the "%" wildcard? Although your redundant declarations should still work, they are wasteful, (because mingw-get must allocate memory for each individual duplicate), so I've taken the liberty of cleaning them up for you. -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2012-06-30 22:29:44
|
Hi Keith, On 30 June 2012 16:45, Keith Marshall wrote: > I guess you were concerned about matching differing compression types, > and didn't realise that you could use the "%" wildcard? Although your > redundant declarations should still work, they are wasteful, (because > mingw-get must allocate memory for each individual duplicate), so I've > taken the liberty of cleaning them up for you. Correct, I was concern about the compression type and I wasn't aware that the '%' wildcard could be used elsewhere (other than version numbers). Thank you for cleaning this up. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |