[Bug fortran/41922] New: Diagnostic: No location shown for overlappingly initialized EQUIVALENCEd character vars

2009-11-03 Thread burnus at gcc dot gnu dot org
Reported at http://gcc.gnu.org/ml/fortran/2009-11/msg00011.html


In the following program, the error location is not shown:



Error: Overlapping unequal initializers in EQUIVALENCE at (1)


Using the commented version instead, it works:

  data cstore/2*4/
 1
Error: Overlapping unequal initializers in EQUIVALENCE at (1)



  Subroutine RestoreR8Run()
  Implicit NONE
  Integer   ISTORE
  Real  XSTORE
!  integer   CSTORE(2)
!  data cstore/2*4/
  character   CSTORE(8)
  data cstore/8*' '/
  data istore/0/
  EQUIVALENCE (CSTORE(1),XSTORE,ISTORE)
  end


-- 
   Summary: Diagnostic: No location shown for overlappingly
initialized EQUIVALENCEd character vars
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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



[Bug c++/37093] [4.2/4.3 Regression] ICE with pointer to member template parameters

2009-11-03 Thread dodji at gcc dot gnu dot org


--- Comment #24 from dodji at gcc dot gnu dot org  2009-11-03 09:23 ---
Subject: Bug 37093

Author: dodji
Date: Tue Nov  3 09:23:41 2009
New Revision: 153841

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153841
Log:
Fix PR c++/37093

gcc/cp/ChangeLog:

PR c++/37093
* pt.c (check_valid_ptrmem_cst_expr): New function.
(convert_nontype_argument): Use it to output an error for
illegal pointer to member expressions used as template arguments.

gcc/testsuite/ChangeLog:

PR c++/37093
* g++.dg/other/ptrmem10.C: New test.
* g++.dg/other/ptrmem11.C: Likewise.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/ptrmem10.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/ptrmem11.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/pt.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/37093] [4.2/4.3 Regression] ICE with pointer to member template parameters

2009-11-03 Thread dodji at gcc dot gnu dot org


--- Comment #25 from dodji at gcc dot gnu dot org  2009-11-03 09:25 ---
Fixed in 4.3 branch.


-- 

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=37093



[Bug lto/41569] .../prev-gcc/xgcc used for the install step of the lto-plugin

2009-11-03 Thread rguenth at gcc dot gnu dot org


--- Comment #13 from rguenth at gcc dot gnu dot org  2009-11-03 09:50 
---
Same problem persists.  The problem are

lto-plugin.lo: ...
 /abuild/rguenther/obj3/./prev-gcc/include/stddef.h \
...
 /abuild/rguenther/obj3/./prev-gcc/include/stdint.h /usr/include/stdint.h \

in lto-plugin/.deps/lto-plugin.Plo

Still

+dependencies = { module=lto-plugin; on=all-gcc; };

is probably correct and needed as we include

#include "../gcc/lto/common.h"

which might refer to generated includes.


-- 


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



[Bug lto/41921] Cross language don't work with typedef unnamed structs

2009-11-03 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2009-11-03 10:11 ---
I will have a look.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-03 10:11:17
   date||


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



[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

2009-11-03 Thread bonzini at gnu dot org


--- Comment #7 from bonzini at gnu dot org  2009-11-03 10:23 ---
Part of the problem is that for each open parenthesis we go through

c_parser_postfix_expression
c_parser_expression
c_parser_expr_no_commas
c_parser_conditional_expression
c_parser_binary_expression
c_parser_cast_expression
c_parser_unary_expression

and back to c_parser_postfix_expression.  c_parser_binary_expression has a
_huge_ stack impact, this should be fixed.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-12-29 07:24:07 |2009-11-03 10:23:32
   date||


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



[Bug c++/38699] [4.3/4.4/4.5 regression] ICE using offsetof with pointer and array accesses

2009-11-03 Thread dodji at gcc dot gnu dot org


--- Comment #12 from dodji at gcc dot gnu dot org  2009-11-03 10:44 ---
Subject: Bug 38699

Author: dodji
Date: Tue Nov  3 10:44:36 2009
New Revision: 153843

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153843
Log:
Fix PR c++/38699

gcc/ChangeLog:

PR c++/38699
* c-common.c (fold_offsetof_1): Issue errors when the
member designator of the offsetoff expression is not legitimate.

gcc/testsuite/ChangeLog:

* c-c++-common/dfp/builtin-offsetof.c: New test.
* g++.dg/other/offsetof6.C: Likewise.

Added:
trunk/gcc/testsuite/c-c++-common/dfp/builtin-offsetof.c
trunk/gcc/testsuite/g++.dg/other/offsetof6.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/38699] [4.3/4.4/4.5 regression] ICE using offsetof with pointer and array accesses

2009-11-03 Thread dodji at gcc dot gnu dot org


--- Comment #13 from dodji at gcc dot gnu dot org  2009-11-03 10:46 ---
Subject: Bug 38699

Author: dodji
Date: Tue Nov  3 10:46:00 2009
New Revision: 153844

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153844
Log:
Fix PR c++/38699

gcc/ChangeLog:

PR c++/38699
* c-common.c (fold_offsetof_1): Issue errors when the member designator
of
the offsetoff expression is not legitimate.

gcc/testsuite/ChangeLog:

* c-c++-common/dfp/builtin-offsetof.c: New test.
* g++.dg/other/offsetof6.C: Likewise.

Added:
branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/
branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/dfp/
branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/dfp/builtin-offsetof.c
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/offsetof6.C
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/c-common.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug tree-optimization/41919] [4.5 Regression] optimized code with -O2 or -O3 gives strange result

2009-11-03 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2009-11-03 10:48 ---
It's VRP which does

si1_12: [-104, -104]

Folding statement: if (si1_12 > 0)
Simplified relational if (si1_12 > 0)
 into if (si1_12 == -104)

uh.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to work||4.4.2
   Last reconfirmed|-00-00 00:00:00 |2009-11-03 10:48:06
   date||
Summary|optimized code with -O2 or -|[4.5 Regression] optimized
   |O3 gives strange result |code with -O2 or -O3 gives
   ||strange result
   Target Milestone|--- |4.5.0


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



[Bug lto/41569] .../prev-gcc/xgcc used for the install step of the lto-plugin

2009-11-03 Thread rguenth at gcc dot gnu dot org


--- Comment #14 from rguenth at gcc dot gnu dot org  2009-11-03 10:57 
---
Not bootstrapping lto-plugin works around the problems.


-- 


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



[Bug libstdc++/41861] [C++0x] does not use monotonic_clock

2009-11-03 Thread paolo dot carlini at oracle dot com


--- Comment #2 from paolo dot carlini at oracle dot com  2009-11-03 11:22 
---
Chris??


-- 


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



[Bug c++/41921] Cross language don't work with typedef unnamed structs

2009-11-03 Thread rguenth at gcc dot gnu dot org


--- Comment #5 from rguenth at gcc dot gnu dot org  2009-11-03 11:46 ---
The C++ FE for

extern "C" { typedef struct {} CvImage; }

creates

  constant 8>
unit size  constant 1>
align 8 symtab 0 alias set -1 canonical type 0x76f3f790
fields 
nonlocal decl_4 VOID file t1.C line 2 col 20
align 1 context 
   >
full-name "struct CvImage"
X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown
chain >

thus, a named type.  The C frontend generates a named type with the
main-variant being an unnamed type.  The C++ frontend also assigns
different sizes to it.  C FE variant:

  constant 0>
unit size  constant 0>
align 8 symtab 0 alias set -1 canonical type 0x76eeab00
chain >

and its main-variant (which is also its canonical type):

  constant 0>
unit size  constant 0>
align 8 symtab 0 alias set -1 canonical type 0x76eeab00
chain >


While we could try hard to workaround this in LTO I think this is a
C++ frontend bug.  extern "C" should cause it to behave like the C
frontend.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
  Component|lto |c++
   Keywords||lto


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



[Bug c++/41921] Cross language don't work with typedef unnamed structs

2009-11-03 Thread rguenth at gcc dot gnu dot org


--- Comment #6 from rguenth at gcc dot gnu dot org  2009-11-03 12:15 ---
This also likely means that the pure C++ testcase

t1.C
-
struct {} a;

t2.C
-
typedef struct {} T;
extern T a;
void foo(void)
{
  a = T();
}


breaks.


-- 


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



[Bug c/35608] imit-structnest.c fails due to O(n^2) memory usage in record_component_alias

2009-11-03 Thread bonzini at gnu dot org


--- Comment #8 from bonzini at gnu dot org  2009-11-03 12:18 ---
Memory allocation is O(n^2) in the nesting of the structures: when changing
LIM4 from 6 to 7 invocations of the lower-level, memory goes from 583976 KB to
798116 KB (which is 1.366 times more, almost exactly a factor of (7/6)^2).

The culprit is record_component_aliases which creates a subset relationship
from each structure to each containing structure.  Maybe we could reuse the
et-forest here since these subset relationships form a forest (do all of them
have this property? would we pessimize a lot by enforcing that even when it is
conservative?)

I suppose the bug has always been there since alias.c was introduced, it's just
that previously an unused struct did not call record_component_aliases.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||compile-time-hog, memory-hog
   Last reconfirmed|-00-00 00:00:00 |2009-11-03 12:18:41
   date||
Summary|gcc.c-  |imit-structnest.c fails due
   |torture/compile/limits- |to O(n^2) memory usage in
   |structnest.c fails -O2 -Os  |record_component_alias


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



[Bug c/35608] imit-structnest.c fails due to O(n^2) memory usage in record_component_alias

2009-11-03 Thread rguenther at suse dot de


--- Comment #9 from rguenther at suse dot de  2009-11-03 12:21 ---
Subject: Re:  imit-structnest.c fails due to O(n^2) memory usage
 in record_component_alias

On Tue, 3 Nov 2009, bonzini at gnu dot org wrote:

> --- Comment #8 from bonzini at gnu dot org  2009-11-03 12:18 ---
> Memory allocation is O(n^2) in the nesting of the structures: when changing
> LIM4 from 6 to 7 invocations of the lower-level, memory goes from 583976 KB to
> 798116 KB (which is 1.366 times more, almost exactly a factor of (7/6)^2).
> 
> The culprit is record_component_aliases which creates a subset relationship
> from each structure to each containing structure.  Maybe we could reuse the
> et-forest here since these subset relationships form a forest (do all of them
> have this property? would we pessimize a lot by enforcing that even when it is
> conservative?)

Yes, they all form a forest.  It shouldn't pessimize anything to enforce
this.

> I suppose the bug has always been there since alias.c was introduced, it's 
> just
> that previously an unused struct did not call record_component_aliases.

Right.

Richard.


-- 


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



[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

2009-11-03 Thread bonzini at gnu dot org


--- Comment #8 from bonzini at gnu dot org  2009-11-03 12:23 ---
Created an attachment (id=18953)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18953&action=view)
patch to fix the bug

The attached patches together reduce the stack usage of expression parsing by
~30%.  On a 64-bit machine with 8 MB the parsing now fails after 10300
recursions instead of 7100.

This still means that one pair of parentheses consumes about 100 words on the
stack.


-- 


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



[Bug lto/41569] .../prev-gcc/xgcc used for the install step of the lto-plugin

2009-11-03 Thread bonzini at gnu dot org


--- Comment #15 from bonzini at gnu dot org  2009-11-03 12:24 ---
I still want to look into it, at least we have a workaround.  


-- 


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



[Bug lto/41569] .../prev-gcc/xgcc used for the install step of the lto-plugin

2009-11-03 Thread bonzini at gnu dot org


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-10-26 12:25:12 |2009-11-03 12:24:40
   date||


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



[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement

2009-11-03 Thread paolo dot carlini at oracle dot com


--- Comment #45 from paolo dot carlini at oracle dot com  2009-11-03 12:37 
---
Created an attachment (id=18954)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18954&action=view)
Second draft, regtests fine

Ok, this version works, I fixed it to use _GLIBCXX_MOVE3 in one case and
_GLIBCXX_MOVE_BACKWARD3 in the other. My benchmarks are fine for simple types,
like ints, I think we should just go ahead, close the PR, and maybe think about
a more general solution optimized for k small, not just 1. But there is no
hurry, definitely. In my opinion, for 4.5.0 it's more urgent to audit the
library vs std::swap, ie, the stable_partition case, but really David, if we
come to that make sure to be all set about building / testing mainline, etc.


-- 


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



[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement

2009-11-03 Thread paolo dot carlini at oracle dot com


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC|paolo dot carlini at oracle |
   |dot com |
 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|NEW |ASSIGNED


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



[Bug c++/38699] [4.3/4.4/4.5 regression] ICE using offsetof with pointer and array accesses

2009-11-03 Thread dodji at gcc dot gnu dot org


--- Comment #14 from dodji at gcc dot gnu dot org  2009-11-03 13:20 ---
Subject: Bug 38699

Author: dodji
Date: Tue Nov  3 13:20:08 2009
New Revision: 153848

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153848
Log:
Move builtin-offsetof.c test

PR c++/38699
* c-c++-common/dfp/builtin-offsetof.c: Moved to ...
* c-c++-common/builtin-offsetof.c: ... here.

Added:
trunk/gcc/testsuite/c-c++-common/builtin-offsetof.c
  - copied, changed from r153846,
trunk/gcc/testsuite/c-c++-common/dfp/builtin-offsetof.c
Removed:
trunk/gcc/testsuite/c-c++-common/dfp/builtin-offsetof.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/39934] Union member incorrectly disallowed

2009-11-03 Thread redi at gcc dot gnu dot org


--- Comment #3 from redi at gcc dot gnu dot org  2009-11-03 13:32 ---
(In reply to comment #2)
> 
> Is there a sane workaround for this?

Don't use 'const' members of unions.

Union members cannot have a non-trivial copy assignment operator.
The assignment operator for A cannot be implicitly defined, as the const member
would make the program ill-formed.
I'm not sure whether using A in a union causes the implicitly-declared copy
assignment operator to be implicitly defined, but that seems to be what's
happening.


-- 


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



[Bug testsuite/41856] g++.dg/lookup/extern-c-redecl[3,4] .C should be target specific

2009-11-03 Thread dodji at gcc dot gnu dot org


--- Comment #16 from dodji at gcc dot gnu dot org  2009-11-03 13:47 ---
Subject: Bug 41856

Author: dodji
Date: Tue Nov  3 13:46:46 2009
New Revision: 153851

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153851
Log:
Fix PR c++/41856

PR c++/41856
* g++.dg/lookup/extern-c-redecl3.C: Make the test x86 only.
* g++.dg/lookup/extern-c-redecl4.C: Likewise.

Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/lookup/extern-c-redecl3.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/lookup/extern-c-redecl4.C


-- 


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



[Bug c++/39934] Union member incorrectly disallowed

2009-11-03 Thread terra at gnome dot org


--- Comment #4 from terra at gnome dot org  2009-11-03 13:47 ---
> I'm not sure whether using A in a union causes the implicitly-declared copy
> assignment operator to be implicitly defined, but that seems to be what's
> happening.

No, that's not quite it.

The requirement for union members is that there cannot be a non-trivial copy
assignment operator.

gcc uses a different rule: it insists that there be a default copy assignment
operator.

Presumably someone thought those two formulations were the same.  But they
are not: struct A doesn't have a copy assignment operator at all.

For the record, this kind of code occurs fairly naturally in C when creating
trees with different node types, tagged here by "x". The problems arise when
C++ code needs to interface with that C code.


-- 


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



[Bug libstdc++/41861] [C++0x] does not use monotonic_clock

2009-11-03 Thread cfairles at gcc dot gnu dot org


--- Comment #3 from cfairles at gcc dot gnu dot org  2009-11-03 13:58 
---
Yes, I'm alive! Starting to get back into the GCC swing of things.

Ok,  and  and clocks. Its a bit of a tricky
situation, reading current standard draft and other related docs (i.e. posix)
to get myself back up to speed. In my preliminary investigations there seems to
be some issues in assuming what "epoch" means when using gthreads and what we
assume is a "known" clock.

I think condition_variable is more correct than mutex using system_clock as its
"known" clock. Currently mutex doesn't attempt "sync" unknown clocks to a known
clock in its *_until/for functions like condition_variable. This could
potentially be an issue for gthread implementations (and posix implementations
for that matter) where the epoch for system_clock, monotonic and high_res
clocks are all different (let alone user-defined clocks).

So, in condition_variable at least, the assumption is the system_clock epoch
(system_clock::time_point()) == gthread's expected epoch.

Taking the assumption that system_clock::time_point() == gthread's epoch, in
mutex, it erroneously assumes that monotic_clock::time_point() ==
system_clock::time_point() but a quick reading of the POSIX docs shows:

"For [the monotonic] clock, the value returned by clock_gettime() represents
the amount of time (in seconds and nanoseconds) since an unspecified point in
the past (for example, system start-up time, or the Epoch)."
(http://www.opengroup.org/onlinepubs/009695399/functions/clock_gettime.html)

For the POSIX gthread_cond* implementation, the POSIX standard suggests that,
if Clock Selection is available you should set the appropriate condition
attribute (ex. pthread_condattr_setclock if available).

For mutexes (from pthread_mutex_timedlock), 
"If the Timers option is supported, the timeout shall be based on the
CLOCK_REALTIME clock; if the Timers option is not supported, the timeout shall
be based on the system clock as returned by the time() function."

This almost exactly describes system_clock other than the fact that it might
use gettimeofday before using time() (i.e. std::time()), which is still
realative to the POSIX epoch so I think thats ok ... for posix gthreads impl.

Long story short, using monotonic_clock as a "known" clock in *mutex* is almost
certainly incorrect since, in POSIX, its absolute value is meaningless (epoch
is arbitrary). It would be more correct to sync the monotonic_clock to
system_clock like condition_varaible does.

30.2.4p4 says implementations should use a monotonic clock for the *_for
functions that take a relative time. Unfortunately, gthreads (and its POSIX
impl) use absolute time and assumes times are relative to the POSIX epoch.

Let me do a bit more research and poke Howard H. again for some clarification
on this before moving forward.

Chris


-- 


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



[Bug c++/39934] Union member incorrectly disallowed

2009-11-03 Thread redi at gcc dot gnu dot org


--- Comment #5 from redi at gcc dot gnu dot org  2009-11-03 14:21 ---
(In reply to comment #4)
> > I'm not sure whether using A in a union causes the implicitly-declared copy
> > assignment operator to be implicitly defined, but that seems to be what's
> > happening.
> 
> No, that's not quite it.
> 
> The requirement for union members is that there cannot be a non-trivial copy
> assignment operator.
>
> gcc uses a different rule: it insists that there be a default copy assignment
> operator.
>
> Presumably someone thought those two formulations were the same.

Use the source, Luke:

  if (TYPE_HAS_COMPLEX_ASSIGN_REF (type))
error ("member %q+#D with copy assignment operator not allowed in
union"
,
   field);

/* Nonzero if there is a user-defined X::op=(x&) for this class.  */
#define TYPE_HAS_COMPLEX_ASSIGN_REF(NODE) (LANG_TYPE_CLASS_CHECK
(NODE)->has_com
plex_assign_ref)

Now there could be a bug there, but it superficially looks right, and does not
look as though anyone thought the two formulations are the same. 

>  But they
> are not: struct A doesn't have a copy assignment operator at all.

It might not be defined, but one is declared, according to [class.copy]/10
"If the class definition does not explicitly declare a copy assignment
operator, one is declared implicitly."


> For the record, this kind of code occurs fairly naturally in C when creating
> trees with different node types, tagged here by "x". The problems arise when
> C++ code needs to interface with that C code.

The fact there are problems doesn't mean g++ is wrong.


-- 


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



[Bug c++/41884] diagnostics: error vs. context

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #2 from jason at gcc dot gnu dot org  2009-11-03 14:36 ---
Created an attachment (id=18955)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18955&action=view)
better patch

This one actually tests cleanly.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #18952|0   |1
is obsolete||


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



[Bug c++/41884] diagnostics: error vs. context

2009-11-03 Thread jason at gcc dot gnu dot org


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-03 14:38:07
   date||


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



[Bug c++/41884] diagnostics: error vs. context

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #3 from jason at gcc dot gnu dot org  2009-11-03 14:39 ---
This patch leaves the includes and the inner context (function or class
instantiation) above the error, but moves all the other includes after the
error.  How does it look to you?


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


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



[Bug c++/41884] diagnostics: error vs. context

2009-11-03 Thread paolo dot carlini at oracle dot com


--- Comment #4 from paolo dot carlini at oracle dot com  2009-11-03 14:42 
---
Thanks Jason for working on this. I want to play with the patch, but give me
say half a day at least, maybe in the meanwhile Benjamin can also start
experimenting a bit with it...


-- 


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



[Bug c++/41884] diagnostics: error vs. context

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #5 from jason at gcc dot gnu dot org  2009-11-03 14:45 ---
(In reply to comment #3)
> but moves all the other includes after the error.

Er, "all the other instantiations".


-- 


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



[Bug libffi/41923] New: libffi.call/testclosure.c failed on Linux/x86-64

2009-11-03 Thread hjl dot tools at gmail dot com
On Linux/x86-64, I got

FAIL: libffi.call/testclosure.c -O0 -W -Wall output pattern test, is 4 5 0 0
FAIL: libffi.call/testclosure.c -O2 -fomit-frame-pointer output pattern test,
is 4 5 0 0
FAIL: libffi.call/testclosure.c -O2 output pattern test, is 4 5 0 0
FAIL: libffi.call/testclosure.c -O3 output pattern test, is 4 5 0 0
FAIL: libffi.call/testclosure.c -Os output pattern test, is 4 5 0 0


-- 
   Summary: libffi.call/testclosure.c failed on Linux/x86-64
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libffi
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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



[Bug middle-end/41924] New: graphite miscompiles aermod

2009-11-03 Thread lifeng at gcc dot gnu dot org
http://www.polyhedron.com/web_images/documents/pb05.zip
the testers report this:
aermod FAILED1 fails and5 passes
[...]
Finished Testing  16 benchmarks -  15 passed, and   1 failed

--
I have reduced the aermod problem in polyhedron benchmark.
It seems that the cloog generate the wrong code for a simple
case...

---Reduced fortran code
MODULE MAIN1
 REAL , ALLOCATABLE :: HRVALD(:)
END MODULE MAIN1

SUBROUTINE VOLCALC()
 USE MAIN1
 INTEGER :: ITYP
 LOGICAL :: WETSCIM

 DO ITYP = 1 , 100
IF ( WETSCIM ) HRVALD(ITYP) = 0.0
 ENDDO
END SUBROUTINE VOLCALC
-
Equivalent C code
int hrval[101];

void volcalc()
{
 int i;
 int wetscim;

 for (i = 0; i < 100; i++)
   if (wetscim)
 hrval[i] = 0;
}
--
(gdb) set debug_generated_program (scop)

if (wetscim_3 <= -1) {
 for (scat_1=0;scat_1<=99;scat_1++) {
   S4(scat_1) ;
 }
}
if (wetscim_3 >= 1) {
 for (;;scat_1++) {
   for (git_0=0;git_0<=99;git_0++) {
 S4(git_0) ;
   }
 }
}

(gdb) set debug_scop (scop)
scop (
parameters (
p_0 -> wetscim_3(D)
)
context (
#  eq p0cst
0 3
)
pbb_4 (
conditions bb_4 (if (wetscim_3(D) != 0)
)
cases bb_4 (if (wetscim_3(D) != 0)
)
pdr_0 (write
(Data Ref:
 stmt: hrval[i_11] = 0;
 ref: hrval[i_11];
 base_object: hrval[0];
 Access function 0: {0, +, 1}_1
)
data accesses (
#  eq i0 p0  alias   sub0cst
4 6
   0  1  0  0 -1  0
   0  0  0  1  0 -1
   1 -1  0  0  0100
   1  1  0  0  0  0
)
)
domains bb_4 (
#  eq i0 p0cst
3 4
   1 -1  0 99
   1  1  0  0
   1  0 -1 -1
3 4
   1 -1  0 99
   1  1  0  0
   1  0  1 -1
)
scattering bb_4 (
#  eq s0 s1 s2 i0 p0cst
3 7
   0  1  0  0  0  0  0
   0  0  1  0 -1  0  0
   0  0  0  1  0  0  0
)
)
original_lst (
(root
 0 (loop
   0 stmt_4)))
transformed_lst (
(root
 0 (loop
   0 stmt_4)))
)


-- 
   Summary: graphite miscompiles aermod
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lifeng at gcc dot gnu dot org


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



[Bug libstdc++/41861] [C++0x] does not use monotonic_clock

2009-11-03 Thread cfairles at gcc dot gnu dot org


--- Comment #4 from cfairles at gcc dot gnu dot org  2009-11-03 15:26 
---
See also:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#887
http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#887


-- 


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



[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement

2009-11-03 Thread paolo dot carlini at oracle dot com


--- Comment #46 from paolo dot carlini at oracle dot com  2009-11-03 15:33 
---
Created an attachment (id=18956)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18956&action=view)
Third draft, also regtests fine

This version restricts the copies to "simple" types (per your initial idea,
here scalar types, similarly to std::fill, but more general types could be also
added) and sets up some general infrastructure for optimizing k > 1 too. Maybe
you like it better, I don't think we want to go much more beyond this, for
4.5.0.


-- 


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



[Bug testsuite/41878] [4.5 Regression] ERROR: gfortran.dg/vect/vect-2.f90

2009-11-03 Thread hjl dot tools at gmail dot com


--- Comment #3 from hjl dot tools at gmail dot com  2009-11-03 15:36 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug libstdc++/41861] [C++0x] does not use monotonic_clock

2009-11-03 Thread paolo dot carlini at oracle dot com


--- Comment #5 from paolo dot carlini at oracle dot com  2009-11-03 15:37 
---
Thanks for your feedback Chris. Gosh, that issue, quite a bit of time spent in
Santa Cruz, Detlef arguing was not implementable and Howard disagreeing...


-- 


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



[Bug middle-end/41925] New: ICE in get_alias_set, at alias.c:710

2009-11-03 Thread rguenth at gcc dot gnu dot org
> ./xgcc -B. -w -m32 -c -flto -O2 usrmarshal.min.i ole32_objidl_p.min.i 
> defaulthandler.min.i clipboard.min.i
> ./lto1 -quiet -o /dev/null -m32 -O2 -w clipboard.min.o defaulthandler.min.o 
> ole32_objidl_p.min.o usrmarshal.min.o
In file included from clipboard.min.i:153:0,
 from :0:
defaulthandler.min.i: In function 'DefaultHandler_EnumDAdvise':
defaulthandler.min.i:95:35: internal compiler error: in get_alias_set, at
alias.c:710
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE in get_alias_set, at alias.c:710
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: lto
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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



[Bug middle-end/41925] ICE in get_alias_set, at alias.c:710

2009-11-03 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2009-11-03 15:54 ---
Created an attachment (id=18957)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18957&action=view)
testcase

Auto-reduced testcase.


-- 


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



[Bug tree-optimization/41919] [4.5 Regression] optimized code with -O2 or -O3 gives strange result

2009-11-03 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2009-11-03 16:05 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-11-03 10:48:06 |2009-11-03 16:05:48
   date||


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



[Bug c++/40687] [C++0x]: error with auto and 7.1.6.4/7 in N2914

2009-11-03 Thread jason at gcc dot gnu dot org


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-07-14 18:50:44 |2009-11-03 16:08:23
   date||


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



[Bug c++/38796] [c++0x] defaulted operator= with non-default return type accepted

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #4 from jason at gcc dot gnu dot org  2009-11-03 16:09 ---
Fixed for 4.5.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug c++/41921] Cross language don't work with typedef unnamed structs

2009-11-03 Thread pinskia at gcc dot gnu dot org


--- Comment #7 from pinskia at gcc dot gnu dot org  2009-11-03 16:16 ---
Note the original testcase did not have an empty struct (which is the cause of
the different sizes).


-- 


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



[Bug c++/40944] [C++0x] rejects well-formed code: SFINAE, decltype, function call

2009-11-03 Thread jason at gcc dot gnu dot org


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-03 16:21:06
   date||


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



[Bug c++/41672] [C++0x] missing diagnostic on an ill-formed rvalue reference initialization

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #2 from jason at gcc dot gnu dot org  2009-11-03 16:21 ---
No, I'm not planning to fix this in 4.4.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug tree-optimization/41919] [4.5 Regression] optimized code with -O2 or -O3 gives strange result

2009-11-03 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2009-11-03 16:25 ---
Jeff promised to look at this.  I can't make sense of test_for_singularity
and the appearant mismatch of EQ_EXPR vs. NE_EXPR when generating the
test substitution.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rguenth at gcc dot gnu dot  |law at gcc dot gnu dot org
   |org |


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



[Bug c++/41815] [C++0x] GCC wrongly treats rvalues of non-class type cv-qualified

2009-11-03 Thread jason at gcc dot gnu dot org


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-03 16:38:27
   date||


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



[Bug middle-end/41926] New: internal compiler error: verify_ssa failed

2009-11-03 Thread jv244 at cam dot ac dot uk
compiling with current trunk:

MODULE hfx_contract_block
  INTEGER, PARAMETER :: dp=KIND(0.0D0)
CONTAINS
  SUBROUTINE block_4_1_1_1(kbd,kbc,kad,kac,pbd,pbc,pad,pac,prim,scale)
REAL(KIND=dp) :: kbd(1*1), kbc(1*1), kad(4*1), kac(4*1), pbd(1*1), &
  pbc(1*1), pad(4*1), pac(4*1), prim(4*1*1*1), scale
INTEGER  :: ma, mb, mc, md, p_index
REAL(KIND=dp):: ks_bc, ks_bd, p_bc, p_bd, tmp
  DO md = 1,1
DO mc = 1,1
  DO mb = 1,1
DO ma = 1,4
  p_index=p_index+1
  tmp = scale*prim(p_index)
  kad((md-1)*4+ma) =  kad((md-1)*4+ma)-tmp*p_bc
  kac((mc-1)*4+ma) = kac((mc-1)*4+ma)-tmp*p_bd
END DO
  END DO
END DO
  END DO
  END SUBROUTINE block_4_1_1_1
END MODULE hfx_contract_block

leads to

gfortran -c -g -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native
-ffree-form bug.f90
bug.f90: In function ‘block_4_1_1_1’:
bug.f90:4:0: error: definition in block 8 does not dominate use in block 14
for SSA_NAME: p_index_17 in statement:
# DEBUG p_index => p_index_17
bug.f90:4:0: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

more details:
arget: x86_64-unknown-linux-gnu
Configured with: /data03/vondele/gcc_trunk/gcc/configure --disable-bootstrap
--prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran
--disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/
--with-cloog=/data03/vondele/gcc_trunk/build/
--with-libelf=/data03/vondele/libelf-0.8.12/build/ --enable-gold --enable-lto
--enable-plugins
Thread model: posix
gcc version 4.5.0 20091103 (experimental) [trunk revision 153852] (GCC) 
COLLECT_GCC_OPTIONS='-c' '-g' '-O2' '-ffast-math' '-funroll-loops'
'-ffree-form' '-v' '-mtune=generic'

/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951
bug.f90 -quiet -dumpbase bug.f90 -mtune=generic -auxbase bug -g -O2 -version
-ffast-math -funroll-loops -ffree-form -fintrinsic-modules-path
/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude
-o /tmp/ccVISL4z.s


-- 
   Summary: internal compiler error: verify_ssa failed
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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



[Bug tree-optimization/41919] [4.5 Regression] optimized code with -O2 or -O3 gives strange result

2009-11-03 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2009-11-03 16:41 ---
I'll take it back as I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|law at gcc dot gnu dot org  |rguenth at gcc dot gnu dot
   ||org


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



[Bug middle-end/41926] [4.5 Regression][VTA] internal compiler error: verify_ssa failed

2009-11-03 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2009-11-03 16:48 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-03 16:48:03
   date||
Summary|internal compiler error:|[4.5 Regression][VTA]
   |verify_ssa failed   |internal compiler error:
   ||verify_ssa failed
   Target Milestone|--- |4.5.0


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



[Bug fortran/41907] [4.5 Regression] 465.tonto in SPEC CPU 2006 runtime failure

2009-11-03 Thread burnus at gcc dot gnu dot org


--- Comment #6 from burnus at gcc dot gnu dot org  2009-11-03 16:52 ---
Subject: Bug 41907

Author: burnus
Date: Tue Nov  3 16:51:52 2009
New Revision: 153854

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153854
Log:
2009-11-03  Tobias Burnus  

PR fortran/41907
* trans-expr.c (gfc_conv_procedure_call): Fix presence check
for optional arguments.

2009-11-03  Tobias Burnus  

PR fortran/41907
* gfortran.dg/missing_optional_dummy_6.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug fortran/41907] [4.5 Regression] 465.tonto in SPEC CPU 2006 runtime failure

2009-11-03 Thread burnus at gcc dot gnu dot org


--- Comment #7 from burnus at gcc dot gnu dot org  2009-11-03 16:55 ---
FIXED. Thanks for the report!

 * * *

> The problem is that gfortran copies for some reason the array descriptor in
> "one()" before calling "two()". The question is only why?

I understand now the "why"; it is a missed optimization - tracked in PR 41911.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug fortran/41907] [4.5 Regression] 465.tonto in SPEC CPU 2006 runtime failure

2009-11-03 Thread jv244 at cam dot ac dot uk


--- Comment #8 from jv244 at cam dot ac dot uk  2009-11-03 16:57 ---
thanks for fixing.. this also affected CP2K.


-- 


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



[Bug c++/40687] [C++0x]: error with auto and 7.1.6.4/7 in N2914

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #4 from jason at gcc dot gnu dot org  2009-11-03 17:11 ---
Subject: Bug 40687

Author: jason
Date: Tue Nov  3 17:11:08 2009
New Revision: 153855

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153855
Log:
PR c++/40687
* pt.c (do_auto_deduction): Diagnose inconsistent deduction.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/auto3.C


-- 


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



[Bug c++/40944] [C++0x] rejects well-formed code: SFINAE, decltype, function call

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #4 from jason at gcc dot gnu dot org  2009-11-03 17:11 ---
Subject: Bug 40944

Author: jason
Date: Tue Nov  3 17:11:18 2009
New Revision: 153856

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153856
Log:
PR c++/40944
* call.c (initialize_reference): Add complain parm.
* typeck.c (convert_for_initialization): Pass it.
* decl.c (grok_reference_init): Likewise.
* cp-tree.h: Declare it.

Added:
trunk/gcc/testsuite/g++.dg/template/sfinae15.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/41927] New: [C++0x] Spurious warning with enable_if and efault function template argument

2009-11-03 Thread paolo dot carlini at oracle dot com
This issue is very annoying, triggers in many places in the C++0x library, is
not suppressed in system headers. Just compile the below with -std=c++0x and
-Wall. Jason, any chance you can have a look?

template
  struct is_int
  { static const bool value = true; };  

template
  struct enable_if 
  { };

template
  struct enable_if
  { typedef Tp type; };

template
  struct duration
  {
duration() { }

template::value)>::type>
duration(const duration&) { }
  };

int main()
{
  duration d0;
  duration d1 = d0;
}


-- 
   Summary: [C++0x] Spurious warning with enable_if and efault
function template argument
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com


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



[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement

2009-11-03 Thread potswa at mac dot com


--- Comment #47 from potswa at mac dot com  2009-11-03 17:21 ---
What is the function of the helper class? I suppose the user could get improved
performance by specializing __is_scalar, but that could have
unintended consequences (resulting from the class not being scalar), not to
mention that the user is then modifying nonstandard internals. Furthermore, we
care more about whether it's POD than scalar.

Why not adapt or add a general interface to the test used by __copy_move* in
stl_algo.h?

  const bool __simple = (__is_pod(_ValueTypeI)
 && __is_pointer<_II>::__value
 && __is_pointer<_OI>::__value
 && __are_same<_ValueTypeI, _ValueTypeO>::__value);

This seems to capture the requirements of memmove… although using copy/move
instead of swap should also be faster for large PODs in eg linked lists.

Anyway, __is_pod being reasonably sufficient for compliant behavior wrt
"complexity of a swap" being known, couldn't we just take patch_draft_2 and
substitute in

  if ( __is_pod(_ValueType) && __k == 1)

I favor this alternative.


-- 


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



[Bug c++/41876] [4.3/4.4/4.5 regression] Parse problems with catch

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #3 from jason at gcc dot gnu dot org  2009-11-03 21:53 ---
Subject: Bug 41876

Author: jason
Date: Tue Nov  3 21:52:56 2009
New Revision: 153873

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153873
Log:
PR c++/41876
* parser.c (cp_parser_exception_declaration): Pass true to
is_condition parm of cp_parser_type_specifier_seq.


Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/parse/eh-decl.C
  - copied unchanged from r153872,
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/parse/eh-decl.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/parser.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement

2009-11-03 Thread paolo dot carlini at oracle dot com


--- Comment #49 from paolo dot carlini at oracle dot com  2009-11-03 17:36 
---
By the way, it's really silly to have code used only for copy-able types (like
scalars or pods) and having to use the *_MOVE* macros only for compilation
sake, in such cases it's normally much cleaner to have the thing inside a
template instantiated on demand.


-- 


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



[Bug rtl-optimization/41928] New: segfault at gcc/bitmap.c:297

2009-11-03 Thread jv244 at cam dot ac dot uk
the attached code causes the compiler to segfault as:

Program received signal SIGSEGV, Segmentation fault.
bitmap_clear (head=0x78) at /data03/vondele/gcc_trunk/gcc/gcc/bitmap.c:297
297   if (head->first)
(gdb) bt
#0  bitmap_clear (head=0x78) at /data03/vondele/gcc_trunk/gcc/gcc/bitmap.c:297
#1  0x00738265 in move_loop_invariants () at
/data03/vondele/gcc_trunk/gcc/gcc/loop-invariant.c:1568
#2  0x00734e8d in rtl_move_loop_invariants () at
/data03/vondele/gcc_trunk/gcc/gcc/loop-init.c:254
#3  0x00770fd4 in execute_one_pass (pass=0x11c1480) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:1518
#4  0x007711e5 in execute_pass_list (pass=0x11c1480) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:1567
#5  0x007711fd in execute_pass_list (pass=0x11c1360) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:1568
#6  0x007711fd in execute_pass_list (pass=0x1242580) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:1568
#7  0x0086c0e1 in tree_rest_of_compilation (fndecl=0x7fdb5deb3d00) at
/data03/vondele/gcc_trunk/gcc/gcc/tree-optimize.c:392
#8  0x009e806d in cgraph_expand_function (node=0x7fdb5ddc8300) at
/data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1160
#9  0x009eaa24 in cgraph_optimize () at
/data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1219
#10 0x009eb3ad in cgraph_finalize_compilation_unit () at
/data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1089
#11 0x0073325d in write_global_declarations () at
/data03/vondele/gcc_trunk/gcc/gcc/langhooks.c:309
#12 0x0081781e in toplev_main (argc=27, argv=0x7fff67e09dc8) at
/data03/vondele/gcc_trunk/gcc/gcc/toplev.c:1061

when compiled with:

gfortran  -c -O1 -march=native -g -ffree-form -fbounds-check

more details:

> gfortran  -c -O1 -march=native -g -ffree-form -fbounds-check -v bug.f90 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /data03/vondele/gcc_trunk/gcc/configure --disable-bootstrap
--prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran
--disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/
--with-cloog=/data03/vondele/gcc_trunk/build/
--with-libelf=/data03/vondele/libelf-0.8.12/build/ --enable-gold --enable-lto
--enable-plugins
Thread model: posix
gcc version 4.5.0 20091103 (experimental) [trunk revision 153852] (GCC) 
COLLECT_GCC_OPTIONS='-c' '-O1'  '-g' '-ffree-form' '-fbounds-check' '-v'

/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951
bug.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param
l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase
bug.f90 -auxbase bug -g -O1 -version -ffree-form -fbounds-check
-fintrinsic-modules-path
/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude
-o /tmp/ccSGzPfe.s
GNU Fortran (GCC) version 4.5.0 20091103 (experimental) [trunk revision 153852]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.1 20080507 (prerelease) [gcc-4_3-branch
revision 135036], GMP version 4.2.2, MPFR version 2.3.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.5.0 20091103 (experimental) [trunk revision 153852]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.1 20080507 (prerelease) [gcc-4_3-branch
revision 135036], GMP version 4.2.2, MPFR version 2.3.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
bug.f90: In function ‘moment’:
bug.f90:124:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: segfault at gcc/bitmap.c:297
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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



[Bug c++/39934] Union member incorrectly disallowed

2009-11-03 Thread paolo dot carlini at oracle dot com


--- Comment #7 from paolo dot carlini at oracle dot com  2009-11-03 17:49 
---
Saying that ARM is "wrong" seems frankly rather silly to me: either the
quotation is incorrect, I don't think so, or ARM has been obsoleted by the ISO
Standard, perfectly possible.


-- 


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



[Bug rtl-optimization/41928] [4.5 Regression] segfault at gcc/bitmap.c:297

2009-11-03 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|segfault at gcc/bitmap.c:297|[4.5 Regression] segfault at
   ||gcc/bitmap.c:297
   Target Milestone|--- |4.5.0


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



[Bug rtl-optimization/41903] [4.5 Regression] Segmentation fault in bitmap_clear

2009-11-03 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|c   |rtl-optimization
   Keywords||ice-on-valid-code
Summary|Segmentation fault in   |[4.5 Regression]
   |bitmap_clear|Segmentation fault in
   ||bitmap_clear
   Target Milestone|--- |4.5.0


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



[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement

2009-11-03 Thread paolo dot carlini at oracle dot com


--- Comment #48 from paolo dot carlini at oracle dot com  2009-11-03 17:32 
---
In general, the user certainly cannot specialize anything, this is internal
stuff, with __ in front. Also, I'm not in favor of general podness, because a
pod can be large, any size, see the example of fill, we want the temporary to
fit in a register or something similar. About k, we aren't doing so well for k
small, I think we should prepare for k > 1, but if you think it's impossible
any time soon, I'm also ok with simplifying things to k == 1 and __is_scalar.


-- 


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



[Bug rtl-optimization/41928] [4.5 Regression] segfault at gcc/bitmap.c:297

2009-11-03 Thread jv244 at cam dot ac dot uk


--- Comment #2 from jv244 at cam dot ac dot uk  2009-11-03 18:06 ---
Created an attachment (id=18958)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18958&action=view)
testcase


-- 


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



[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement

2009-11-03 Thread potswa at mac dot com


--- Comment #50 from potswa at mac dot com  2009-11-03 17:53 ---
The current RAI algo uses a temporary regardless of size or class. We could put
in a "&& sizeof(_ValueType) < __MAX_TEMP_SIZE" or something… but stack overflow
from a single temporary doesn't seem to have been concern in the past.

I don't see how being register-size in particular is important. If we were
swapping the temporary every time, we would want it to fit in a reasonable
number of registers so the compiler could optimize out read-after-writes. But
the __tmp here is only written and read once. The larger it is, the more
acceleration.

Proposed performance is very good with k small > 1, compared to current. Using
memmove is simply even faster. It's not clear such rotate operations are
popular enough to warrant a framework for optimization, though.

If we assure it's a non-move type then I also favor reverting out the
_GLIBCXX_MOVE[3]().


-- 


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



[Bug libffi/41908] closures fail for some structure arguments containing floats

2009-11-03 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2009-11-03 17:46 ---
*** Bug 41923 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement

2009-11-03 Thread paolo at gcc dot gnu dot org


--- Comment #52 from paolo at gcc dot gnu dot org  2009-11-03 18:16 ---
Subject: Bug 41351

Author: paolo
Date: Tue Nov  3 18:16:34 2009
New Revision: 153860

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153860
Log:
2009-11-03  David Krauss  
Paolo Carlini  

PR libstdc++/41351
* include/bits/stl_algo.h (__rotate(_RandomAccessIterator,
_RandomAccessIterator, _RandomAccessIterator,
random_access_iterator_tag)): Rewrite to use only std::swap in
general and std::copy/std::copy_backward when safe.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algo.h


-- 


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



[Bug rtl-optimization/41928] segfault at gcc/bitmap.c:297

2009-11-03 Thread jv244 at cam dot ac dot uk


--- Comment #1 from jv244 at cam dot ac dot uk  2009-11-03 17:53 ---
might be a dup of PR41903 or PR41891. However, I might have a reasonably sized
testcase (delta still running).


-- 


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



[Bug c++/21498] [c++0x] friend declaration can name non-class with class-key

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #14 from jason at gcc dot gnu dot org  2009-11-03 18:40 ---
In C++0x the testcase is still ill-formed, but changing "friend class" to
"friend typename" makes it well-formed.  I'm not going to give an error for
this usage until the other usage is implemented.

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1791.pdf


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[c++0x] clause 7.1.5.3/2 of |[c++0x] friend declaration
   |the c++ is not enforced |can name non-class with
   ||class-key


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



[Bug middle-end/41924] graphite miscompiles aermod

2009-11-03 Thread spop at gcc dot gnu dot org


--- Comment #1 from spop at gcc dot gnu dot org  2009-11-04 02:03 ---
What are the options that you used to produce this?
I am not able to reproduce the failing clast with -O2, nor with -O3 with the
current graphite branch.


-- 


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



[Bug c++/41815] [C++0x] GCC wrongly treats rvalues of non-class type cv-qualified

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #1 from jason at gcc dot gnu dot org  2009-11-03 18:43 ---
Subject: Bug 41815

Author: jason
Date: Tue Nov  3 18:42:59 2009
New Revision: 153862

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153862
Log:
PR c++/41815
* call.c (build_call_a): Strip cv-quals from rvalue result.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/rv-return.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/deduce.C


-- 


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



[Bug c++/41927] [C++0x] Spurious warning with enable_if and default function template argument

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #2 from jason at gcc dot gnu dot org  2009-11-03 18:44 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug target/41930] New: [4.5 regression] cc1 SEGV compiling maxval_r16.c

2009-11-03 Thread ro at gcc dot gnu dot org
Between 20091005 and 20091102, bootstrapping Tru64 UNIX V5.1B started to fail
in
libgfortan:

$ /vol/gcc/obj/gcc-4.5.0-20091102/5.1b-gcc/./gcc/xgcc
-B/vol/gcc/obj/gcc-4.5.0-20091102/5.1b-gcc/./gcc/
-B/vol/gcc/alpha-dec-osf5.1b/bin/ -B/vol/gcc/alpha-dec-osf5.1b/lib/ -isystem
/vol/gcc/alpha-dec-osf5.1b/include -isystem
/vol/gcc/alpha-dec-osf5.1b/sys-include -DHAVE_CONFIG_H -I.
-I/vol/gcc/src/gcc-dist/libgfortran -iquote/vol/gcc/src/gcc-dist/libgfortran/io
-I/vol/gcc/src/gcc-dist/libgfortran/../gcc
-I/vol/gcc/src/gcc-dist/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE
-std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -mieee
-MT maxval_r16.lo -MD -MP -MF .deps/maxval_r16.Tpo -c
/vol/gcc/src/gcc-dist/libgfortran/generated/maxval_r16.c  -DPIC -o
.libs/maxval_r16.o
/vol/gcc/src/gcc-dist/libgfortran/generated/maxval_r16.c: In function
'mmaxval_r16':
/vol/gcc/src/gcc-dist/libgfortran/generated/maxval_r16.c:413:1: internal
compiler error: Segmentation fault

Unfortunately, I cannot investigate the crash with gdb 6.6 since gdb crashes
itself when run on cc1.  I'll try with 7.0 instead.

Interestingly, it works ok on alpha-dec-osf4.0f: it seems to be due to the fact
that V5.1B supports 128-bit long double, while V4.0F does not.


-- 
   Summary: [4.5 regression] cc1 SEGV compiling maxval_r16.c
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: alpha-dec-osf5.1b
  GCC host triplet: alpha-dec-osf5.1b
GCC target triplet: alpha-dec-osf5.1b


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



[Bug c++/41927] [C++0x] Spurious warning with enable_if and default function template argument

2009-11-03 Thread jason at gcc dot gnu dot org


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-03 18:07:00
   date||


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



[Bug ada/41929] 64-bit null_pointer_deref1 gnat.dg test consumes all available memory

2009-11-03 Thread ebotcazou at gcc dot gnu dot org


--- Comment #1 from ebotcazou at gcc dot gnu dot org  2009-11-03 18:49 
---
Somewhat expected, see the comment in the test.  A patch to disable it on this
platform (sparc*-*-solaris2.11) is pre-approved.

The failure very likely means that the 64-bit pattern matching code of the
fallback routine in config/sparc/sol2-unwind.h misbehaves for Solaris 11. 
Unfortunately, I don't have access to any Solaris 11 machine so I cannot fix.

To debug this, you need to recompile libgcc at -O0 -g and put a breakpoint on
sparc64_fallback_frame_state from within the debugger; it will be hit once you
resume execution after the SIGSEGV.  What happens from that on?


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-03 18:49:44
   date||


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



[Bug c++/39934] Union member incorrectly disallowed

2009-11-03 Thread terra at gnome dot org


--- Comment #6 from terra at gnome dot org  2009-11-03 17:44 ---
cp/class.c has code like this:

/* If any field is const, the structure type is pseudo-const. * /
if (CP_TYPE_CONST_P (type))
  {
...
/* ARM $12.6.2: [A member initializer list] (or, for an
   aggregate, initialization by a brace-enclosed list) is the
   only way to initialize nonstatic const and references
   members.  */
TYPE_HAS_COMPLEX_ASSIGN_REF (t) = 1;
  }

The ARM comment (as quoted) is clearly wrong: offhand, I can think of
two other ways of getting an object initialized.  There are probably
more.

1. Casting the offending "const" away.  (Note that struct A is a plain
   old C type -- data members only.)

   // Make an object of type A.
   A *pa = (A *)malloc (sizeof (A));
   *const_cast(&pa->x) = 42;
   pa->y = 42;

2. Copying an existing object.

   A a (*pa);

I don't see the justification for setting TYPE_HAS_COMPLEX_ASSIGN_REF,
just for prohibiting assignment.  That's pretty much the mixup I was
claiming in comment 4.


-- 


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



[Bug libffi/41923] libffi.call/testclosure.c failed on Linux/x86-64

2009-11-03 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2009-11-03 17:46 ---
This is expected considering the testcase was added for bug 41908.

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


-- 

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=41923



[Bug c++/39934] Union member incorrectly disallowed

2009-11-03 Thread redi at gcc dot gnu dot org


--- Comment #8 from redi at gcc dot gnu dot org  2009-11-03 18:10 ---
(In reply to comment #6)
> 
> The ARM comment (as quoted) is clearly wrong: offhand, I can think of
> two other ways of getting an object initialized.  There are probably
> more.
> 
> 1. Casting the offending "const" away.  (Note that struct A is a plain
>old C type -- data members only.)

It's irrelevant that it has data members only.  Casting away const on an object
declared const is undefined behaviour.

> 2. Copying an existing object.
> 
>A a (*pa);

Copy construction is dealt with separately from copy assignment, so
has_complex_assign_ref is not relevant in this case.

So the ARM comment may be incorrect, but not due to either of your reasons.

As I said earlier, I'm not sure whether using A in a union causes the
implicitly-declared copy assignment operator to be implicitly defined.  This
issue hinges on that point, not on the points you've been making.

The standard is clear that a copy assignment operator is implicitly-declared.
If it is implicitly defined then that copy assignment operator would be
ill-formed.
So the only question is whether using the type in a union causes it to be
implicitly defined.


-- 


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



[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement

2009-11-03 Thread paolo dot carlini at oracle dot com


--- Comment #53 from paolo dot carlini at oracle dot com  2009-11-03 18:18 
---
Fixed for 4.5.0.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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



[Bug ada/41929] New: 64-bit null_pointer_deref1 gnat.dg test consumes all available memory

2009-11-03 Thread ro at gcc dot gnu dot org
Between 20091022 and 20091102, a parallel make check run (both 32 and 64 bit)
on Solaris 11/SPARC started to fail with `Cannot fork: out of memory'.  It
turns
out that the null_pointer_deref1 gnat.dg test is the culprit: it grows to 11+
GB
on my test system:

   PID USERNAME  SIZE   RSS STATE  PRI NICE  TIME  CPU PROCESS/NLWP   
 15442 ro 11G 6705M stop430   0:03:16 0.0% null_pointer_de/1

pmap shows that it's all on the heap:

15442:  ./null_pointer_deref1.exe
0001120K r-x-- 
/export/vol/gcc/obj/SunOS-sparc/gcc-4.5.0-20091102/11-gcc/gcc/testsuite/gnat/null_pointer_deref1.exe
00010011C000 24K rwx-- 
/export/vol/gcc/obj/SunOS-sparc/gcc-4.5.0-20091102/11-gcc/gcc/testsuite/gnat/null_pointer_deref1.exe
000100122000   2936K rwx--[ heap ]
00010040 933888K rwx--[ heap ]
7FFF7F46  8K rwxs-[ anon ]
7FFF7F50 24K rwx--[ anon ]
7FFF7F60  8K rwx--[ anon ]
7FFF7F70  8K r-x-- 
/platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap1.so.1
7FFF7F80   1312K r-x--  /lib/sparcv9/libc.so.1
7FFF7FA48000 40K rwx--  /lib/sparcv9/libc.so.1
7FFF7FA52000  8K rwx--  /lib/sparcv9/libc.so.1
7FFF7FB0  8K rwx--[ anon ]
7FFF7FC0  8K rw---[ anon ]
7FFF7FD0  8K rw---[ anon ]
7FFF7FE0224K r-x--  /lib/sparcv9/ld.so.1
7FFF7FF38000 16K rwx--  /lib/sparcv9/ld.so.1
7FFF7FF3C000  8K rwx--  /lib/sparcv9/ld.so.1
FFFCF5C0   10653696K rw---[ stack ]
 total 11592344K

Unfortunately, I haven't been able to get a stacktrace with pstack, nor with
gdb 6.6 (quite old now, admittedly).  Since this breaks all testing, I've moved
the source out of the way for now.


-- 
   Summary: 64-bit null_pointer_deref1 gnat.dg test consumes all
available memory
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.11
  GCC host triplet: sparc-sun-solaris2.11
GCC target triplet: sparc-sun-solaris2.11


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



[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

2009-11-03 Thread bonzini at gnu dot org


--- Comment #9 from bonzini at gnu dot org  2009-11-03 18:58 ---
The patch is not enough for mainline because some functions have a bigger stack
frame.  With the patch, mainline aborts after 9827 recursive calls.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

   Keywords||ra


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



[Bug c++/39786] [4.3/4.4 Regression] Qualified name lookup through different numbers of using directives

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #6 from jason at gcc dot gnu dot org  2009-11-03 22:09 ---
Fixed fer 4.4.3, 4.5.0.  I'm not comfortable applying the fix to 4.3 as it
might have unintended side-effects.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.3.5   |4.4.3


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



[Bug c++/40944] [C++0x] rejects well-formed code: SFINAE, decltype, function call

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #5 from jason at gcc dot gnu dot org  2009-11-03 18:49 ---
Fixed for 4.5.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug c++/40687] [C++0x]: error with auto and 7.1.6.4/7 in N2914

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #5 from jason at gcc dot gnu dot org  2009-11-03 18:49 ---
Fixed for 4.5.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug fortran/41918] Superflous warning "was declared INTENT(OUT) but was not set"

2009-11-03 Thread kargl at gcc dot gnu dot org


--- Comment #2 from kargl at gcc dot gnu dot org  2009-11-03 23:08 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00158.html


-- 


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



[Bug middle-end/20548] [4.3/4.4/4.5 regression] ACATS c52103x c52104x c52104y segfault

2009-11-03 Thread ebotcazou at gcc dot gnu dot org


--- Comment #38 from ebotcazou at gcc dot gnu dot org  2009-11-03 22:49 
---
Subject: Bug 20548

Author: ebotcazou
Date: Tue Nov  3 22:49:37 2009
New Revision: 153877

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153877
Log:
PR target/10127
PR ada/20548
* expr.h (STACK_CHECK_PROBE_INTERVAL): Delete.
(STACK_CHECK_PROBE_INTERVAL_EXP): New macro.
(STACK_CHECK_MOVING_SP): Likewise.
* system.h (STACK_CHECK_PROBE_INTERVAL): Poison it.
* doc/tm.texi (Stack Checking): Delete STACK_CHECK_PROBE_INTERVAL.
Document STACK_CHECK_PROBE_INTERVAL_EXP and STACK_CHECK_MOVING_SP.
* doc/md.texi (Standard Pattern Names): Tweak entry of CHECK_STACK.
Document PROBE_STACK.
* explow.c (anti_adjust_stack_and_probe): New function.
(allocate_dynamic_stack_space): Do not directly allocate space if
STACK_CHECK_MOVING_SP, instead invoke above function.
(emit_stack_probe): Handle probe_stack insn.
(PROBE_INTERVAL): New macro.
(STACK_GROW_OPTAB): Likewise.
(STACK_GROW_OFF): Likewise.
(probe_stack_range): Use Pmode and memory_address consistently.  Fix
loop condition in the small constant case.  Rewrite in the general
case to be immune to wraparounds.  Make sure the address of probes
is valid.  Try to use [base + disp] addressing mode if possible.
* ira.c (setup_eliminable_regset): Set frame_pointer_needed if stack
checking is enabled and STACK_CHECK_MOVING_SP.
* rtlanal.c (may_trap_p_1) : If stack checking is enabled,
return 1 for volatile references to the stack pointer.
* tree.c (build_common_builtin_nodes): Do not set ECF_NOTHROW on
__builtin_alloca if stack checking is enabled.
* unwind-dw2.c (uw_identify_context): Take into account whether the
context is that of a signal frame or not.
* config/i386/linux.h (STACK_CHECK_MOVING_SP): Define to 1.
* config/i386/linux64.h (STACK_CHECK_MOVING_SP): Likewise.

Added:
trunk/gcc/testsuite/gnat.dg/stack_check1.adb
trunk/gcc/testsuite/gnat.dg/stack_check2.adb
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/linux.h
trunk/gcc/config/i386/linux64.h
trunk/gcc/doc/md.texi
trunk/gcc/doc/tm.texi
trunk/gcc/explow.c
trunk/gcc/expr.h
trunk/gcc/ira.c
trunk/gcc/rtlanal.c
trunk/gcc/system.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/unwind-dw2.c


-- 


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



[Bug c++/41884] diagnostics: error vs. context

2009-11-03 Thread bkoz at gcc dot gnu dot org


--- Comment #6 from bkoz at gcc dot gnu dot org  2009-11-03 23:36 ---
Created an attachment (id=18960)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18960&action=view)
pre-processed source to reproduce diagnostic


-- 


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



[Bug c++/36959] [4.3/4.4/4.5 Regression] C++ front-end causing a static inline function to be emitted

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #7 from jason at gcc dot gnu dot org  2009-11-03 23:02 ---
Subject: Bug 36959

Author: jason
Date: Tue Nov  3 23:02:41 2009
New Revision: 153878

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153878
Log:
PR c++/36959
* decl2.c (cxx_callgraph_analyze_expr): Don't reference a function
just because a static variable in it is needed unless -frepo.

Added:
trunk/gcc/testsuite/g++.dg/opt/inline16.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement

2009-11-03 Thread paolo dot carlini at oracle dot com


--- Comment #55 from paolo dot carlini at oracle dot com  2009-11-03 20:51 
---
David, this issue is closed, nobody will pay further attention to it. And, more
generally, we are not going to change the other overloads of rotate in the
4.5.0 timeframe, is too risky. Thus, please, as already recommended, please
concentrate on the std::swap issue in the other algorithms, and post any
further prospective discussions to libstd...@. Also, again, as already
recommended, please make sure to do all the tests vs current mainline. A lot
has changes the last years in the compiler too, not just the library. Thanks.


-- 


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



[Bug c++/41884] diagnostics: error vs. context

2009-11-03 Thread paolo dot carlini at oracle dot com


--- Comment #8 from paolo dot carlini at oracle dot com  2009-11-04 02:22 
---
Yes, I think the last message from Benjamin summarizes well the enhancement we
have been thinking about: first the error (file, line number and actual error
message), then all the rest.


-- 


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



[Bug middle-end/41925] ICE in get_alias_set, at alias.c:710

2009-11-03 Thread marcus at jet dot franken dot de


--- Comment #2 from marcus at jet dot franken dot de  2009-11-03 23:49 
---
order of files seems important even


-- 


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



[Bug c++/41884] diagnostics: error vs. context

2009-11-03 Thread paolo dot carlini at oracle dot com


--- Comment #9 from paolo dot carlini at oracle dot com  2009-11-04 02:36 
---
You know what? I'm a bit unsure about the issue itself... I mean, let's assume
the user passes in any case -Wfatal-errors, which, as we discussed already, is
the only way to manage those huge series of error messages. Now, in the current
situation, even if the messages are very long, the last few lines, which you
can read close to your new prompt contain the actual error: message line. On
the other hand, if we reverse completely the order, for short messages the
output is cleaner, because you get first the error: and then the "details", so
to speak, but for very long error messages there is the important risk that the
line containing error: exits the shell from the top! I'm not sure I have been
able to fully explain what I mean...


-- 


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



[Bug c++/36959] [4.3/4.4/4.5 Regression] C++ front-end causing a static inline function to be emitted

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #9 from jason at gcc dot gnu dot org  2009-11-03 23:50 ---
Fixed for 4.4.3 and 4.5.0.  My inclination is to leave 4.3 unfixed, but I don't
mind applying it there if other people think that's a good idea.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.3.5   |4.4.3


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



[Bug c++/36959] [4.3/4.4/4.5 Regression] C++ front-end causing a static inline function to be emitted

2009-11-03 Thread jason at gcc dot gnu dot org


--- Comment #8 from jason at gcc dot gnu dot org  2009-11-03 23:49 ---
Subject: Bug 36959

Author: jason
Date: Tue Nov  3 23:49:07 2009
New Revision: 153881

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153881
Log:
PR c++/36959
* decl2.c (cxx_callgraph_analyze_expr): Don't reference a function
just because a static variable in it is needed unless -frepo.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/opt/inline16.C
Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/decl2.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug rtl-optimization/41917] Strange athrithmetic result with -O3

2009-11-03 Thread jakub at gcc dot gnu dot org


--- Comment #4 from jakub at gcc dot gnu dot org  2009-11-03 22:40 ---
Subject: Bug 41917

Author: jakub
Date: Tue Nov  3 22:40:08 2009
New Revision: 153875

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153875
Log:
PR rtl-optimization/41917
* rtlanal.c (num_sign_bit_copies1) : If sign bit of second
operand isn't known to be 0, return 1.

* gcc.c-torture/execute/pr41917.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41917.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/rtlanal.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/41933] internal compiler error: tree check: expected field_decl, have error_mark in build_lambda_object, at cp/semantics.c:5353

2009-11-03 Thread paolo dot carlini at oracle dot com


--- Comment #1 from paolo dot carlini at oracle dot com  2009-11-04 02:42 
---
A new one... (thanks)


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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



[Bug c++/35067] [4.3/4.4/4.5 Regression] multiple definition of virtual thunk

2009-11-03 Thread jason at gcc dot gnu dot org


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-03 21:21:25
   date||


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



[Bug target/10127] -fstack-check let's program crash

2009-11-03 Thread ebotcazou at gcc dot gnu dot org


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-06-28 01:27:31 |2009-11-03 21:22:58
   date||


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



[Bug middle-end/20548] [4.3/4.4/4.5 regression] ACATS c52103x c52104x c52104y segfault

2009-11-03 Thread ebotcazou at gcc dot gnu dot org


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|SUSPENDED   |ASSIGNED
   Last reconfirmed|2006-03-19 09:00:55 |2009-11-03 21:23:42
   date||


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



  1   2   >