United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6958465 Sparc aten build24.0: openjdk-7.ea-b96 failed Error: Formal argument ... requires an lvalue
JDK-6958465 : Sparc aten build24.0: openjdk-7.ea-b96 failed Error: Formal argument ... requires an lvalue

Details
Type:
Bug
Submit Date:
2010-06-04
Status:
Closed
Updated Date:
2012-05-02
Project Name:
JDK
Resolved Date:
2011-04-23
Component:
hotspot
OS:
solaris_10
Sub-Component:
build
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
aten
Fixed Versions:
hs19 (b06)

Related Reports
Backport:
Backport:
Backport:
Backport:

Sub Tasks

Description
aten build24.0: failed to build  openjdk-7.ea-b96 on Sparc.
build23.0 does not have such error.

If it turns out to be an error in  hotspot sources,
please transfer this bug to jvm/hotspot/other


How to reproduce
================

cp -r  /net/clpt41/export/home/isvs/hotspot-7.ea.b96_sparc <your_area_on_sparc>
cd <your_area_on_sparc>/hotspot-7.ea.b96_sparc
bld_hotspot_bug.sh

The failure looks like this:

===== Build 24.0
"src_server/methodHandles_sparc.cpp", line 76: Error: Formal argument addrlit of type AddressLiteral& in call to MacroAssembler::jump_to(AddressLiteral&, RegisterImpl*, int) requires an lvalue.
"src_server/methodHandles_sparc.cpp", line 501: Error: Formal argument addrlit of type AddressLiteral& in call to MacroAssembler::jump_to(AddressLiteral&, RegisterImpl*, int) requires an lvalue.
"src_server/methodHandles_sparc.cpp", line 595: Error: Formal argument addrlit of type AddressLiteral& in call to MacroAssembler::jump_to(AddressLiteral&, RegisterImpl*, int) requires an lvalue.
3 Error(s) detected.
The Studio 12.2 C++ compiler 5.11 no longer allows by default invalid code that attempts to initialize a reference to a non-const object with an rvalue.

The failing code in question follows this model:
   class T { ... };
   void foo(T&); // foo takes a reference to a non-const T, requires lvalue
   ...
   foo( T() ); // T() is an rvalue, not an lvalue

Sun compilers were lax in enforcing the rule that a reference to a non-const object cannot be initialized with an lvalue (like a temporary object). Popular open-source code like Boost now requires strict enforcement of the rule, becuase it affects function overload resolution. To get correct behavior the invalid code cannot be accepted.

The best option is to fix the code. In my example, you would create an explicit temporary variable:
   T t;
   foo( t ); // t is an lvalue
This code is valid and will work with any compiler from any vendor. It has the same net effect as the invalid code.

If you are in a situation where you cannot modify the code but need to use the newer compiler, you can use a CC Qoption to restore the old compiler behavior:
   -Qoption ccfe -features=rvalueref
Add this option to the command that generates complaints about this kind of invalid initialization. This usage should be regarded as a temporary measure until the source code can be fixed.

                                    

Comments
SUGGESTED FIX

Approximate patch is attached: addrlit.zip
                                     
2010-07-23
EVALUATION

Description is correct.
                                     
2010-07-23
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a64438a2b7e8
                                     
2010-07-29
EVALUATION

Summary: Fix compilation errors.  Made non-const references const so can be assigned with lvalue.
                                     
2010-07-29
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a64438a2b7e8
                                     
2010-08-02



Hardware and Software, Engineered to Work Together