User account creation filtered due to spam.

Bug 42892 - Incorrect code generated for enhanced for loop.
Summary: Incorrect code generated for enhanced for loop.
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.4.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-28 06:51 UTC by Ralph Loader
Modified: 2016-09-30 22:49 UTC (History)
2 users (show)

See Also:
Host: x86_64-redhat-linux
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-02-07 20:25:51


Attachments
Test case (344 bytes, text/x-java)
2010-01-28 06:51 UTC, Ralph Loader
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Loader 2010-01-28 06:51:05 UTC
The following code (to be attached) contains two loops, one of which is miscompiled.

The first is an enhanced for loop, the second is the same loop, but manually desugared accorded to the JLS (JLS 3, section 14.14.2 http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.14.2).

The two loops should therefore behave identically.  They do not; the first loop [incorrectly] finishes normally, the second loop [correctly] throws a class cast exception.

The issue is that according to the JLS,

   for (String s:u) ...

gets desugarred to

   for (Type i = u.iterator(); i.hasNext(); ) { String s = i.next(); ... }

where Type is the type of u.iterator().

However, after erasing generics, the initialisation of the loop variable i potentially requires a cast (after erase, in this case, u.iterator() has compile-time type Iterator, while the variable has type MyIterator).

It appears that gcj does not insert the required cast.

(Both Sun javac and eclipse get this wrong also, in an identical manner.  It is possible that Sun will decide to change the JLS to match the compiler behaviour?)
Comment 1 Ralph Loader 2010-01-28 06:51:47 UTC
Created attachment 19736 [details]
Test case
Comment 2 Andrew Pinski 2010-01-28 06:53:23 UTC
>Both Sun javac and eclipse 

Well gcj uses eclipse source to byte code compiler to compile to byte code so it might not be a bug in gcj's byte code compiler.
Comment 3 Ralph Loader 2010-01-28 07:02:58 UTC
So java front end bugs shouldn't be logged here?
Comment 4 Andrew Pinski 2010-01-28 07:07:45 UTC
(In reply to comment #3)
> So java front end bugs shouldn't be logged here?

No they should be.  Just I was trying to point out gcj uses ecj as the source front-end.  It might be the bytecode compiler which is broke and not the source to byte code part (which is ecj).  If it is ecj which is getting it incorrect as you had suggested in comment #0, then it should be reported upsteam and this bug should be suspended until that is fixed.
Comment 5 Ralph Loader 2010-01-28 07:26:48 UTC
Ok, it is an ecj bug.  I'll report upstream as soon as their bugzilla stops hanging...
Comment 6 Andrew Pinski 2010-02-07 20:25:51 UTC
Confirmed to ...
Comment 7 Andrew Pinski 2010-02-07 20:26:10 UTC
Suspend.
Comment 8 Andrew Pinski 2016-09-30 22:49:12 UTC
Closing as won't fix as the Java front-end has been removed from the trunk.