[Bug middle-end/42874] [4.5 Regression] Error on correct code: sorry, unimplemented: function �foo� can never be copied because it uses
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-27 08:39 ---
The question is why we can't inline it, when clearly 4.4 branch can inline it
just fine.
The 4.4 comment says:
/* We cannot inline a function of the form
void F (int i) { struct S { int ar[i]; } s; }
Attempting to do so produces a catch-22.
If walk_tree examines the TYPE_FIELDS chain of RECORD_TYPE/
UNION_TYPE nodes, then it goes into infinite recursion on a
structure containing a pointer to its own type. If it doesn't,
then the type node for S doesn't get adjusted properly when
F is inlined.
??? This is likely no longer true, but it's too late in the 4.0
cycle to try to find out. This should be checked for 4.1. */
As 4.4 walk_tree didn't end up with endless recursion on it, I wonder whether
we just can't remove this. Note that inlining functions that return variably
modified type might still be problematic, but that's order of magnitude rarer
(especially because I think most of GCCs so far ICEd on such code).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42874
[Bug middle-end/42874] [4.5 Regression] Error on correct code: sorry, unimplemented: function �foo� can never be copied because it uses
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-27 08:43 --- (In reply to comment #2) The question is why we can't inline it, when clearly 4.4 branch can inline it just fine. Note that comment is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25566 :). At one point I was going through all the FIXME/??? in gcc and filing bug reports since comments did not get a looking at really once they were written. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42874
[Bug middle-end/42874] [4.5 Regression] Error on correct code: sorry, unimplemented: function �foo� can never be copied because it uses
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-27 08:51 --- Seems the hack not to inline such functions (but until 4.4 always_inline won over it) has been added for PR6994, which has been fixed in a different way anyway. And obviously we are now copying/remapping stuff containing VLAs, e.g. omp-low.c does that. So I'd say we should just nuke that restriction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42874
[Bug middle-end/42874] [4.5 Regression] Error on correct code: sorry, unimplemented: function �foo� can never be copied because it uses
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-27 09:07 --- Created an attachment (id=19723) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19723action=view) gcc45-pr42874.patch I think we should just do this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42874
[Bug target/42671] Thumb2 generate more instructions than Thumb1 to load GOT address
--- Comment #1 from nickc at gcc dot gnu dot org 2010-01-27 09:19 --- Subject: Bug 42671 Author: nickc Date: Wed Jan 27 09:19:36 2010 New Revision: 156276 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156276 Log: PR target/42671 * config/arm/arm.c (arm_load_pic_register): Use the same code sequence with Thumb2 as for Thumb1. * config/arm/arm.md (pic_add_dot_plus_four): Enable this pattern for all Thumb varieties. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42671
[Bug debug/42800] [4.5 Regression] VLA DW_AT_upper_bound is no longer emitted
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42800
[Bug middle-end/42874] [4.5 Regression] Error on correct code: sorry, unimplemented: function �foo� can never be copied because it uses
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-27 10:24 --- Works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42874
[Bug target/42879] Replace tst r3, 1 with lsl r3, r3, 31 in thumb2
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-27 10:25 --- Could be done in a peephole if there's a scratch available for the destination. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-27 10:25:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42879
[Bug c++/42871] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #5 from redi at gcc dot gnu dot org 2010-01-27 10:27 --- ICE with at 4.4.3 and -O3 but not 4.4.2 or -O2 -- redi at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.4.3 Known to work||4.4.2 Last reconfirmed|-00-00 00:00:00 |2010-01-27 10:27:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug c++/42880] New: trunk does not compile boost MPL
gcc version 4.5.0 20100126 (rev. 156253) is not able to compile the following program: #include boost/mpl/size.hpp version 20100115 didn't complain. I've checked it on boost 1.37 and 1.39. For those who don't have boost installed, there is a preprocessed file from boost 1.39. -- Summary: trunk does not compile boost MPL Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: piotr dot wyderski at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug tree-optimization/42878] -fcompare-debug failure at -O1 (2)
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-27 10:42 --- Confirmed. It's loop header copying, or rather gimple_duplicate_sese_region, that causes SSA name differences. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-27 10:42:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42878
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #1 from piotr dot wyderski at gmail dot com 2010-01-27 10:43 --- Created an attachment (id=19724) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19724action=view) preprocessed boost 1.39 mpl/size.hpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #2 from piotr dot wyderski at gmail dot com 2010-01-27 10:44 --- Created an attachment (id=19725) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19725action=view) compiler error output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42871] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #6 from jakub at gcc dot gnu dot org 2010-01-27 10:46 --- Reducing. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2010-01-27 10:27:46 |2010-01-27 10:46:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug fortran/42647] Missed initialization/dealloc of allocatable scalar DT with allocatable component
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|burnus at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42647
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-27 10:57 --- I'm seeing two problems here: on x86_64-linux I can see only the last error, about specialization / redefinition, can well be a non-bug but can also be a regression, I'm CC-ing Dodji about it; plus, apparently something is specifically going wrong on cygwin at configure time, I see char_16t etc issues. I'm CC-ing two cygwin maintainers about it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||dave dot korn dot cygwin at ||gmail dot com, dannysmith at ||users dot sourceforge dot ||net, dodji at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug inline-asm/42881] New: SSE2 intrinsics miscompiled at -O0 -march=k8
A simple test program, a.c:
#include stdio.h
#include emmintrin.h
int main(void) {
double a[2];
__m128d x = _mm_set1_pd(3);
_mm_storeu_pd(a,x);
printf(%f %f\n,a[0],a[1]);
return 0;
}
$ gcc-4.5 -O0 -march=k8 a.c ./a.out # broken
0.00 0.00
$ gcc-4.5 -O1 -march=k8 a.c ./a.out # good
3.00 3.00
$ gcc-4.5 -O0 -march=core2 a.c ./a.out # good
3.00 3.00
$ gcc-4.5 -O0 -march=k8 -c a.c objdump -d -M intel --prefix-addresses a.o |
grep main
main push rbp
0001 main+0x1 movrbp,rsp
0004 main+0x4 subrsp,0x40
0008 main+0x8 movrax,0x4008
0012 main+0x12 movQWORD PTR [rbp-0x8],rax
0016 main+0x16 movsd xmm2,xmm1
001a main+0x1a unpcklpd xmm2,xmm2
001e main+0x1e movapd xmm0,xmm2
0022 main+0x22 movlpd xmm1,QWORD PTR [rbp-0x8]
0027 main+0x27 movaps XMMWORD PTR [rbp-0x40],xmm0
002b main+0x2b movapd xmm0,XMMWORD PTR [rbp-0x40]
0030 main+0x30 learax,[rbp-0x30]
0034 main+0x34 movQWORD PTR [rbp-0x10],rax
0038 main+0x38 movaps XMMWORD PTR [rbp-0x20],xmm0
003c main+0x3c movrax,QWORD PTR [rbp-0x10]
0040 main+0x40 movapd xmm0,XMMWORD PTR [rbp-0x20]
0045 main+0x45 movupd XMMWORD PTR [rax],xmm0
0049 main+0x49 movlpd xmm1,QWORD PTR [rbp-0x28]
004e main+0x4e movlpd xmm0,QWORD PTR [rbp-0x30]
0053 main+0x53 moveax,0x0
0058 main+0x58 movrdi,rax
005b main+0x5b moveax,0x2
0060 main+0x60 call 0065 main+0x65
0065 main+0x65 moveax,0x0
006a main+0x6a leave
006b main+0x6b ret
$ gcc-4.5 -O0 -march=core2 -c a.c objdump -d -M intel --prefix-addresses a.o
| grep main
main push rbp
0001 main+0x1 movrbp,rsp
0004 main+0x4 subrsp,0x40
0008 main+0x8 movrax,0x4008
0012 main+0x12 movQWORD PTR [rbp-0x8],rax
0016 main+0x16 movddup xmm0,QWORD PTR [rbp-0x8]
001b main+0x1b movapd XMMWORD PTR [rbp-0x40],xmm0
0020 main+0x20 movapd xmm0,XMMWORD PTR [rbp-0x40]
0025 main+0x25 learax,[rbp-0x30]
0029 main+0x29 movQWORD PTR [rbp-0x10],rax
002d main+0x2d movapd XMMWORD PTR [rbp-0x20],xmm0
0032 main+0x32 movrax,QWORD PTR [rbp-0x10]
0036 main+0x36 movapd xmm0,XMMWORD PTR [rbp-0x20]
003b main+0x3b movupd XMMWORD PTR [rax],xmm0
003f main+0x3f movrdx,QWORD PTR [rbp-0x28]
0043 main+0x43 movsd xmm0,QWORD PTR [rbp-0x30]
0048 main+0x48 moveax,0x0
004d main+0x4d movq xmm1,rdx
0052 main+0x52 movrdi,rax
0055 main+0x55 moveax,0x2
005a main+0x5a call 005f main+0x5f
005f main+0x5f moveax,0x0
0064 main+0x64 leave
0065 main+0x65 ret
The incorrect bit is
0016 main+0x16 movsd xmm2,xmm1
001a main+0x1a unpcklpd xmm2,xmm2
001e main+0x1e movapd xmm0,xmm2
0022 main+0x22 movlpd xmm1,QWORD PTR [rbp-0x8]
0027 main+0x27 movaps XMMWORD PTR [rbp-0x40],xmm0
which is corrected by -march=core2 to
0016 main+0x16 movddup xmm0,QWORD PTR [rbp-0x8]
001b main+0x1b movapd XMMWORD PTR [rbp-0x40],xmm0
Of course all the redundant stores are collapsed at any positive optimization
level, and the result becomes correct regardless of -march. Unfortunately, the
bug is in the generic x86-64 target so it's highly visible. This bug is not
present in 4.4.2.
$ gcc-4.5 -v
Using built-in specs.
COLLECT_GCC=gcc-4.5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-languages=c,c++,fortran
--enable-gold --enable-plugin --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-lto --enable-gnu-unique-object --disable-multilib
--disable-libstdcxx-pch --with-tune=generic --with-system-zlib --with-ppl
--with-cloog --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --disable-werror --enable-checking=release
--program-suffix=-4.5 --enable-version-specific-runtime-libs : (reconfigured)
../configure --prefix=/usr --enable-languages=c,c++,fortran --enable-gold
--enable-plugin --enable-threads=posix --enable-__cxa_atexit
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #4 from piotr dot wyderski at gmail dot com 2010-01-27 11:06 --- (In reply to comment #3) The new compiler was built with gcc-4.5.0 20100115. Both were configured as follows: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper. exe Target: i686-pc-cygwin Configured with: ../configure --prefix=/opt/gcc-trunk -v --enable-bootstrap --en able-version-specific-runtime-libs --enable-shared --enable-shared-libgcc --with -gnu-ld --with-gnu-as --enable-dwarf2-exceptions --disable-symvers --disable-nls --with-arch=core2 --with-tune=generic --enable-threads=posix --enable-languages =c,c++ Thread model: posix gcc version 4.5.0 20100126 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-27 11:08 --- Ok. If you could figure out more precisely *when* the first problem started on cygwin, it would be very useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug tree-optimization/42878] -fcompare-debug failure at -O1 (2)
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-27 11:26 ---
But the root cause is SSA names get out-of sync already during early inlining
via .MEMs. Which is because with debug isns we retain j_11 = 0 in
bb 5:
# VUSE .MEM_12
D._10 = s_9-i;
# .MEM_14 = VDEF .MEM_12
e2 (D._10);
# DEBUG i = i_1(D)
j_11 = 0;
# DEBUG j = j_11
# .MEM_15 = VDEF .MEM_14
e2 (i_1(D));
# DEBUG j = NULL
return;
while without it's gone.
bb 5:
# VUSE .MEM_11
D._10 = s_9-i;
# .MEM_13 = VDEF .MEM_11
e2 (D._10);
# .MEM_14 = VDEF .MEM_13
e2 (i_1(D));
return;
This is because
/* By inlining function having uninitialized variable, we might
extend the lifetime (variable might get reused). This cause
ICE in the case we end up extending lifetime of SSA name across
abnormal edge, but also increase register pressure.
We simply initialize all uninitialized vars by 0 except
for case we are inlining to very first BB. We can avoid
this for all BBs that are not inside strongly connected
regions of the CFG, but this is expensive to test. */
if (id-entry_bb
is_gimple_reg (SSA_NAME_VAR (name))
TREE_CODE (SSA_NAME_VAR (name)) != PARM_DECL
(id-entry_bb != EDGE_SUCC (ENTRY_BLOCK_PTR, 0)-dest
|| EDGE_COUNT (id-entry_bb-preds) != 1))
{
gimple_stmt_iterator gsi = gsi_last_bb (id-entry_bb);
gimple init_stmt;
init_stmt = gimple_build_assign (new_tree,
fold_convert (TREE_TYPE
(new_tree),
integer_zero_node));
inserts this assignment also if there are only debug-uses. We come along
here from re-mapping the default-defs of decls.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42878
[Bug c++/42871] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-27 11:33 ---
int *foo ();
struct A
{
static int a ();
};
template class T
struct B
{
B (unsigned);
int b1 (const T );
T *b2;
unsigned b3, b4;
};
template class T
int
B T::b1 (const T x)
{
unsigned i = 0;
for (; i b3; i++)
if (i b4)
{
b2[i] = x;
*foo () = 12;
return -1;
}
}
struct C
{
C operator= (C x) { c3 = x.c1 (); return *this; }
~C () {}
int c1 () { return c3; }
void c2 (int x) { c3 = x; }
int c3;
};
void
bar ()
{
B C b (100);
C c[100];
for (int i = 0; i 100; i++)
{
c[i].c2 (i);
b.b1 (c[i]);
if (b.b1 (c[i]))
A::a ();
}
}
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfirmed|2010-01-27 10:46:28 |2010-01-27 11:33:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug c++/42871] [4.4 Regression] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-27 11:42 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-01-27 11:33:25 |2010-01-27 11:42:50 date|| Summary|g++: Internal error:|[4.4 Regression] g++: |Segmentation fault (program |Internal error: Segmentation |cc1plus)|fault (program cc1plus) Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug tree-optimization/42878] -fcompare-debug failure at -O1 (2)
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-27 11:43 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-01-27 10:42:56 |2010-01-27 11:43:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42878
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #6 from davek at gcc dot gnu dot org 2010-01-27 12:06 --- I tried building the preprocessed source with my stock 4.3.4 compiler. The first two error messages are about the undefined wide char types, then there's a massive cascade of template errors following on from that. Cygwin provides a uchar.h that defines char16_t and char32_t. I checked that none of the #-directives in the preprocessed source referred to uchar.h, so if boost fails to include it and boost gets an error about these types being undefined, I think that is likely to be a boost bug rather than a cygwin or gcc problem. I therefore don't propose to investigate this any further, unless new evidence comes to light. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42871] [4.4 Regression] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-01-27 12:08 ---
We're translating { {plus_expr,i_96,1}, {component_ref b2,b}, {component_ref
c3,array_ref i_96,c}, {plus_expr,i_29,1} } through
;; basic block 21, loop depth 1, count 0
;; prev block 7, next block 8
;; pred: 4 [95.5%] (false,exec)
;; succ: 8 [100.0%] (fallthru)
bb 21:
;; basic block 8, loop depth 2, count 0
;; prev block 21, next block 25
;; pred: 25 [100.0%] (fallthru,dfs_back) 21 [100.0%] (fallthru)
;; succ: 25 [95.5%] (true,exec) 19 [4.5%] (false,exec)
bb 8:
Invalid sum of incoming frequencies 9512, should be 9120
# i_10 = PHI i_29(25), 0(21)
i_29 = i_10 + 1;
if (i_29 D.2275_92)
goto bb 25;
else
goto bb 19;
during partial-antic computation. And we recurse endlessly phi-translating
{plus_expr,i_96,1} already. Because the leader for i_96 we are translating
is {component_ref c3,array_ref i_96,c} where we recursively reach i_96
and its leader again.
The whole function:
void bar() ()
{
unsigned int D.2295;
unsigned int D.2294;
struct C * D.2291;
int * D.2287;
unsigned int i;
int SR.6;
unsigned int D.2275;
unsigned int D.2274;
struct C * D.2271;
int * D.2267;
unsigned int i;
int save_filt.3;
void * save_eptr.2;
register struct C * D.2182;
int i;
struct C c[100];
struct B b;
bb 2:
__comp_ctor (b, 100);
bb 3:
# i_96 = PHI i_14(28), 0(2)
c[i_96].c3 = i_96;
D.2275_92 = b.b3;
if (D.2275_92 != 0)
goto bb 4;
else
goto bb 20;
bb 20:
goto bb 12;
bb 4:
D.2274_93 = b.b4;
if (D.2274_93 != 0)
goto bb 5;
else
goto bb 21;
bb 5:
Invalid sum of incoming frequencies 38, should be 430
D.2271_24 = b.b2;
D.2271_24-c3 = i_96;
D.2267_28 = foo ();
bb 6:
*D.2267_28 = 12;
D.2295_3 = b.b3;
if (D.2295_3 != 0)
goto bb 22;
else
goto bb 23;
bb 23:
goto bb 12;
bb 22:
bb 7:
# D.2295_107 = PHI D.2295_3(22), D.2295_104(19)
D.2294_100 = b.b4;
if (D.2294_100 != 0)
goto bb 9;
else
goto bb 24;
bb 21:
bb 8:
Invalid sum of incoming frequencies 9512, should be 9120
# i_10 = PHI i_29(25), 0(21)
i_29 = i_10 + 1;
if (i_29 D.2275_92)
goto bb 25;
else
goto bb 19;
bb 25:
goto bb 8;
bb 9:
Invalid sum of incoming frequencies 38, should be 430
SR.6_33 = c[i_96].c3;
D.2291_34 = b.b2;
D.2291_34-c3 = SR.6_33;
D.2287_38 = foo ();
bb 10:
*D.2287_38 = 12;
goto bb 12;
bb 24:
bb 11:
Invalid sum of incoming frequencies 9512, should be 9120
# i_98 = PHI i_39(26), 0(24)
i_39 = i_98 + 1;
if (D.2295_107 i_39)
goto bb 26;
else
goto bb 27;
bb 26:
goto bb 11;
bb 27:
bb 12:
a ();
bb 13:
i_14 = i_96 + 1;
if (i_14 = 99)
goto bb 28;
else
goto bb 29;
bb 28:
goto bb 3;
L6:
save_filt.3_15 = [filter_expr] filter object;
save_eptr.2_16 = [exc_ptr_expr] exception object;
bb 15:
# D.2182_106 = PHI D.2182_18(30), c[100](14)
D.2182_18 = D.2182_106 + -4;
if (c[0] == D.2182_18)
goto bb 16;
else
goto bb 30;
bb 30:
goto bb 15;
bb 16:
Invalid sum of outgoing probabilities 0.0%
exception object = save_eptr.2_16;
filter object = save_filt.3_15;
resx 1
bb 29:
bb 17:
# D.2182_51 = PHI D.2182_20(31), c[100](29)
D.2182_20 = D.2182_51 + -4;
if (c[0] == D.2182_20)
goto bb 18;
else
goto bb 31;
bb 31:
goto bb 17;
bb 18:
return;
bb 19:
D.2295_104 = b.b3;
goto bb 7;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-27 12:12 --- Thanks Dave. Thus, essentially, is submitter wrong that the problem is new? (the other issue, which I can reproduce on x86_64-linux, stays) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #8 from paolo dot carlini at oracle dot com 2010-01-27 12:21 --- Also note: something is going on with char16_t / char32_t which I do not understand at all, at the moment: in that tr1_impl code I did not setup the specializations for char16_t / char32_t conditionally to some configure check or header included or actual target, because I was assuming that in C++, in C++0x mode, those are **always** available. Is that not true? And we didn't realize for all this time?!? Note, actually the error means the submitter is passing -std=c++0x on the command line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c/42882] New: Mips16 generated code with -O0 will often lead GDB to be lost when the first instruction of a C code is a function call
Hi all,
These are the items asked by the Reporting Bugs guide:
Output of gcc -v:
=
Using built-in specs.
Target: mips-elf
Configured with: ../gcc-4.4.2/configure --prefix=/gcc442_mips/linux
--target=mips-elf --with-newlib
--with-headers=../newlib-1.17.0/newlib/libc/include/
--with-ar=/gcc442_mips/linux/bin/mips-elf-ar
--with-as=/gcc442_mips/linux/bin/mips-elf-as
--with-ld=/gcc442_mips/linux/bin/mips-elf-ld --with-mpfr=/gcc442_mips/linux
--with-gmp=/gcc442_mips/linux --with-ppl=/gcc442_mips/linux
--with-cloog=/gcc442_mips/linux --enable-languages=c,c++ --disable-multilib
--with-gcc-version-trigger=../gcc-4.4.2/gcc/version.c --disable-libstdcxx-pch
Thread model: single
gcc version 4.4.2 (GCC)
Preprocessed files:
===
Not needed, we've reduced the testcase to a small file that doesn't include any
other file. Here is the code :
--- Code snippet code.c ---
int test()
{
return 3;
}
int jumpy(int argc,char** argv)
{
test();
return 2;
}
int main(int argc,char** argv)
{
return jumpy(argc,argv);
}
--- End of code snippet ---
Command lines to generated the bug:
===
mips-elf-gcc code.c -o code16 -O0 -mips16
and (for comparison purposes, see below)
mips-elf-gcc code.c -o code32 -O0 -mips32
Note:
=
There's no need to debug the compiled code on a real target to observe the
problem, looking at the disassembly should be sufficient.
Explanation of the Problem:
===
When connecting GDB on the above compiled code in *MIPS16*, stepping in the
function 'jumpy' will lost GDB a bit. It will not find the first instruction
corresponding to the call to test, and instead will then point to the first
assembly instruction of the jumpy function. The consequence is that the
function arguments will not be properly analyzed by GDB because the stack is
not yet in the proper state. Worse, if we try to set a breakpoint on the first
line of code of the function 'jumpy', this will lead GDB to be completely lost.
In *MIPS32*, debugging with GDB has no such problems.
Investigation of the Problem:
=
By looking at the disassembly of the jumpy function in MIPS32 and MIPS16, we
can see that
* In MIPS32, the compiler did not do any optimization with delay slots when
dealing with a call instruction.
* In MIPS16, the compiler did some optimization with delay slots, and put one
instruction of the stack saving process in the delay slot, after the first call
to the function 'test'.
Here are these disassembly dumps:
MIPS32: A nop is in the delay slot:
---
00400198 jumpy:
400198:27bdffe8 addiusp,sp,-24
40019c:afbf0014 swra,20(sp)
4001a0:afbe0010 sws8,16(sp)
4001a4:03a0f021 moves8,sp
4001a8:afc40018 swa0,24(s8)
4001ac:afc5001c swa1,28(s8)
4001b0:0c10005d jal400174 test
4001b4: nop = Good!
4001b8:24020002 liv0,2
4001bc:03c0e821 movesp,s8
4001c0:8fbf0014 lwra,20(sp)
4001c4:8fbe0010 lws8,16(sp)
4001c8:27bd0018 addiusp,sp,24
4001cc:03e8 jrra
4001d0: nop
MIPS16: A stack-saving instruction is in the delay slot:
00400188 jumpy:
400188:63fd addiusp,-24
40018a:6205 swra,20(sp)
40018c:d104 sws1,16(sp)
40018e:0104 addius1,sp,16
400190:d982 swa0,8(s1)
400192:1a00 005d jal400174 test
400196:d9a3 swa1,12(s1) = Bad!
400198:6a02 liv0,2
40019a:65b9 movesp,s1
40019c:9701 lwa3,4(sp)
40019e:9100 lws1,0(sp)
4001a0:ef00 jra3
4001a2:6301 addiusp,8
Expected Behaviour:
===
We believe that the MIPS16 code should not be optimized, and that a nop should
be found in the delay slot too, the jal instruction being AFTER all stack
saving instructions.
Thanks by advance for you attention! We would be very grateful for your help,
and sorry for any flaw this bug report could contain.
Ben
--
Summary: Mips16 generated code with -O0 will often lead GDB to be
lost when the first instruction of a C code is a
function call
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ben at coolsand-tech dot fr
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mips-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42882
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #9 from piotr dot wyderski at gmail dot com 2010-01-27 12:27 --- (In reply to comment #7) Thanks Dave. Thus, essentially, is submitter wrong that the problem is new? My code compiled flawlessly on 4.5.0-20100115, otherwise I would have reported the issue earlier... 20100126 has been built in a clean directory, so no interferences with previous builds are possible. Paolo: yes, -std=gnu++0x -- it's the reason I use trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug tree-optimization/42878] -fcompare-debug failure at -O1 (2)
--- Comment #6 from zsojka at seznam dot cz 2010-01-27 12:28 --- Created an attachment (id=19726) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19726action=view) different testcase, not crashing, but having difference in einline2 dump This testcase passes the compare-debug test, but shows the behaviour you described. In this case, there are no uninitialized variables though (I am not aware of any). I hope this file can be useful. Command line: gcc -O1 -fcompare-debug testcase.c -c -fdump-tree-einline2 diff testcase.c.*024t.einline2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42878
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #10 from davek at gcc dot gnu dot org 2010-01-27 12:29 --- (In reply to comment #8) Also note: something is going on with char16_t / char32_t which I do not understand at all, at the moment: in that tr1_impl code I did not setup the specializations for char16_t / char32_t conditionally to some configure check or header included or actual target, because I was assuming that in C++, in C++0x mode, those are **always** available. Is that not true? And we didn't realize for all this time?!? I don't understand. There's no equivalent in g++ of the builtin stdint types that Joseph added for C, so if you don't include the header that defines them, no definitions should be available, yes? Note, actually the error means the submitter is passing -std=c++0x on the command line. That didn't make any difference to the undefined types errors, but it did fix a lot of the knock-on errors I was seeing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #11 from davek at gcc dot gnu dot org 2010-01-27 12:30 --- (In reply to comment #9) (In reply to comment #7) Thanks Dave. Thus, essentially, is submitter wrong that the problem is new? My code compiled flawlessly on 4.5.0-20100115, otherwise I would have reported the issue earlier... Can you attach the preprocessed source you get from that build of the compiler, so we can see why it either a) finds definitions of the ucharXX_t types, or b) doesn't attempt to declare templates referring to them? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #16 from kkojima at gcc dot gnu dot org 2010-01-27 12:32 --- I've got some new libstdc++-v3 testsuite failures with the patch on my nightly sh4-linux tester: Running /exp/ldroot/dodes/ORIG/trunk/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... FAIL: 23_containers/deque/requirements/exception/basic.cc (test for excess errors) WARNING: 23_containers/deque/requirements/exception/basic.cc compilation failed to produce executable FAIL: 23_containers/deque/requirements/exception/propagation_consistent.cc (test for excess errors) WARNING: 23_containers/deque/requirements/exception/propagation_consistent.cc compilation failed to produce executable FAIL: 30_threads/packaged_task/members/get_future.cc execution test FAIL: 30_threads/shared_future/members/get.cc execution test The first failure is /tmp/ccl5TCl4.s: Assembler messages: /tmp/ccl5TCl4.s:43070: Error: undefined symbol `.L3394' in operation FAIL: 23_containers/deque/requirements/exception/basic.cc (test for excess errors) The last 2 failures are resulted with the unaligned accesses. I saw Sending SIGBUS to get_future.exe due to unaligned access (PC 296554a8 PR 2965549a) Sending SIGBUS to get.exe due to unaligned access (PC 296554a8 PR 2965549a) on the target machine. With reverting the first hunk of the patch, these errors go away. Christian, could you please revert or disable the first hunk of patches temporarily? Sorry I didn't catch this earlier. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||christian dot bruel at st ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug c++/42871] [4.4 Regression] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-01-27 12:32 --- Sort-of same IL with trunk if you make C c[100] global. But there's not a single EH edge on trunk?! which likely makes it work there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-27 12:33 --- Then say that explicitly, *always*. Actually, the complete command line is part of the requirements for PRs. But, anyway, that error with char16_t and char32_t doesn't make *any* sense to me. We have plenty of testcases in the C++ testsuite for char16_t and char32_t on all the targets, working fine without including any header. Can you compile something as simple as this: char16_t a; with -std=c++0x (or -std=gnu++0x)? If you can't, then this is something which is much more general than boost MPL; if you can, something inside boost MPL is playing weird tricks with those names. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #13 from paolo dot carlini at oracle dot com 2010-01-27 12:35 --- Dave, please grep the C++ testsuite for char16_t and char32_t: you will find tons of testcases using those types + -std=c++0x on the command line, no special target-dependent treatments, no includes whatsoever. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #20 from edwintorok at gmail dot com 2010-01-27 12:35 --- Thanks to Jakub for the hints. This is not a bug in libstdc++/gcc: the problem is that fork() is called when we already have threads (due to openmp/libstdc++ parallel mode), and then you can call a limited number of functions before exec(). std::find is called both before and after fork(). This is fine in a default build, but in a parallel mode build, the first std::find spawns threads, which ClamAV doesn't expect. I will just make it a #error if ClamAV is built in libstdc++ parallel mode. -- edwintorok at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #14 from davek at gcc dot gnu dot org 2010-01-27 12:36 --- (In reply to comment #12) on all the targets, working fine without including any header. Can you compile something as simple as this: char16_t a; with -std=c++0x (or -std=gnu++0x)? This is from head r.156219 $ cat test.cpp char16_t a; dkad...@ubik /tmp/boost $ g++-4 -std=c++0x -c test.cpp ; echo $? 0 dkad...@ubik /tmp/boost $ g++-4 -v Using built-in specs. COLLECT_GCC=g++-4 COLLECT_LTO_WRAPPER=/gnu/gcc/install-lto/opt/gcc-tools/bin/../libexec/gcc/i686-p c-cygwin/4.5.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: /gnu/gcc/gcc/configure --prefix=/opt/gcc-tools -v --with-gmp=/u sr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs -- enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --wi th-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --disable-symver s --enable-libjava --enable-interpreter --program-suffix=-4 --enable-libgomp --d isable-libssp --disable-libada --enable-threads=posix --with-arch=i686 --with-tu ne=generic CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 --with-ec j-jar=/usr/share/java/ecj.jar --disable-win32-registry --disable-libgcj-debug -- enable-lto --enable-languages=c,c++,fortran,java,lto,objc,obj-c++ --enable-graph ite Thread model: posix gcc version 4.5.0 20100121 (experimental) (GCC) dkad...@ubik /tmp/boost $ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #15 from davek at gcc dot gnu dot org 2010-01-27 12:38 --- And this is r.155967 $ cat test.cpp char16_t a; dkad...@ubik /tmp/boost $ g++-4 -std=c++0x -c test.cpp ; echo $? 0 dkad...@ubik /tmp/boost $ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #16 from piotr dot wyderski at gmail dot com 2010-01-27 12:39 --- Can you attach the preprocessed source you get from that build of the compiler Unfortunately not, because I assumed that the new compiler will work, so make install overwritten the binaries of 0115. Anyway, I think I have an earlier build somewhere (20100107) which also works, so I will provide you a preprocessed source from that version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #17 from paolo dot carlini at oracle dot com 2010-01-27 12:42 --- So, as a matter of fact, char16_t and char32_t normally work on cygwin too. Then, what the heck is boost doing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #18 from davek at gcc dot gnu dot org 2010-01-27 12:45 --- (In reply to comment #17) So, as a matter of fact, char16_t and char32_t normally work on cygwin too. Ah, hang on. I may have got some of my revision numbers mixed up there. (I have a number of objdirs lying around built at various times from the same sandbox.) Here are two fairly recent ones: $ /gnu/gcc/install-lto/opt/gcc-tools/bin/g++-4 -std=c++0x -c mpl_size_hpp.ii ; echo $? 0 $ /gnu/gcc/install-obj2/opt/gcc-tools/bin/g++-4 -std=c++0x -c mpl_size_hpp.ii ; echo $? In file included from /usr/include/boost_1_39_0/boost/mpl/aux_/include_preproces sed.hpp:37:0, from /usr/include/boost_1_39_0/boost/mpl/aux_/full_lambda.hpp:4 4, from /usr/include/boost_1_39_0/boost/mpl/lambda.hpp:22, from /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:20, from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:18, from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/full_lambda.hpp:555:49 2: error: specialization of 'boost::mpl::aux::template_arityboost::mpl::lambda mpl_::na, mpl_::na ' after instantiation /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/full_lambda.hpp:555:49 2: error: redefinition of 'struct boost::mpl::aux::template_arityboost::mpl::la mbdampl_::na, mpl_::na ' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arityboost:: mpl::lambdampl_::na, mpl_::na ' In file included from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:18:0, from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:45:531: error: specialization of 'boost::mpl::aux::template_arityboost::mpl::iter_fold ' after instantiati on /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:45:531: error: redefinition of 'struct boost::mpl::aux::template_arityboost::mpl::iter_fold ' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arityboost:: mpl::iter_fold ' In file included from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:19:0, from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/iterator_range.hpp:38:521: error: specializa tion of 'boost::mpl::aux::template_arityboost::mpl::iterator_range ' after i nstantiation /usr/include/boost_1_39_0/boost/mpl/iterator_range.hpp:38:521: error: redefiniti on of 'struct boost::mpl::aux::template_arityboost::mpl::iterator_range ' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arityboost:: mpl::iterator_range ' In file included from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19: 0, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/distance.hpp:74:485: error: specialization o f 'boost::mpl::aux::template_arityboost::mpl::distance ' after instantiation /usr/include/boost_1_39_0/boost/mpl/distance.hpp:74:485: error: redefinition of 'struct boost::mpl::aux::template_arityboost::mpl::distance ' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arityboost:: mpl::distance ' In file included from br.cpp:2:0: /usr/include/boost_1_39_0/boost/mpl/size.hpp:38:421: error: specialization of 'b oost::mpl::aux::template_arityboost::mpl::size ' after instantiation /usr/include/boost_1_39_0/boost/mpl/size.hpp:38:421: error: redefinition of 'str uct boost::mpl::aux::template_arityboost::mpl::size ' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arityboost:: mpl::size ' 1 dkad...@ubik /tmp/boost $ /gnu/gcc/install-lto/opt/gcc-tools/bin/g++-4 -std=c++0x -c mpl_size_hpp.ii ; echo $? 0 dkad...@ubik /tmp/boost $ However, note there's still no problem with the wide char types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #19 from piotr dot wyderski at gmail dot com 2010-01-27 12:47 --- Then say that explicitly, *always*. Actually, the complete command line is part of the requirements for PRs. Sorry, I misunderstood you. I use -std=gnu++0x in my actual program, which today became uncompilable. For the PR it was: g++ -std=gnu++0x br.cpp -I/usr/include/boost_1_39_0/ Without extensions enabled, merely: g++ br.cpp -I/usr/include/boost_1_39_0/ the compiler also emits an error list, however much shorter (it's probably what you see on Linux): specialization after instantiation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #20 from davek at gcc dot gnu dot org 2010-01-27 12:48 --- (In reply to comment #18) (In reply to comment #17) So, as a matter of fact, char16_t and char32_t normally work on cygwin too. Ah, hang on. I may have got some of my revision numbers mixed up there. (I have a number of objdirs lying around built at various times from the same sandbox.) Here are two fairly recent ones: Those versions are: gcc version 4.5.0 20100121 (experimental) (GCC) gcc version 4.5.0 20100125 (experimental) (GCC) So I can confirm the specialisation error that you've also seen on x86_64-linux has also appeared on cygwin, but I can't yet confirm any bug about the char types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #17 from chrbr at gcc dot gnu dot org 2010-01-27 12:50 --- strange, I didn't see that, even the undefined symbol in the assembler. OK I disable the fix until this is clarified. Let me do a recheck on the silicium, will let you know. -c (In reply to comment #16) I've got some new libstdc++-v3 testsuite failures with the patch on my nightly sh4-linux tester: Running /exp/ldroot/dodes/ORIG/trunk/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... FAIL: 23_containers/deque/requirements/exception/basic.cc (test for excess errors) WARNING: 23_containers/deque/requirements/exception/basic.cc compilation failed to produce executable FAIL: 23_containers/deque/requirements/exception/propagation_consistent.cc (test for excess errors) WARNING: 23_containers/deque/requirements/exception/propagation_consistent.cc compilation failed to produce executable FAIL: 30_threads/packaged_task/members/get_future.cc execution test FAIL: 30_threads/shared_future/members/get.cc execution test The first failure is /tmp/ccl5TCl4.s: Assembler messages: /tmp/ccl5TCl4.s:43070: Error: undefined symbol `.L3394' in operation FAIL: 23_containers/deque/requirements/exception/basic.cc (test for excess errors) The last 2 failures are resulted with the unaligned accesses. I saw Sending SIGBUS to get_future.exe due to unaligned access (PC 296554a8 PR 2965549a) Sending SIGBUS to get.exe due to unaligned access (PC 296554a8 PR 2965549a) on the target machine. With reverting the first hunk of the patch, these errors go away. Christian, could you please revert or disable the first hunk of patches temporarily? Sorry I didn't catch this earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #21 from paolo dot carlini at oracle dot com 2010-01-27 12:53 --- Excellent Dave. Thus, we are looking for confirmation of the char16_t / char32_t issue, we don't see it on our cygwin and linux machines. And we should nail down more precisely in time the specialization / redefinition issue, can be a regression or g++ becoming more strict. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #22 from davek at gcc dot gnu dot org 2010-01-27 12:59 --- (In reply to comment #21) Excellent Dave. Thus, we are looking for confirmation of the char16_t / char32_t issue, we don't see it on our cygwin and linux machines. OK, so I'll try updating my most recent build from 156219 to 156253 and see if that makes a difference re. the char types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #23 from piotr dot wyderski at gmail dot com 2010-01-27 13:04 --- cmdline: g++ [-std=gnu++0x] br.cpp -I/usr/include/boost_1_39_0/ On gcc version 4.5.0 20090604 (experimental) (GCC): compiled OK On gcc version 4.5.0 20100107 (experimental) (GCC) compiled OK On 20100115 it was also OK, but I can't prove it. On 20100126: a lot of errors, the amount depends on the presence of -std=gnu++0x I have no intermediate builds between 15 and 26, so can't reduce the range any more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #24 from piotr dot wyderski at gmail dot com 2010-01-27 13:08 --- Created an attachment (id=19727) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19727action=view) preprocessed boost 1.39 mpl/size.hpp (20100107) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42883] New: 4.5-20100121: internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2112
This only occurs at positive optimization levels $ g++-4.5 -c -O0 avtOpenFOAMFileFormat.preprocessed.C # okay $ g++-4.5 -c -O1 avtOpenFOAMFileFormat.preprocessed.C /home/jed/visit/src/databases/OpenFOAM/avtOpenFOAMFileFormat.C: In member function vtkUnstructuredGrid* avtOpenFOAMFileFormat::MakeInternalMesh(): /home/jed/visit/src/databases/OpenFOAM/avtOpenFOAMFileFormat.C:443:23: internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2112 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ g++-4.5 -v Using built-in specs. COLLECT_GCC=g++-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr --enable-languages=c,c++,fortran --enable-gold --enable-plugin --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-lto --enable-gnu-unique-object --disable-multilib --disable-libstdcxx-pch --with-tune=generic --with-system-zlib --with-ppl --with-cloog --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-werror --enable-checking=release --program-suffix=-4.5 --enable-version-specific-runtime-libs : (reconfigured) ../configure --prefix=/usr --enable-languages=c,c++,fortran --enable-gold --enable-plugin --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-lto --enable-gnu-unique-object --disable-multilib --disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-werror --enable-checking=release --program-suffix=-4.5 --enable-version-specific-runtime-libs Thread model: posix gcc version 4.5.0 20100121 (experimental) (GCC) -- Summary: 4.5-20100121: internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2112 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugs at 59A2 dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42883
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #25 from davek at gcc dot gnu dot org 2010-01-27 13:12 --- (In reply to comment #24) Created an attachment (id=19727) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19727action=view) [edit] preprocessed boost 1.39 mpl/size.hpp (20100107) Apart from include file paths in # lines, the two files are identical. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42883] 4.5-20100121: internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2112
--- Comment #1 from bugs at 59A2 dot org 2010-01-27 13:13 --- Created an attachment (id=19728) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19728action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42883
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #18 from chrbr at gcc dot gnu dot org 2010-01-27 13:24 --- Subject: Bug 42841 Author: chrbr Date: Wed Jan 27 13:24:40 2010 New Revision: 156282 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156282 Log: temporarily revert fix for PR target/42841 Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #26 from piotr dot wyderski at gmail dot com 2010-01-27 13:25 --- Apart from include file paths in # lines, the two files are identical. I double-checked the compilers used to generate them -- the attachments are correct. So the issue must be inside the compiler itself, not in its stdc++ includes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #19 from chrbr at gcc dot gnu dot org 2010-01-27 13:40 --- to make sure we are in the same testing/configuration environment could you please send me the preprocessed file for 23_containers/deque/requirements/exception/propagation_consistent.cc as well as the compilation line in libstdc++.log that you used ? many thanks Christian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug c/42884] New: GCC (v4.3.3) fails to detect uninitialized variable
GCC fails to detect an unitialized variable in a function. In the attached code [warning.c] it fails to detect that 'diglen' could be unitialized by time the 'for' loop is encountered. -- Summary: GCC (v4.3.3) fails to detect uninitialized variable Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tstdenis at elliptictech dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-27 14:00 --- No attachment. Moreover, please try also a more recent release, in the 4.4.x series. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Version|unknown |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #2 from tstdenis at elliptictech dot com 2010-01-27 14:01
---
Here's the file [I'm getting an internal error when submitting a file]
---warning.c---
#define NULL ((void *)0)
#define OK 0
typedef struct { void *a; } state;
int init(int, state *);
int done(unsigned char *, unsigned long *, state *);
int function(unsigned char *param5, unsigned long param6)
{
state st;
unsigned char dig[128];
unsigned long y, outpos, diglen;
int err;
outpos = 0;
err= OK;
while (err == OK outpos param6) {
err = init(0, st);
if (err == OK) {
diglen = sizeof(dig);
err = done(dig, diglen, st);
}
for (y = 0; y diglen outpos param6; y++) {
param5[outpos++] = dig[y];
}
}
return err;
}
--
tstdenis at elliptictech dot com changed:
What|Removed |Added
Version|4.3.3 |unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #3 from tstdenis at elliptictech dot com 2010-01-27 14:02 --- (In reply to comment #1) No attachment. Moreover, please try also a more recent release, in the 4.4.x series. No warning from GCC 4.4.0 when using '-Wall -W -O3'. -- tstdenis at elliptictech dot com changed: What|Removed |Added Version|4.3.3 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c++/42871] [4.4 Regression] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-01-27 14:03
---
Testcase that also fails on trunk:
struct C
{
~C ();
int c3;
};
C *b2;
static void
b1 (const C x, unsigned b3, unsigned b4)
{
unsigned i = 0;
for (; i b3; i++)
if (i b4)
{
b2[0].c3 = x.c3;
return;
}
}
int a ();
void
bar (unsigned b3, unsigned b4)
{
C c[100];
for (int i = 0; i 100; i++)
{
c[i].c3 = i;
for (int j = 0; j b3; j++)
if (j b4)
{
b2[0].c3 = 0;
break;
}
b1 (c[i], b3, b4);
a ();
}
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.4.3 |4.4.3 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-27 14:07 --- Yes. I'm pretty sure we have duplicates in Bugzilla. Anyway, I just tested two other high quality compilers and they don't warn either. I don't think we can reach zero negatives in this area any time soon. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2010-01-27 14:07:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2010-01-27 14:07:00 |2010-01-27 14:07:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #20 from kkojima at gcc dot gnu dot org 2010-01-27 14:08 --- Created an attachment (id=19729) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19729action=view) A test case cc1plus -std=gnu++0x -O2 propagation_consistent.ii produces a problematic code here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #5 from tstdenis at elliptictech dot com 2010-01-27 14:08 --- (In reply to comment #4) Yes. I'm pretty sure we have duplicates in Bugzilla. Anyway, I just tested two other high quality compilers and they don't warn either. I don't think we can reach zero negatives in this area any time soon. If this bug is a dupe please close this as resolved/dupe. I didn't check that hard. I think this is a bug because GCC attempts to resolve whether variables are initialized or not and doesn't in this case. It's misleading to the user to suggest it can do something it clearly cannot [in this case]. -- tstdenis at elliptictech dot com changed: What|Removed |Added Version|4.3.3 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #6 from paolo dot carlini at oracle dot com 2010-01-27 14:13 --- I'm restating my point: indeed, the variable can be used uninitialized. This is not at issue. My point is that, depending on the way the compiler is internally organized, etc, you can have it warning for a larger class of cases and not warning for a larger class of non-cases, but normally you cannot obtain full accuracy. As two data points, for comparison, I told you that two other, up to date, high quality, compilers don't warn either. I'm saying, do not hold your breath on this, in principle we can, and should, make progress, but it's hard to say now how much and when. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #7 from doko at ubuntu dot com 2010-01-27 14:21 --- please consider a backport for the 4.4 branch -- doko at ubuntu dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Known to fail||4.4.3 Known to work||4.5.0 Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #7 from tstdenis at elliptictech dot com 2010-01-27 14:28 --- (In reply to comment #6) I'm restating my point: indeed, the variable can be used uninitialized. This is not at issue. My point is that, depending on the way the compiler is internally organized, etc, you can have it warning for a larger class of cases and not warning for a larger class of non-cases, but normally you cannot obtain full accuracy. As two data points, for comparison, I told you that two other, up to date, high quality, compilers don't warn either. I'm saying, do not hold your breath on this, in principle we can, and should, make progress, but it's hard to say now how much and when. I take your point about false warnings, but if something like coverity can correctly identify this, it is possible. I wouldn't expect this to be fixed overnight, but part of the point is to at least report these things so developers know about them. -- tstdenis at elliptictech dot com changed: What|Removed |Added Version|4.3.3 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #8 from paolo dot carlini at oracle dot com 2010-01-27 14:37 --- Is 'coverity' a compiler? I don't think so. Do you have actual examples of *compilers* which, everything taken into account, decided to make sure this case is worth warning? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #8 from paolo dot carlini at oracle dot com 2010-01-27 14:52 --- If you say 'consider' and are talking to a GWP and release manager, it seems unpolite to re-open at once. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug middle-end/42874] [4.5 Regression] Error on correct code: sorry, unimplemented: function �foo� can never be copied because it uses
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-27 15:10 --- Subject: Bug 42874 Author: jakub Date: Wed Jan 27 15:09:23 2010 New Revision: 156287 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156287 Log: PR middle-end/42874 * tree-inline.c (cannot_copy_type_1): Removed. (copy_forbidden): Don't forbid copying of functions containing records/unions with variable length fields. * gcc.dg/vla-22.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vla-22.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42874
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #27 from davek at gcc dot gnu dot org 2010-01-27 15:17 --- (In reply to comment #26) Apart from include file paths in # lines, the two files are identical. I double-checked the compilers used to generate them -- the attachments are correct. So the issue must be inside the compiler itself, not in its stdc++ includes. Indeed, and that matches what Paolo said in comment 13. I've now built r.156253 and here is the output from compiling your testcase; it still shows no sign of the charXX_t problem: $ /gnu/gcc/install-obj3/opt/gcc-tools/bin/g++-4 -std=c++0x o.cpp In file included from /usr/include/boost_1_39_0/boost/mpl/aux_/include_preproces sed.hpp:37:0, from /usr/include/boost_1_39_0/boost/mpl/aux_/full_lambda.hpp:4 4, from /usr/include/boost_1_39_0/boost/mpl/lambda.hpp:22, from /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:20, from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:18, from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/full_lambda.hpp:555:49 2: error: specialization of 'boost::mpl::aux::template_arityboost::mpl::lambda mpl_::na, mpl_::na ' after instantiation /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/full_lambda.hpp:555:49 2: error: redefinition of 'struct boost::mpl::aux::template_arityboost::mpl::la mbdampl_::na, mpl_::na ' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arityboost:: mpl::lambdampl_::na, mpl_::na ' In file included from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:18:0, from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:45:531: error: specialization of 'boost::mpl::aux::template_arityboost::mpl::iter_fold ' after instantiati on /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:45:531: error: redefinition of 'struct boost::mpl::aux::template_arityboost::mpl::iter_fold ' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arityboost:: mpl::iter_fold ' In file included from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:19:0, from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/iterator_range.hpp:38:521: error: specializa tion of 'boost::mpl::aux::template_arityboost::mpl::iterator_range ' after i nstantiation /usr/include/boost_1_39_0/boost/mpl/iterator_range.hpp:38:521: error: redefiniti on of 'struct boost::mpl::aux::template_arityboost::mpl::iterator_range ' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arityboost:: mpl::iterator_range ' In file included from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19: 0, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/distance.hpp:74:485: error: specialization o f 'boost::mpl::aux::template_arityboost::mpl::distance ' after instantiation /usr/include/boost_1_39_0/boost/mpl/distance.hpp:74:485: error: redefinition of 'struct boost::mpl::aux::template_arityboost::mpl::distance ' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arityboost:: mpl::distance ' In file included from br.cpp:2:0: /usr/include/boost_1_39_0/boost/mpl/size.hpp:38:421: error: specialization of 'b oost::mpl::aux::template_arityboost::mpl::size ' after instantiation /usr/include/boost_1_39_0/boost/mpl/size.hpp:38:421: error: redefinition of 'str uct boost::mpl::aux::template_arityboost::mpl::size ' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arityboost:: mpl::size ' dkad...@ubik /tmp/boost $ except, of course, if I omit -std=c++0x: $ /gnu/gcc/install-obj3/opt/gcc-tools/bin/g++-4 o.cpp In file included from /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/ty pe_traits:51:0, from /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bi ts/move.h:38, from /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bi ts/stl_pair.h:60, from /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/ut ility:71, from
[Bug middle-end/42874] [4.5 Regression] Error on correct code: sorry, unimplemented: function �foo� can never be copied because it uses
--- Comment #8 from jakub at gcc dot gnu dot org 2010-01-27 15:21 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42874
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #28 from davek at gcc dot gnu dot org 2010-01-27 15:31 --- I've just gone back through the older compiler versions I have lying around. None of them can successfully compile the testcase without -std=c++0x at all, they all complain about the missing types in the same way. So I think the stuff to do with char types is just a red-herring that happened while Piotr was trying out the standalone testcase, by omitting the -std flag. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #29 from paolo dot carlini at oracle dot com 2010-01-27 15:31 --- To be clear: when the tr1_impl/type_traits implementation code is included as tr1 code, is included from tr1/type_traits that is, _GLIBCXX_INCLUDE_AS_CXX0X is undefined and no error should happen. Likewise, when the tr1_impl/type_traits code is included as C++0x code, from type_traits that is, the macro is defined, but no problem should occur in that case too because char16_t and char32_t are certainly available in C++0x mode. In practice, on linux I can compile the provided one-line snippet, both with -std=c++0x and without, and get *only* the errors unrelated to char16_t / char32_t. This doesn't suprise me, because in the libstdc++ testsuite we are *very* careful about these things: we have tons of testcases including type_traits and tr1/type_traits in normal mode, c++0x mode, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42871] [4.4 Regression] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-01-27 15:35
---
In the testcase from comment #11 on trunk when translating PA_IN [7],
{ i_45 (0028), {...@.mem_46 (0007),
{component_refc3,array_refi_45,0,4,c...@.mem_21 (0022), {plus_expr,i_45,1}
(0009) }
to block 20 we first translate
{component_refc3,array_refi_45,0,4,c...@.mem_21
(0022) which is translated to
{component_refc3,array_refi_45,0,4,c...@.mem_26
(0028). Later we translate i_45 (0028) to i_45 (0028), but when entering
that into the sets the value is already present.
Thus, this particular case is fixed by value-replacing the translated
expression in phi_translate_set.
But that does not sound like a proper solution. It looks more like an
issue of sorting. Though doing the value-replacement in case of
the translation being a name looks not too weird.
Danny? Is this something that should not happen because of some
constraints which are possibly violated?
Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c (revision 156276)
+++ gcc/tree-ssa-pre.c (working copy)
@@ -1834,12 +1834,20 @@ phi_translate_set (bitmap_set_t dest, bi
{
pre_expr translated;
translated = phi_translate (expr, set, NULL, pred, phiblock);
+ if (!translated)
+ continue;
/* Don't add empty translations to the cache */
if (translated)
phi_trans_add (expr, translated, pred);
- if (translated != NULL)
+ /* We might end up with multiple expressions from SET being
+translated to the same value. In this case we do not want
+to retain the NARY or REFERENCE expression but prefer a NAME
+which would be the leader. */
+ if (translated-kind == NAME)
+ bitmap_value_replace_in_set (dest, translated);
+ else
bitmap_value_insert_into_set (dest, translated);
}
VEC_free (pre_expr, heap, exprs);
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #30 from paolo dot carlini at oracle dot com 2010-01-27 15:41 --- If Dave, you have evidence that older versions of GCC always needed -std=c++0x in order to compile this boost code, this is a cygwin-specific issue: I just tried with a 4.4.x gcc and I can compile it without -std=c++0x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #9 from tstdenis at elliptictech dot com 2010-01-27 15:43 --- (In reply to comment #8) Is 'coverity' a compiler? I don't think so. Do you have actual examples of *compilers* which, everything taken into account, decided to make sure this case is worth warning? I wonder if there is an apathy reason to close bugs ho hum... I'm just saying that it is something that should at some point be addressed. Maybe not today, maybe not tomorrow, but soon, and for the rest of the projects life cycle. -- tstdenis at elliptictech dot com changed: What|Removed |Added Version|4.3.3 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #10 from paolo dot carlini at oracle dot com 2010-01-27 15:47 --- To be clear: nobody closed this bug, ever. And talking about apathy is plain offensive, or maybe you are just ignorant of the trade-offs involved in this area. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Version|unknown |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #31 from davek at gcc dot gnu dot org 2010-01-27 15:48 --- (In reply to comment #30) If Dave, you have evidence that older versions of GCC always needed -std=c++0x in order to compile this boost code, this is a cygwin-specific issue: I just tried with a 4.4.x gcc and I can compile it without -std=c++0x. This is 4.3.4, the stock cygwin distro version right now: dkad...@ubik /tmp/boost $ cat test.cpp char16_t a; dkad...@ubik /tmp/boost $ g++ -c test.cpp test.cpp:1: error: 'char16_t' does not name a type dkad...@ubik /tmp/boost $ g++ -c test.cpp -std=c++0x test.cpp:1: error: 'char16_t' does not name a type dkad...@ubik /tmp/boost I take it that much is unsurprising? This is the oldest version of trunk I have lying around, from r155967: dkad...@ubik /tmp/boost $ /gnu/gcc/install-clean/opt/gcc-tools/bin/g++-4 -c test.cpp test.cpp:1:1: error: 'char16_t' does not name a type dkad...@ubik /tmp/boost $ /gnu/gcc/install-clean/opt/gcc-tools/bin/g++-4 -c test.cpp -std=c++0x dkad...@ubik /tmp/boost That is also how everything up to r156253 behaves. Is there something wrong with that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-01-27 15:49 --- Subject: Bug 42832 Author: rguenth Date: Wed Jan 27 15:49:00 2010 New Revision: 156290 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156290 Log: 2010-01-27 Richard Guenther rguent...@suse.de PR libstdc++/42832 * include/std/functional (function::swap): Perform bytewise swap of _M_functor. * include/tr1/functional (function::swap): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/functional trunk/libstdc++-v3/include/tr1/functional -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-01-27 15:51 --- Doesn't depend on fixed memcpy, no longer blocks 42617. Depends on 42845 for enhancing the fix. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|42834 |42845 OtherBugsDependingO|42617 | nThis|| AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Severity|normal |enhancement Status|ASSIGNED|NEW Summary|Revisit std::function for |Revisit std::function for |aliasing issues |aliasing issues and ||efficiency http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #32 from paolo dot carlini at oracle dot com 2010-01-27 15:56 --- Dave, the issue with char16_t / cha32_t is cygwin specific, and, to be really honest, personally I'm not interested in cygwin much. My suggestion is just making sure the C++ front-end is fine for cygwin vs char16_t / char32_t, ans simply running the C++ testsuite should be more than enough. If eventually you come to the conclusion that some special workrounds in the C++ runtime is needed to support cygwin, let's discuss that separately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency
--- Comment #16 from paolo dot carlini at oracle dot com 2010-01-27 15:57 --- Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #11 from tstdenis at elliptictech dot com 2010-01-27 15:57 --- (In reply to comment #10) To be clear: nobody closed this bug, ever. And talking about apathy is plain offensive, or maybe you are just ignorant of the trade-offs involved in this area. I didn't say you did close the bug I said you probably should if everyone is apathetic as you appear to be. I don't care if commercial compilers miss this, GCC claims to detect this sort of bug, it doesn't, that's a bug. Furthermore, it is detectable in an automated way [e.g., coverity] so it's not like I'm asking to boil the ocean or whatever... Whether it's high priority or not [I don't think it is] is not at issue. So stop being so dismissive about it. -- tstdenis at elliptictech dot com changed: What|Removed |Added Version|4.3.3 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-27 15:59 --- You are apathetic, and your mother and son. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug tree-optimization/42878] -fcompare-debug failure at -O1 (2)
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-27 16:00 --- Subject: Bug 42878 Author: rguenth Date: Wed Jan 27 16:00:31 2010 New Revision: 156291 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156291 Log: 2010-01-27 Richard Guenther rguent...@suse.de PR middle-end/42878 * tree-inline.c (remap_decl): Delay remapping of SSA name default definitions until we need them. * gcc.dg/torture/pr42878-1.c: New testcase. * gcc.dg/torture/pr42878-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr42878-1.c trunk/gcc/testsuite/gcc.dg/torture/pr42878-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c --- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-27 16:01 --- Fixed. -- rguenth 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=42878
[Bug tree-optimization/42878] -fcompare-debug failure at -O1 (2)
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-27 16:00 --- Subject: Bug 42878 Author: rguenth Date: Wed Jan 27 16:00:31 2010 New Revision: 156291 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156291 Log: 2010-01-27 Richard Guenther rguent...@suse.de PR middle-end/42878 * tree-inline.c (remap_decl): Delay remapping of SSA name default definitions until we need them. * gcc.dg/torture/pr42878-1.c: New testcase. * gcc.dg/torture/pr42878-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr42878-1.c trunk/gcc/testsuite/gcc.dg/torture/pr42878-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42878
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #13 from tstdenis at elliptictech dot com 2010-01-27 16:05 --- (In reply to comment #12) You are apathetic, and your mother and son. ` Apathy: noun, a lack of enthusiasm or emotion. Being dismissive of the bug because other compilers don't detect it either is apathetic. Irony: noun, A statement that, when taken in context, may actually mean the opposite of what is written literally; the use of words expressing something other than their literal intention, notably as a form of humor. Calling someone who took the time to file a bug report apathetic is ironic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-01-27 16:06 --- As diglen has its address taken and we do not warn about uninitialized use of memory we do not warn. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #33 from davek at gcc dot gnu dot org 2010-01-27 16:07 --- (In reply to comment #32) Dave, the issue with char16_t / cha32_t is cygwin specific, and, to be really honest, personally I'm not interested in cygwin much. My suggestion is just making sure the C++ front-end is fine for cygwin vs char16_t / char32_t, ans simply running the C++ testsuite should be more than enough. If eventually you come to the conclusion that some special workrounds in the C++ runtime is needed to support cygwin, let's discuss that separately. I'll run the testsuite on today's build and see if it differs from my most recent run, which was pretty clean. More later when that finishes. (I thought the problem was that the preprocessed testcase was prepared using -std=c++0x and therefore embeds all the #ifdef decisions made using that standard, and so the preprocessed testcase must be compiled using the same -std= which was used to prepare it.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug middle-end/42883] [4.5 Regression] internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2112
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-27 16:08 --- Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-27 16:08:10 date|| Summary|4.5-20100121: internal |[4.5 Regression] internal |compiler error: in |compiler error: in |redirect_eh_edge_1, at tree-|redirect_eh_edge_1, at tree- |eh.c:2112 |eh.c:2112 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42883
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #34 from paolo dot carlini at oracle dot com 2010-01-27 16:14 --- Right Dave, that's why we ask submitters to also provide the actual command line used. Anyway, sorry about a bit of harshness on my side, I'm afraid we are digressing too much in this thread: for sure, if I just take the one-liner provided by submitter the errors I get are the same, with and without -std=c++0x, and with 4.4.x I can compile it with no errors, irrerspective of the command-line switches. This is what I consider sane behavior modulo the *possible*, yet to be confirmed, C++ front-end issue with specialization / redefinition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug middle-end/42881] [4.5 Regression] SSE2 intrinsics miscompiled at -O0 -march=k8
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-27 16:16 ---
At -O0 I see in .optimized:
bb 2:
__F_7 = 3.0e+0;
D.6259_8 = {__F_7, __F_7};
D.6258_11 = D.6259_8;
x.0_1 = D.6258_11;
x = x.0_1;
x.1_2 = x;
__P_9 = a[0];
__A_10 = x.1_2;
__builtin_ia32_storeupd (__P_9, __A_10);
D.6247_3 = a[1];
D.6248_4 = a[0];
D.6249_5 = (const char * restrict) %f %f\n[0];
printf (D.6249_5, D.6248_4, D.6247_3);
D.6250_6 = 0;
return D.6250_6;
nothing wrong here sofar. But we expand:
;; D.6259_8 = {__F_7, __F_7};
(insn 7 6 8 /usr/lib64/gcc/x86_64-suse-linux/4.5/include/emmintrin.h:65 (set
(reg:V2DF 68)
(vec_duplicate:V2DF (reg:DF 69))) 1501 {vec_dupv2df} (nil))
(insn 8 7 9 /usr/lib64/gcc/x86_64-suse-linux/4.5/include/emmintrin.h:65 (set
(reg:DF 69)
(mem/c/i:DF (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -8 [0xfff8])) [0 __F+0 S8 A64])) -1
(nil))
(insn 9 8 0 /usr/lib64/gcc/x86_64-suse-linux/4.5/include/emmintrin.h:65 (set
(reg:V2DF 64 [ D.6259 ])
(reg:V2DF 68)) -1 (nil))
whoops. We duplicate reg:DF 69 before setting it. That works ok in 4.4.
My bet is SSA expand.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||matz at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Component|inline-asm |middle-end
Ever Confirmed|0 |1
Keywords||wrong-code
Priority|P3 |P1
Last reconfirmed|-00-00 00:00:00 |2010-01-27 16:16:46
date||
Summary|SSE2 intrinsics miscompiled |[4.5 Regression] SSE2
|at -O0 -march=k8|intrinsics miscompiled at -
||O0 -march=k8
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42881
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #15 from tstdenis at elliptictech dot com 2010-01-27 16:22 --- (In reply to comment #14) As diglen has its address taken and we do not warn about uninitialized use of memory we do not warn. I get that the compiler can't track if an external function actually initializes a value through a pointer, but the diglen = sizeof... line should be good enough for the positive case. In the false path though diglen is not initialized nor its address taken. -- tstdenis at elliptictech dot com changed: What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
--- Comment #10 from jakub at gcc dot gnu dot org 2010-01-27 16:37 --- Subject: Bug 42861 Author: jakub Date: Wed Jan 27 16:36:57 2010 New Revision: 156292 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156292 Log: PR debug/42861 * var-tracking.c (val_store): Add modified argument, obey it. Adjust callers. (count_uses): Move down logging of main. (compute_bb_dataflow): Use val_store for MO_VAL_USEs that don't need resolution. (emit_notes_in_bb): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-01-27 16:51 --- (In reply to comment #15) (In reply to comment #14) As diglen has its address taken and we do not warn about uninitialized use of memory we do not warn. I get that the compiler can't track if an external function actually initializes a value through a pointer, but the diglen = sizeof... line should be good enough for the positive case. In the false path though diglen is not initialized nor its address taken. No, it's an implementation detail. Uninitialized variable use tracking works with detecting uses of SSA name default definitions. Memory is not in SSA form so this mechanism does not work. Uninitialized memory detection is not done at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug libgomp/42872] [4.5 regression] Revision 156232 failed many libgomp tests
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-27 16:58 --- 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=42872
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
--- Comment #11 from jakub at gcc dot gnu dot org 2010-01-27 17:00 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
