From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73186 invoked by alias); 23 Jul 2015 23:17:39 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 73115 invoked by uid 48); 23 Jul 2015 23:17:35 -0000 From: "jason at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE Date: Thu, 23 Jul 2015 23:17:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: c++-concepts X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jason at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-07/txt/msg02044.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962 Jason Merrill changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2015-07-23 Ever confirmed|0 |1 --- Comment #8 from Jason Merrill --- (In reply to Casey Carter from comment #5) > (In reply to Markus Trippelsdorf from comment #2) > > /usr/local/gcc-concepts/include/c++/6.0.0/initializer_list:47:11: fatal > > error: definition of std::initializer_list does not match #include > > > > This is because the definition of std::initializer_list in the preprocessed > source doesn't agree with your compiler's - or mine - notion of what > std::initializer_list should be. The issue is just 32-bit vs 64-bit size_t. I'm able to reproduce the bug with the original testcase using the -m32 flag. The testcase in comment #7 has different requirements on iter_swap2, so it doesn't run into this bug. It was crashing because my recent patch needed an additional NULL check, which I have now added. The problem in Eric's testcases seems to be that decompose_assumptions is consuming an extreme amount of memory, I think because left_disjunction causes the process to have quadratic complexity. So I think we need an algorithmic change here. Andrew?