[Bug debug/21828] [4.0/4.1 Regression] debug info omitted for uninitialized variables
--- Additional Comments From mark at codesourcery dot com 2005-07-22 06:52 --- Subject: Re: [4.0/4.1 Regression] debug info omitted for uninitialized variables mark at codesourcery dot com wrote: > Unfortunately, it failed -- gcc.dg/pch/global-1.c fails at -O3. > > I have not yet figured out why... This has to do with the fact that first_global_object_name and weak_global_object_name are not preserved across PCH; this looks to be a bug latent since the introduction of PCH. Working on fixing that now... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21828
[Bug debug/21828] [4.0/4.1 Regression] debug info omitted for uninitialized variables
--- Additional Comments From mark at codesourcery dot com 2005-07-22 06:25 --- Subject: Re: [4.0/4.1 Regression] debug info omitted for uninitialized variables mmitchel at gcc dot gnu dot org wrote: > I will try a test run with my patch reverted; if that passes, and still fixes > the bug in this PR, I will check in. Unfortunately, it failed -- gcc.dg/pch/global-1.c fails at -O3. I have not yet figured out why... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21828
[Bug middle-end/22284] [4.1 Regression] ia64 exception handling broken
--- Additional Comments From hjl at lucon dot org 2005-07-22 05:51 --- It looks like the unwind info in libstdc++.so is bad. (gdb) r Starting program: /export/build/gnu/gcc-next/build-ia64-linux/gcc/testsuite/cond1.exe Program received signal SIGSEGV, Segmentation fault. 0x201b9b90 in read_encoded_value_with_base (encoding=180 '´', base=0, p=0x400021b0 "\002", val=0x6fffa5d0) at unwind-pe.h:267 267 result = *(_Unwind_Internal_Ptr *) result; Current language: auto; currently c++ (gdb) p result $1 = 232 (gdb) bt #0 0x201b9b90 in read_encoded_value_with_base (encoding=180 '´', base=0, p=0x400021b0 "\002", val=0x6fffa5d0) at unwind-pe.h:267 #1 0x201ba2e0 in get_ttype_entry (info=0x6fffa608, i=Variable "i" is not available. ) at /net/gnu-3/export/gnu/src/gcc-next/gcc/libstdc++-v3/libsupc++/eh_personality.cc:209 #2 0x201babb0 in __gxx_personality_v0 (version=Variable "version" is not available. ) at /net/gnu-3/export/gnu/src/gcc-next/gcc/libstdc++-v3/libsupc++/eh_personality.cc:550 #3 0x202ec590 in _Unwind_RaiseException () from /lib/libgcc_s.so.1 #4 0x201bb420 in __cxa_throw (obj=Variable "obj" is not available. ) at /net/gnu-3/export/gnu/src/gcc-next/gcc/libstdc++-v3/libsupc++/eh_throw.cc:72 #5 0x4d00 in main () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22284
[Bug c++/22590] parser does not recover well after error
--- Additional Comments From igodard at pacbell dot net 2005-07-22 05:50 --- # 1 "opClock.cc" # 1 "/home/ivan/ootbc/members/src//" # 1 "" # 1 "" # 1 "opClock.cc" include "core.hh" # 1 "../../members/include/opClock.hh" 1 # 1 "/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../includ e/c++/3.4.0/cstddef" 1 3 # 1 "/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/include/stddef.h" 1 3 4 # 151 "/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/include/stddef.h " 3 4 typedef int ptrdiff_t; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22590
[Bug target/22585] [4.0 only] ICE in redirect_branch_edge
--- Additional Comments From uros at kss-loka dot si 2005-07-22 05:46 --- I was trying to trigger the "unrecognizable insn" bug with gcc-4.1, because this bug should be fixed by the patch in PR22576. I have tested: gcc -O2 -mno-ieee-fp fractal.c gcc -O2 -ffast-math fractal.c gcc -O2 fractal.c gcc -mno-ieee-fp fractal.c gcc -ffast-math fractal.c gcc fractal.c And the same pack of compile options with testcase from comment #1. In all cases, compilation was successful. The compiler was: gcc version 4.1.0 20050716 (experimental), patched with patch from PR22576. I'm updating the summary to reflect this. -- What|Removed |Added Known to work||4.1.0 Summary|[4.0/4.1 regression] ICE in |[4.0 only] ICE in |redirect_branch_edge|redirect_branch_edge http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22585
[Bug middle-end/22284] [4.1 Regression] ia64 exception handling broken
--- Additional Comments From hjl at lucon dot org 2005-07-22 05:45 --- I have identified that http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01149.html is the cause. -- What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22284
[Bug c/22605] New: Allocation of structures across stack slots
Hi,
gcc 4 seems quite a bit smarter at keeping the stack smaller, and as you can see
below allocates the 8 byte structure across two stack slots.
It did break something, which drew this to my attention, and James Wilson
already some analsysis in
http://www.gelato.unsw.edu.au/archives/linux-ia64/0507/1885.html. Quoting him
> If gcc-3.4 and earlier, some structures (BLKmode structures) were being
> over-aligned when allocated to stack slots. They always got the maximum
> alignment (16 bytes for IA-64) instead of their natural alignment. It
> isn't clear why. I think this was an accident of implementation. We
> were basing variable alignment on modes instead of type alignment, and
> since some BLKmode structures do require max alignment, we had to give
> it to all of them.
We came to the conclusion that we are unsure if this is a bug or a feature. I
am unsure if the larger stack space required is a good trade off against
possible better code.
Thanks,
-i
--- sample ---
[EMAIL PROTECTED]:/tmp$ cat test.c
#include
struct disk_stat {
int fd;
unsigned count;
};
int main(void)
{
int blah;
struct disk_stat test;
printf("%p\n", &blah);
printf("%p\n", &test);
}
[EMAIL PROTECTED]:/tmp$ gcc-3.4 -o test test.c
[EMAIL PROTECTED]:/tmp$ ./test
0x6fcdf480
0x6fcdf490
[EMAIL PROTECTED]:/tmp$ gcc-4.0 -o test test.c
[EMAIL PROTECTED]:/tmp$ ./test
0x6fd57490
0x6fd57494
--
Summary: Allocation of structures across stack slots
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ianw at gelato dot unsw dot edu dot au
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22605
[Bug bootstrap/20737] Build fails in target-libiberty
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22 04:03 --- No feedback in 3 months. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20737
[Bug c++/22603] [4.0 Regression] internal compiler error: in pop_binding, at cp/name-lookup.c:380
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22 04:00 --- I should mention this was started after 20050225 which was when the branch happened. And here is the backtrace: #0 fancy_abort (file=0x1197880 "../../gcc/cp/name-lookup.c", line=380, function=0x1197904 "pop_binding") at ../../gcc/diagnostic.c:556 #1 0x001e83d0 in pop_binding (id=0x426b923c, decl=0x426b5e80) at ../../gcc/cp/name-lookup.c: 380 #2 0x00028968 in poplevel (keep=0, reverse=0, functionbody=0) at ../../gcc/cp/decl.c:650 #3 0x0002707c in finish_scope () at ../../gcc/cp/decl.c:346 #4 0x00079c34 in end_template_decl () at ../../gcc/cp/pt.c:2400 #5 0x001b6e1c in finish_template_decl (parms=0x4267c300) at ../../gcc/cp/semantics.c:2300 #6 0x00147594 in cp_parser_template_declaration_after_export (parser=0x426b92a4, member_p=1 '\001') at ../../gcc/cp/parser.c:15038 #7 0x0013a240 in cp_parser_template_declaration (parser=0x426b92a4, member_p=1 '\001') at ../../ gcc/cp/parser.c:8154 #8 0x001436bc in cp_parser_member_declaration (parser=0x426b92a4) at ../../gcc/cp/parser.c: 13099 #9 0x00143624 in cp_parser_member_specification_opt (parser=0x426b92a4) at ../../gcc/cp/ parser.c:13040 #10 0x00141dc4 in cp_parser_class_specifier (parser=0x426b92a4) at ../../gcc/cp/parser.c:12498 #11 0x0013c8e4 in cp_parser_type_specifier (parser=0x426b92a4, flags=CP_PARSER_FLAGS_OPTIONAL, decl_specs=0xb840, is_declaration=1 '\001', declares_class_or_enum=0xb7d8, is_cv_qualifier=0xb7dc "") at ../../gcc/cp/parser.c:9326 #12 0x00138d18 in cp_parser_decl_specifier_seq (parser=0x426b92a4, flags=CP_PARSER_FLAGS_OPTIONAL, decl_specs=0xb840, declares_class_or_enum=0xb890) at ../ ../gcc/cp/parser.c:7309 #13 0x00138714 in cp_parser_simple_declaration (parser=0x426b92a4, function_definition_allowed_p=1 '\001') at ../../gcc/cp/parser.c:7005 #14 0x001386b8 in cp_parser_block_declaration (parser=0x426b92a4, statement_p=0 '\0') at ../../ gcc/cp/parser.c:6966 #15 0x001384a0 in cp_parser_declaration (parser=0x426b92a4) at ../../gcc/cp/parser.c:6883 #16 0x001380fc in cp_parser_declaration_seq_opt (parser=0x426b92a4) at ../../gcc/cp/parser.c:6787 #17 0x00130d8c in cp_parser_translation_unit (parser=0x426b92a4) at ../../gcc/cp/parser.c:2596 -- What|Removed |Added Known to fail||4.1.0 Known to work||3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22603
[Bug c++/22604] [4.0/4.1 Regression] "internal compiler error" after invalid covariant return
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22 03:58 --- I should mention this started to happen after 20041124 but before 20050225. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22604
[Bug target/22599] ICE with invalid asm usage
--- Additional Comments From gnu at the-meissners dot org 2005-07-22 03:54 --- I forgot to mention, the patch was against the mainline, sources current as of July 20th. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22599
[Bug c++/22604] [4.0/4.1 Regression] "internal compiler error" after invalid covariant return
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22 03:53 --- Confirmed. Here is the backtrace: #0 0x080b94b6 in dfs_modify_vtables (binfo=0xb7d11840, data=0xb7cbe398) at /home/peshtigo/ pinskia/src/gnu/gcc/src/gcc/cp/class.c:2032 #1 0x08122b40 in dfs_walk_all (binfo=0xb7d11840, pre_fn=0x80b8e00 , post_fn=0, data=0xb7cbe398) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/search.c:1528 #2 0x08123444 in dfs_walk_once (binfo=0xb7d11840, pre_fn=0x80b8e00 , post_fn=0, data=0xb7cbe398) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/search.c:1651 #3 0x080c8247 in finish_struct_1 (t=0xb7cbe398) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/ cp/class.c:2223 #4 0x080ca5e6 in finish_struct (t=0xb7cbe398, attributes=0xb7cbe398) at /home/peshtigo/pinskia/ src/gnu/gcc/src/gcc/cp/class.c:5107 #5 0x080e953a in cp_parser_type_specifier (parser=0xb7cbbe38, flags=Variable "flags" is not available. ) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:12642 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||error-recovery, ice-on- ||invalid-code Last reconfirmed|-00-00 00:00:00 |2005-07-22 03:53:06 date|| Summary|"internal compiler error: |[4.0/4.1 Regression] |Segmentation fault" with|"internal compiler error" |invalid nested classes |after invalid covariant ||return Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22604
[Bug c++/22604] "internal compiler error: Segmentation fault" with invalid nested classes
--- Additional Comments From flash at pobox dot com 2005-07-22 03:38 --- Created an attachment (id=9327) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9327&action=view) BBinder_segfault.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22604
[Bug c++/22604] New: "internal compiler error: Segmentation fault" with invalid nested classes
The invalid code below results in "internal compiler error: Segmentation fault"
with a checking version of GCC 4.0.1. Does not happen with GCC 3.3.4 or Apple
GCC 4.0.0.
Like the code for bug 22603, this is a greatly-reduced and anonymized excerpt,
found by Daniel
Wilkerson's Delta, from a real PalmSource file. (This reduction was found by
looking for a segfault; the
previous reduction looked for any compiler error.)
I don't think this is the same bug as my 22508, since that one also
happened with Apple GCC 4.0.0.
It doesn't sound to me like 21975 or 22441 either.
class NameOne;
class NameTwo : virtual public SAtom
{
virtual NameOne* NameThree();
};
class NameFour : virtual public NameFive
{
class NameOne : public NameTwo
{
virtual NameOne* NameThree();
==
Session:
125> /opt/gcc401chk/bin/g++ -v
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/
BBinder_segfault.ii
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-checking --prefix=/opt/gcc401chk
--enable-languages=c,c+
+
Thread model: posix
gcc version 4.0.1
/opt/gcc401chk/libexec/gcc/i686-pc-linux-gnu/4.0.1/cc1plus -fpreprocessed
/Projects/
PlatformTools/compilerChain/tests/cpp/bugfiles/error/BBinder_segfault.ii -quiet
-dumpbase
BBinder_segfault.ii -mtune=pentiumpro -auxbase BBinder_segfault -version -o
/tmp/ccuEkHiJ.s
GNU C++ version 4.0.1 (i686-pc-linux-gnu)
compiled by GNU C version 3.3.4 (pre 3.3.5 20040809).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/BBinder_segfault.ii:3:
error: expected
class-name before { token
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/BBinder_segfault.ii:7:
error: expected
class-name before { token
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/BBinder_segfault.ii:10:
error:
expected `}' at end of input
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/BBinder_segfault.ii:10:
error: invalid
covariant return type for virtual NameFour::NameOne*
NameFour::NameOne::NameThree()
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/BBinder_segfault.ii:4:
error:
overriding virtual NameOne* NameTwo::NameThree()
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/BBinder_segfault.ii:9:
internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Like bug 22603, this is tracked by PalmSouce bug 104911, though I suspect it's
different.
--
Summary: "internal compiler error: Segmentation fault" with
invalid nested classes
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: flash at pobox dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22604
[Bug c++/22590] parser does not recover well after error
--- Additional Comments From bangerth at dealii dot org 2005-07-22 03:16 --- I believe you, though I can't reproduce with a simple set of include files. Can you try to reduce your program to something more reasonable that still shows the same problem? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22590
[Bug c++/22603] [4.0 Regression] internal compiler error: in pop_binding, at cp/name-lookup.c:380
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22 02:43 --- Confirmed, only a 4.0 regression. We do not get an ICE on the mainline. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||error-recovery, ice-on- ||invalid-code Last reconfirmed|-00-00 00:00:00 |2005-07-22 02:43:47 date|| Summary|internal compiler error: in |[4.0 Regression] internal |pop_binding, at cp/name-|compiler error: in |lookup.c:380|pop_binding, at cp/name- ||lookup.c:380 Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22603
[Bug c++/22603] internal compiler error: in pop_binding, at cp/name-lookup.c:380
--- Additional Comments From flash at pobox dot com 2005-07-22 02:35 --- This sounds like bugs 9777 and 5402, but those were supposedly fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22603
[Bug c++/22603] internal compiler error: in pop_binding, at cp/name-lookup.c:380
--- Additional Comments From flash at pobox dot com 2005-07-22 02:32 --- Created an attachment (id=9326) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9326&action=view) 104911_HtmlView_min.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22603
[Bug c++/22603] New: internal compiler error: in pop_binding, at cp/name-lookup.c:380
The invalid code below results in "internal compiler error: in pop_binding, at
cp/name-lookup.c:380"
with a checking version of GCC 4.0.1. Does not happen with GCC 3.3.4.
class NameOne : public static_small_value
{
inline NameOne(T v) {
}
{
};
template
class NameTwo : private NameThree
{
void NameFour(const struct NameFive &cache);
This code is a greatly-reduced (and anonymized) excerpt, found by Daniel
Wilkerson's Delta, from some
real PalmSource code; I'm not sure it makes any sense at all. The original
code seemed to give a
different compiler error, which I'll try to file separately; though it involves
16K lines of proprietary code,
so it may have to wait for our CodeSourcery support agreement.
===
Session:
117> /opt/gcc401chk/bin/g++ -v
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/
104911_HtmlView_min.ii
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-checking --prefix=/opt/gcc401chk
--enable-languages=c,c+
+
Thread model: posix
gcc version 4.0.1
/opt/gcc401chk/libexec/gcc/i686-pc-linux-gnu/4.0.1/cc1plus -fpreprocessed
/Projects/
PlatformTools/compilerChain/tests/cpp/bugfiles/error/104911_HtmlView_min.ii
-quiet -dumpbase
104911_HtmlView_min.ii -mtune=pentiumpro -auxbase 104911_HtmlView_min -version
-o /tmp/
ccKTKYmH.s
GNU C++ version 4.0.1 (i686-pc-linux-gnu)
compiled by GNU C version 3.3.4 (pre 3.3.5 20040809).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/104911_HtmlView_min.ii:2:
error:
expected class-name before { token
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/104911_HtmlView_min.ii:3:
error:
expected `)' before v
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/104911_HtmlView_min.ii:5:
error:
expected unqualified-id before { token
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/104911_HtmlView_min.ii:9:
error:
expected class-name before { token
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/104911_HtmlView_min.ii:10:
error:
expected `}' at end of input
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/104911_HtmlView_min.ii:10:
error:
expected unqualified-id at end of input
/Projects/PlatformTools/compilerChain/tests/cpp/bugfiles/error/104911_HtmlView_min.ii:10:
internal
compiler error: in pop_binding, at cp/name-lookup.c:380
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
PalmSource bug 104911
--
Summary: internal compiler error: in pop_binding, at cp/name-
lookup.c:380
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: flash at pobox dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22603
[Bug c++/22590] parser does not recover well after error
--- Additional Comments From igodard at pacbell dot net 2005-07-22 01:25 --- Then Andrew's test case is not showing the problem. In the original, although the message is the same as Andrew's, the line/file reference is deep inside a system include that contains the first program text after the point of error: In file included from /mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/cstddef:48, from /home/ivan/ootbc/common/include/comtype.hh:6, from ../../members/include/opClock.hh:4, from opClock.cc:2: /mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/include/stddef.h:151: error: expected constructor, destructor, or type conversion before string constant The cited line in stddef.h does not contain a string constant, as the message seems to assert. The actual error was four files away in opClock.cc, and pretty hard to find. In Andrew's test, ithe compiler reports: x.cc:1: error: expected constructor, destructor, or type conversion before string constant Note that here the cited line is line 1, i.e. the line where the cited string constant appears and so Andrew's case gives the right line/file, whereas the original does not. If in the original the same message had given the line/file of the "string constant" it mentions (which was the file name in what was intended to be a #include) I'd be happy, but it doesn't. I don't know what the difference is between the original report code and Andrew's as far as the parser is concerned, but the location in the message in the original is lousy while in Andrew's it's fine. I surmise that the line/file reporting system is confused when the parser scans over an #include boundary (or several); that happens in the original and not in Andrew's. Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22590
[Bug c++/22591] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From pcarlini at suse dot de 2005-07-22 01:24 --- For the moment, I give up: in my opinion, a miscompilation is still the most likely possibility. Meaningless behaviors are taking place: for instance, the testcase passes if I exchange the arguments of swap to (my_other_list, my_list) and of course the implementation is symmetric and nobody changed it for eons. A last comment about mudflap. Right now, I'm not really able to make sense out of some of its outputs: even a single push_back() to a single list leads to errors?!? Really, it would be great if Janis could hunt for the regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug c++/22602] I can't enter a bug here
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22 01:01 --- Are you filing via the web? If so attach the preprocessed source after you submitted the bug. The reason for the limit is so we don't get the preprocessed source inlined and have to copy and paste. I see you are reporting against a 4.0.x (because of the error message). If this is 4.0.0, please try and use 4.0.1 and if that does not work, please report a new bug and attach the preprocessed source after submitting. Also if you run into the 1M limit when attaching, please use gzip or bzip2 to compress it and then attach that. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22602
[Bug c++/22602] I can't enter a bug here
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-22 00:59 --- Subject: Re: New: I can't enter a bug here On Fri, 2005-07-22 at 00:57 +, jacob dot navia at ants dot com wrote: > Because there is a size limitation to 64K in this software. > I prepared a single file with no includes that faithfully reproduced the bug: > bug0.cpp: In member function 'double AtomicDouble::CompareExchange(double, > double) volatile': > bug0.cpp:4999: internal compiler error: in create_tmp_var, at gimplify.c:368 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > > This took me hours. THEN, I entered here the file. > > This software told me when I pressed the "submmit" button that > my stuff was bigger than 64K, then IT DISCARDED ALL MY INPUT. > > NICE. > > I have worked like 3 hours more but the file size went down fro; 350k to 162K > only. It is becoming increasingly difficult to reduce the size. > > In this times, *ANY* include directive will produce file sizes of more than > 64K. > > Why this stupid limitation? > Uh, becuase we want you to *attach the file*, not *paste it into the comments*. Click create new attachment Why the heck would we want to see 65k of text in the comments of a bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22602
Re: [Bug c++/22602] New: I can't enter a bug here
On Fri, 2005-07-22 at 00:57 +, jacob dot navia at ants dot com wrote: > Because there is a size limitation to 64K in this software. > I prepared a single file with no includes that faithfully reproduced the bug: > bug0.cpp: In member function 'double AtomicDouble::CompareExchange(double, > double) volatile': > bug0.cpp:4999: internal compiler error: in create_tmp_var, at gimplify.c:368 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > > This took me hours. THEN, I entered here the file. > > This software told me when I pressed the "submmit" button that > my stuff was bigger than 64K, then IT DISCARDED ALL MY INPUT. > > NICE. > > I have worked like 3 hours more but the file size went down fro; 350k to 162K > only. It is becoming increasingly difficult to reduce the size. > > In this times, *ANY* include directive will produce file sizes of more than > 64K. > > Why this stupid limitation? > Uh, becuase we want you to *attach the file*, not *paste it into the comments*. Click create new attachment Why the heck would we want to see 65k of text in the comments of a bug?
[Bug c++/22602] New: I can't enter a bug here
Because there is a size limitation to 64K in this software. I prepared a single file with no includes that faithfully reproduced the bug: bug0.cpp: In member function 'double AtomicDouble::CompareExchange(double, double) volatile': bug0.cpp:4999: internal compiler error: in create_tmp_var, at gimplify.c:368 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. This took me hours. THEN, I entered here the file. This software told me when I pressed the "submmit" button that my stuff was bigger than 64K, then IT DISCARDED ALL MY INPUT. NICE. I have worked like 3 hours more but the file size went down fro; 350k to 162K only. It is becoming increasingly difficult to reduce the size. In this times, *ANY* include directive will produce file sizes of more than 64K. Why this stupid limitation? -- Summary: I can't enter a bug here Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jacob dot navia at ants dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22602
[Bug tree-optimization/22504] [4.1 Regression] benchmark - galgel fails at runtime with miscompare output
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-22 00:33 --- Subject: Bug 22504 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-22 00:33:48 Modified files: gcc: ChangeLog tree-complex.c Log message: PR tree-opt/22504 * tree-complex.c (complex_ssa_name_components): New. (cvc_lookup): Allow entry not found. (create_components): Remove. (create_one_component_var, get_component_var): New. (get_component_ssa_name, set_component_ssa_name): New. (extract_component): Use get_component_ssa_name. (update_complex_components): Use set_component_ssa_name. (update_complex_components_on_edge): Likewise. (update_phi_components): Create new PHI nodes directly, instead of adding insns to edges. (tree_lower_complex): Allocate and free complex_variable_components and complex_ssa_name_components here. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9507&r2=2.9508 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-complex.c.diff?cvsroot=gcc&r1=2.36&r2=2.37 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22504
[Bug c++/22596] Impossible to explicitly instantiate particular overloaded function
--- Additional Comments From bangerth at dealii dot org 2005-07-22 00:18
---
Oh, I apparently didn't read closely enough. I see the problem now.
For others -- take this:
-
template void f(T) {}
template void f(T) {}
template void f (int);
-
We want the first function to be instantiated, but both functions match
the signature and gcc (as well as icc) instantiate the second:
g/x> c++ -c x.cc
g/x> nm -C x.o
W void f(int)
I remember that there was a PR on this somewhere in bugzilla, and possibly
a DR on this. I don't remember the conclusion, though...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22596
[Bug c++/22591] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From pcarlini at suse dot de 2005-07-21 23:34 --- > The test case passes for me on powerpc-linux with GCC 3.4.x and fails with > everything later. Mainline doesn't fail for me on x86-linux, but I have it configured with a different allocator (new). Is the mudflap output enough to track down the problem, > or would the results of a regression hunt still help? I'm trying to debug a little further, a regression hunt would definitely help! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug ada/22601] New: GNAT Command lists many commands as available that are not
Typing the command "gnat" results in the following output (note this is Centos 4.1 but I am pretty sure this is not target specific) : GNAT 3.4.3 20050227 (Red Hat 3.4.3-22.1) Copyright 1996-2004 Free Software Found ation, Inc. List of available commands GNAT BIND gnatbind GNAT CHOP gnatchop GNAT CLEAN gnatclean GNAT COMPILEgnatmake -f -u -c GNAT ELIM gnatelim GNAT FIND gnatfind GNAT KRUNCH gnatkr GNAT LINK gnatlink GNAT LIST gnatls GNAT MAKE gnatmake GNAT NAME gnatname GNAT PREPROCESS gnatprep GNAT PRETTY gnatpp GNAT STUB gnatstub GNAT XREF gnatxref Commands FIND, LIST, PRETTY, STUB and XREF accept project file switches -vPx, -P prj and -Xnam=val Some of the commands that are listed as available commands are not really available: %gnat elim Couldn't locate gnatelim %gnat pretty Couldn't locate gnatpp %gnat stub Couldn't locate gnatstub I think these are only available with the pro distribution of GNAT. Seems to still be the case in HEAD right now too (with possible addition of the sub command metric). Perhaps gnatcmd.adb should be updated so that it looks at some other file that is already branched between the FSF sources and ACT and tailor the output to only include those commands that are actually expected to be present. -- Summary: GNAT Command lists many commands as available that are not Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: minor Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jeff at thecreems dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22601
[Bug c++/22596] Impossible to explicitly instantiate particular overloaded function
--- Additional Comments From phenning at lanl dot gov 2005-07-21 23:26 --- (In reply to comment #5) > Your explicit instantiation > template int foo< A_class >(A_class a); > obviously matches both the declarations of foo. I'm unsure which > one the compiler should choose, but if you want to instantiate the > second one, why don't you write > template int foo< A_class,int >(A_class a); > i.e. explicitly state the second template argument as well? The compiler is more than happy to instantiate the second one... the problem is that it is converting my one template parameter explicit specialization into the two template parameter form, presumably because the function signature matches. I would expect that if I explicitly state the one parameter form, the compiler should instantiate the one parameter form. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22596
[Bug debug/21828] [4.0/4.1 Regression] debug info omitted for uninitialized variables
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-07-21 23:26 --- Jakub -- Thank you for finding the patch that fixed this problem. Richard's patch changed things to mark the problematic variable as DECL_IGNORED_P earlier, so my patch is no longer necessary. As for Jim's comments about matching the source, the variable is also DECL_ARTIFICIAL, so perhaps its reasonable to assume that the user doesn't care about it. I will try a test run with my patch reverted; if that passes, and still fixes the bug in this PR, I will check in. Thanks! -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21828
[Bug target/22577] [4.1 Regression] PA bootstrap fails
--- Additional Comments From danglin at gcc dot gnu dot org 2005-07-21 23:19 --- I won't have time to test until early next week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22577
[Bug c++/22596] Impossible to explicitly instantiate particular overloaded function
--- Additional Comments From bangerth at dealii dot org 2005-07-21 23:17 --- Your explicit instantiation template int foo< A_class >(A_class a); obviously matches both the declarations of foo. I'm unsure which one the compiler should choose, but if you want to instantiate the second one, why don't you write template int foo< A_class,int >(A_class a); i.e. explicitly state the second template argument as well? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22596
[Bug c++/22590] parser does not recover well after error
--- Additional Comments From bangerth at dealii dot org 2005-07-21 23:11
---
With Andrew's little testcase, I get
g/x> cat > x.cc
include "core.hh"
typedef unsigned int size_t;
namespace std
{
using ::size_t;
}
g/x> /home/bangerth/bin/gcc-4.1-pre/bin/c++ -c x.cc
x.cc:1: error: expected constructor, destructor, or type conversion before
string constant
x.cc:5: error: ‘::size_t‘ has not been declared
I guess that's as good as it gets: it doesn't understand your include
statement
(understandably so) and then keeps reading. Since there is no semicolon
after the botched include, it skips the rest of the presumed statement
until after your declaration of ::size_t. The next error is where you
use ::size_t, which of course it doesn't know.
What's wrong with this?
W.
--
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22590
[Bug c++/22575] immutable object placed in .bss section.
--- Additional Comments From bangerth at dealii dot org 2005-07-21 23:00 --- No, icc puts it into bss and runs code to initialize it with 7: .bss .align 4 .globl _ZN3obj5sevenE _ZN3obj5sevenE: .type _ZN3obj5sevenE,@object .size _ZN3obj5sevenE,4 .space 4# pad .data .align 4 W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22575
[Bug target/20191] [3.4 Regression] ICE in reload_cse_simplify_operands, on powerpc linux
--- Additional Comments From janis at gcc dot gnu dot org 2005-07-21 22:25 --- Fixed on the 3.4 branch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20191
[Bug driver/22600] Exit code should be different from 1 for internal compiler error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 22:14 --- One more thing usually ICEs have better error messages than just Segmentation fault. some give the line number in GCC's source where it occurred. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600
[Bug driver/22600] Exit code should be different from 1 for internal compiler error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21
22:12 ---
I don't see why it should be different than 1. It would only be helpful when
you have automated builds
but even then you need to look at the errors.
and for recursive crash testing you need to look for a pattern still as you
might hit a different bug.
Here is a python script which I use as a wrapper:
#!/usr/bin/python
# Using delta debugging on GCC input
#import psyco
#from psyco.classes import *
import commands
import string
import sys
# Invoke GCC
(status, output) =
commands.getstatusoutput("/Users/pinskia/local.c/libexec/gcc/powerpc-apple-
darwin7.9.0/4.1.0/cc1plus --param ggc-min-expand=0 --param ggc-min-heapsize=0
-quiet -O2
-Wfatal-errors %s 2>&1" % sys.argv[1])
# Determine outcome
if status == 0:
sys.exit(1)
elif string.find(output, "Segmentation Fault") >= 0:
sys.exit(0)
else:
sys.exit(1)
cut
You might want to look into delta for reducing testcases:
http://www.cs.berkeley.edu/~dsw/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600
[Bug driver/22600] New: Exit code should be different from 1 for internal compiler error
Steps: 93> /opt/gcc401chk/bin/g++ -pass-exit-codes ../cpp/bugfiles/error/EckelRob_104822.ii ../jammed/Barney/eckel.cpp:2039: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. 94> echo $? [This uses my file for bug 22508.] Actual Result: 1 Expected Result: Anything but 1 or 0. For recursive crash testing, the return code for an internal compiler error should be distinguishable from that for correct rejection of incorrect code. As a workaround, I've been checking the output for the presence and absence of various patterns, but this is inelegant and subject to error. PalmSource bug 50522. -- Summary: Exit code should be different from 1 for internal compiler error Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: flash at pobox dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600
[Bug target/20191] [3.4 Regression] ICE in reload_cse_simplify_operands, on powerpc linux
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-21 21:57 --- Subject: Bug 20191 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-07-21 21:57:05 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.md gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: 20050721-1.c Log message: PR target/20191 Backport from mainline: 2004-04-23 Dale Johannesen <[EMAIL PROTECTED]> * config/rs6000.md (movsf_hardfloat): Add POWER form of nop. (movdf_hardfloat64): Ditto. (movdf_softfloat64): Ditto. * config/rs6000.md (movsf_hardfloat): Accept CTR-to-CTR copy. (movdf_hardfloat64): Ditto. testsuite: PR target/20191 * gcc.c-torture/compile/20050721-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.883&r2=2.2326.2.884 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.284.4.18&r2=1.284.4.19 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.407&r2=1.3389.2.408 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050721-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20191
[Bug inline-asm/20718] "+r" constraint with uninitialized value
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-07-21
21:06 ---
gcc4 behaviour seems fine to me.
A slightly simpler example
int foo(int a)
{
int b;
asm ("" : "+r" (b) : "r" (a));
return b;
}
Can be (and is) legitimately be transformed into
int foo(int a)
{
asm ("" : "+r" (a) : "r" (a));
return a;
}
In which case it's much more obvious that the compiler is going to allocate
the same register.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20718
[Bug target/22599] ICE with invalid asm usage
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 20:38 --- Confirmed, only the second example fails from 4.0.0 upwards. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-21 20:38:00 date|| Summary|Segfault with invalid asm |ICE with invalid asm usage |usage | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22599
[Bug target/21149] invalid code generation for _mm_movehl_ps SSE intrisinc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 20:33 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21149
[Bug target/22576] [4.0/4.1 regression] ICE with simple factorial program compiled with -ffast-math on gcc 4.0.2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 20:33 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22576
[Bug c++/2922] [DR 197] two-stage lookup for unqualified function calls with type-dependent arguments
--- Additional Comments From sebor at roguewave dot com 2005-07-21 20:33 --- (In reply to comment #13) ... > * g++.dg/lookup/two-stage2.C: New. FWIW, the following comment in this patch is wrong: + g(2);// f(char) followed by f(int) ^^ The call to g(2) should cause 2 calls to f(char). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2922
[Bug target/22599] Segfault with invalid asm usage
-- What|Removed |Added Component|c |target Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22599
[Bug c++/22597] [4.1 Regression] pure attribute produces incorrect results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21
20:14 ---
Confirmed, reduced testcase:
extern "C" void abort(void);
int t = 0;
struct point
{
point( const point& o ) {}
explicit point(){}
point __attribute__((pure)) operator/(const double m ) const
{
t++;
}
};
void f(const point&){}
int main()
{
point a;
f(a / 5.0);
if (t!=1)
abort();
return 0;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||wrong-code
Known to fail||4.0.1
Known to work||3.4.0 4.1.0
Last reconfirmed|-00-00 00:00:00 |2005-07-21 20:14:55
date||
Summary|pure attribute produces |[4.1 Regression] pure
|incorrect results |attribute produces incorrect
||results
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22597
[Bug c/22599] New: Segfault with invalid asm usage
I triggered a segfault on a i386 target with a piece of code intented to be
compiled for avr target. I get a more descriptive message by modifiying the code
a little bit. Here is the source, messages and versions :
typedef unsigned long uint32_t;
typedef unsigned char uint8_t;
int
main (void)
{
volatile uint32_t d = 0;
volatile uint8_t b0 = 1, b1 = 2, b2 = 3, b3 = 4;
asm ("mov %C0, %3" "\r\n"
"mov %D0, %4" "\r\n"
: "=d" (d) : "r" (b0), "r" (b1), "r" (b2), "r" (b3));
return 0;
}
/*
cc -g -Wall -W -Wundef -O2 -I../../.. -I../../../common -MMD -include
avrconfig.h t.c -o t
t.c: In function `main':
t.c:13: internal compiler error: Segmentation fault
*/
/* Or with a modified version :
typedef unsigned long uint32_t;
typedef unsigned char uint8_t;
int
main (void)
{
volatile uint32_t d = 0;
volatile uint8_t b0 = 1, b1 = 2, b2 = 3, b3 = 4;
asm ("mov %D0, %4" "\r\n"
: "=d" (d) : "r" (b0), "r" (b1), "r" (b2), "r" (b3));
return 0;
}
*/
/*
t.c:15: internal compiler error: in print_operand, at config/i386/i386.c:7003
*/
/* gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-13)
*/
--
Summary: Segfault with invalid asm usage
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schodet at efrei dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-linux
GCC host triplet: i486-linux
GCC target triplet: i486-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22599
[Bug tree-optimization/22598] [4.1 Regression] 23_containers/set/explicit_instantiation/3.cc fails
-- What|Removed |Added Keywords||ice-on-valid-code Summary|23_containers/set/explicit_i|[4.1 Regression] |nstantiation/3.cc fails |23_containers/set/explicit_i ||nstantiation/3.cc fails Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22598
[Bug target/21149] invalid code generation for _mm_movehl_ps SSE intrisinc
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-21 19:59 --- Subject: Bug 21149 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-21 19:59:09 Modified files: gcc: ChangeLog gcc/config/i386: sse.md Log message: PR target/21149 * config/i386/i386.md (sse_movhlps): Fix vec_select values. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9505&r2=2.9506 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/sse.md.diff?cvsroot=gcc&r1=1.21&r2=1.22 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21149
[Bug target/21149] invalid code generation for _mm_movehl_ps SSE intrisinc
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-21 19:58 --- Subject: Bug 21149 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-07-21 19:58:31 Modified files: gcc: ChangeLog gcc/config/i386: sse.md Log message: PR target/21149 * config/i386/i386.md (sse_movhlps): Fix vec_select values. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.326&r2=2.7592.2.327 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/sse.md.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.7&r2=1.7.14.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21149
[Bug tree-optimization/22598] New: 23_containers/set/explicit_instantiation/3.cc fails
FAIL: 23_containers/set/explicit_instantiation/3.cc (test for excess errors) is still present on mainline on i686-pc-linux-gnu on 20050721 (07:00 UTC). This was related to bugs 22444, 22416, 22483 which have been closed (1.cc and 2.cc do indeed now pass). /scratch/gcc/nightly-2005-07-21-mainline/i686-pc-linux-gnu/build_gcc/build/gcc-mainline-nightly-i686-pc-linux-gnu-i686-pc-linux-gnu/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_set.h: In member function 'std::pair, _Compare, typename _Alloc::rebind<_Key>::other>::const_iterator, bool> std::set<_Key, _Compare, _Alloc>::insert(const _Key&) [with _Key = int, _Compare = std::less, _Alloc = std::allocator]': /scratch/gcc/nightly-2005-07-21-mainline/i686-pc-linux-gnu/build_gcc/build/gcc-mainline-nightly-i686-pc-linux-gnu-i686-pc-linux-gnu/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_set.h:318: internal compiler error: tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:466 -- Summary: 23_containers/set/explicit_instantiation/3.cc fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22598
[Bug target/22576] [4.0/4.1 regression] ICE with simple factorial program compiled with -ffast-math on gcc 4.0.2
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-21 19:56 --- Subject: Bug 22576 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-07-21 19:56:30 Modified files: gcc: ChangeLog gcc/config/i386: i386.md Log message: PR target/22576 * config/i386/i386.md (cmpxf): Change operand constraints to "nonmemory_operand". Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.325&r2=2.7592.2.326 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.618.4.4&r2=1.618.4.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22576
[Bug c++/22597] pure attribute produces incorrect results
--- Additional Comments From eda-qa at disemia dot com 2005-07-21 19:55 --- Created an attachment (id=9325) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9325&action=view) demostration of the error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22597
[Bug target/22576] [4.0/4.1 regression] ICE with simple factorial program compiled with -ffast-math on gcc 4.0.2
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-21 19:55 --- Subject: Bug 22576 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-21 19:55:03 Modified files: gcc: ChangeLog gcc/config/i386: i386.md Log message: PR target/22576 * config/i386/i386.md (cmpxf): Change operand constraints to "nonmemory_operand". Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9504&r2=2.9505 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&r1=1.649&r2=1.650 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22576
[Bug c++/22597] pure attribute produces incorrect results
--- Additional Comments From eda-qa at disemia dot com 2005-07-21 19:54 --- Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.1 (Debian 4.0.1-2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22597
[Bug c++/22597] New: pure attribute produces incorrect results
In the attached code the pure attribute is causing the result to be random/junk on the final calculation in main. According to the docs the function seems to qualify for pure status -- it uses only the parameters given. It does however create a temporary (but as this exists on the stack I assumed it is okay, since it still doesn't violate the notion of being pure). Expected result (with -DNOATTRIB or -DNOCOPYCTOR flags): 5, 5 1, 1 Actual Result (compiled with g++ -o test point_err.cc): 5, 5 338848, 4.85849e-270 (NOTE: Worked on 3.3) It is curious also that no declaring the copy constructor also allows this code to work with the pure attribute. So, either this is a bug in the 4.0 "pure" handling, or the documentation for "pure" is omitting some vital point which my code violates. -- Summary: pure attribute produces incorrect results Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eda-qa at disemia dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22597
[Bug middle-end/21180] [4.1 Regression] checking on fold no longer happens in some cases
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-21 19:36 --- Subject: Bug 21180 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-21 19:36:51 Modified files: gcc: ChangeLog fold-const.c Log message: 2005-07-21 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/21180 * fold-const.c (fold_build1): Add checksum for the operands. (fold_build2): Likewise. (fold_build3): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9502&r2=2.9503 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.607&r2=1.608 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21180
[Bug middle-end/21180] [4.1 Regression] checking on fold no longer happens in some cases
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 19:36 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21180
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
-- Bug 19987 depends on bug 19055, which changed state. Bug 19055 Summary: Minor bit optimization with or and xor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19055 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
[Bug tree-optimization/19055] Minor bit optimization with or and xor
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-21 19:34 --- Subject: Bug 19055 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-21 19:33:50 Modified files: gcc: ChangeLog fold-const.c gcc/testsuite : ChangeLog Log message: 2005-07-21 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/19055 * gcc.dg/tree-ssa/pr19055.c: New test. * gcc.dg/tree-ssa/pr19055-2.c: New test. 2005-07-21 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/19055 * fold-const.c (fold_binary): Transform "(X | Y) ^ X" to "Y & ~ X". Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9501&r2=2.9502 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.606&r2=1.607 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5798&r2=1.5799 --- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 19:34 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19055
[Bug tree-optimization/19055] Minor bit optimization with or and xor
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-21 19:34 --- Subject: Bug 19055 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-21 19:33:50 Modified files: gcc: ChangeLog fold-const.c gcc/testsuite : ChangeLog Log message: 2005-07-21 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/19055 * gcc.dg/tree-ssa/pr19055.c: New test. * gcc.dg/tree-ssa/pr19055-2.c: New test. 2005-07-21 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/19055 * fold-const.c (fold_binary): Transform "(X | Y) ^ X" to "Y & ~ X". Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9501&r2=2.9502 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.606&r2=1.607 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5798&r2=1.5799 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19055
[Bug c++/22596] Impossible to explicitly instantiate particular overloaded function
--- Additional Comments From phenning at lanl dot gov 2005-07-21 19:16
---
(In reply to comment #2)
> void g(void)
> {
> A_class a;
> foo >(a);
> }
Right, and I think that it should in that case. It seems that g++ attempts to
call the first definition
when there is usage like:
foo(something_that_returns_Aclass_int());
So, when I try to compile code that uses std::vector, the compiler
generates calls to both
std::_Destroy >(int *, int*, std::allocator)
and
std::_Destroy, int>(int *, int*, std::allocator)
Since I can't explicitly instantiate the first form, I can't compile
std::vector code with -fno-implicit-
templates.
This could be changed by how _Destroy is implemented, but it seems strange that
I can't explicitly
instantiate a class, given that I'm providing the template parameter signature
explicitly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22596
[Bug c++/22596] Impossible to explicitly instantiate particular overloaded function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 18:58 --- I don't think this is a bug in the front-end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22596
[Bug c++/22596] Impossible to explicitly instantiate particular overloaded function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21
18:57 ---
Note both Comeau and ICC have this same behavior.
Even the following code calls the second declaration too:
template struct A_class
{
int do_it(int i){return T::f(i);}
};
template int foo(A a);
template int foo(A_class a)
{
return a.do_it(2);
}
void g(void)
{
A_class a;
foo >(a);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22596
[Bug c++/22596] Impossible to explicitly instantiate particular overloaded function
--- Additional Comments From phenning at lanl dot gov 2005-07-21 18:48 --- Created an attachment (id=9324) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9324&action=view) sample code illustrating problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22596
[Bug c++/22596] New: Impossible to explicitly instantiate particular overloaded function
Compiling the following code with "g++ -c -fno-implict-templates" always
generates code for the
second definition of foo(). It appears that g++ is automatically deducing the
template parameters from
the function parameters, even though the template parameters are explicitly
given in the explict
instantiation. This problem prevents explicitly instantiating the function
std::_Destroy>(int *, int *, std::allocator);
from bits/stl_construct.h in the 4.x Common Library implementation.
This behavior has been seen in:
i686-pc-linux-gnu gcc-3.4.2
powerpc-apple-darwin8 gcc-4.0.0 (20041026 Apple Computer build 4061)
i686-pc-linux-gnu gcc-4.1.0 20050629 (experimental)
// ---
template struct A_class
{
int do_it(int i) { return i+1; }
};
template int foo(A a)
{
return a.do_it(1);
}
template int foo(A_class a)
{
return a.do_it(2);
}
template int foo< A_class >(A_class a);
// ---
--
Summary: Impossible to explicitly instantiate particular
overloaded function
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: phenning at lanl dot gov
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu, powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22596
[Bug c++/22358] C++ front-end produces mis-match types in MODIFY_EXPR
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-21 18:29 --- Subject: Bug 22358 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-21 18:29:06 Modified files: gcc/cp : ChangeLog class.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/other: pr22358.C Log message: 2005-07-21 Andrew Pinski <[EMAIL PROTECTED]> PR C++/22358 * g++.dg/other/pr22358.C: New test. 2005-07-21 Andrew Pinski <[EMAIL PROTECTED]> PR C++/22358 * class.c (build_base_path): Convert BINFO_OFFSET to the correct type. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4829&r2=1.4830 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.727&r2=1.728 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5797&r2=1.5798 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/pr22358.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22358
[Bug other/22368] [meta-bugs] mis-match types in GCC
-- Bug 22368 depends on bug 22358, which changed state. Bug 22358 Summary: C++ front-end produces mis-match types in MODIFY_EXPR http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22358 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
[Bug c++/22358] C++ front-end produces mis-match types in MODIFY_EXPR
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 18:29 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22358
[Bug libstdc++/22087] ctype tables are offset by one on DJGPP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 18:08 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-21 18:08:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22087
[Bug rtl-optimization/21827] unroll misses simple elimination - works with manual unroll
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 18:07 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-21 18:07:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21827
[Bug target/21452] insn does not satisfy its constraints
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 18:04 --- Fixed for 3.4.0 and upwards. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work|4.1.0 |4.1.0 3.4.0 Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21452
[Bug c++/22591] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From janis at gcc dot gnu dot org 2005-07-21 17:59 --- The test case passes for me on powerpc-linux with GCC 3.4.x and fails with everything later. Is the mudflap output enough to track down the problem, or would the results of a regression hunt still help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug c++/22590] parser does not recover well after error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21
17:58 ---
Confirmed.
Testcase:
include "core.hh"
typedef unsigned int size_t;
namespace std
{
using ::size_t;
}
--
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||diagnostic
Last reconfirmed|-00-00 00:00:00 |2005-07-21 17:58:28
date||
Summary|parser hosed|parser does not recover well
||after error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22590
[Bug c++/22591] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 17:54 --- I wonder if this is not really a bug in libstdc++. with -fmudflap: *** mudflap violation 1 (check/write): time=1121968411.144393 ptr=0xbffa2030 size=4 pc=0x226d6d location=`t1.cc:9808 (std::_List_iterator::_List_iterator)' /home/peshtigo/pinskia/linux/lib/libmudflap.so.0(__mf_check+0x3d) [0x226d6d] ./a.out(_ZNSt14_List_iteratorIiEC1EPSt15_List_node_base+0x6f) [0x804b093] ./a.out(_ZNSt4listIiSaIiEE5beginEv+0x83) [0x804b145] Nearby object 1: checked region begins 16B before and ends 13B before mudflap object 0x9ce43b8: name=`t1.cc:10240 (std::list >::push_front) ' bounds=[0xbffa2040,0xbffa2043] size=4 area=stack check=0r/0w liveness=0 alloc time=1121968411.144386 pc=0x22604d Nearby object 2: checked region begins 7B before and ends 4B before mudflap dead object 0x9ce4350: name=`t1.cc:9992 (std::_List_base >:: _List_base) ' bounds=[0xbffa2037,0xbffa2037] size=1 area=stack check=0r/0w liveness=0 alloc time=1121968411.144362 pc=0x22604d dealloc time=1121968411.144370 pc=0x225ba6 number of nearby objects: 2 *** mudflap violation 2 (check/write): time=1121968411.146855 ptr=0xbffa2030 size=4 pc=0x226d6d location=`t1.cc:9808 (std::_List_iterator::_List_iterator)' /home/peshtigo/pinskia/linux/lib/libmudflap.so.0(__mf_check+0x3d) [0x226d6d] ./a.out(_ZNSt14_List_iteratorIiEC1EPSt15_List_node_base+0x6f) [0x804b093] ./a.out(_ZNSt4listIiSaIiEE5beginEv+0x83) [0x804b145] Nearby object 1: checked region begins 16B before and ends 13B before mudflap object 0x9d2cca8: name=`t1.cc:10240 (std::list >::push_front) ' bounds=[0xbffa2040,0xbffa2043] size=4 area=stack check=0r/0w liveness=0 alloc time=1121968411.146849 pc=0x22604d Nearby object 2: checked region begins 7B before and ends 4B before mudflap dead object 0x9d2cc58: name=`t1.cc:9992 (std::_List_base >:: _List_base) ' bounds=[0xbffa2037,0xbffa2037] size=1 area=stack check=0r/0w liveness=0 alloc time=1121968411.146839 pc=0x22604d dealloc time=1121968411.146845 pc=0x225ba6 number of nearby objects: 2 *** mudflap violation 3 (check/write): time=1121968411.147476 ptr=0xbffa2090 size=4 pc=0x226d6d location=`t1.cc:9808 (std::_List_iterator::_List_iterator)' /home/peshtigo/pinskia/linux/lib/libmudflap.so.0(__mf_check+0x3d) [0x226d6d] ./a.out(_ZNSt14_List_iteratorIiEC1EPSt15_List_node_base+0x6f) [0x804b093] ./a.out(_ZNSt4listIiSaIiEE5beginEv+0x83) [0x804b145] Nearby object 1: checked region begins 4B before and ends 1B before mudflap object 0x9ce4288: name=`t1.cc:29341 (main) std::_List_iterator it' bounds=[0xbffa2094,0xbffa2097] size=4 area=stack check=0r/0w liveness=0 alloc time=1121968411.144342 pc=0x22604d Nearby object 2: checked region begins 77B after and ends 80B after mudflap dead object 0x9d2cca8: name=`t1.cc:10240 (std::list >::push_front) ' bounds=[0xbffa2040,0xbffa2043] size=4 area=stack check=0r/0w liveness=0 alloc time=1121968411.146849 pc=0x22604d dealloc time=1121968411.147468 pc=0x225ba6 number of nearby objects: 2 *** mudflap violation 4 (check/write): time=1121968411.148044 ptr=0xbffa2088 size=4 pc=0x226d6d location=`t1.cc:9808 (std::_List_iterator::_List_iterator)' /home/peshtigo/pinskia/linux/lib/libmudflap.so.0(__mf_check+0x3d) [0x226d6d] ./a.out(_ZNSt14_List_iteratorIiEC1EPSt15_List_node_base+0x6f) [0x804b093] ./a.out(_ZNSt4listIiSaIiEE3endEv+0x19) [0x804b0b7] Nearby object 1: checked region begins 12B before and ends 9B before mudflap object 0x9ce4288: name=`t1.cc:29341 (main) std::_List_iterator it' Nearby object 2: checked region begins 16B before and ends 13B before mudflap object 0x9ce4220: name=`t1.cc:29322 (main) std::list > my_other_list' bounds=[0xbffa2098,0xbffa209f] size=8 area=stack check=0r/1w liveness=1 alloc time=1121968411.144338 pc=0x22604d Nearby object 3: checked region begins 69B after and ends 72B after mudflap dead object 0x9d2cca8: name=`t1.cc:10240 (std::list >::push_front) ' number of nearby objects: 3 *** mudflap violation 5 (check/write): time=1121968411.148637 ptr=0xbffa208c size=4 pc=0x226d6d location=`t1.cc:9808 (std::_List_iterator::_List_iterator)' /home/peshtigo/pinskia/linux/lib/libmudflap.so.0(__mf_check+0x3d) [0x226d6d] ./a.out(_ZNSt14_List_iteratorIiEC1EPSt15_List_node_base+0x6f) [0x804b093] ./a.out(_ZNSt4listIiSaIiEE5eraseESt14_List_iteratorIiE+0xd3) [0x804c737] Nearby object 1: checked region begins 8B before and ends 5B before mudflap object 0x9ce4288: name=`t1.cc:29341 (main) std::_List_iterator it' Nearby object 2: checked region begins 12B before and ends 9B before mudflap object 0x9ce4220: name=`t1.cc:29322 (main) std::list > my_other_list' Nearby object 3: checked region begins 20B before and ends 17B before mudflap object 0x9ce41b8: name=`t1.cc:29319 (main) std::list > my_list' bounds=[0xbffa20a0,0xbffa20a7] size=8 area=stack check=0r/1w liveness=1 alloc time=1121968411.144334 pc=0x22604d Nearby obj
[Bug debug/22514] [4.1 Regression] ICE in force_decl_die with invalid code after error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21
17:44 ---
Here is a shorter testcase:
namespace s
{
template struct _List_base
{
int _M_impl;
};
template struct list : _List_base
{
using _List_base::_M_impl;
}
}
s::list<1> OutputModuleListType;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22514
[Bug debug/22514] [4.1 Regression] ICE in force_decl_die with invalid code after error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 17:37 --- *** Bug 22593 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||micis at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22514
[Bug debug/22593] ICE in force_decl_die, at dwarf2out.c:12621
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 17:37 --- *** This bug has been marked as a duplicate of 22514 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22593
[Bug other/22594] HOST_LONG_LONG_FORMAT not used in HOST_WIDE_INT_PRINT macro
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 17:23 --- Confirmed. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||07/msg01413.html Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-07-21 17:23:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22594
[Bug c++/22595] [4.0 regression] wrong warning: control may reach end of non-void function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 17:10 --- This was already decided against being fixed for 4.0.x series. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22595
[Bug target/22576] [4.0/4.1 regression] ICE with simple factorial program compiled with -ffast-math on gcc 4.0.2
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-21 17:07 --- The problem is related to PR22585 where another ICE with long doubles occurs. Unfortunately Uros' patch doesn't fix the problem there. -- What|Removed |Added Keywords||monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22576
[Bug target/22585] [4.0/4.1 regression] ICE in redirect_branch_edge
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-21
17:05 ---
Confirmed (at least the ICE in redirect_branch_edge and extract_insn,
I cannot reproduce the one in expand_simple_unop).
Reduced testcase:
=
struct A
{
long double d;
};
int foo(struct A *p)
{
if (p->d)
return 1;
}
=
This is related to PR22576.
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||ice-on-valid-code, monitored
Last reconfirmed|-00-00 00:00:00 |2005-07-21 17:05:45
date||
Summary|[4.0/4.1 regression] ICE in |[4.0/4.1 regression] ICE in
|expand_simple_unop |redirect_branch_edge
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22585
[Bug c++/22595] [4.0 regression] wrong warning: control may reach end of non-void function
--- Additional Comments From debian-gcc at lists dot debian dot org 2005-07-21 17:05 --- Created an attachment (id=9323) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9323&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22595
[Bug c++/22595] [4.0 regression] wrong warning: control may reach end of non-void function
-- What|Removed |Added Known to fail||4.0.2 Known to work||3.4.4 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22595
[Bug c++/22595] New: [4.0 regression] wrong warning: control may reach end of non-void function
[forwarded from http://bugs.debian.org/319309] regression from 3.4, fixed in 4.1 Compile the attached example source code with: g++ -Wall -O3 -c bug.cc g++ produces the warning: bug.cc:9: warning: control may reach end of non-void function 'char* f(char*)' being inlined This is wrong, as should be obvious, since every possible control path in f() either leads to a return or a throw. g++ 3.x correctly analyses the code and does not generate a warning. -- Summary: [4.0 regression] wrong warning: control may reach end of non-void function Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22595
[Bug c++/22591] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 17:03 --- (In reply to comment #2) > It would greatly help to identify the patch that broke either this PR or PR > 22513. One possible offender is the new alias stuff by Diego/Daniel. Also Paolo said it works on the mainline so I really doube it was broken by those patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug c++/22591] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From giovannibajo at libero dot it 2005-07-21 16:59 --- It would greatly help to identify the patch that broke either this PR or PR 22513. One possible offender is the new alias stuff by Diego/Daniel. -- What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug other/22584] ICE in make_decl_rtl, at varasm.c:886
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 16:56 --- One thing you don't need gcc-ada-fwrapv.patch any more. The rest except for 20297 I trust are good as most are my patches. -- What|Removed |Added Status|UNCONFIRMED |WAITING Keywords||build, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22584
[Bug c++/22590] parser hosed
-- What|Removed |Added Attachment #9319|application/octet-stream|text/plain mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22590
[Bug other/22594] HOST_LONG_LONG_FORMAT not used in HOST_WIDE_INT_PRINT macro
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 16:52 --- Could you send your patch to [EMAIL PROTECTED] -- What|Removed |Added GCC build triplet|i686-pc-mingw32 | GCC target triplet||HWI_size==64 Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22594
[Bug other/22594] HOST_LONG_LONG_FORMAT not used in HOST_WIDE_INT_PRINT macro
-- What|Removed |Added CC||wintermute2k4 at ntlworld ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22594
[Bug other/22594] HOST_LONG_LONG_FORMAT not used in HOST_WIDE_INT_PRINT macro
--- Additional Comments From wintermute2k4 at ntlworld dot com 2005-07-21 16:46 --- Created an attachment (id=9322) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9322&action=view) proposed patch to hwint.h the attached patch seems to fix the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22594
[Bug other/22594] New: HOST_LONG_LONG_FORMAT not used in HOST_WIDE_INT_PRINT macro
For mips target hosted on mingw32 building libgcc2 fails. ccAF.s: Assembler messages: ccAF.s:19: Warning: expected `$' ccAF.s:19: Error: junk at end of line, first unrecognized character is `n' make[2]: *** [libgcc/./_muldi3.o] Error 1 the offending code is the function prologue produced by mips_output_function_prologue in gcc/config/mips/mips.c __muldi3: .frame$sp,0,(null)# vars= 7640055, regs= 0/0, args= 0, gp= 0 which should have been __muldi3: .frame$sp,0,$31# vars= 0, regs= 0/0, args= 0, gp= 0 this is caused by the HOST_WIDE_INT_PRINT_DEC macro in gcc/hwint.h not using the HOST_LONG_LONG_FORMAT override from /gcc/config/i386/xm-mingw32.h -- Summary: HOST_LONG_LONG_FORMAT not used in HOST_WIDE_INT_PRINT macro Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wintermute2k4 at ntlworld dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22594
[Bug c++/22592] -fvisibility-inlines-hidden broken differently
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 16:39 --- No I think this code is in fact invalid and should error out like this. Note you also declared operator== as being hidden too. So if you call that, it would break too. -- What|Removed |Added Component|middle-end |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22592
[Bug c/22589] [3.4 regression] ICE casting to long long
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-21 16:36 --- Confirmed. Appeared with gcc 3.4.0. Only affects 3.4 branch. -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code, monitored Known to fail||3.4.0 3.4.4 Known to work||3.3.6 4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-07-21 16:36:13 date|| Summary|gcc 3.4.3 segfault |[3.4 regression] ICE casting ||to long long Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22589
[Bug debug/22593] ICE in force_decl_die, at dwarf2out.c:12621
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 16:35 --- I think this is a dup of bug 22514. One thing that makes me think it is a dup of that bug is that the dates match up to the dates in that bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22593
[Bug debug/22593] ICE in force_decl_die, at dwarf2out.c:12621
--- Additional Comments From micis at gmx dot de 2005-07-21 16:22 --- Created an attachment (id=9321) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9321&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22593
[Bug debug/22593] New: ICE in force_decl_die, at dwarf2out.c:12621
When I compile one of our files with the actual snapshot of gcc41 I get an ICE. The last snapshot which works is gcc-4.1-20050604, the first that fails is gcc-4.1-20050611 Michael Cieslinski g++41g -g -c -o AutoFocus.o AutoFocus.ii AutoFocus.ii:32394: error: 'CompressDefault' was not declared in this scope AutoFocus.ii:32395: error: 'CompressDefault' was not declared in this scope AutoFocus.ii: In instantiation of 'std::list >': AutoFocus.ii:33244: instantiated from here AutoFocus.ii:27629: internal compiler error: in force_decl_die, at dwarf2out.c:12621 Please submit a full bug report, with preprocessed source if appropriate. g++41g -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.1-20050716/configure --prefix=/usr/local/gcc41g -- program-suffix=41g --with-arch=opteron --enable-languages=c,c++ --enable- checking Thread model: posix gcc version 4.1.0 20050716 (experimental) -- Summary: ICE in force_decl_die, at dwarf2out.c:12621 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de CC: gcc-bugs at gcc dot gnu 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=22593
[Bug middle-end/22592] -fvisibility-inlines-hidden broken differently
-- What|Removed |Added CC||mueller at kde dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22592
