[Bug target/41021] [ARM] Suboptimal code generated to store a struct

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2009-08-10 07:16 ---
SRA expert -> CC


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-10 07:16:06
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41021

[Bug c++/40866] [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504

[dodji at gcc dot gnu dot org]

--- Comment #5 from dodji at gcc dot gnu dot org  2009-08-10 07:16 ---
Subject: Bug 40866

Author: dodji
Date: Mon Aug 10 07:16:08 2009
New Revision: 150615

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150615
Log:
2009-08-10  Dodji Seketeli  

gcc/ChangeLog:
PR c++/40866
* tree-inline.c (copy_statement_list): The resulting copy shouldn't
loose the original type of the statement list.

gcc/testsuite/ChangeLog:
PR c++/40866
* g++.dg/expr/stmt-expr-1.C: New test.



Added:
trunk/gcc/testsuite/g++.dg/expr/stmt-expr-1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40866

[Bug c++/40866] [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504

[dodji at gcc dot gnu dot org]

--- Comment #6 from dodji at gcc dot gnu dot org  2009-08-10 07:17 ---
Fixed in 4.5


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40866

[Bug bootstrap/40788] [4.5 regression] ICE on sparc: tree check: expected class 'expression', have 'declaration' (var_decl) in gimplify_va_arg_expr, at builtins.c:5107

[laurent at guerby dot net]

--- Comment #5 from laurent at guerby dot net  2009-08-10 08:01 ---
The search is not finished but it's likely the following patch:

2009-07-17  Aldy Hernandez  
   Manuel López-Ibáñez  

   PR 40435
  ... builtins.c ... Add location argument to ...



The ICE happens here:

builtins.c:
  *expr_p = targetm.gimplify_va_arg_expr (valist, type, pre_p, post_p);
  SET_EXPR_LOCATION (*expr_p, loc);

While compiling the following code:

genattrtab.c:
  HOST_WIDE_INT arg0 = va_arg (p, HOST_WIDE_INT);

Note the HOST_WIDE_INT here. And sparc_gimplify_va_arg_expr does something
special in one case, tagged FIXME:

sparc.c:
  /* If the address isn't aligned properly for the type, we need a temporary.
 FIXME: This is inefficient, usually we can do this in registers.  */
  else if (align == 0 && TYPE_ALIGN (type) > BITS_PER_WORD)
{
  tree tmp = create_tmp_var (type, "va_arg_tmp");
  tree dest_addr = build_fold_addr_expr (tmp);
  tree copy = build_call_expr (implicit_built_in_decls[BUILT_IN_MEMCPY],
   3, dest_addr, addr, size_int (rsize));
  TREE_ADDRESSABLE (tmp) = 1;
  gimplify_and_add (copy, pre_p);
  addr = dest_addr;
}

This is guessing because I don't understand all that stuff so help welcomed :).


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org,
   ||aldyh at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40788

[Bug target/41017] regparm=3 passes structures inconsistently

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2009-08-10 08:05 ---
(In reply to comment #4)

> If you want to change it to be consistent with the documentation (not with
> existing implementation) and pass structures always on stack, I wouldn't 
> object
> against it. Just don't change it later.
> 

IMO, regparm ABI should be documented in i386 psABI first [1], so we will have
something to implement against. As it stands now, regparm is mainly internal to
gcc, so non-exported functions can be called more efficiently. So, everything
is OK as long as the caller and the callee agree on the location of arguments.

OTOH, if regparm is documented, we can implement alternative function entry
points, so exported functions will also benefit from regparm ABI. See how ICC
handles this.

[1] http://groups-beta.google.com/group/ia32-abi


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41017

[Bug target/41017] regparm=3 passes structures inconsistently

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2009-08-10 08:06 ---
Adding H.J. to CC.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41017

[Bug ada/17566] Gnatxref formatting

[charlet at gcc dot gnu dot org]

--- Comment #2 from charlet at gcc dot gnu dot org  2009-08-10 08:25 ---
Subject: Bug 17566

Author: charlet
Date: Mon Aug 10 08:25:05 2009
New Revision: 150617

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150617
Log:
2009-08-10  Vincent Celier  

PR ada/17566
* xref_lib.adb (Print_Xref): Make sure that there is at least one space
between a declaration name and its type.


Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/xref_lib.adb


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17566

[Bug ada/17566] Gnatxref formatting

[charlet at gcc dot gnu dot org]

--- Comment #3 from charlet at gcc dot gnu dot org  2009-08-10 08:27 ---
Should now be fixed


-- 

charlet at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17566

[Bug target/41021] [ARM] Suboptimal code generated to store a struct

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-08-10 09:07 ---
There is only one struct copy, so it isn't SRAs business to optimize anything
here.  Instead the burden is put on expand and the backend to figure out the
most efficient way to do this block copy.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41021

[Bug bootstrap/40788] [4.5 regression] ICE on sparc: tree check: expected class 'expression', have 'declaration' (var_decl) in gimplify_va_arg_expr, at builtins.c:5107

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-08-10 09:10 ---
  *expr_p = targetm.gimplify_va_arg_expr (valist, type, pre_p, post_p);
  SET_EXPR_LOCATION (*expr_p, loc);

is simply bogus.  You can't expect *expr_p being still an expression tree
when you throw the gimplifier on it.  I suggest to simply remove that
location setting here - the target gimplifiers should fix up locations if
necessary.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40788

[Bug fortran/40940] [F03] CLASS statement

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2009-08-10 09:19 ---
Subject: Bug 40940

Author: janus
Date: Mon Aug 10 09:19:24 2009
New Revision: 150620

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150620
Log:
2009-08-10  Janus Weil  

PR fortran/40940
* decl.c (gfc_match_type_spec): Match CLASS statement and warn about
missing polymorphism.
* gfortran.h (gfc_typespec): Add field 'is_class'.
* misc.c (gfc_clear_ts): Initialize 'is_class' to zero.
* resolve.c (type_is_extensible): New function to check if a derived
type is extensible.
(resolve_fl_variable_derived): Add error checks for CLASS variables.
(resolve_typebound_procedure): Disallow non-polymorphic passed-object
dummy arguments, turning warning into error.
(resolve_fl_derived): Use 'type_is_extensible'. Disallow
non-polymorphic
passed-object dummy arguments for procedure pointer components,
turning warning into error. Add error check for CLASS components.

2009-08-10  Janus Weil  

PR fortran/40940
* gfortran.dg/class_1.f03: New.
* gfortran.dg/class_2.f03: New.
* gfortran.dg/proc_ptr_comp_pass_1.f90: Use CLASS instead of TYPE.
* gfortran.dg/proc_ptr_comp_pass_2.f90: Ditto.
* gfortran.dg/proc_ptr_comp_pass_3.f90: Ditto.
* gfortran.dg/typebound_call_10.f03: Ditto.
* gfortran.dg/typebound_call_2.f03: Ditto.
* gfortran.dg/typebound_call_3.f03: Ditto.
* gfortran.dg/typebound_call_4.f03: Ditto.
* gfortran.dg/typebound_generic_3.f03: Ditto.
* gfortran.dg/typebound_generic_4.f03: Ditto.
* gfortran.dg/typebound_proc_1.f08: Ditto.
* gfortran.dg/typebound_proc_5.f03: Ditto.
* gfortran.dg/typebound_proc_6.f03: Ditto.


Added:
trunk/gcc/testsuite/gfortran.dg/class_1.f03
trunk/gcc/testsuite/gfortran.dg/class_2.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/misc.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_pass_1.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_pass_2.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_pass_3.f90
trunk/gcc/testsuite/gfortran.dg/typebound_call_10.f03
trunk/gcc/testsuite/gfortran.dg/typebound_call_2.f03
trunk/gcc/testsuite/gfortran.dg/typebound_call_3.f03
trunk/gcc/testsuite/gfortran.dg/typebound_call_4.f03
trunk/gcc/testsuite/gfortran.dg/typebound_generic_3.f03
trunk/gcc/testsuite/gfortran.dg/typebound_generic_4.f03
trunk/gcc/testsuite/gfortran.dg/typebound_proc_1.f08
trunk/gcc/testsuite/gfortran.dg/typebound_proc_5.f03
trunk/gcc/testsuite/gfortran.dg/typebound_proc_6.f03


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40940

[Bug middle-end/41006] [4.5 Regression] verify_stmts failed: error: non-trivial conversion at assignment

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-08-10 09:23 ---
Subject: Bug 41006

Author: rguenth
Date: Mon Aug 10 09:22:47 2009
New Revision: 150621

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150621
Log:
2009-08-10  Richard Guenther  

PR middle-end/41006
* tree-ssa.c (useless_type_conversion_p_1): Fold into ...
(useless_type_conversion_p): ... here.  Require pointer targets
to be compatible.

* gcc.c-torture/compile/pr41006-1.c: New testcase.
* gcc.c-torture/compile/pr41006-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr41006-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr41006-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41006

[Bug middle-end/41006] [4.5 Regression] verify_stmts failed: error: non-trivial conversion at assignment

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-08-10 09:23 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41006

[Bug c++/39987] [4.3 Regression] Rejects default argument that is a template via access failure

[dodji at gcc dot gnu dot org]

--- Comment #9 from dodji at gcc dot gnu dot org  2009-08-10 10:09 ---
Okay,I have adjusted the regression markers.
I won't apply the patch to 4.3 for now though.

To apply this patch to 4.3, one would need to backport the patch
http://gcc.gnu.org/viewcvs?view=rev&revision=142628 to 4.3 first.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|dodji at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW
Summary|[4.3/4.4/4.5 Regression]|[4.3 Regression] Rejects
   |Rejects default argument|default argument that is a
   |that is a template via  |template via access failure
   |access failure  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39987

[Bug fortran/41022] New: [4.5.0] problem with procedure pointers

[reuter at physik dot uni-freiburg dot de]

It seems that not a pointer is transferred but a value in the following case.
Here is the tracking info:

gfortran -g fptr_transfer.f90 -o fptr_transfer && ./fptr_transfer
Segmentation fault (core dumped)gdb fptr_transfer core
[...]
Program terminated with signal 11, Segmentation fault.
#0  0x00400629 in assign_proc_ptr (ptr=0x0, obj1=( 0x40060c  
)) at fptr_transfer.f90:32
32  ptr => obj1%proc
(gdb) where
#0  0x00400629 in assign_proc_ptr (ptr=0x0, obj1=( 0x40060c  
)) at fptr_transfer.f90:32
#1  0x00400687 in transfer_proc_ptr (obj2=( 0 ), obj1=( 0x40060c 
 )) at fptr_transfer.f90:26
#2  0x0040064c in foo () at fptr_transfer.f90:19
#3  0x004006c2 in main (argc=1, argv=0x712d2fe4 
'./fptr_transfer\000') at fptr_transfer.f90:19
#4  0x7f1d9cdf0586 in __libc_start_main () from /lib64/libc.so.6
#5  0x00400549 in _start () at ../sysdeps/x86_64/elf/start.S:113
Current language:  auto; currently fortran
(gdb)

Here is the corresponding code:
subroutine proc ()
end subroutine proc

program foo

   interface
  subroutine proc ()
  end subroutine proc
   end interface

   type :: container_t
  procedure(proc), nopass, pointer :: proc => null ()
   end type container_t

   type(container_t), target :: obj1
   type(container_t) :: obj2

   obj1%proc => proc
   call transfer_proc_ptr (obj2, obj1)

contains

   subroutine transfer_proc_ptr (obj2, obj1)
 type(container_t), intent(out) :: obj2
 type(container_t), intent(in), target :: obj1
 call assign_proc_ptr (obj2%proc, obj1)
   end subroutine transfer_proc_ptr

   subroutine assign_proc_ptr (ptr, obj1)
 procedure(proc), pointer :: ptr
 type(container_t), intent(in), target :: obj1
 ptr => obj1%proc
   end subroutine assign_proc_ptr

end program foo


-- 
   Summary: [4.5.0] problem with procedure pointers
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reuter at physik dot uni-freiburg dot de
 GCC build triplet: Ref. svn r150253
  GCC host triplet: Linux 32bit, 64bit, MAC OS X
GCC target triplet: fortran 4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41022

[Bug fortran/41022] [4.5.0] problem with procedure pointers

[reuter at physik dot uni-freiburg dot de]

--- Comment #1 from reuter at physik dot uni-freiburg dot de  2009-08-10 
10:12 ---
Created an attachment (id=18335)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18335&action=view)
Example file which shows the PP problem


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41022

[Bug c++/41020] Can't declare an extern "C" friend.

[jwakely dot gcc at gmail dot com]

--- Comment #2 from jwakely dot gcc at gmail dot com  2009-08-10 10:40 
---
Apart from the semi-colon after the extern "C" block the code is valid and this
is a recent regression on trunk.


-- 

jwakely dot gcc at gmail dot com changed:

   What|Removed |Added

 CC||jwakely dot gcc at gmail dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020

[Bug fortran/37425] Fortran 2003: GENERIC bindings as operators

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2009-08-10 10:52 ---
Subject: Bug 37425

Author: domob
Date: Mon Aug 10 10:51:46 2009
New Revision: 150622

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150622
Log:
2009-08-10  Daniel Kraft  

PR fortran/37425
* gfortran.dg/typebound_operator_1.f03: New test.
* gfortran.dg/typebound_operator_2.f03: New test.

2009-08-10  Daniel Kraft  

PR fortran/37425
* gfortran.h (struct gfc_namespace): New fields tb_uop_root and tb_op.
(gfc_find_typebound_user_op): New routine.
(gfc_find_typebound_intrinsic_op): Ditto.
(gfc_check_operator_interface): Now public routine.
* decl.c (gfc_match_generic): Match OPERATOR(X) or ASSIGNMENT(=).
* interface.c (check_operator_interface): Made public, renamed to
`gfc_check_operator_interface' accordingly and hand in the interface
as gfc_symbol rather than gfc_interface so it is useful for type-bound
operators, too.  Return boolean result.
(gfc_check_interfaces): Adapt call to `check_operator_interface'.
* symbol.c (gfc_get_namespace): Initialize new field `tb_op'.
(gfc_free_namespace): Free `tb_uop_root'-based tree.
(find_typebound_proc_uop): New helper function.
(gfc_find_typebound_proc): Use it.
(gfc_find_typebound_user_op): New method.
(gfc_find_typebound_intrinsic_op): Ditto.
* resolve.c (resolve_tb_generic_targets): New helper function.
(resolve_typebound_generic): Use it.
(resolve_typebound_intrinsic_op), (resolve_typebound_user_op): New.
(resolve_typebound_procedures): Resolve operators, too.
(check_uop_procedure): New, code from gfc_resolve_uops.
(gfc_resolve_uops): Moved main code to new `check_uop_procedure'.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_operator_1.f03
trunk/gcc/testsuite/gfortran.dg/typebound_operator_2.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37425

[Bug fortran/37427] Passed-object dummy argument should be polymorphic

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2009-08-10 10:57 ---
After Janus' recent check-in of CLASS parsing, this behaviour is fixed (though
CLASS is not really polymorphic).

I'm not sure if we should close this or keep open until CLASS is fully
implemented.  Janus, feel free to close it if you think that's ok.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|domob at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37427

[Bug fortran/37425] Fortran 2003: GENERIC bindings as operators

[domob at gcc dot gnu dot org]

--- Comment #2 from domob at gcc dot gnu dot org  2009-08-10 11:08 ---
After the check-in now, type-bound operators are parsed/checked correctly, but
can not be called for now.  I'll work on that as a follow-up patch.

This means that the test-case given in the report works, but of course I'll
keep the PR open until type-bound operators are fully supported.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37425

[Bug fortran/41023] New: Inconsistent error locations for wrong interfaces with overloaded operators

[domob at gcc dot gnu dot org]

When defining an OPERATOR(...) for intrinsic operators or ASSIGNMENT(=), the
interface of the provided procedure must match certain characteristics (like
one or two dummy arguments, being a FUNCTION/SUBROUTINE, respectively, and so
on).

For a wrong interface, gfortran correctly prints an error message.  The source
location this is associated to is however quite inconsistent and misleading. 
For instance with the example:

MODULE m
  IMPLICIT NONE

  TYPE t
INTEGER :: num
  END TYPE t

  INTERFACE OPERATOR(+)
MODULE PROCEDURE myplus
  END INTERFACE OPERATOR(+)

CONTAINS

  INTEGER FUNCTION myplus (a, b, c)
TYPE(t), INTENT(IN) :: a, b, c
myplus = a%num + b%num + 42
  END FUNCTION myplus

END MODULE m

I get this error:

[/tmp]# gfortran-dev test.f03 
test.f03:14.25:

  INTEGER FUNCTION myplus (a, b, c)
 1
Error: Operator interface at (1) has the wrong number of arguments

It is of course right, but I would expect at least a reference to where myplus
is actually defined as OPERATOR(+).  On the other hand, for

MODULE m
  IMPLICIT NONE

  TYPE t
INTEGER :: num
  END TYPE t

  INTERFACE OPERATOR(+)
MODULE PROCEDURE myplus
  END INTERFACE OPERATOR(+)

CONTAINS

  SUBROUTINE myplus (a, b)
TYPE(t), INTENT(IN) :: a, b
  END SUBROUTINE myplus

END MODULE m

I get:

[/tmp]# gfortran-dev test.f03 
test.f03:9.27:

MODULE PROCEDURE myplus
   1
Error: Intrinsic operator interface at (1) must be a FUNCTION

Which is quite better, in my opinion.  I suggest we change the error location
in every case to the MODULE PROCEDURE line, which is more reasonable IMHO as
well as consistent.  Alternatively, we could also reference both locations (but
should also do this in both cases to stay consistent).


-- 
   Summary: Inconsistent error locations for wrong interfaces with
overloaded operators
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: domob at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41023

[Bug fortran/41023] Inconsistent error locations for wrong interfaces with overloaded operators

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2009-08-10 11:18 ---
The same holds for type-bound operators, see for instance
gcc/testsuite/gfortran.dg/typebound_operator_2.f03 for the current
"inconsistent" locations.

But as the checking code is mainly shared, a fix will probably do both in one. 
I think though that this should be verified (e.g. by adapting the mentioned
test-case to the new error locations which will be necessary anyways).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41023

[Bug c++/41002] Redundant diagnostic when class member function's name overlaps with class field's name

[jwakely dot gcc at gmail dot com]

--- Comment #2 from jwakely dot gcc at gmail dot com  2009-08-10 11:34 
---
(In reply to comment #0)
> To my mind statement
>   test.cpp: In constructor 'testclass::testclass()':
>   test.cpp:4: error: class 'testclass' does not have any field named 'number'
> is redundant because statements
>   test.cpp:15: error: declaration of 'int testclass::number'
>   test.cpp:9: error: conflicts with previous declaration 'int
> testclass::number() const'
> that appear before already cover this case. We already have a member named
> 'number' so we certainly can't have field with the same name. Diagnostic 
> claims
> that a member 'number' already exist and field with that name cannot be 
> created
> seems to be more reasonable here, but "test.cpp:15" and "test.cpp:9" already
> said that.

The errors for lines 9 and 15 relate to the duplicate declaration of a member
with the name 'number', whereas the error on line 4 refers to the invalid
member initializer for 'number'.  Those are separate errors.

If you removed the declaration of 'int number;' (fixing the error on line 15)
then there would still be an error on line 4, so I definitely don't consider
that diagnostic to be redundant.

> Besides I found it interesting that swapping public: and private: blocks 
> around
> makes diagnostic even more unclear:

Huh?  The errors are the same except for swapping which declaration is treated
as the duplicate and which as the previous declaration, and that's because you
swappged the order.  What did you expect?  Why is it more unclear?


(In reply to comment #1)
> By the way using gcc instead of g++ doesn't changed things.

Good - it shouldn't make any difference in this case.

The difference with Comeau apears to be that name lookup finds the member
variable 'number' whereas GCC finds the member function 'number' - maybe
Comeau's name lookup finds the last declaration of that name and GCC's finds
the member function - I'm not sure.  Since the code is invalid neither compiler
is right or wrong, and personally I don't have a strong preference.  Both
compilers point out that 'number' is declared twice, which is the main problem
in the code that needs to be fixed, and both compilers print that as the first
error.

Note that if you put the declaration of 'int number;' first then Comeau has a
very similar error to GCC's when the member function is first - it complains
about the invalid member initializer and about the return statement in the
member function.  i.e. when the member function is declared later, Comeau's
name lookup finds that one, and behaves similarly to GCC.

I don't think there's much scope for improvement here.


-- 

jwakely dot gcc at gmail dot com changed:

   What|Removed |Added

 CC||jwakely dot gcc at gmail dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41002

[Bug c++/41002] Redundant diagnostic when class member function's name overlaps with class field's name

[jwakely dot gcc at gmail dot com]

--- Comment #3 from jwakely dot gcc at gmail dot com  2009-08-10 11:35 
---
(In reply to comment #2)
> Note that if you put the declaration of 'int number;' first then Comeau has a
> very similar error to GCC's when the member function is first - it complains
> about the invalid member initializer and about the return statement in the
> member function.  i.e. when the member function is declared later, Comeau's
> name lookup finds that one, and behaves similarly to GCC.

Just to be clear: this means Comeau also prints the error that you consider to
be redundant.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41002

[Bug driver/41024] New: driver passes wrong parameter to as

[rainer at emrich-ebersheim dot de]

$ gcc -v -o test.exe test.c
Es werden eingebaute Spezifikationen verwendet.
Ziel: x86_64-w64-mingw32
Konfiguriert mit: ../../../../src/gcc-4.5.0/configure
--prefix=/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw
--with-sysroot=/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw
--with-gmp=/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw
--with-mpfr=/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw
--with-mpc=/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw
--with-ppl=/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw
--with-cloog=/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw
--with-host-libstdcxx='-L/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/lib64
-lstdc++' --build=i686-pc-mingw32 --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-multilib --disable-bootstrap
--with-gnu-as
--with-as=/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/as.exe
--with-gnu-ld
--with-ld=/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/ld.exe
--enable-checking=release --enable-languages=c,c++,fortran,java,objc,obj-c++
--enable-libgomp --disable-werror 'BOOT_CFLAGS=-g -O0' CFLAGS='-g -O0'
CXXFLAGS='-g -O0' 'CFLAGS_FOR_BUILD=-g -O0' CFLAGS_FOR_TARGET=-O0
CXXFLAGS_FOR_TARGET=-O0
Thread-Modell: win32
gcc-Version 4.5.0 20090805 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-mtune=generic'

c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.0/cc1.exe
-quiet -v -iprefix
c:\mingw\gcc\gcc-4.5.0\x86_64-w64-mingw32\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.5.0/
-isysroot c:\mingw\gcc\gcc-4.5.0\x86_64-w64-mingw32\mingw\bin\../../mingw
test.c -quiet -dumpbase test.c -mtune=generic -auxbase test -version -o
D:\DOKUME~1\rainer\LOCALS~1\Temp\ccxMcHNc.s
GNU C (GCC) Version 4.5.0 20090805 (experimental) (x86_64-w64-mingw32)
kompiliert von GNU-C-Version 4.5.0 20090805 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.6
GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
nicht vorhandenes Verzeichnis
»c:\mingw\gcc\gcc-4.5.0\x86_64-w64-mingw32\mingw\bin\../../mingwC:/MinGW/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/include«
wird ignoriert
doppeltes Verzeichnis
»c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.0/include«
wird ignoriert
doppeltes Verzeichnis
»c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.0/include-fixed«
wird ignoriert
#include "..." - Suche beginnt hier:
#include <...> - Suche beginnt hier:

c:\mingw\gcc\gcc-4.5.0\x86_64-w64-mingw32\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.5.0/include

c:\mingw\gcc\gcc-4.5.0\x86_64-w64-mingw32\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.5.0/include-fixed

c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/lib/gcc/../../x86_64-w64-mingw32/include
 c:\mingw\gcc\gcc-4.5.0\x86_64-w64-mingw32\mingw\bin\../../mingw/mingw/include
Ende der Suchliste.
GNU C (GCC) Version 4.5.0 20090805 (experimental) (x86_64-w64-mingw32)
kompiliert von GNU-C-Version 4.5.0 20090805 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.6
GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1161644d70e4366deea2251f6760d83e
COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-mtune=generic'

c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/bin/as.exe
-v -V -o D:\DOKUME~1\rainer\LOCALS~1\Temp\cc0jfYFh.o
D:\DOKUME~1\rainer\LOCALS~1\Temp\ccxMcHNc.s
GNU assembler version 2.19.51 (x86_64-w64-mingw32) using BFD version (GNU
Binutils) 2.19.51.20090805
c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/bin/as.exe:
unrecognized option `-V'


-- 
   Summary: driver passes wrong parameter to as
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rainer at emrich-ebersheim dot de
 GCC build triplet: i686-pc-mingw32
  GCC host triplet: *-w64-mingw32
GCC target triplet: *-w64-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41024

[Bug libstdc++/41005] Unable to link fstream open and ctor with std::string argument.

[jwakely dot gcc at gmail dot com]

--- Comment #1 from jwakely dot gcc at gmail dot com  2009-08-10 12:26 
---
Does libstdc++-v3/src/fstream-inst.cc get compiled in C++0x mode?  If not, then
the C++0x-only symbols would not be instantiated in the library


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug c/41025] New: v4.3.3, 4.4.1, etc -ftracer sometimes fails by "is already defined"

[mahatma at eu dot by]

-ftracer on various gcc versions sometimes gives "is already defined" error on
build. Was on glibc (x86_*) & linux kernel (x86_64), but now git-kernel build
good and I not going deep. Only glibc 2.10.1 log tail:
===
[...]
i686-pc-linux-gnu-gcc ../sysdeps/unix/sysv/linux/dl-execstack.c -c -std=gnu99
-fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants
-fno-strict-aliasing -pipe -Wstrict-prototypes -mpreferred-stack-boundary=2 
-fPIC -g0 -O99 -fomit-frame-pointer -D__USE_STRING_INLINES-I../include
-I/var/tmp/portage/sys-libs/glibc-2.10.1/work/build-default-i686-pc-linux-gnu-nptl/elf
-I/var/tmp/portage/sys-libs/glibc-2.10.1/work/build-default-i686-pc-linux-gnu-nptl
-I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686
-I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386
-I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread
-I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu
-I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet
-I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv
-I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../sysdeps/unix
-I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../nptl/sysdeps/i386/i686
-I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486
-I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386
-I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl  -I.. -I../libio -I.
-nostdinc -isystem /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/include -isystem
/usr/lib/gcc/i686-pc-linux-gnu/4.3.3/include-fixed -isystem /usr/include
-D_LIBC_REENTRANT -include ../include/libc-symbols.h  -DPIC -DSHARED
-DNOT_IN_libc=1 -DIS_IN_rtld=1 -pipe -fomit-frame-pointer -ftracer
-U_FORTIFY_SOURCE -U_FORTIFY_SOURCE -o
/var/tmp/portage/sys-libs/glibc-2.10.1/work/build-default-i686-pc-linux-gnu-nptl/elf/dl-execstack.os
-MD -MP -MF
/var/tmp/portage/sys-libs/glibc-2.10.1/work/build-default-i686-pc-linux-gnu-nptl/elf/dl-execstack.os.dt
-MT
/var/tmp/portage/sys-libs/glibc-2.10.1/work/build-default-i686-pc-linux-gnu-nptl/elf/dl-execstack.os
 
../sysdeps/unix/sysv/linux/dl-execstack.c: Assembler messages:
../sysdeps/unix/sysv/linux/dl-execstack.c:163: Error: symbol
`__i686.get_pc_thunk.cx' is already defined
make[2]: ***
[/var/tmp/portage/sys-libs/glibc-2.10.1/work/build-default-i686-pc-linux-gnu-nptl/elf/dl-execstack.os]
Error 1
make[2]: Leaving directory
`/var/tmp/portage/sys-libs/glibc-2.10.1/work/glibc-2.10.1/elf'
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory
`/var/tmp/portage/sys-libs/glibc-2.10.1/work/glibc-2.10.1'
make: *** [all] Error 2
===


-- 
   Summary: v4.3.3, 4.4.1, etc -ftracer sometimes fails by "is
already defined"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mahatma at eu dot by
  GCC host triplet: i686-pc-linux-gnu-gcc, x86_64-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41025

[Bug c++/41020] [4.5 Regression] Can't declare an extern "C" friend.

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||rejects-valid
Summary|Can't declare an extern "C" |[4.5 Regression] Can't
   |friend. |declare an extern "C"
   ||friend.
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020

[Bug fortran/41022] [4.5.0] problem with procedure pointers

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2009-08-10 12:46 ---
Confirmed. -fdump-tree-original shows:

assign_proc_ptr (void (*) (void) * ptr, struct container_t & obj1)
{
  *ptr = obj1->proc;
}


-- 

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 |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-10 12:46:47
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41022

[Bug tree-optimization/41026] New: invariant address load inside loop

[rahul at icerasemi dot com]

gcc --version
gcc (GCC) 4.4.1 20090507 (prerelease)

The following test compiled with
gcc -S -Os

struct struct_t {
  int* data;
};

void testAddr (struct struct_t* sp, int len)
{
int i;
for (i = 0; i < len; i++)
  {
sp->data[i] = 0;
  }
}

generates the following code for x86

testAddr :
pushl   %ebp
xorl%eax, %eax
movl%esp, %ebp
movl8(%ebp), %ecx
pushl   %ebx
movl12(%ebp), %edx
jmp .L2
.L3:
movl(%ecx), %ebx  <-- invariant address load
movl$0, (%ebx,%eax,4)
incl%eax
.L2:
cmpl%edx, %eax
jl  .L3
popl%ebx
popl%ebp
ret

Whereas making the intent explicit like so

void testAddr (struct struct_t* sp, int len)
{
int i;
int *p = sp->data;
for (i = 0; i < len; i++)
  {
p[i] = 0;
  }
}

generates

testAddr :
pushl   %ebp
movl%esp, %ebp
movl8(%ebp), %eax
movl12(%ebp), %ecx
movl(%eax), %edx  <-- now outside the loop
xorl%eax, %eax
jmp .L2
.L3:
movl$0, (%edx,%eax,4)
incl%eax
.L2:
cmpl%ecx, %eax
jl  .L3
popl%ebp
ret

Why can't we move the address load outside the loop in the first case?


-- 
   Summary: invariant address load inside loop
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rahul at icerasemi dot com
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41026

[Bug libstdc++/41005] Unable to link fstream open and ctor with std::string argument.

[jwakely dot gcc at gmail dot com]

--- Comment #2 from jwakely dot gcc at gmail dot com  2009-08-10 13:17 
---
Since the C++0x changes to fstream are only additions, the simplest solution is
probably to compile src/fstream-inst.cc in c++0x mode, which just means adding
new targets to src/Makefile.am so that -std=gnu++0x is used.

I'll test that fix tonight if noone beats me to it.

The problem seems to be present on the 4.4 branch as well as trunk.


-- 

jwakely dot gcc at gmail dot com changed:

   What|Removed |Added

 CC||jwakely dot gcc at gmail dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug target/39386] [avr] different computation results for O1 and O0 executables

[anitha dot boyapati at atmel dot com]

--- Comment #6 from anitha dot boyapati at atmel dot com  2009-08-10 13:27 
---
Confirmed with gcc 4.4.0. Using switch -O0 with avr-gcc 4.4.0 (-mmcu=atmega128)
gave the result 0 while -O1 gave 0xFF


-- 

anitha dot boyapati at atmel dot com changed:

   What|Removed |Added

 CC||anitha dot boyapati at atmel
   ||dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39386

[Bug target/39386] [avr] different computation results for O1 and O0 executables

[eric dot weddington at atmel dot com]

-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2009-03-18 17:47:31 |2009-08-10 13:40:54
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39386

[Bug fortran/41022] [F03] problem with procedure pointers

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-08-10 13:41 ---
Actually the part of the dump shown in comment #2 is ok. The problematic piece
is this:

transfer_proc_ptr (struct container_t & obj2, struct container_t & obj1)
{
  [...]
  assign_proc_ptr (obj2->proc, (struct container_t *) obj1);
}

Here the obj2->proc is missing an "&".


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.5.0] problem with|[F03] problem with procedure
   |procedure pointers  |pointers


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41022

[Bug fortran/41022] [F03] problem with procedure pointers

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-08-10 13:49 ---
This problems seems to be similar to PR 40450.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41022

[Bug fortran/41022] [F03] procedure pointer components as actual arguments

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2009-08-10 14:14 ---
This patchlet should fix it:

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 150621)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -2679,7 +2679,8 @@ gfc_conv_procedure_call (gfc_se * se, gf
   && fsym->attr.flavor != FL_PROCEDURE)
  || (fsym->attr.proc_pointer
  && !(e->expr_type == EXPR_VARIABLE
- && e->symtree->n.sym->attr.dummy
+ && e->symtree->n.sym->attr.dummy))
+ || gfc_is_proc_ptr_comp (e, NULL)))
{
  /* Scalar pointer dummy args require an extra level of
 indirection. The null pointer already contains


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|[F03] problem with procedure|[F03] procedure pointer
   |pointers|components as actual
   ||arguments


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41022

[Bug c++/41002] Redundant diagnostic when class member function's name overlaps with class field's name

[b0ntrict0r at yandex dot ru]

--- Comment #4 from b0ntrict0r at yandex dot ru  2009-08-10 14:16 ---
Thank you for your explanation.


(In reply to comment #2)
> The errors for lines 9 and 15 relate to the duplicate declaration of a member
> with the name 'number', whereas the error on line 4 refers to the invalid
> member initializer for 'number'.  Those are separate errors.

Those are seperate errors of course. I've meant that when compiler already
discovered that there is a conflict between number and number() it looks like
it's keeping on emitting errors on every occurence of symbol that becoms a
source of that conflict. In fact GCC found out that it is able to create nor
property number nor member number(); later compiler descried a reference to a
variable that is not exist (because it killed this variable later) and omitted
another error. I agree that compiler exhibits its strict behaviour there but
I'm not shure is it good for non-pedantic mode.
Anyway I'm not familiar with internals, principles and organization of
compilers, so I can be badly mistaken for my proposition.


(In reply to comment #2)
> Huh?  The errors are the same except for swapping which declaration is treated
> as the duplicate and which as the previous declaration, and that's because you
> swappged the order.  What did you expect?  Why is it more unclear?
I expected a different order of error messages.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41002

[Bug other/41027] New: Missing warning from -Wc++-compat

[rearnsha at gcc dot gnu dot org]

trying to build gcc for arm-eabi with --enable-build-with-cxx fails with
'structure 'key' with uninitialized const members'.  However, a normal C-based
bootstrap does not report this as a warning when -Wc++-compat is used.

struct f
{
  const int a;
};

void g(struct f*);

void h ()
{
struct f h;
g(&h);
}


-- 
   Summary: Missing warning from -Wc++-compat
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-eabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41027

[Bug c++/41002] Redundant diagnostic when class member function's name overlaps with class field's name

[jwakely dot gcc at gmail dot com]

--- Comment #5 from jwakely dot gcc at gmail dot com  2009-08-10 14:44 
---
(In reply to comment #4)
> Those are seperate errors of course. I've meant that when compiler already
> discovered that there is a conflict between number and number() it looks like
> it's keeping on emitting errors on every occurence of symbol that becoms a
> source of that conflict. In fact GCC found out that it is able to create nor
> property number nor member number(); later compiler descried a reference to a
> variable that is not exist (because it killed this variable later) and omitted
> another error. I agree that compiler exhibits its strict behaviour there but
> I'm not shure is it good for non-pedantic mode.

Ah, I see what you mean.

-pedantic controls something different and I don't think it should suppress
later errors as you suggest.  You might want to try -Wfatal-errors, which will
cause compilation to stop at the first error.  That's still not exactly what
you want, as it will prevent *all* further errors being printed and not just
those which are related to the first one, but I think in general it would be
very difficult for the compiler to determine if individual errors are caused by
an earlier error and suppress them conditionally.  


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41002

[Bug c++/41002] Redundant diagnostic when class member function's name overlaps with class field's name

[b0ntrict0r at yandex dot ru]

--- Comment #6 from b0ntrict0r at yandex dot ru  2009-08-10 15:02 ---
I've got your point, thank you. So if
(In reply to comment #5)
> in general it would be
> very difficult for the compiler to determine if individual errors are caused 
> by
> an earlier error and suppress them conditionally
I calculate the bug can be closed?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41002

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2009-08-10 15:09 ---
For now, the workaround is to provide some or all of these explicit
instantiations in your program:

namespace std
{
template
basic_ofstream::basic_ofstream(string const&, ios_base::openmode);

template
void 
basic_ofstream::open(string const&, ios_base::openmode);

template
basic_ifstream::basic_ifstream(string const&, ios_base::openmode);

template
void 
basic_ifstream::open(string const&, ios_base::openmode);

template
basic_fstream::basic_fstream(string const&, ios_base::openmode);

template
void 
basic_fstream::open(string const&, ios_base::openmode);

template
basic_filebuf*
basic_filebuf::open(string const&, ios_base::openmode);
}


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.4.1 4.5.0
   Last reconfirmed|-00-00 00:00:00 |2009-08-10 15:09:05
   date||
Summary|Unable to link fstream open |[C++0x] Unable to link
   |and ctor with std::string   |fstream open and ctor with
   |argument.   |std::string argument.


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug c++/41028] New: Compilation error when a class specialization use a typedef define in a template class

[maxime dot fiandino at gmail dot com]

I do a partial specialisation of a class. I havec a compilation error if I
specialize on a typedef which is defined in a template class


-- 
   Summary: Compilation error when a class specialization use a
typedef define in a template class
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: maxime dot fiandino at gmail dot com
 GCC build triplet: Linux-i686
  GCC host triplet: Linux-i686
GCC target triplet: Linux-i686


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41028

[Bug c++/41028] Compilation error when a class specialization use a typedef define in a template class

[maxime dot fiandino at gmail dot com]

--- Comment #1 from maxime dot fiandino at gmail dot com  2009-08-10 15:20 
---
Created an attachment (id=18336)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18336&action=view)
simple source with the bug

just use:
g++ main.cc

on 3.46/4.1.1 no error
on 4.4.0/4.4.1
main.cc:30: error: template parameters not used in partial specialization:
main.cc:30: error: 'T'
main.cc:30: error: 'U'


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41028

[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

[sje at cup dot hp dot com]

--- Comment #18 from sje at cup dot hp dot com  2009-08-10 15:33 ---
I tried the pa.c change, it didn't help.  I will do a non-bootstrap build with
tests.  All my HP-UX machines are behind the HP firewall unfortunately.  I see
we have a PA box in the compile farm but I think it is running linux and not
hpux.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952

[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395

[uweigand at gcc dot gnu dot org]

--- Comment #19 from uweigand at gcc dot gnu dot org  2009-08-10 15:34 
---
Subject: Bug 37053

Author: uweigand
Date: Mon Aug 10 15:34:09 2009
New Revision: 150626

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150626
Log:
PR target/37053
* reload1.c (reload_as_needed): Use cancel_changes to completely
undo a failed replacement attempt.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/reload1.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053

[Bug c++/41028] Compilation error when a class specialization use a typedef define in a template class

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2009-08-10 15:36 ---
The code is invalid:  The template parameters T and U cannot be deduced in your
partial specialization, because they occur in a non-deduced context.

According to 14.5.4.1 [temp.class.spec.match] paragraph 2 the template
arguments of the partial specialisation must be deduced, but in the attached
program they appear in non-deduced contexts as defined by 14.8.2.4
[temp.deduct]
paragraph 4.


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41028

[Bug c++/41020] [4.5 Regression] Can't declare an extern "C" friend.

[davek at gcc dot gnu dot org]

--- Comment #3 from davek at gcc dot gnu dot org  2009-08-10 16:17 ---
(In reply to comment #2)
> Apart from the semi-colon after the extern "C" block the code is valid and 
> this
> is a recent regression on trunk.

I am fairly sure that a semi-colon after a block statement like that is
unnecessary, but not actually invalid.  It certainly makes no difference to the
testcase whether it is present or absent.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020

[Bug c++/41020] [4.5 Regression] Can't declare an extern "C" friend.

[jwakely dot gcc at gmail dot com]

--- Comment #4 from jwakely dot gcc at gmail dot com  2009-08-10 17:05 
---
It's irrelevant to this bug and is just me being more pedantic than -pedantic,
however ... even with -pedantic GCC has always accepted stray semi-colons at
namespace scope, but it's not valid.

At function scope a lone ';' is a valid expression-statement, but
expression-statements are not allowed at namespace scope, only declarations
are, and ';' is not a valid declaration.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020

[Bug c++/41020] [4.5 Regression] Can't declare an extern "C" friend.

[davek at gcc dot gnu dot org]

--- Comment #5 from davek at gcc dot gnu dot org  2009-08-10 17:16 ---
(In reply to comment #4)
> It's irrelevant to this bug and is just me being more pedantic than -pedantic,
> however ... even with -pedantic GCC has always accepted stray semi-colons at
> namespace scope, but it's not valid.
> 
> At function scope a lone ';' is a valid expression-statement, but
> expression-statements are not allowed at namespace scope, only declarations
> are, and ';' is not a valid declaration.

  Well you learn something new every day!  Never realised that was a gnu
extension, but it sure is, comeau online choked on my testcase:

"ComeauTest.c", line 5: error: extra ";" ignored,
In C: A function definition does not end with a semicolon
In C++: A non-member function definition, extern "C" block,
or namespace does not end with a semicolon
  };
   ^
  Anyway.  Consider the testcase amended.  :-)

$ cat friend.cxx

extern "C"
{
  int fork (void);
}

class frok
{
  int this_errno;
  friend int fork (void);
};

extern "C" int
fork (void)
{
  frok grouped;
  return grouped.this_errno;
}

$ g++-4 -c friend.cxx -o friend.o
friend.cxx:10:24: error: new declaration 'int fork()'
friend.cxx:4:7: error: ambiguates old declaration 'int fork()'
friend.cxx: In function 'int fork()':
friend.cxx:9:7: error: 'int frok::this_errno' is private
friend.cxx:17:18: error: within this context

$


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020

[Bug target/32893] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[mahatma at eu dot by]

--- Comment #23 from mahatma at eu dot by  2009-08-10 17:48 ---
(In reply to comment #17)

> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129764
> Log:
> PR tree-optimization/32893
> * tree-vectorize.c (vect_can_force_dr_alignment_p): Check
> STACK_BOUNDARY instead of PREFERRED_STACK_BOUNDARY.

In 4.4 STACK_BOUNDARY changed to MAX_STACK_ALIGNMENT in this place.
MAX_STACK_ALIGNMENT is STACK_BOUNDARY "by default", but in i386.h:
#define MAX_STACK_ALIGNMENT MAX_OFILE_ALIGNMENT

I not check code dependences more, but starting from 4.4.0 this error alive
(Bug 40985). Are there are regression or something else?

PS May be reopen this bug with other version or Bug 40985 as regression report?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893

[Bug bootstrap/41018] bootstrap broken on FreeBSD powerpc

[andreast at gcc dot gnu dot org]

--- Comment #1 from andreast at gcc dot gnu dot org  2009-08-10 18:22 
---
Subject: Bug 41018

Author: andreast
Date: Mon Aug 10 18:22:22 2009
New Revision: 150631

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150631
Log:
2009-08-10  Andreas Tobler  

PR bootstrap/41018
* config/rs6000/freebsd.h: Define SVR4_ASM_SPEC. Adjust copyright
year.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/rs6000/freebsd.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41018

[Bug bootstrap/41018] bootstrap broken on FreeBSD powerpc

[andreast at gcc dot gnu dot org]

--- Comment #2 from andreast at gcc dot gnu dot org  2009-08-10 18:24 
---
Subject: Bug 41018

Author: andreast
Date: Mon Aug 10 18:23:57 2009
New Revision: 150632

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150632
Log:
2009-08-10  Andreas Tobler  

PR bootstrap/41018
* config/rs6000/freebsd.h: Define SVR4_ASM_SPEC. Adjust copyright
year.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/freebsd.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41018

[Bug bootstrap/41018] bootstrap broken on FreeBSD powerpc

[andreast at gcc dot gnu dot org]

--- Comment #3 from andreast at gcc dot gnu dot org  2009-08-10 18:25 
---
Committed.


-- 

andreast at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41018

[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

[sje at cup dot hp dot com]

--- Comment #19 from sje at cup dot hp dot com  2009-08-10 19:32 ---
Here are the unexpected failures I see when running the testsuite using a
non-bootstrap PA compiler.  The compiler I built includes the patch from
comment #17.

FAIL: 22_locale/ctype/narrow/char/2.cc execution test
FAIL: gcc.c-torture/execute/20020108-1.c execution,  -O0
FAIL: gcc.c-torture/execute/20020108-1.c execution,  -O1
FAIL: gcc.c-torture/execute/pr39240.c execution,  -O0
FAIL: gcc.c-torture/execute/pr39240.c execution,  -O1
FAIL: gcc.c-torture/execute/pr39240.c execution,  -O2
FAIL: gcc.c-torture/execute/pr39240.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/pr39240.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/pr39240.c execution,  -Os
FAIL: gfortran.dg/compiler-directive_1.f90  -O   (test for errors, line 42)
FAIL: gfortran.dg/compiler-directive_1.f90  -O  (test for excess errors)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[3dw4rd at verizon dot net]

--- Comment #4 from 3dw4rd at verizon dot net  2009-08-10 19:35 ---
(In reply to comment #2)
> Since the C++0x changes to fstream are only additions, the simplest solution 
> is
> probably to compile src/fstream-inst.cc in c++0x mode, which just means adding
> new targets to src/Makefile.am so that -std=gnu++0x is used.
> 
> I'll test that fix tonight if noone beats me to it.
> 
> The problem seems to be present on the 4.4 branch as well as trunk.
> 

I'm confused because the definitions of these functions are in the header
include/std/fstream.  I thought that inclusion of the header with the
-std=c++0x flag would get the definition or that if PCH is used, at least one
would have been compiled with -std=gnu++0x and provide the definition.

I would have thought ODR would prevent having the definition here and in
src/fstream-inst.cc.

Or are you saying we should either:
1) move definition open(std::string) etc. to src/fstream-inst.cc (or maybe
better src/fstream-inst_c++0x.cc to be consistent with other treatments).
2) move definition open(std::string) etc. to src/fstream-inst_c++0x.cc
   AND
   move definition open(const char *) etc. to src/fstream-inst.cc
   for consistency


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug target/41017] regparm=3 passes structures inconsistently

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #7 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-08-10 19:36 ---
Worse, try to return these structures with -freg-struct-return and it also
follows this inconsistent pattern, some are returned in EAX:EDX, some are
returned in ST(0).

It is even inconsistent between GCC releases:
struct {
float a[1];
float a[0];
}
is returned in EAX on GCC-3.3 and in ST(0) on GCC-3.4 and GCC-4.

It is much worse than regparm inconsistency because some operating systems (for
example FreeBSD) use -freg-struct-return as a default calling convention and
GCC generates incompatible code for them.

Where is this "-freg-struct-return" thing documented. The documentation in
manpage, "Return 'struct' and 'union' values in registers when possible." is
really inadequate.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41017

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[jwakely dot gcc at gmail dot com]

--- Comment #5 from jwakely dot gcc at gmail dot com  2009-08-10 19:39 
---
The definitions are in that header, but the 'extern template' extension is used
to prevent the compiler from instantiating the code in your program, see
http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html

Instead of instantiating that code in every object a single explicit
instantiation is provided in libstdc++.so, that's the purpose of
src/fstream-inst.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[jwakely dot gcc at gmail dot com]

--- Comment #6 from jwakely dot gcc at gmail dot com  2009-08-10 20:05 
---
(In reply to comment #5)
> Instead of instantiating that code in every object a single explicit
> instantiation is provided in libstdc++.so, that's the purpose of
> src/fstream-inst.cc

... but in this case it fails to provide an explicit instantiation of the new
C++0x members because src/fstream-inst.cc is not compiled with -std=c++0x or
-std=gnu++0x

So the library tells the compiler not to instantiate the templates in your
code, promising to provide explicit instantiations, and then fails to provide
the explicit instantiations. So the workaround I gave in comment #3 provides
them in your program.  Another workaround would be to compile with
-D_GLIBCXX_EXTERN_TEMPLATE=0, which disables the extern template feature,
causing the compiler to implicitly instantiate the templates in every file that
needs them, and then rely on the linker to merge the duplicate definitions.

But the right fix is just to ensure src/fstream-inst.cc is compiled in C++0x
mode, so that the instantiations are present in libstdc++.so and you don't need
any workaround.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

[bonzini at gnu dot org]

--- Comment #20 from bonzini at gnu dot org  2009-08-10 20:09 ---
Created an attachment (id=18337)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18337&action=view)
patch fixing hpux differences

This patch squashes in the following too.  It is a stupid used-uninitialized
bug that was not signaled because unsignedp is passed by reference to
promote_function_mode.

Index: gcc/stmt.c
===
--- gcc/stmt.c  (branch promote-function-mode2)
+++ gcc/stmt.c  (working copy)
@@ -1517,8 +1517,8 @@ expand_value_return (rtx val)
   rtx return_reg = DECL_RTL (decl);
   if (return_reg != val)
 {
-  int unsignedp;
   tree funtype = TREE_TYPE (current_function_decl);
   tree type = TREE_TYPE (decl);
+  int unsignedp = TYPE_UNSIGNED (type);
   enum machine_mode old_mode = DECL_MODE (decl);
   enum machine_mode mode = promote_function_mode (type, old_mode,

I'll also bootstrap the patch overnight on x86_64-pc-linux-gnu, and plan to
rename the last argument of the hook now.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

  Attachment #18309|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952

[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

[sje at cup dot hp dot com]

--- Comment #21 from sje at cup dot hp dot com  2009-08-10 20:18 ---
That seems to have fixed pr39240.c in the testsuite.  I will try a complete
bootstrap again.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952

[Bug fortran/41023] Inconsistent error locations for wrong interfaces with overloaded operators

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2009-08-10 20:54 ---
I think the ifort messages are more helpful:

[ibook-dhum] f90/bug% ifc pr41023.f90
pr41023.f90(14): error #6711: The number of function arguments is inconsistent
with the intrinsic use of the OPERATOR.   [MYPLUS]
  INTEGER FUNCTION myplus (a, b, c)
---^
compilation aborted for pr41023.f90 (code 1)

[ibook-dhum] f90/bug% ifc pr41023_1.f90
pr41023_1.f90(14): error #6708: A specific procedure must be a function for a
defined OPERATOR.   [MYPLUS]
  SUBROUTINE myplus (a, b)
-^
compilation aborted for pr41023_1.f90 (code 1)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41023

[Bug middle-end/41029] New: ICE RTL check: expected code 'reg', have 'post_inc' in rhs_regno, at rtl.h:1008

[rmansfield at qnx dot com]

Building sh4-unknown-linux-gnu target with --enable-checking=rtl yields.

gcc version 4.5.0 20090810 (experimental) [trunk revision 150633] (GCC)

../../../libiberty/floatformat.c: In function 'floatformat_from_double':
../../../libiberty/floatformat.c:683:1: internal compiler error: RTL check:
expected code 'reg', have 'post_inc' in rhs_regno, at rtl.h:1008
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: ICE RTL check: expected code 'reg', have 'post_inc' in
rhs_regno, at rtl.h:1008
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sh4-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41029

[Bug target/41015] [4.4/4.5 Regression] SH: miscompilation for sh4-linux

[kkojima at gcc dot gnu dot org]

--- Comment #5 from kkojima at gcc dot gnu dot org  2009-08-10 20:57 ---
Subject: Bug 41015

Author: kkojima
Date: Mon Aug 10 20:57:35 2009
New Revision: 150635

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150635
Log:
PR target/41015
* longlong.h [__sh__] (udiv_qrnnd): Add T register to clobber list.
(sub_ddmmss): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/longlong.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41015

[Bug tree-optimization/41026] invariant address load inside loop

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||alias
   Last reconfirmed|-00-00 00:00:00 |2009-08-10 21:13:09
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41026

[Bug tree-optimization/41026] invariant address load inside loop with -Os.

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-08-10 21:15 ---
This is not an aliasing issue rather PRE not running at -Os which is expected.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|alias   |
Summary|invariant address load  |invariant address load
   |inside loop |inside loop with -Os.


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41026

[Bug tree-optimization/41026] invariant address load inside loop with -Os.

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2009-08-10 21:29 ---
Hmm, this isn't my day.  Of course you're right, Andrew.

So the issue is that a loop invariant load is not hoisted at -Os, because it
does not improve size.

FWIW several patches have been proposed to change this, see e.g.:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00199.html
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00794.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41026

[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

[sje at cup dot hp dot com]

--- Comment #22 from sje at cup dot hp dot com  2009-08-10 21:30 ---
A hppa2.0w-hp-hpux11.11 bootstrap was successful with the v3 patch and running
the broken tests also looks OK now.  I will let my normal nightly process do a
full test run tonight on PA but it looks good.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952

[Bug c++/41030] New: [C++0x] "invalid operands" error doing == on strong enums

[msclrhd at gmail dot com]

#!/bin/bash

cat << EOF > test.cpp
enum class foo : char
{
A,
B
};

int main()
{
foo a = foo::A;

return (a == foo::A) ? 1 : 0;
}
EOF

$ g++-4.4 -std=c++0x test.cpp
test.cpp: In function ‘int main()’:
test.cpp:11: error: invalid operands of types ‘foo’ and ‘foo’ to binary
‘operator==’

$ gcc-4.4 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.4-20090418-1ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.0 20090419 (prerelease) [gcc-4_4-branch revision 146360]
(Ubuntu 4.4-20090418-1ubuntu3)


-- 
   Summary: [C++0x] "invalid operands" error doing == on strong
enums
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msclrhd at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41030

[Bug middle-end/41029] ICE RTL check: expected code 'reg', have 'post_inc' in rhs_regno, at rtl.h:1008

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2009-08-10 21:33 ---
Can you attach the preprocessed source, so that we can try to reproduce this
without building a complete cross-toolchain?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41029

[Bug c++/38064] [c++0x] operator== doesn't work for enum classes

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38064

[Bug c++/41030] [C++0x] "invalid operands" error doing == on strong enums

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-08-10 21:37 ---


*** This bug has been marked as a duplicate of 38064 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41030

[Bug c++/38064] [c++0x] operator== doesn't work for enum classes

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2009-08-10 21:37 
---
*** Bug 41030 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||msclrhd at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38064

[Bug middle-end/41029] ICE RTL check: expected code 'reg', have 'post_inc' in rhs_regno, at rtl.h:1008

[rmansfield at qnx dot com]

--- Comment #2 from rmansfield at qnx dot com  2009-08-10 21:40 ---
Created an attachment (id=18338)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18338&action=view)
preprocessed source


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41029

[Bug middle-end/41029] ICE RTL check: expected code 'reg', have 'post_inc' in rhs_regno, at rtl.h:1008

[rmansfield at qnx dot com]

--- Comment #3 from rmansfield at qnx dot com  2009-08-10 22:12 ---
It doesn't appear on gcc 4.3 and 4.4 branches. I'll narrow down when it was
introduced.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41029

[Bug bootstrap/40788] [4.5 regression] ICE on sparc: tree check: expected class 'expression', have 'declaration' (var_decl) in gimplify_va_arg_expr, at builtins.c:5107

[laurent at guerby dot net]

--- Comment #7 from laurent at guerby dot net  2009-08-10 22:25 ---
I tested the following patch and it restores --with-cpu=v8 c,ada bootstrap

Index: gcc/builtins.c
===
--- gcc/builtins.c  (revision 150589)
+++ gcc/builtins.c  (working copy)
@@ -5104,7 +5104,6 @@
return GS_ALL_DONE;

   *expr_p = targetm.gimplify_va_arg_expr (valist, type, pre_p, post_p);
-  SET_EXPR_LOCATION (*expr_p, loc);
   return GS_OK;
 }
 }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40788

[Bug target/41029] ICE RTL check: expected code 'reg', have 'post_inc' in rhs_regno, at rtl.h:1008

[kkojima at gcc dot gnu dot org]

--- Comment #4 from kkojima at gcc dot gnu dot org  2009-08-10 23:15 ---
GDB backtrace shows a target problem.  I'm testing the patch below.

* config/sh/sh.md (reload_outdf__RnFRm+4): Fix thinko.

--- ORIG/trunk/gcc/config/sh/sh.md  2009-07-06 23:27:44.0 +0900
+++ trunk/gcc/config/sh/sh.md   2009-08-11 07:54:41.0 +0900
@@ -6065,7 +6065,7 @@ label:
   /* If we have modified the stack pointer, the value that we have
 read with post-increment might be modified by an interrupt,
 so write it back.  */
-  if (REGNO (addr) == STACK_POINTER_REGNUM)
+  if (REGNO (XEXP (addr, 0)) == STACK_POINTER_REGNUM)
emit_insn (gen_push_e (reg0));
   else
emit_insn (gen_addsi3 (XEXP (operands[1], 0), XEXP (operands[1],
0), GEN_INT (-4)));


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|middle-end  |target
 Ever Confirmed|0   |1
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2009-08-10 23:15:48
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41029

[Bug tree-optimization/41031] New: [4.5 Regression]: build breakage for cris-elf building newlib, ICE in insert_value_copy_on_edge

[hp at gcc dot gnu dot org]

With revision 150591, cris-elf built.
>From revision 150593 and on, build is broken as follows, compiling newlib:

...
/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v10/newlib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v10/newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v10/libgloss/cris
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v10/libgloss/libnosys
-L/tmp/hpautotest-gcc1/gcc/libgloss/cris
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include  -march=v10
-mbest-lib-options -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.17.0\" -DPACKAGE_STRING=\"newlib\ 1.17.0\"
-DPACKAGE_BUGREPORT=\"\"  -I. -I/tmp/hpautotest-gcc1/gcc/newlib/libc/stdlib -O2
-DHAVE_RENAME -D_USE_WRITE -DCOMPACT_CTYPE -fno-builtin  -g -O2  -march=v10
-mbest-lib-options -c -o lib_a-ecvtbuf.o `test -f 'ecvtbuf.c' || echo
'/tmp/hpautotest-gcc1/gcc/newlib/libc/stdlib/'`ecvtbuf.c
/tmp/hpautotest-gcc1/gcc/newlib/libc/stdlib/ecvtbuf.c: In function 'print_e':
/tmp/hpautotest-gcc1/gcc/newlib/libc/stdlib/ecvtbuf.c:146:1: internal compiler
error: in insert_value_copy_on_edge, at tree-outof-ssa.c:223
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[8]: *** [lib_a-ecvtbuf.o] Error 1
make[8]: Leaving directory
`/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v10/newlib/libc/stdlib'

Author of patches in suspect revision range CC:ed.

Will attach preprocessed source.


-- 
   Summary: [4.5 Regression]: build breakage for cris-elf building
newlib, ICE in insert_value_copy_on_edge
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, build
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41031

[Bug tree-optimization/41031] [4.5 Regression]: build breakage for cris-elf building newlib, ICE in insert_value_copy_on_edge

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2009-08-11 00:18 ---
Created an attachment (id=18339)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18339&action=view)
Preprocessed ecvtbuf.c from months-old newlib

Compile with -O2 to reproduce ICE.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41031

[Bug tree-optimization/41031] [4.5 Regression]: build breakage for cris-elf building newlib, ICE in insert_value_copy_on_edge

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2009-08-11 01:02 ---
I had a brief look.  Seems like the new code assumes that promote_mode always
promotes the input mode (ahem! :) when mismatching, which it only does if the
target defines PROMOTE_MODE (which CRIS does not; it just has a
TARGET_PROMOTE_FUNCTION_MODE hook).  So, a QImode is still QImode and
mismatching SImode for the object in SA.partition_to_pseudo[dest])).

At the gcc_assert in question:
(gdb) p src_mode
$24 = QImode
(gdb) p unsignedp
$25 = 0
(gdb) p dest_mode
$26 = QImode
(gdb) p dest
$27 = 3
(gdb) p SA.partition_to_pseudo[dest]
$28 = (rtx) 0xb7e658f0
(gdb) pr
(reg/v:SI 220 [ type ])

hth


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41031

[Bug target/8603] [Alpha] s?addl pattern doesn't work

[mattst88 at gmail dot com]

--- Comment #6 from mattst88 at gmail dot com  2009-08-11 02:38 ---
To show how worthwhile this trivial patch is -- the following table shows the
number of times s{4,8}{add,sub}l are used in building the Linux kernel
(2.6.31-rc5) with unpatched and patched gcc (4.3.4).

unpatched   patched
s4addl  53  395
s8addl  79  132
s4subl  0   111
s8subl  0   35

This patch also causes gcc to produce exactly the same output as Compaq's C
compiler (this is a good thing!) for the two test cases given in the report.

For example --
Test case:
UP1500 gcc-tests # cat s_addl.c 
int f(int x, int y) { return 4 * x + y; }
int g(int x) { return 3 * x; }

Results with unpatched gcc-4.3.x

UP1500 gcc-tests # gcc-unpatched -O3 -mcpu=ev67 -c s_addl.c 
UP1500 gcc-tests # objdump -d s_addl.o 

s_addl.o: file format elf64-alpha

Disassembly of section .text:

 :
   0:   40 04 11 42 s4addq  a0,a1,v0
   4:   00 00 e0 43 sextl   v0,v0 <-- unnecessary
   8:   01 80 fa 6b ret
   c:   00 00 fe 2f unop

0010 :
  10:   60 05 10 42 s4subq  a0,a0,v0
  14:   00 00 e0 43 sextl   v0,v0 <-- unnecessary
  18:   01 80 fa 6b ret
  1c:   00 00 fe 2f unop

Results with patched gcc-4.3.x

UP1500 gcc-tests # gcc-patched -O3 -mcpu=ev67 -c s_addl.c 
UP1500 gcc-tests # objdump -d s_addl.o 

s_addl.o: file format elf64-alpha

Disassembly of section .text:

 :
   0:   40 00 11 42 s4addl  a0,a1,v0
   4:   01 80 fa 6b ret
   8:   1f 04 ff 47 nop
   c:   00 00 fe 2f unop

0010 :
  10:   60 01 10 42 s4subl  a0,a0,v0
  14:   01 80 fa 6b ret
  18:   1f 04 ff 47 nop
  1c:   00 00 fe 2f unop

Results with Compaq C compiler (what we're trying to replicate)

UP1500 gcc-tests # ccc -fast -host -c s_addl.c 
UP1500 gcc-tests # objdump -d s_addl.o 

s_addl.o: file format elf64-alpha

Disassembly of section .text:

 :
   0:   40 00 11 42 s4addl  a0,a1,v0
   4:   01 80 fa 6b ret
   8:   00 00 fe 2f unop
   c:   00 00 fe 2f unop

0010 :
  10:   60 01 10 42 s4subl  a0,a0,v0
  14:   01 80 fa 6b ret


Please add to gcc-4.3.x and gcc-4.4.x.


-- 

mattst88 at gmail dot com changed:

   What|Removed |Added

 CC||mattst88 at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8603

[Bug target/8603] [Alpha] s?addl pattern doesn't work

[ubizjak at gmail dot com]

--- Comment #7 from ubizjak at gmail dot com  2009-08-11 06:46 ---
(In reply to comment #6)

> Please add to gcc-4.3.x and gcc-4.4.x.

OK, I will post the patch, thanks for the analysis.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|rask at gcc dot gnu dot org |ubizjak at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8603