The following code snippet triggers an ICE since GCC 4.0.0:
==
extern Java struct A {};
A a = A();
==
bug.cc:3: internal compiler error: in store_init_value, at cp/typeck2.c:598
Please submit a full bug report, [etc.]
With GCC
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30293
The following code snippet triggers an ICE since GCC 4.0.0:
==
extern Java struct A {};
const A foo()
{
A a;
return a;
}
==
bug.cc: In function 'const A foo()':
bug.cc:6: internal compiler error: in ocp_convert, at cp/cvt.c:658
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30294
The following code snippet triggers an ICE since GCC 4.0.0:
==
extern Java struct A
{
int i;
};
A foo(A);
void bar()
{
foo(A()).i;
}
==
bug.cc: In function 'void bar()':
bug.cc:10: error: no matching function for call to
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30295
I tried to install gcc-3.4.6 as always in a MacBook Pro with Intel Core 2 Duo
CPU. I configured with the command
/common/src/gcc-3.4.6/configure --prefix=/common/compilers/mac/gcc-3.4.6
--program-suffix=-3.4.6 --enable-languages=c,c++,f77
and the second time I added --disable-multilib.
when I
The following (IMHO valid) code snippet triggers an ICE since GCC 4.1.0:
==
struct A
{
int i;
};
extern C struct B : A
{
A::i;
};
==
bug.cc:7: internal compiler error: tree check: expected tree that contains
'decl with
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30297
==
union A {};
struct B : A {};
struct B : A {};
==
bug.cc:3: error: base type 'A' fails to be a struct or class type
bug.cc:4: internal compiler error: in xref_basetypes, at cp/decl.c:9865
Please submit a full bug report, [etc.]
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30298
The following invalid code snippet triggers an ICE on mainline and 4.2 branch:
==
struct A
{
int i;
};
templatevoid struct B : A
{
B() { this-i; }
};
==
bug.cc:6: error: 'void' is not a valid type for a template constant
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30299
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-12-26 12:15 ---
(In reply to comment #1)
Index: gcc/fortran/scanner.c
===
--- gcc/fortran/scanner.c (Revision 120144)
+++ gcc/fortran/scanner.c
The compiler issues errors about anonymous unions for the following code
snippet although there's only an anonymous class:
struct A
{
class
{
static int i;
int j;
};
};
bug.cc:5: error: 'int A::anonymous class::i' invalid;
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-26 13:08 ---
No, compiling .java should work with the gcc driver and if it does not, then
there is a bug there. And we should not error out.
Also the ICE is a bug which needs to fixed seperately from the driver issue
anyways.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-26 13:11 ---
3.4.6 was released a long time before Mac OS X x86 was released.
Also only GCC 4.2.0 and above really supports x86 Mac OS X.
3.4.x is no longer supported and this is not really a regression so closing as
won't
The following invalid code snippet is accepted since at least GCC 2.95.3:
==
templateint struct A
{
struct { static int i; };
};
==
It is correctly rejected when the template is instantiated.
--
Summary: Invalid
The following invalid code snippet triggers an ICE since GCC 3.0:
==
struct A
{
struct { static int i; };
void foo() { i; }
};
==
bug.cc:3: error: 'int A::anonymous struct::i' invalid; an anonymous union can
only have non-static
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30302
The following invalid code snippet triggers an ICE on mainline and 4.2 branch:
==
class A
{
int i;
};
A::A() { A(); }
==
bug.cc:6: error: definition of implicitly-declared 'A::A()'
bug.cc:6: error: declaration of 'A::A()' throws
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30303
The following invalid code snippet triggers an ICE on mainline:
==
class A
{
int i;
};
void foo()
{
A();
}
A::A() {}
==
bug.cc:11: error: definition of implicitly-declared 'A::A()'
bug.cc:11: error: declaration of 'A::A()'
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30304
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-12-26 13:52
---
Maybe related to PR 28266.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30295
--- Comment #10 from dir at lanl dot gov 2006-12-26 13:57 ---
This is no problem with g95. You can move files to other Macintosh computers
without g95 istalled and use them. This really is quite important, the
usefulness of gfortran is greatly limited without this ablity. Programs built
--- Comment #1 from patchapp at dberlin dot org 2006-12-26 14:38 ---
Subject: Bug number PR20896
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01686.html
--
$ cat x.cpp
char const c1[] = { '\0' };
static char const* cp1 = c1;
int main() { return 0; }
$ g++ -Wall -gdwarf-2 -g2 x.cpp -o x
x.cpp:2: warning: #8216;cp1#8217; defined but not used
/tmp/ccyTiLjt.o:(.debug_info+0xe2): undefined reference to `c1'
collect2: ld returned 1 exit status
gcc
If %% is used in printf formats without any actual format requiring
substitution being used, gcc still does not perform the optimization.
#include stdio.h
int
main (void)
{
printf (hello !\n);
return 0;
}
This code is compiled to call printf even though it should lead to code calling
The following tests fail for me on Solaris 10 x86:
FAIL: gcc.target/i386/ssse3-pabsb.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-pabsd.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-pabsw.c (test for excess errors)
FAIL: gcc.target/i386/ssse3-palignr.c (test for excess errors)
When attempting to run gfortran/open_errors.f90 on cygwin based system, the
close(77, status=delete fails to delete the file.
--
Summary: [4.1,4.2,4.3] open_errors.f90 fails on cygwin
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-26 17:35 ---
This just means the as you have don't support S-SSE3 support.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-26 17:37 ---
*** This bug has been marked as a duplicate of 27657 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-12-26 17:37
---
*** Bug 30305 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-26 17:40 ---
Confirmed. This should be a simple fix to builtins.c which checks if % is used
% is after it and then we replace it in the string.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-12-26 18:07
---
(In reply to comment #10)
This is no problem with g95.
That is because g95's library is not fully integrated at all in GCC's build
infrastructure at all.
You can use just disable's gfortran shared library
--- Comment #36 from ghazi at gcc dot gnu dot org 2006-12-26 19:03 ---
Subject: Bug 29335
Author: ghazi
Date: Tue Dec 26 19:03:17 2006
New Revision: 120211
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120211
Log:
PR middle-end/29335
* builtins.c (do_mpfr_arg1,
--- Comment #37 from ghazi at gcc dot gnu dot org 2006-12-26 19:13 ---
Done.
Remaining functions (Bessel lgamma) await implementation in MPFR and marked
for PR30250 PR30251.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tromey at gcc dot gnu dot org 2006-12-26 20:55 ---
FWIW making the gcc driver work properly here is not easy.
gcj reads a spec file with internal options in it.
These are required for the proper operation of jc1.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-26 22:10 ---
The fix for PR 18073 was not fully correct, it allowed a conversion from a
vector type to any type, even if it was not an integer.
I have a fix which gets us back to 3.4.0's behavior.
--
pinskia at gcc dot gnu
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-26 22:19 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-26 22:20 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-26 22:21 ---
Confirmed, here is the backtrace:
#0 0x00220284 in finish_id_expression (id_expression=0x434e08c0,
decl=0x434dcae0, scope=0x0, idk=0xbfffed68, integral_constant_expression_p=0
'\0',
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-26 22:22 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-26 22:27 ---
Confirmed, I wonder why we don't mark the function as having an error_mark_node
for the DECL_SAVED_TREE.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-26 22:30 ---
Confirmed, only related in that the error mark node in the TARGET_EXPR causes
the same issue as PR 28266..
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-26 22:32 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-26 22:33 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-26 22:33 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-26 22:50 ---
This is obviously caused by the tuple changes.
I am trying to find a simple fix for this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30253
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-12-26 22:56 ---
Here is the patch which I am going to test in the new year:
Index: gimplify.c
===
--- gimplify.c (revision 120211)
+++ gimplify.c (working copy)
@@
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Unexpected compilation |[4.1 Regression] Unexpected
|results: -O1 vs. -O1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-27 00:06 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-27 00:17 ---
Confirmed, but this does not happen on powerpc-darwin for some reason.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-27 00:38 ---
Here is the patch which I am going to test in the new year:
Index: decl.c
===
--- decl.c (revision 120211)
+++ decl.c (working copy)
@@
--- Comment #2 from hubicka at ucw dot cz 2006-12-27 01:01 ---
Subject: Re: gcc.dg/tree-prof/stringop-1.c fails
This problem is conflict in between my memcpy and value profiling
optimization. I will have to figure out why it does not happen on
powerpc-darwin and otherwise the
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-27 01:06 ---
Hmm, I think this means you are linking against the wrong version of libgcov.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30258
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|regression |target
GCC target triplet||arm
Target
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-27 02:19 ---
Another simple regression for the new year to test:
Index: semantics.c
===
--- semantics.c (revision 120211)
+++ semantics.c (working copy)
@@ -1621,7
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-27 02:32 ---
(In reply to comment #2)
The dump suggest that a temporary array has not been properly sized.
We get:
char[0:][1:12] * D.972;
{
int4 S.3;
S.3 = 0;
while (1)
{
if (S.3 0)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-27 02:34 ---
Just to show this works in general, here is the result for powerpc-darwin:
_bar:
li r4,0
b _foo
Also I don't think push will work as it can cause the stack to become
unaligned.
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-27 02:35 ---
Fixed for 4.1.2 at least.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30084
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-27 02:47 ---
Confirmed, and you are correct in that the error message was just copied.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-27 02:49 ---
Unions have the same issue:
templateint struct A
{
union { static int i; };
};
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-27 02:52 ---
(In reply to comment #3)
FWIW making the gcc driver work properly here is not easy.
Why, every other language works the correct way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30292
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-27 03:16 ---
This patch works for me but I don't know if it is correct, it mirrors other
places which uses currently_open_derived_class but we now get a bogus error
message with this patch:
Index: semantics.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-27 03:35 ---
Mine for the new year:
Index: decl.c
===
--- decl.c (revision 120211)
+++ decl.c (working copy)
@@ -6216,7 +6219,10 @@
XXX
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-27 03:36 ---
My patch for PR 30303 also fixes this, they are the same issue.
*** This bug has been marked as a duplicate of 30303 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-27 03:36 ---
*** Bug 30304 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30303
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-27 04:01 ---
And another one:
Index: tree.c
===
--- tree.c (revision 120211)
+++ tree.c (working copy)
@@ -2199,6 +2199,10 @@
then handles a few
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-12-27 04:35
---
For these VIEW_CONVERT_EXPR to work correctly, we need to extend
DECL_GIMPLE_REG_P to work for all types and not just VECTOR_TYPE and
COMPLEX_TYPE. I am going to work on that first and then come back to using
72 matches
Mail list logo
