On Wed, Jul 23, 2014 at 10:01 PM, Mark de Wever <ko...@xs4all.nl> wrote:
> On Mon, Jul 21, 2014 at 04:10:41PM -0400, chris beck wrote: > > Dear List, > > > > This is an issue from about a month ago actually, but it was brought up > > again on irc today so I thought I would write this email. > > > > Since some commit on June 15, the travis gcc build (which used the travis > > default gcc version of 4.6) began segfaulting when trying to build > wesnoth. > > It would be nice to know the commit that introduced, maybe the code can > be written differently so the problem no longer occurs. > > > I don't remember whether we reported the segfault to the gcc maintainers, > > but regardless, since there's apparently nothing we can do to debug gcc > and > > stop it from crashing, > > GCC 4.6 and 4.7 are no longer supported by upstream and since 4.8 > doesn't have the problem I think it makes little sense to sumbit a > report. I tested with GCC 4.4 yesterday and there was no ICE. Shadow > master tested with GCC 4.6 with -O0 instead of -O2 and there was no ICE. > (I have observed that behaviour with other ICEs in a different project > the past.) > > Perhaps the solution is to just add __attribute__((optimize(0))) to a few functions for the GCC 4.6-4.7? Note that one could declare function with that attribute and and then implementation of it will be compiled without optimization. > > I think we should actually upgrade the project gcc build requirements > > to version 4.8. (Or maybe 4.7, I don't know right now what is the > > actually the minimal version that doesn't crash.) > > > > I didn't propose this initially because frankly I had never heard of gcc > > segfaulting like this, and I hoped that it would just go away. But it > > doesn't seem to be going away. If we upgrade the compiler requirements in > > the scons / cmake recipes, then at least it will save any user or > developer > > an hours worth of compiling which leads inevitably to a crash. > > > > Are there any objections to this? > > I think it's a bad idea to bump the minimum version, especially since > GCC 4.4 has no problems. I think it would be good to document this issue > in the INSTALL and RELEASE_NOTES files. IMO we should only bump the > requirements if we're 100% sure older versions will no longer compile. > For example if we move to C++11 it would be a good idea to drop support > for older GCC versions, that have no (or little) C++11 support. > > -- > Regards, > Mark de Wever aka Mordante/SkeletonCrew > > _______________________________________________ > Wesnoth-dev mailing list > Wesnoth-dev@gna.org > https://mail.gna.org/listinfo/wesnoth-dev >
_______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
