From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7990 invoked by alias); 13 Oct 2012 13:28:32 -0000 Received: (qmail 7974 invoked by uid 22791); 13 Oct 2012 13:28:31 -0000 X-SWARE-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_THREADED,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mail.physik.uni-muenchen.de (HELO mail.physik.uni-muenchen.de) (192.54.42.129) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 13 Oct 2012 13:28:28 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id CF47A27E93; Sat, 13 Oct 2012 15:28:26 +0200 (CEST) Received: from mail.physik.uni-muenchen.de ([127.0.0.1]) by localhost (mail.physik.uni-muenchen.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XqyXq2OOHTUb; Sat, 13 Oct 2012 15:28:26 +0200 (CEST) Received: from tobias-schluters-computer.local (e181018138.adsl.alicedsl.de [85.181.18.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 45EF427D66; Sat, 13 Oct 2012 15:28:26 +0200 (CEST) Message-ID: <50796C79.5010204@physik.uni-muenchen.de> Date: Sat, 13 Oct 2012 13:51:00 -0000 From: =?UTF-8?B?VG9iaWFzIFNjaGzDvHRlcg==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Fortran List , gcc-patches Subject: Re: PR fortran/51727: make module files reproducible, question on C++ in gcc References: <50796BF5.4060100@physik.uni-muenchen.de> In-Reply-To: <50796BF5.4060100@physik.uni-muenchen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-10/txt/msg01287.txt.bz2 ps I forgot to mention that I also changed write_generic to traverse the=20 tree in defined order, this is the same in the C++ and the C-only patch. Cheers, - Tobi On 2012-10-13 15:26, Tobias Schl=C3=BCter wrote: > > Hi, > > first a question also to non-gfortraners: if I want to use std::map, > where do I "#include "? In system.h? > > Now to the patch-specific part: in this PR, module files are produced > with random changes because the order in which symbols are written can > depend on the memory layout. This patch fixes this by recording which > symbols need to be written and then processing them in order. The patch > doesn't make the more involved effort of putting all symbols into the > module in an easily predicted order, instead it only makes sure that the > order remains fixed across the compiler invocations. The reason why the > former is difficult is that during the process of writing a symbol, it > can turn out that other symbols will have to be written as well (say, > because they appear in array specifications). Since the module-writing > code determines which symbols to output while actually writing the file, > recording all the symbols that need to be written before writing to the > file would mean a lot of surgery. > > I'm putting forward two patches. One uses a C++ map to very concisely > build up and handle the ordered list of symbols. This has three problems: > 1) gfortran maintainers may not want C++isms (even though in this case > it's very localized, and in my opinion very transparent), and > 2) it can't be backported to old release branches which are still > compiled as C. Joost expressed interested in a backport. > 3) I don't know where to #include (see above) > Therefore I also propose a patch where I added the necessary ~50 lines > of boilerplate code and added the necessary traversal function to use > gfortran's GFC_BBT to maintain the ordered tree of symbols. > > Both patches pass the testsuite and Joost confirms that they fix the > problem with CP2K. I also verified with a few examples that they both > produce identical .mod files as they should. > > Is the C++ patch, modified to do the #include correctly, ok for the > trunk? If not, the C-only patch? Can I put the C-only patch on the > release branches? And which? > > Cheers, > - Tobi