From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28408 invoked by alias); 16 Oct 2004 17:26:08 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 28371 invoked by uid 48); 16 Oct 2004 17:26:07 -0000 Date: Sat, 16 Oct 2004 17:26:00 -0000 Message-ID: <20041016172607.28370.qmail@sourceware.org> From: "ebotcazou at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20041002054828.17793.pinskia@gcc.gnu.org> References: <20041002054828.17793.pinskia@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug middle-end/17793] [4.0 Regression] Ada bootstrap failure X-Bugzilla-Reason: CC X-SW-Source: 2004-10/txt/msg02265.txt.bz2 List-Id: ------- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-16 17:26 ------- [Thanks for elaborating on your position.] > check_pointer_types_r is wrong but so is Ada assuming that integer types are > not compatible (read the full bug report which I reported in the first place): > "The integer_type's are not compatible by defined by the front-end, why?" My understanding is that type compatibility is purely a front-end business, so there is not really a notion of being right or wrong here. The middle-end should be able to cope with either situation. > See this is where Ada becomes wrong with respect to generic and gimple where > it needs integer types which have the same PRECISION, UNSIGNEDness, and SIZE > are consided compatible types (so are their POINTERs). Could you point me at where this requirement is documented? The Ada front-end contains this comment (misc.c:560): ??? We may also want to generalize to considering lots of integer types compatible, but we need to understand the effects of alias sets first. > For Kenner here, Generic and Gimple have the same type system which is partly > described above. Yes this is not documented but should be. This again is an > Ada bug not doing what the middle-end generic and gimple expects to happen. I think the issue is orthogonal to the discussion on the type systems of GENERIC and GIMPLE. The front-end generates a correct GENERIC tree AFAICS so the gimplifier should be able to deal with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17793