[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

--- 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 changed

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

--- 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 Assig

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

--- 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=gcc&view=rev&rev=107350 Log: 2005-11-21 Benjamin Kosnik <[EMAIL PROTECTED]> Ulrich

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

--- 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. -- http://gcc.gnu.org/bu

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

--- 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 ne

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

--- 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 bootstrap/24984] Use of old "tail" parameters in Makefile*

--- 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 m

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

--- 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*

--- 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 _POSIX2_VERSION=1992

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

--- 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

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

--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24

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

--- 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 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

--- 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++/24986] g++ is confused when function is defined inside and outside some namespace and called with '::' prefix

--- 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=10318&action=view) Testcase (bug.cpp) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24986

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

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 remov

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

--- 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

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

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?

--- 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'

Re: [Bug c++/24983] 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' | 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 fortran/24546] [meta-bug] gfortran debugging problems

--- 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 DWA

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

--- 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 err

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

--- 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 other/14251] Use POSIX-compatible flags for 'head' and 'tail'

--- 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 bootstrap/24984] Use of old "tail" parameters in Makefile*

--- 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 c++/24983] Needs a warning?

--- 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 foo

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

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: f

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

--- 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 | fo

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

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 target/24982] Bootstrap failure with ICE in refers_to_regno_for_reload_p

--- 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 applied.

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

--- 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=10317&action=view) A reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24982

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

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 -Wmissing-

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

+===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 tree-optimization/24931] [4.0 Regression] uninitialized structure member after assignment

--- 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 libstdc++/24975] Aliasing problems inside libstdc++

--- 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 target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)

--- 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 c++/21755] Warning from function template in system header

--- 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 libstdc++/24975] Aliasing problems inside libstdc++

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

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

--- 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++

--- 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 libfortran/24903] dotprod should use conj?

--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-21 22:53 --- (In reply to comment #2) > I'm ready to do that, but since complex numbers in C are always a pain, I > want to know: are we sure that conj/conjf/conjl are *always* available? I > mean, are they part of the things gc

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

--- Comment #9 from rguenth at gcc dot gnu dot org 2005-11-21 22:35 --- Doing both fixed DLV! (now trying without that dynamic string thingie) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24975

[Bug fortran/24917] Handling of hexadecimal constants in gfortran

--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-21 22:29 --- http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01542.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24917

[Bug preprocessor/24976] [3.4/4.0/4.1/4.2 Regression] simple hexadecimal number and plus/minus and no space

--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-21 22:27 --- Confirmed, as a diagnostic issue only. I am going to mark this as a regression even though I know that the preprocessor was rewritten between 2.95.3 and 3.0.x. -- pinskia at gcc dot gnu dot org changed:

[Bug fortran/24774] [gomp-branch] wrong results for INQUIRE statement

--- Comment #4 from jakub at gcc dot gnu dot org 2005-11-21 22:04 --- Subject: Bug 24774 Author: jakub Date: Mon Nov 21 22:03:56 2005 New Revision: 107328 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107328 Log: gcc/fortran/ PR fortran/14943 PR fortran/21647

[Bug fortran/14943] read/write code generation is not thread safe

--- Comment #4 from jakub at gcc dot gnu dot org 2005-11-21 22:04 --- Subject: Bug 14943 Author: jakub Date: Mon Nov 21 22:03:56 2005 New Revision: 107328 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107328 Log: gcc/fortran/ PR fortran/14943 PR fortran/21647

[Bug fortran/21647] INQUIRE errors when using -fdefault-integer-8

--- Comment #6 from jakub at gcc dot gnu dot org 2005-11-21 22:04 --- Subject: Bug 21647 Author: jakub Date: Mon Nov 21 22:03:56 2005 New Revision: 107328 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107328 Log: gcc/fortran/ PR fortran/14943 PR fortran/21647

[Bug java/24980] GCJ/GIJ segfaults on Workout.java from Click and Hack's "Java Puzzlers"

--- Comment #7 from mckinlay at redhat dot com 2005-11-21 22:02 --- > Except that under Bryce's GCJ, the function terminates successfully > even if you throw in System.out.println's into it, thus tainting its > "purity". No, when I add a System.out.println("hi"), and compile with a trun

[Bug java/24980] GCJ/GIJ segfaults on Workout.java from Click and Hack's "Java Puzzlers"

--- Comment #6 from vadimn at redhat dot com 2005-11-21 21:52 --- (In reply to comment #5) > It is not that bizarre as what is happening is that the function is > being marked as a "pure" function so it does nothing useful, so we > remove it. Except that under Bryce's GCJ, the function

[Bug libgcj/1373] recursion stress test causes segmentation fault

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

[Bug java/24980] GCJ/GIJ segfaults on Workout.java from Click and Hack's "Java Puzzlers"

--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-21 21:46 --- (In reply to comment #3) > Number two, the TCO cannot possibly be applied in this case. (I can't > see how at the moment, but I'm willing to be convinced otherwise.) Actually TCO cannot because you still need to un

[Bug java/24980] GCJ/GIJ segfaults on Workout.java from Click and Hack's "Java Puzzlers"

--- Comment #4 from vadimn at redhat dot com 2005-11-21 21:40 --- Created an attachment (id=10316) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10316&action=view) call-tree-of-depth-4.png So, speaking of stress patterns, this is what the call tree looks like if you run attachment

[Bug java/24980] GCJ/GIJ segfaults on Workout.java from Click and Hack's "Java Puzzlers"

--- Comment #3 from vadimn at redhat dot com 2005-11-21 21:34 --- Yeah, this may be a dup. Bryce did mention that native-compiling this program with -O2 should turn on the TCO. There are two problems with this theory. Number one, it still segfaults for me: | $ gcj -O2 --main=Workout

[Bug java/24980] GCJ/GIJ segfaults on Workout.java from Click and Hack's "Java Puzzlers"

--- Comment #2 from vadimn at redhat dot com 2005-11-21 21:20 --- Created an attachment (id=10315) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10315&action=view) BinaryCallTree.java For my own education, I wrote a variation of Workout.java that prints out the call tree in the Gr

[Bug java/24980] GCJ/GIJ segfaults on Workout.java from Click and Hack's "Java Puzzlers"

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 21:18 --- I think this is a dup of bug 1373. You should try with optimizations turned on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24980

[Bug java/24980] New: GCJ/GIJ segfaults on Workout.java from Click and Hack's "Java Puzzlers"

GIJ segfaults on java-puzzlers/5-exceptional-puzzlers/puzzle-45/Workout.java from Bloch and Gafter's latest book. (This "puzzle" is due to Jim Hugunin of Jython and IronPython fame.) | $ curl -O http://www.javapuzzlers.com/java-puzzlers.zip | % Total% Received % Xferd Average Speed Time

[Bug awt/20630] GTK 2.8 peer Image and Graphics API reorganization

--- Comment #5 from mark at gcc dot gnu dot org 2005-11-21 21:11 --- As requested by Tom I add the following information from the following mailinglist thread: http://thread.gmane.org/gmane.comp.java.classpath.patches/5606 The application that uses this functionality is Caliph & Emir ht

[Bug c++/24979] New: DECL_MAIN_P is declared twice in cp-tree.h

I was too lazy to fix this so instead I was filing a bug. Anyways DECL_MAIN_P is declared twice in cp-tree.h with the same definition. I don't know or when it happend but it does. -- Summary: DECL_MAIN_P is declared twice in cp-tree.h Product: gcc Version: 4.1.

[Bug fortran/24978] ICE in gfc_assign_data_value_range

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 21:02 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCON

[Bug libfortran/24432] [4.1 regression] Missing symbols

--- Comment #19 from ebotcazou at gcc dot gnu dot org 2005-11-21 20:53 --- Subject: Bug 24432 Author: ebotcazou Date: Mon Nov 21 20:53:50 2005 New Revision: 107323 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107323 Log: PR libfortran/24432 * lib/target-suppor

[Bug other/24970] Error in header file: ctime:69: error: �::tm� has not been declared

--- Comment #6 from schnetter at aei dot mpg dot de 2005-11-21 20:53 --- Thanks for finding the reason. The include file was actually called "Time.h", but my file system is case insensitive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24970

[Bug libfortran/24432] [4.1 regression] Missing symbols

--- Comment #18 from ebotcazou at gcc dot gnu dot org 2005-11-21 20:52 --- Subject: Bug 24432 Author: ebotcazou Date: Mon Nov 21 20:52:25 2005 New Revision: 107321 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107321 Log: PR libfortran/24432 * lib/target-suppor

[Bug target/24959] Trampolines fail on i686-apple-darwin because stack is not executable

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfi

[Bug target/24959] Trampolines fail on i686-apple-darwin because stack is not executable

--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-21 20:43 --- I should note that in Apple's GCC for i686-darwin, they warn about this. I think they should look into fixing the issue here. Anyways confirmed. -- pinskia at gcc dot gnu dot org changed: What|R

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

--- Comment #3 from janis at gcc dot gnu dot org 2005-11-21 20:27 --- A regression hunt identified the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=106588 2005-11-07 Paolo Bonzini <[EMAIL PROTECTED]> PR target/24230 * config/rs6000/rs6000.c (easy_vector_

[Bug fortran/24705] ICE on assumed length character result

--- Comment #4 from pault at gcc dot gnu dot org 2005-11-21 20:03 --- Subject: Bug 24705 Author: pault Date: Mon Nov 21 20:02:54 2005 New Revision: 107320 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107320 Log: 2005-11-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/

[Bug fortran/24223] Gfortran crashes in two places

--- Comment #7 from pault at gcc dot gnu dot org 2005-11-21 20:03 --- Subject: Bug 24223 Author: pault Date: Mon Nov 21 20:02:54 2005 New Revision: 107320 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107320 Log: 2005-11-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/

[Bug regression/24978] New: ICE in gfc_assign_data_value_range

Following code is causing the internal compiler error. $ cat test.f90 real:: a(5,5) data a/25*1.0/ data a(1,1), a(3,1), a(1,2), a(3,3) /2*1.0, 2*2.0/ data a(2:5,4) /4*1.0/ end $ gfortran test.f90 t38.f90:0: internal compiler error: in gfc_assign_data

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

--- Comment #8 from pcarlini at suse dot de 2005-11-21 19:49 --- Another thing, about the basic_string warning: in order to figure out whether that cast is really creating problems, you can add --enable-fully-dynamic-string: with it the problematic code is not used at all. (as I already

[Bug target/24955] ICE: rs6000_output_function_epilogue, at config/rs6000/rs6000.c:15204

--- Comment #5 from aj at gcc dot gnu dot org 2005-11-21 19:47 --- Ok, understood -- aj at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED

[Bug target/24959] Trampolines fail on i686-apple-darwin

--- Comment #2 from gcc at microbizz dot nl 2005-11-21 19:28 --- Subject: Trampolines fail on i686-apple-darwin On closer inspection, the problem is that the stack is non-executable. Adding the following code (borrowed from gcc/config/netbsd.h) to darwin.h fixes the problem Adriaan

THE_HACKER_IS_HACKING 757147

I'm the bad boy on the block So forgive me

[Bug target/24955] ICE: rs6000_output_function_epilogue, at config/rs6000/rs6000.c:15204

--- Comment #4 from dje at gcc dot gnu dot org 2005-11-21 18:57 --- Treelang is a sample language. There is no language type defined for it in any ABI and no reason to create a type. This actually is a good test that the assert works for undefined languages. -- http://gcc.gnu.org/

[Bug target/24953] [4.1/4.2 Regression] RTL check: access of elt 1 of vector with last elt 0 in vrsave_operation_1, at config/rs6000/predicates.md:1041

--- Comment #5 from dje at gcc dot gnu dot org 2005-11-21 18:52 --- Fixed. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug preprocessor/24976] simple hexadecimal number parsed as C99 hex float

--- Comment #3 from bernie at develer dot com 2005-11-21 18:41 --- (In reply to comment #2) > 0xe+100 is a single preprocessing number. If the end of > is unclear, > please let us know how we could have improved it so that yo

[Bug target/14552] compiled trivial vector intrinsic code is inefficient

--- Comment #20 from pluto at agmk dot net 2005-11-21 18:38 --- (In reply to comment #19) > (In reply to comment #18) > > can we classify this as a code size regression? > > No because 3.3.x was also wrong in the sense it did not emit an emms. ok. gcc 4.1.0/20051113 with x87/mmx mode

[Bug preprocessor/24976] simple hexadecimal number parsed as C99 hex float

--- Comment #2 from joseph at codesourcery dot com 2005-11-21 18:21 --- Subject: Re: New: simple hexadecimal number parsed as C99 hex float On Mon, 21 Nov 2005, bernie at develer dot com wrote: > This testcase: > > int a = 0xe+100; 0xe+100 is a single preprocessing number. If t

[Bug c++/19092] g++ accepts code that violates 14.6.4.2

--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-21 18:20 --- *** Bug 24977 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c++/24977] Dependent lookup considers static functions

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 18:20 --- This is a dup of bug 19092. *** This bug has been marked as a duplicate of 19092 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c++/24977] New: Dependent lookup considers static functions

Sorry in advance if this is a dup. Dependent lookup considers static candidate functions, which seems to be in violation of 14.6.4.2. A dejagnu-style testcase: // { dg-do run } extern "C" void abort (void); void f(int) {} static void f(char) { abort(); } template void g(T t) { f(t); } int main()

[Bug fortran/15809] ICE Using Pointer Functions

--- Comment #16 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-11-21 18:08 --- Subject: Re: ICE Using Pointer Functions pgf90 compiles Paul Thomas' example, giving an empty string as output from the subroutine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1580

[Bug fortran/15809] ICE Using Pointer Functions

--- Comment #15 from sven dot buijssen at math dot uni-dortmund dot de 2005-11-21 18:06 --- I cannot tell why, but it seems to me that Paul Thomas' test case is no valid code: * Compaq Fortran Compiler X5.4A-1684-46B5P gives: f90: Warning: line 14: An explicit-shaped array is being pas

[Bug target/24953] RTL check: access of elt 1 of vector with last elt 0 in vrsave_operation_1, at config/rs6000/predicates.md:1041

--- Comment #4 from dje at gcc dot gnu dot org 2005-11-21 18:04 --- Subject: Bug 24953 Author: dje Date: Mon Nov 21 18:04:14 2005 New Revision: 107314 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107314 Log: PR target/24953 * config/rs6000/predicates.md (vrsave

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

--- Comment #7 from pcarlini at suse dot de 2005-11-21 17:55 --- Created an attachment (id=10314) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10314&action=view) Draft for the set/multiset issue Richard, can you see if the miscompilation goes away with the attached? In a sense is

[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719

--- Comment #16 from krebbel at gcc dot gnu dot org 2005-11-21 17:36 --- (In reply to comment #15) > (In reply to comment #14) > > The testcase to get that construct is: > Compiling with -mpowerpc64 to get the mixed mode. I would not doubt that the > arm failure is a similar issue but

[Bug preprocessor/24976] simple hexadecimal number parsed as C99 hex float

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 17:28 --- (In reply to comment #0) > but many users are going to think of this behavior as > a parser bug. This is more of a tokenizer error rather than a parser error. Anyways 2.95.3 gives: t.c:1: missing white space after

[Bug c/24976] New: simple hexadecimal number parsed as C99 hex float

This testcase: int a = 0xe+100; Produces a diagnostic message that would surprise most users: foo.c:1:9: error: invalid suffix "+100" on integer constant I'm not sure what the standard says about ambiguity between the hex float notation and the regular + operator, but many users are going t

[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

--- Comment #6 from bonzini at gcc dot gnu dot org 2005-11-21 17:05 --- Andreas, can you confirm it is fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24951

[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

--- Comment #5 from bonzini at gcc dot gnu dot org 2005-11-21 17:04 --- Subject: Bug 24951 Author: bonzini Date: Mon Nov 21 17:04:11 2005 New Revision: 107313 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107313 Log: 2005-11-21 Paolo Bonzini <[EMAIL PROTECTED]> PR ta

[Bug rtl-optimization/20583] [4.0 regression] ICE in output_operand: invalid expression as operand

--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-21 16:50 --- Fixed in 4.1.0 and above for now. -- pinskia 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

--- Comment #4 from bonzini at gcc dot gnu dot org 2005-11-21 16:38 --- Subject: Bug 24951 Author: bonzini Date: Mon Nov 21 16:38:13 2005 New Revision: 107312 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107312 Log: 2005-11-21 Paolo Bonzini <[EMAIL PROTECTED]> PR ta

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

--- Comment #6 from pcarlini at suse dot de 2005-11-21 16:28 --- Actually, to be 100% safe wrt binary compatibility (addresses, etc.) we can also overload for _Rb_tree::const_iterator the involved _Rb_tree functions, I'm preparing a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi

[Bug middle-end/24947] -Os should maximize inlining --param values.

--- Comment #9 from msharov at hotmail dot com 2005-11-21 16:25 --- (In reply to comment #8) > Depends on which C++ developers and if they have really thought about all > their > uses of inline (most have not even though they say they want functions > declared > as inline to be inlined

[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719

--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-21 16:22 --- (In reply to comment #14) > The testcase to get that construct is: Compiling with -mpowerpc64 to get the mixed mode. I would not doubt that the arm failure is a similar issue but not with complex types. -- ht

[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719

--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-21 16:19 --- (In reply to comment #13) > Ups. That's what I was trying to suggest - an unusual typo isn't it? ;-) > Thanks for taking care of this! Actually I was wrong in saying that only complex modes can show up here. It

[Bug target/24953] RTL check: access of elt 1 of vector with last elt 0 in vrsave_operation_1, at config/rs6000/predicates.md:1041

--- Comment #3 from dje at gcc dot gnu dot org 2005-11-21 16:12 --- Subject: Bug 24953 Author: dje Date: Mon Nov 21 16:12:32 2005 New Revision: 107311 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107311 Log: PR target/24953 * config/rs6000/predicates.md (vrsave

[Bug c++/20416] Incorrect lifetime for temporary with static const reference

--- Comment #2 from rsandifo at gcc dot gnu dot org 2005-11-21 16:09 --- BTW, this is 12.2/5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20416

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

--- Comment #5 from pcarlini at suse dot de 2005-11-21 16:09 --- One more bit of info (meant for Chris too): I think the cast has been added when set was changed to have both iterator and const_iterator as const iterator types. Since we are not exporting anything, I suppose we can fix th

[Bug c++/20416] Incorrect lifetime for temporary with static const reference

--- Comment #1 from rsandifo at gcc dot gnu dot org 2005-11-21 16:09 --- Confirmed. Here's a dejagnu-style testcase: // PR c++/20416. We correctly constructed the temporary S in foo(), // but incorrectly destroyed it every time foo() was called. // { dg-do run } extern "C" void abort

[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719

--- Comment #13 from krebbel at gcc dot gnu dot org 2005-11-21 16:07 --- > I don't have an Intel 64bit machine, but I can do a bootstrap on a x86_64 > machine with this patch. Ups. That's what I was trying to suggest - an unusual typo isn't it? ;-) Thanks for taking care of this! --

[Bug middle-end/24947] -Os should maximize inlining --param values.

--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-21 16:06 --- (In reply to comment #7) I'm pretty sure that if you run a poll of all the C++ > programmers, they'll tell you that they expect the former to always be inlined > in an optimized build, while the latter ought to depen

  1   2   >