--- Comment #3 from jakub at gcc dot gnu dot org 2010-04-27 06:16 ---
It depends on what the platform allows, I'm not familiar with it at all.
If you can force dumping core and getting backtrace from it, that would be
interesting info, if you can preload some library to print backtrace
--- Comment #1 from manu at gcc dot gnu dot org 2010-04-27 07:27 ---
Bonus points if the C/C++ FE share most of the code related to this warning (so
we only have one place to fix in the future).
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from janus at gcc dot gnu dot org 2010-04-27 07:38 ---
Subject: Bug 43896
Author: janus
Date: Tue Apr 27 07:38:06 2010
New Revision: 158767
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158767
Log:
2010-04-27 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #11 from janus at gcc dot gnu dot org 2010-04-27 07:41 ---
The commit in comment #10 fixes the fortran-dev regression, but not the
original problem in comment #0.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ktietz at gcc dot gnu dot org 2010-04-27 07:52 ---
(In reply to comment #2)
As it turns out, the ICE only manifests in a parallel build. I tried make -j
8,
my default and make -j 3.
For an ordinary make there is no issue. So, I'm curious how to handle this.
Any
--- Comment #21 from burnus at gcc dot gnu dot org 2010-04-27 08:41 ---
Subject: Bug 18918
Author: burnus
Date: Tue Apr 27 08:41:00 2010
New Revision: 158768
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158768
Log:
2010-04-27 Tobias Burnus bur...@net-b.de
PR
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-27 09:25 ---
It's not a bug. const restrict doesn't say anything special and restrict
only disambiguates against other restrict pointers. Thus, the store through
a _can_ modify what b points to.
--
rguenth at gcc dot gnu
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-27 09:30 ---
local statics need to be mangled before SRA changes the function signature.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43903
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-27 09:33 ---
(In reply to comment #1)
Some further investigation shows that there is code in expand_expr_real_2 that
is supposed to be able to generate multiply-accumulate instructions, but it
isn't general enough. In my
--- Comment #8 from bernds at gcc dot gnu dot org 2010-04-27 09:34 ---
Subject: Bug 40657
Author: bernds
Date: Tue Apr 27 09:34:08 2010
New Revision: 158771
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158771
Log:
PR target/40657
* config/arm/arm.c
--- Comment #9 from bernds at gcc dot gnu dot org 2010-04-27 09:35 ---
Fixed.
--
bernds at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-27 09:36 ---
I can't get it to FAIL either. Tried various -march=XXX in
make check-gcc RUNTESTFLAGS=--target_board=unix/-m32/-march=atom
compile.exp=pr42196-2.c
HJ, what arch do you configure for?
--
--- Comment #14 from dominiq at lps dot ens dot fr 2010-04-27 09:38 ---
If the testsuite run produces nothing, can you check the object files of the
two stage2 compilers (working and broken) for differences in code generation?
That could help narrow down which file is being
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-27 09:41 ---
The ICE has been fixed on the trunk (PR42653). With the fix we now run into
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:21433
Please submit a full bug report,
with preprocessed source if
--
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
--- Comment #2 from alexey dot salmin at gmail dot com 2010-04-27 09:46
---
restrict only disambiguates against other restrict pointers.
Can you please support that assertion with a reference?
ISO/IEC 9899:TC2 Committee Draft May 6, 2005, 6.7.3 paragraph 7
An object that is
--- Comment #15 from bernds at gcc dot gnu dot org 2010-04-27 09:47 ---
Thanks. Could you attach those object files (ignoring ifcvt.o since it
obviously changes due to the source change)?
Even better would be if you could produce assembly output by finding the
command that produced
--- Comment #10 from jamborm at gcc dot gnu dot org 2010-04-27 10:08
---
Subject: Bug 43812
Author: jamborm
Date: Tue Apr 27 10:07:47 2010
New Revision: 158777
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158777
Log:
2010-04-27 Martin Jambor mjam...@suse.cz
PR
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-27 10:26 ---
The commit in comment #10 fixes the fortran-dev regression, but not the
original problem in comment #0.
The original problem in comment #0 is probably a duplicate of pr42051 both
fails with
internal compiler
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-27 10:33 ---
(In reply to comment #2)
restrict only disambiguates against other restrict pointers.
Can you please support that assertion with a reference?
ISO/IEC 9899:TC2 Committee Draft May 6, 2005, 6.7.3 paragraph 7
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-27 10:37 ---
Which would be implemented by
Index: gcc/tree-ssa-alias.c
===
--- gcc/tree-ssa-alias.c(revision 158770)
+++ gcc/tree-ssa-alias.c
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-27 10:38 ---
Note that the patches will break Fortran quite seriously.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43907
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-27 11:17 ---
WONTFIX on the 4.3 branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-04-27 11:27
---
Subject: Bug 40561
Author: rguenth
Date: Tue Apr 27 11:27:18 2010
New Revision: 158778
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158778
Log:
2010-04-27 Richard Guenther rguent...@suse.de
PR
The following code:
struct A { int r0; int r1; };
void sigh(struct A *a, const int d)
{
int i;
for (i = 0; i 8; ++i) {
if (d (1U i))
a-r0 = 1;
else
a-r1 = 1;
}
}
compiled using
../../g++-4.5.svn/gcc/tree-ssa-structalias.c: In function 'constraint_expr
get_function_part_constraint(variable_info*, unsigned int)':
../../g++-4.5.svn/gcc/tree-ssa-structalias.c:3644:29: error: enumeral and
non-enumeral type in conditional expression [-Werror]
cc1plus: all warnings being
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-27 12:11 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-04-27 12:14 ---
Subject: Bug 43116
Author: rguenth
Date: Tue Apr 27 12:13:52 2010
New Revision: 158781
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158781
Log:
2010-04-27 Richard Guenther rguent...@suse.de
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-04-27 12:16
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-04-27 12:16 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-27 12:16
---
Subject: Bug 38564
Author: rguenth
Date: Tue Apr 27 12:15:53 2010
New Revision: 158782
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158782
Log:
2010-04-27 Richard Guenther rguent...@suse.de
--- Comment #13 from fmartinez at gmv dot com 2010-04-27 12:56 ---
I have not got that far to the linking step. I am converting some code to a
more OOP style.
I have tried to patch my local version but unfrtunately what I have downloaded,
4.5_20100422 and 4.5_20100424, do not seem to
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-27 13:07 ---
Ooops. I meant Linux/ia64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43901
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet||ia64-*-*
Target Milestone|--- |4.6.0
On Linux/ia32, revision 158765 gave
FAIL: gcc.dg/Walways-true-1.c (test for excess errors)
FAIL: gcc.dg/Walways-true-1.c correct warning (test for warnings, line 29)
FAIL: gcc.dg/Walways-true-1.c correct warning (test for warnings, line 33)
FAIL: gcc.dg/Walways-true-1.c correct warning (test for
--- Comment #5 from rainer at emrich-ebersheim dot de 2010-04-27 13:15
---
(In reply to comment #4)
(In reply to comment #2)
As it turns out, the ICE only manifests in a parallel build. I tried make
-j 8,
my default and make -j 3.
For an ordinary make there is no issue. So,
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43910
--- Comment #14 from burnus at gcc dot gnu dot org 2010-04-27 13:30 ---
(In reply to comment #13)
I have not got that far to the linking step. I am converting some code to a
more OOP style. I have tried to patch my local version but unfrtunately what
I have downloaded, 4.5_20100422
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-27 13:58 ---
Fixed by revision 158769.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #22 from hjl dot tools at gmail dot com 2010-04-27 13:59
---
On Linux/ia32, I got
FAIL: gfortran.dg/coarray_12.f90 -O scan-tree-dump-times original
a.dim.0..ubound = .* nn; 1
FAIL: gfortran.dg/coarray_12.f90 -O scan-tree-dump-times original
a.dim.1..ubound = .* mm; 1
--- Comment #23 from burnus at gcc dot gnu dot org 2010-04-27 14:09 ---
Subject: Bug 18918
Author: burnus
Date: Tue Apr 27 14:09:29 2010
New Revision: 158785
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158785
Log:
2010-04-27 Tobias Burnus bur...@net-b.de
PR
--- Comment #4 from pluto at agmk dot net 2010-04-27 14:10 ---
(In reply to comment #3)
Sorry:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01166.html
--enable-build-with-cxx will change the plugin framework interface to match
the C++ plugin symbol mangling but in such case users
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-27 15:19 ---
C++ plugins are not supported. They only happen to work with the
build-gcc-with-c++ trick.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from dominiq at lps dot ens dot fr 2010-04-27 15:24 ---
Thanks. Could you attach those object files (ignoring ifcvt.o since it
obviously changes due to the source change)?
Even better would be if you could produce assembly output by finding the
command that
--- Comment #17 from dominiq at lps dot ens dot fr 2010-04-27 15:27 ---
Created an attachment (id=20499)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20499action=view)
bziped tar file containing the *.i and *.s files
The *_f.* files corresponds to the failing bootstrap and the
The test code which fails to compile with g++ on both 4.4.3 and 4.5.0:
#include iostream
int main(void)
{
std::cout Hello. std::endl;
return 0;
}
$ gcc test.c++
/usr/lib/gcc/powerpc-gnu-linux-uclibc/4.5.0/../../../libstdc++.so: undefined
reference to `_Unwind_GetIPInfo'
--- Comment #11 from dougmencken at gmail dot com 2010-04-27 17:07 ---
GCC 4.5.0 bootstraps without --disable-checking (Configured with: ./configure
--prefix=/usr --sysconfdir=/etc
--mandir=/usr/share/man --build=powerpc-gnu-linux-uclibc
--host=powerpc-gnu-linux-uclibc
--- Comment #1 from redi at gcc dot gnu dot org 2010-04-27 17:15 ---
that symbol is defined in libgcc_s.so - is that file present in the same
directory as libstdc++.so?
If you add -v to the compilation command it will show you the directories gcc
searches, is libgcc_s.so in any of those
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-27 17:16 ---
oh wait a second ... what happens if you compile with g++ not gcc?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43911
--- Comment #3 from dougmencken at gmail dot com 2010-04-27 17:18 ---
I do not compile c++ sources with gcc. Yes, I mistyped gcc instead of g++ in
the first message, sorry.
$ g++ test.c\+\+
/usr/lib/gcc/powerpc-gnu-linux-uclibc/4.5.0/../../../libstdc++.so: undefined
reference to
--- Comment #4 from dougmencken at gmail dot com 2010-04-27 17:20 ---
$ g++ -v test.c\+\+
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-gnu-linux-uclibc/4.5.0/lto-wrapper
Target: powerpc-gnu-linux-uclibc
Configured with: ./configure --prefix=/usr
--- Comment #5 from dougmencken at gmail dot com 2010-04-27 17:28 ---
$ find / -name libgcc_s.so
/usr/lib/libgcc_s.so
$ objdump -x /usr/lib/libgcc_s.so
objdump: /usr/lib/libgcc_s.so: File format not recognized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43911
--- Comment #3 from jv244 at cam dot ac dot uk 2010-04-27 18:07 ---
still fails with current trunk.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-04-27 18:08 ---
See PR 14192 on why this is restrict is ignored here.
*** This bug has been marked as a duplicate of 14192 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-04-27 18:08
---
*** Bug 43907 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jv244 at cam dot ac dot uk 2010-04-27 18:25 ---
the original loop gets now (4.6.0) vectorized, and gets the same performance as
the 'hand optimized loop' (which does not get vectorized):
./a.out
default loop 0.880055003
hand optimized loop
--- Comment #13 from jason at gcc dot gnu dot org 2010-04-27 18:56 ---
Subject: Bug 42844
Author: jason
Date: Tue Apr 27 18:56:13 2010
New Revision: 158797
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158797
Log:
PR c++/42844
* decl.c
--- Comment #2 from jason at gcc dot gnu dot org 2010-04-27 19:04 ---
Subject: Bug 41468
Author: jason
Date: Tue Apr 27 19:04:09 2010
New Revision: 158798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158798
Log:
PR c++/41468
* class.c (convert_to_base): Add
--- Comment #3 from jason at gcc dot gnu dot org 2010-04-27 19:04 ---
Subject: Bug 41468
Author: jason
Date: Tue Apr 27 19:04:23 2010
New Revision: 158799
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158799
Log:
PR c++/41468
* call.c (convert_like_real)
--- Comment #12 from dougmencken at gmail dot com 2010-04-27 19:13 ---
$ cat /usr/lib/libgcc_s.so
/* GNU ld script
Use the shared library, but some functions are only in
the static library. */
GROUP ( libgcc_s.so.1 libgcc.a )
$ readelf -s /usr/lib/libgcc_s.so.1 | grep Unwind
--- Comment #6 from dougmencken at gmail dot com 2010-04-27 19:15 ---
$ cat /usr/lib/libgcc_s.so
/* GNU ld script
Use the shared library, but some functions are only in
the static library. */
GROUP ( libgcc_s.so.1 libgcc.a )
$ readelf -s /usr/lib/libgcc_s.so.1 | grep Unwind
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-04-27 19:17 ---
Are you sure that the newly built libgcc_s.so.1 is being installed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43911
--- Comment #8 from dougmencken at gmail dot com 2010-04-27 19:22 ---
Yes, I'm sure, I'm using http://manulix.wikidot.com/files:prepare-mx-chroot-sh
script with --fresh option, so I do always have a fresh chroot environment in 5
minutes for powerpc uclibc, and I can also easily switch
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-04-27 19:42
---
Closing then.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-04-27 19:48
---
*** Bug 43091 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-04-27 19:48 ---
*** This bug has been marked as a duplicate of 34640 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from justin at mattair dot net 2010-04-27 19:52 ---
I have upgraded this to critical because it causes data corruption and because
I am not certain how to classify this. Lower if needed.
--
justin at mattair dot net changed:
What|Removed
It would be nice for gdb users if any variables captured by a lambda
were described in the debuginfo for the inner function.
See http://sourceware.org/bugzilla/show_bug.cgi?id=11547
--
Summary: lambda debug info does not describe captured variables
Product: gcc
--- Comment #13 from dominiq at lps dot ens dot fr 2010-04-27 20:08 ---
As pointed out in comment #10 pr38471 is a duplicate of this one, as well as
pr42851 (see comment #1 of pr43091). They all give the same backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
--- Comment #5 from jason at gcc dot gnu dot org 2010-04-27 20:09 ---
Subject: Bug 43790
Author: jason
Date: Tue Apr 27 20:08:47 2010
New Revision: 158801
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158801
Log:
PR c++/43790
* tree.c (cv_unqualified): Handle
c_lto_20100423-2_0.o-c_lto_20100423-2_1.o link
=== gcc Summary ===
# of expected passes479
# of unexpected failures17
# of unresolved testcases 24
# of unsupported tests 2
/Users/stevenb/lto_objdir/gcc/xgcc version 4.6.0 20100427 (experimental
--- Comment #9 from dougmencken at gmail dot com 2010-04-27 20:35 ---
$ objcopy --globalize-symbol _Unwind_GetIPInfo /usr/lib/libgcc_s.so.1
/usr/lib/libgcc_s.so.2
$ readelf -s /usr/lib/libgcc_s.so.2 | grep _Unwind_GetIPInfo
240: bd8020 FUNCGLOBAL DEFAULT9
/home/manuel/src/test/gcc/testsuite/g++.dg/template/recurse3.C: In
instantiation of const int Y1000::value:
/home/manuel/src/test/gcc/testsuite/g++.dg/template/recurse3.C:17:17:
instantiated from here
/home/manuel/src/test/gcc/testsuite/g++.dg/template/recurse3.C:13:46: error:
expression
--- Comment #10 from dougmencken at gmail dot com 2010-04-27 20:48 ---
And may I repeat, please? It's definitely not-x86[_64] bug. I don't know can it
be revealed with cross toolchain (because all of you do test gcc only and only
on x86[_64] as host).
So, if you don't have an access to
Following code causes output Strange instead of the expected A:
#include stdio.h
typedef enum {a, b, c} k;
k s;
int main()
{
s = a;
switch(s)
{
a:
printf(A\n);
b:
printf(B\n);
c:
printf(C\n);
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-27 20:54 ---
a:
That defines a label called a rather than a case statement. You want case a:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jason at gcc dot gnu dot org 2010-04-27 21:21 ---
Subject: Bug 43875
Author: jason
Date: Tue Apr 27 21:21:35 2010
New Revision: 158805
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158805
Log:
PR c++/43875
* semantics.c (lambda_return_type):
--- Comment #2 from jason at gcc dot gnu dot org 2010-04-27 21:26 ---
Subject: Bug 43856
Author: jason
Date: Tue Apr 27 21:26:25 2010
New Revision: 158807
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158807
Log:
PR c++/43856
* name-lookup.c (qualify_lookup):
--- Comment #15 from janus at gcc dot gnu dot org 2010-04-27 21:40 ---
I've reduced the test case to the bare minimum required to trigger the ICE:
module m_rotation_matrix
type t_rotation_matrix
end type
contains
function rotation_matrix_times_vector( left ) result(res)
--- Comment #18 from bernds at gcc dot gnu dot org 2010-04-27 22:27 ---
Thanks for all the information. However, I'm still puzzled. Here's the
situation.
Thanks to your information, I think I can reproduce how the assembly files are
generated:
./cc1 -feliminate-unused-debug-symbols
--- Comment #3 from redi at gcc dot gnu dot org 2010-04-27 22:27 ---
Created an attachment (id=20501)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20501action=view)
patch to fix freestanding build
this seems to fix the non-hosted build
--
redi at gcc dot gnu dot org changed:
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-27 22:33 ---
This was caused by http://gcc.gnu.org/viewcvs?view=revisionrevision=146604 and
I think it's a simple typo
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from siarhei dot siamashka at gmail dot com 2010-04-27
22:44 ---
#pragma GCC target|optimize just does not seem to work with C++. Just
stumbled on it trying to narrow down something that looks like wrong-code
generation bug in gcc 4.5.0 when compiling qt4.
Prepending
--- Comment #5 from redi at gcc dot gnu dot org 2010-04-27 22:54 ---
Subject: Bug 43865
Author: redi
Date: Tue Apr 27 22:54:13 2010
New Revision: 158812
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158812
Log:
2010-04-27 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #3 from jason at gcc dot gnu dot org 2010-04-27 23:03 ---
Subject: Bug 43875
Author: jason
Date: Tue Apr 27 23:02:56 2010
New Revision: 158814
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158814
Log:
PR c++/43875
* semantics.c (lambda_return_type):
--- Comment #3 from jason at gcc dot gnu dot org 2010-04-27 23:03 ---
Subject: Bug 43856
Author: jason
Date: Tue Apr 27 23:03:06 2010
New Revision: 158815
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158815
Log:
PR c++/43856
* name-lookup.c (qualify_lookup):
--- Comment #6 from redi at gcc dot gnu dot org 2010-04-27 23:30 ---
Subject: Bug 43865
Author: redi
Date: Tue Apr 27 23:30:21 2010
New Revision: 158816
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158816
Log:
2010-04-27 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #7 from redi at gcc dot gnu dot org 2010-04-27 23:31 ---
fixed for 4.5.1 and 4.6.0
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jason at gcc dot gnu dot org 2010-04-28 00:03 ---
Subject: Bug 29043
Author: jason
Date: Wed Apr 28 00:03:21 2010
New Revision: 158817
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158817
Log:
PR c++/29043
* init.c (perform_member_init): check
Compilation of boost_1_42_0 fails with errors.
bash-3.2# g++ --version
g++ (GCC) 4.5.0
bash-3.2# g++ -ftemplate-depth-128 -finline-functions -Wno-inline -Wall
-dynamic -std=gnu++0x -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_DLL=1
-DBOOST_THREAD_POSIX -DNDEBUG -I. -c -o
--- Comment #1 from mlrus at mac dot com 2010-04-28 01:01 ---
bash-3.2# cat build.2.log
Building the Boost C++ Libraries.
After the build, the headers will be located at
/usr/local/boost_1_42_0
The libraries will be located at
/usr/local/boost_1_42_0/stage/lib
Use 'bjam
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-28 02:00 ---
Can you attach the preprocessed source? This might be an issue with boost.
There was a change with respect to rvalue references; lvalues cannot bind to
rvalue references. The C++0x standard is changing still so
Simple programs like the following do not compile under -std=c++0x on GCC 4.5.0
- due to the new GCC enforcement of C++0x rules regarding l-values not being
allowed to bind to .
#include iostream
#include math.h
int main(int argc, char** argv)
{
std::pair std::string, std::string x(hello,
Simple programs like the following do not compile under -std=c++0x on GCC 4.5.0
- due to the new GCC enforcement of C++0x rules regarding l-values not being
allowed to bind to .
#include iostream
#include math.h
int main(int argc, char** argv)
{
std::pair std::string, std::string x(hello,
95 matches
Mail list logo
