--- Comment #16 from pinskia at gcc dot gnu dot org 2009-11-16 06:21
---
*** Bug 42064 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 2009-11-16 06:21 ---
*** This bug has been marked as a duplicate of 11764 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
below is an example in standard N2960.
struct A { A(); };
struct B : public A { B(); };
A::A() { }
B::B() { }
A::A a;
int main()
{
return 0;
}
According to the standard [class.qual]/2, 'A::A a;' is error because A::A is
not a type name. But g++ can compile it without error or warning.
This bug is related to the example in [class.dtor]/12 of standard N2960.
according to the example, in the following program:
#include
struct B {
virtual ~B() { std::cout << "~B" << std::endl; }
};
struct D : B {
~D () { std::cout << "~D" << std::endl; }
};
typedef B B_alias;
i
--- Comment #7 from craig dot schlenter at gmail dot com 2009-11-16 04:37
---
(In reply to comment #3)
> I brought this up on the Google-internal C list. They reduced it further:
>
> $ cat main.cc
> #include
>
> int main(void)
> {
>typedef std::map MyMap2;
>MyMap2 map2_;
>
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-11-16
01:26 ---
This doesn't solve the abort in ejc1 on x86_64-apple-darwin10, but shouldn't we
have...
Index: libjava/Makefile.in
===
--- libjava/Makefile.
--- Comment #4 from dje at gcc dot gnu dot org 2009-11-15 23:04 ---
It's fixed.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-11-15
22:52 ---
Comparing the linkages of ecjx and gij on x86_64-apple-darwin10 with your
patch, one thing I did notice is that there is a slight difference in the link
flags. The ecjx linkage is passed -findirect-dispatch
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42062
The following invalid testcase triggers an ICE since GCC 4.3.4:
===
template struct A
{
template void foo();
template<> struct A
{
template void foo();
};
};
void bar()
{
A a;
a.foo<0>();
}
===
bug.cc:5:12:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42061
The following invalid testcase triggers an ICE since GCC 4.4.2:
==
int& i = { j };
==
bug.cc:1:12: error: 'j' was not declared in this scope
bug.cc:1:14: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in reference_relate
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42060
The following invalid testcase triggers an ICE since GCC 4.4.1:
==
void foo()
{
int a[1];
throw a = {};
}
==
bug.cc: In function 'void foo()':
bug.cc:4:14: error: invalid use of non-lvalue array
bug.cc:4:15: internal compiler error: tree check: expected class '
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42059
The following invalid testcase triggers an ICE since GCC 4.4.1:
==
void foo(int i)
{
int a[i];
a = {};
}
==
bug.cc: In function 'void foo(int)':
bug.cc:4:8: internal compiler error: tree check: expected integer_cst, have
nop_expr in process_init_constructor_arr
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42058
The following invalid testcase triggers an ICE on trunk (and GCC 4.1.x):
struct A;
struct B
{
A a;
};
B b[1] = (B[]) { 0 };
bug.cc:5:5: error: field 'a' has incomplete type
bug.cc:8:20: error: initializer for 'B' must b
--- Comment #7 from simartin at gcc dot gnu dot org 2009-11-15 21:38
---
Patch submitted here:
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00747.html
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42057
The following invalid testcase triggers an ICE on trunk:
struct A;
struct B
{
virtual B* foo(A);
};
struct C : virtual B
{
virtual C* foo(A) { return 0; }
};
C c;
bug.cc: In member function 'virtual C* C::foo(A)':
bu
The following invalid testcase triggers an ICE since GCC 4.4.0
(when the meaning of the auto keyword changed).
==
template struct A
{
int a[auto(1)];
};
==
bug.cc:3:16: internal compiler error: in fold_convert_loc, at fold-const.c:2671
Please subm
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42055
The following invalid testcase triggers an ICE on trunk:
===
template void foo(T, T);
template void foo(T, int);
template void foo(int, int);
===
bug.cc:5:15: error: ambiguous template specialization 'foo<>' for 'vo
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42054
The following invalid testcase triggers an ICE since GCC 4.2.0:
=
template struct A;
template struct A;
=
bug.cc:1:14: error: two or more data types in declaration of 'parameter'
bug.cc:2:14: error: two or more data types in declarat
>From the Fortran 2003 standard:
C817 (R823) For a given select-type-construct, the same type and kind type
parameter values shall not be specified in more than one TYPE IS
type-guard-stmt and shall not be specified in more than one CLASS IS
type-guard-stmt.
This check is missing for CLASS IS block
--- Comment #9 from paolo dot carlini at oracle dot com 2009-11-15 19:56
---
r154190 is the subversion version I built and tested, this project doesn't use
cvs anymore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40938
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu
2009-11-15 19:26 ---
Subject: Re: [4.5/4.4 Regression] data statement with nested type
constructors
On Sun, Nov 15, 2009 at 07:04:42PM -, jvdelisle at gcc dot gnu dot org
wrote:
>
>
> --- Comment #12 from
submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
gcc-4 -v
Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/lto-wrapper
Target: x86_64-apple-darwin10.2.0
Configured with: ../gcc-4.5-20091115/con
--- Comment #8 from dcb314 at hotmail dot com 2009-11-15 19:19 ---
(In reply to comment #7)
> Works for me now (r154190).
I have no idea what r154190 means, but I can confirm
that the snapshot of 2009112 seems to work ok,
even at optimisation level -O3 -march=native.
This looks fixed
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-11-15 19:04
---
When we simplify start[i], we turn that expression into a constant. Then I
believe the traverse_data_var can no longer increment the index since we made
it a constant. I don't think the start[i] expression shou
--- Comment #149 from pinskia at gcc dot gnu dot org 2009-11-15 19:02
---
*** Bug 42052 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 2009-11-15 19:02 ---
You are violating C/C++ aliasing rules. You access a void* via a int*.
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
gcc 4.4.1 generates incorrect code for the following type of expression:
void *P;
for (something) {
...
*((*(int **)&P)++) = Value;
...
};
P remains unchanged throughout the loop.
This code worked correctly in earlier versions of gcc, last checked on gcc
4.3.2.
the following flags
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-15 18:49 ---
Backtrace:
#0 gfc_conv_variable (se=0x7fffd860, expr=0x1788a00) at
/home/jweil/gcc45/trunk/gcc/fortran/trans-expr.c:550
#1 0x0059ab0a in gfc_conv_expr (se=0x7fffd860, expr=0x1788a00) at
/home/jweil/g
--- Comment #11 from kargl at gcc dot gnu dot org 2009-11-15 18:38 ---
Jerry, I added
@@ -56,11 +55,11 @@ get_array_index (gfc_array_ref *ar, mpz_
for (i = 0; i < ar->dimen; i++)
{
e = gfc_copy_expr (ar->start[i]);
- re = gfc_simplify_expr (e, 1);
+ gfc_simplif
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-15 18:30 ---
(In reply to comment #0)
> field_grid.f03:27:0: internal compiler error: in gfc_conv_variable, at
> fortran/trans-expr.c:550
Here is a reduced test case which gives the same ICE:
type grid
end type
contains
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-11-15 17:58 ---
Patches submitted to do all of the above cleanups, etc.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from paolo dot carlini at oracle dot com 2009-11-15 17:44
---
Works for me now (r154190). If you can still see something wrong, please
reopen.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-15 17:39
---
Lambdas are in mainline now, and I don't see any ICE, just a normal error.
Please double check, thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Adde
--- Comment #1 from danglin at gcc dot gnu dot org 2009-11-15 17:28 ---
also fails on hppa64-hp-hpux11.11.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41915
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-15 17:23
---
For the record, even before San Francisco, rvalue-rvalue swaps were prohibited.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-15 16:58
---
Let's CC Jason here too, being an issue with lambda...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-15 16:45
---
It still crashes with checking enabled though, and that isn't good. Let's add
Jason in CC, maybe he can have a look...
--
paolo dot carlini at oracle dot com changed:
What|Removed
Gfortran 4.5.0 20091106 (with Janus's patch for PR42048) produces the following
on the code below:
gfortran -c field_grid.f03
field_grid.f03: In function output:
field_grid.f03:27:0: internal compiler error: in gfc_conv_variable, at
fortran/trans-expr.c:550
Please submit a full bug report,
with
--- Comment #11 from janus at gcc dot gnu dot org 2009-11-15 16:00 ---
(In reply to comment #4)
> Wouldn't it be more obvious to check for attr.result or something like that?
Tobias, I don't quite see how that would work. Simply checking for attr.result
is surely not enough. After all t
--- Comment #10 from janus at gcc dot gnu dot org 2009-11-15 15:49 ---
(In reply to comment #9)
> error #6837: The leftmost part-ref in a data-ref can not be a function
> reference.
This is C612 in the Fortran 2003 standard:
R612 data-ref is part-ref [ % part-ref ] ...
R613 part-ref
--- Comment #9 from janus at gcc dot gnu dot org 2009-11-15 15:40 ---
(In reply to comment #8)
> Let's hope these beasts are all invalid ;)
At least this one is rejected by ifort and NAG. ifort says:
error #6837: The leftmost part-ref in a data-ref can not be a function
reference.
--- Comment #8 from janus at gcc dot gnu dot org 2009-11-15 15:32 ---
Uh, it seems we're opening a can of worms here. The following also fails:
type(grid) :: g
g = new_field()%mesh
Let's hope these beasts are all invalid ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4204
--- Comment #7 from janus at gcc dot gnu dot org 2009-11-15 15:24 ---
(In reply to comment #6)
> OTOH, is this even valid?
At first glance, I don't see why it shouldn't be. Btw, this also fails with
type-bound functions:
integer :: i
i = new_field()%mesh%new_int()
--
http://
--- Comment #2 from zsojka at seznam dot cz 2009-11-15 15:17 ---
Since:
r153816 | jason | 2009-11-02 17:14:26 +0100 (Mon, 02 Nov 2009) | 5 lines
Restrict DR 757 change to C++0x mode.
* decl2.c (mark_used): Check cxx_dialect.
* decl.c (grokfndecl): Do check type l
--- Comment #6 from janus at gcc dot gnu dot org 2009-11-15 15:12 ---
(In reply to comment #4)
> Besides, it probably fails for strange constructions such as
Another thing that does not work is:
type(field) function new_field()
! ...
end function
subroutine test
call new_field
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-15 15:05 ---
(In reply to comment #4)
> Besides, it probably fails for strange constructions such as
Ah, indeed. Sorry for comitting too early :(
Seems it was not quite obvious enough ...
--
janus at gcc dot gnu dot org chang
--- Comment #4 from burnus at gcc dot gnu dot org 2009-11-15 14:59 ---
> - if (sym->attr.flavor != FL_PROCEDURE
> + if ((sym->attr.flavor != FL_PROCEDURE || sym == gfc_current_ns->proc_name)
Wouldn't it be more obvious to check for attr.result or something like that?
>From the testcas
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-15 14:55 ---
Fixed with r154190. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-15 14:54 ---
Subject: Bug 42048
Author: janus
Date: Sun Nov 15 14:54:05 2009
New Revision: 154190
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154190
Log:
2009-11-15 Janus Weil
PR fortran/42048
* matc
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-15 14:32 ---
Confirmed.
#1 0x00570173 in expand_expr_real_1 (exp=0x7616e140, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /home/rguenther/src/gcc-4_4-branch/gcc/expr.c:9314
9314
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-15 14:27 ---
This is the usual missing code-hoisting optimization. Dup is PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42046
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-15 14:24 ---
(In reply to comment #2)
> internal compiler error: in gfc_walk_variable_expr, at
> fortran/trans-array.c:6308
The ICE goes away when adding this:
Index: gcc/fortran/resolve.c
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-15 12:50 ---
With the following patch, the errors go away:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 154188)
+++ gcc/fortran/resolve.
--- Comment #1 from jv244 at cam dot ac dot uk 2009-11-15 12:40 ---
works on 4.4 branch, fails on 4.5 branch
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-15 12:39 ---
Cf. also PR39997, the discussion in
http://j3-fortran.org/pipermail/j3/2009-May/002736.html and follow-ups, and
http://www.j3-fortran.org/doc/year/09/09-236r1.txt (which seems to confirm that
the test case is valid).
nable-plugins
Thread model: posix
gcc version 4.5.0 20091115 (experimental) [trunk revision 154188] (GCC)
COLLECT_GCC_OPTIONS='-c' '-fgraphite-identity' '-O1' '-v' '-mtune=generic'
/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.
/* Following code give ICE with -O2 or -O3
ice.c: In function main:
ice.c:46: internal compiler error: in expand_expr_real_1, at expr.c:9314
works OK with -O1 and no warnings given
*/
extern char *strcpy(char *s1, const char *s2);
/* #include */
typedef struct _ccy_nameCCY_NAME;
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-15 10:43 ---
The following patch makes the test case compile:
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 154106)
+++ gcc/fortran/match.c (workin
Reported by Damian Rouson:
module grid_module
implicit none
type grid
contains
procedure :: new_grid
end type
contains
subroutine new_grid(this)
class(grid) :: this
end subroutine
end module
module field_module
use grid_module
implicit none
type field
type(grid) :: mesh
end t
--- Comment #3 from jv244 at cam dot ac dot uk 2009-11-15 09:20 ---
(In reply to comment #2)
> Mine (got a patch)
has the patch been posted ? Couldn't find it yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41926
69 matches
Mail list logo
