[Bug bootstrap/42812] --enable-build-with-cxx bootstrap fails on fortran/resolve.c:gfc_resolve

[amylaar at gcc dot gnu dot org]

--- Comment #3 from amylaar at gcc dot gnu dot org  2010-01-20 08:20 ---
patch applied:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01071.html
http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00529.html


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level

[FBergemann at web dot de]

--- Comment #11 from FBergemann at web dot de  2010-01-20 08:39 ---
Hi Paolo,

here's the response from HP:


> I kindly would like to ask you for confirmation of the problem.

> Because i want to exclude that the problem is just due to our system

> set-up here.

> I would highly appreciate if you could try to re-produce the problem  

> (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791)

> and give us positive or negative confirmation.



I ran the test case from the GCC bug report using GCC 3.4.5 and Boost

1.33.1 and was able to reproduce the problem on my system.



> For decision making about new gcc compiler version to use,

> i would like to ask you for a proposal - especially related to

> performance issues.

> Because there are difference gcc version packages available from your

> download sites.



Generally, I recommend using the most recent GCC version available.



> If you confirm the problem, then it might also be helpful to add the

> information to your web-site, porting guidelines, etc.

> - for all your customers (they might hit the same problem)

> Or ask gnu to fix it.



The FSF is not going to fix anything on the 3.4.* branch, this branch is

considered 'dead' and is no longer being maintained.



[...]
[@cup.hp.com


So could you pls. set it to WONTFIX - because WORKSFORME means it works - but
it doesn't. Just for other people facing the same problem again.

We check for new compiler version to use now.

Thanks for your help!

cheers,
Frank


-- 


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

[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level

[paolo dot carlini at oracle dot com]

--- Comment #12 from paolo dot carlini at oracle dot com  2010-01-20 10:34 
---
Frank, to be honest, you are *boring*. I'm adding 3.4.6 to Know to fail, I
think this is the right thing to do. To be clear, I'm not paying further
attention to your messages here, involving a completely obsolete compiler
nobody is interested in.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

  Known to fail||3.4.6


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

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug c++/42797] [4.5 Regression] call of overloaded 'allocator()' is ambiguous

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-01-20 10:49 ---
Appearantly not a duplicate.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |
Summary|call of overloaded  |[4.5 Regression] call of
   |'allocator()' is ambiguous  |overloaded 'allocator()' is
   ||ambiguous
   Target Milestone|--- |4.5.0


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

[Bug middle-end/42803] [4.4/4.5 Regression] c++ compilation hang

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-01-20 11:08 ---
Subject: Bug 42803

Author: jakub
Date: Wed Jan 20 11:08:24 2010
New Revision: 156069

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156069
Log:
PR middle-end/42803
* varasm.c (narrowing_initializer_constant_valid_p): Add CACHE
argument, call initializer_constant_valid_p_1 instead of
initializer_constant_valid_p, pass CACHE to it, return NULL
immediately if first call returns NULL.
(initializer_constant_valid_p_1): New function.
(initializer_constant_valid_p): Use it.

* g++.dg/parse/limits-initializer1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/parse/limits-initializer1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c


-- 


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

[Bug middle-end/42803] [4.4/4.5 Regression] c++ compilation hang

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-01-20 11:28 ---
Subject: Bug 42803

Author: jakub
Date: Wed Jan 20 11:27:49 2010
New Revision: 156070

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156070
Log:
PR middle-end/42803
* varasm.c (narrowing_initializer_constant_valid_p): Add CACHE
argument, call initializer_constant_valid_p_1 instead of
initializer_constant_valid_p, pass CACHE to it, return NULL
immediately if first call returns NULL.
(initializer_constant_valid_p_1): New function.
(initializer_constant_valid_p): Use it.

* g++.dg/parse/limits-initializer1.C: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/parse/limits-initializer1.C
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/varasm.c


-- 


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

[Bug bootstrap/42786] Athlon SSE3 and Fx processors not supported by configure

[uros at gcc dot gnu dot org]

--- Comment #4 from uros at gcc dot gnu dot org  2010-01-20 11:28 ---
Subject: Bug 42786

Author: uros
Date: Wed Jan 20 11:27:49 2010
New Revision: 156071

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156071
Log:
PR bootstrap/42786
* config.gcc (i[34567]86-*-*): Fix handling of athlon64 and athlon-fx
cpu types.  Add support for *-sse3 cpu types.
(x86_64-*-*): Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc


-- 


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

[Bug tree-optimization/41879] [4.5 Regression] 172.mgrid regression, vectorizer prevents predictive commoning

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-01-20 11:42 ---
mgrid now miscompares on i?86 ...


-- 


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

[Bug libstdc++/21769] per-file control over PCH inclusion

[paolo at gcc dot gnu dot org]

--- Comment #4 from paolo at gcc dot gnu dot org  2010-01-20 11:58 ---
Subject: Bug 21769

Author: paolo
Date: Wed Jan 20 11:57:44 2010
New Revision: 156075

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156075
Log:
2010-01-20  Janis Johnson  
Paolo Carlini  

PR libstdc++/21769
* testsuite/lib/dg-options.exp (add_options_for_no_pch): Add.
* testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc:
Use it.


Modified:
trunk/libstdc++-v3/ChangeLog
   
trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc
trunk/libstdc++-v3/testsuite/lib/dg-options.exp


-- 


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

[Bug libstdc++/21769] per-file control over PCH inclusion

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2010-01-20 12:04 
---
Done.


-- 

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

[Bug middle-end/42803] [4.4/4.5 Regression] c++ compilation hang

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-01-20 12:09 ---
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=42803

[Bug tree-optimization/42717] [4.5 Regression] ice: verify_ssa failed

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-20 12:30 ---
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=42717

[Bug tree-optimization/42717] [4.5 Regression] ice: verify_ssa failed

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-01-20 12:30 ---
Subject: Bug 42717

Author: rguenth
Date: Wed Jan 20 12:30:15 2010
New Revision: 156076

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156076
Log:
2010-01-20  Richard Guenther  

PR tree-optimization/42717
* tree-ssa-dce.c (get_live_post_dom): Remove.
(forward_edge_to_pdom): Take an arbitrary edge to copy
degenerate PHI args from.
(remove_dead_stmt): Use the first post-dominator even if it
does not contain live statements as redirection destination.

* gcc.c-torture/compile/pr42717.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr42717.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dce.c


-- 


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

[Bug tree-optimization/41826] invalid read in get_constraint_for_ptr_offset

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-20 13:06 ---
Subject: Bug 41826

Author: rguenth
Date: Wed Jan 20 13:06:40 2010
New Revision: 156078

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156078
Log:
2010-01-20  Richard Guenther  

PR tree-optimization/41826
* tree-ssa-structalias.c (get_constraint_for_ptr_offset): Avoid
access to re-allocated vector fields.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-structalias.c


-- 


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

[Bug tree-optimization/41826] invalid read in get_constraint_for_ptr_offset

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-01-20 13:07 ---
Subject: Bug 41826

Author: rguenth
Date: Wed Jan 20 13:07:41 2010
New Revision: 156079

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156079
Log:
2010-01-20  Richard Guenther  

PR tree-optimization/41826
* tree-ssa-structalias.c (get_constraint_for_ptr_offset): Avoid
access to re-allocated vector fields.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/tree-ssa-structalias.c


-- 


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

[Bug tree-optimization/41826] invalid read in get_constraint_for_ptr_offset

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-01-20 13:08 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.5.0   |4.3.5 4.4.3 4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.3.5


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

[Bug libstdc++/42460] man page errors for generated libstdc++ man pages

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2010-01-20 13:12 
---
Ok, let's close this one as fixed...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug libstdc++/42201] [C++0x] std::vector>::push_back fails

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-01-20 13:16 
---
Jon, what do you think, shall we go ahead with this one too?


-- 


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

[Bug libstdc++/42460] man page errors for generated libstdc++ man pages

[doko at ubuntu dot com]

--- Comment #11 from doko at ubuntu dot com  2010-01-20 13:58 ---
the man pages still have problems with escape codes used (prefix backslashes);
I didn't build and run the check tool yet again.

  Matthias


-- 


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

[Bug libstdc++/42460] man page errors for generated libstdc++ man pages

[paolo dot carlini at oracle dot com]

--- Comment #12 from paolo dot carlini at oracle dot com  2010-01-20 14:00 
---
Ok, let's re-open to be safe: please provide as soon as possible to Benjamin
the information he needs...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug libstdc++/42201] [C++0x] std::vector>::push_back fails

[jwakely dot gcc at gmail dot com]

--- Comment #7 from jwakely dot gcc at gmail dot com  2010-01-20 14:38 
---
I was going to ask you the same thing :-)

I would like to update  for 4.5, I'll send the patch when I get home in
a few hours


-- 


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

[Bug tree-optimization/41879] [4.5 Regression] 172.mgrid regression, vectorizer prevents predictive commoning

[matz at gcc dot gnu dot org]

--- Comment #9 from matz at gcc dot gnu dot org  2010-01-20 14:42 ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35418#c8


-- 


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

[Bug libstdc++/42201] [C++0x] std::vector>::push_back fails

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2010-01-20 14:46 
---
Great.


-- 


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

[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level

[FBergemann at web dot de]

--- Comment #13 from FBergemann at web dot de  2010-01-20 15:00 ---
Hi paolo.carl...@oracle.com,
the funny thing about your last comment is, that the company i am working for
is selling quite successfully large systems with adjunct big oracle database
cluster systems to Tier-1 operators. Until now holding on a "completely
obsolete compiler nobody is interested in" which fulfilled our needs for
stability and performance was not a bad idea :-)
regards,
Frank


-- 


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

[Bug tree-optimization/41879] [4.5 Regression] 172.mgrid regression, vectorizer prevents predictive commoning

[steven at gcc dot gnu dot org]

--- Comment #10 from steven at gcc dot gnu dot org  2010-01-20 15:25 ---
Is there an alt.src for this from SPEC?


-- 


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

[Bug tree-optimization/42644] [4.5 Regression] wrong code for -fgraphite-identify in 183.equake

[uramakrishna at gmail dot com]

--- Comment #3 from uramakrishna at gmail dot com  2010-01-20 15:26 ---
Created an attachment (id=19666)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19666&action=view)
Reduced test case for this PR

We (Tobias, Li and Ramakrishna) have reduced the test case further. This file
shows the problem.


-- 


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

[Bug tree-optimization/41879] [4.5 Regression] 172.mgrid regression, vectorizer prevents predictive commoning

[rguenther at suse dot de]

--- Comment #11 from rguenther at suse dot de  2010-01-20 15:31 ---
Subject: Re:  [4.5 Regression] 172.mgrid
 regression, vectorizer prevents predictive commoning

On Wed, 20 Jan 2010, steven at gcc dot gnu dot org wrote:

> --- Comment #10 from steven at gcc dot gnu dot org  2010-01-20 15:25 
> ---
> Is there an alt.src for this from SPEC?

I don't think so - SPEC 2000 is no longer officially maintained.


-- 


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

[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.

[tony3 at GarlandConsulting dot us]

--- Comment #9 from tony3 at GarlandConsulting dot us  2010-01-20 15:42 
---
I am reopening this bug if only because I'd like to get a response to my
previous comments.  

I can appreciated that, in your view, the compiler is 'technically correct' in
making the assumption that it need not support programs which inadvertently
generate an enumeration value outside of the defined range.

But if you step back from this 'technical legitimacy', and look at the bigger
picture, we are left with a compiler which is not doing much to help us write
reliable code.  In fact, it is doing just the opposite by silently accepting
such code and even running it in the expected fashion when optimization is less
than -O2.

It is one thing to state that the compiler doesn't have to support a value
which is greater than 1 less than the closest power of two, and another to make
a compiler which usefully indicates when it refuses to follow where the
programmer is directing it to go.

All the more so when its refusal to implement an exit loop--indeed completely
expunging the expected exit condition from the code--hinges on such a rare
combination of incident:  1) optimization set at -O2, and 2) a maximum
enumeration value which happens to fall just under a power of two.  Unless this
unhappy combination occurs, the code misleadingly does as the programmer
expects.  (Also, I would venture to say that many programmers would be
extremely surprised to find that powers of 2 which fit well within 8-bits are
apparently to be included in this behavior: 8, 16, 32, 64, 128.)

So, given that those who know much more about enumerations and compilers than I
ever will have decided that such behavior is not to be improved upon, why is it
that we get no warning about it?  Isn't the intention of warnings to indicate
to the programmer when they have done something silly or dangerous where the
results may differ from their expectations?  Surely this situation falls into
that category.

The fact that there have been two bug reports in this regard and that a number
of experienced programmers at my site found the resulting execution completely
puzzling and unexpected would seem to indicate some sort of response beyond
"this is technically acceptable therefore the bug report is INVALID . . .
next!" is in order?


-- 

tony3 at GarlandConsulting dot us changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2010-01-20 15:48 
---
Too bad, yes.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/42644] [4.5 Regression] wrong code for -fgraphite-identify in 183.equake

[grosser at gcc dot gnu dot org]

-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |grosser at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-20 15:50:56
   date||


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

[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-01-20 
16:37 ---
Subject: Re:  [4.5 regression] ICE in function_and_variable_visibility breaks
Ada bootstrap

> --- Comment #20 from hubicka at ucw dot cz  2010-01-18 12:57 ---
> Subject: Re:  [4.5 regression] ICE in
> function_and_variable_visibility breaks Ada bootstrap
>
>> This is really messy: maybe I'll have some more luck with a cross
>> compiler.
> Indeed it is.  I will try, but I had problem building the cross because of
> missing a.out headers.  Can you, please, try the change to ada directory
> itself? That alone should be enough to cure the bootstrap failure (not the C
> version of testcase).  So I am testing it now and intend to commit it ahead of
> rest of changes.

Indeed it does: with that chance, a full bootstrap on alpha-dec-osf4.0f
and alpha-dec-osf5.1b succeeded.

Thanks
Rainer


-- 


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

[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2010-01-20 17:40 
---
Patches welcome to add diagnostics to the C++ frontend.


-- 


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

[Bug other/42813] New: --enable-build-with-cxx libstdc++-v3 is incomplete

[amylaar at gcc dot gnu dot org]

On i686-pc-linux-gnu, seven libstdc++-v3 symbols are missing when configuring
with --enable-build-with-cxx.
For x86_64-unknown-linux-gnu, it's 53 vs. 46 missing symbols, i.e. again
seven more missing symbols for --enable-build-with-cxx.

Take for example:
__gnu_parallel::_Settings::get()

In the ordinary compilation, this symbol is defined in parallel_settings.o;
that object file is missing for --enable-build-with-cxx.

compilation of parallel_settings.cc depends on ENABLE_PARALLEL, set
by configure.

Inspection of the src/Makefile files shows that ENABLE_PARALLEL was not
set for --enable-build-with-cxx .
The building of parallel_list.o also depends on ENABLE_PARALLEL;
parallel_list and parallel_settings together account for the seven missing
symbols.

The normal bootstrap log file shows:
line 11064/21065:
checking for parallel mode support... yes

The --enable-build-with-cxx bootstrap log file shows:
line 4234/23482:
configure:
/user/inria/fsf/bld-gcc-cxx12/i686-pc-linux-gnu/libstdc++-v3/../libgo
mp/omp.h not found
checking for parallel mode support... no

line 8212/23482:
configure:
/user/inria/fsf/bld-gcc-cxx12/i686-pc-linux-gnu/libstdc++-v3/../libgo
mp/omp.h not found
checking for parallel mode support... no

line 12192/23482:
configure:
/user/inria/fsf/bld-gcc-cxx12/i686-pc-linux-gnu/libstdc++-v3/../libgomp/omp.h
not found
checking for parallel mode support... no


The normal bootstrap log shows:
line 9732/21065:
Configuring in i686-pc-linux-gnu/libgomp

The --enable-build-with-cxx bootstrap log file shows:
line 12983/23482:
Configuring in i686-pc-linux-gnu/libgomp

I.e. the problem is that libgomp is not built before the final
libstdc++-v3 is configured.


-- 
   Summary: --enable-build-with-cxx libstdc++-v3 is incomplete
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org


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

[Bug other/42813] --enable-build-with-cxx libstdc++-v3 is incomplete

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-01-20 18:42 
---
Is this issue related to PR36101?


-- 


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

[Bug libstdc++/42813] --enable-build-with-cxx libstdc++-v3 is incomplete

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-20 18:43 ---
libstdc++ configure issue.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|other   |libstdc++
   Keywords||build


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

[Bug libstdc++/16612] empty basic_strings can't live in shared memory

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug libstdc++/42813] --enable-build-with-cxx libstdc++-v3 is incomplete

[amylaar at gcc dot gnu dot org]

--- Comment #3 from amylaar at gcc dot gnu dot org  2010-01-20 18:49 ---
(In reply to comment #1)
> Is this issue related to PR36101?
Yes, if PR36101 was fixed, I'd expect this problem to go away.


-- 


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

[Bug libstdc++/29366] atomics config for sh is weird

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-01-20 18:51 
---
Let's add an SH maintainer in CC...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu dot
   ||org


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

[Bug target/40332] [4.5 Regression] (.eh_frame); no .eh_frame_hdr table will be created.

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2010-01-20 18:53 
---
Only RMs may change regression priority.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P1  |P3


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

[Bug c++/40750] Side-effect of member function call not produced in certain circumstances

[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-15 09:41:03 |2010-01-20 18:54:11
   date||


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

[Bug libstdc++/36101] deps on other host libraries incorrect

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-01-20 18:54 
---
Let's add in CC a couple of build machinery maintainers, maybe we can get some
help...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||Ralf dot Wildenhues at gmx
   ||dot de, neroden at gcc dot
   ||gnu dot org, bonzini at gnu
   ||dot org


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

[Bug c++/42336] [4.5 Regression] ICE with pointer-to-member-function argument in template function with -fipa-sra

[rguenth at gcc dot gnu dot org]

--- Comment #22 from rguenth at gcc dot gnu dot org  2010-01-20 18:59 
---
(In reply to comment #18)
> Subject: Re:  [4.5 Regression] ICE with pointer-to-member-function
>  argument in template function
> 
> On 01/10/2010 06:42 PM, hubicka at gcc dot gnu dot org wrote:
> > In general I am not sure plan of doing all
> > datastructure/function call conventions changes via cloning is coolest idea.
> 
> Well, just pretending that a particular parameter never existed isn't 
> acceptable from a debugging standpoint; I think we need to have a 
> separate modified decl which points back to the original unmodified decl 
> with DECL_ABSTRACT_ORIGIN.
> 
> Beyond that, it might be possible to avoid much copying by just moving 
> the function body over from the original decl to the modified one.

That hints at a possible fix?  Instead of versioning the function just
version the DECL (thus basically perform the DECL creation part of
versioning only).  It requires fixing up call stmts of course, but that
shouldn't be too hard.

Martin - can you try this?


-- 


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

[Bug c++/42814] New: gcc segfaults on gch

[JamesMikeDuPont at googlemail dot com]

/usr/local/bin/g++ -DHAVE_CONFIG_H -I. -I.. -I../ -DHAVE_CONFIG_H
-DMAPNIK_DEBUGinclude -ggdb -O1 -DDEBUG -pg -DMAPNIK_DEBUG
-I/usr/include/libpng12 -I/usr/include/freetype2
-I/media/NewFoundSpace/2010/01/mapnik/agg/include -I/usr/local/include
-I/usr/include/libxml2 -D_REENTRANT -I/usr/include/cairomm-1.0
-I/usr/include/cairo -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb
-I/usr/include/libpng12 -I../include -save-temps -MT
libmapnik_la-filter_factory.lo -MD -MP -MF
.deps/libmapnik_la-filter_factory.Tpo -c src/filter_factory.ii 
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See  for instructions.


-- 
   Summary: gcc segfaults on gch
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: JamesMikeDuPont at googlemail dot com


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

[Bug c++/42814] gcc segfaults on gch

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-01-20 19:11 
---
Please provide all the required information, in particular a pre-processed
file. See this page for details:

  http://gcc.gnu.org/bugs/#report


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/42814] gcc segfaults on gch

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-20 19:13 ---
Also make sure to include the PCH from the toplevel source file and not from
some header.


-- 


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

[Bug c++/42814] gcc segfaults on gch

[JamesMikeDuPont at googlemail dot com]

--- Comment #3 from JamesMikeDuPont at googlemail dot com  2010-01-20 19:17 
---
Created an attachment (id=19667)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19667&action=view)
precompiled headers

/usr/local/bin/g++ -DHAVE_CONFIG_H -I. -I.. -I../ -DHAVE_CONFIG_H
-DMAPNIK_DEBUGinclude -ggdb -O1 -DDEBUG -pg -DMAPNIK_DEBUG
-I/usr/include/libpng12 -I/usr/include/freetype2
-I/media/NewFoundSpace/2010/01/mapnik/agg/include -I/usr/local/include
-I/usr/include/libxml2 -D_REENTRANT -I/usr/include/cairomm-1.0
-I/usr/include/cairo -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb
-I/usr/include/libpng12 -I../include -save-temps -MT
libmapnik_la-filter_factory.lo -MD -MP -MF
.deps/libmapnik_la-filter_factory.Tpo -c src/filter_factory.ii 
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See  for instructions.


-- 


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

[Bug c++/42814] gcc segfaults on gch

[JamesMikeDuPont at googlemail dot com]

--- Comment #4 from JamesMikeDuPont at googlemail dot com  2010-01-20 19:27 
---
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 326 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To g...@github.com:h4ck3rm1k3/MapNickAutotools.git
   1ae752a..6803b1b  master -> master


-- 


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

[Bug c++/42814] gcc segfaults on gch

[JamesMikeDuPont at googlemail dot com]

--- Comment #5 from JamesMikeDuPont at googlemail dot com  2010-01-20 19:41 
---
Sorry that is not the precompiled header, but the preprocessed,
all you need to get the crash i hope.


-- 


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

[Bug c++/42814] gcc segfaults on gch

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-01-20 19:48 
---
We are still missing the SVN Rev of the GCC 4.5 you are using and how you built
it.


-- 


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

[Bug c++/42814] gcc segfaults on gch

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-01-20 20:01 ---
Which GCC version are you using?  The preprocessed source does not use
a precompiled header.  Compiling the file works ok for me with GCC 4.4.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet||i?86-*-*


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

[Bug c++/42814] gcc segfaults on gch

[JamesMikeDuPont at googlemail dot com]

--- Comment #8 from JamesMikeDuPont at googlemail dot com  2010-01-20 20:05 
---
got it again after make clean,
maybe it ran out of memory:
mdup...@introspector-desktop:/media/NewFoundSpace/2010/01/mapnik$ gunzip
src/filter_factory.ii.gz
mdup...@introspector-desktop:/media/NewFoundSpace/2010/01/mapnik$
/usr/local/bin/g++ -DHAVE_CONFIG_H -I. -I.. -I../ -DHAVE_CONFIG_H
-DMAPNIK_DEBUGinclude -ggdb -O1 -DDEBUG -pg -DMAPNIK_DEBUG
-I/usr/include/libpng12 -I/usr/include/freetype2
-I/media/NewFoundSpace/2010/01/mapnik/agg/include -I/usr/local/include
-I/usr/include/libxml2 -D_REENTRANT -I/usr/include/cairomm-1.0
-I/usr/include/cairo -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb
-I/usr/include/libpng12 -I../include -save-temps -MT
libmapnik_la-filter_factory.lo -MD -MP -MF
.deps/libmapnik_la-filter_factory.Tpo -c src/filter_factory.ii 
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See  for instructions


-- 


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

[Bug c++/42814] gcc segfaults on gch

[JamesMikeDuPont at googlemail dot com]

--- Comment #9 from JamesMikeDuPont at googlemail dot com  2010-01-20 20:09 
---
Subject: Re:  gcc segfaults on gch

/usr/local/bin/c++ --version
c++ (GCC) 4.5.0 20100113 (experimental)
Copyright (C) 2010 Free Software Foundation, Inc.

On Wed, Jan 20, 2010 at 9:01 PM, rguenth at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #7 from rguenth at gcc dot gnu dot org  2010-01-20 20:01 
> ---
> Which GCC version are you using?  The preprocessed source does not use
> a precompiled header.  Compiling the file works ok for me with GCC 4.4.
>
>
> --
>
> rguenth at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> 
>  GCC target triplet|                            |i?86-*-*
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42814
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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

[Bug c++/42815] New: using variables only in C++0x lambda function closures produce unused var warnings

[indy2718 at gmail dot com]

// This compiled with
// g++ -Wall -Wextra -std=c++0x c.cpp 
// c.cpp:5:6: warning: unused parameter ‘x’
// c.cpp: In function ‘void func2()’:
// c.cpp:15:6: warning: unused variable ‘y’

#include 


void func1(int x)
{
auto f = [&](int j) { return j + x; };
std::cout << f(4) << std::endl;

}


void func2()
{
int y=100;
auto f = [&](int k) { return k+y; };
std::cout << f(6) << std::endl;
}


int main()
{
func1(8);
func2();
}


-- 
   Summary: using variables only in C++0x lambda function closures
produce unused var warnings
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: indy2718 at gmail dot com


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

[Bug libstdc++/36101] deps on other host libraries incorrect

[rwild at gcc dot gnu dot org]

--- Comment #2 from rwild at gcc dot gnu dot org  2010-01-20 20:15 ---
(In reply to comment #0)
> Libstdc++ configuration assumes that libgcc and libgomp have been configured
> and built before libstdc++ configure is run.
> 
> This is wrong,

What do you mean with "this is wrong"?  Is it wrong for libstdc++ configuration
to depend on libgcc and libgomp?  Or it is that the toplevel Makefile doesn't
have the proper dependencies in place to ensure that libgcc and libgomp really
are built before libstdc++ configure is started.

The latter ought to be fairly easy to fix.  In fact, toplevel Makefile.def
already has
dependencies = { module=configure-target-libstdc++-v3;
on=configure-target-libgomp; };

so changing that to depend on all-target-libgomp and adding a similar statement
for libgcc ought to fix that then.


-- 


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

[Bug libstdc++/36101] deps on other host libraries incorrect

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-01-20 20:20 
---
That idea of yours Ralf makes perfect sense to me, actually, I was wondering
whether a fix wasn't something like that. Are you willing to go ahead that way?


-- 


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

[Bug c++/41920] [C++0x] Invalid 'unused parameter' warning for parameters used in lambdas

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-01-20 20:23 
---
*** Bug 42815 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||indy2718 at gmail dot com


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

[Bug c++/42815] using variables only in C++0x lambda function closures produce unused var warnings

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-01-20 20:23 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/41920] [C++0x] Invalid 'unused parameter' warning for parameters used in lambdas

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-01-20 20:26 
---
Jason, we just got a third duplicate for this issue: if we could do something
about it in time for 4.5.0...


-- 


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

[Bug libstdc++/36101] deps on other host libraries incorrect

[rwild at gcc dot gnu dot org]

--- Comment #4 from rwild at gcc dot gnu dot org  2010-01-20 20:31 ---
Yes, sure.  But I would like to know a couple of things first:
Does that mean, when libstdc++ is built in early bootstrap stages (e.g., for
--enable-build-with-cxx), it is not necessary to have libgomp first?

Then, please show how the failure manifests itself/how I can confirm/reproduce
it.  Even if the patch is simple then having a way to ensure it works helps.
Thanks.


-- 


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

[Bug libstdc++/36101] deps on other host libraries incorrect

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2010-01-20 20:34 
---
Ralf, make sure the submitter of 42813 pays attention to your comments, maybe
add to that audit trail, instead of this one.


-- 


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

[Bug c++/42814] gcc segfaults on gch

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-01-20 20:47 
---
With unoptimized trunk I see us blowing the stack during garbage-collecting.
Note that we have a load of templates in this testcase and we walk them in
unfortunate order.

(gdb) 
#79368 0x0835b9fb in ggc_collect ()
at /home/richard/src/trunk/gcc/ggc-page.c:1962
1962  ggc_mark_roots ();


ugh.  We reach stuff from the function decl type.

400   gt_ggc_m_9tree_node ((*x).generic.type.size_unit);
(gdb) 
#79358 0x0828fdc9 in gt_ggc_mx_lang_tree_node (x_p=0xb772f378)
at ./gt-cp-tree.h:163
163   gt_ggc_m_9tree_node ((*x).generic.int_cst.common.type);
(gdb) 
#79357 0x0829106b in gt_ggc_mx_lang_tree_node (x_p=0xb7743000)
at ./gt-cp-tree.h:398
398   gt_ggc_m_9tree_node ((*x).generic.type.values);

hmm ...

#79349 0x0829115c in gt_ggc_mx_lang_tree_node (x_p=0xa83ff180)
at ./gt-cp-tree.h:417
417   gt_ggc_m_9tree_node ((*x).generic.type.name);
(gdb) 

#79348 0x08290cb9 in gt_ggc_mx_lang_tree_node (x_p=0xa8400138)
at ./gt-cp-tree.h:355
355   gt_ggc_m_9tree_node
((*x).generic.type_decl.common.common.common.common.common.context);
(gdb) 
#79347 0x0829106b in gt_ggc_mx_lang_tree_node (x_p=0xa83ff000)
at ./gt-cp-tree.h:398
398   gt_ggc_m_9tree_node ((*x).generic.type.values);
(gdb) 
#79346 0x08290229 in gt_ggc_mx_lang_tree_node (x_p=0xa84003a8)
at ./gt-cp-tree.h:228
228   gt_ggc_m_9tree_node
((*x).generic.decl_non_common.common.common.common.common.common.type);
(gdb) 
#79345 0x0829121c in gt_ggc_mx_lang_tree_node (x_p=0xa83ff420)
at ./gt-cp-tree.h:425
425   gt_ggc_m_9lang_type ((*x).generic.type.lang_specific);
(gdb) 
#79344 0x08292154 in gt_ggc_mx_lang_type (x_p=0xa83fdaa0) at ./gt-cp-tree.h:713
713   gt_ggc_m_9tree_node ((*x).u.c.template_info);


hmm - we reach templates via integer constants ...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-20 20:47:22
   date||


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

[Bug c++/41920] [C++0x] Invalid 'unused parameter' warning for parameters used in lambdas

[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-11-06 09:35:27 |2010-01-20 20:53:01
   date||


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

[Bug c++/42814] gcc segfaults on gch

[JamesMikeDuPont at googlemail dot com]

--- Comment #11 from JamesMikeDuPont at googlemail dot com  2010-01-20 
20:54 ---
Subject: Re:  gcc segfaults on gch

so I am thinking about a way to wrap the existing templates that I use.
there must be a way to reduce the size of the gch by specifing a list
of classes we use. that would reduce the build size.

this boost lib takes forever to process.
We only use %1 of it at a time. There has got to be a way to
precompile all these templates. A nice fine grained, for each header,
external pch database for stl and boost would make working with them
fun again.

I have been experimenting with grouping the headers into groups of
common dependencies. Basically I made a type level dependency tree
that is sliced up into pools of common types and topologically sorted
so that we can compile the the gch files in the right order and
include the previous gch.

I would consider putting some time into helping make the gch better if
you give me direction.

mike

On Wed, Jan 20, 2010 at 9:47 PM, rguenth at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #10 from rguenth at gcc dot gnu dot org  2010-01-20 20:47 
> ---
> With unoptimized trunk I see us blowing the stack during garbage-collecting.
> Note that we have a load of templates in this testcase and we walk them in
> unfortunate order.
>
> (gdb)
> #79368 0x0835b9fb in ggc_collect ()
>    at /home/richard/src/trunk/gcc/ggc-page.c:1962
> 1962      ggc_mark_roots ();
>
>
> ugh.  We reach stuff from the function decl type.
>
> 400                   gt_ggc_m_9tree_node ((*x).generic.type.size_unit);
> (gdb)
> #79358 0x0828fdc9 in gt_ggc_mx_lang_tree_node (x_p=0xb772f378)
>    at ./gt-cp-tree.h:163
> 163                   gt_ggc_m_9tree_node ((*x).generic.int_cst.common.type);
> (gdb)
> #79357 0x0829106b in gt_ggc_mx_lang_tree_node (x_p=0xb7743000)
>    at ./gt-cp-tree.h:398
> 398                   gt_ggc_m_9tree_node ((*x).generic.type.values);
>
> hmm ...
>
> #79349 0x0829115c in gt_ggc_mx_lang_tree_node (x_p=0xa83ff180)
>    at ./gt-cp-tree.h:417
> 417                   gt_ggc_m_9tree_node ((*x).generic.type.name);
> (gdb)
>
> #79348 0x08290cb9 in gt_ggc_mx_lang_tree_node (x_p=0xa8400138)
>    at ./gt-cp-tree.h:355
> 355                   gt_ggc_m_9tree_node
> ((*x).generic.type_decl.common.common.common.common.common.context);
> (gdb)
> #79347 0x0829106b in gt_ggc_mx_lang_tree_node (x_p=0xa83ff000)
>    at ./gt-cp-tree.h:398
> 398                   gt_ggc_m_9tree_node ((*x).generic.type.values);
> (gdb)
> #79346 0x08290229 in gt_ggc_mx_lang_tree_node (x_p=0xa84003a8)
>    at ./gt-cp-tree.h:228
> 228                   gt_ggc_m_9tree_node
> ((*x).generic.decl_non_common.common.common.common.common.common.type);
> (gdb)
> #79345 0x0829121c in gt_ggc_mx_lang_tree_node (x_p=0xa83ff420)
>    at ./gt-cp-tree.h:425
> 425                   gt_ggc_m_9lang_type ((*x).generic.type.lang_specific);
> (gdb)
> #79344 0x08292154 in gt_ggc_mx_lang_type (x_p=0xa83fdaa0) at 
> ./gt-cp-tree.h:713
> 713               gt_ggc_m_9tree_node ((*x).u.c.template_info);
>
>
> hmm - we reach templates via integer constants ...
>
>
> --
>
> rguenth at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> 
>             Status|WAITING                     |NEW
>     Ever Confirmed|0                           |1
>   Last reconfirmed|-00-00 00:00:00         |2010-01-20 20:47:22
>               date|                            |
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42814
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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

[Bug c++/42814] gcc segfaults on gch

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2010-01-20 21:09 
---
(In reply to comment #11)
> Subject: Re:  gcc segfaults on gch
> 
> so I am thinking about a way to wrap the existing templates that I use.
> there must be a way to reduce the size of the gch by specifing a list
> of classes we use. that would reduce the build size.
> 
> this boost lib takes forever to process.
> We only use %1 of it at a time. There has got to be a way to
> precompile all these templates. A nice fine grained, for each header,
> external pch database for stl and boost would make working with them
> fun again.
> 
> I have been experimenting with grouping the headers into groups of
> common dependencies. Basically I made a type level dependency tree
> that is sliced up into pools of common types and topologically sorted
> so that we can compile the the gch files in the right order and
> include the previous gch.

You can at most include a single gch file.

> I would consider putting some time into helping make the gch better if
> you give me direction.

I think the issue is the following enum:

  template
struct __traitor
{
  enum { __value = bool(_Sp::__value) || bool(_Tp::__value) };


-- 


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

[Bug c++/2474] global destructors should run in reverse order of _finishing_ construction

[jason at gcc dot gnu dot org]

--- Comment #15 from jason at gcc dot gnu dot org  2010-01-20 21:12 ---
Suspending since this seems unfixable on systems without __cxa_atexit.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
 Status|NEW |SUSPENDED


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

[Bug c++/42815] using variables only in C++0x lambda function closures produce unused var warnings

[indy2718 at gmail dot com]

--- Comment #2 from indy2718 at gmail dot com  2010-01-20 21:15 ---
(In reply to comment #1)
> 
> *** This bug has been marked as a duplicate of 41920 ***
> 

Sorry,
Using bug search, I had searched for "lambda" and there is another list of bugs
for "lambdas".  


-- 


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

[Bug ada/42816] New: Crash in Ada.Containers.Vectors.Update_Element

[gcc at coreland dot ath dot cx]

See the attached world_test_main program.

This was taken from a working program with as much code removed as possible.

$ gnatchop blob.adb
$ gnatmake world_test_main
$ ./world_test_main
test_tasks(1)_000800A50500: waiting to initialize
world_task_000800A0B700: running
main_task_000800A0AA00: initializing tasks
test_tasks(1)_000800A50500: initialized
test_tasks(1)_000800A50500: logged in
test_tasks(1)_000800A50500: fetching messages

raised STORAGE_ERROR : s-intman.adb:139 explicit raise

Running in gdb shows:

Program received signal SIGSEGV, Segmentation fault.
0x7f9fd9e8 in ?? ()
(gdb) bt
#0  0x7f9fd9e8 in ?? ()
#1  0x0040e3fa in world.player_sessions.update_element (container=...,
position=..., process=0x7f9fd9e8)
at
/storage/volatile/gnat_build/builds/8.0/x86_64/svn-r155934/lib/gcc/x86_64-unknown-freebsd8.0/4.5.0/adainclude/a-cohama.adb:853
#2  0x0040f6f8 in world.world_state.player_fetch_messages
(<_object>=..., name=..., messages=...)
at world.adb:67
#3  0x0040f767 in 
(name=..., messages=...) at world.adb:49
#4  0x0040f9ad in world.fetch_messages (name=..., messages=...) at
world.adb:114
#5  0x0041176a in  (<_task>=0x55bda0) at
world_test.adb:50
#6  0x00419260 in system.tasking.stages.task_wrapper
(self_id=0x800a50500) at s-tassta.adb:1188
#7  0x0008006974b1 in ?? () from /lib/libthr.so.3
#8  0x in ?? ()
(gdb) up
#1  0x0040e3fa in world.player_sessions.update_element (container=...,
position=..., process=0x7f9fd9e8)
at
/gnat/builds/8.0/x86_64/svn-r155934/lib/gcc/x86_64-unknown-freebsd8.0/4.5.0/adainclude/a-cohama.adb:853
853 Process (K, E);
(gdb) print Process
$1 = (access procedure (a1: world.player_sessions.key_typeX; a2: 
world.queue.vector)) 0x7f9fd9e8

This looks like it could possibly be a code generation error. The access to
Process seems to be invalid:

$ gdb world_test_main
(gdb) b world.adb:62
Breakpoint 1 at 0x40f6cf: file world.adb, line 62.
(gdb) r
Starting program:
/storage/home/m0/doc/dev/2010/01/another_gnat_bug2/test/world_test_main 
test_tasks(1)_000800A50500: waiting to initialize
world_task_000800A0B700: running
main_task_000800A0AA00: initializing tasks
test_tasks(1)_000800A50500: initialized
test_tasks(1)_000800A50500: logged in
test_tasks(1)_000800A50500: fetching messages

Breakpoint 1, world.world_state.player_fetch_messages (<_object>=..., name=...,
messages=...) at world.adb:67
67Player_Sessions.Update_Element
(gdb) s
world.player_sessions.update_element (container=..., position=...,
process=0x7f9fd9e8)
at
/storage/volatile/gnat_build/builds/8.0/x86_64/svn-r155934/lib/gcc/x86_64-unknown-freebsd8.0/4.5.0/adainclude/a-cohama.adb:827
827   if Position.Node = null then
(gdb) s
832   if Position.Container /= Container'Unrestricted_Access then
(gdb) s
world_task_000800A0B700845   B := B + 1;
(gdb) s
: running846 L := L + 1;
(gdb) s

849 K : Key_Type renames Position.Node.Key;
(gdb) s
850 E : Element_Type renames Position.Node.Element;
(gdb) s
853 Process (K, E);
(gdb) s

Program received signal SIGSEGV, Segmentation fault.
0x7f9fd9e8 in ?? ()

I've tested with every build of GCC I have from 4.4.0 to SVN r155934 on both
x86 and x86_64 and the point of failure is identical each time.


-- 
   Summary: Crash in Ada.Containers.Vectors.Update_Element
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at coreland dot ath dot cx
  GCC host triplet: x86_64-unknown-freebsd8.0


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

[Bug ada/42816] Crash in Ada.Containers.Vectors.Update_Element

[gcc at coreland dot ath dot cx]

--- Comment #1 from gcc at coreland dot ath dot cx  2010-01-20 21:24 ---
Created an attachment (id=19668)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19668&action=view)
Repro


-- 


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

[Bug c++/40750] Side-effect of member function call not produced in certain circumstances

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2010-01-20 21:30 ---
Subject: Bug 40750

Author: jason
Date: Wed Jan 20 21:30:20 2010
New Revision: 156084

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156084
Log:
PR c++/40750
* decl.c (grokdeclarator): Clear type_quals for a member function
declared using a typedef.  Don't complain about adding cv-quals
to a function typedef in C++0x mode.

Added:
trunk/gcc/testsuite/g++.dg/parse/fn-typedef1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/cv_func.C


-- 


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

[Bug c++/41920] [C++0x] Invalid 'unused parameter' warning for parameters used in lambdas

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2010-01-20 21:30 ---
Subject: Bug 41920

Author: jason
Date: Wed Jan 20 21:30:28 2010
New Revision: 156085

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156085
Log:
PR c++/41920
* semantics.c (build_lambda_object): Call mark_used on captured
variables.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-warn1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/41788] -Wpacked option changes the layout of packed non-POD structs

[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
   Keywords||ABI
   Last reconfirmed|2009-10-22 09:32:15 |2010-01-20 21:47:01
   date||


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

[Bug c++/40750] Side-effect of member function call not produced in certain circumstances

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2010-01-20 21:59 ---
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=40750

[Bug ada/42816] Crash in Ada.Containers.Vectors.Update_Element

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2010-01-20 21:59 ---
I tested 4.4.1 on x86_64-linux and it seems not to crash:

gue...@gcc13:~/pr42816$ PATH=/opt/cfarm/release/4.4.1/bin:$PATH
gue...@gcc13:~/pr42816$ gnatmake world_test_main.adb 
gcc -c world_test_main.adb
gcc -c world_test.adb
gcc -c log.adb
gcc -c world.adb
gnatbind -x world_test_main.ali
gnatlink world_test_main.ali
gue...@gcc13:~/pr42816$ ./world_test_main 
test_tasks(1)_0066C420: waiting to initialize
world_task_00668D10: running
main_task_00668020: initializing tasks
test_tasks(1)_0066C420: initialized
test_tasks(1)_0066C420: logged in
test_tasks(1)_0066C420: fetching messages
world_task_00668D10: running
test_tasks(1)_0066C420: fetching messages
world_task_00668D10: running
... (looping)

So this is freebsd specific.


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net
   Keywords||wrong-code


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

[Bug c++/41920] [C++0x] Invalid 'unused parameter' warning for parameters used in lambdas

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2010-01-20 22:00 ---
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=41920

[Bug c++/42038] [4.3/4.4/4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2010-01-20 22:11 ---
The patch is OK.


-- 


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

[Bug c++/42277] decltype error in template

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2010-01-20 22:12 ---
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=42277

[Bug c++/41788] -Wpacked option changes the layout of packed non-POD structs

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2010-01-20 22:15 ---
Subject: Bug 41788

Author: jason
Date: Wed Jan 20 22:14:51 2010
New Revision: 156088

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156088
Log:
PR c++/41788
* class.c (layout_class_type): Set packed_maybe_necessary for packed
non-PODs.

Added:
trunk/gcc/testsuite/g++.dg/abi/packed1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/42338] [c++0x] ICE on decltype usage with templates

[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 |2010-01-20 22:42:01
   date||


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

[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.

[zlogic at gmail dot com]

--- Comment #3 from zlogic at gmail dot com  2010-01-20 22:42 ---
Confirmed, I've encountered this bug in 64-bit Windows 7. I've used Qt Creator
1.3.1 (bundled with gc 4.4.0) for building a project which calls OpenMP
functions from inside a pthread.

If I call OpenMP function from main(), everything works fine.


-- 


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

[Bug debug/42782] [4.5 Regression] VTA missed location: parameter via stack

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-01-20 22:57 ---
Subject: Bug 42782

Author: jakub
Date: Wed Jan 20 22:57:20 2010
New Revision: 156092

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156092
Log:
PR debug/42782
* var-tracking.c: Include tree-flow.h.
(mem_dies_at_call): New.
(dataflow_set_preserve_mem_locs): Use it.
(dataflow_set_remove_mem_locs): Likewise.
(dump_var): Renamed from dump_variable.  Adjust all callers.
(dump_var_slot): Renamed from dump_variable_slot.  Likewise.
* Makefile.in (var-tracking.o): Adjust deps.

* gcc.dg/guality/pr42782.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/guality/pr42782.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/testsuite/ChangeLog
trunk/gcc/var-tracking.c


-- 


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

[Bug fortran/42809] Too much noise with -Wconversion

[anlauf at gmx dot de]

--- Comment #3 from anlauf at gmx dot de  2010-01-20 23:02 ---
Created an attachment (id=19669)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19669&action=view)
Partial patch for conversion at assignment

A patch that addresses the trivial part of the problem:
the conversions from kind(x) to kind(y), where x < y
Not too elegant, but works.


-- 


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

[Bug c++/41788] -Wpacked option changes the layout of packed non-POD structs

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2010-01-20 23:11 ---
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=41788

[Bug c++/42038] [4.3/4.4/4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p

[paolo at gcc dot gnu dot org]

--- Comment #8 from paolo at gcc dot gnu dot org  2010-01-20 23:12 ---
Subject: Bug 42038

Author: paolo
Date: Wed Jan 20 23:12:25 2010
New Revision: 156094

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156094
Log:
/cp
2010-01-20  Paolo Carlini  

PR c++/42038
* except.c (expand_start_catch_block): Deal correctly with
do_begin_catch returning error_mark_node.

/testsuite
2010-01-20  Paolo Carlini  

PR c++/42038
* g++.dg/parse/crash55.C: New.

Added:
trunk/gcc/testsuite/g++.dg/parse/crash55.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/except.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/42038] [4.3/4.4/4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2010-01-20 23:15 
---
Fixed for 4.5.0. Being just an ice-on-invalid will not be fixed in 4_3 / 4_4.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG

[rguenth at gcc dot gnu dot org]

--- Comment #25 from rguenth at gcc dot gnu dot org  2010-01-20 23:30 
---
Please close this bug if it is fixed.


-- 


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

[Bug c++/41970] use of a type with no linkage to declare a variable with linkage

[jason at gcc dot gnu dot org]

--- Comment #17 from jason at gcc dot gnu dot org  2010-01-20 23:32 ---
We accept this testcase with a warning because it is both common and harmless.

In 4.5, this testcase will be accepted with no warning in -std=c++0x mode, as
we now implement DR 757.


-- 

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|2010-01-11 18:52:09 |2010-01-20 23:32:16
   date||


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

[Bug c++/41970] use of a type with no linkage to declare a variable with linkage

[jason at gcc dot gnu dot org]

--- Comment #18 from jason at gcc dot gnu dot org  2010-01-20 23:36 ---
So, removing the accepts-invalid keyword.  I'll fix the diagnostic in 4.6.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|accepts-invalid |


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

[Bug libstdc++/42201] [C++0x] std::vector>::push_back fails

[redi at gcc dot gnu dot org]

--- Comment #9 from redi at gcc dot gnu dot org  2010-01-20 23:38 ---
patch posted as http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01126.html


-- 


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

[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG

[jingyu at google dot com]

--- Comment #26 from jingyu at google dot com  2010-01-20 23:48 ---
This bug is fixed in both trunk(4.5) and 4.4.
I will send a message to gcc-patches when I patch the test case.


-- 

jingyu at google dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/42201] [C++0x] std::vector>::push_back fails

[redi at gcc dot gnu dot org]

--- Comment #10 from redi at gcc dot gnu dot org  2010-01-21 00:02 ---
Subject: Bug 42201

Author: redi
Date: Thu Jan 21 00:01:47 2010
New Revision: 156097

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156097
Log:
2010-01-21  Jonathan Wakely  

PR libstdc++/42201
* include/std/future: Update to latest WP.
* src/functexcept.cc (__throw_future_error): Use make_error_code.
* testsuite/30_threads/async/any.cc: New.
* testsuite/30_threads/async/async.cc: New.
* testsuite/30_threads/async/sync.cc: New.
* testsuite/30_threads/packaged_task/cons/alloc.cc: New.
* testsuite/30_threads/packaged_task/cons/assign_neg.cc: Adjust.
* testsuite/30_threads/packaged_task/cons/copy_neg.cc: Adjust.
* testsuite/30_threads/packaged_task/members/get_future.cc: Adjust.
* testsuite/30_threads/packaged_task/members/get_future2.cc: Likewise.
* testsuite/30_threads/packaged_task/members/invoke.cc: Adjust.
* testsuite/30_threads/packaged_task/members/invoke2.cc: Adjust.
* testsuite/30_threads/packaged_task/members/invoke3.cc: Adjust.
* testsuite/30_threads/packaged_task/members/invoke4.cc: Adjust.
* testsuite/30_threads/packaged_task/members/reset.cc: Adjust.
* testsuite/30_threads/packaged_task/members/reset2.cc: Adjust.
* testsuite/30_threads/shared_future/cons/assign_neg.cc: Remove.
* testsuite/30_threads/shared_future/cons/default_neg.cc: Remove.
* testsuite/30_threads/shared_future/cons/default.cc: New.
* testsuite/30_threads/shared_future/cons/assign.cc: New.
* testsuite/30_threads/shared_future/cons/copy.cc: Adjust.
* testsuite/30_threads/shared_future/cons/move.cc: Adjust.
* testsuite/30_threads/shared_future/cons/move_assign.cc: New.
* testsuite/30_threads/shared_future/members/is_ready.cc: Remove.
* testsuite/30_threads/shared_future/members/has_value.cc: Remove.
* testsuite/30_threads/shared_future/members/has_exception.cc: Remove.
* testsuite/30_threads/shared_future/members/valid.cc: New.
* testsuite/30_threads/unique_future/cons/default_neg.cc: Remove.
* testsuite/30_threads/unique_future/cons/default.cc: New.
* testsuite/30_threads/unique_future/cons/move_assign.cc: New.
* testsuite/30_threads/unique_future/cons/assign_neg.cc: Adjust.
* testsuite/30_threads/unique_future/cons/copy_neg.cc: Adjust.
* testsuite/30_threads/unique_future/cons/move.cc: Adjust.
* testsuite/30_threads/unique_future/requirements/
explicit_instantiation.cc: Adjust.
* testsuite/30_threads/unique_future/members/is_ready.cc: Remove.
* testsuite/30_threads/unique_future/members/has_value.cc: Remove.
* testsuite/30_threads/unique_future/members/has_exception.cc: Remove.
* testsuite/30_threads/unique_future/members/valid.cc: New.
* testsuite/30_threads/unique_future/members/get.cc: Adjust.
* testsuite/30_threads/unique_future/members/get2.cc: Adjust.
* testsuite/30_threads/unique_future/members/wait.cc: Adjust.
* testsuite/30_threads/unique_future/members/wait_for.cc: Adjust.
* testsuite/30_threads/unique_future/members/wait_until.cc: Adjust.
* testsuite/30_threads/headers/future/types_std_c++0x.cc: Adjust.
* testsuite/30_threads/promise/cons/alloc.cc: New.
* testsuite/30_threads/promise/cons/assign_neg.cc: Adjust.
* testsuite/30_threads/promise/cons/copy_neg.cc: Adjust.
* testsuite/30_threads/promise/cons/move.cc: Adjust.
* testsuite/30_threads/promise/cons/move_assign.cc: Adjust.
* testsuite/30_threads/promise/members/get_future.cc: Adjust.
* testsuite/30_threads/promise/members/set_value.cc: Adjust.
* testsuite/30_threads/promise/members/set_exception.cc: Adjust.
* testsuite/30_threads/promise/members/set_exception2.cc: Adjust.
* testsuite/30_threads/promise/members/set_value2.cc: Adjust.
* testsuite/30_threads/promise/members/set_value3.cc: Adjust.
* testsuite/30_threads/promise/members/swap.cc: Adjust.


Added:
trunk/libstdc++-v3/testsuite/30_threads/async/
trunk/libstdc++-v3/testsuite/30_threads/async/any.cc
trunk/libstdc++-v3/testsuite/30_threads/async/async.cc
trunk/libstdc++-v3/testsuite/30_threads/async/sync.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/alloc.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/cons/alloc.cc
trunk/libstdc++-v3/testsuite/30_threads/shared_future/cons/assign.cc
trunk/libstdc++-v3/testsuite/30_threads/shared_future/cons/default.cc
trunk/libstdc++-v3/testsuite/30_threads/shared_future/cons/move_assign.cc
trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/valid.cc
trunk/libstdc++-v3/testsuite/30_threads/unique_future/cons/default.cc
trunk/libstdc++-v3/testsuite/30_threa

[Bug libstdc++/42201] [C++0x] std::vector>::push_back fails

[redi at gcc dot gnu dot org]

--- Comment #11 from redi at gcc dot gnu dot org  2010-01-21 00:06 ---
Fixed.  The testcase works if you replace unique_future with future.


-- 

redi 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=42201

[Bug other/42715] [4.5 Regression] output_operand: invalid expression as operand

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-01-21 00:42 ---
Subject: Bug 42715

Author: jakub
Date: Thu Jan 21 00:42:02 2010
New Revision: 156102

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156102
Log:
PR debug/42715
* var-tracking.c (use_type): Choose MO_VAL_SET for REGs set
without a cselib val.
(count_uses): Accept MO_VAL_SET with no val on stores.
(add_stores): Likewise.

* gcc.dg/pr42715.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr42715.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/var-tracking.c


-- 


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

[Bug libstdc++/36101] deps on other host libraries incorrect

[amylaar at gcc dot gnu dot org]

--- Comment #6 from amylaar at gcc dot gnu dot org  2010-01-21 00:53 ---
The configuration test can be replaced with some configure / makefile
hackery, but this doesn't help:
he compilation of libstdc++-v3 also depends on the header file:

/bin/sh ../libtool --tag CXX   --mode=compile
/user/inria/fsf/bld-gcc-cxx13/./gcc/xgcc -shared-libgcc
-B/user/inria/fsf/bld-gcc-cxx13/./gcc -nostdinc++
-L/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/src
-L/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/user/inria/cxx/i686-pc-linux-gnu/bin/
-B/user/inria/cxx/i686-pc-linux-gnu/lib/ -isystem
/user/inria/cxx/i686-pc-linux-gnu/include -isystem
/user/inria/cxx/i686-pc-linux-gnu/sys-include
-I/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include
-I/user/inria/fsf/gcc/libstdc++-v3/libsupc++  -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual  -fdiagnostics-show-location=once 
-ffunction-sections -fdata-sections  -g -O2 -D_GNU_SOURCE -fopenmp
-D_GLIBCXX_PARALLEL
-I/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/../libgomp -c
../../../../gcc/libstdc++-v3/src/parallel_list.cc
libtool: compile:  /user/inria/fsf/bld-gcc-cxx13/./gcc/xgcc -shared-libgcc
-B/user/inria/fsf/bld-gcc-cxx13/./gcc -nostdinc++
-L/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/src
-L/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/user/inria/cxx/i686-pc-linux-gnu/bin/
-B/user/inria/cxx/i686-pc-linux-gnu/lib/ -isystem
/user/inria/cxx/i686-pc-linux-gnu/include -isystem
/user/inria/cxx/i686-pc-linux-gnu/sys-include
-I/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include
-I/user/inria/fsf/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -fopenmp
-D_GLIBCXX_PARALLEL
-I/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/../libgomp -c
../../../../gcc/libstdc++-v3/src/parallel_list.cc  -fPIC -DPIC -o
.libs/parallel_list.o
In file included from
/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include/parallel/algobase.h:40:0,
 from
/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:1155,
 from
/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include/list:61,
 from ../../../../gcc/libstdc++-v3/src/list.cc:51,
 from ../../../../gcc/libstdc++-v3/src/parallel_list.cc:25:
/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include/parallel/base.h:37:17:
fatal error: omp.h: No such file or directory


-- 


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

[Bug libstdc++/36101] deps on other host libraries incorrect

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2010-01-21 01:32 
---
At this time I don't know --enable-build-with-cxx enough to contribute much to
the solution of the specific issue having to to with that configure option,
just wanted to point out that normal uses of the library don't need the
parallel mode facilities, thus anything having to do with it could be left out,
in particular src/parallel_list.cc. I'm assuming of course that even when that
option is used eventually a normal C++ library is built and installed.

Anyway, the issue here, in this specific PR, seems different, is about building
libgomp before libstdc++-v3 in normal GCC builds and I'm not sure that this
makes sense also with --enable-build-with-cxx...


-- 


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

[Bug c++/42338] [c++0x] ICE on decltype usage with templates

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2010-01-21 01:59 ---
Subject: Bug 42338

Author: jason
Date: Thu Jan 21 01:58:53 2010
New Revision: 156103

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156103
Log:
PR c++/42338
* mangle.c (write_expression): Handle tree codes that have extra
arguments in the middle-end.
* cp-demangle.c (d_print_comp): Fix array index printing.

Added:
trunk/gcc/testsuite/g++.dg/abi/mangle39.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c


-- 


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

[Bug target/42818] New: Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)

[davek at gcc dot gnu dot org]

[ Don't Panic.  There is already a fix for this bug, in fact two, one that is
suitable for our current Stage 3(4?) status but slightly suboptimal, another
that is better but blocked by an existing PR that won't be fixed until next
Stage1.  I just figured I should say that first of all. ]

There's a problematic interaction between the parts of cygwin backend's linker
specs, the cygwin libc CRT startup code, and the backend's support for N2800
#17.6.4.6 [replacement.functions].  When linking C++ executables statically,
this leads to symptoms such as those reported here:

http://cygwin.com/ml/cygwin/2009-12/msg00583.html

/tmp/winsup/i686-pc-cygwin/winsup/cygwin/libcygwin.a(_cygwin_crt0_common.o):_cyg
> win_crt0_common.cc:(.data+0x0): undefined reference to `___real__Znwj'
> /tmp/winsup/i686-pc-cygwin/winsup/cygwin/libcygwin.a(_cygwin_crt0_common.o):_cyg
> win_crt0_common.cc:(.data+0x4): undefined reference to `___real__Znaj'
> /tmp/winsup/i686-pc-cygwin/winsup/cygwin/libcygwin.a(_cygwin_crt0_common.o):_cyg
> win_crt0_common.cc:(.data+0x8): undefined reference to `___real__ZdlPv'
> collect2: ld returned 1 exit status
> make[1]: *** [cygserver.exe] Error 1

The particular functions reported as undefined will be whatever subset of the
replaceable new/delete operators are referenced in the executable and drawn
into the final link.

I'll post analysis, patches and test results as separate comments.  I've not
set the severity of this bug any higher than "normal" because it's
already/about-to-be fixed, but I'm going to leave it open after applying the
stage3-suitable fix to remind me to apply the more optimal one when we return
to stage 1 and Bug 41594 and/or Bug 41596 get fixed.


-- 
   Summary: Static C++ linking breakage "undefined reference to
___real__Znwj" and others in
libcygwin.a(_cygwin_crt0_common.o)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: missed-optimization, link-failure
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: davek at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
 BugsThisDependsOn: 41594,41596


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

[Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)

[davek at gcc dot gnu dot org]

--- Comment #1 from davek at gcc dot gnu dot org  2010-01-21 03:20 ---
Test results:

clean h...@155967, default test configuration using shared C++ linking:
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01628.html

clean h...@155967, tested using static C++ linking:
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01900.html

patched h...@155967, tested with static linking and the simple stage-3-safe
fix:
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01901.html


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-21 03:20:38
   date||


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

[Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)

[davek at gcc dot gnu dot org]

--- Comment #2 from davek at gcc dot gnu dot org  2010-01-21 03:57 ---
Here's what's going on:

- To implement operator new/delete replacement, we use ld and --wrap to
redirect all references to the operator functions into redirection stubs in the
cygwin dll.

- Each DLL or executable records a list of which (if any) of those operators it
provides replacements for.  It does this with an array of function pointers in
a part of the CRT pre-main() startup.  In the array are weak references to all
the replaceable operators; any for which overrides are visible at final-link
time will get filled out with the addresses of those overrides, and the
weakness of the references means they won't cause any functions that aren't
already present in the final link to be pulled in from libraries.  The
references assign asm names to the symbols that use the "__real__" prefix in
order that they don't see the Cygwin DLL wrapper functions, just the real
actual implementations present.

- As an optimisation, we don't apply the wrapper redirection when linking
statically.  That's because there's no need; any function replacement overrides
present in the final link will just automatically override the libstdc++
versions by preventing them from ever being pulled out of the static libstdc++
archive at final-link time.


That's all fine as it stands, but:-

- Some recent optimisation of EH generation had the effect that, where
previously every C++ object was always emitted with a reference to the gxx eh
personality function, this reference is now only emitted when strictly needed.

- This means that for the first time it became possible that the only
references to libstdc++ in a C++ executable undergoing final link might be
references to the operator new/delete function(s).

- Since these are all redirected to the wrappers in the Cygwin DLL, that can
mean there are no unresolved references to pull in anything at all from the
libstdc++ import library, and so the resulting executable does not depend on
nor cause the libstdc++ dll to be loaded into memory, meaning that the real
versions of the replacement functions that the redirect stubs need to redirect
to aren't present!

- So, the way to prevent that is by also emitting an extern reference to the
real version of the operator function in question, which causes the DLL to be
imported (even though the imports aren't used directly but only via the
redirection stubs in the DLL; the important point being that you have to load
libstdc++ so that it can register the default versions of all the operators
using its own array of weak (but fully-filled-out) function pointers.  This is
done in gcc/config/i386/winnt.c, in i386_pe_file_end().

- And that's where it goes wrong.  The compiler doesn't know at the time it's
emitting assembly whether the final object will be statically linked or not, so
it really has no choice but to emit the reference; but if it does end up being
statically linked, the wrappers aren't in effect, so there is no "__real__*"
function.

-  That wouldn't be a problem: the toolchain doesn't care about the undefined
symbol, because no relocs reference it, and the runtime loader doesn't give a
stuff about symbols at all, caring only about the import and export tables.

- Except for one final gotcha.  Because the undefined references that are
emitted to cause the DLL to be loaded are strong undefs - they have to be,
since they have to cause an import stub to be pulled in from a library archive.
 So even though there are no relocs in the object that contains the strong
undef, it has the knock-on effect that the weak references in the array of
function pointers become strong.  And that's where the link failure arises.


-- 


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

[Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)

[davek at gcc dot gnu dot org]

--- Comment #3 from davek at gcc dot gnu dot org  2010-01-21 04:00 ---
Created an attachment (id=19670)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19670&action=view)
Simple stage-3-safe fix

This is the simple fix that is safe for stage 3.  By trivially tweaking the
specs, we remove the don't-redirect-via-wrappers-if-statically-linking
optimisation.

This is a minor performance hit, but correctness combines with the need for
low-risk changes in stage 3 to win out here.  I'll talk about the more optimal
fix (and the complications that mean it has to wait for next stage 1) next.

As I've already run all the tests, and as I've just been appointed a
maintainer, I'll check this in shortly :-)


-- 


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