[Bug regression/24565] New: facerec performance regression

There has been a performance drop of approx. 8% in facerec benchmark with at -O2 optimizatio level, since 2005-10-17 on ppc. After doing little regression hunt, found following patch causing the drop, http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00586.html As this patch has two parts, one fixes bug #

[Bug bootstrap/24562] makebootstrap failed: make[3]: *** No rule to make target `../zlib/libz.a'

--- Comment #7 from ebotcazou at gcc dot gnu dot org 2005-10-28 06:24 --- > Following your way, I download zlib at http://www.zlib.net, gunzip and untar > it at GCC'src directory. Don't do that, everything should be included in the GCC archive. What GCC archive do you use and where do

[Bug fortran/24554] internal compiler error

--- Comment #4 from mabdallah at unido-ichet dot org 2005-10-28 06:09 --- (In reply to comment #3) > Because if you look in that BUGs audit-trail we have > > The error message is > > city3s.f:0: internal compiler error: in gfc_assign_data_value, at > fortran/data.c:319 > > given t

[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement

--- Comment #6 from uros at kss-loka dot si 2005-10-28 06:05 --- (In reply to comment #5) > The realy problem here is that the xor is produced after reload and is really > only done on some x86 targets. > This happens in following peephole2 pattern: ;; Don't move an immediate directly

[Bug ada/24564] Bug box in Ada compiler: in create_tmp_var, at gimplify.c:368

--- Comment #2 from sgmcmillan at gmail dot com 2005-10-28 05:59 --- Created an attachment (id=10072) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10072&action=view) Ada body for the test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24564

[Bug ada/24564] Bug box in Ada compiler: in create_tmp_var, at gimplify.c:368

--- Comment #1 from sgmcmillan at gmail dot com 2005-10-28 05:58 --- Created an attachment (id=10071) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10071&action=view) Ada spec for the test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24564

[Bug ada/24564] New: Bug box in Ada compiler: in create_tmp_var, at gimplify.c:368

The following bug box is generated with the attched test case: +===GNAT BUG DETECTED==+ | 4.0.1 (i686-pc-linux-gnu) in create_tmp_var, at gimplify.c:368 | | Error detected at message_pool.adb:62:5 | | Pl

[Bug c/24563] New: getting internal error

NM_FOR_TARGET="nm" AWK="gawk" \ LIBGCC2_CFLAGS="-O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes\ INCLUDES="-I. -I. -I../../gcc-3.2.2/gcc -I../../gcc-3.2.2/gcc/. -I../../gcc-3\ CONFIG_H="config.h auto-host.h ../../gcc-3.2.2/gcc/../include/ansidecl.h ../.\ LIB1ASMSRC='' \ MAKEOVE

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

--- Comment #2 from woodzltc at sources dot redhat dot com 2005-10-28 04:51 --- Yes. Some of these problems stems from gdb, like 24527; others from gfortran, like 22244, and yet others involve both. I could spare some time to work on fortran support in gdb. And very willing to work w

[Bug fortran/17905] allocated arrays not visible with gdb

--- Comment #5 from woodzltc at sources dot redhat dot com 2005-10-28 04:42 --- "set lang c" didn't give me that output. What is your configuration, gdb , gfortran version and so on? My gdb session is like this: (gdb) whatis array type = Invalid type code (3) in symbol table. (gdb)

[Bug fortran/24527] derived types not displayed correctly with gdb

--- Comment #2 from woodzltc at sources dot redhat dot com 2005-10-28 04:39 --- Yes. I agree that it is more like a gdb bug. But I would rather say that it is an enhancement request for gdb, because GDB never says that it supports complete Fortran-95 syntax. The support for Fortrn 77

[Bug bootstrap/24562] makebootstrap failed: make[3]: *** No rule to make target `../zlib/libz.a'

--- Comment #6 from luongductruong at gmail dot com 2005-10-28 04:33 --- (In reply to comment #5) > What tar file did you download? > > You should have a zlib directory in the src directory. > Following your way, I download zlib at http://www.zlib.net, gunzip and untar it at GCC'src d

[Bug c++/23426] [4.0/4.1 Regression] Too large array problem gives two error message

--- Comment #15 from pinskia at gcc dot gnu dot org 2005-10-28 04:18 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01599.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/23426] [4.0/4.1 Regression] Too large array problem gives two error message

--- Comment #14 from pinskia at gcc dot gnu dot org 2005-10-28 03:57 --- Actually I figured out how to fix the problem with my patch, just moving around error mark node is what is needed here. -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug middle-end/23155] [4.0/4.1 Regression] Gimplification failed for union cast

--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-28 03:36 --- Patch posted: . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug bootstrap/24562] makebootstrap failed: make[3]: *** No rule to make target `../zlib/libz.a'

--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-28 02:45 --- What tar file did you download? You should have a zlib directory in the src directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24562

[Bug bootstrap/24562] makebootstrap failed: make[3]: *** No rule to make target `../zlib/libz.a'

--- Comment #4 from luongductruong at gmail dot com 2005-10-28 02:39 --- (In reply to comment #2) > Second can you show how you build gcc? > And attached the full build log. > Following the instruction at gcc.gnu.org/install/configure.html I attached the full build log. The error occu

[Bug testsuite/23720] FAIL: gcc.dg/debug/dwarf2/dwarf-char[123].c scan-assembler 0x[68][ \t]# DW_AT_encoding

--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-28 02:34 --- Fixed so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Statu

[Bug bootstrap/24562] makebootstrap failed: make[3]: *** No rule to make target `../zlib/libz.a'

--- Comment #3 from luongductruong at gmail dot com 2005-10-28 02:32 --- Created an attachment (id=10070) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10070&action=view) GCC 4.0.2 Full Log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24562

[Bug c++/24561] no static definition

--- Comment #7 from mark at codesourcery dot com 2005-10-28 02:16 --- Subject: Re: no static definition pinskia at gcc dot gnu dot org wrote: > Not really as unit at a time is considered an optimization and the C++ > front-end just turns it on always. I don't think that's accurate.

[Bug testsuite/23720] FAIL: gcc.dg/debug/dwarf2/dwarf-char[123].c scan-assembler 0x[68][ \t]# DW_AT_encoding

--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2005-10-28 02:01 --- Subject: Re: FAIL: gcc.dg/debug/dwarf2/dwarf-char[123].c scan-assembler 0x[68][ \t]# DW_AT_encoding > Does this work now, I think it does? Right, I'm not seeing it anymore. Dave -- http://gcc.gnu.or

[Bug testsuite/23720] FAIL: gcc.dg/debug/dwarf2/dwarf-char[123].c scan-assembler 0x[68][ \t]# DW_AT_encoding

--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-28 01:52 --- Does this work now, I think it does? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23720

[Bug bootstrap/24562] makebootstrap failed: make[3]: *** No rule to make target `../zlib/libz.a'

--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-28 01:42 --- Second can you show how you build gcc? And attached the full build log. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug middle-end/24556] gcc can't inline functions using setjmp

--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-28 01:39 --- So this is not a bug. Closing as won't fix. You found the issue and the docs for setjmp are really clear. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug bootstrap/24562] makebootstrap failed: make[3]: *** No rule to make target `../zlib/libz.a'

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 01:37 --- First try to configure with an absolute path. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c++/24561] no static definition

--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-28 01:34 --- (In reply to comment #5) > I understand it's a change. That's different from saying it's a regression. It was an unexpected change really at least as far as I can tell > Then, this bug should be changed to be a mid

[Bug fastjar/24562] New: makebootstrap failed: make[3]: *** No rule to make target `../zlib/libz.a'

When make bootstrap gcc4.0.2, I receive error: make[3]: *** No rule to make target `../zlib/libz.a', needed by `fastjar'. Stop. What's error? How I do to fix? Thank you. This is my configure command: CXXFLAGS='-Xassembler gstabs' ../src/gcc-4.0.2/configure --prefix=/usr/local/binut/ --with-as

[Bug c++/24561] no static definition

--- Comment #5 from mark at codesourcery dot com 2005-10-28 00:50 --- Subject: Re: no static definition pinskia at gcc dot gnu dot org wrote: > --- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-28 00:24 > --- > (In reply to comment #3) > >>I wouldn't call this a reg

[Bug regression/24556] gcc can't inline functions using setjmp

--- Comment #6 from samuel dot thibault at ens-lyon dot org 2005-10-28 00:47 --- Subject: Re: gcc can't inline functions using setjmp pinskia at gcc dot gnu dot org, le Fri 28 Oct 2005 00:37:47 -, a écrit : > Let me look into why setjmp was caused not to inline, there was a reason

[Bug regression/24556] gcc can't inline functions using setjmp

--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-28 00:37 --- (In reply to comment #4) That is not really GCC's fault. Let me look into why setjmp was caused not to inline, there was a reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24556

[Bug c++/24561] no static definition

--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-28 00:24 --- (In reply to comment #3) > I wouldn't call this a regression; I don't think there's any guarantee that > unused statics stay around, even with -O0. It is a regression as turning on unit-at-a-time at -O0 changed it

[Bug regression/24556] gcc can't inline functions using setjmp

--- Comment #4 from samuel dot thibault at ens-lyon dot org 2005-10-28 00:21 --- Well, there is indeed an issue: the address of some local variables might be passed to other functions and then be modified in an external way between setjmp() and longjmp(), and if some local variables are

[Bug c++/24561] no static definition

--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-28 00:11 --- I wouldn't call this a regression; I don't think there's any guarantee that unused statics stay around, even with -O0. However, I tend to agree that it would be better if they did stay around at -O0. In other w

[Bug c++/24561] no static definition

--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-27 23:58 --- I don't know if this is really can be considered a bug as the static defintions are unused. If you want to keep them, you have to use the attribute used. But I will let someone else (Mark?) to decide. -- pinski

[Bug c++/24561] no static definition

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 23:56 --- This is because unit at a time is turned on by default. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/24561] New: no static definition

4.0.x and mainline have regressed WRT 3.4.x // Ensure freelist is constructed first. static int freelist_mutex = 1; static void _M_destroy_thread_key(void* __id) { int i = 0; } void _M_destroy_thread(void* __id) { int i = 0; } gives: %gcc -x c -g -O0 -c testme.cc %nm testm

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

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 23:32 --- >From the looks of it, some of these are really gdb issues as they work when you do: set lang c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546

[Bug fortran/17905] allocated arrays not visible with gdb

--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-27 23:27 --- This is more of a gdb bug as if I do: set lang c it prints out the array as a descriptor: $2 = {data = 0x9a7f2d8, offset = -1, dtype = 265, dim = {{stride = 1, lbound = 1, ubound = 10}}} -- http://gcc.gnu.org/bu

[Bug fortran/24527] derived types not displayed correctly with gdb

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 23:24 --- Confirmed. This is a gdb bug as if I do: "set lang c" it works. Oh, I think there is a dup around somewhere too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Adde

[Bug fortran/24526] variables from modules not visible in gdb

--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-27 23:15 --- (In reply to comment #1) > To let gdb recognize 'a' directly, some trick in gdb might be needed. I don't know if some trickery is needed, just we might need to emit something like what C++ does with it using stateme

[Bug fortran/24549] gfortran: IMPORT of f2003 not yet implemented, ICE

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 23:13 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCON

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

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

[Bug fortran/24558] ENTRY doesn't work in module procedures

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 23:12 --- For the second one, I get an ICE: t.f90:10: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:355 But confirmed otherwise. -- pinskia at gcc dot gnu dot org changed: What|Rem

[Bug fortran/24557] ICE: PRINTing function result of size depending on assumed length CHARACTER dummy

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 22:00 --- Confirmed, backtace: #0 0x080ffa9b in convert_nonlocal_reference (tp=0xb7c6cabc, walk_subtrees=0xbfe14468, data=0xbfe14538) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/tree-nested.c:829 #1 0x0836eea5 in walk_

[Bug libstdc++/24537] Non-uglified names inside namespace __gnu_cxx

--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-27 21:55 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCON

[Bug tree-optimization/24172] [4.1 Regression] error: incorrect sharing of tree nodes

--- Comment #13 from hubicka at gcc dot gnu dot org 2005-10-27 21:18 --- This is patch I am testing to prevent the sharing. I think it is good idea in addition to Richard's patch to make fold do it's job too: void IOException( char); inline int* dummy( const char* const mode ) { IOE

[Bug c/23155] [4.0/4.1 Regression] Gimplification failed for union cast

--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-27 21:15 --- This is a combination of a GCC extension (of cast to union) and a C99 feature (subscripting a non-lvalue array) so this is valid code (but undefined code) even though it looks so weird. Anyways I have a patch which

[Bug c++/19989] [4.0/4.1 regression] Inconsistency with zero-sized arrays

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19989

[Bug c++/20681] [4.0/4.1 Regression] wrong "control reaches" warning with switches

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681

[Bug c++/17964] [4.0/4.1 Regression] cpp error messages contain wrong line in C++

--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-27 20:34 --- (In reply to comment #5) > It gets worse if the unknown escape is at the beginning of the file and then > you have about 100 more lines. Or even in a different file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?

[Bug middle-end/22156] [4.0/4.1 Regression] bit-field copying regressed

--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-27 20:31 --- Nothing can happen until 4.2.0 for this issue really as we need a real copy prop for structs. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c/23155] [4.0/4.1 Regression] Gimplification failed for union cast

--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-27 20:01 --- I might look into this soon. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/24560] "insufficient contextual information to determine type" is not a helpful error message

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 19:55 --- 2.95.3 to 3.2.3 gave: t.cc: In function `void g()': t.cc:3: request for member `a' in `{}.A::f', which is of non-aggregate type `' Which is close to what you were expecting so this is a regression. Confirmed.

[Bug c++/24560] New: "insufficient contextual information to determine type" is not a helpful error message

Testcase: struct A { void f(); }; void g() { A().f.a; } GCC 3.4 and 4.0 display the following error message: a.cpp:2: error: insufficient contextual information to determine type This message is surprising, because, whatever the context, a compiler will never be able to do anything useful w

[Bug middle-end/24362] [4.0/4.1 Regression] internal compiler error: in extract_component, at tree-complex.c:68

--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-27 19:49 --- Will commit once SVN is alive: . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug libstdc++/24559] Incorrect definition of wcspbrk in cwchar

--- Comment #2 from pcarlini at suse dot de 2005-10-27 19:42 --- Thanks, likely will be the first svn library commit ;) -- pcarlini at suse dot de changed: What|Removed |Added

[Bug preprocessor/22042] [3.4/4.0/4.1 Regression] stringification BUG

--- Comment #13 from pinskia at gcc dot gnu dot org 2005-10-27 19:36 --- Patch submitted: . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c++/23229] [4.0/4.1 Regression] g++ gives incorrect error message with void main() and a void function

--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-27 19:21 --- Patch posted: . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/23488] [4.1 Regression] GCSE load PRE does not work with non sets

--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-27 18:30 --- Changing the summary to give a better idea what is going on here. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug libstdc++/24559] Incorrect definition of wcspbrk in cwchar

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 18:16 --- Confirmed, the issue is in libstdc++. inline wchar_t* wcspbrk(wchar_t* __s1, wchar_t* __s2) { return wcspbrk(const_cast(__s1), __s2); } -- pinskia at gcc dot gnu dot org changed: What|Remov

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

--- Comment #12 from dann at godzilla dot ics dot uci dot edu 2005-10-27 18:08 --- (In reply to comment #9) > And CSiBE tells you the story that GCC 4.1 produces smaller code overall. > http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-os&basephp=s-i686-linux Well, it obviously d

[Bug c++/24559] New: Incorrect definition of wcspbrk in cwchar

According to the C++ standard the declarations of wcspbrk should take two cont pointers or a (non-const pointer and a const pointer (in that order): The actual declarations as if gcc 4.0 and apparently since introduction of the second declaration take either two const pointers or two non-const poi

[Bug bootstrap/23776] configure: error: no acceptable cc found in $PATH

--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-27 18:01 --- You install a compiler via the installer you installed the OS from (since this is GNU/Linux). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug target/16589] [4.0/4.1 regression] [m68k] segmentation fault on identical array accesses in the ?: operators' body

--- Comment #13 from pinskia at gcc dot gnu dot org 2005-10-27 17:59 --- This is still a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/23368] internal compiler error with NAG routines

--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-27 17:57 --- Closing as fixed for 4.0.2. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfir

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

--- Comment #11 from steven at gcc dot gnu dot org 2005-10-27 17:34 --- And FWIW there is also a problem with this insn, the length is wrong: #(insn 11 46 47 0x2a955cc840 (set (reg:SI 0 eax [orig:61 x ] [61]) #(mem/f:SI (symbol_ref:SI ("x")) [5 x+0 S4 A32])) 44 {*movsi_1} (nil)

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

--- Comment #10 from steven at gcc dot gnu dot org 2005-10-27 17:31 --- For the record, we're talking about: 1.file "t.c" 2.text 3.p2align 4,,15 4.globl foo 5

[Bug libfortran/24541] libgfortran.so in 4.1 is incompatible with 4.0

--- Comment #7 from tobi at gcc dot gnu dot org 2005-10-27 17:21 --- We should bump the library file's version number. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24541

[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement

--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-27 17:21 --- The realy problem here is that the xor is produced after reload and is really only done on some x86 targets. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

--- Comment #9 from steven at gcc dot gnu dot org 2005-10-27 17:08 --- And CSiBE tells you the story that GCC 4.1 produces smaller code overall. http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-os&basephp=s-i686-linux So do the SPEC benchmark boxes btw. -- http://gcc.gnu.org

[Bug c++/23480] default-initializing variable size array new expression for basic types does not work

--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-27 16:56 --- Fixed for 4.0.3 and above. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/21833] simd tests fail in 3.4.4, but not in 3.3.6 or 4.0.1

--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-27 16:48 --- Closing as fixed in 4.0.1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug rtl-optimization/15265] delete_output_reload deletes necessary insn

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

[Bug fortran/18197] bus error on returning from a function

--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-27 16:46 --- We get an ICE now: t.f90:26: internal compiler error: in gfc_trans_arrayfunc_assign, at fortran/trans-expr.c:2632 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/23246] Error using function returning array as subroutine argument

--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-27 16:45 --- This works now but I don't know if this is really fixed as the now libgfortran just calls into malloc/free without wrapping it so we get errors like this. Newer glibc should error out but I don't have it because I a

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2005-10-27 16:43 --- (In reply to comment #7) > Could the dear reported at least try to provide a small test case? The testcase in the attachment contains only a 4 lines function: HandleDeIconify, the rest is just fluff to a

[Bug middle-end/21939] [3.4 Regression] corrupted memory with deque of >63 items

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21939

[Bug rtl-optimization/21804] [3.4 only] gcc generates incorrect code on x86_64 with -O2

--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-27 16:40 --- Closing as fixed for 4.0.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/18182] Incorrect processing of __attribute__ by the C++ parser

--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-27 16:30 --- I think this has been fixed as I get an error on i686-pc-linux-gnu with your non-Pmode pointers expample. This was on the mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18182

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

--- Comment #7 from steven at gcc dot gnu dot org 2005-10-27 16:26 --- Could the dear reported at least try to provide a small test case? I think this should not be marked as a regression. It's just sad that this kind of non-bug keeps the regression count high, when in reality GCC 4.1

[Bug c++/24312] C++ front-end doesn't correctly handle distinction between global initializers and ctors

--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-27 16:22 --- Hmm, ICC gets it wrong too, maybe there is a misunderstanding somewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24312

[Bug target/22432] [4.0/4.1 Regression] Wrong code generation using MMX intrinsics on amd64

--- Comment #4 from pluto at agmk dot net 2005-10-27 16:00 --- With my patched gcc-4.1.0-20051019 the testcase works. Applied patches: PR7776, PR20297, PR22429, PR22533, PR23948, PR19505, PR20606, PR24069, PR24419, PR24172, PR24295, PR20928 [EMAIL PROTECTED] BUILD]$ gcc -Wall -O2 pr2243

[Bug c/24371] -fno-unit-at-a-time ignored in IMA mode

--- Comment #2 from rguenth at gcc dot gnu dot org 2005-10-27 15:48 --- Confirmed as a diagnostics issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug other/4372] #pragma weak pthread* inclusion causes applications to crash without a linker error when one forgets to link with -lpthread

-- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org

[Bug target/22432] [4.0/4.1 Regression] Wrong code generation using MMX intrinsics on amd64

--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-27 14:44 --- A regression from 3.4.x and 3.3.x. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug preprocessor/22042] [3.4/4.0/4.1 Regression] stringification BUG

--- Comment #12 from pinskia at gcc dot gnu dot org 2005-10-27 14:33 --- I will relook at this and post it soon. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug regression/24556] gcc can't inline functions using setjmp

--- Comment #3 from rguenth at gcc dot gnu dot org 2005-10-27 14:11 --- I believe it should be safe to inline, as inlining can only make a previously invalid use of sjlj valid, but not the other way around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24556

[Bug c++/23229] [4.0/4.1 Regression] g++ gives incorrect error message with void main() and a void function

--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-27 14:11 --- I have a simple fix for this, we just need to copy the type as it looks as it is shared now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/23426] [4.0/4.1 Regression] Too large array problem gives two error message

--- Comment #13 from pinskia at gcc dot gnu dot org 2005-10-27 14:01 --- (In reply to comment #12) > I might have a fix for the two error messages, though it might also cause > other > issues, let see what happens in the test results. It did not work. -- http://gcc.gnu.org/bugzil

[Bug libgcj/24552] Encoding alias "EUC_JP" missing

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 13:59 --- Related to PR14358 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24552

[Bug regression/24556] gcc can't inline functions using setjmp

--- Comment #2 from samuel dot thibault at ens-lyon dot org 2005-10-27 13:45 --- Subject: Re: gcc can't inline functions using setjmp pinskia at gcc dot gnu dot org, le Thu 27 Oct 2005 13:37:32 -, a écrit : > This is not a bug as if you inline it, the place setjmp goes to could b

[Bug regression/24556] gcc can't inline functions using setjmp

--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 13:37 --- This is not a bug as if you inline it, the place setjmp goes to could be not where you want to goto. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/24558] New: ENTRY doesn't work in module procedures

With explicitely declared types for a function and it's entry points, I get a 'Duplicate key found!' error: kl-nrb:~$ cat test_entry_2.f90 module foo contains function n1() integer :: n1, n2 n1 = 1 return entry n2() n2 = 2 return end function n1

[Bug fortran/24554] internal compiler error

--- Comment #3 from rguenth at gcc dot gnu dot org 2005-10-27 12:33 --- Because if you look in that BUGs audit-trail we have The error message is city3s.f:0: internal compiler error: in gfc_assign_data_value, at fortran/data.c:319 given the detailled information in this (24554) bug

[Bug fortran/24554] internal compiler error

--- Comment #2 from steven at gcc dot gnu dot org 2005-10-27 11:26 --- Huh, how can this ICE be a duplicate of an accepts-invalid bug?? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24554

[Bug target/24547] Branch cost of -Os is ignored

--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-27 11:26 --- Confirmed, in principle. Though, in this light, one needs to re-evaluate if the branch cost of 1 is good for optimize_size. Same for x86_64, btw., which should really get different size-cost table for 64bit. --

[Bug fortran/17737] ICE when variable appears in two data statements

--- Comment #10 from rguenth at gcc dot gnu dot org 2005-10-27 11:18 --- *** Bug 24554 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug fortran/24554] internal compiler error

--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-27 11:18 --- *** This bug has been marked as a duplicate of 17737 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/24557] New: ICE: PRINTing function result of size depending on assumed length CHARACTER dummy

kl-nrb:~$ cat buggy.f90 program main implicit none character(4) :: a(2) print *,fun(a) contains function fun(arg) character(len=*), intent(in) :: arg(:) integer :: fun(size(arg)) fun = 5 end function fun end pkl-nrb:~$ gfortran41 buggy.f90 buggy.f90:4: internal compiler erro

  1   2   >