RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build.

[Lindenmaier, Goetz]

Hi Kim,

I really would appreciate if we could get this fixed soon.
Maybe we can submit my version and if we put a comment into
8135181 that points to this change, the questionable casts can be 
identified later on, too.

The broken build hinders our work. I have to manually fix our nightbuilds all 
the time, and my colleagues stomped into this and fixed it in their workspace
locally.  Any webrev we prepare we have to patch with this change ...
So I really would like to see this resolved.

The change is now pending since 19.11.

I rebased my webrev, which also contains some more casts
for issues poping up since my first attempt to fix this:
http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.01/
(Kim, you've seen this before).

Best regards,
  Goetz


> -----Original Message-----
> From: Kim Barrett [mailto:kim.barrett at oracle.com]
> Sent: Freitag, 20. November 2015 02:05
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build.
> 
> On Nov 19, 2015, at 4:44 AM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > OK, so I went back and checked it all ...
> > 1.) -Wconversion is set since ever:
> >     http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3e82d72933d0
> > 2.) The warning is not triggered by -Wconversion, it is enabled per default
> in gcc 4.1.2:
> 
> Does the warning still occur if -Wconversion is explicitly turn it
> off, e.g. add -Wno-conversion?  Unfortunately, after reading these
> 
> http://lists.apple.com/archives/xcode-users/2005/Oct/msg00147.html
> https://gcc.gnu.org/wiki/NewWconversion
> 
> I suspect it does, which would be unfortunate. But confirmation would
> be helpful, and would strongly affect my opinion about how to proceed.
> 
> [Note that the NewWconversion page suggests we really ought not be
> using the pre-gcc4.3 -Wconversion either.  But if -Wno-conversion
> doesn't do anything useful for you then that's a separate issue.]
> 
> An important (to me) reason to not hide these warnings via unchecked
> casts is that doing so makes it harder to properly address
> JDK-8135181, because some of the places that ought to be modified as
> part of that will be harder to find.
> 
> > And I would really appreciate if the following two issues could be kept
> separate:
> >
> > - Decision what compiler is supported with which settings.
> > - Fixes for a supported compiler/flag combination.
> 
> I don't think those are separable. If a particular configuration
> rejects otherwise working code, then the configuration ought to be
> looked at. Even if it's decided that the code must be changed rather
> than the configuration, if the modified code is clearly a workaround
> rather than a "natural" alternative, I think the workaround should be
> made obvious and traceable to the problematic configuration.
> Otherwise, future readers cannot tell whether the code is odd for a
> good reason, and the workaround is hard to clean up in the future.
> 
> The fact that this particular problem has been cropping up repeatedly
> suggests to me that some concerted effort should be applied to the
> problem.  I spent a little bit of time today prototyping an
> integer_cast function, which would cover most of the cases mentioned
> in JDK-8135181 and all in the changeset under discussion.  It doesn't
> look too difficult, but I haven't finished or really tested it yet.