[Bug target/47855] missed cbnz optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47855 --- Comment #1 from Carrot 2011-02-25 07:18:07 UTC --- I printed out the address of each instruction from function arm_reorg() id=173 addr=0 id=2 addr=4 id=3 addr=8 id=15 addr=12 id=18 addr=16 id=199 addr=24 id=21 addr=26 id=23 addr=30 id=26 add

[Bug c++/47874] Multiple Inheritance - Virtual Function - Segfault

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47874 --- Comment #2 from Ibaidul Sahib 2011-02-25 05:29:27 UTC --- (In reply to comment #1) > is this a duplicate of Bug 47873? > > the attachments are slightly different, but presumably it's the same problem I presume that the problem is related. I

[Bug lto/47891] GCC 4.6 LTO not worked reliable on Windows target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47891 Dmitry Gorbachev changed: What|Removed |Added CC||d.g.gorbachev at gmail dot

[Bug lto/47891] GCC 4.6 LTO not worked reliable on Windows target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47891 --- Comment #2 from Dongsheng Song 2011-02-25 03:06:01 UTC --- This issues only in 32bit, 64bit is fine: $ i686-w64-mingw32-gcc -m64 -g -flto -o hello.c.64bit.lto.exe Hello.c $ i686-w64-mingw32-objdump -d hello.c.64bit.lto.exe 004029c0

[Bug lto/47891] GCC 4.6 LTO not worked reliable on Windows target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47891 --- Comment #1 from Dongsheng Song 2011-02-25 03:01:38 UTC --- Sorry, there is a typo: With LTO, it's OK: should be: Without LTO, it's OK:

[Bug lto/47891] New: GCC 4.6 LTO not worked reliable on Windows target

lto --enable-cloog-backend=ppl-legacy Thread model: win32 gcc version 4.6.0 20110224 (experimental) (GCC) With LTO, the generated exe file have invalid address reference to _puts: $ i686-w64-mingw32-gcc -g -flto -o hello.c.lto.exe Hello.c $ i686-w64-mingw32-objdump -d hello.c.lto.exe 00402430 <

[Bug tree-optimization/47890] [4.5/4.6 Regression] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1186

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47890 --- Comment #1 from Dmitry Gorbachev 2011-02-25 01:42:56 UTC --- Created attachment 23463 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23463 Backtrace from GCC 4.5 4.5.3 also fails with `internal compiler error: in get_initial_def_for_ind

[Bug tree-optimization/47890] New: [4.5/4.6 Regression] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1186

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47890 Summary: [4.5/4.6 Regression] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1186 Product: gcc Version: 4.6.0 Status: UNCONFIRMED

[Bug rtl-optimization/47862] Incorrect code for spilling a vector register

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47862 --- Comment #2 from Pat Haugen 2011-02-25 00:55:20 UTC --- The DI mode for the spill locations is being decided in caller-save.c:init_caller_save(), which appears to decide what mode should be used when a caller-saved reg needs to be saved/restor

[Bug target/46655] invalid '.line 0' directive emitted with -g

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #23 from Richard Nolde 2011-02-25 00:20:54 UTC --- On 02/24/2011 01:42 PM, michael.haubenwallner at salomon dot at wrote: Progress report on building Gcc 4.5.0 on AIX 6.0: Using your suggestion for gmake bootstrap STAGE1_FLAGS=-0 ge

[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769 --- Comment #33 from Mikael Morin 2011-02-24 23:57:24 UTC --- One should also look at related bugs PR45836 and pr45900.

[Bug lto/47889] New: Segmentation fault in lto1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47889 Summary: Segmentation fault in lto1 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org

[Bug lto/47888] New: tree check: expected array_type, have record_type in array_ref_low_bound, at expr.c:6248

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47888 Summary: tree check: expected array_type, have record_type in array_ref_low_bound, at expr.c:6248 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal

[Bug target/46655] invalid '.line 0' directive emitted with -g

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #22 from Richard Nolde 2011-02-24 22:27:13 UTC --- On 02/24/2011 01:42 PM, michael.haubenwallner at salomon dot at wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 > > --- Comment #20 from Michael Haubenwallner dot at> 2011

[Bug fortran/47886] ICE: OpenMP !$omp task if(omp_get_num_threads() > 0)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47886 Tobias Burnus changed: What|Removed |Added Keywords||openmp CC|

[Bug middle-end/47887] [4.6 Regression] FAIL: 187.facerec in SPEC CPU 2000 at -O3

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47887 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 Andrew Pinski changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2

[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769 --- Comment #32 from Mikael Morin 2011-02-24 22:04:52 UTC --- Created attachment 23460 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23460 hack implementing comment 31

[Bug middle-end/47887] New: [4.6 Regression] FAIL: 187.facerec in SPEC CPU 2000 at -O3

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47887 Summary: [4.6 Regression] FAIL: 187.facerec in SPEC CPU 2000 at -O3 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Componen

[Bug libfortran/47872] Alternative syntax for intrinsics should be documented on separate line

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47872 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug libfortran/47872] Alternative syntax for intrinsics should be documented on separate line

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47872 --- Comment #1 from Tobias Burnus 2011-02-24 21:58:49 UTC --- Author: burnus Date: Thu Feb 24 21:58:47 2011 New Revision: 170480 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170480 Log: 2011-02-24 Tobias Burnus PR fortran/47

[Bug rtl-optimization/47862] Incorrect code for spilling a vector register

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47862 --- Comment #1 from Pat Haugen 2011-02-24 21:54:00 UTC --- Looks like the bogus spill/restore insns are being inserted via caller-save.c routines since IRA assigned volatile regs to pseudos which are live across a call. 190.sched1 dump for the

[Bug fortran/47886] New: ICE: OpenMP !$omp task if(omp_get_num_threads() > 0)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47886 Summary: ICE: OpenMP !$omp task if(omp_get_num_threads() > 0) Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assigne

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #24 from Janne Blomqvist 2011-02-24 21:51:41 UTC --- Author: jb Date: Thu Feb 24 21:51:39 2011 New Revision: 170478 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170478 Log: PR 47802 Use strftime for CTIME and FDATE intrinsic

[Bug libgcj/47885] "find: unrecognized: -follow"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47885 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug libgcj/47885] New: "find: unrecognized: -follow"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47885 Summary: "find: unrecognized: -follow" Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.

[Bug target/46655] invalid '.line 0' directive emitted with -g

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #21 from Richard Nolde 2011-02-24 20:53:42 UTC --- On 02/24/2011 01:42 PM, michael.haubenwallner at salomon dot at wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 > > --- Comment #20 from Michael Haubenwallner dot at> 2011

[Bug target/46655] invalid '.line 0' directive emitted with -g

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #20 from Michael Haubenwallner 2011-02-24 20:42:46 UTC --- (In reply to comment #19) > > /usr/bin/gcc -c -g -fkeep-inline-functions -DIN_GCC ... > > This is a problem in /usr/bin/gcc, not in the GCC sources you're compiling. (In rep

[Bug other/47884] gcc: Internal error: Segmentation fault (program as)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47884 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #24 from Jakub Jelinek 2011-02-24 20:17:05 UTC --- Richard, can you check if this fixes 187.facerec?

[Bug other/47884] New: gcc: Internal error: Segmentation fault (program as)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47884 Summary: gcc: Internal error: Segmentation fault (program as) Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedT

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #23 from Jakub Jelinek 2011-02-24 20:14:00 UTC --- Author: jakub Date: Thu Feb 24 20:13:57 2011 New Revision: 170476 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170476 Log: PR fortran/47878 * io/transfer.c (read_sf)

[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836 --- Comment #6 from th.r.klein at web dot de 2011-02-24 19:42:39 UTC --- Since I did not need to have libc I also did not need to have libstdc++-v3, too. Also I did not need to have libgomp, libmudflap, libffi, libssp, libquadmath, boehm-gc .. But

[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #7 from Benjamin Kosnik 2011-02-24 19:28:02 UTC --- ack, I mis-read rtti.c, these are the decimal exports, ie decimal128 not float128. Jakub you are correct these are exports as LD symbols via ld versioning via inclusion. I missed

[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 f

[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #5 from Benjamin Kosnik 2011-02-24 19:09:33 UTC --- RE comment 2. Yes, agreed full support is a ways off. However, typeinfo support is ostensibly already there, just not emitted. This is a bug, and not something users can work arou

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47606 --- Comment #6 from Aldy Hernandez 2011-02-24 19:08:36 UTC --- Created attachment 23459 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23459 Additional ICE on incorrect code At -O0 we get a correct diagnosis for this incorrect snippet: b.c

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47606 Aldy Hernandez changed: What|Removed |Added Attachment #23243|0 |1 is obsolete|

[Bug libstdc++/46922] Missing exported symbols from libstdc++

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46922 Benjamin Kosnik changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #4 from Benjamin Kosnik 2011-02-24 18:54:06 UTC --- Created attachment 23457 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23457 typeinfo exports for float128

[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #3 from Benjamin Kosnik 2011-02-24 18:53:08 UTC --- Expecting this as exported as fundamental_type_info, see in emit_support_tinfos via rtti.c:1461: static tree *const fundamentals[] = { &void_type_node, &boolean_type_no

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #22 from Jerry DeLisle 2011-02-24 18:30:38 UTC --- Just to be clear; Created attachment 23456 [details] gcc46-pr47878.patch is approved. It has to be right, look at that attachment number! ;)

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #21 from Jerry DeLisle 2011-02-24 18:27:42 UTC --- This is OK and do add the close with status = "delete"

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #20 from Tobias Burnus 2011-02-24 17:41:20 UTC --- Comment on attachment 23456 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23456 gcc46-pr47878.patch >+ read (99, '(5i3)') a >+ if (any (a.ne.(/1, 2, 3, 0, 0/))) call abort >

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #18 from Jerry DeLisle 2011-02-24 17:10:50 UTC --- The old code did this: fbuf_seek (dtp->u.p.current_unit, n + seen_comma, SEEK_CUR); So we could adjust for comma as well.

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #17 from Jerry DeLisle 2011-02-24 17:07:06 UTC --- C14, my browser here is not displaying the comment numbers, odd. You will see where we set the eor number to 1 or 2 depending on what was found. That can be used to adjust n if neede

[Bug fortran/42041] Missing defs in omp_lib.h

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42041 --- Comment #6 from Jakub Jelinek 2011-02-24 16:22:28 UTC --- Author: jakub Date: Thu Feb 24 16:22:24 2011 New Revision: 170475 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170475 Log: * omp.h.in (omp_in_final): New prototype. *

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #16 from Jakub Jelinek 2011-02-24 16:20:27 UTC --- Do you prefer the patch in #c13, or what I wrote in #c14? I'd prefer not to test both. As for pointer comparisons, you can't compare the old pointer with the new one, that triggers u

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #15 from Jerry DeLisle 2011-02-24 16:03:41 UTC --- Jakub's suggestion is probably OK. I am not at a place where I can do and test. My only concern, is there a chance that we would backup passed the beginning of the buffer? Maybe mak

[Bug c/47882] Incorrect "array subscript is above array bounds" warning

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47882 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #2 from joseph at codesourcery dot com 2011-02-24 15:23:33 UTC --- This seems related to bug 40855. See also and the rest of that thread. libstdc++ support for extended inte

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #14

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #22 from Janne Blomqvist 2011-02-24 15:08:00 UTC --- (In reply to comment #21) > (In reply to comment #20) > > + if (q == EOF) > > > > Does this always work? We have in "static inline int fbuf_getc (gfc_unit * > > u)": > >

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #13 from Jakub Jelinek 2011-02-24 15:05:39 UTC --- Created attachment 23455 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23455 gcc46-pr47878.patch So how about this patch? Fixes the valgrind reported issues on Tobi's testcase

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #21 from Janne Blomqvist 2011-02-24 15:04:42 UTC --- (In reply to comment #20) > Some random thoughts looking at the patch > (http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170432) - probably not > helping at all with the regression

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #23 from dave at hiauly1 dot hia.nrc.ca 2011-02-24 14:55:52 UTC --- On Thu, 24 Feb 2011, jb at gcc dot gnu.org wrote: > > libgfortran.sl is built twice on HP-UX 10, once for the single thread > > model and once for the dce thread model

[Bug libfortran/47883] New: libgfortran configuration should use AC_LINK_IFELSE instead of AC_TRY_LINK

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47883 Summary: libgfortran configuration should use AC_LINK_IFELSE instead of AC_TRY_LINK Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #22 from Janne Blomqvist 2011-02-24 14:51:21 UTC --- Author: jb Date: Thu Feb 24 14:51:17 2011 New Revision: 170471 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170471 Log: PR 47802 Test for POSIX getpwuid_r Modified: t

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #12 from Tobias Burnus 2011-02-24 14:35:54 UTC --- (In reply to comment #11) > Test case for the actual issue: > > The crucial part seems to be to have (a) RECL= and (b) a line which is longer > than 80 characters. ... and reading mo

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #11 from Tobias Burnus 2011-02-24 14:34:09 UTC --- Failing test case - though different to the one reported above: integer :: a(5) open(99,Recl = 40) write(99,'(5i3)') 1,2,3 rewind(99) read(99,'(5i3)') a ! Expected: 1 2

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #10 from Richard Guenther 2011-02-24 14:25:48 UTC --- There are a load of valgrind errors as well: ==11765== Invalid read of size 1 ==11765==at 0x4F003D6: eat_leading_spaces (read.c:499) ==11765==by 0x4F00885: _gfortrani_read

[Bug c/47882] New: Incorrect "array subscript is above array bounds" warning

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47882 Summary: Incorrect "array subscript is above array bounds" warning Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #9 from Richard Guenther 2011-02-24 14:18:06 UTC --- And Integer, Pointer:: Image (:, :) Breakpoint 1, read_radix (dtp=0x7fffd7e0, f=0x107bba0, dest=0x6377c0 "�, length=4, radix=16) at /space/rguenther/

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #20 from Tobias Burnus 2011-02-24 14:17:40 UTC --- Some random thoughts looking at the patch (http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170432) - probably not helping at all with the regressions: I find the following a bit dub

[Bug fortran/42041] Missing defs in omp_lib.h

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42041 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 f

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #8 from Richard Guenther 2011-02-24 14:04:04 UTC --- Ah, line 61 of that file is 3A3B393C3B3C3B3D3B3B3C3C3C3D3D3E3F3D403E3F403E3E3C3D3B3D423E3E403E3E444242474B586E849EB9C1C5C5C9CBCECDCCCFCFCDCACDCAC9C6CCCACBD0 with +-1 surrounding l

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #7 from Richard Guenther 2011-02-24 14:01:27 UTC --- The error is Performing comparison with probe entries 1 ar2:global move determines position 58 45, similarity = 0.79937 1 ar2: best match ar1 sim. = 0.85

[Bug target/46779] wrong code generation for array access

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 --- Comment #7 from Georg-Johann Lay 2011-02-24 13:58:58 UTC --- Created attachment 23453 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23453 Simpler example without #include Slightly simpler test case, compile with avr-gcc -S -Os -mmcu=a

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #6 from Jerry DeLisle 2011-02-24 13:51:09 UTC --- We are going to need some sort of reduced test case or revert the patch.

[Bug debug/47858] [4.5/4.6 Regression] IPA-SRA decreases quality of debug info

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47858 --- Comment #2 from Alexandre Oliva 2011-02-24 13:50:18 UTC --- I think it would make sense to model this call-site SRA as partial inlining. It wouldn't get us perfect debug info, but it would at least give us something sensible at the inlined e

[Bug lto/47810] [4.6 Regression] New LTO/debug failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47810 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug debug/47801] guality tests have issues with LTO / -fwhole-program

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47801 Richard Guenther changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment

[Bug debug/43552] FAIL: gcc.dg/guality/pr41353-1.c with -flto and -fwhopr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43552 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug debug/47801] guality tests have issues with LTO / -fwhole-program

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47801 --- Comment #1 from Richard Guenther 2011-02-24 13:40:35 UTC --- Author: rguenth Date: Thu Feb 24 13:40:32 2011 New Revision: 170467 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170467 Log: 2011-02-24 Richard Guenther PR testsui

[Bug debug/47881] New: [4.6 Regression] -fcompare-debug failure (length) with -O -fno-dce -funroll-loops -fno-web

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47881 Summary: [4.6 Regression] -fcompare-debug failure (length) with -O -fno-dce -funroll-loops -fno-web Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal

[Bug ada/47880] New: Free in System.Pool_Local raises Storage_Error

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47880 Summary: Free in System.Pool_Local raises Storage_Error Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: ada AssignedTo: unassi

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #19 from Tobias Burnus 2011-02-24 12:51:38 UTC --- (In reply to comment #18) > Fixed on trunk. Keeping this PR open in order to remind us to > 1) Backport to older releases once we have some experience on trunk. Breaks SPEC CPU 2000'

[Bug c++/47861] static variables inside member functions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861 --- Comment #12 from Michal Turlik 2011-02-24 11:48:10 UTC --- Yep the Meyer singleton! T* instance() { static T instance; return &instance; } The trouble probably comes from this one...where the static definition comes from? Redi...I onl

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #21 from Janne Blomqvist 2011-02-24 11:34:18 UTC --- (In reply to comment #20) > libgfortran.sl is built twice on HP-UX 10, once for the single thread > model and once for the dce thread model. It's the single thread build > that's t

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #5 from Richard Guenther 2011-02-24 11:28:36 UTC --- Fails with -O0, works with r170432 reverted.

[Bug c++/47861] static variables inside member functions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861 --- Comment #11 from Jonathan Wakely 2011-02-24 11:27:51 UTC --- (In reply to comment #10) > > oo.cc:4:3: Warning: 'it' is declared as a function-scope > static, error prone, see static member variables No, it is not "error prone" - it is valid

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #4 from Richard Guenther 2011-02-24 11:19:57 UTC --- (In reply to comment #3) > (In reply to comment #0) > > I see miscompares with -O3 and -O2 -ffast-math. > > Does the miscompare depend on the -O flags? If so, the patch for PR 4769

[Bug c++/47861] static variables inside member functions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861 --- Comment #10 from Michal Turlik 2011-02-24 11:15:51 UTC --- redi, the signatures where wrong, the correct ones are: Base* Base::next (bool) void Base::init() btw you got the point - I mean you understood how the code buggy is. a better warn

[Bug c++/47861] static variables inside member functions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861 Paolo Carlini changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|

[Bug fortran/47879] wrong-debug issue with multiple USE-assoc of variables of other translation units

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47879 Tobias Burnus changed: What|Removed |Added Summary|wrong-debugICE in |wrong-debug issue with

[Bug fortran/47879] New: wrong-debugICE in dwarf2out.c:add_AT_specification

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47879 Summary: wrong-debugICE in dwarf2out.c:add_AT_specification Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: lto, wrong-debug Severity: normal Priority: P3

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #3 from Tobias Burnus 2011-02-24 10:57:28 UTC --- (In reply to comment #0) > I see miscompares with -O3 and -O2 -ffast-math. Does the miscompare depend on the -O flags? If so, the patch for PR 47694 cannot have cause it as it is a li

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org,

[Bug c++/47861] static variables inside member functions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861 --- Comment #8 from Jonathan Wakely 2011-02-24 10:44:15 UTC --- (In reply to comment #7) > The issue is clearly caused by having > declared static the iterator. So that's a bug, don't do that. > Obviously the same snippet code can be > replac

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 Richard Guenther changed: What|Removed |Added Target|x86_64-*-* |x86_64-*-*, ia64-*-*,

[Bug fortran/47878] New: [4.6 Regression] 187.facerec miscompares

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 Summary: [4.6 Regression] 187.facerec miscompares Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fort

[Bug fortran/47839] ICE in dwarf2out.c:add_AT_specification

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47839 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug fortran/47839] ICE in dwarf2out.c:add_AT_specification

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47839 --- Comment #5 from Richard Guenther 2011-02-24 09:53:30 UTC --- Author: rguenth Date: Thu Feb 24 09:53:26 2011 New Revision: 170463 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170463 Log: 2011-02-24 Richard Guenther PR fortran

[Bug c++/47874] Multiple Inheritance - Virtual Function - Segfault

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47874 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug c++/47877] New: -fvisibility-inlines-hidden does not hide member template functions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47877 Summary: -fvisibility-inlines-hidden does not hide member template functions Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c++/47861] static variables inside member functions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861 --- Comment #7 from Michal Turlik 2011-02-24 09:44:53 UTC --- Well guys it is probably silly but you need to consider a more specific case. Base* MyClass::next(bool reset) { static Bases::iterator it = m_bases.begin(); if(reset) it

[Bug target/46655] invalid '.line 0' directive emitted with -g

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #19 from Eric Botcazou 2011-02-24 09:26:58 UTC --- > /usr/bin/gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall > -Wwrite-strings > -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-format-attribute > -pedantic -

[Bug tree-optimization/47860] is vectorization of "condition in nested loop" supported

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47860 --- Comment #5 from vincenzo Innocente 2011-02-24 08:48:25 UTC --- I see, if you ever will commit anything in the mainline please let me know (I do like yet to work with patches in gcc :-). I understand that you need to provide an "architectural

[Bug tree-optimization/47860] is vectorization of "condition in nested loop" supported

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47860 --- Comment #4 from Ira Rosen 2011-02-24 08:37:07 UTC --- I tried to implement this last year: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00018.html and http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00631.html. But I don't think I want to contin

  1   2   >