From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8789 invoked by alias); 1 Feb 2005 13:01:25 -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 8602 invoked by uid 48); 1 Feb 2005 13:01:18 -0000 Date: Tue, 01 Feb 2005 13:01:00 -0000 Message-ID: <20050201130118.8591.qmail@sourceware.org> From: "rmathew at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050201065958.19738.rmathew@gcc.gnu.org> References: <20050201065958.19738.rmathew@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug java/19738] gcjh generates invalid class member floating-point initialisers X-Bugzilla-Reason: CC X-SW-Source: 2005-02/txt/msg00063.txt.bz2 List-Id: ------- Additional Comments From rmathew at gcc dot gnu dot org 2005-02-01 13:01 ------- (In reply to comment #2) > Yes. Notice that also this code: > > struct A > { > static const int a = 45; > }; > > is invalid without a matching definition. That is, you need to > provide a single definition of: > > const int A::a; Thanks, I understand this. I was wondering why gcjh generates an explicit (and incorrect for reals, as it turns out) initialisation for a "final" Java field but not otherwise. That is, given: static final int foo = 32; v/s static int bar = 42; gcjh generates the initialiser only for "foo", but not "bar". In both cases, *someone* needs to initialise these fields, right? Since these are generated from Java classes, presumably the "Java side" will initialise them - but then, why explicitly write it out for "final" (const) fields? This is what I attempted to suppress with my patch in the first followup comment in this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19738