[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #56 from jakub at gcc dot gnu dot org 2010-08-12 08:20 --- Please stop wasting your and GCC developers time. As several people have explained, your code triggers undefined behavior in C/C++, so it can do anything at runtime. The fact that it happens to work as you expect with some compilers doesn't mean anything. If you choose to program in C (or C++), you just need to follow the standard. GCC bugzilla is for reporting GCC bugs, not for learning programming languages, look for various C forums instead. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #18 from sebastian dot huber at embedded-brains dot de
2010-08-12 08:19 ---
This bug is still present in GCC 4.6.0 20100807 (arm-eabi-gcc -O1
-fschedule-insns2 -mthumb):
readStream:
push{r4, lr}
sub sp, sp, #8
mov r4, sp
mov r3, #0
strbr3, [r4, #7]
add r4, r4, #7
ldr r3, [r0]
mov r1, r4
mov r2, #1
bl doStreamReadBlock
add sp, sp, #8
ldrbr0, [r4]
@ sp needed for prologue
pop {r4}
pop {r1}
bx r1
.size readStream, .-readStream
.ident GCC: (GNU) 4.6.0 20100807 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug middle-end/45262] [4.2/4.3/4.4/4.5/4.6 Regression] Optimization results in wrong result on expression x31||(-x)31
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-08-12 00:44:58 |2010-08-12 08:43:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45262
[Bug debug/45259] [4.5/4.6 Regression] ICE in save_call_clobbered_regs
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-12 09:05 --- Subject: Bug 45259 Author: jakub Date: Thu Aug 12 09:04:48 2010 New Revision: 163185 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163185 Log: PR debug/45259 * caller-save.c (save_call_clobbered_regs): Only swap notes with DEBUG_INSNs if n_regs_saved. * gcc.dg/pr45259.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr45259.c Modified: trunk/gcc/ChangeLog trunk/gcc/caller-save.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45259
[Bug debug/45259] [4.5/4.6 Regression] ICE in save_call_clobbered_regs
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-12 09:10 --- Subject: Bug 45259 Author: jakub Date: Thu Aug 12 09:09:49 2010 New Revision: 163186 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163186 Log: PR debug/45259 * caller-save.c (save_call_clobbered_regs): Only swap notes with DEBUG_INSNs if n_regs_saved. * gcc.dg/pr45259.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45259.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/caller-save.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45259
[Bug debug/45055] [4.5/4.6 Regression] another -fcompare-debug failure with uninitialised read in walk_gimple_stmt
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-12 09:15 --- Subject: Bug 45055 Author: jakub Date: Thu Aug 12 09:14:47 2010 New Revision: 163187 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163187 Log: Backport from mainline 2010-07-30 Jakub Jelinek ja...@redhat.com PR debug/45055 PR rtl-optimization/45137 * rtl.h (prev_nonnote_nondebug_insn, next_nonnote_nondebug_insn): New prototypes. * emit-rtl.c (prev_nonnote_nondebug_insn, next_nonnote_nondebug_insn): New functions. * combine.c (next_nonnote_nondebug_insn): Removed. * ifcvt.c (noce_process_if_block): Use prev_nonnote_nondebug_insn. * haifa-sched.c (queue_to_ready): Use next_nonnote_nondebug_insn. * sched-deps.c (sched_analyze_insn): Likewise. (fixup_sched_groups, deps_start_bb): Use prev_nonnote_nondebug_insn. * rtlanal.c (canonicalize_condition): Likewise. * postreload.c (reload_combine): Likewise. (reload_cse_move2add): Use next_nonnote_nondebug_insn. * gcc.dg/pr45055.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45055.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/combine.c branches/gcc-4_5-branch/gcc/emit-rtl.c branches/gcc-4_5-branch/gcc/haifa-sched.c branches/gcc-4_5-branch/gcc/ifcvt.c branches/gcc-4_5-branch/gcc/postreload.c branches/gcc-4_5-branch/gcc/rtl.h branches/gcc-4_5-branch/gcc/rtlanal.c branches/gcc-4_5-branch/gcc/sched-deps.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45055
[Bug rtl-optimization/45137] [4.6 Regression] -g changes the generated code for gcc/sched-vis.c on SH
--- Comment #7 from jakub at gcc dot gnu dot org 2010-08-12 09:15 --- Subject: Bug 45137 Author: jakub Date: Thu Aug 12 09:14:47 2010 New Revision: 163187 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163187 Log: Backport from mainline 2010-07-30 Jakub Jelinek ja...@redhat.com PR debug/45055 PR rtl-optimization/45137 * rtl.h (prev_nonnote_nondebug_insn, next_nonnote_nondebug_insn): New prototypes. * emit-rtl.c (prev_nonnote_nondebug_insn, next_nonnote_nondebug_insn): New functions. * combine.c (next_nonnote_nondebug_insn): Removed. * ifcvt.c (noce_process_if_block): Use prev_nonnote_nondebug_insn. * haifa-sched.c (queue_to_ready): Use next_nonnote_nondebug_insn. * sched-deps.c (sched_analyze_insn): Likewise. (fixup_sched_groups, deps_start_bb): Use prev_nonnote_nondebug_insn. * rtlanal.c (canonicalize_condition): Likewise. * postreload.c (reload_combine): Likewise. (reload_cse_move2add): Use next_nonnote_nondebug_insn. * gcc.dg/pr45055.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45055.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/combine.c branches/gcc-4_5-branch/gcc/emit-rtl.c branches/gcc-4_5-branch/gcc/haifa-sched.c branches/gcc-4_5-branch/gcc/ifcvt.c branches/gcc-4_5-branch/gcc/postreload.c branches/gcc-4_5-branch/gcc/rtl.h branches/gcc-4_5-branch/gcc/rtlanal.c branches/gcc-4_5-branch/gcc/sched-deps.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45137
[Bug debug/45259] [4.5/4.6 Regression] ICE in save_call_clobbered_regs
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-12 09:32 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45259
[Bug debug/45055] [4.5/4.6 Regression] another -fcompare-debug failure with uninitialised read in walk_gimple_stmt
--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-12 09:32 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45055
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #8 from hainque at gcc dot gnu dot org 2010-08-12 09:42 --- (In reply to comment #7) Hi John, PR boehm-gc/34544 (__gthread_active_init): Use pthread_default_stacksize_np instead of pthread_create to determine if hpux pthreads are active. branches/gcc-4_3-branch/gcc/gthr-posix.h After this change, our local 4.3 builds on PA HPUX 11.0 with Ada fail producing intermediate binaries that aren't linked with -lpthread (gnatbind to start with), with complaints like /usr/ccs/bin/ld: Unsatisfied symbols: pthread_default_stacksize_np (first referenced in .../libgcc_eh.a(unwind-dw2-fde.o)) (code) Presumably, this used to work because libc provides a dummy pthread_create. Thoughts ? I can provide more details on our configuration etc if need be. MTIA, Olivier -- hainque at gcc dot gnu dot org changed: What|Removed |Added CC||hainque at adacore dot com, ||hainque at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug target/45261] Doesn't indicate failure status when it doesn't support (attiny2313A)
--- Comment #4 from j at uriah dot heep dot sax dot de 2010-08-12 09:54 --- (In replay to comment #1) That should most likely be an error instead of just a fprintf. Agreed. What surprises me a bit that I've been under the impression this used to work in previous releases: [part of avr-libc's config.log] configure:6074: checking if avr-gcc has support for attiny461a configure:6090: avr-gcc -c -mmcu=attiny461a conftest.c 5 Known MCU names: avr1 avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega1 [...] Assembler messages: Fatal error: unknown MCU: attiny461a configure:6097: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME avr-libc | #define PACKAGE_TARNAME avr-libc | #define PACKAGE_VERSION 1.6.8 | #define PACKAGE_STRING avr-libc 1.6.8 | #define PACKAGE_BUGREPORT avr-libc-...@nongnu.org | #define PACKAGE avr-libc | #define VERSION 1.6.8 | /* end confdefs.h. */ | configure:6116: result: no [/config.log] However, if I parse these messages correctly, GCC probably never really rejected the unknown -mmcu option, instead it has only incidentally been rejected because in turn, the assembler eventually cmoplained. I agree that it should already be the compiler's business to cause an error exit status (by turning the fprintf() into an error()). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45261
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #19 from steven at gcc dot gnu dot org 2010-08-12 10:00 --- According to comment#14, a patch from Alexander Monakov introduced this bug, therefore: 1. this is a regression on a primary platform = priority should be set P1 -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, amonakov at gcc dot gnu ||dot org Summary|Optimization flag -O1 - |[4.3/4.4/4.5/4.6 Regression] |fschedule-insns2 causes |Optimization flag -O1 - |wrong code |fschedule-insns2 causes ||wrong code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #20 from steven at gcc dot gnu dot org 2010-08-12 10:00 --- ...and 2. Add richi and amonakov to CC: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #7 from paolo dot carlini at oracle dot com 2010-08-12 10:02 --- In practice, I don't see how this issue can be tackled independently from the complexity of erase returning iterator: adding a cache for the first non-empty bucket is generally simple, but there is a problem with erase(const key_type), when it erases the entire first non-empty bucket, thus potentially has to scan all the buckets to update the cache. In other terms, it seems to me that simply adding a cache fixes the complexity of begin() but deteriorates the complexity of erase(const key_type). Is this the specific point raised in the Boost PR or I'm missing something? Understand it's the first time I'm seriously touching the unordered containers, only simple fixes and cleanups so far. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #21 from steven at gcc dot gnu dot org 2010-08-12 10:08 --- Re. comment #14 I am a bit irritated why this bug survived the 4.4.0 and 4.5.0 release.: Yes, well, ARM maintainers have been in the CC-list for this bug since the beginning, and apparently it was even too much trouble for them to see if this is a regression or not... :-( Anyway, many thanks to Sebastian Huber for identifying the revision that introduced (or exposed) this bug. -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-12-22 11:16:40 |2010-08-12 10:08:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #22 from amonakov at gcc dot gnu dot org 2010-08-12 10:12 --- It looks like patch from comment #16 should fix the problem, but was not reviewed and/or applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #57 from rogerio at rilhas dot com 2010-08-12 10:16 --- (In reply to comment #56) Please stop wasting your and GCC developers time. As several people have explained, your code triggers undefined behavior in C/C++, so it can do anything at runtime. The fact that it happens to work as you expect with some compilers doesn't mean anything. If you choose to program in C (or C++), you just need to follow the standard. GCC bugzilla is for reporting GCC bugs, not for learning programming languages, look for various C forums instead. I've clearly shown the bug in my commment #51. It is a bug in the address operator. C99 says GCC shouldn't be doing that. The format is not undefined behavior. In comment #36 Richard Guenther agrees that X should return the stack address. GCC is not doing that. Please open your eyes and understand this. It is simple. I believe you all have the brain power to understand at least that. If you just forget all the rest and focus on X you'll see GCC has a bug. If you fix it I can then handle the rest on my own, thank you, no need for all your rants about standards. You are the ones who shouldn't be wasting my time like this. -- rogerio at rilhas dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #58 from paolo dot carlini at oracle dot com 2010-08-12 10:18 --- . -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug tree-optimization/45232] [4.6 regression] tree reassociation introduces undefined overflow
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-08-12 10:38 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45232
[Bug tree-optimization/45232] [4.6 regression] tree reassociation introduces undefined overflow
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-12 10:38 --- Subject: Bug 45232 Author: rguenth Date: Thu Aug 12 10:38:05 2010 New Revision: 163190 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163190 Log: 2010-08-12 Richard Guenther rguent...@suse.de PR tree-optimization/45232 * tree-ssa-reassoc.c (can_reassociate_p): Disable re-association for types with undefined overflow. (reassociate_bb): Allow re-associating of bit and min/max operations for types with undefined overflow. * tree-ssa-forwprop.c (associate_plusminus): New function. (tree_ssa_forward_propagate_single_use_vars): Call it. * gcc.dg/tree-ssa/pr44133.c: Adjust warning location. * gcc.dg/tree-ssa/loop-7.c: Adjust. * gcc.dg/tree-ssa/reassoc-1.c: XFAIL. * gcc.dg/tree-ssa/reassoc-20.c: Add reassoc-1.c variant with unsigned arithmetic. * gcc.dg/tree-ssa/reassoc-14.c: Use unsigned arithmetic. * gcc.dg/tree-ssa/reassoc-15.c: Likewise. * gcc.dg/tree-ssa/reassoc-18.c: Likewise. * gcc.dg/tree-ssa/reassoc-2.c: XFAIL. * gcc.dg/tree-ssa/reassoc-21.c: Add reassoc-2.c variant with unsigned arithmetic. * gcc.dg/tree-ssa/reassoc-6.c: XFAIL. * gcc.dg/tree-ssa/reassoc-22.c: Add reassoc-6.c variant with unsigned arithmetic. * gcc.dg/tree-ssa/reassoc-7.c: Use unsigned arithmetic. * gcc.dg/tree-ssa/reassoc-9.c: XFAIL. * gcc.dg/tree-ssa/reassoc-23.c: Add reassoc-9.c variant with unsigned arithmetic. * gcc.dg/tree-ssa/ssa-pre-2.c: Adjust. * gcc.dg/tree-ssa/negate.c: Adjust. * gcc.dg/vect/vect-1.c: Adjust. * gfortran.dg/reassoc_6.f: XFAIL. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-20.c trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-21.c trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-22.c trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-23.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-7.c trunk/gcc/testsuite/gcc.dg/tree-ssa/negate.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr44133.c trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-14.c trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-15.c trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-18.c trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-6.c trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-7.c trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-9.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-2.c trunk/gcc/testsuite/gcc.dg/vect/vect-1.c trunk/gcc/testsuite/gfortran.dg/reassoc_6.f trunk/gcc/tree-ssa-forwprop.c trunk/gcc/tree-ssa-reassoc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45232
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #8 from paolo dot carlini at oracle dot com 2010-08-12 10:55 --- Maybe averaging over all possible keys, we are fine: the probability to erase the first non-empty bucket is of the order 1 / # buckets, thus decreases exactly as fast as # buckets grows. On the average the slowness of that rare operation should not impact the O complexity of erase(const key_type), should remain asymptotically independent from # buckets, as we want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug target/45258] linkage on -ldl, -lm and -lpthread should be purged from darwin build
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2010-08-12 11:23 --- Posted patches to http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00886.html and http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00887.html. Testsuite results posted at http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01232.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45258
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #23 from steven at gcc dot gnu dot org 2010-08-12 11:37 --- The patch from comment #16 only fixes the symptom, and only on ARM. It is not a proper fix for the generic problem that is apparently also visible on POWER. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #24 from jakub at gcc dot gnu dot org 2010-08-12 11:47 --- It is not visible on POWER, because it has been fixed there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug middle-end/45262] [4.2/4.3/4.4/4.5/4.6 Regression] Optimization results in wrong result on expression x31||(-x)31
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-12 11:56 --- Created an attachment (id=21468) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21468action=view) gcc46-pr45262.patch Untested fix. As the testcase shows, while bar isn't miscompiled by 4.1 and earlier, foo is miscompiled even by 3.2. Seems fold_range_test and related routines expect normalized ranges and e.g. PLUS_EXPR/MINUS_EXPR do that normalization, but NEGATE_EXPR handling does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45262
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #25 from amonakov at gcc dot gnu dot org 2010-08-12 12:00 --- (In reply to comment #23) The patch from comment #16 only fixes the symptom, and only on ARM. It is not a proper fix for the generic problem that is apparently also visible on POWER. PR30282 audit trail contains more discussion of this problem. Jim Wilson argues that this problem should be addressed by emitting stack ties in epilogues for targets that suffer from this problem (other targets apparently do not thanks to red zone). POWER was fixed that way (PR44199). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-08-12 12:04 --- (In reply to comment #19) According to comment#14, a patch from Alexander Monakov introduced this bug, therefore: 1. this is a regression on a primary platform = priority should be set P1 It's not P1 because P1 is reserved for serious bugs that were never in any release which isn't true here. P1 _block_ a release, it is unreasonable to do so in general if a previous release shipped with that bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #27 from rearnsha at gcc dot gnu dot org 2010-08-12 12:13 --- (In reply to comment #21) Re. comment #14 I am a bit irritated why this bug survived the 4.4.0 and 4.5.0 release.: Yes, well, ARM maintainers have been in the CC-list for this bug since the beginning, and apparently it was even too much trouble for them to see if this is a regression or not... :-( Anyway, many thanks to Sebastian Huber for identifying the revision that introduced (or exposed) this bug. So this ARM maintainer, proposed a fix for the problem (a generic bug, not a back-end bug). But because it seems that generating correct code on all targets isn't a priority, it was rejected. The compiler shouldn't be generating unsafe code by default; back-ends shouldn't need to paper over bugs in the MI code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #28 from jakub at gcc dot gnu dot org 2010-08-12 12:26 --- The problem is that stuff like red-zone presence and size isn't known to the middle-end, all that stuff is backend private, so I think the right way is to handle this in the backends and most of the backends managed to handle it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #29 from rearnsha at gcc dot gnu dot org 2010-08-12 12:30 --- (In reply to comment #28) The problem is that stuff like red-zone presence and size isn't known to the middle-end, all that stuff is backend private, so I think the right way is to handle this in the backends and most of the backends managed to handle it. No, the middle end code must fail safe. If targets don't need that, then they should have the ability to turn it off; not the other way around. This is critical because it leads to silent failures otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #9 from joaquin at tid dot es 2010-08-12 12:32 --- Hi Paolo, My comments on your last two posts: I think the impact of this is independent of #579: even if erase does not return an iterator, the cached bucket pointer has to be synced. This happens for erase(const key_type) as well as erase(const_iterator). Of course, if erase(const_iterator) returns an iterator then the cached bucket pointer cost is masked (because you need to reach for the next non-empty bucket anyway). And yes, there is a non-negligible impact on doing the cache thing. There was no discussion on this on the committe, so we are basically on our own :-) I agree with you the impact does not affect the O complexity of insert/erase, but it's an impact nonetheless. The testcase provided is this: you have an *empty* container with a large bucket count (because it held a large number of elements before) and keep adding and removing the same element: the resulting performance is linear with the number of buckets. Whether this must be considered or not a pathological use case I don't know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #10 from paolo dot carlini at oracle dot com 2010-08-12 12:42 --- My comments on your last two posts: Thanks Manuel. I think the impact of this is independent of #579: even if erase does not return an iterator, the cached bucket pointer has to be synced. This happens for erase(const key_type) as well as erase(const_iterator). Of course, if erase(const_iterator) returns an iterator then the cached bucket pointer cost is masked (because you need to reach for the next non-empty bucket anyway). Totally agreed. And yes, there is a non-negligible impact on doing the cache thing. There was no discussion on this on the committe, so we are basically on our own :-) I agree with you the impact does not affect the O complexity of insert/erase, but it's an impact nonetheless. The testcase provided is this: you have an *empty* container with a large bucket count (because it held a large number of elements before) and keep adding and removing the same element: the resulting performance is linear with the number of buckets. Whether this must be considered or not a pathological use case I don't know. Agreed again. Now I begin to understand this issue ;) Anyway, the patch for our library is almost ready, already passes all my test. I'll apply it later today and start working on the even more serious erase(iterator) issue: during that work I will give more thinking to this one too, see if we can improve the QoI of erase(const key_type) somehow. Let's keep in touch about these issues. Thanks again for now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-12 13:38 --- Subject: Re: pthread_default_stacksize_np failed. Hi Olivier, Hi John, PR boehm-gc/34544 (__gthread_active_init): Use pthread_default_stacksize_np instead of pthread_create to determine if hpux pthreads are active. branches/gcc-4_3-branch/gcc/gthr-posix.h After this change, our local 4.3 builds on PA HPUX 11.0 with Ada fail producing intermediate binaries that aren't linked with -lpthread (gnatbind to start with), with complaints like /usr/ccs/bin/ld: Unsatisfied symbols: pthread_default_stacksize_np (first referenced in .../libgcc_eh.a(unwind-dw2-fde.o)) (code) Presumably, this used to work because libc provides a dummy pthread_create. Thoughts ? The function is present in libc.sl on my PA HPUX 11.00 system. Possibly, this can be fixed by updating your libc version. However, I just noticed that there is no libc stub for pthread_default_stacksize_np in libc.a. Are you doing a static link? Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug c++/45200] [4.5/4.6 Regression] ICE in template instantiation
--- Comment #10 from dodji at gcc dot gnu dot org 2010-08-12 13:40 --- A better patch submitted to http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00842.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-12 14:04 --- Subject: Re: pthread_default_stacksize_np failed. The function is present in libc.sl on my PA HPUX 11.00 system. Possibly, this can be fixed by updating your libc version. However, I just noticed that there is no libc stub for pthread_default_stacksize_np in libc.a. Are you doing a static link? It appears pthread_default_stacksize_np was added to libc in PHCO_30531 on 11.23. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #11 from joaquin at tid dot es 2010-08-12 14:06 --- Thanks Manuel. It's Joaquín :-) You're welcome. Agreed again. Now I begin to understand this issue ;) Anyway, the patch for our library is almost ready, already passes all my test. I'll apply it later today and start working on the even more serious erase(iterator) issue: during that work I will give more thinking to this one too, see if we can improve the QoI of erase(const key_type) somehow. Let's keep in touch about these issues. Perfect, let's do that. Regarding #579, last I heard from my contact in the committee is that the issue has been finally dismissed and the standard will have an iterator-returning erase(const_iterator). That seems to imply that there exist singly linked lists implementations capable of circumventing the problem, but I haven't seen one yet. Do you have more info (maybe directly from the committee) on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #11 from hainque at adacore dot com 2010-08-12 14:14 --- Subject: Re: pthread_default_stacksize_np failed. dave at hiauly1 dot hia dot nrc dot ca wrote: The function is present in libc.sl on my PA HPUX 11.00 system. Hmm, not here. There are many more pthread_ entries in libc.sl than in libc.a, but not this one. Possibly, this can be fixed by updating your libc version. However, I just noticed that there is no libc stub for pthread_default_stacksize_np in libc.a. Right, it's not here either for us (B.11.00 U 9000/785 2008571012). Are you doing a static link? Not entirely (according to the logs, we link with libc.sl and libgcc*.a). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #12 from hainque at adacore dot com 2010-08-12 14:18 --- Subject: Re: pthread_default_stacksize_np failed. [Thanks for your prompt feebdack Dave :-)] dave at hiauly1 dot hia dot nrc dot ca wrote: It appears pthread_default_stacksize_np was added to libc in PHCO_30531 on 11.23. PHCO_29955 seems relevant as well ( SR:8606338169 CR:JAGae99143 ) Unable to resolve pthread_default_stacksize_np(3T) symbol due to the lack of stub in libc when not linked to pthread library. We probably could update our system and document but I don't know what to think of the more general user base (whether many could possibly be affected). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #13 from hainque at adacore dot com 2010-08-12 14:24 --- Subject: Re: pthread_default_stacksize_np failed. hainque at adacore dot com wrote: PHCO_29955 seems relevant as well This was for 11.11. For 11.00, this is part of PHCO_29956. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug target/45264] New: Stack corruption with any function using frame
With the beta AVR toolchain 3.0.0.207, the prologue for functions using a frame has changed and is now causing stack corruption when an interrupt fires. Take for example a function which needs 5 bytes of frame. This is how the frame is setup in the function prologue: Under WinAVR2010: a30: df 93 pushr29 a32: cf 93 pushr28 a34: 00 d0 rcall .+0 ; 0xa36 a36: 00 d0 rcall .+0 ; 0xa38 a38: 0f 92 pushr0 a3a: cd b7 in r28, 0x3d ; 61 a3c: de b7 in r29, 0x3e ; 62 AVR Toolchain 3.0.0.207: +0507: 93DFPUSH R29Push register on stack +0508: 93CFPUSH R28Push register on stack +0509: B7CDINR28,0x3D In from I/O location +050A: B7DEINR29,0x3E In from I/O location +050B: 9725SBIW R28,0x05 Subtract immediate from word +050C: BFDEOUT 0x3E,R29 Out to I/O location +050D: BFCDOUT 0x3D,R28 The stack corruption occurs when an interrupt fires between addresses 0x50C and 0x50D in the example above since the stack pointer is only half updated. I have submitted this as critical since it causes applications to crash consistently. -- Summary: Stack corruption with any function using frame Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: darkdragon2000 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #12 from paolo dot carlini at oracle dot com 2010-08-12 14:37 --- It's Joaquín :-) You're welcome. Sorry. I don't know what I was thinking. Perfect, let's do that. Regarding #579, last I heard from my contact in the committee is that the issue has been finally dismissed and the standard will have an iterator-returning erase(const_iterator). That seems to imply that there exist singly linked lists implementations capable of circumventing the problem, but I haven't seen one yet. Do you have more info (maybe directly from the committee) on this? Yes, I attended the Rapperswil meeting, but wasn't in the room. Anyway, from the minutes I understand that people spent only a few minutes on this issue. Pablo Halpern and Howard Hinnant reported that their prototype implementations worked well, nobody said anything special about memory use and the discussion quickly ended with a pool: 12 votes strongly in favor of iterator, 1 weakly in favor, only 1 weakly against. Let's keep in touch off-Bugzilla about the details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug rtl-optimization/45223] RTL PRE GCSE pass hoists trapping insn out of loop
--- Comment #6 from ubizjak at gmail dot com 2010-08-12 14:46 --- Ouch, Here are the ration of before and after on Intel Core i7. Gzip slowed down by 10 to 20%. [1] Richi says: The fix is to teach LIM to do conditional invariant motion. Probably also related to PR42108 catch-all PR. [1] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00771.html [2] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00884.html -- ubizjak at gmail dot com changed: What|Removed |Added BugsThisDependsOn||42108 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45223
[Bug c++/45265] New: GCC has an intermittent bug when computing the address of function parameters
The following code:
void bug_example_2(const char** format_address, int* ip) {
char* p1=(char*)format_address;
char* p2=(char*)ip;
int dif=p2-p1;
if (dif!=sizeof(char*)) {
// crash
char* p=0; *p=0;
}
}
void bug_example(const char* strp, int i) {
char buffer[1000]; buffer[0]=0;
bug_example_2(strp, i);
}
int main(void) {
bug_example(GCC has a bug, 10);
return 0;
}
... is incorrectly compiled by GCC. As you can see there are no variable
parameters in this code, so there is nothing here out of the ordinary.
Possibility 1) GCC is not cdecl-ABI compliant, so the dif can have values
other than 4 on x86-32. In this case GCC should not claim to be
cdecl-compliant.
Possibility 2) GCC is not conformant to C99 but it is cdecl-ABI compliant. C99
states in section 6.5.3.2 paragraph 3 that The unary operator yields the
address of its operand., but GCC is not doing that, as the if in
bug_example_2 is occasionally entered. Thus dif is not 4 (and with cdecl ABI
it should be 4 on x86-32).
If line char buffer[1000]; buffer[0]=0; GCC then compiles the code as
expected and dif will be 4.
This proves GCC is not conforming to C99 recommendations or that is not
cdecl-ABI compliant (or possibly both).
Don't bother trying to understand why I need the operand to work as stated in
C99, or why I need the code to be cdecl compliant, that is too complicated for
you and it would just confuse you. For the purpose of this bug you may simply
consider that I'm performing conformity tests on GCC against C99 and cdecl, and
that GCC failed the test.
Next I will send you the preprocessed file and the compilation script.
--
Summary: GCC has an intermittent bug when computing the address
of function parameters
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rogerio at rilhas dot com
GCC build triplet: i686-virtualboxvm-ubuntu?
GCC host triplet: i686-virtualboxvm-ubuntu?
GCC target triplet: i686-virtualboxvm-ubuntu?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #1 from rogerio at rilhas dot com 2010-08-12 14:52 --- Created an attachment (id=21469) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21469action=view) Preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #2 from rogerio at rilhas dot com 2010-08-12 14:52 --- Created an attachment (id=21470) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21470action=view) Compilation script -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #3 from rogerio at rilhas dot com 2010-08-12 14:54 --- Correction: If line char buffer[1000]; buffer[0]=0; _is removed then_ GCC then compiles the code as expected and dif will be 4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-12 15:03 --- Subject: Re: pthread_default_stacksize_np failed. We probably could update our system and document but I don't know what to think of the more general user base (whether many could possibly be affected). That's a good question. At a minimum, the documentation needs updating. At the moment it looking like there's no good way to determine whether threads are active or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-12 15:08 --- Pretty please, before filing further bugs take time and learn C. The pointer subtraction triggers undefined behavior, because one pointer points to one object and the other pointer points to different object. See ISO C99, 6.5.6/9. In particular, in this testcase the functions are inlined and thus i and strp are just normal automatic variables in main, obviously nothing guarantees how they are laid out in the stack. But even if it isn't inlined, the behavior would be undefined. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug target/45264] Stack corruption with any function using frame
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-12 15:15 --- Why isn't this a bug in the interrupt handler? What is beta AVR toolchain 3.0.0.207 btw? We do not release such, so maybe you should file a bug with the vendor releasing that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264
[Bug middle-end/45262] [4.2/4.3/4.4/4.5/4.6 Regression] Optimization results in wrong result on expression x31||(-x)31
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-12 15:21 --- Subject: Bug 45262 Author: jakub Date: Thu Aug 12 15:21:34 2010 New Revision: 163193 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163193 Log: PR middle-end/45262 * fold-const.c (make_range) case NEGATE_EXPR: Punt if -a overflows. Normalize the range. * gcc.c-torture/execute/pr45262.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr45262.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45262
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #5 from schwab at linux-m68k dot org 2010-08-12 15:24 --- ISO/IEC 9899:1999, 6.9.1 Function definitions 9. Each parameter has automatic storage duration. Its identifier is an lvalue, which is in effect declared at the head of the compound statement that constitutes the function body (and therefore cannot be redeclared in the function body except in an enclosed block). *The layout of the storage for parameters is unspecified.* -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug middle-end/45262] [4.2/4.3/4.4/4.5/4.6 Regression] Optimization results in wrong result on expression x31||(-x)31
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-12 15:25 --- Subject: Bug 45262 Author: jakub Date: Thu Aug 12 15:25:08 2010 New Revision: 163194 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163194 Log: PR middle-end/45262 * fold-const.c (make_range) case NEGATE_EXPR: Punt if -a overflows. Normalize the range. * gcc.c-torture/execute/pr45262.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr45262.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/fold-const.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45262
[Bug middle-end/45262] [4.2/4.3/4.4/4.5/4.6 Regression] Optimization results in wrong result on expression x31||(-x)31
--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-12 15:28 --- Subject: Bug 45262 Author: jakub Date: Thu Aug 12 15:28:40 2010 New Revision: 163195 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163195 Log: PR middle-end/45262 * fold-const.c (make_range) case NEGATE_EXPR: Punt if -a overflows. Normalize the range. * gcc.c-torture/execute/pr45262.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr45262.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/fold-const.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45262
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #6 from rogerio at rilhas dot com 2010-08-12 15:33 --- (In reply to comment #4) Pretty please, before filing further bugs take time and learn C. The pointer subtraction triggers undefined behavior, because one pointer points to one object and the other pointer points to different object. Pretty pretty please: before you give out such wrong and embarassing answers please take the time to learn the standards and also take the time to learn how to read. I'm subtracting 2 pointers of the same type. If you knew how to read you would have seen that p1 and p2 are of the same type. Or maybe you just don't know C, but I'm sure you can learn it so that you can be helpful to the GCC team and not waste my time. See ISO C99, 6.5.6/9. I did read it, but it is not the case here, you got it wrong. In particular, in this testcase the functions are inlined Where did you get that idea from??? They are not inlined, you are wrong, check the assembler before imagining what is hapening. and thus i and strp are just normal automatic variables in main, obviously nothing guarantees how they are laid out in the stack. Wrong, you should learn your C. You could have understood this by yourself if you realized that i works but 10 doesn't. If you knew your basic C you would know that both strp and i were passed by value, and so they are not the original in the main but instead copies in bug_example. I'm sure you would want it not to be so, to save face, but you said it now you're stuck with it. But even if it isn't inlined, the behavior would be undefined. Wrong again. Undefined by C99 but not undefined by cdecl. I didn't specify inline, so GCC should have made cdecl. If it didn't then GCC should not claim to be cdecl. So choose: is it GCC's bug possibility 1 or possibility 2? (is it really that easy for you to write such wrong answers for everyone to see and keep wasting my time like this??? ... do you think that helps GCC?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #7 from rogerio at rilhas dot com 2010-08-12 15:33 --- (In reply to comment #5) ISO/IEC 9899:1999, 6.9.1 Function definitions 9. Each parameter has automatic storage duration. Its identifier is an lvalue, which is in effect declared at the head of the compound statement that constitutes the function body (and therefore cannot be redeclared in the function body except in an enclosed block). *The layout of the storage for parameters is unspecified.* Wrong again. Undefined by C99 but not undefined by cdecl. So choose: is it GCC's bug possibility 1 or possibility 2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug middle-end/45266] New: [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90
On Linux/x86-64, revision 163191 gave FAIL: gfortran.dg/array_memcpy_3.f90 -O scan-tree-dump-times original memcpy|(ref-all.*ref-all) 2 FAIL: gfortran.dg/array_memcpy_3.f90 -O scan-tree-dump-times original memcpy|(ref-all.*ref-all) 2 Revision 163187 is OK. This may be caused by revision 163189: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00400.html Linux/ia32 doesn't have this regression. -- Summary: [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45266
[Bug testsuite/45266] [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-12 15:46 --- The pattern doesn't match even though I see two memcpy calls!? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |testsuite Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45266
[Bug middle-end/45266] [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-12 15:48 ---
(In reply to comment #1)
The pattern doesn't match even though I see two memcpy calls!?
I am using
# make RUNTESTFLAGS=--target_board 'unix{-m32,}' check
2 failures are 1 for 64bit and 1 for 32bit.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Component|testsuite |middle-end
Target Milestone|4.6.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45266
[Bug testsuite/45266] [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-12 15:50 --- I see the fails, but the pattern should still match. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |testsuite Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-12 15:50:34 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45266
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #8 from redi at gcc dot gnu dot org 2010-08-12 15:52 --- (In reply to comment #6) (In reply to comment #4) Pretty please, before filing further bugs take time and learn C. The pointer subtraction triggers undefined behavior, because one pointer points to one object and the other pointer points to different object. Pretty pretty please: before you give out such wrong and embarassing answers please take the time to learn the standards and also take the time to learn how to read. Bravo, well trolled. I'm subtracting 2 pointers of the same type. If you knew how to read you would have seen that p1 and p2 are of the same type. Or maybe you just don't know C, but I'm sure you can learn it so that you can be helpful to the GCC team and not waste my time. Please stop trying to use GCC, we'll all be better off. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #9 from schwab at linux-m68k dot org 2010-08-12 15:52 --- The parameters contain copies of the argument values (6.9.1#10: as if by assignment). The address of a parameter has no meaning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #10 from matz at gcc dot gnu dot org 2010-08-12 16:00 --- Ahh, it's just so entertaining. C99 is a language, cdecl a calling convention. There is no 'cdecl compiler', it makes no sense to speak about such a thing. cdecl is a calling convention for function written in all kinds of languages. If you chose to program in C (and you claim you do), then you have to work by the rules the relevant language standard imposes on you. It has been shown multiple times to you (and you even agree), that what you do is outside of C99. Countering this with but it should still work, because 'cdecl' says so is invalid reasoning, a calling convention can't override any limitation the language standard imposes. What you want to program in is not C99 (or any C whatsoever), but rather Microsofts idea of what a language looking similar to C might look like-C. GCC makes no claim to support such language. It supports C99, and it supports the cdecl calling convention. It does not support the language that you think is C, but isn't. It might be conceivable that somebody implements a new language frontend for GCC that would support the Microsoft language without name, as long as that isn't the case (and you yourself aren't interested in developing such frontend) the bug reports remain invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #11 from rogerio at rilhas dot com 2010-08-12 16:04 --- (In reply to comment #8) (In reply to comment #6) (In reply to comment #4) Pretty please, before filing further bugs take time and learn C. The pointer subtraction triggers undefined behavior, because one pointer points to one object and the other pointer points to different object. Pretty pretty please: before you give out such wrong and embarassing answers please take the time to learn the standards and also take the time to learn how to read. Bravo, well trolled. I'm subtracting 2 pointers of the same type. If you knew how to read you would have seen that p1 and p2 are of the same type. Or maybe you just don't know C, but I'm sure you can learn it so that you can be helpful to the GCC team and not waste my time. Please stop trying to use GCC, we'll all be better off. Oh and that will make your colleague Jakub right about p1 and p2 be of diferent types? Does it make his answer intelligent? Sure, whatever you say, I'll follow your recommendation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #12 from redi at gcc dot gnu dot org 2010-08-12 16:09 --- Seriously, go away. I'll get far ruder if you're going to open bug reports worded like this: (In reply to comment #0) Don't bother trying to understand why I need the operand to work as stated in C99, or why I need the code to be cdecl compliant, that is too complicated for you and it would just confuse you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-08-12 16:09 --- diferent types? He did not say different types but different objects. There is a difference between objects and types. This comes down to: a - b being undefined in C90/C99/C++98/C++03/C++0x because a and b are two different objects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #14 from jakub at gcc dot gnu dot org 2010-08-12 16:11 --- I never claimed p1 and p2 have different types. They have the same type. But the standard paragraph I mentioned says: When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object That is not the case in your testcase, strp and i are different objects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #15 from rogerio at rilhas dot com 2010-08-12 16:15 --- (In reply to comment #14) I never claimed p1 and p2 have different types. They have the same type. But the standard paragraph I mentioned says: When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object That is not the case in your testcase, strp and i are different objects. char* p1=random_address(); char* p2=another_random_address(); p1-p2 is always well defined, no matter to which objects they point to. After the subtracion they will point to objects of the same type (char's). So, you don't know your C nor C99 (we are reading it wrong). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug middle-end/45267] New: [4.5 regression] inlining fails with -m32
My code, which previously compiled with GCC 4.3 and 4.4 with -m32 as well as
for 64 bit, fails to compile with GCC 4.5.[01] when compiling for 32 bit
(-m32).
I tried to reduce the problem to a minimal testcase and arrived at this:
typedef int __v4si __attribute__ ((__vector_size__ (16)));
typedef long long __v2di __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_set_epi32 (int __q3, int __q2, int __q1, int __q0)
{
return __extension__ (__m128i)(__v4si){ __q0, __q1, __q2, __q3 };
}
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_set1_epi32 (int __A)
{
return _mm_set_epi32 (__A, __A, __A, __A);
}
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_cmpeq_epi32 (__m128i __A, __m128i __B)
{
return (__m128i)__builtin_ia32_pcmpeqd128 ((__v4si)__A, (__v4si)__B);
}
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_slli_epi32 (__m128i __A, int __B)
{
return (__m128i)__builtin_ia32_pslldi128 ((__v4si)__A, __B);
}
extern __inline int __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_testc_si128 (__m128i __M, __m128i __V)
{
return __builtin_ia32_ptestc128 ((__v2di)__M, (__v2di)__V);
}
templatetypename T
class Vector
{
public:
inline Vector(__m128i x) : d(x) {}
inline Vector(T a) : d(_mm_set1_epi32(a)) {}
inline VectorT operator(int x) const
__attribute__((always_inline));
inline bool operator==(const VectorT x) const
{
return !_mm_testc_si128(_mm_cmpeq_epi32(d, x.d),
_mm_set1_epi32(0xu));
}
private:
__m128i d;
};
template inline Vectorint Vectorint::operator(int x) const
{
return _mm_slli_epi32(d, x);
}
templatetypename T1, typename M inline void foo(const T1 , const M ) {}
class Fail {};
int main()
{
Vectorint a(1);
if ((a 2) == (a 2)) {
foo(a 2, (a 2) == (a 2));
throw Fail();
}
return 0;
}
g++ -m32 -O3 -Wall -march=core2 -msse4 -ansi -o arithmetics arithmetics.cpp
arithmetics.cpp: In function #8216;int main()#8217;:
arithmetics.cpp:47:31: sorry, unimplemented: inlining failed in call to
#8216;VectorT VectorT::operator(int) const [with T = int]#8217;: call
is unlikely and code size would grow
arithmetics.cpp:59:40: sorry, unimplemented: called from here
arithmetics.cpp:47:31: sorry, unimplemented: inlining failed in call to
#8216;VectorT VectorT::operator(int) const [with T = int]#8217;: call
is unlikely and code size would grow
arithmetics.cpp:59:40: sorry, unimplemented: called from here
arithmetics.cpp:47:31: sorry, unimplemented: inlining failed in call to
#8216;VectorT VectorT::operator(int) const [with T = int]#8217;: call
is unlikely and code size would grow
arithmetics.cpp:59:41: sorry, unimplemented: called from here
--
Summary: [4.5 regression] inlining fails with -m32
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kretz at kde dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45267
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #16 from redi at gcc dot gnu dot org 2010-08-12 16:17 --- (In reply to comment #15) char* p1=random_address(); char* p2=another_random_address(); p1-p2 is always well defined, no matter to which objects they point to. No. No it isn't. It really isn't. (In reply to comment #6) Pretty pretty please: before you give out such wrong and embarassing answers please take the time to learn the standards and also take the time to learn how to read. Maybe you should practice what you preach. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #17 from rogerio at rilhas dot com 2010-08-12 16:18 --- (In reply to comment #12) Seriously, go away. I'll get far ruder if you're going to open bug reports worded like this: (In reply to comment #0) Don't bother trying to understand why I need the operand to work as stated in C99, or why I need the code to be cdecl compliant, that is too complicated for you and it would just confuse you. ... o... now you got me scared. I will just go away before you call me C-ignorant or something really insightful like that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #18 from rogerio at rilhas dot com 2010-08-12 16:18 --- You know what? I did a small sample showing this bug to other people. They all understood it, but not you. They all know what it means C99+cdecl at the same time. You don't. I'm surprised at your lack of capacity for uderstanding. Well, as long as you are proud of yourselves then that is what really matters, right? Good luck with that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #19 from redi at gcc dot gnu dot org 2010-08-12 16:20 --- Everyone understands it, you're just wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug middle-end/45266] [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-12 16:44 --- I was wrong. Linux/ia32 has the same regression: FAIL: gfortran.dg/array_memcpy_3.f90 -O scan-tree-dump-times original memcpy|(ref-all.*ref-all) 2 -- hjl dot tools at gmail dot com changed: What|Removed |Added Component|testsuite |middle-end Target Milestone|4.6.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45266
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #20 from dj at redhat dot com 2010-08-12 16:57 --- Just for fun, I compiled this test case with various levels of optimization. It works fine without optimization or with -O1, but segfaults at -O2 or -O3. That indicates that the program only works by coincidence, not by design - you've made assumptions about how GCC will interpret your sources, and those assumptions are wrong. In this case, your assumption is that bug_example_2 will always be a separate function, and will always be called as a separate function, and thus that you can assume some knowledge of the internals of the stack layout. The C language does *not* require that a function which is called, be called as a separate function, only that the semantics of the call be the same as far as the C language requires. The C language allows GCC to implement that function call in any way it chooses - and GCC chooses to implement it without actually doing a function call, but by copying the function body to the callee. At least, it does when optimizing. Without optimization, it *happens* to do what you expect. It will also do what you expect if bug_example_2 and bug_example are in separate source files - *then* the cdecl standard you refer to applies, because cross-object calls are limited by the compatibility standards. However - if you use gcc to link as well, gcc has the option of optimizing those calls *also*. So, GCC is cdecl compliant because *if* there's a function call, *then* the *stack* is laid out the same. However, the cdecl standard does *not* require that your program work, because C allows the optimizer to avoid the actual function call completely when the callee and caller are in the same scope. Note: you can tell gcc to not inline a function with __attribute__((noinline)) in which case a call to it is always an actual call to it, but it would be easier to just use the standard methods for accessing parameters so that it *always* works. Also, with full optimization enabled, your code crashes with MSVC also. Please file a bug report with Microsoft. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #21 from froydnj at gcc dot gnu dot org 2010-08-12 17:08 --- Even without optimization (as the compilation script uses), the program crashes. To be concrete about what's going wrong based on what the assembly code actually looks like (GCC version Ubuntu 4.4.3-4ubuntu5): bug_example: pushl%ebp movl%esp, %ebp subl$1048, %esp # space for buffer movl8(%ebp), %eax # move string elsewhere movl%eax, -1020(%ebp) movl%gs:20, %eax# stuff for stack checking movl%eax, -12(%ebp) xorl%eax, %eax movb$0, -1012(%ebp) leal12(%ebp), %eax # address of i to stack movl%eax, 4(%esp) leal-1020(%ebp), %eax # address of (copied) strp to stack movl%eax, (%esp) callbug_example_2 movl-12(%ebp), %eax xorl%gs:20, %eax je.L6 call__stack_chk_fail .L6: leave ret .sizebug_example, .-bug_example You are assuming that in `bug_example' that the parameters passed to `bug_example_2' must be the addresses of those variables *as they were passed on the stack*. This is certainly one way of implementing it, but it is not mandated by the standard (as comment #9 points out). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #22 from rogerio at rilhas dot com 2010-08-12 17:24 --- (In reply to comment #21) Even without optimization (as the compilation script uses), the program crashes. Right, that was the point of introducing the 1000-character buffer. With it it crashes always. To be concrete about what's going wrong based on what the assembly code actually looks like (GCC version Ubuntu 4.4.3-4ubuntu5): bug_example: pushl%ebp movl%esp, %ebp subl$1048, %esp # space for buffer movl8(%ebp), %eax # move string elsewhere movl%eax, -1020(%ebp) movl%gs:20, %eax# stuff for stack checking movl%eax, -12(%ebp) xorl%eax, %eax movb$0, -1012(%ebp) leal12(%ebp), %eax # address of i to stack movl%eax, 4(%esp) leal-1020(%ebp), %eax # address of (copied) strp to stack movl%eax, (%esp) callbug_example_2 movl-12(%ebp), %eax xorl%gs:20, %eax je.L6 call__stack_chk_fail .L6: leave ret .sizebug_example, .-bug_example You are assuming that in `bug_example' that the parameters passed to `bug_example_2' must be the addresses of those variables *as they were passed on the stack*. This is certainly one way of implementing it, but it is not mandated by the standard (as comment #9 points out). You are absolutelly right, I fully agree that a non-cdecl conformant GCC would not need to pass parameters on the stack. It only has to pass parameters on the stack (in a very well-defined way) if it claims to be cdecl-compliant. But even with the cdecl specifier in the source the generated assembly code is wrong. Hence a bug. Hadn't you realized yet that that is my point from the start -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #23 from rogerio at rilhas dot com 2010-08-12 17:25 --- (In reply to comment #19) Everyone understands it, you're just wrong. No I'm not, the problem seems to be just to complex for you because you would have to tie up C99+cdecl to understand, but you don't understand it because you don't know cdecl language (this still makes me laugh!) and so you don't get out of your little C99 box (which makes you lose sight of the big picture). char* p1=random_address(); char* p2=another_random_address(); Any compiler that does not predictably compute p2-p1 is a piece of crap. You can twist C99 all you want, but whenever p2-p1 is left to some undefined criteria of the compiler then it is just an absolute piece of crap. Period. That is why no compiler leaves this indefined, even GCC (apparently it was just luck). This should be enough for you to see you are not getting C99 right, because following what you say would create crappy compilers. Feel free to try and prove they would not be crappy. Even if you could convince me of your interpretation of C99 and p2-p1 were not well defined, you would still have to explain why strp is not 4 bytes before i (not subtracting, just looking at their disassembled addresses). This is the big picture that you do not understand, you just keep deflecting. ... while we discuss GCC still doesn't return the correct address for strp. So, let me just summarize by saying I was so so so so wrong to expect GCC to have returned the address that my little brain expected to result from the combination C99+cdecl. Of course I was wrong and you were right, which makes me stupit and you smart. Meanwhile everyone else knows that if it compiles in GCC and executes correctly then it compiles and executes correctly in any other compiler... can you deduce why? Does it make you proud? ... hint: which do you think is the compiler with the most reduced capabilities that serves as a baseline for your code? Would you like to keep GCC at this low end of the spectrum? Good, just keep on insisting on your interpretation of C99. http://en.wikipedia.org/wiki/GNU_Compiler_Collection In 2007, GCC received criticism from one OpenBSD developer who complained that GCC is mostly developed by companies, that it is large, buggy, slow, and that it generates poor code,[31][not in citation given][32] and who also dislike v3 of the GNU GPL.[33] The OpenBSD project and FreeBSD projects, respectively, are experimenting with replacing GCC with the Portable C Compiler[33] and Clang/LLVM.[34] The NetBSD and DragonFlyBSD projects have commented that on replacing GCC, they have explored various compiler replacements but have no solid answers.[35] (I've checked the references, they are fine!!) Does it have anything to do that you dismiss people who find and show you bugs? Maybe you do a good job when you quickly send them away after stamping it with non-conformant, I don't know, but I expected a little more interest on your part to make GCC better. I would be open to anything, including something along the lines of ok, it is not a bug, but we will consider this as a feature request... but not even that. I'll come back some day (be afraid!! :-) ) with a list of compilers tested to see how many produce correct results for this bug report. For now in 4 compilers tested (2 from Microsoft) 3 of them do the job correctly and GCC is the only one that doesn't. Oopss...! I meant: GCC is the only one to have correctly interpreted C99, the other 3 got it wrong and let me get the addresses of the parameters as I wrongfully expected. And let me subtract them predictably. This surelly proves you are very insightfull and that you know C99 better than anyone else. Gone, sorry for any inconvenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #24 from rogerio at rilhas dot com 2010-08-12 17:50 --- (In reply to comment #20) I couldn't resist to comming back (you respond very quickly, kudos!, I'm not used to that! :-) Just for fun, I compiled this test case with various levels of optimization. It works fine without optimization or with -O1, but segfaults at -O2 or -O3. The script I sent you does not request optimizations and segfaults. That indicates that the program only works by coincidence, not by design - you've made assumptions about how GCC will interpret your sources, and those assumptions are wrong. In this case, your assumption is that bug_example_2 will always be a separate function, and will always be called as a separate function, and thus that you can assume some knowledge of the internals of the stack layout. When I don«t request optimizations my interpretation is right. A function declaration (that doesn't specifically request inline) is a function. I don't know if C99 says it (probably does, in a C-sense function), but cdecl does. The C language does *not* require that a function which is called, be called as a separate function, only that the semantics of the call be the same as far as the C language requires. The C language allows GCC to implement that function call in any way it chooses - and GCC chooses to implement it without actually doing a function call, but by copying the function body to the callee. At least, it does when optimizing. Without optimization, it *happens* to do what you expect. Compile it like I did in the script (without optimizations) and see it fail. It will also do what you expect if bug_example_2 and bug_example are in separate source files - *then* the cdecl standard you refer to applies, because cross-object calls are limited by the compatibility standards. However - if you use gcc to link as well, gcc has the option of optimizing those calls *also*. So, GCC is cdecl compliant because *if* there's a function call, *then* the *stack* is laid out the same. However, the cdecl standard does *not* require that your program work, because C allows the optimizer to avoid the actual function call completely when the callee and caller are in the same scope. Incorrect, code should not be optimized if I don't request it. If I do I have to live without cdecl compliance, obviously, as I don't know of any compiler that has an option like optimize_as_possible_but_keep_cdecl_always. My point is for non-optimized code, and that is why I included the scrip I used to build it. Note: you can tell gcc to not inline a function with __attribute__((noinline)) in which case a call to it is always an actual call to it, but it would be easier to just use the standard methods for accessing parameters so that it *always* works. Agreed. But I'm determining the addresses of the parameters just to check GCC's conformity, remember? So don't you worry about how easy the code is for me, I will deal with that. I just tried the attribute and didn't make any difference in the code, and is still not cdecl. I'm sure it is not a bug in GCC though... Also, with full optimization enabled, your code crashes with MSVC also. Right. As explained, this bug report is about non-optimized code. I also didn't expect Microsoft's code to not crash if optimized (nor tried it until your comment). I don't think I ever mentioned optimizations in this bug report, I did it in the variable parameters bug report bucause that was how I initially got it to crash and had no way to report it to you (it crashed without optimizations in a larger program that I could not send to you), but I later sent you a full report (with snapshots and all in comment #51) a non-optimized version that crashed. Here I could easilly show it to crash when not optimized, and so I could live with disabling optimizations to get the addresses to be returned properly. Please file a bug report with Microsoft. No need. Their code *NEVER* crashes if I don't request optimizations. This is it, I must resist! Bye!! :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug target/45264] Stack corruption with any function using frame
--- Comment #2 from darkdragon2000 at hotmail dot com 2010-08-12 17:52 --- It's not a bug in the handler since when the interrupt fires at the point when the stack pointer is invalid (right after 0x50c), the program counter gets pushed onto the stack, which is an invalid location. When I tried to submit a report with the vendor, they pointed me back here. Maybe this should go to AVRLiBC? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #25 from redi at gcc dot gnu dot org 2010-08-12 17:53 --- (In reply to comment #23) Maybe you do a good job when you quickly send them away after stamping it with non-conformant, I don't know, but I expected a little more interest on your part to make GCC better. I would be open to anything, including something along the lines of ok, it is not a bug, but we will consider this as a feature request... but not even that. You opened this bug report with insults, what sort of response do you expect? GCC is too crappy and amateur for your awesome code, so I suggest you stick to better compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #26 from rogerio at rilhas dot com 2010-08-12 18:04 --- You opened this bug report with insults, what sort of response do you expect? GCC is too crappy and amateur for your awesome code, so I suggest you stick to better compilers. Will do, thanks. ... and sorry for my opening lines, I was very pissed off that after a great deal of work making a full report you didn't see that problem was not related to the variable arguments and it seemed to me that you were not even bothering to to read it, and kept dismissing me as trying to do non-conformat things. That is what motivated me to isolate the problem for this bug report, and I am sorry I was unable to put on a happy face, my bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #27 from matz at gcc dot gnu dot org 2010-08-12 18:05 --- Oh, this fun. Enjoyable, really! ;-) So, you admit that MSVC does in fact miscompile your perfectly fine cdecl code, if you request optimization from it? How bad is that of them? Terrible! I would consider creating a bug report with them, because if they miscompile your code with optimizations it must surely be their bug. After all optimization is a process of transforming a valid program into another program that behaves exactly the same, hence if they optimize your valid program into a crasher, what else could it be than a bug in their compiler? I mean, really. They are supposed to provide a commercial grade compiler. How can it be that they force you to deactivate optimization options (and hence live with slow runtime) just so that your valid cdecl program doesn't crash? One side remark about your p2-p1 claim: char* p1=random_address(); char* p2=another_random_address(); Any compiler that does not predictably compute p2-p1 is a piece of crap. You can twist C99 all you want, but whenever p2-p1 is left to some undefined criteria of the compiler then it is just an absolute piece of crap. Period. You obviously never used segmented platforms (old DOS was such a thing, but there are others more recent, e.g. Cell with PowerPC is similar in this respect). On those it was valid only to sunstract pointers from each other when they pointed into the same segment. Because the pointer difference type was a 16 bit type, whereas the pointers could address 1MB of memory (hence effectively 20 bit). If you do the math you'll see that it's impossible to map all 2^20 possible differences between pointers (unsigned 2-completement 20-bit arithmetic, otherwise 2^21 differences) into just 16 bit. So yes, on those platforms it really was impossible to substract two arbitrary pointers. C (the language) reflects such constraints. With complete trust in your incapability to grok these concepts. but hats off to a capable troll, Michael. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #28 from dj at redhat dot com 2010-08-12 18:08 --- I built your test case with gcc and g++ without optimizations, and it worked fine. I could only get it to fail with gcc/g++ by optimizing, but then, I could get it to fail with MSVC by optimizing. Seems to me, gcc and MSVC are doing the same thing, or you have some modified version of gcc that is not acting the same way as the official version. Also, please provide an official spec for this cdecl you keep referring to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug testsuite/45266] [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-08-12 18:16 --- Pls don't change back bug attributes all the time... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |testsuite Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45266
[Bug middle-end/45267] [4.5 regression] inlining fails with -m32
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45267
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #29 from rogerio at rilhas dot com 2010-08-12 18:24 --- (In reply to comment #27) Oh, this fun. Enjoyable, really! ;-) Again I couldn't resist! Everytime I'm ready to go away you say something shocking that I simply can«t resist. Its time for me to admit I have a problem! :-) So, you admit that MSVC does in fact miscompile your perfectly fine cdecl code, if you request optimization from it? Yes. How bad is that of them? Not perfect, but still better than GCC, because at least I can get it to work. Terrible! ... n... that's just your jealousy talking because you can't even begin to understand how to make a temporary variable an l-value... how can someone be defending a compiler that never conforms (GCC) to one that conforms if I don't request it to optimize? That's just bad logic. It's not my intention to insult you, but the observation itself lacks any underlying logic. I would consider creating a bug report with them, because if they miscompile your code with optimizations it must surely be their bug. No, optimizations take away room for assumptions. That's why GCC can optimize for(i=0; istrlen(sp); i++). What??? GCC didn't call strlen() every time? How stupid! No, you are just lacking logic. Drink something with vitamins and get out more, it will do you good. After all optimization is a process of transforming a valid program into another program that behaves exactly the same, hence if they optimize your valid program into a crasher, what else could it be than a bug in their compiler? Read my strlen() example. That shows you are wrong. You invented that definition, you can't really back it up otherwise strlen() would have to be called every time. I mean, really. They are supposed to provide a commercial grade compiler. How can it be that they force you to deactivate optimization options (and hence live with slow runtime) just so that your valid cdecl program doesn't crash? Yup, money can only buy so much. No money can buy you alittle bit less. One side remark about your p2-p1 claim: char* p1=random_address(); char* p2=another_random_address(); Any compiler that does not predictably compute p2-p1 is a piece of crap. You can twist C99 all you want, but whenever p2-p1 is left to some undefined criteria of the compiler then it is just an absolute piece of crap. Period. You obviously never used segmented platforms (old DOS was such a thing, but there are others more recent, e.g. Cell with PowerPC is similar in this respect). Yes I did work with those platforms. Remember the far qualifiers? Remember what they were for? They were invented to make you, again, write something wrong. However, as parameters to functions, they were always in the same segment, so the subtraction was always valid. C99 cannot back this up though, it was just the way things were made back then. Maybe GCC inherited too much from those days. On those it was valid only to sunstract pointers from each other when they pointed into the same segment. Not really, you could always subtract. However, far pointers gave predictable addresses, just like C99 says they pointer arithmetic should. Go and read C99 about the far qualifier so that you can see why it was not smart of you to talk about DOS. Still, on every segmented platform, the subtraction of the addresses of parameters is always valid, as parameter will be all placed on the same stack. And if some parameters had far qualifies and other not then the compilers would warn you about it so that you could requalify them. Don't talk about what you don't know, you clearly know much less about the old days than me. Stick to C99. Because the pointer difference type was a 16 bit type, whereas the pointers could address 1MB of memory (hence effectively 20 bit). If you do the math you'll see that it's impossible to map all 2^20 possible differences between pointers (unsigned 2-completement 20-bit arithmetic, otherwise 2^21 differences) into just 16 bit. So yes, on those platforms it really was impossible to substract two arbitrary pointers. No. Pointers of the same type, with the same qualifiers, were always subtractable. Don't invent, it will just make you wrong. The addresses of parameters on the stack would always be near (16-bit), so subtraction would always be well-defined. C (the language) reflects such constraints. Not really, no. Or can you back up your claims with an old standard applycable 30 or 40 years ago? I'm sure you can't. I don't even know if cdecl was well defined back then, do you? With complete trust in your incapability to grok these concepts. but hats off to a capable troll, Michael. Its is amazing how foast you take your self out and crash head-on into a wall. And be proud of it. But you are right, this is fun. Keep on sending your errors, inventions, inconsistencies, and mistakes, and I'll keep on correcting them. Then you deflect and try to pretend that you said smart
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #30 from pinskia at gcc dot gnu dot org 2010-08-12 18:27 --- you can't even begin to understand how to make a temporary variable an l-value. Please look up move constructors and rvalue references. move constructors are not standard C++ code but the C++ standard committee decided to add rvalue references instead. Please read the history of those and then come back when you understand what you are talking about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #31 from rogerio at rilhas dot com 2010-08-12 18:32 --- (In reply to comment #28) I built your test case with gcc and g++ without optimizations, and it worked fine. Just like my script? I noticed that I'm using a not-the-newest GCC version, and I know that some older version 3.xxx didn't have the problem (a few years ago). Maybe it is something changed in the most recent versions? I could only get it to fail with gcc/g++ by optimizing, but then, I could get it to fail with MSVC by optimizing. Seems to me, gcc and MSVC are doing the same thing, or you have some modified version of gcc that is not acting the same way as the official version. I'm sorry, but I'm new to Linux, I'm not sure if the GCC I'm using got tweaked in any way. It came with Ubuntu, but I don't know if it got upgraded with Code::Blocks. I thought that -save-temps would provide you with that information, didn't it? How can I get such information? Also, please provide an official spec for this cdecl you keep referring to. Sorry, I did send you one in my variable arguments report and I forgot to send it here olso. http://sco.com./developers/devspecs/abi386-4.pdf, see Figure 3-48: C Stack Frame. It is not a standard, as I'm sure you know, but it is a well-defined concept. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #32 from rogerio at rilhas dot com 2010-08-12 18:38 --- (In reply to comment #30) you can't even begin to understand how to make a temporary variable an l-value. Please look up move constructors and rvalue references. move constructors are not standard C++ code but the C++ standard committee decided to add rvalue references instead. Please read the history of those and then come back when you understand what you are talking about. If I were to follow your logic I would, because acording to your logic a parameter doesn't have an address. But C99 doesn't limit this in any way, does it? The get the address of the item, period. So I don't need to go look up unrelated topics, you are the one who should look up address of parameter. function(class_name(initializer)) ... should work if class_name(initializer) were an lvalue. One of you posted a standard for that. Microsoft can get the address of class_name(initializer), hence Microsft is capable of looking at class_name(initializer) as an l-value. How Microsoft does it is not important, they do it and GCC doesn't. So Microsoft can compile all these equivalently: int a=10; function(i) function(int(20)) function(class_name(initializer)) I don't really care what GCC could do to make class_name(initializer) an l-value, but if move constructors are a good way to go at it then do it. As C99 doesn't specify this GCC is happy and doesn't need the feel to change. And, so, I don't call it a bug, just a very nice feature that it is missing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c/45268] New: CPU2006 458.sjeng: type mismatch in array reference with -fwhole-program -combine
458.sjeng compilation fails with the following config options: ( fails with gcc4.6, passes with gcc4.4, gcc4.5 not tested yet) 458.sjeng=peak=default: ONESTEP = yes COPTIMIZE = -fwhole-program -combine -march=amdfam10 -m64 PORTABILITY = -DSPEC_CPU_LP64 feedback = 0 Here is the message: specmake build 2 make.err | tee make.out /usr/local/bin/gcc -DSPEC_CPU -DNDEBUG -fwhole-program -combine -march=amdfam10 -m64 -DSPEC_CPU_LP64 attacks.c book.c crazy.c draw.c ecache.c epd.c eval.c leval.c moves.c neval.c partner.c proof.c rcfile.c search.c see.c seval.c sjeng.c ttable.c utils.c -o sjeng sjeng.c: In function 'main': sjeng.c:75:5: error: type mismatch in array reference struct move_x struct move_x game_history_x[move_number.324] = path_x[0]; sjeng.c:75:5: error: type mismatch in array reference struct move_x struct move_x game_history_x[move_number.390] = path_x[0]; sjeng.c:75:5: error: type mismatch in array reference struct move_x struct move_x path_x[0] = game_history_x[move_number.428]; sjeng.c:75:5: error: type mismatch in array reference struct move_x struct move_x path_x[0] = game_history_x[move_number.435]; sjeng.c:75:5: error: type mismatch in array reference struct move_x struct move_x path_x[0] = game_history_x[move_number.439]; sjeng.c:75:5: internal compiler error: verify_gimple failed -- Summary: CPU2006 458.sjeng: type mismatch in array reference with -fwhole-program -combine Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: changpeng dot fang at amd dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45268
[Bug c/45268] CPU2006 458.sjeng: type mismatch in array reference with -fwhole-program -combine
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-12 18:47 --- -combine is known to be broken with respect of the type checker in both 4.5 and 4.6 (though it does not ICE when you turn off checking). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45268
[Bug c/45268] CPU2006 458.sjeng: type mismatch in array reference with -fwhole-program -combine
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-12 18:50 --- -combine is obsolete, use LTO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45268
[Bug c++/45269] New: CPU2006 450.soplex: verify_cgraph_node failed with -fprofile-generate
With gcc 4.6 on X86, 450.soplex ICE with -fprofile-generate in spxmpsread.cc: g++ -c -o spxmpsread.o -DSPEC_CPU -DNDEBUG-fprofile-generate -O2 -m64 -DSPEC_CPU_LP64 spxmpsread.cc spxmpsread.cc:678:1: error: Inline clone with address taken std::basic_ostream_CharT, _Traits std::endl(std::basic_ostream_CharT, _Traits) [with _CharT = char, _Traits = std::char_traitschar]/276(-1) @0x7fafaf623000 (asm: _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_) (inline copy in virtual bool soplex::SPxLP::readMPS(std::istream, soplex::NameSet*, soplex::NameSet*, soplex::DIdxSet*)/728) availability:local analyzed 71 time, 13 benefit (100 after inlining) 35 size, 4 benefit (75 after inlining) address_taken body local finalized inlinable called by: void soplex::_ZN6soplexL8readRowsERNS_8MPSInputERNS_8LPRowSetERNS_7NameSetE.constprop.9(soplex::MPSInput, soplex::LPRowSet, soplex::NameSet)/268 (0.01 per call) (inlined) (can throw external) calls: built-in/722 (0.01 per call) std::basic_ios_CharT, _Traits::char_type std::basic_ios_CharT, _Traits::widen(char) const [with _CharT = char, _Traits = std::char_traitschar, std::basic_ios_CharT, _Traits::char_type = char]/277 (inlined) (0.01 per call) (can throw external) std::basic_ostream_CharT, _Traits std::basic_ostream_CharT, _Traits::put(std::basic_ostream_CharT, _Traits::char_type) [with _CharT = char, _Traits = std::char_traitschar, std::basic_ostream_CharT, _Traits::char_type = char]/837 (0.01 per call) (can throw external) std::basic_ostream_CharT, _Traits std::basic_ostream_CharT, _Traits::flush() [with _CharT = char, _Traits = std::char_traitschar]/840 (0.01 per call) (can throw external) References: var:long int* __gcov_indirect_call_counters (read) var:void* __gcov_indirect_call_callee (read) var:long int *.LPBX1 [427] (write) var:void* __gcov_indirect_call_callee (write) var:long int *.LPBX1 [427] (read) var:long int *.LPBX1 [427] (write) var:long int *.LPBX1 [427] (read) var:long int *.LPBX1 [427] (write) var:long int *.LPBX1 [427] (read) var:long int *.LPBX1 [427] (write) var:long int *.LPBX1 [427] (read) Refering this function: fn:void soplex::_ZN6soplexL10readBoundsERNS_8MPSInputERNS_8LPColSetERNS_7NameSetEPNS_7DIdxSetE.constprop.13(soplex::MPSInput, soplex::LPColSet, soplex::NameSet, soplex::DIdxSet*)/595 (addr) fn:void soplex::_ZN6soplexL10readRangesERNS_8MPSInputERNS_8LPRowSetERNS_7NameSetE.constprop.12(soplex::MPSInput, soplex::LPRowSet, soplex::NameSet)/481 (addr) fn:void soplex::_ZN6soplexL7readRhsERNS_8MPSInputERNS_8LPRowSetERNS_7NameSetE.constprop.11(soplex::MPSInput, soplex::LPRowSet, soplex::NameSet)/260 (addr) fn:void soplex::_ZN6soplexL8readRowsERNS_8MPSInputERNS_8LPRowSetERNS_7NameSetE.constprop.9(soplex::MPSInput, soplex::LPRowSet, soplex::NameSet)/268 (addr) fn:void soplex::_ZN6soplexL8readNameERNS_8MPSInputE.constprop.7(soplex::MPSInput)/369 (addr) spxmpsread.cc:678:1: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions -- Summary: CPU2006 450.soplex: verify_cgraph_node failed with - fprofile-generate Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: changpeng dot fang at amd dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45269
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #33 from matz at gcc dot gnu dot org 2010-08-12 18:56 --- Don't talk about what you don't know, you clearly know much less about the old days than me. Well, I'll grant you that you know many wondrous and astounding facts, indeed. Let me just answer one random sentence out of your answer, just to keep it funny: Not really, you could always subtract. However, far pointers gave predictable addresses, just like C99 says they pointer arithmetic should. They didn't. If you subtracted far pointers that pointed into different segment, the segment difference was ignored. If you include real segmentation like on 80286, where there's no linear relationship between effective address and segment+offset, subtraction would have been prohibitively expensive to implement anyway. And you still wouldn't get around the size limitation of ptrdiff_t that was 16bit. And of course the subtraction of addresses of parameter is always meaningless in C, segmented or not, as pointed out multiple times. With or without cdecl. Or, another one: No, optimizations take away room for assumptions. Um, huh? That's completely backwards. Optimizations make _use_ of the assumptions/guarantees that the relevant standard gives you. Drink something with vitamins and get out more, it will do you good. That is certainly a good advise. I OTOH would advise you to possibly drink more alcohol. Much more. Really much much more. Go and read C99 about the far qualifier so that you can see why it was not smart of you to talk about DOS. C99 doesn't mention such qualifiers. I said that the restrictions in the standard (in this case which pointers can be compared/subtracted) have their reason in wanting to support all imaginable memory models. Nevertheless those restriction apply to _all_ implementations, even those that have trivial memory models, like a flat address space. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45269] CPU2006 450.soplex: verify_cgraph_node failed with -fprofile-generate
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-12 18:57 --- Probably related to PR44206. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||44206 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45269
[Bug c/45270] New: CPU2006 435.gromacs: Segmentation fault with -fprofile-generate
With gcc 4.6 on x86, 435.gromacs Segmentation fault with -fprofile-generate inconstr.c: gcc -c -DSPEC_CPU -DNDEBUG -I. -DHAVE_CONFIG_H -fprofile-generate -O2 -m64 -DSPEC_CPU_LP64 constr.c constr.c: In function âcount_constraintsâ: constr.c:624:5: internal compiler error: Segmentation fault -- Summary: CPU2006 435.gromacs: Segmentation fault with -fprofile- generate Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: changpeng dot fang at amd dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45270
[Bug middle-end/45267] [4.5 regression] inlining fails with -m32
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-12 19:09 --- It is fixed by revision 158732: http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00839.html on trunk. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-12 19:09:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45267
[Bug preprocessor/44836] Missing headers are always fatal
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-12 19:30 --- I believe mysql has been changed already not to rely on this. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44836
[Bug fortran/45271] New: [OOP] Polymorphic code breaks when changing order of USE statements
Hi, the attached code fails at runtime as follows: % ./a.out calling cg... cg: before g%assign Oops in concrete_vector::my_assign : wrong type Interchanging the indicated use statements in the main program leads to: % ./a.out calling cg... cg: before g%assign cg: after g%assign after cg... The code works flawlessly with nagfor 5.2, xlf 12.1 and xlf 13.1. Cheers, ha -- Summary: [OOP] Polymorphic code breaks when changing order of USE statements Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #1 from anlauf at gmx dot de 2010-08-12 19:56 --- Created an attachment (id=21471) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21471action=view) Demo code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
