[Bug libstdc++/24975] Aliasing problems inside libstdc++

2005-11-21 Thread rguenth at gcc dot gnu dot org
--- Comment #10 from rguenth at gcc dot gnu dot org 2005-11-21 22:59 --- The patch_draft_24975 alone fixed it. Looks like libstdc++ needs some auditing for aliasing issues... Thanks Paolo! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24975

[Bug libstdc++/24975] Aliasing problems inside libstdc++

2005-11-21 Thread pcarlini at suse dot de
--- Comment #11 from pcarlini at suse dot de 2005-11-21 23:02 --- (In reply to comment #10) The patch_draft_24975 alone fixed it. Looks like libstdc++ needs some auditing for aliasing issues... Indeed it does, but I expect that nothing is in a shape worse than basic_string from the

[Bug libstdc++/24975] Aliasing problems inside libstdc++

2005-11-21 Thread pcarlini at suse dot de
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org |

[Bug c++/21755] Warning from function template in system header

2005-11-21 Thread pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 23:06 --- Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)

2005-11-21 Thread schwab at suse dot de
--- Comment #5 from schwab at suse dot de 2005-11-21 23:07 --- The comment in the patch has a typo: clr.b (%a0) should be clr.b (%a1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201

[Bug libstdc++/24975] Aliasing problems inside libstdc++

2005-11-21 Thread pcarlini at suse dot de
--- Comment #12 from pcarlini at suse dot de 2005-11-21 23:07 --- (In reply to comment #10) The patch_draft_24975 alone fixed it. Looks like libstdc++ needs some auditing for aliasing issues... By the way, for your curiosity, I digged a bit and the set issue was already there in

[Bug tree-optimization/24931] [4.0 Regression] uninitialized structure member after assignment

2005-11-21 Thread pinskia at gcc dot gnu dot org
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-22 00:06 --- Fixed at least on the mainline and 4.1 branch for now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug ada/22533] [4.1/4.2 regression] Ada ICE during bootstrap on many platforms

2005-11-21 Thread pluto at agmk dot net
+===GNAT BUG DETECTED==+ | 4.1.0 20051121 (prerelease) (powerpc-pld-linux-gnu) Segmentation fault   | | Error detected at a-except.adb:1305:1                                    | raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380 make[2]: *** [ada/a-except.o] Error

[Bug target/24982] New: Bootstrap failure with ICE in refers_to_regno_for_reload_p

2005-11-21 Thread kkojima at gcc dot gnu dot org
The mainline and 4.1 fails to bootstrap on sh4-unknown-linux-gnu with stage1/xgcc -Bstage1/ -B/usr/gnu/sh4-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition

[Bug target/24982] Bootstrap failure with ICE in refers_to_regno_for_reload_p

2005-11-21 Thread kkojima at gcc dot gnu dot org
--- Comment #1 from kkojima at gcc dot gnu dot org 2005-11-22 01:12 --- Created an attachment (id=10317) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10317action=view) A reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24982

[Bug target/24982] Bootstrap failure with ICE in refers_to_regno_for_reload_p

2005-11-21 Thread kkojima at gcc dot gnu dot org
--- Comment #2 from kkojima at gcc dot gnu dot org 2005-11-22 01:17 --- 4.1 and 4.2 fail to compile gcc.c-torture/execute/20040709-[12].c at -O3 -m4 -ml for sh-elf with the same ICE internal compiler error: in refers_to_regno_for_reload_p, at reload.c:6281 after the same patch

[Bug c++/24983] New: Needs a warning?

2005-11-21 Thread igodard at pacbell dot net
struct foo { const void f(); }; void foo::f(){} gets you: ~/ootbc/members/src$ g++ foo.cc -Wall foo.cc:2: error: prototype for `void foo::f()' does not match any in class `foo' foo.cc:1: error: candidate is: const void foo::f() foo.cc:2: error: `void foo::f()' and `const void foo::f()' cannot be

[Bug c++/24983] Needs a warning?

2005-11-21 Thread gdr at integrable-solutions dot net
--- Comment #1 from gdr at integrable-solutions dot net 2005-11-22 02:46 --- Subject: Re: New: Needs a warning? igodard at pacbell dot net [EMAIL PROTECTED] writes: | struct foo { const void f(); }; | void foo::f(){} | | gets you: | | ~/ootbc/members/src$ g++ foo.cc -Wall |

[Bug bootstrap/24984] New: Use of old tail parameters in Makefile*

2005-11-21 Thread malitzke at metronets dot com
The tail utility in its newer versions requires 'tail -c +16' instead of the previous 'tail +16c'. This older version seems to used from gcc-3.4* through gcc-4.1* Makefile.in. It affects testing against stage2. a simple test that shows this is to execute from the gcc-package root the following:

[Bug c++/24983] Needs a warning?

2005-11-21 Thread pinskia at gcc dot gnu dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-22 03:01 --- Different versions give different diagnostics: earth:~gcc t.cc t.cc:2: error: prototype for 'void foo::f()' does not match any in class 'foo' t.cc:1: error: candidate is: const void foo::f() t.cc:2: error: 'void

[Bug bootstrap/24984] Use of old tail parameters in Makefile*

2005-11-21 Thread pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-22 03:03 --- As mentioned over and over again, coreutils is wrong. See PR 14251 and some new discussions on this recently. *** This bug has been marked as a duplicate of 14251 *** -- pinskia at gcc dot gnu dot org changed:

[Bug other/14251] Use POSIX-compatible flags for 'head' and 'tail'

2005-11-21 Thread pinskia at gcc dot gnu dot org
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-22 03:03 --- *** Bug 24984 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/18382] define __pic__ and/or __PIC__ in c-cppbuiltins.c instead of scattershot in target config

2005-11-21 Thread ghazi at gcc dot gnu dot org
--- Comment #5 from ghazi at gcc dot gnu dot org 2005-11-22 03:27 --- Updated patch installed on mainline: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01575.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/24983] Needs a warning?

2005-11-21 Thread igodard at pacbell dot net
--- Comment #3 from igodard at pacbell dot net 2005-11-22 03:45 --- The 3.0 is the best error, but I like the warning that comeau also gives: Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1 Copyright 1988-2003 Comeau Computing. All rights reserved. MODE:strict

[Bug fortran/24546] [meta-bug] gfortran debugging problems

2005-11-21 Thread woodzltc at sources dot redhat dot com
--- Comment #6 from woodzltc at sources dot redhat dot com 2005-11-22 03:49 --- I ever opened an issue to request to add something to identify the main function (such as Fortran MAIN__) in a program. But that is deferred to DWARF 4. So maybe now it is too late to add anything into

Re: [Bug c++/24983] Needs a warning?

2005-11-21 Thread Gabriel Dos Reis
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | earth:~~/ia32_linux_gcc3_0/bin/gcc t.cc | t.cc:2: prototype for `void foo::f()' does not match any in class `foo' | t.cc:1: candidate is: const void foo::f() | earth:~~/ia32_linux_gcc2_95//bin/gcc t.cc | t.cc:2: new declaration `void

[Bug c++/24983] Needs a warning?

2005-11-21 Thread gdr at integrable-solutions dot net
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-22 03:58 --- Subject: Re: Needs a warning? pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | earth:~~/ia32_linux_gcc3_0/bin/gcc t.cc | t.cc:2: prototype for `void foo::f()' does not match any in class `foo' |

[Bug c++/24985] New: Line info in diagnostics is very unfriendly

2005-11-21 Thread igodard at pacbell dot net
Showing the source line in the diagnostic, with a caret (^) inder the column in error, is much friendlier. The best I've ever seen also was graceful when the error was inside a maco expansion; it showed the position in the token list of each nested macro, limited to a dozen or so tokens on either

[Bug c++/24983] Needs a warning?

2005-11-21 Thread igodard at pacbell dot net
--- Comment #5 from igodard at pacbell dot net 2005-11-22 04:05 --- On the contrary, const void is a valid type, because the difference between const void* and void* preserved the typeless constness, which can be important in disambiguating templates. So if const void is valid as a

[Bug c++/24986] New: g++ is confused when function is defined inside and outside some namespace and called with '::' prefix

2005-11-21 Thread relf at os2 dot ru
g++ (GCC) 4.0.3 2005 (prerelease) (Debian 4.0.2-4) g++ fails to compile the attached program with the following error $ g++ bug.cpp bug.cpp: In member function 'void B::foo(N::C)': bug.cpp:12: error: cannot convert 'N::C' to 'long int' for argument '1' to 'void foo(long int)' Note that

[Bug c++/24986] g++ is confused when function is defined inside and outside some namespace and called with '::' prefix

2005-11-21 Thread relf at os2 dot ru
--- Comment #1 from relf at os2 dot ru 2005-11-22 04:33 --- Created an attachment (id=10318) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10318action=view) Testcase (bug.cpp) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24986

[Bug target/24951] [4.1/4.2 Regression] ICE: RTL check: expected code 'const_int', have 'const_double' in output_vec_const_move, at config/rs6000/rs6000.c

2005-11-21 Thread amodra at bigpond dot net dot au
--- Comment #7 from amodra at bigpond dot net dot au 2005-11-22 05:05 --- I verified that an x86-powerpc64 mainline compiler built with --enable-checking=all compiles the testcase without errors. -- amodra at bigpond dot net dot au changed: What|Removed

[Bug c++/24985] Line info in diagnostics is very unfriendly

2005-11-21 Thread pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-22 05:11 --- Confirmed, this was already a known issue. There is another bug mentioning the caret. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/24986] g++ is confused when function is defined inside and outside some namespace and called with '::' prefix

2005-11-21 Thread pinskia at gcc dot gnu dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-22 05:13 --- I don't think this is a bug as what is happening is that :: is a qualified name and qualified namelookup (IIRC) does not find decls which are injected via using. --

[Bug c++/24199] [3.4 Regression] Segfault with -frepo -g

2005-11-21 Thread mark at codesourcery dot com
--- Comment #5 from mark at codesourcery dot com 2005-11-22 05:17 --- Subject: Re: [3.4 Regression] Segfault with -frepo -g gdr at gcc dot gnu dot org wrote: --- Comment #4 from gdr at gcc dot gnu dot org 2005-11-21 02:39 --- (In reply to comment #3) It looks like it was

[Bug bootstrap/24984] Use of old tail parameters in Makefile*

2005-11-21 Thread malitzke at metronets dot com
--- Comment #2 from malitzke at metronets dot com 2005-11-22 06:00 --- Upon further investigation using coreutils-5.93 (using both the documentation and the compiled tail as test case) the following stands out: The interpretation adopted by support is on valid if env

[Bug other/14251] Use POSIX-compatible flags for 'head' and 'tail'

2005-11-21 Thread malitzke at metronets dot com
--- Comment #18 from malitzke at metronets dot com 2005-11-22 06:04 --- See comments in PR 24984 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14251

[Bug bootstrap/24984] Use of old tail parameters in Makefile*

2005-11-21 Thread pinskia at gcc dot gnu dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-22 06:13 --- Please read the recent thread: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00618.html Especially this one: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00783.html Again coreutils is buggy. *** This bug has been

[Bug other/14251] Use POSIX-compatible flags for 'head' and 'tail'

2005-11-21 Thread pinskia at gcc dot gnu dot org
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-22 06:13 --- *** Bug 24984 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14251

[Bug target/24954] [4.1/4.2 Regression] ICE: could not split insn

2005-11-21 Thread amodra at bigpond dot net dot au
--- Comment #4 from amodra at bigpond dot net dot au 2005-11-22 06:37 --- Weird. I don't see this ICE on a newly build --enable-checking=all x86-powerpc64 cross compiler. I do on a native powerpc64-linux compiler (built with default --enable-checking). -- amodra at bigpond dot

[Bug target/24954] [4.1/4.2 Regression] ICE: could not split insn

2005-11-21 Thread amodra at bigpond dot net dot au
--- Comment #5 from amodra at bigpond dot net dot au 2005-11-22 06:42 --- I'll bet this is the (char) cast in easy_vector_constant_add_self. char is unsigned on a powerpc host, so (char) (-24 255) results in 0xe8, not -24. Bootstrapping the obvious fix. --

[Bug libstdc++/23591] exceptions in plugins in threads cause segmentation violation by leaving bad exit handler for the pthread

2005-11-21 Thread bkoz at gcc dot gnu dot org
--- Comment #6 from bkoz at gcc dot gnu dot org 2005-11-22 06:54 --- Subject: Bug 23591 Author: bkoz Date: Tue Nov 22 06:54:08 2005 New Revision: 107350 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107350 Log: 2005-11-21 Benjamin Kosnik [EMAIL PROTECTED] Ulrich

[Bug rtl-optimization/24899] [4.1/4.2 Regression] loop.c miscompiles libgnomecanvas

2005-11-21 Thread steven at gcc dot gnu dot org
--- Comment #15 from steven at gcc dot gnu dot org 2005-11-22 07:33 --- Well then... Mine. -- steven at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/24951] [4.1/4.2 Regression] ICE: RTL check: expected code 'const_int', have 'const_double' in output_vec_const_move, at config/rs6000/rs6000.c

2005-11-21 Thread aj at gcc dot gnu dot org
--- Comment #8 from aj at gcc dot gnu dot org 2005-11-22 07:42 --- Seems to be fixed according to: http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg01060.html Compare this with: http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg01039.html Thanks! -- aj at gcc dot gnu dot org

<    1   2   3