[Bug java/42892] New: Incorrect code generated for enhanced for loop.
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?)
--
Summary: Incorrect code generated for enhanced for loop.
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
GCC host triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892
[Bug java/42892] Incorrect code generated for enhanced for loop.
--- Comment #1 from suckfish at ihug dot co dot nz 2010-01-28 06:51 --- Created an attachment (id=19736) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19736action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892
[Bug java/42892] Incorrect code generated for enhanced for loop.
--- Comment #3 from suckfish at ihug dot co dot nz 2010-01-28 07:02 --- So java front end bugs shouldn't be logged here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892
[Bug java/42892] Incorrect code generated for enhanced for loop.
--- Comment #5 from suckfish at ihug dot co dot nz 2010-01-28 07:26 --- Ok, it is an ecj bug. I'll report upstream as soon as their bugzilla stops hanging... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892
[Bug middle-end/37809] [4.2/4.3/4.4 Regression] Incorrect code with MMX right shift __builtin_ia32_psradi
--- Comment #7 from suckfish at ihug dot co dot nz 2008-11-10 07:44 --- Could someone commit the patch? [http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00147.html] I don't have SVN commit access. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809
[Bug middle-end/37809] [4.2/4.3/4.4 Regression] Incorrect code with MMX right shift __builtin_ia32_psradi
--- Comment #6 from suckfish at ihug dot co dot nz 2008-10-17 22:18 ---
Pleasantly, my fears that this was just the tip of the iceburg seems to be
wrong. Writing some test cases, found another bug involving a shift, and also
the ICE below [fixed by some combination of change above and 38707 fix.]
Will fix the remaining case post patches to gcc-patches list.
#include mmintrin.h
typedef int v2si __attribute__ ((vector_size (8)));
v2si shiftU (v2si y)
{
return _m_psrldi (_m_psrldi (y, 0), 0);
}
$ gcc -O shift2.c
shift2.c: In function shiftU:
shift2.c:6: internal compiler error: in trunc_int_for_mode, at explow.c:55
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla for instructions.
Preprocessed source stored into /tmp/cckqI2oC.out file, please attach this to
your bugreport.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809
[Bug target/37809] [4.2/4.3/4.4 Regression] Incorrect code with MMX right shift __builtin_ia32_psradi
--- Comment #4 from suckfish at ihug dot co dot nz 2008-10-14 07:17 ---
Digging a bit, in combine.c, the ASHIFTRT case of force_to_mode() contains two
calls to simplify_shift_const(). Disabling those for vector modes fixes the
test case here (patch below).
But I suspect this is just the tip of the iceberg; there are probably many
other arithmetic simplifications here that will get incorrectly applied to
vector types, especially when sizeof(vector type) = sizeof (HOST_WIDE_INT).
Do we need to audit the whole compiler for such things, or is there a sensible
place we can insert a don't-optimise-vector-types test with disabling too many
useful optimisations?
Thinking that the test-suite probably contains many more tests for 128 bit
vector types, would it be possible/worth-while to build a compiler run the
test-suite with HOST_WIDE_INT being 128 bits?
diff --git a/gcc/combine.c b/gcc/combine.c
index 5821301..ad24d94 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -7635,7 +7635,8 @@
nonzero = INTVAL (XEXP (x, 1));
}
- if ((mask ~nonzero) == 0)
+ if ((mask ~nonzero) == 0
+ !VECTOR_MODE_P (mode) !VECTOR_MODE_P (GET_MODE (x)))
{
x = simplify_shift_const (NULL_RTX, LSHIFTRT, GET_MODE (x),
XEXP (x, 0), INTVAL (XEXP (x, 1)));
@@ -7643,7 +7644,8 @@
return force_to_mode (x, mode, mask, next_select);
}
- else if ((i = exact_log2 (mask)) = 0)
+ else if ((i = exact_log2 (mask)) = 0
+!VECTOR_MODE_P (mode) !VECTOR_MODE_P (GET_MODE (x)))
{
x = simplify_shift_const
(NULL_RTX, LSHIFTRT, GET_MODE (x), XEXP (x, 0),
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809
[Bug c/37807] New: Exponential compile time with MMX builtins.
Using MMX bultins in a sizeable but not extreme function leads to exponential compile time. Attached code will take an excessive compile time [I think hours]. Similar code using SSE compiles quickly for me. $ gcc --version gcc (GCC) 4.3.2 20081007 (Red Hat 4.3.2-6) Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Summary: Exponential compile time with MMX builtins. Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: suckfish at ihug dot co dot nz GCC build triplet: x86-64 GCC host triplet: x86-64 GCC target triplet: x86-64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
[Bug c/37807] Exponential compile time with MMX builtins.
--- Comment #1 from suckfish at ihug dot co dot nz 2008-10-11 21:21 --- Created an attachment (id=16482) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16482action=view) Code showing exponential compile time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
[Bug c/37807] Exponential compile time with MMX builtins.
--- Comment #2 from suckfish at ihug dot co dot nz 2008-10-11 21:35 --- Using '-da' it looks like the 'combine' pass is the culprit: $ pidof cc1 6410 $ ls -l /proc/6410/fd ... 4 - ... slow.c.162r.combine $ ls -s slow.c.162r.combine 0 slow.c.162r.combine [is there an easier way to get cc1 to tell me what pass it's running when?] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
[Bug c/37807] Exponential compile time with MMX builtins.
--- Comment #4 from suckfish at ihug dot co dot nz 2008-10-11 22:23 --- BTW, __builtin_ia32_psrld and __builtin_ia32_pslld are not documented on the 'X86 built-in functions' page of the manual. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
[Bug c/37807] Exponential compile time with MMX builtins.
--- Comment #5 from suckfish at ihug dot co dot nz 2008-10-11 23:02 --- It looks like nonzero_bits1 in rtlanal.c is going into an exponential recursion. AFAICS, that function doesn't deal properly with vector arithmetic anyway? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
[Bug c/37807] Exponential compile time with MMX builtins.
--- Comment #6 from suckfish at ihug dot co dot nz 2008-10-11 23:24 ---
I think this function actually gets miscompiled:
typedef int v2si __attribute__ ((vector_size (8)));
v2si foo (v2si x)
{
x = (v2si) 0xll;
x = __builtin_ia32_psrad (x, 1);
x = (v2si) 0x8000ll;
return x;
}
to
foo:
pxor%xmm0, %xmm0
ret
The psrad is preserving the sign bit we are returning, so the compiler should
not assume it to be zero.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
[Bug c/37809] New: Incorrect code with MMX right shift __builtin_ia32_psradi
Bug on both trunk and 4.3.2 [for the latter, change psradi to psrad as the
builtin function name changed].
Compiling the following code with -O2 -flax-vector-conversions -mmmx -msse
-msse2 generates incorrect code:
typedef int v2si __attribute__ ((vector_size (8)));
v2si foo (v2si x)
{
x = (v2si) 0xll;
x = __builtin_ia32_psradi (x, 1);
x = (v2si) 0x8000ll;
return x;
}
The compile incorrectly assumes that bit 31 of the shift result always ends up
as zero:
foo:
pxor%xmm0, %xmm0
ret
Presumeably, some optimiseration is incorrectly treating the v2si right shift
as a 64-bit right shift.
[It appears to me that both nonzero_bits1 and num_sign_bit_copies1 can
incorrectly optimise vector operation as if they were scalar ops, which is what
inspired this example, however, attempting to fix those did not fix this bug,
which makes me think the problem is elsewhere.]
--
Summary: Incorrect code with MMX right shift
__builtin_ia32_psradi
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809
[Bug c/37807] Exponential compile time with MMX builtins.
--- Comment #7 from suckfish at ihug dot co dot nz 2008-10-12 02:39 --- Bug 37809 opened for the issue in internal comment 6, as it is different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
[Bug c/37809] Incorrect code with MMX right shift __builtin_ia32_psradi
--- Comment #1 from suckfish at ihug dot co dot nz 2008-10-12 02:47 --- Created an attachment (id=16483) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16483action=view) Test case as a complete program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809
[Bug c/37807] Exponential compile time with MMX builtins.
--- Comment #8 from suckfish at ihug dot co dot nz 2008-10-12 04:46 --- Created an attachment (id=16484) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16484action=view) Test-case modfied to take exponential time on trunk too. It turns out that it was fast on trunk because inlining is less aggressive there. Making some functions inline causes compile time to blow up with trunk also. Updated test case attached also. PS. The correct fix for the rotate on trunk was to use __builtin_ia32_psrldi/pslldi. -- suckfish at ihug dot co dot nz changed: What|Removed |Added Attachment #16482|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
[Bug c/37807] Exponential compile time with MMX builtins.
--- Comment #9 from suckfish at ihug dot co dot nz 2008-10-12 05:22 --- Created an attachment (id=16486) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16486action=view) Possible fix for 37807 Patch above essentially stops nonzero_bits1 and num_sign_bit_copies1 processing vector types. This fixes the problem looking at those functions, they were not written with vector types in mind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
[Bug c/37807] Exponential compile time with MMX builtins.
--- Comment #10 from suckfish at ihug dot co dot nz 2008-10-12 05:27 --- Changelog for patch if accepted [will do full bootstrap make test]: 2008-10-12 Ralph Loader [EMAIL PROTECTED] PR 37807 * rtlanal.c (numzero_bits1): Return early on vector types, avoiding exponential time recursion. (num_sign_bit_copies1): Likewise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37807
[Bug c/37743] New: Bogus printf format warning with __builtin_bswap32.
Code below generates an incorrect warning:
$ gcc -Wall -c temp.c
temp.c:4: warning: format %x expects type unsigned int, but argument 2 has
type unsigned int
$ cat temp.c
int format (const char * f, ...) __attribute__ ((format (printf, 1, 2)));
void bar (unsigned int x)
{
format (%x, __builtin_bswap32 (x));
}
Unless I'm going mad, unsigned int and unsigned int are identical.
Giving an explicit prototype of __builtin_bswap32 works-around.
$ gcc --version ; rpm -q gcc
gcc (GCC) 4.3.2 20080917 (Red Hat 4.3.2-4)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gcc-4.3.2-4.x86_64
--
Summary: Bogus printf format warning with __builtin_bswap32.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743
[Bug c++/25362] New: Error message for unmatched overload is gobbledygook
[I believe that this is a regression. Around 2.95.x or early 3.x, gcc produced
sensible error messages in similar circumstances.]
With the following code
-
#include map
namespace NS {
struct Foo : public std::mapunsigned int, int
{
};
}
using namespace NS;
bool foo (const Foo m)
{
return m.find (0x1234) != m.end;
}
the error message produced by gcc is unreadable nonsense:
temp.cc:13: error: no match for operator!= in ((const
NS::Foo*)m)-NS::Foo::anonymous.std::map_Key, _Tp, _Compare, _Alloc::find
[with _Key = unsigned int, _Tp = int, _Compare = std::lessunsigned int,
_Alloc = std::allocatorstd::pairconst unsigned int, int ](((const unsigned
int)((const unsigned int*)(4660u != m-std::map_Key, _Tp, _Compare,
_Alloc::end [with _Key = unsigned int, _Tp = int, _Compare =
std::lessunsigned int, _Alloc = std::allocatorstd::pairconst unsigned int,
int ]
In detail:
(1)
No match for '...
'operator!=' is in quotes. When talking about a document, quote marks indicate
quotation. But 'operator!=' is not a quotation from the document in question -
the source file.
(2)
operator!=
'operator!=' is not the key for the look-up that failed. The key was a triple
- the operator, and the types of each of the two arguments. If the types were
given in the error message, there would be no need for the horrors that follow.
(3)
in
'No match for A in B' means that 'A' does not occur within 'B'. But in this
case the text after the word 'in' is not what we were looking up within; rather
it just gives more context to what is being looked up. 'from' would be a
better word than 'in'.
(4)
'
more quote marks around text that is not a quote.
(5) The text within the second set of quote marks manages to expand 24
characters to several hundred.
That adds nothing to help the user understand the error; it hinders me, and I'm
more familiar with the language than many C++ programers, and have plenty of
general experience with decoding complex formal expressions.
Imagine someone being faced with this error message on their first attempt to
write a program.
(6)
(const NS::Foo*)m
casting m to (const NS::Foo*) would indeed be worth an error message, but does
not occur in the original program. It should not be in the error message.
(7)
-
The member reference was done with the correct '.' not the incorrect '-'.
(8)
NS::Foo::
The member reference did not use a fully qualified name.
(9)
anonymous
This is incorrect whatever it is meant to represent. In particular, there are
no anonymous structs or namespaces involved in the member look-ups.
(10)
.std::map_Key, _Tp, _Compare, _Alloc::find [with _Key = unsigned int, _Tp =
int, _Compare = std::lessunsigned int, _Alloc =
std::allocatorstd::pairconst unsigned int, int ]
The find member was not given a fully qualified name. The '.' is also
incorrect; an [incorrect] member access '-' has already been given.
(11)
std::map_Key, _Tp, _Compare, _Alloc::find [with _Key = unsigned int, _Tp =
int, _Compare = std::lessunsigned int, _Alloc =
std::allocatorstd::pairconst unsigned int, int ]
While separating out the template parameters will in some case avoid an
exponentially long type name, in this case it lengthens it and only confuses
the message.
Much better would be to state the type as std::mapunsigned int, int, putting
the template parameters in the template instantiation, and dropping defaulted
template arguments.
(12)
((const unsigned int)((const unsigned int*)(4660u))
bears no relation to the integer constant expression actually used:
a. the original expression does not have a reference type.
b. the expression was given in hex, not decimal.
c. the address of the constant was not taken. (You can't do that).
d. Nothing was cast to (const unsigned int*).
e. No pointer was cast to a reference, and that is not legal C++.
m-
(13) should be '.' not '-'
--
Summary: Error message for unmatched overload is gobbledygook
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25362
[Bug c++/25363] New: Excessively long error message.
-- Summary: Excessively long error message. Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: suckfish at ihug dot co dot nz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25363
[Bug c++/22566] New: Incorrect overload resolution on mutable field.
The following program prints a hex address. I expected it to print Hello,
world
nm | c++filt|grep operator shows that the operator used is:
std::basic_ostreamchar, std::char_traitschar ::operator(void const*)
I expected operator(char const*)
This is with Fedora's gcc-4.0.1-3.i386.rpm
The program:
#include sstream
#include stdio.h
struct cerror {
~cerror() { printf (%s\n, s.str().c_str()); }
mutable std::ostringstream s;
};
int main()
{
cerror().s Hello, world\n;
return 0;
}
--
Summary: Incorrect overload resolution on mutable field.
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22566
