[Bug ada/39336] libgnat.dylib, libgnarl.dylib don't contain full paths
--- Comment #2 from simon at pushface dot org 2009-04-29 06:00 --- (In reply to comment #1) The Ada make files don't use GNU libtool to build the shared libraries. GNAT Pro 6.2.1 on Darwin uses -rpath/@rpath, presumably AdaCore will fold this in at a future date. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39336
[Bug c++/39956] New: no error for a instantiated class accessing private types in base class
Access to private types in a class from another instantiated template class is
not getting the expected type is private error from gcc compiler.
$gcc -c -v inp4.cpp
Using built-in specs.
Target: hppa1.1-hp-hpux11.11
Configured with: /tmp/gcc-4.3.1.tar.gz/gcc-4.3.1/configure
--host=hppa1.1-hp-hpux11.11 --target=hppa1.1-hp-hpux11.11
--build=hppa1.1-hp-hpux11.11 --prefix=/opt/hp-gcc-4.3.1 --with-gnu-as
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix
--enable-languages=c,c++ --with-gmp=/proj/opensrc/be/hppa1.1-hp-hpux11.11
--with-mpfr=/proj/opensrc/be/hppa1.1-hp-hpux11.11
Thread model: posix
gcc version 4.3.1 (GCC)
COLLECT_GCC_OPTIONS='-c' '-v' '-mschedule=7100LC'
/usr/local/libexec/gcc/hppa1.1-hp-hpux11.11/4.3.1/cc1plus -quiet -v -iprefix
/usr/local/bin/../lib/gcc/hppa1.1-hp-hpux11.11/4.3.1/ inp4.cpp -quiet -dumpbase
inp4.cpp -mschedule=7100LC -auxbase inp4 -version -o /var/tmp//cc7ckWOk.s
ignoring nonexistent directory
/usr/local/bin/../lib/gcc/hppa1.1-hp-hpux11.11/4.3.1/../../../../hppa1.1-hp-hpux11.11/include
ignoring duplicate directory /usr/local/include/c++/4.3.1
ignoring duplicate directory
/usr/local/include/c++/4.3.1/hppa1.1-hp-hpux11.11
ignoring duplicate directory /usr/local/include/c++/4.3.1/backward
ignoring duplicate directory /usr/local/include
ignoring duplicate directory
/usr/local/lib/gcc/hppa1.1-hp-hpux11.11/4.3.1/include
ignoring duplicate directory
/usr/local/lib/gcc/hppa1.1-hp-hpux11.11/4.3.1/include-fixed
ignoring nonexistent directory /usr/local/hppa1.1-hp-hpux11.11/include
#include ... search starts here:
#include ... search starts here:
/usr/local/bin/../lib/gcc/hppa1.1-hp-hpux11.11/4.3.1/../../../../include/c++/4.3.1
/usr/local/bin/../lib/gcc/hppa1.1-hp-hpux11.11/4.3.1/../../../../include/c++/4.3.1/hppa1.1-hp-hpux11.11
/usr/local/bin/../lib/gcc/hppa1.1-hp-hpux11.11/4.3.1/../../../../include/c++/4.3.1/backward
/usr/local/bin/../lib/gcc/hppa1.1-hp-hpux11.11/4.3.1/include
/usr/local/bin/../lib/gcc/hppa1.1-hp-hpux11.11/4.3.1/include-fixed
/usr/local/include
/usr/include
End of search list.
GNU C++ (GCC) version 4.3.1 (hppa1.1-hp-hpux11.11)
compiled by GNU C version 4.3.1, GMP version 4.2.1, MPFR version 2.3.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d046d88028b4361d28297b29c4e5d08d
inp4.cpp:1: error: 'typedef int A::type' is private
inp4.cpp:6: error: within this context
$cat inp4.cpp
class A { typedef int type; };
templatetypename T class B { typedef A::type type; /* no error. */ };
Bvoid b;
class C { typedef A::type type; /* error thrown. */ };
Note: Though I tested this with 4.3.1 gcc I think the problem should be present
in 4.4.0 as well because the changes document does not state anything related
to this bu.
Please get back as quicly as possible.
--
Summary: no error for a instantiated class accessing private
types in base class
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kannanmj at hp dot com
GCC build triplet: hppa1.1-hp-hpux11.11
GCC host triplet: hppa1.1-hp-hpux11.11
GCC target triplet: hppa1.1-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39956
[Bug c++/39956] no error for a instantiated class accessing private types in base class
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Keywords||accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39956
[Bug c++/33934] access control bug in member function templates
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-29 07:05 --- *** This bug has been marked as a duplicate of 16617 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33934
[Bug c++/24118] Access control bug for base class of templates
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-29 07:05 --- *** This bug has been marked as a duplicate of 16617 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24118
[Bug c++/26693] [4.3/4.4/4.5 regression] Access checks not performed for types in templates
--- Comment #17 from pinskia at gcc dot gnu dot org 2009-04-29 07:09 --- *** Bug 39956 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||kannanmj at hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26693
[Bug target/39947] Shared libgcc getting clobbered for multilib builds
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-04-29 07:29 --- The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll, libssp-x.dll, etc) that are built as part of gcc Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947
[Bug target/39947] Shared libgcc getting clobbered for multilib builds
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-04-29 07:38 --- (In reply to comment #2) The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll, libssp-x.dll, etc) that are built as part of gcc Danny That's correct. We have to find a way to install those binaries for multilib builds into different locations, or we have to extend the DLL names by a target key. I would prefer here to use a different location, why not using in /bin target specific directories? Something like bin/dll32 and bin/dll64? Cheers, Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-29 07:38:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #11 from vvv at ru dot ru 2009-04-29 07:46 --- (In reply to comment #8) From config/i386/i386.c: /* AMD Athlon works faster when RET is not destination of conditional jump or directly preceded by other jump instruction. We avoid the penalty by inserting NOP just before the RET instructions in such cases. */ static void ix86_pad_returns (void) ... But I am using Core 2 Duo. Why we see multibyte nop, not single byte nop? Why if change line u = F(u)*3+1; to u = F(u)*4+1; or u = F(u); number of nops changed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #12 from vvv at ru dot ru 2009-04-29 07:55 --- (In reply to comment #9) So that explains it, Use -Os or attribute cold if you want NOPs to be gone. But my measurements on Core 2 Duo P8600 show that push %ebp mov %esp,%ebp leave ret _faster_ then push %ebp mov %esp,%ebp leave xchg %ax,%ax ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug target/39565] Static variable leaves undefined symbol in object file
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-29 08:34 --- Subject: Bug 39565 Author: rguenth Date: Wed Apr 29 08:34:21 2009 New Revision: 146928 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146928 Log: 2009-04-29 Anmol P. Paralkar an...@freescale.com PR target/39565 * gcc.dg/pr39565.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr39565.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39565
[Bug target/39947] Shared libgcc getting clobbered for multilib builds
--- Comment #4 from jon_y at users dot sourceforge dot net 2009-04-29 08:37 --- (In reply to comment #3) (In reply to comment #2) The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll, libssp-x.dll, etc) that are built as part of gcc Danny That's correct. We have to find a way to install those binaries for multilib builds into different locations, or we have to extend the DLL names by a target key. I would prefer here to use a different location, why not using in /bin target specific directories? Something like bin/dll32 and bin/dll64? Cheers, Kai I would prefer a new naming scheme, that way, we don't need to change PATH (by much) for the system to pick up the dlls. btw, my libssp seems oddly placed. prefix/lib/gcc/x86_64-w64-mingw32/bin/libssp-0.dll (64bit) prefix/lib/gcc/x86_64-w64-mingw32/4.5.0/bin/libssp-0.dll (32bit) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947
[Bug c++/39862] [4.5 Regression] verify_eh_tree failed with -O2
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-04-29 08:58
---
Shorter testcase, which still includes map, though.
It crashes with -O and above:
==
#includemap
struct A
{
virtual ~A() {}
};
struct B : A
{
virtual ~B() { foo(); }
void foo();
};
struct C : B
{
C();
C(const C c) : B(c) { foo(); }
virtual ~C();
};
void bar(std::mapint, C m)
{
m.insert(std::pairint, C(0, C()));
}
==
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39862
[Bug libstdc++/39909] non-TLS version of std::call_once causes terminate
--- Comment #6 from paolo dot carlini at oracle dot com 2009-04-29 09:17 --- Jon, patch looks generally good to me, can you please send it to the mailing list for higher visibility? Then we can commit it and close this annoying issue once and for all ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39909
[Bug tree-optimization/39955] [4.5 Regression] struct-layout-1 test failures passing struct containing _Decimal32
--- Comment #4 from matz at gcc dot gnu dot org 2009-04-29 09:22 --- I didn't enable it explicitely, but Janis neither (according to the testresults post), so it's probably default. But I did not use some other options, in particular the --with-cpu=default32, so I'm rechecking with Janis' ones. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39955
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #13 from jakub at gcc dot gnu dot org 2009-04-29 09:32 --- You are benchmarking something completely unrelated. What really matters is how code that has 4 branches/calls in one 16-byte block is able to predict all those branches. And Core2 similarly to various AMD CPUs is not able to predict them well. In the #c6 testcase it considers the je, call, jne and ret whether they can be in a 16 byte block or not. They can't, je is 2 bytes, call 5 bytes, leal 4 bytes (but gcc uses min_insn_size, which is 2 in this case), testl 2, jne 2, addq 4 (but again, min_insn_size is 2 in this case). min_insn_size seems to be very conservative, I guess teaching it about a bunch of prefixes couldn't hurt, for non-jump/call insns ATM it estimates just the displacement size, doesn't consider any prefixes (even those that really can't change after machine reorg), etc. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #14 from jakub at gcc dot gnu dot org 2009-04-29 10:12 --- Also, couldn't we use the information computed by compute_alignments and assume CODE_LABELs are aligned? Probably would need to add label_to_max_skip (rtx) function to final.c, so that not just label_to_alignment, but also LABEL_TO_MAX_SKIP is available to backends. Then when we know for the label in the testcase that .p2align 4,,10 .p2align 3 then we know the 16 byte boundary is either at that label, or at most 5 bytes before it, so all we need is consider any jumps/calls in the last 5 bytes before the label. For min_insn_size, is it possible to find out for which non-jump/call insns get_attr_length might not be exact (i.e. be a maximum guess rather than guaranteed size (though of course, this is also just an optimization, so 100% guarantees aren't needed either))? If so, we could use get_attr_length for the insns where it is known to be exact... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug middle-end/39941] [4.5 Regression] ice in passes.c:execute_todo()
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-29 10:39 --- 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=39941
[Bug middle-end/39941] [4.5 Regression] ice in passes.c:execute_todo()
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-29 10:39 --- Subject: Bug 39941 Author: rguenth Date: Wed Apr 29 10:39:26 2009 New Revision: 146948 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146948 Log: 2009-04-29 Richard Guenther rguent...@suse.de PR tree-optimization/39941 * tree-ssa-pre.c (eliminate): Schedule update-ssa after eliminating an indirect call. * gcc.c-torture/compile/pr39941.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr39941.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39941
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #10 from joseph at codesourcery dot com 2009-04-29 11:33 --- Subject: Re: [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c On Wed, 29 Apr 2009, matz at gcc dot gnu dot org wrote: The user should have the possibility to announce the unalignedness to the compiler via casts, like so: memcpy((char*)outdata-tv, tp, sizeof outdata-tv); (or void* or whatever). This doesn't work currently, as the emitted gimple code loses that cast. So, there're two things: explicit alignment changing casts are lost and the type of ADDR_EXPR of non-naturally aligned fields has the wrong pointer type (losing the unalignedness). The former problem is a bit problematic to solve, as parameter passing always has an implicit conversion to the formal parameter type (void* in this case). We don't want to lose alignment info just because of that conversion, only for explicit ones. In ISO C terms casts change alignment information in the opposite direction to the one you want - if the conversion sequence contains anywhere a pointer to an N-byte aligned type, you can assume that the pointer is N-byte aligned, so you take the highest alignment from the sequence of types, not the lowest. The problem is representing the address of an unaligned field as a pointer-to-aligned-type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #11 from matz at gcc dot gnu dot org 2009-04-29 11:38 --- Thanks for the clarification. So there indeed is only one issue, that the temporary has an aligned type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug middle-end/39666] spurious warning with ranged-switch statements
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-29 11:52 ---
In C:
int foo (int i)
{
int j;
switch (i)
{
case -__INT_MAX__ - 1 ... -1:
j = 6;
break;
case 0:
j = 5;
break;
case 1 ... __INT_MAX__:
j = 4;
break;
}
return j;
}
fails the same way. The default label is added by gimplify_switch_expr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39666
[Bug c++/39862] [4.5 Regression] verify_eh_tree failed with -O2
--- Comment #4 from reichelt at gcc dot gnu dot org 2009-04-29 12:33
---
Confirmed. Reduced testcase (crashes with -O):
==
struct A
{
virtual ~A() {}
};
struct B : A
{
virtual ~B() { foo(); }
void foo();
};
struct C : B
{
C(const C c) : B(c) { foo(); }
};
void bar(const C c)
{
try
{ new C(c); }
catch(...)
{}
}
==
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-04-29 12:33:01
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39862
[Bug c++/35669] NULL (__null) not considered different from 0 with C++
--- Comment #10 from bangerth at gmail dot com 2009-04-29 12:51 --- There is really nothing much that can be done within the current C++ standard. In C, NULL is defined as (void*)0 which can be converted to any other pointer and so is clearly marked as a pointer. The compiler can then warn when passing it to an integer argument of a function. In C++, we have [18.1/4] The macro NULL is an implementation-defined C++ null pointer constant in this International Standard (_conv.ptr_).180) and footnote 180 specifically says: 180) Possible definitions include 0 and 0L, but not (void*)0. This is because void* is not implicitly convertible to any other pointer type and so NULL could not be assigned to other pointers. As a consequence, since NULL can not in an obvious way be a pointer, there is no obvious warning that can be generated. The situation will be different with the upcoming C++1x standard where there is null_ptr. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35669
[Bug middle-end/39891] Bogus location given for warning, no warning at real location: dereferencing pointer �anonymous� does break strict-aliasing rules
--- Comment #4 from manu at gcc dot gnu dot org 2009-04-29 13:16 --- (In reply to comment #3) Note that getInt is completely inlined and there is no location involving that function available anymore :/ The difficulties of C++ and late diagnostics ... I wonder what Clang+LLVM does here. Their diagnostics are (in general) far superior and we are the ones that should start following their lead. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39891
[Bug c++/39859] duplicated and unhelpful error for c:n (parser)
--- Comment #1 from manu at gcc dot gnu dot org 2009-04-29 13:21 --- Confirmed. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2009-04-29 13:21:44 date|| Summary|C++: Duplicated and |duplicated and unhelpful |unhelpful error for c:n |error for c:n (parser) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39859
[Bug c++/35669] NULL (__null) not considered different from 0 with C++
--- Comment #11 from l dot lunak at suse dot cz 2009-04-29 13:21 --- (In reply to comment #10) As a consequence, since NULL can not in an obvious way be a pointer, there is no obvious warning that can be generated. Of course there is. NULL with gcc is not 0, 0L or (void*)0, it is __null. And gcc can make __null be whatever it wants, can it not? The same way it can warn about converting __null to integer. The situation will be different with the upcoming C++1x standard where there is null_ptr. Gcc already in practice has null_ptr. It's called __null. What would be the point of __null otherwise, to have a really sophisticated way to write 0? -- l dot lunak at suse dot cz changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35669
[Bug c++/39858] C++: expected primary-expression error could be more useful
--- Comment #1 from manu at gcc dot gnu dot org 2009-04-29 13:23 --- Confirmed. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-29 13:23:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39858
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #9 from ramana at gcc dot gnu dot org 2009-04-29 13:48 --- 4.2.x is now closed. Since this appears to work on 4.3.1, could you confirm if this is still a problem with an eabi toolchain of more recent vintage ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug tree-optimization/39955] [4.5 Regression] struct-layout-1 test failures passing struct containing _Decimal32
--- Comment #6 from hjl dot tools at gmail dot com 2009-04-29 13:50 --- (In reply to comment #5) Pff, I still can't reproduce the testsuite failures, but I can reproduce the ICE on the testcase from the initial comment. rs6000.c needs to handle SSA_NAMEs now. I'm currently regstrapping this: See PR 39952 on why you didn't see it on Linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39955
[Bug middle-end/39666] spurious warning with ranged-switch statements
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-29 13:54 --- Created an attachment (id=17778) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17778action=view) gcc44-pr39666.patch Fix I'm going to bootstrap/regtest soon. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39666
[Bug libgcj/36658] Building gcj for arm linux from trunk (gcc 4.4.0): libjava/gcj/array.h:24: internal compiler error: verify_gimple failed
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-29 13:58 --- Could you check with a version of more recent vintage and provide more information like the svn revision number ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36658
[Bug testsuite/39952] Inadequate gcc.dg/compat/struct-layout-1_generate.c
--- Comment #1 from jakub at gcc dot gnu dot org 2009-04-29 14:04 --- That's by design. Obviously there are so many possible combinations that you can't exhaustively test them all, that's why this test randomly chooses some. You can pass -n count to the generator to generate more (or fewer) tests, instead of the default 3000. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39952
[Bug middle-end/39937] [4.5 Regression] Revision 146831 failed SPEC CPU 2006
--- Comment #8 from hjl dot tools at gmail dot com 2009-04-29 14:04 --- On Linux/x86-64, I got gcc -c -o pp_sort.o -DSPEC_CPU -DNDEBUG -DPERL_CORE -O3 -ffast-math -funroll-loops -DSPEC_CPU_LP64 -DSPEC_CPU_LINUX_X64 pp_sort.c pp_sort.c: In function 'S_qsortsv': pp_sort.c:1352: error: type mismatch in pointer plus expression struct SV * * struct SV * * struct SV * * vect_vec_iv_.1464_184 = vect_vec_iv_.1464_183 + vect_cst_.1463_182; pp_sort.c:1352: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. specmake[3]: *** [pp_sort.o] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39937
[Bug middle-end/39937] [4.5 Regression] Revision 146831 failed SPEC CPU 2006
--- Comment #9 from hjl dot tools at gmail dot com 2009-04-29 14:06 --- (In reply to comment #8) On Linux/x86-64, I got gcc -c -o pp_sort.o -DSPEC_CPU -DNDEBUG -DPERL_CORE -O3 -ffast-math -funroll-loops -DSPEC_CPU_LP64 -DSPEC_CPU_LINUX_X64 pp_sort.c pp_sort.c: In function 'S_qsortsv': pp_sort.c:1352: error: type mismatch in pointer plus expression struct SV * * struct SV * * struct SV * * vect_vec_iv_.1464_184 = vect_vec_iv_.1464_183 + vect_cst_.1463_182; pp_sort.c:1352: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. specmake[3]: *** [pp_sort.o] Error 1 This is in perlbench. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39937
[Bug middle-end/39937] [4.5 Regression] Revision 146831 failed SPEC CPU 2006
--- Comment #10 from rguenther at suse dot de 2009-04-29 14:06 --- Subject: Re: [4.5 Regression] Revision 146831 failed SPEC CPU 2006 On Wed, 29 Apr 2009, hjl dot tools at gmail dot com wrote: --- Comment #8 from hjl dot tools at gmail dot com 2009-04-29 14:04 --- On Linux/x86-64, I got gcc -c -o pp_sort.o -DSPEC_CPU -DNDEBUG -DPERL_CORE -O3 -ffast-math -funroll-loops -DSPEC_CPU_LP64 -DSPEC_CPU_LINUX_X64 pp_sort.c pp_sort.c: In function 'S_qsortsv': pp_sort.c:1352: error: type mismatch in pointer plus expression struct SV * * struct SV * * struct SV * * vect_vec_iv_.1464_184 = vect_vec_iv_.1464_183 + vect_cst_.1463_182; pp_sort.c:1352: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. specmake[3]: *** [pp_sort.o] Error 1 Is that after or before 2009-04-28 Richard Guenther rguent...@suse.de * tree-vect-loop.c (get_initial_def_for_induction): Use correct types for pointer increment. ? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39937
[Bug middle-end/39666] [4.3/4.4/4.5 Regression] spurious warning with ranged-switch statements
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-29 14:07 --- This is a regression from 3.4.x to 4.0.x BTW. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|spurious warning with |[4.3/4.4/4.5 Regression] |ranged-switch statements|spurious warning with ||ranged-switch statements Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39666
[Bug middle-end/39937] [4.5 Regression] Revision 146831 failed SPEC CPU 2006
--- Comment #11 from hjl dot tools at gmail dot com 2009-04-29 14:10 --- (In reply to comment #10) 2009-04-28 Richard Guenther rguent...@suse.de * tree-vect-loop.c (get_initial_def_for_induction): Use correct types for pointer increment. That is before and with revision 146920. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39937
[Bug middle-end/39937] [4.5 Regression] Revision 146831 failed SPEC CPU 2006
--- Comment #12 from rguenther at suse dot de 2009-04-29 14:12 --- Subject: Re: [4.5 Regression] Revision 146831 failed SPEC CPU 2006 On Wed, 29 Apr 2009, hjl dot tools at gmail dot com wrote: --- Comment #11 from hjl dot tools at gmail dot com 2009-04-29 14:10 --- (In reply to comment #10) 2009-04-28 Richard Guenther rguent...@suse.de * tree-vect-loop.c (get_initial_def_for_induction): Use correct types for pointer increment. That is before and with revision 146920. Ok, it seems to work for me on current trunk. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39937
[Bug fortran/39286] Missing out-of-bounds diagnostic
--- Comment #2 from dominiq at lps dot ens dot fr 2009-04-29 14:12 --- I wonder if this not a duplicate of pr36683. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39286
[Bug middle-end/39957] New: ICE : in expand_scalar_variables_expr, at graphite.c:4262
gcc 4.5 r146933 gcc -std=gnu99 -O2 -floop-block -c matmul_c4.c /svn/compilers/gcc/libgfortran/generated/matmul_c4.c: In function 'matmul_c4': /svn/compilers/gcc/libgfortran/generated/matmul_c4.c:79: internal compiler error: in expand_scalar_variables_expr, at graphite.c:4262 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE : in expand_scalar_variables_expr, at graphite.c:4262 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: linuxl4 at sohu dot com GCC build triplet: x86_64-linux-pc GCC host triplet: x86_64-linux-pc GCC target triplet: x86_64-linux-pc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39957
[Bug middle-end/39666] [4.3/4.4/4.5 Regression] spurious warning with ranged-switch statements
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-29 14:17 --- With -O2 VRP should (since 4.4) fix this as well. That said, newer GCC no longer need a default label. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39666
[Bug fortran/39286] Missing out-of-bounds diagnostic
--- Comment #3 from dominiq at lps dot ens dot fr 2009-04-29 14:19 --- I have modified the code referenced in pr36683 as: PROGRAM calls IMPLICIT NONE INTEGER :: a(2), b(3), c(6), n , i c = myfunc(a,b) WRITE(*,*) c:,c!! gives c: 1 2 3 4 5 6 n = 5 c = 0 c(1:n) = (/(i+2,i=0,n)/)/myfunc(a,b) WRITE(*,*) c:,c!! gives c: 1 2 3 4 5 0 CONTAINS FUNCTION myfunc(v1,v2) RESULT(v3) IMPLICIT NONE INTEGER, INTENT(IN) :: v1(:), v2(:) INTEGER :: v3(SIZE(v1,1)*SIZE(v2,1)) INTEGER :: i, j, k DO i=1,SIZE(v1,1) DO j=1,SIZE(v2,1) k = (i-1)*SIZE(v2,1) + j v3(k) = k ENDDO ENDDO WRITE(*,*) myfunc: v3:,v3!! always gives v3: 1 2 3 4 5 6 END FUNCTION myfunc END PROGRAM calls and I don't get any run time error even with '-fbounds-check'. This confirms that this pr is a duplicate of pr36683. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39286
[Bug middle-end/39932] [4.5 Regression] Revision 146831 caused many test failures
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-04-29 14:20 --- The only expected fails left should now be FAIL: gcc.dg/pr34989-1.c (internal compiler error) FAIL: gcc.dg/pr34989-1.c (internal compiler error) FAIL: gcc.dg/pr34989-1.c (test for excess errors) FAIL: gcc.dg/pr34989-1.c (test for excess errors) FAIL: gcc.dg/struct/wo_prof_double_malloc.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_double_malloc.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_double_malloc.c (test for excess errors) FAIL: gcc.dg/struct/wo_prof_double_malloc.c (test for excess errors) all --combine ones, and FAIL: libgomp.c++/task-4.C -O (internal compiler error) FAIL: libgomp.c++/task-4.C -O (internal compiler error) FAIL: libgomp.c++/task-4.C -O (test for excess errors) FAIL: libgomp.c++/task-4.C -O (test for excess errors) a bug wrt missing gimplification of VLA array type bounds. This bug is now very confusing (as are all revision blabla caused many regression bugs). I will open two new bugs for the above and close this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39932
[Bug fortran/36683] -fbounds-check failure for allocated array and spread
--- Comment #2 from dominiq at lps dot ens dot fr 2009-04-29 14:20 --- pr39286 is a duplicate of this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36683
[Bug middle-end/39957] ICE : in expand_scalar_variables_expr, at graphite.c:4262
--- Comment #1 from linuxl4 at sohu dot com 2009-04-29 14:21 --- Created an attachment (id=17779) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17779action=view) the source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39957
[Bug middle-end/39958] New: [4.5 Regression] OMP tasking creates invalid gimple
FAIL: libgomp.c++/task-4.C -O (internal compiler error) FAIL: libgomp.c++/task-4.C -O (internal compiler error) FAIL: libgomp.c++/task-4.C -O (test for excess errors) FAIL: libgomp.c++/task-4.C -O (test for excess errors) /space/rguenther/src/svn/trunk/libgomp/testsuite/libgomp.c++/task-4.C: In function 'void foo(int, int)':^M /space/rguenther/src/svn/trunk/libgomp/testsuite/libgomp.c++/task-4.C:37: error: type mismatch in indirect reference^M int[0:D.2184]^M ^M int[0: error ]^M ^M D.2194 = (*q.1)[0];^M ^M so there is an issue with gimplification of type sizes of VLA. -- Summary: [4.5 Regression] OMP tasking creates invalid gimple Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39958
[Bug c/39959] New: [4.5 Regression] IMA is broken
FAIL: gcc.dg/pr34989-1.c (internal compiler error) FAIL: gcc.dg/pr34989-1.c (internal compiler error) FAIL: gcc.dg/pr34989-1.c (test for excess errors) FAIL: gcc.dg/pr34989-1.c (test for excess errors) /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr34989-2.c: In function 'syslogd_main':^M /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr34989-2.c:3: error: non-trivial conversion at assignment^M struct globals * const^M struct globals *^M # .MEM_3 = VDEF .MEM_2(D)^M ptr_to_globals = 0B;^M -- Summary: [4.5 Regression] IMA is broken Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
[Bug tree-optimization/39960] New: [4.5 Regression] struct-reorg is broken
FAIL: gcc.dg/struct/wo_prof_double_malloc.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_double_malloc.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_double_malloc.c (test for excess errors) FAIL: gcc.dg/struct/wo_prof_double_malloc.c (test for excess errors) /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/struct/wo_prof_double_malloc.c:26: error: non-trivial conversion at assignment^M struct type_struct *^M struct test_struct_sub.1 *^M # .MEM_41 = VDEF .MEM_18^M *D.3347_31 = D.3349_40;^M ^M struct-reorg doesn't bother to update reference trees properly and creates invalid gimple. -- Summary: [4.5 Regression] struct-reorg is broken Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
[Bug middle-end/39932] [4.5 Regression] Revision 146831 caused many test failures
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-04-29 14:27 --- Three actually. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39958 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960 Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||39958, 39959, 39960 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39932
[Bug middle-end/39958] [4.5 Regression] OMP tasking creates invalid gimple
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39958
[Bug tree-optimization/39960] [4.5 Regression] struct-reorg is broken
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
[Bug c/39959] [4.5 Regression] IMA is broken
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
[Bug fortran/36754] Compile-time bound-checking for allocatable arrays with known bonds
--- Comment #10 from dominiq at lps dot ens dot fr 2009-04-29 14:28 --- This may be a duplicate of PR36683(?). It is not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36754
[Bug target/36697] SIGSEGV on program exit with gcc 4.3.1
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-29 14:38 --- The new code has a value of max_idx of DTOR_END - DTOR_LIST - 1. You might want to see why your implementation has a value of max_idx 1. It doesn't appear to be a target bug yet - Please check this and get back with any more information with a compiler of more recent vintage. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36697
[Bug testsuite/39952] Inadequate gcc.dg/compat/struct-layout-1_generate.c
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-29 14:40 --- (In reply to comment #1) That's by design. Obviously there are so many possible combinations that you can't exhaustively test them all, that's why this test randomly chooses some. You can pass -n count to the generator to generate more (or fewer) tests, instead of the default 3000. If it is truly random, shouldn't someone on Linux/x86-64 run into it sometimes? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39952
[Bug c++/39961] New: variables in ctor don't have DW_AT_name in DW_TAG_variable
Compiling to-be-attached snippet with -g does not seem to emit sufficient debug info for vars defined inside ctor bodies; neither is gdb able to display info for them, nor do their names appear in the debug info sections. Versions I've tried this with: 4.2.3, 4.3.1 and 4.3.2. Using i686 instead also did not make a difference. -- Summary: variables in ctor don't have DW_AT_name in DW_TAG_variable Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thb at openoffice dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39961
[Bug c++/39961] variables in ctor don't have DW_AT_name in DW_TAG_variable
--- Comment #1 from thb at openoffice dot org 2009-04-29 14:45 --- Created an attachment (id=17780) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17780action=view) test file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39961
[Bug c/39962] New: Subtraction bug with a constant without braces
Dear,
There may be a substraction or other arithmetic operation bug in the gcc
compiler when one of the operands is a constant which is defined with another
constant and a value.
I've discovered the bug in gcc version v4.1.2-44 which is the default gcc
compiler for the RedHat Enterprise Linux v5.2 distribution.
I'v also been enable to reproduce the bug with the latest gcc version v4.4.0 .
My development platform is an i386 Linux system in 32-bit mode with kernel
version 2.6.18 .
See the following test program for the explanation/invocation of the gcc bug:
--
/*
** Test program to reproduce the subtraction bug with a constant without braces
**
** Author: Johan Vermeire, Diebold corporation, Belgium
**
** Date: April, the 29th of 2009
*/
#include stdlib.h
/* MOSEL HEADER OFFSETS */
#define Q_dest 0x00
#define BUGGY
#ifdef BUGGY // Invokes the bug in gcc
#define Q_source Q_dest + 1
#define Q_len Q_source + 1
#define Q_T_tpdu Q_len + 2
#define Q_T_dest Q_T_tpdu + 1
#define Q_T_source Q_T_dest + 8
#define Q_T_mesQ_T_source + 8
#else // Doesn't invoke the bug in gcc
#define Q_source (Q_dest + 1)
#define Q_len (Q_source + 1)
#define Q_T_tpdu (Q_len + 2)
#define Q_T_dest (Q_T_tpdu + 1)
#define Q_T_source (Q_T_dest + 8)
#define Q_T_mes(Q_T_source + 8)
#endif
#define iMOSEL_HEADER_SIZE Q_T_mes
int tppnauto_PPC_prepare_PPC2() {
int iOffset = 460;
return iOffset;
}
int main() {
int iPrepMsgSize = tppnauto_PPC_prepare_PPC2();
int iMacTextLength;
iMacTextLength = iPrepMsgSize;
int size = iMOSEL_HEADER_SIZE; // size = iMOSEL_HEADER_SIZE = 21
iMacTextLength = iPrepMsgSize - iMOSEL_HEADER_SIZE;
// iMacTextLength = 481, problem
iMacTextLength = iPrepMsgSize - size;
// iMacTextLength = 439, OK
exit(0);
}
---
Met Vriendelijke Groet, Bien à vous, Best Regards,
Johan Vermeire
Software engineer
Fixed line: +32 (0)2 464 32 32
Mobile : +32 (0)473 533 186
Picture (Metafile)
Url: http://www.diebold.com
Diebold BeLux
Professional Services
Brusselsesteenweg, 498 Chaussée de Bruxelles
B-1731 Zellik
Belgium
--
Summary: Subtraction bug with a constant without braces
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jvme38 at gmail dot com
GCC build triplet: Linux rhel4-1 2.6.18-128.1.6.el5 #1 SMP Tue Mar 24
12:10:27 EDT
GCC host triplet: Linux rhel4-1 2.6.18-128.1.6.el5 #1 SMP Tue Mar 24
12:10:27 EDT
GCC target triplet: Linux rhel4-1 2.6.18-128.1.6.el5 #1 SMP Tue Mar 24
12:10:27 EDT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39962
[Bug middle-end/39941] [4.5 Regression] ice in passes.c:execute_todo()
--- Comment #8 from hjl at gcc dot gnu dot org 2009-04-29 14:55 --- Subject: Bug 39941 Author: hjl Date: Wed Apr 29 14:54:54 2009 New Revision: 146972 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146972 Log: 2009-04-29 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-04-29 Richard Guenther rguent...@suse.de PR tree-optimization/39941 * gcc.c-torture/compile/pr39941.c: New testcase. 2009-04-29 Anmol P. Paralkar an...@freescale.com PR target/39565 * gcc.dg/pr39565.c: New testcase. 2009-04-28 Richard Guenther rguent...@suse.de PR middle-end/39937 * gfortran.fortran-torture/compile/pr39937.f: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr39941.c - copied unchanged from r146971, trunk/gcc/testsuite/gcc.c-torture/compile/pr39941.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr39565.c - copied unchanged from r146971, trunk/gcc/testsuite/gcc.dg/pr39565.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr39937.f - copied unchanged from r146971, trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr39937.f Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39941
[Bug c++/39961] variables in ctor don't have DW_AT_name in DW_TAG_variable
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-29 15:09 --- (In reply to comment #2) This is fixed AFAIK in 4.4.0. And in 4.3.3. *** This bug has been marked as a duplicate of 27574 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39961
[Bug debug/27574] [4.2/4.3 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor
--- Comment #32 from pinskia at gcc dot gnu dot org 2009-04-29 15:09 --- *** Bug 39961 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||thb at openoffice dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug middle-end/36194] [Regression] Truncation optimization in combine can remove necessary truncations
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36194
[Bug bootstrap/27367] [4.2/4.3 Regression] gstdint.h in libdecnumber is not cleaned up with make distclean
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27367
[Bug libgomp/33131] [4.2 regression] libgomp/env.c:60: warning: implicit declaration of function 'strncasecmp'
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33131
[Bug debug/36278] [4.2/4.3/4.4 Regression] ICE with typedef void in namespace and using the defined type in another when compiling with -g
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36278
[Bug target/36634] -msecure-plt combine gives invalid call insn
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36634
[Bug target/35100] [4.2/4.3/4.4 regression] internal compiler error: in extract_insn, at recog.c:1990
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
[Bug middle-end/35432] [4.2/4.3/4.4 regression] ICE with zero-sized array
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35432
[Bug middle-end/37014] [4.2/4.3/4.4 Regression] internal compiler error: in expand_expr_real_1, at expr.c:8760
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37014
[Bug target/37101] [4.2 Regression] wrong code: tree vectorizer omits bogus movq/movlps construct
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37101
[Bug c++/37389] [4.2/4.3 Regression] expected integer_cst, have error_mark in build_enumerator
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37389
[Bug debug/34037] [4.2/4.3/4.4 Regression] Bounds for VLAs not emitted into debuginfo
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34037
[Bug rtl-optimization/37544] [4.4 Regression] Conversion double - unsigned long long - unsigned - double gives wrong results
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug middle-end/18071] [4.2/4.3/4.4 Regression] -Winline does not respect -fno-default-inline
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug tree-optimization/35737] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35737
[Bug middle-end/37809] [4.2/4.3 Regression] Incorrect code with MMX right shift __builtin_ia32_psradi
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809
[Bug c++/38007] [4.2/4.3 Regression] g++ instantiate same operator twice due to bitfield in -O0 mode, causing symbol already defined assembler error
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38007
[Bug target/28102] [4.2/4.3/4.4 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug c++/35405] [4.2/4.3/4.4 Regression] Internal compiler error
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35405
[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
[Bug c++/28513] [4.2/4.3/4.4 Regression] QOI: Diagnostic missing since 3.3.x when naming rule is violated
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28513
[Bug tree-optimization/26243] [4.2/4.3/4.4 Regression] reassoc is not documented in passes.texi
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26243
[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-29 15:22 --- Does http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01619.html fix this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
[Bug c++/28743] [4.2/4.3/4.4 regression] ICE with invalid specialization
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28743
[Bug c++/34937] [4.2 regression] ICE with attribute weak
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34937
[Bug c++/34962] [4.2 regression] ICE with VLA and attribute in template
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34962
[Bug c++/39963] New: undefined reference not signaled
struct bug
{
int A;
};
int main()
{
int C = 10;
bug B[5]; // uninitialized reference
B[0].A = C; // crash
}
compiled with
gcc -o bug bug.cpp
withouth errors (the uninitialized reference is not signaled)
class bug
{
int A;
};
int main()
{
int C = 10;
bug B[5]; // uninitialized reference
B[0].A = C; // crash
}
compiled with
gcc -o bug bug.cpp
withouth errors (the uninitialized reference is not signaled)
class bug
{
public:
int A;
bug() {};
~bug() {};
};
int main()
{
int C = 10;
bug B[5]; // uninitialized reference
B[0].A = C; // crash
}
compiled with
gcc -o bug bug.cpp
bug.cpp: In constructor bug::bug():
bug.cpp:8: error: uninitialized reference member bug::A
The uninitialized reference must be signaled in the first two cases ? I am not
sure, so i report it
( g++ same behaviour )
Here gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-cpu=generic --build=i386-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)
--
Summary: undefined reference not signaled
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: asmprog32 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39963
[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9
--- Comment #4 from dominiq at lps dot ens dot fr 2009-04-29 15:24 --- Does http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01619.html fix this? If you think so, I'll try ASAP. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
[Bug middle-end/39964] New: compilation with -fprofile-generate causes code to segfault.
Compiling CP2K with -fprofile-generate causes the resulting executable to segfault. In gdb there is some additional 'expression error' message for the point of the segfault: Program received signal SIGSEGV, Segmentation fault. fftw3_create_plan_3d (plan=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at /data03/vondele/cjm/cp2k/src/../src/lib/fftw3_lib.F:127 127 IF (aligned) THEN (gdb) bt #0 fftw3_create_plan_3d (plan=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at /data03/vondele/cjm/cp2k/src/../src/lib/fftw3_lib.F:127 #1 0x0182d231 in fft_create_plan_3d (plan=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. It will be hard to get a run time testcase (except getting a full copy of CP2K). I'll attach the file where the segfault happens, and that can be compiled with: gfortran -c -static -g -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -ffree-form -fprofile-generate -D__FFTW3 fftw3_lib.F -- Summary: compilation with -fprofile-generate causes code to segfault. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39964
[Bug middle-end/39964] compilation with -fprofile-generate causes code to segfault.
--- Comment #1 from jv244 at cam dot ac dot uk 2009-04-29 15:27 --- Created an attachment (id=17781) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17781action=view) source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39964
[Bug middle-end/39964] compilation with -fprofile-generate causes code to segfault.
--- Comment #2 from jv244 at cam dot ac dot uk 2009-04-29 15:27 --- GNU Fortran (GCC) version 4.4.0 20090414 (prerelease) [gcc-4_4-branch revision 146034] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39964
[Bug c++/39045] uninitialized reference in struct with operator new is not erroring out
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-04-29 15:35 --- *** Bug 39963 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||asmprog32 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39045
[Bug c++/39963] undefined reference not signaled
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-29 15:35 --- *** This bug has been marked as a duplicate of 39045 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39963
[Bug c++/35316] [4.2 regression] ICE with typeof/decltype and bit-fields
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.5 |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35316
[Bug c++/39965] New: undefined reference not signaled
struct bug
{
int A;
};
int main()
{
int C = 10;
bug B[5]; // uninitialized reference
B[0].A = C; // crash
}
compiled with
gcc -o bug bug.cpp
withouth errors (the uninitialized reference is not signaled)
class bug
{
int A;
};
int main()
{
int C = 10;
bug B[5]; // uninitialized reference
B[0].A = C; // crash
}
compiled with
gcc -o bug bug.cpp
withouth errors (the uninitialized reference is not signaled)
class bug
{
public:
int A;
bug() {};
~bug() {};
};
int main()
{
int C = 10;
bug B[5]; // uninitialized reference
B[0].A = C; // crash
}
compiled with
gcc -o bug bug.cpp
bug.cpp: In constructor bug::bug():
bug.cpp:8: error: uninitialized reference member bug::A
The uninitialized reference must be signaled in the first two cases ? I am not
sure, so i report it
( g++ same behaviour )
Here gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-cpu=generic --build=i386-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)
--
Summary: undefined reference not signaled
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: asmprog32 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39965
[Bug testsuite/39952] Inadequate gcc.dg/compat/struct-layout-1_generate.c
--- Comment #6 from hjl dot tools at gmail dot com 2009-04-29 15:48 --- So the issues are 1. We want to test as many different combination as possible at random. 2. We want each test reproducible. Can we generate tests at random in such a way that they are reproducible? Can we do 1. Put the random seed in generated file. 2. Change struct-layout-1_generate.c to take a random seed. so that if there is a failure, we can run struct-layout-1_generate.c with the known random seed on the same platform? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39952
[Bug c++/39966] New: undefined reference not signaled
struct bug
{
int A;
};
int main()
{
int C = 10;
bug B[5]; // uninitialized reference
B[0].A = C; // crash
}
compiled with
gcc -o bug bug.cpp
withouth errors (the uninitialized reference is not signaled)
class bug
{
int A;
};
int main()
{
int C = 10;
bug B[5]; // uninitialized reference
B[0].A = C; // crash
}
compiled with
gcc -o bug bug.cpp
withouth errors (the uninitialized reference is not signaled)
class bug
{
public:
int A;
bug() {};
~bug() {};
};
int main()
{
int C = 10;
bug B[5]; // uninitialized reference
B[0].A = C; // crash
}
compiled with
gcc -o bug bug.cpp
bug.cpp: In constructor bug::bug():
bug.cpp:8: error: uninitialized reference member bug::A
The uninitialized reference must be signaled in the first two cases ? I am not
sure, so i report it
( g++ same behaviour )
Here gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-cpu=generic --build=i386-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)
--
Summary: undefined reference not signaled
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: asmprog32 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39966
[Bug middle-end/36828] 4.3.1 when optimising for size generates much larger code than 4.0.x
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-29 15:50 --- The size regression occurs with 4.3.x but with trunk today I see a size reduction to 992 bytes which is in the ball park of the original size. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-29 15:50:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36828
[Bug c++/39965] undefined reference not signaled
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-29 15:52 --- *** This bug has been marked as a duplicate of 39963 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39965
