Processed: Re: Bug#626236: g++-4.1: PR27935 operator delete(void*, size_t) issue
Processing commands for cont...@bugs.debian.org: > reassign 626236 g++-4.1 Bug #626236 [delete operator] g++-4.1: PR27935 operator delete(void*, size_t) issue Warning: Unknown package 'delete' Warning: Unknown package 'operator' Bug reassigned from package 'delete operator' to 'g++-4.1'. > -- Stopping processing here. Please contact me if you need assistance. -- 626236: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626236 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.130501222310062.transcr...@bugs.debian.org
Bug#626236: marked as done (g++-4.1: PR27935 operator delete(void*, size_t) issue)
Your message dated Tue, 10 May 2011 08:23:24 +0100 with message-id <20110510072324.gk5...@jirafa.cyrius.com> and subject line Re: Bug#626236: g++-4.1: PR27935 operator delete(void*, size_t) issue has caused the Debian Bug report #626236, regarding g++-4.1: PR27935 operator delete(void*, size_t) issue to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 626236: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626236 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- From: zeb_1...@yahoo.com Package: Delete Operator Bug: g++-4.1: PR27935 appears to be unresolved (operator delete(void*, size_t) issue)--- End Message --- --- Begin Message --- * Tahir Zeb [2011-05-09 23:52]: > Package: Delete Operator > > Bug: > g++-4.1: PR27935 appears to be unresolved (operator delete(void*, size_t) > issue) G++ 4.1 is not in any current versions of Debian anymore. I suggest you upgrade to a newer GCC. -- Martin Michlmayr http://www.cyrius.com/ --- End Message ---
Bug#626240: gcc-4.5: Spurious array bounds warning
Package: gcc-4.5 Version: 4.5.2-11 Severity: normal Tags: upstream This version of the gcc-4.5 package causes a spurious array-bounds warning on certain input: $ /usr/bin/gcc-4.5 -m32 -Warray-bounds -O2 -c -o /dev/null foo.i In file included from ../cpu-defs.h:30:0, from /home/dwg/ibm/kvm/qemu/target-ppc/cpu.h:76, from ../qemu-common.h:130, from ../sysemu.h:1, from /home/dwg/ibm/kvm/qemu/hw/spapr_hcall.c:1: ../osdep.h: In function ‘spapr_register_hypercall’: ../osdep.h:29:14: warning: array subscript is above array bounds Below is a sample input file which triggers this error. I've cut this down from some qemu code I was working on, after preprocessing. Note that the line number information from the preprocessor that I've included *is* significant. If the last line of it is removed, the spurious warning goes away. I'm not sure how to trim the innards of the line number information without causing other errors. The same code does not generate a warning with gcc-4.6. foo.i = # 1 "/home/dwg/ibm/kvm/qemu/hw/spapr_hcall.c" # 1 "/home/dwg/ibm/kvm/qemu/ppc64-softmmu//" # 1 "" # 1 "" # 1 "/home/dwg/ibm/kvm/qemu/hw/spapr_hcall.c" # 1 "../sysemu.h" 1 # 1 "../qemu-common.h" 1 # 1 "../config-host.h" 1 # 6 "../qemu-common.h" 2 # 17 "../qemu-common.h" # 1 "/usr/include/stdlib.h" 1 3 4 # 25 "/usr/include/stdlib.h" 3 4 # 1 "/usr/include/features.h" 1 3 4 # 313 "/usr/include/features.h" 3 4 # 1 "/usr/include/bits/predefs.h" 1 3 4 # 314 "/usr/include/features.h" 2 3 4 # 346 "/usr/include/features.h" 3 4 # 1 "/usr/include/sys/cdefs.h" 1 3 4 # 353 "/usr/include/sys/cdefs.h" 3 4 # 1 "/usr/include/bits/wordsize.h" 1 3 4 # 354 "/usr/include/sys/cdefs.h" 2 3 4 # 347 "/usr/include/features.h" 2 3 4 # 378 "/usr/include/features.h" 3 4 # 1 "/usr/include/gnu/stubs.h" 1 3 4 # 1 "/usr/include/bits/wordsize.h" 1 3 4 # 5 "/usr/include/gnu/stubs.h" 2 3 4 # 1 "/usr/include/gnu/stubs-32.h" 1 3 4 # 8 "/usr/include/gnu/stubs.h" 2 3 4 # 379 "/usr/include/features.h" 2 3 4 # 26 "/usr/include/stdlib.h" 2 3 4 # 1 "/usr/lib/gcc/i486-linux-gnu/4.5.2/include/stddef.h" 1 3 4 # 211 "/usr/lib/gcc/i486-linux-gnu/4.5.2/include/stddef.h" 3 4 # 323 "/usr/lib/gcc/i486-linux-gnu/4.5.2/include/stddef.h" 3 4 # 34 "/usr/include/stdlib.h" 2 3 4 # 1 "/usr/include/bits/waitflags.h" 1 3 4 # 43 "/usr/include/stdlib.h" 2 3 4 # 1 "/usr/include/bits/waitstatus.h" 1 3 4 # 65 "/usr/include/bits/waitstatus.h" 3 4 # 1 "/usr/include/endian.h" 1 3 4 # 37 "/usr/include/endian.h" 3 4 # 1 "/usr/include/bits/endian.h" 1 3 4 # 38 "/usr/include/endian.h" 2 3 4 # 61 "/usr/include/endian.h" 3 4 # 1 "/usr/include/bits/byteswap.h" 1 3 4 # 28 "/usr/include/bits/byteswap.h" 3 4 # 1 "/usr/include/bits/wordsize.h" 1 3 4 # 29 "/usr/include/bits/byteswap.h" 2 3 4 # 62 "/usr/include/endian.h" 2 3 4 # 66 "/usr/include/bits/waitstatus.h" 2 3 4 # 44 "/usr/include/stdlib.h" 2 3 4 # 68 "/usr/include/stdlib.h" 3 4 # 96 "/usr/include/stdlib.h" 3 4 # 140 "/usr/include/stdlib.h" 3 4 # 236 "/usr/include/stdlib.h" 3 4 # 1 "/usr/include/xlocale.h" 1 3 4 # 28 "/usr/include/xlocale.h" 3 4 # 237 "/usr/include/stdlib.h" 2 3 4 # 311 "/usr/include/stdlib.h" 3 4 # 1 "/usr/include/sys/types.h" 1 3 4 # 29 "/usr/include/sys/types.h" 3 4 # 1 "/usr/include/bits/types.h" 1 3 4 # 28 "/usr/include/bits/types.h" 3 4 # 1 "/usr/include/bits/wordsize.h" 1 3 4 # 29 "/usr/include/bits/types.h" 2 3 4 # 131 "/usr/include/bits/types.h" 3 4 # 1 "/usr/include/bits/typesizes.h" 1 3 4 # 132 "/usr/include/bits/types.h" 2 3 4 # 32 "/usr/include/sys/types.h" 2 3 4 # 133 "/usr/include/sys/types.h" 3 4 # 1 "/usr/include/time.h" 1 3 4 # 58 "/usr/include/time.h" 3 4 # 74 "/usr/include/time.h" 3 4 # 92 "/usr/include/time.h" 3 4 # 104 "/usr/include/time.h" 3 4 # 134 "/usr/include/sys/types.h" 2 3 4 # 1 "/usr/lib/gcc/i486-linux-gnu/4.5.2/include/stddef.h" 1 3 4 # 148 "/usr/include/sys/types.h" 2 3 4 # 195 "/usr/include/sys/types.h" 3 4 # 220 "/usr/include/sys/types.h" 3 4 # 1 "/usr/include/sys/select.h" 1 3 4 # 31 "/usr/include/sys/select.h" 3 4 # 1 "/usr/include/bits/select.h" 1 3 4 # 23 "/usr/include/bits/select.h" 3 4 # 1 "/usr/include/bits/wordsize.h" 1 3 4 # 24 "/usr/include/bits/select.h" 2 3 4 # 32 "/usr/include/sys/select.h" 2 3 4 # 1 "/usr/include/bits/sigset.h" 1 3 4 # 24 "/usr/include/bits/sigset.h" 3 4 # 35 "/usr/include/sys/select.h" 2 3 4 # 1 "/usr/include/time.h" 1 3 4 # 120 "/usr/include/time.h" 3 4 # 45 "/usr/include/sys/select.h" 2 3 4 # 1 "/usr/include/bits/time.h" 1 3 4 # 69 "/usr/include/bits/time.h" 3 4 # 47 "/usr/include/sys/select.h" 2 3 4 # 55 "/usr/include/sys/select.h" 3 4 # 67 "/usr/include/sys/select.h" 3 4 # 99 "/usr/include/sys/select.h" 3 4 # 109 "/usr/include/sys/select.h" 3 4 # 121 "/usr/include/sys/select.h" 3 4 # 221 "/usr/include/sys/types.h" 2 3 4 # 1 "/usr/include/sys/sysmacros.h" 1 3 4 # 30 "/usr/include/sys/sysmacros.h" 3 4 # 224 "/usr/include/sys/types.h" 2 3 4 # 248 "/usr/include/sys/types.h" 3 4 # 1 "/usr/
[Bug debug/48159] [4.6/4.7 Regression] ICE: SIGSEGV in build2_stat (tree.c:3802) with -ftree-loop-distribution -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48159 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek 2011-05-10 12:15:55 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167697 -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bug-48159-5724-yrvg6kb...@http.gcc.gnu.org/bugzilla/
[Bug debug/48159] [4.6/4.7 Regression] ICE: SIGSEGV in build2_stat (tree.c:3802) with -ftree-loop-distribution -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48159
--- Comment #7 from Jakub Jelinek 2011-05-10
13:08:31 UTC ---
Further reduced testcase for -O3 -g:
void
foo (double x, int y, double *__restrict z, double *__restrict w)
{
while (y--)
*z++ = (*w++ = 0) * x;
}
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/bug-48159-5724-i1jqhjf...@http.gcc.gnu.org/bugzilla/
[Bug debug/48159] [4.6/4.7 Regression] ICE: SIGSEGV in build2_stat (tree.c:3802) with -ftree-loop-distribution -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48159 Jakub Jelinek changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #8 from Jakub Jelinek 2011-05-10 14:29:32 UTC --- First of all, it surprises me that tree-loop-distribution.c and stmts_from_loop don't do anything special about debug stmts, I'd say stmts_from_loop should ignore debug stmts like it ignores GIMPLE_LABELs and generate_loops_for_partition and generate_builtin match that, the first by keeping all DEBUG stmts in all loops and generate_builtin to just ignore them. Otherwise I think we risk -fcompare-debug failures. The second problem is in generate_loops_for_partition, it wants to remove all stmts that are not in that partition, and going in the order of stmts queued from stmts_from_loop, by walking the loop bbs sequentially and first going through not marked phis, removing each of them, then going through stmts from first to last in the bb, again removing unneeded stmts. insert_debug_temp_for_var_def though assumes I think that within one bb stmts are removed from the end towards beginning and that bbs are traversed during removal in the right order according to dominator info. Not sure what we want to do there, perhaps reset all the debug stmts that use values set by stmts that are not in the current partition? Alex, any ideas? In particular, the problematic DEBUG stmt uses a SSA_NAME which is not in partition bitmap, whose definition is a PHI node result again not in the partition, and where one of the PHI arguments again uses the SSA_NAME also used in the DEBUG stmt. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bug-48159-5724-8lxts7x...@http.gcc.gnu.org/bugzilla/
[Bug debug/48159] [4.6/4.7 Regression] ICE: SIGSEGV in build2_stat (tree.c:3802) with -ftree-loop-distribution -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48159 Jakub Jelinek changed: What|Removed |Added Target Milestone|4.7.0 |4.6.1 -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bug-48159-5724-cupyuab...@http.gcc.gnu.org/bugzilla/
Re: sh4 architecture into Wheezy
Hi,
2011/4/26 Neil McGovern :
> On Tue, Apr 26, 2011 at 12:58:24PM +0900, Nobuhiro Iwamatsu wrote:
>> > We don't have faster hardware.
>> > We think of a too slow thing in a question
>>
>> A test of gcc of sh4 takes time.
>> When there is not a test, a package is done in about two days.
>>
>> How does sh4 become targeted for the release architecture?
>> Can sh4 disable gcc test?
>>
>
> I woudn't be particularly happy with that unless the gcc maintainers ok
> it, and I'm still not sure that two days is also an acceptable
> timescale.
Hmm.
>
> Have you tried a SH4A with a dual core? At the moment, I think that this
> issue is severe enough that it can't be a release architecture. (Note
> that if it is solved, there may be other problems, but we can get to
> those later.)
No.
I have the board which this CPU on. However, I cannot use it for
Buildd because this is for development.
Is buildd using distcc accommodate?
If it is a cause that speed of buildd is slow, Debian may not support
the CPU for embedded.
Best regards,
Nobuhiro
>
> Neil
> --
> A. Because it breaks the logical sequence of discussion
> Q. Why is top posting bad?
> gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li A40F862E
>
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/banlktikedcya4obc2kefijtdb+aacyx...@mail.gmail.com
