Maintenance of ftp.tsukuba.wide.ad.jp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, ftp.tsukuba.wide.ad.jp (one of mirror server) will maintenance shutdown, due to electrical equipment inspection and HW migration. start time: 27/Oct/2013 00:00 JST (UTC+0900) end time : 30/Oct/2013 00:00 JST (UTC+0900) Thank you for your understanding. - -- Kohei Takahashi WIDE Project Tsukuba NOC fl...@tsukuba.wide.ad.jp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQIcBAEBAgAGBQJSZTo9AAoJEIFgvc+dw1m2JsAQAImfnVtnoe37H4PEmbC6bhWi To60sbhyItG440T5yn3Rnmn8VZ+5iMKTunT/C7GsDUQmZG2FFb7oyGd5i8yOqXCw IKs/vsE/hWal/kO2n1G23hqhLrmWNpeQOMZG5NHPM1+eIEsq6c4ny7TbuOQ6ofuP 2fpga+iGlwuSOsiEgXzvXx/RjxQZtw4bBknOI6VkzbRi6ZKC9HTnpwn36i+z1wMN q+IsjGsHX9TRszmtBsAKadBxoEXUjn+if332chVWuVHriWltsmysBsT6v14krXE2 DGBbG7i7fqkTVtfroBHja8tLn/g2izUIN9cc/TISkvM/X4+uuUSU7G6GjwfaNnqX U/49P/7ioejZJx4dUb9LNt5bgv7CNoda1fp4V3RBkRx9xvjdOtYE0tUq5nBZMpzJ 8T9sWUTzOGSVvDaOVGnAtmfbsLuDOscLns13jX2xd/DRTS+SND099prQ3YnyOtt7 oc+by9ouEi9Erjm+fVLIMBfM+xIm+ZuwEUEO9FcPGWggtEXPuX06L9J1HQ1h5Dhd iFri9sh9CNj/XKWwA/UBrBb+BRedexly+ZOOK1XI7jGmyd0Vn4Vipoihga8Di27Y M9zPDDByMbNJ6RUVhQNtC0a6GifPFIn9To6EZG9FlIHwYIA7qbcMLu1GM9L9xFRO MbUk2+ry+d0CmCGHwsZU =CSD5 -END PGP SIGNATURE-
Re: Maintenance of ftp.tsukuba.wide.ad.jp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I announced wrong dates. Correct maintenance window is following. start time: 26/Oct/2013 00:00 JST (UTC+0900) end time : 29/Oct/2013 00:00 JST (UTC+0900) We apologize for your inconvenience. (2013/10/21 23:29), Kohei Takahashi wrote: > Hi, > > ftp.tsukuba.wide.ad.jp (one of mirror server) will maintenance > shutdown, due to electrical equipment inspection and HW migration. > > start time: 27/Oct/2013 00:00 JST (UTC+0900) > end time : 30/Oct/2013 00:00 JST (UTC+0900) > > Thank you for your understanding. > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQIcBAEBAgAGBQJSZTyrAAoJEGGyPxPRp/zobCMP/iTaunmUCtrsYV4mC7maZHoS m8I3l41JjTwYwkjLUgPTOoF02ZbEtE8P2//a/sVpbSM537YoJ+kQaVo1CCUQ4sUM 8XpoQx23x8+8AQIPmBIf7ky/Am807qlaRUccKzk56uRyQKVpLH6GTTnbX1NOa8T0 XIWeSRkhbyJHM+tykOwd3ol7xkz0cS0D/+W5M4BbBtAR5YTUr1P9T+HwjVvruksW Vma7D4lv5Gt7sFqbbb7TA6NHObaETgbqT/ebYISpaSSP3eCKTA9rsSQA7QaSPvoX slScYZ+V8C9kivuNMRJ1OcheD313ZXa44CSLC3EuOsLg6Ejf8PnfkpSyaglYZ32t pWkvztr/a93j0jgimJJpTekngsnIUCmzObyRrkTYd5cSal5HeQeIMDAX8eo/YWAV z1lz07ZyCLlssw2uN0sd3+UzcwSGUwWHLRV3gtrMnqGgHL82OEbXBJDM5JEjso3z OZMNT+4YBppgNWYtiQ1cE+BSG7+6rFXtkbUOqMpcj6gzMyKPSo2TMYNxsdqlWNVK pID0dgtViGyn8QZj1tDxM1ilCrCf0VNlT2goE2kKgmx3s6tHAs1UjmsmP23UFzXp KQkWIH4sVgmeIAMS4Vjg+CGaD+ztAph9DcrwPLo/UZHrR6okaTf//f1qTdwrFZZQ tP8vKnzoFsdHe2bcPBT0 =mxFs -END PGP SIGNATURE-
Re: make install broken on the trunk?
> "Matthias" == Matthias Klose writes: Matthias> A make install from trunk 20131020 seems to be broken, at Matthias> least when building with Go (last time I successfully Matthias> installed was 20130917). However, even without Go enabled, Matthias> dfa.c is rebuilt and and then the depending binaries are Matthias> rebuilt. Rebuilding go1 ends with If you are using bootstrap-lean then this is PR 58572. Tom
Different behavior of dejagnu testsuite with x32 and x64 cross toolchains
Hi! I have two toolchains built for arm target with the same options on different hosts (64bit and 32bit): --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none -linux-gnueabi I've met the problem while running libgomp.graphite/force-parallel-7.c execution test on one arm target. Test binaries produced with x64 toolchain showed that test failed: WARNING: program timed out. FAIL: libgomp.graphite/force-parallel-7.c execution test But at the same time test binaries produced with x32 toolchain showed that test passed: PASS: libgomp.graphite/force-parallel-7.c execution test Manual run of tests (without dejagnu) showed that test binaries have the same run time. readelf showed that my binaries differ only in debug_info section and memory usage. I'm a little confused what's going wrong while test built with 64 toolchain is running on my target? Why timeout occur only for this binary? Do you have any ideas why could it happen? Thank you, Tatiana
Re: [RFC] Include file structuring.
Hi, On Fri, Oct 18, 2013 at 10:00:13AM -0400, Andrew MacLeod wrote: > At a minimum, I do think that if a .h file *requires* another .h > file to compile, that it should include it. Absolutely. > ie, if gimple-ssa.h is > included, it wont compile unless tree-ssa-operands.h has already > been included, so that seems reasonable to include directly in > gimple-ssa.h. Otherwise ones needs to add the file, compile, and > then figure out what other file you need. That seems silly to me. Indeed. And it is easy to overlook the file is already included couple of lines below. This has just happened to me when dealing with all requirements for the new tree-phinodes.h. Thanks, Martin
Re: [RFC] Include file structuring.
On Fri, Oct 18, 2013 at 10:00 AM, Andrew MacLeod wrote: > The question is... Do we allow a .h file like this to be an aggregator, > meaning a file can just include tree-ssa.h and get all this, or do we push > it all down to the .c file, and actually include what each one needs. Or do > we pick a specific subset for tree-ssa.h... In general, I'm a big fan of Include What You Use (IWYU). Files should explicitly include everything they need. Moreover, header files should not bleed onto each other. This means that they should be self-contained (i.e., I should be able to re-order the set of #includes in a given .c file without altering the semantics of the TU). In the case of headers, this is a double edge sword, on the one hand you want to make it self-contained (so it should #include everything it needs), and at the same time you want to disallow headers to #include other files. As much as possible, I agree that we should not allow header files to include other headers. Using forward type declarations can alleviate this problem somewhat. But if the header has inline functions, you're forced to include the other header it depends on. IWYU is important in the long term so that we can take advantage of C++ modules. For now, moving to a model where no header files include other headers will allow us to fix modularity problems. This will give us IWYU in .c files, we can later think about enforcing IWYU for .h files. Diego.
Sorry, couldn't resist this one:
https://twitter.com/ToonMoene/status/392392928493973504 -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
