Re: c++/linker problems maybe?
Marek, Your response is MOST helpful. THANK YOU! Regards, George... - Original Message - From: Marek Polacek pola...@redhat.com To: George R Goffe grgo...@yahoo.com Cc: gcc@gcc.gnu.org gcc@gcc.gnu.org Sent: Monday, August 5, 2013 10:16 PM Subject: Re: c++/linker problems maybe? On Mon, Aug 05, 2013 at 10:05:22PM -0700, George R Goffe wrote: Hi, I'm having trouble building or linking C++ code. Could one of you brains take a peek at the enclosed and let me know where I'm goofing please? This question is not appropriate for the mailing list gcc@gcc.gnu.org, which is for the development of GCC. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. [ 88%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3bthemedlabel.cpp.o [ 88%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3blsofwrapper.cpp.o [ 89%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3blsofwrapperdialog.cpp.o [ 89%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3baction.cpp.o [ 89%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3bdevicemenu.cpp.o [ 89%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3bviewcolumnadjuster.cpp.o [ 90%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3bmodelutils.cpp.o Linking CXX executable k3b CMakeFiles/k3b_bin.dir/k3b.cpp.o: In function `K3b::MainWindow::~MainWindow()': /tools/k3b/k3b/src/k3b.cpp:272: undefined reference to `KXmlGuiWindow::~KXmlGuiWindow(void const**)' CMakeFiles/k3b_bin.dir/k3b.cpp.o: In function `K3b::MainWindow::MainWindow()': /tools/k3b/k3b/src/k3b.cpp:227: undefined reference to `KXmlGuiWindow::KXmlGuiWindow(void const**, QWidget*, QFlagsQt::WindowType)' CMakeFiles/k3b_bin.dir/k3b.cpp.o: In function `K3b::MainWindow::MainWindow()': /tools/k3b/k3b/src/k3b.cpp:227: undefined reference to `KXmlGuiWindow::KXmlGuiWindow(void const**, QWidget*, QFlagsQt::WindowType)' CMakeFiles/k3b_bin.dir/k3b.cpp.o: In function `K3b::MainWindow::~MainWindow()': /tools/k3b/k3b/src/k3b.cpp:272: undefined reference to `KXmlGuiWindow::~KXmlGuiWindow(void const**)' collect2: error: ld returned 1 exit status make[2]: *** [src/k3b] Error 1 make[1]: *** [src/CMakeFiles/k3b_bin.dir/all] Error 2 make: *** [all] Error 2 It just seems the library containing the definition of KXmlGuiWindow::KXmlGuiWindow isn't properly linked in. Marek
Re: [RFC] gcc feature request: Moving blocks into sections
On Mon, 2013-08-05 at 11:49 -0700, Linus Torvalds wrote: Ugh. Why the crazy update_jump_label script stuff? After playing with the patches again, I now understand why I did that. It wasn't just for optimization. Currently the way jump labels work is that we use asm goto() and place a 5 byte nop in the assembly, with some labels. The location of the nop is stored in the __jump_table section. In order to use either 2 or 5 byte jumps, I had to put in the actual jump and let the assembler place the correct op code in. This changes the default switch for jump labels. Instead of being default off, it is now default on. To handle this, I had to convert all the jumps back to nops before the kernel runs. This was done at compile time with the update_jump_label script/program. Now, we can just do the update in early boot, but is this the best way? This means that the update must happen before any jump label is used. This may not be an issue, but as jump labels can be used for anything (not just tracing), it may be hard to know when the first instance is actually used. Also, if there is any issue with the op codes as Mathieu has been pointing out, it would only be caught at run time (boot time). The update_jump_label program isn't really that complex. Yes it parses the elf tables, but that's rather standard and that method is used by ftrace with the mcount locations (instead of that nasty daemon). It finds the __jump_table section and runs down the list of locations just like the boot up code does, and modifies the jumps to nops. If the compiler does something strange, it would be caught at compile time not boot time. Anyway, if you feel that update_jump_label is too complex, I can go the update at early boot route and see how that goes. -- Steve
i386 __atomic_compare_exchange_n not found
Hi all, I am form RTEMS org, recently we are working on atomic support for RTEMS. The C11 stdatomic.h has been ported to RTEMS. But when i build the atomic test case for pc686 BSP it will post some error like this : /home/rtems-build/i386-build/i386-rtems4.11/c/pc686/testsuites/smptests/smpatomic07/../../../../../pc686/lib/include/rtems/score/cpustdatomic.h:278: undefined reference to `__atomic_compare_exchange_4' /home/rtems-build/i386-build/i386-rtems4.11/c/pc686/testsuites/smptests/smpatomic07/../../../../../pc686/lib/include/rtems/score/cpustdatomic.h:278: undefined reference to `__atomic_compare_exchange_4' tasks.o: In function `_Atomic_Compare_exchange_ptr': /home/rtems-build/i386-build/i386-rtems4.11/c/pc686/testsuites/smptests/smpatomic07/../../../../../pc686/lib/include/rtems/score/cpustdatomic.h:290: undefined reference to `__atomic_compare_exchange_4' /home/rtems-build/i386-build/i386-rtems4.11/c/pc686/testsuites/smptests/smpatomic07/../../../../../pc686/lib/include/rtems/score/cpustdatomic.h:290: undefined reference to `__atomic_compare_exchange_4' tasks.o:/home/rtems-build/i386-build/i386-rtems4.11/c/pc686/testsuites/smptests/smpatomic07/../../../../../pc686/lib/include/rtems/score/cpustdatomic.h:290: more undefined references to `__atomic_compare_exchange_4' follow And i have found some mail list talking about gcc has remove lock free atomic int support [1][2], is this true? or just some error caused by my toolchain? I am waiting for your reply, Thank you! [1]. http://gcc.gnu.org/ml/gcc/2012-12/msg00079.html [2]. http://www.phoronix.com/scan.php?page=news_itempx=MTI1MDU WeiY Best Regards
Re: i386 __atomic_compare_exchange_n not found
On 6 August 2013 15:47, Deng Hengyi wrote: And i have found some mail list talking about gcc has remove lock free atomic int support [1][2], is this true? or just some error caused by my toolchain? I am waiting for your reply, Thank you! [1]. http://gcc.gnu.org/ml/gcc/2012-12/msg00079.html [2]. http://www.phoronix.com/scan.php?page=news_itempx=MTI1MDU No it's not true, you've misunderstood. There was a proposal to deprecate (not remove) i386 support, but it didn't happen. Even if it did happen, that wouldn't remove support for lock-free atomic ints, only i386 targets would be affected (not i486 or later), and they don't fully support lock-free atomic ints anyway.
Re: i386 __atomic_compare_exchange_n not found
Hi Jonathan, Thank you for your reply. And about the error i encounter, do you have any advice? maybe it is caused by my toolchain not install rightly? In the standard pc686 architecture(not cross compile on RTEMS) will it encounter the similar error? WeiY Best Regards 在 2013-8-6，下午11:25，Jonathan Wakely jwakely@gmail.com 写道： On 6 August 2013 15:47, Deng Hengyi wrote: And i have found some mail list talking about gcc has remove lock free atomic int support [1][2], is this true? or just some error caused by my toolchain? I am waiting for your reply, Thank you! [1]. http://gcc.gnu.org/ml/gcc/2012-12/msg00079.html [2]. http://www.phoronix.com/scan.php?page=news_itempx=MTI1MDU No it's not true, you've misunderstood. There was a proposal to deprecate (not remove) i386 support, but it didn't happen. Even if it did happen, that wouldn't remove support for lock-free atomic ints, only i386 targets would be affected (not i486 or later), and they don't fully support lock-free atomic ints anyway.
Re: Help with C++11 memory model on zSeries
On Mon, 2013-08-05 at 15:03 +0100, Richard Sandiford wrote: Sorry for the long mail and for what's probably an FAQ. I did try to find an answer without bothering the list... (and showing my ignorance so much :-)) At the moment, the s390 backend treats all atomic loads as simple loads and only uses serialisation instructions for atomic stores. I just wanted to check whether this was really the right behaviour. The architecture has strong memory-ordering semantics in which a CPU is only allowed to move a store after a later load; the other three combinations cannot happen. The current implementation seems fine from that point of view, because it means that a serialising instruction after a store is enough to prevent any reordering. However, page 5-126 of the architecture manual[*] says: Following is an example showing the effects of serialization. Location A initially contains FF hex. CPU 1 CPU 2 MVI A,X'00' GCLI A,X'00' BCR 15,0 BNE G The BCR 15,0 instruction executed by CPU 1 is a serializing instruction that ensures that the store by CPU 1 at location A is completed. However, CPU 2 may loop indefinitely, or until the next interruption on CPU 2, because CPU 2 may already have fetched from location A for every execution of the CLI instruction. A serializing instruction must be in the CPU-2 loop to ensure that CPU 2 will again fetch from location A. Does the new C/C++ memory model allow that kind of infinite loop even for sequentially-consistent atomic loads? The draft text was: [29.3.3] There shall be a single total order S on all memory_order_seq_cst operations, consistent with the “happens before” order and modification orders for all affected locations, such that each memory_order_seq_cst operation that loads a value observes either the last preceding modification according to this order S, or the result of an operation that is not memory_order_seq_cst. but when I asked around, noone could see anything in the standard that prevents the total order from having an infinite sequence of loads between two stores. That feels like a cheat though. :-) It would be a correct execution in terms of the allowed orderings, I think. What you're asking about is a forward progress guarantee, and 1.10.25 (in C++ N3690) states: An implementation should ensure that the last value (in modification order) assigned by an atomic or synchronization operation will become visible to all other threads in a finite period of time. Which to me states that busy-waiting loops like in the example above should eventually stop looping. The latency of this would be a QoI issue I guess. Even if it isn't allowed, every CPU is going to get interrupted eventually, and I'm told that in practice all current implementations would see the store at some point. In that case it might come down to a quality of implementation question. Is it OK to leave out the serialisation anyway with a slightly vague guarantee like that? That's a good question. If every thread is interrupted eventually, then it would be correct without adding a serializing instruction to each load. If not, we'd either have to add one on each atomic load, which might be expensive (how expensive would it be on s390?); or we'd need to try to just add it to loops that look like a busy waiting loop (ie, a loop whose termination might depend on an atomic load). I'm not aware of other architectures where we'd need to be concerned about atomic loads not picking up the most recent value eventually -- does anybody know about others or is this just a problem on s390? Torvald
Re: i386 __atomic_compare_exchange_n not found
On 6 August 2013 16:30, Deng Hengyi wrote: Hi Jonathan, Thank you for your reply. And about the error i encounter, do you have any advice? maybe it is caused by my toolchain not install rightly? In the standard pc686 architecture(not cross compile on RTEMS) will it encounter the similar error? I don't know anything about the RTEMS port. You might need to build and link to libatomic, but I don't know.
Re: [RFC] gcc feature request: Moving blocks into sections
On Mon, 2013-08-05 at 14:43 -0700, H. Peter Anvin wrote: For unconditional jmp that should be pretty safe barring any fundamental changes to the instruction set, in which case we can enable it as needed, but for extra robustness it probably should skip prefix bytes. Would the assembler add prefix bytes to: jmp 1f 1: ?? -- Steve
Re: [RFC] gcc feature request: Moving blocks into sections
On 08/06/2013 09:15 AM, Steven Rostedt wrote: On Mon, 2013-08-05 at 14:43 -0700, H. Peter Anvin wrote: For unconditional jmp that should be pretty safe barring any fundamental changes to the instruction set, in which case we can enable it as needed, but for extra robustness it probably should skip prefix bytes. Would the assembler add prefix bytes to: jmp 1f No, but if we ever end up doing MPX in the kernel, for example, we would have to put an MPX prefix on the jmp. -hpa
Re: [RFC] gcc feature request: Moving blocks into sections
On Tue, 2013-08-06 at 09:19 -0700, H. Peter Anvin wrote: On 08/06/2013 09:15 AM, Steven Rostedt wrote: On Mon, 2013-08-05 at 14:43 -0700, H. Peter Anvin wrote: For unconditional jmp that should be pretty safe barring any fundamental changes to the instruction set, in which case we can enable it as needed, but for extra robustness it probably should skip prefix bytes. Would the assembler add prefix bytes to: jmp 1f No, but if we ever end up doing MPX in the kernel, for example, we would have to put an MPX prefix on the jmp. Well then we just have to update the rest of the jump label code :-) -- Steve
Re: [RFC] gcc feature request: Moving blocks into sections
On 08/06/2013 09:26 AM, Steven Rostedt wrote: No, but if we ever end up doing MPX in the kernel, for example, we would have to put an MPX prefix on the jmp. Well then we just have to update the rest of the jump label code :-) For MPX in the kernel, this would be a small part of the work...! -hpa
Re: [RFC] gcc feature request: Moving blocks into sections
On Tue, Aug 6, 2013 at 7:19 AM, Steven Rostedt rost...@goodmis.org wrote: After playing with the patches again, I now understand why I did that. It wasn't just for optimization. [explanation snipped] Anyway, if you feel that update_jump_label is too complex, I can go the update at early boot route and see how that goes. Ugh. I'd love to see short jumps, but I do dislike binary rewriting, and doing it at early boot seems really quite scary too. So I wonder if this is a ok, let's not bother, it's not worth the pain issue. 128 bytes of offset is very small, so there probably aren't all that many cases that would use it. Linus
Re: [RFC] gcc feature request: Moving blocks into sections
On Tue, 2013-08-06 at 10:48 -0700, Linus Torvalds wrote: So I wonder if this is a ok, let's not bother, it's not worth the pain issue. 128 bytes of offset is very small, so there probably aren't all that many cases that would use it. OK, I'll forward port the original patches for the hell of it anyway, and post it as an RFC. Let people play with it if they want, and if it seems like it would benefit the kernel perhaps we can reconsider. It shouldn't be too hard to do the forward port, and if we don't ever take it, it would be a fun exercise regardless ;-) Actually, the first three patches should be added as they are clean ups and safety checks. Nothing to do with the actual 2-5 byte jumps. They were lost due to their association with the complex patches. :-/ -- Steve
i686 elf return values
Hi, i386elf.h defines: /* The ELF ABI for the i386 says that records and unions are returned in memory. */ #define SUBTARGET_RETURN_IN_MEMORY(TYPE, FNTYPE) \ (TYPE_MODE (TYPE) == BLKmode \ || (VECTOR_MODE_P (TYPE_MODE (TYPE)) int_size_in_bytes (TYPE) == 8)) and as such differs from the regular i86 return mechanism. Notice that the comment doesn't match the code: *) some structs/unions are non BLKmode *) some vectors can be BLKmode, some might not be -- the vector mode check appears to be an attempt to catch DImode vectors. Basing your ABI on the internal modes used by the compiler is not, IMHO, a sensible design choice. This code doesn't appear at first glance to cope with transparent_union. In fact it looks pretty bitrotted. Is it best just to junk the different behaviour at this point? nathan
Re: i686 elf return values
On Tue, Aug 6, 2013 at 1:46 PM, Nathan Sidwell nat...@acm.org wrote: Hi, i386elf.h defines: /* The ELF ABI for the i386 says that records and unions are returned in memory. */ #define SUBTARGET_RETURN_IN_MEMORY(TYPE, FNTYPE) \ (TYPE_MODE (TYPE) == BLKmode \ || (VECTOR_MODE_P (TYPE_MODE (TYPE)) int_size_in_bytes (TYPE) == 8)) and as such differs from the regular i86 return mechanism. Notice that the comment doesn't match the code: *) some structs/unions are non BLKmode *) some vectors can be BLKmode, some might not be -- the vector mode check appears to be an attempt to catch DImode vectors. Basing your ABI on the internal modes used by the compiler is not, IMHO, a sensible design choice. This code doesn't appear at first glance to cope with transparent_union. In fact it looks pretty bitrotted. Is it best just to junk the different behaviour at this point? Yes and yes :-) -- Gaby
Re: [RFC] gcc feature request: Moving blocks into sections
* Steven Rostedt (rost...@goodmis.org) wrote: On Tue, 2013-08-06 at 10:48 -0700, Linus Torvalds wrote: So I wonder if this is a ok, let's not bother, it's not worth the pain issue. 128 bytes of offset is very small, so there probably aren't all that many cases that would use it. OK, I'll forward port the original patches for the hell of it anyway, and post it as an RFC. Let people play with it if they want, and if it seems like it would benefit the kernel perhaps we can reconsider. It shouldn't be too hard to do the forward port, and if we don't ever take it, it would be a fun exercise regardless ;-) Actually, the first three patches should be added as they are clean ups and safety checks. Nothing to do with the actual 2-5 byte jumps. They were lost due to their association with the complex patches. :-/ Steve, perhaps you could add a mode to your binary rewriting program that counts the number of 2-byte vs 5-byte jumps found, and if possible get a breakdown of those per subsystem ? It might help us getting a clearer picture of how many important sites, insn cache-wise, are being shrinked by this approach. Thanks, Mathieu -- Steve -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Toolchain Build Robot
Hi! Since some time, I'm running compile tests for binutils/gdb/gcc on three of my machines. As you noticed, they're hitting errors from time to time. So I decided to spend it a small web frontend: http://toolchain.lug-owl.de/buildbot/ Maybe it's useful to somebody. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Friends are relatives you make for yourself. the second : signature.asc Description: Digital signature
Re: [RFC] gcc feature request: Moving blocks into sections
On Tue, 2013-08-06 at 16:33 -0400, Mathieu Desnoyers wrote: Steve, perhaps you could add a mode to your binary rewriting program that counts the number of 2-byte vs 5-byte jumps found, and if possible get a breakdown of those per subsystem ? I actually started doing that, as I was curious to how many were being changed as well. Note, this is low on my priority list, so I work on it as I get time. -- Steve
Re: Git mirror changes
On 22 July 2013 21:39, Jason Merrill wrote: I'd like to make some changes to the GCC git-svn mirror. Specifically, I want to move all the SVN branches from remotes/ into heads/ and split the subdirectory branches (redhat, google, etc) into the individual branches. Should I leave the SVN branches as they are in remotes/ as well, for backward compatibility with existing users? Do we want to limit creation of non-personal branches via git? Any other thoughts? It might be unrelated, but something has changed in the Git mirror around July 25th such that origin/master is no longer the same as origin/trunk: $ git rev-parse origin/trunk 775a7983ddd36f65cee7f54e23ff45da0ad106b5 $ git rev-parse origin/master 1f6ad59d8ba56b21e8f5dedb6d3792e1424962a1 The branches have the same content, but diverge after commit 149a90 $ git merge-base origin/trunk origin/master 149a90068641f143967c39dd3f3107dc6a7c8786 Was that caused by moving these branches and was it expected? Now that I've figured out why 'git pull' and 'git svn rebase' kept giving me different content I can easily change my upstream to origin/trunk, but it had me confused for a while!
Re: Git mirror changes
On 7 August 2013 00:56, Jonathan Wakely wrote: On 22 July 2013 21:39, Jason Merrill wrote: I'd like to make some changes to the GCC git-svn mirror. Specifically, I want to move all the SVN branches from remotes/ into heads/ and split the subdirectory branches (redhat, google, etc) into the individual branches. Should I leave the SVN branches as they are in remotes/ as well, for backward compatibility with existing users? Do we want to limit creation of non-personal branches via git? Any other thoughts? It might be unrelated, but something has changed in the Git mirror around July 25th such that origin/master is no longer the same as origin/trunk: $ git rev-parse origin/trunk 775a7983ddd36f65cee7f54e23ff45da0ad106b5 $ git rev-parse origin/master 1f6ad59d8ba56b21e8f5dedb6d3792e1424962a1 The branches have the same content, but diverge after commit 149a90 $ git merge-base origin/trunk origin/master 149a90068641f143967c39dd3f3107dc6a7c8786 Was that caused by moving these branches and was it expected? Now that I've figured out why 'git pull' and 'git svn rebase' kept giving me different content I can easily change my upstream to origin/trunk, but it had me confused for a while! Hmm, this might have been caused by some weird config on my side. After some changes I can't reproduce it now.
Re: [RFC] gcc feature request: Moving blocks into sections
On Tue, 2013-08-06 at 16:43 -0400, Steven Rostedt wrote: On Tue, 2013-08-06 at 16:33 -0400, Mathieu Desnoyers wrote: Steve, perhaps you could add a mode to your binary rewriting program that counts the number of 2-byte vs 5-byte jumps found, and if possible get a breakdown of those per subsystem ? I actually started doing that, as I was curious to how many were being changed as well. I didn't add it to the update program as that runs on each individual object (needs to handle modules). But I put in the start up code a counter to see what types were converted: [3.387362] short jumps: 106 [3.390277] long jumps: 330 Thus, approximately 25%. Not bad. -- Steve
Re: [RFC] gcc feature request: Moving blocks into sections
On Tue, 2013-08-06 at 20:45 -0400, Steven Rostedt wrote: [3.387362] short jumps: 106 [3.390277] long jumps: 330 Thus, approximately 25%. Not bad. Also, where these happen to be is probably even more important than how many. If all the short jumps happen in slow paths, it's rather pointless. But they seem to be in some rather hot paths. I had it print out where it placed the short jumps too: [0.00] short jump at: place_entity+0x53/0x87 8106e139^M [0.00] short jump at: place_entity+0x17/0x87 8106e0fd^M [0.00] short jump at: check_preempt_wakeup+0x11c/0x16e 8106f92b^M [0.00] short jump at: can_migrate_task+0xc6/0x15d 8106e72e [0.00] short jump at: update_group_power+0x72/0x1df 81070394 [0.00] short jump at: update_group_power+0xaf/0x1df 810703d1^M [0.00] short jump at: hrtick_enabled+0x4/0x35 8106de51 [0.00] short jump at: task_tick_fair+0x5c/0xf9 81070102^M [0.00] short jump at: source_load+0x27/0x40 8106da7c^M [0.00] short jump at: target_load+0x27/0x40 8106dabc^M [0.00] short jump at: try_to_wake_up+0x127/0x1e2 8106b1d4^M [0.00] short jump at: build_sched_domains+0x219/0x90b 8106bc24^M [0.00] short jump at: smp_trace_call_function_single_interrupt+0x79/0x112 8102616f^M [0.00] short jump at: smp_trace_call_function_interrupt+0x7a/0x111 81026038 [0.00] short jump at: smp_trace_error_interrupt+0x72/0x109 81028c9e [0.00] short jump at: smp_trace_spurious_interrupt+0x71/0x107 81028b77 [0.00] short jump at: smp_trace_reschedule_interrupt+0x7a/0x110 81025f01^M [0.00] short jump at: __raise_softirq_irqoff+0xf/0x90 810406e0^M [0.00] short jump at: it_real_fn+0x17/0xb2 8103ed85 [0.00] short jump at: trace_itimer_state+0x13/0x97 8103e9ff^M [0.00] short jump at: debug_deactivate+0xa/0x7a 8106014d^M [0.00] short jump at: debug_activate+0x10/0x86 810478c7^M [0.00] short jump at: __send_signal+0x233/0x268 8104a6bb [0.00] short jump at: send_sigqueue+0x103/0x148 8104bbbf^M [0.00] short jump at: trace_workqueue_activate_work+0xa/0x7a 81053deb^M [0.00] short jump at: _rcu_barrier_trace+0x31/0xbc 810b8f81 [0.00] short jump at: trace_rcu_dyntick+0x14/0x8f 810ba3a2^M [0.00] short jump at: rcu_implicit_dynticks_qs+0x95/0xc4 810ba35f [0.00] short jump at: rcu_implicit_dynticks_qs+0x47/0xc4 810ba311^M [0.00] short jump at: trace_rcu_future_gp.isra.38+0x46/0xe9 810b91e8 [0.00] short jump at: trace_rcu_grace_period+0x14/0x8f 810b90d3 [0.00] short jump at: trace_rcu_utilization+0xa/0x7a 810b9a6b [0.00] short jump at: update_curr+0x89/0x14f 8106f4c9^M [0.00] short jump at: update_stats_wait_end+0x5a/0xda 8106f203^M [0.00] short jump at: delayed_put_task_struct+0x1b/0x95 8103c798^M [0.00] short jump at: trace_module_get+0x10/0x86 81096b44^M [0.00] short jump at: pm_qos_update_flags+0xc5/0x149 81076fa0^M [0.00] short jump at: pm_qos_update_request+0x51/0xf3 81076b1e^M [0.00] short jump at: pm_qos_add_request+0xb7/0x14e 81076db9^M [0.00] short jump at: wakeup_source_report_event+0x7b/0xfc 81323045 [0.00] short jump at: trace_rpm_return_int+0x14/0x8f 81323d3d^M [0.00] short jump at: __activate_page+0xdd/0x183 810f8a1d^M [0.00] short jump at: __pagevec_lru_add_fn+0x139/0x1c4 810f88b5^M [0.00] short jump at: shrink_inactive_list+0x364/0x400 810fcee8^M [0.00] short jump at: isolate_lru_pages.isra.57+0xb6/0x14a 810fbafb^M [0.00] short jump at: wakeup_kswapd+0xaf/0x14a 810fbd20^M [0.00] short jump at: free_hot_cold_page_list+0x2a/0xca 810f3d1e [0.00] short jump at: kmem_cache_free+0x74/0xee 81129f9a^M [0.00] short jump at: kmem_cache_alloc_node+0xe6/0x17b 8112afb1^M [0.00] short jump at: kmem_cache_alloc_node_trace+0xe1/0x176 8112b615^M [0.00] short jump at: kmem_cache_alloc+0xd8/0x168 8112c1fe^M [0.00] short jump at: trace_kmalloc+0x21/0xac 8112aa7e^M [0.00] short jump at: wait_iff_congested+0xdc/0x158 81105ee3^M [0.00] short jump at: congestion_wait+0xa6/0x122 81106005^M [0.00] short jump at: global_dirty_limits+0xd7/0x151 810f5f74 [0.00] short jump at: queue_io+0x165/0x1e6 811568ec [0.00] short jump at: bdi_register+0xe9/0x161 81106329^M [0.00] short jump at: bdi_start_background_writeback+0xf/0x9c
Re: [RFC] gcc feature request: Moving blocks into sections
On Tue, Aug 06, 2013 at 08:56:00PM -0400, Steven Rostedt wrote: On Tue, 2013-08-06 at 20:45 -0400, Steven Rostedt wrote: [3.387362] short jumps: 106 [3.390277] long jumps: 330 Thus, approximately 25%. Not bad. Also, where these happen to be is probably even more important than how many. If all the short jumps happen in slow paths, it's rather pointless. But they seem to be in some rather hot paths. I had it print out where it placed the short jumps too: The kmem_cache_* and the try_to_wake_up* are the hot paths that caught my eye. But still, is this worth it? Add short_counter,long_counter and before increment counter before each jump. That way we will know how many short/long jumps were taken. -- Steve
[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
Another testcases:
int
bar (int i)
{
return 1 | ((i * 2) 254);
}
int
foo (int i)
{
return 1 | ((i * 2) 255);
}
[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 --- Comment #13 from janus at gcc dot gnu.org --- Author: janus Date: Tue Aug 6 08:20:17 2013 New Revision: 201521 URL: http://gcc.gnu.org/viewcvs?rev=201521root=gccview=rev Log: 2013-08-06 Janus Weil ja...@gcc.gnu.org PR fortran/57306 * class.c (gfc_class_null_initializer): Rename to 'gfc_class_initializer'. Treat non-NULL init-exprs. * gfortran.h (gfc_class_null_initializer): Update prototype. * trans-decl.c (gfc_get_symbol_decl): Treat class variables. * trans-expr.c (gfc_conv_initializer): Ditto. (gfc_trans_subcomponent_assign): Renamed gfc_class_null_initializer. 2013-08-06 Janus Weil ja...@gcc.gnu.org PR fortran/57306 * gfortran.dg/pointer_init_8.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pointer_init_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from janus at gcc dot gnu.org --- r201521 basically fixes this PR (the remaining problem of comment 7 will be tracked by PR 55207). Closing.
[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088
--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #4)
Another testcases:
int
bar (int i)
{
return 1 | ((i * 2) 254);
}
int
foo (int i)
{
return 1 | ((i * 2) 255);
}
This happens for any value of the RHS of the AND that is = 128.
A stack overflow occurs because fold_binary_loc keeps getting called, but op1,
which is supposed to be the result of maksing the RHS with the NOT of the 2 in
(i * 2) is set to something else.
Now investigating...
[Bug fortran/55207] Automatic deallocation of variables declared in the main program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 --- Comment #13 from janus at gcc dot gnu.org --- Test case from PR 57306 comment 7 (see also http://gcc.gnu.org/ml/fortran/2013-07/msg00103.html): type :: c end type c type(c), target :: x class(c), pointer :: px = x if (.not. associated(px)) call abort() end
[Bug target/40523] GCC generates invalid instructions when building for Thumb-2 on armel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40523 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Resolution|WONTFIX |FIXED --- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org --- It was fixed in 4.4.0, just not in 4.3.
[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Well, for (i * 2) 128 the BIT_AND_EXPR case doesn't do anything, but then we get into BIT_IOR_EXPR case, here the Canonicalize (X C1) | C2. code changes that into (i * 2) 255, then in BIT_AND_EXPR we drop the zero bits, so we get (i * 2) 254, but then it gets canonicalized into (i * 2) 255 again and so on and on, then we overflow.
[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213 --- Comment #15 from janus at gcc dot gnu.org --- Another test case related to comment 12 (from http://gcc.gnu.org/ml/fortran/2013-08/msg00015.html): integer, target :: tgt type t2 end type t2 type(t2), target :: tgt2 type t class(*), pointer :: a = tgt class(*), pointer :: b = tgt2 end type t type(t) :: x type(t), SAVE :: y end Unpatched gfortran gives: tobias3.f90:1.22: integer, target :: tgt 1 Internal Error at (1): tobias3.f90:6.31: class(*), pointer :: a = tgt 1 Can't convert INTEGER(4) to CLASS(*) at (1) and also the patches from comment 8 and 10 don't help here.
[Bug fortran/57959] [F03] ICE with structure constructor with scalar allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57959 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-06 CC||janus at gcc dot gnu.org Summary|ICE with structure |[F03] ICE with structure |constructor with scalar |constructor with scalar |allocatable components |allocatable components Ever confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org --- Loosely related: PR 49213.
[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #16 from janus at gcc dot gnu.org ---
(In reply to janus from comment #15)
and also the patches from comment 8 and 10 don't help here.
... but the following does:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 201520)
+++ gcc/fortran/expr.c(working copy)
@@ -3936,8 +3936,7 @@ gfc_default_initializer (gfc_typespec *ts)
if (comp-initializer)
{
ctor-expr = gfc_copy_expr (comp-initializer);
- if ((comp-ts.type != comp-initializer-ts.type
- || comp-ts.kind != comp-initializer-ts.kind)
+ if (!gfc_compare_types (comp-ts, comp-initializer-ts)
!comp-attr.pointer !comp-attr.proc_pointer)
gfc_convert_type_warn (ctor-expr, comp-ts, 2, false);
}
[Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a non-aligned memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58039 --- Comment #2 from Alexander Barkov bar at mariadb dot org --- Any updates? Thanks.
[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213 --- Comment #17 from janus at gcc dot gnu.org --- (In reply to janus from comment #16) and also the patches from comment 8 and 10 don't help here. ... but the following does: ... without any testsuite failures, btw.
[Bug c++/58091] Non-ambiguous member lookup rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58091 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- However current ICC agrees with GCC. We may have something in Bugzilla.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-08/msg00224.htm ||l --- Comment #29 from Martin Jambor jamborm at gcc dot gnu.org --- Richi approved the patch, I've committed it to trunk. I'm about to bootstrap and test n the 4.8 branch. Author: jamborm Date: Tue Aug 6 09:22:16 2013 New Revision: 201523 URL: http://gcc.gnu.org/viewcvs?rev=201523root=gccview=rev Log: 2013-08-06 Martin Jambor mjam...@suse.cz PR middle-end/58041 * gimple-ssa-strength-reduction.c (replace_ref): Make sure built MEM_REF has proper alignment information. testsuite/ * gcc.dg/torture/pr58041.c: New test. * gcc.target/arm/pr58041.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr58041.c trunk/gcc/testsuite/gcc.target/arm/pr58041.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-strength-reduction.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58091] Non-ambiguous member lookup rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58091 --- Comment #2 from fimbul77 at gmail dot com --- 3.4 Name lookup The name lookup rules apply uniformly to all names (including typedef-names (7.1.3), namespace-names (7.3), and class-names (9.1)) wherever the grammar allows such names in the context discussed by a particular rule. NS0::value NS(namespace) should not be lookup(the grammar don't allow appearing angle brackets after namespace name). Only NS(class template) should be lookup. Perhaps Clang is correct.
[Bug c/58092] New: BEQ (Branch on equal) jumps to wrong address (executes conditional code!)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092 Bug ID: 58092 Summary: BEQ (Branch on equal) jumps to wrong address (executes conditional code!) Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zajec5 at gmail dot com Created attachment 30617 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30617action=edit Minimal test case (ANSI C) In my code I'm using simple if (rev == 0x4) to make a conditional write. Unfortunately when using mipsel gcc with -Os the code from conditional part is *partially* executed even when rev doesn't equal 4. mipsel-openwrt-linux-uclibc-gcc -v Reading specs from /home/zajec/openwrt/openwrt.git/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/lib64/gcc/mipsel-openwrt-linux-uclibc/4.6.4/specs COLLECT_GCC=mipsel-openwrt-linux-uclibc-gcc COLLECT_LTO_WRAPPER=/home/zajec/openwrt/openwrt.git/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/lib/gcc/mipsel-openwrt-linux-uclibc/4.6.4/lto-wrapper Target: mipsel-openwrt-linux-uclibc Configured with: /home/zajec/openwrt/openwrt.git/build_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/gcc-linaro-4.6-2012.12/configure --with-bugurl=https://dev.openwrt.org/ --with-pkgversion='OpenWrt/Linaro GCC 4.6-2012.12 r36315' --prefix=/home/zajec/openwrt/openwrt.git/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2 --build=x86_64-suse-linux --host=x86_64-suse-linux --target=mipsel-openwrt-linux-uclibc --with-gnu-ld --enable-target-optspace --disable-libgomp --disable-libmudflap --disable-multilib --disable-nls --with-host-libstdcxx=-lstdc++ --with-float=soft --with-gmp=/home/zajec/openwrt/openwrt.git/staging_dir/host --with-mpfr=/home/zajec/openwrt/openwrt.git/staging_dir/host --disable-decimal-float --with-mips-plt --with-mpc=/home/zajec/openwrt/openwrt.git/staging_dir/host --disable-libssp --disable-__cxa_atexit --with-headers=/home/zajec/openwrt/openwrt.git/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/include --enable-languages=c,c++ --enable-shared --enable-threads --with-slibdir=/home/zajec/openwrt/openwrt.git/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/lib --enable-lto --with-libelf=/home/zajec/openwrt/openwrt.git/staging_dir/host Thread model: posix gcc version 4.6.4 (OpenWrt/Linaro GCC 4.6-2012.12 r36315)
[Bug c/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092 --- Comment #1 from Rafał Miłecki zajec5 at gmail dot com --- Created attachment 30618 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30618action=edit Compiled version of test.c Command I use to compile test.c: mipsel-openwrt-linux-uclibc-gcc \ -I arch/mips/include \ -I arch/mips/include/generated \ -I arch/mips/include/asm/mach-bcm47xx \ -I arch/mips/include/asm/mach-generic \ -I include \ -include include/linux/kconfig.h \ -D__KERNEL__ -DMODULE \ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror-implicit-function-declaration -Wno-format-security -Wframe-larger-than=1024 -Wno-unused-but-set-variable -Wdeclaration-after-statement -Wno-pointer-sign \ -fno-strict-aliasing -fno-common -fno-delete-null-pointer-checks -fno-caller-saves -fno-stack-protector -fno-pic -pipe -fomit-frame-pointer -femit-struct-debug-baseonly -fno-strict-overflow -fconserve-stack \ -mno-check-zero-division -mno-abicalls -mno-branch-likely -msoft-float -mno-long-calls -ffreestanding -mabi=32 -march=mips32 -Wa,-mips32 -Wa,--trap \ -D CC_HAVE_ASM_GOTO \ -Os \ -c -o test.o test.c
[Bug c++/58091] Non-ambiguous member lookup rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58091 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Generally speaking, this is a basic C++ issue, doesn't have to do with the recent constexpr, and normally icc is very solid about those. Remember there are also DRs, besides the published Standards. At the moment, I simply don't know.
[Bug c/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092 --- Comment #2 from Rafał Miłecki zajec5 at gmail dot com --- ### Decompiled object ### test: 0: 24020002li v0,2 4: 24030004li v1,4 8: aca2sw v0,0(a1) c: 10830002beq a0,v1,18 test+0x18 10: 24020008li v0,8 14: 8ca20040lw v0,64(a1) 18: aca20040sw v0,64(a1) 1c: 03e8jr ra 20: nop ### Decompiled with my explanations ### 0: 24020002li v0,2 4: 24030004li v1,4 8: aca2sw v0,0(a1) v0 (0x2) is stored in a1 unconditionally - this is fine c: 10830002beq a0,v1,18 test+0x18 10: 24020008li v0,8 a0 (rev argument) is compared with v1 (0x4) - if equal CPU jumps to 0x18 14: 8ca20040lw v0,64(a1) the above line is executed to rev != 4 18: aca20040sw v0,64(a1) the above lins (store v0 in a1+64) is always executed! it should be executed for rev==4 only v0 is 0x8 by default, or some different value for rev != 4 1c: 03e8jr ra 20: nop
[Bug c++/58014] vshuf-v2si.C fails at -O3 on hppa64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58014 --- Comment #2 from John David Anglin danglin at gcc dot gnu.org --- Introduced in r197845: 2013-04-12 Richard Biener rguent...@suse.de * gimple.c (is_gimple_constant): Vector CONSTRUCTORs should not be considered a gimple constant.
[Bug c++/58093] New: Semi-bogus warning about narrowing conversions and variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093
Bug ID: 58093
Summary: Semi-bogus warning about narrowing conversions and
variadic templates
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nmm1 at cam dot ac.uk
This may be related to 45397 and 53661, but it's not clear. The diagnostic
is both confusing and makes many uses of variadic templates extremely
confusing to their users.
4.13 [conv.rank], 4.7 [conv.integral] and 5 [expr] make it pretty clear
that this is not a narrowing conversion, which makes the diagnostic very
confusing. I agree that it potentially changes value, but the wording
could be better (e.g. 'loss of sign'). That's the trivial part of this
report.
The more serious (but still minor) one is that I don't think that this
is a soluble problem for the variadic template writer. It is unreasonable
to have to convert arguments explicitly, when it's automatic under almost
all circumstances.
The following program:
#include iostream
using namespace std;
templatetypename ... Pack
void weeble (Pack ... Dims) {
size_t r[] = {Dims...};
for (int i = 0; i sizeof...(Dims); ++i)
std::cout r[i];
std::cout std::endl;
}
int main() {
weeble(7,13,42,69);
}
produces:
junk.cpp: In instantiation of 'void weeble(Pack ...) [with Pack = {int, int,
int, int}]':
junk.cpp:13:22: required from here
junk.cpp:6:26: warning: narrowing conversion of 'Dims#0' from 'int' to 'size_t
{aka long unsigned int}' inside { } [-Wnarrowing]
size_t r[] = {Dims...};
^
junk.cpp:6:26: warning: narrowing conversion of 'Dims#1' from 'int' to 'size_t
{aka long unsigned int}' inside { } [-Wnarrowing]
junk.cpp:6:26: warning: narrowing conversion of 'Dims#2' from 'int' to 'size_t
{aka long unsigned int}' inside { } [-Wnarrowing]
junk.cpp:6:26: warning: narrowing conversion of 'Dims#3' from 'int' to 'size_t
{aka long unsigned int}' inside { } [-Wnarrowing]
g++ -v produces:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/nmm/GCC/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/nmm/GCC --disable-bootstrap
--enable-languages=c,c++,fortran --enable-werror=yes --disable-decimal-float
Thread model: posix
gcc version 4.8.1 (GCC)
[Bug fortran/57987] Fortran finalizers considered extern-inline by middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-08/msg00074.htm ||l Resolution|--- |FIXED --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Tue Aug 6 12:48:53 2013 New Revision: 201526 URL: http://gcc.gnu.org/viewcvs?rev=201526root=gccview=rev Log: 2013-08-06 Martin Jambor mjam...@suse.cz PR fortran/57987 * cgraphunit.c (cgraph_finalize_function): Assert that nested function is not re-finalized. Rename second parameter to no_collect. fortran/ * trans-decl.c (gfc_generate_function_code): Never call cgraph_finalize_function on nested functions. testsuite/ * gfortran.dg/pr57987.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr57987.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug c/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- Please attach the pre-processed test.i (gcc -E or -save-temps).
[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Nick Maclaren from comment #0)
4.13 [conv.rank], 4.7 [conv.integral] and 5 [expr] make it pretty clear
that this is not a narrowing conversion, which makes the diagnostic very
confusing. I agree that it potentially changes value, but the wording
could be better (e.g. 'loss of sign'). That's the trivial part of this
report.
8.5.4 [dcl.init.list] p7 makes it very clear it *is* a narrowing conversion,
because the elements in the pack expansion Dims... are not constant
expressions.
The more serious (but still minor) one is that I don't think that this
is a soluble problem for the variadic template writer. It is unreasonable
to have to convert arguments explicitly, when it's automatic under almost
all circumstances.
Why is it not soluble? The solution is trivial:
size_t r[] = {static_castsize_t(Dims)...};
Or replace the static_cast with your preferred choice of cast.
G++ is following the standard, this is not a bug.
size_t r[] = {Dims...};
for (int i = 0; i sizeof...(Dims); ++i)
std::cout r[i];
This would be simpler as:
size_t r[] = {Dims...};
for (auto i : r)
std::cout i;
[Bug middle-end/58094] New: [4.9 Regression] IPA devirt testsuite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094 Bug ID: 58094 Summary: [4.9 Regression] IPA devirt testsuite errors Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00092.html This patch caused new testsuite regressions: FAIL: g++.dg/ipa/devirt-11.C -std=gnu++98 scan-ipa-dump-times inline Discovered a virtual call to a known target 3 FAIL: g++.dg/ipa/devirt-11.C -std=gnu++98 scan-ipa-dump-times inline and turned into root of the clone tree 1 FAIL: g++.dg/ipa/devirt-11.C -std=gnu++11 scan-ipa-dump-times inline Discovered a virtual call to a known target 3 FAIL: g++.dg/ipa/devirt-11.C -std=gnu++11 scan-ipa-dump-times inline and turned into root of the clone tree 1 FAIL: g++.dg/tree-ssa/pr42337.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/tree-ssa/pr42337.C -std=gnu++11 (test for excess errors)
[Bug middle-end/58094] [4.9 Regression] IPA devirt testsuite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target||powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-06 CC||hubicka at gcc dot gnu.org, ||marxin.liska at gmail dot com Host||powerpc*-*-* Ever confirmed|0 |1 Build||powerpc*-*-* --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- Confirmed.
[Bug middle-end/58094] [4.9 Regression] IPA devirt testsuite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- I am not able to reproduce those on gcc110.fsffrance.org. Would be possible to have -fdump-ipa-all -fdump-tree-all dumps of the devirt testcase? I think both are related to fast that ipa-prop is not propagating across the local aliases, but I do not see why the local aliases are introduced here at first place. Perhaps binds_local_p is somehow wrong for AIX?
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #30 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Hi Martin, I have bootstrapped this patch for i686-pc-linux-gnu and have seen some excess errors in your test script: /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c: In function 'foo': /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11: note: The ABI for passing parameters with 16-byte alignment has changed in GCC 4.6 /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11: warning: SSE vector argument without SSE enabled changes the ABI [enabled by default] /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11: warning: SSE vector argument without SSE enabled changes the ABI [enabled by default] output is: /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c: In function 'foo': /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11: note: The ABI for passing parameters with 16-byte alignment has changed in GCC 4.6 /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11: warning: SSE vector argument without SSE enabled changes the ABI [enabled by default] /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11: warning: SSE vector argument without SSE enabled changes the ABI [enabled by default] FAIL: gcc.dg/torture/pr58041.c -O0 (test for excess errors) Excess errors: /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11: warning: SSE vector argument without SSE enabled changes the ABI [enabled by default] /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11: warning: SSE vector argument without SSE enabled changes the ABI [enabled by default]
[Bug c/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092 --- Comment #4 from Rafał Miłecki zajec5 at gmail dot com --- Created attachment 30619 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30619action=edit test.i generated by adding -save-temps Hi Mikael! I added -save-temps at the end of my mipsel-openwrt-linux-uclibc-gcc call and got warning: mipsel-openwrt-linux-uclibc-gcc: warning: -pipe ignored because -save-temps specified and test.i of course. By looking at decompiled version of test.o it seems to still contain the bug, so ignored -pipe shouldn't hurt us. Hope this is what you expected!
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #31 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #30) Hi Martin, I have bootstrapped this patch for i686-pc-linux-gnu and have seen some excess errors in your test script: /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c: In function 'foo': /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11: note: The ABI for passing parameters with 16-byte alignment has changed in GCC 4.6 /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11: warning: SSE vector argument without SSE enabled changes the ABI [enabled by default] I can't reproduce this with the -m32 flag on my x86_64... do you still have the compiler built on an i686? If so, could you try and make function foo static in that testcase and see if the error goes away? Thanks!
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #32 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Tue Aug 6 15:08:59 2013 New Revision: 201530 URL: http://gcc.gnu.org/viewcvs?rev=201530root=gccview=rev Log: 2013-08-06 Martin Jambor mjam...@suse.cz PR middle-end/58041 * gimple-ssa-strength-reduction.c (replace_ref): Make sure built MEM_REF has proper alignment information. testsuite/ * gcc.dg/torture/pr58041.c: New test. * gcc.target/arm/pr58041.c: Likewise. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr58041.c branches/gcc-4_8-branch/gcc/testsuite/gcc.target/arm/pr58041.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/gimple-ssa-strength-reduction.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093 --- Comment #2 from Nick Maclaren nmm1 at cam dot ac.uk --- I have no idea why you think that it is a narrowing conversion. The references I gave have been essentially unchanged since C90, and there is required to be no loss of information. All values of int can be represented in unsigned long in any conforming implementation. The primary condition of 8.5.4 p7 is fulfilled, and therefore the exception is irrelevant. This was clarified in C99 6.2.6.2. No, I did not support that interpretation in C90, but it's the one WG14 adopted. But it's merely a confusing diagnostic, and is therefore lost in the multitude of such things. Thank you for your correction on the templates - I was still thinking in terms of arguments and not patterns!
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #33 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Martin Jambor from comment #31) I can't reproduce this with the -m32 flag on my x86_64... do you still have the compiler built on an i686? If so, could you try and make function foo static in that testcase and see if the error goes away? static does not help. If I add -msse the warning goes away, but the compiled executable crashes because of illegal instruction. Dual Pentium II, with mmx but obviously no sse, whatever that may be: flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 mmx fxsr
[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Nick Maclaren from comment #2) I have no idea why you think that it is a narrowing conversion. Please read the definition of a narrowing conversion in C++11, at 8.5.4 [dcl.init.list] p7. What the C standard says is irrelevant here.
[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Nick Maclaren from comment #2) All values of int can be represented in unsigned long in any conforming implementation. Except the negative ones!
[Bug middle-end/58094] [4.9 Regression] IPA devirt testsuite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094 --- Comment #3 from David Edelsohn dje at gcc dot gnu.org --- Created attachment 30620 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30620action=edit ipa and tree dumps -fdump-ipa-all -fdump-tree-all output file attached in gzipped tar file.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #34 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
by the way the initializer of struct s a =
seems to generate warnings at -Wall, because some brackets are missing:
changed that to
struct s a = {0,{{0,0},{0,0}}};
but somehow I wonder what forced us to generate sse instructions here?
when that same example works on a ARMv5 targe?
[Bug c++/58095] New: SIMD code requiring auxiliary array for best optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58095 Bug ID: 58095 Summary: SIMD code requiring auxiliary array for best optimization Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: siavashserver at gmail dot com Created attachment 30621 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30621action=edit Source code and its generated asm code. Hello. I have noticed a strange behavior when I'm trying to write SIMD code using provided SSE intrinsics. It looks like GCC is not able to generate/optimize same code like function (bar) for function (foo). I was wondering how can I achieve same generated code for the function (foo) without going into trouble of defining and using an auxiliary array like function (bar). I've tried using __restrict__ keyword for input data (foo2), but GCC still generates same code like function (foo). ICC and Clang also generate same code and fail to optimize. Something strange I've noticed is that GCC 4.4.7 generates desired code for function (foo), but fails to do for function (foo2) and (bar). Newer versions generate exactly same code for function (foo) and (foo2), and desired code for function (bar). Output attached is generated from GCC 4.8.1 using -O2 optimization level. I've used online GCC compiler from: http://gcc.godbolt.org/
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #35 from Martin Jambor jamborm at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #34)
by the way the initializer of struct s a =
seems to generate warnings at -Wall, because some brackets are missing:
changed that to
struct s a = {0,{{0,0},{0,0}}};
but somehow I wonder what forced us to generate sse instructions here?
when that same example works on a ARMv5 targe?
Strange, does the correct initializer make the warning go away?
If so, I'll fix it in the testsuite in a moment.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #36 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Martin Jambor from comment #35)
(In reply to Bernd Edlinger from comment #34)
by the way the initializer
of struct s a =
seems to generate warnings at -Wall, because some
brackets are missing:
changed that to
struct s a = {0,{{0,0},{0,0}}};
but somehow I wonder what forced us to generate sse instructions here?
when that same example works on a ARMv5 targe?
Strange, does the correct
initializer make the warning go away?
If so, I'll fix it in the testsuite in a moment.
no that is just a different warning with -Wall, that one did not
make the test case fail however.
and in line 6 the typedef struct S { V v; } P __attribute__((aligned (1)));
is superfluos too.
hmm, maybe the problem is I should not say -msse in the first place.
do you get the warning if you use -m32 -mno-sse ?
what's funny about that warning, that it does not need to be enabled with
-Wall like the other warning.
[Bug tree-optimization/58095] SIMD code requiring auxiliary array for best optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58095 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|siavashserver at gmail dot com | Component|c++ |tree-optimization Severity|major |normal
[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093 --- Comment #5 from Nick Maclaren nmm1 at cam dot ac.uk --- I did. Please read what the C++ standard says about conversions. 4.7 [conv.integral] paragraph 2 is a paraphrase of wording that has been in every C and C++ compiler since C90, and states that all integers (negative and positive) can be represented in unsigned ones of an equal or greater rank. Indeed, this was and is a design requirement in the parts of the library that use -1 converted to an unsigned integer as a result type. I can't be bothered to pursue this one further - as I said, one more confusing diagnostic is neither here nor there.
[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 --- Comment #15 from Andrew Benson abensonca at gmail dot com --- Thanks for fixing!
[Bug lto/57602] [4.9 Regression] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed thus.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #37 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
this version fixes the warning:
--- ../gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c 2013-08-02
20:59:38.0 +0200
+++ pr58041.c 2013-08-06 18:30:51.0 +0200
@@ -3,8 +3,6 @@
typedef long long V
__attribute__ ((vector_size (2 * sizeof (long long)), may_alias));
-typedef struct S { V v; } P __attribute__((aligned (1)));
-
struct s
{
char u;
@@ -12,24 +10,24 @@
} __attribute__((packed,aligned(1)));
__attribute__((noinline, noclone))
-long long foo(struct s *x, int y, V z)
+long long foo(struct s *x, int y, V *z)
{
V a = x-v[y];
- x-v[y] = z;
+ x-v[y] = *z;
return a[1];
}
-struct s a = {0,{0,0}};
+struct s a = {0,{{0,0},{0,0}}};
int main()
{
V v1 = {0,1};
V v2 = {0,2};
- if (foo(a,0,v1) != 0)
+ if (foo(a,0,v1) != 0)
__builtin_abort();
- if (foo(a,0,v2) != 1)
+ if (foo(a,0,v2) != 1)
__builtin_abort();
- if (foo(a,1,v1) != 0)
+ if (foo(a,1,v1) != 0)
__builtin_abort();
return 0;
}
[Bug c/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se --- I can't reproduce the wrong-code with 4.6.4. 4.7.2, or 4.8.1. They all generate: test: 0: 24020002li v0,2 4: aca2sw v0,0(a1) 8: 24020004li v0,4 c: 14820002bne a0,v0,18 test+0x18 10: 24020008li v0,8 14: aca20040sw v0,64(a1) 18: 03e8jr ra 1c: nop which looks correct to me (not that I know MIPS very well). Please try with a self-compiled gcc built from unmodified sources, or report this to openwrt as your hacked gcc clearly indicated (see the bugurl in comment #1).
[Bug tree-optimization/58095] SIMD code requiring auxiliary array for best optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58095 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I've tried using __restrict__ keyword for input data (foo2), I think you want __restrict__ inside of the [].
[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-06 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org --- Change to gcc/prefix.c seems to make sense for relocatable-setup. The hack part seems to be no longer necessary and also wrong. I
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #38 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #37) this version fixes the warning: And I confirm that it still tests the bug. If you want to commit it yourself, go ahead, otherwise let me now and I'll do it before I leave today. Thanks a lot!
[Bug driver/46501] Relocatable toolchains still search --prefix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46501 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- This bug is a duplicate of pr/35300 *** This bug has been marked as a duplicate of bug 35300 ***
[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org --- *** Bug 46501 has been marked as a duplicate of this bug. ***
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #39 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Martin Jambor from comment #38) (In reply to Bernd Edlinger from comment #37) this version fixes the warning: And I confirm that it still tests the bug. If you want to commit it yourself, go ahead, otherwise let me now and I'll do it before I leave today. Thanks a lot! no thanks, just go ahead.
[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Nick Maclaren from comment #5)
I did. Please read what the C++ standard says about conversions. 4.7
[conv.integral] paragraph 2 is a paraphrase of wording that has been in
every C and C++ compiler since C90,
But that's not where narrowing conversions are defined.
See the examples in 8.5.4 which make it clear that converting a negative value
to an unsigned type is a narrowing conversion:
unsigned char uc2 = {-1}; // error: narrows
unsigned int ui1 = {-1}; // error: narrows
Those exxamples come from the proposal by Stroustrup et al:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2531.pdf
Also http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1449
As is made plain in the examples in that paragraph, a conversion of a negative
value to an unsigned type is intended to be a narrowing conversion
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #40 from Martin Jambor jamborm at gcc dot gnu.org --- OK, I have updated the testcase on both branches. So I hope all is well now and we can close this PR. Thanks everyone for cooperation. Author: jamborm Date: Tue Aug 6 17:33:59 2013 New Revision: 201538 URL: http://gcc.gnu.org/viewcvs?rev=201538root=gccview=rev Log: 2013-08-06 Martin Jambor mjam...@suse.cz Bernd Edlinger bernd.edlin...@hotmail.de testsuite/ * gcc.dg/torture/pr58041.c (foo): Accept z by reference. (a): Fix constructor. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr58041.c Author: jamborm Date: Tue Aug 6 17:35:11 2013 New Revision: 201539 URL: http://gcc.gnu.org/viewcvs?rev=201539root=gccview=rev Log: 2013-08-06 Martin Jambor mjam...@suse.cz Bernd Edlinger bernd.edlin...@hotmail.de testsuite/ * gcc.dg/torture/pr58041.c (foo): Accept z by reference. (a): Fix constructor. Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr58041.c
[Bug tree-optimization/58095] SIMD code requiring auxiliary array for best optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58095 --- Comment #2 from Siavash Eliasi siavashserver at gmail dot com --- (In reply to Andrew Pinski from comment #1) I've tried using __restrict__ keyword for input data (foo2), I think you want __restrict__ inside of the []. Do you mind pasting the modified source code and generated asm code please?
[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Kyrylo, do you plan to work on this? If that's the case, please assign the bug to yourself.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #41 from Bill Schmidt wschmidt at gcc dot gnu.org --- Thanks, Martin!
[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088 ktkachov at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #8 from ktkachov at gcc dot gnu.org --- Mine.
Carrefour ti regala la spesa di 500 euro
Con il DECRETO-LEGGE 8 aprile 2013, n. 35 in cui il Consiglio dei Ministri anticipa i pagamenti alle P.A. e aiuti per le famiglie, Carrefour Spa ti consente di acquistare la carta Prepagata SpesAmica del valore di 500 Euro al prezzo di 100 Euro. (80% rimborsato dal Ministero dello Sviluppo Economico). segui le indicazioni su : http://carrefour.damnserver.com/
[Bug target/58067] ICE in GFortran recog.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #4 from Alexandre Oliva aoliva at gcc dot gnu.org --- The note just means the debug info location expression containing this unexpected piece of RTL can't be expressed in dwarf and will thus be dropped on the floor, so you lose a bit of debug info, but that's all.
[Bug regression/58084] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added Target|arm-none-eabi |arm-none-eabi, ||powerpc64-linux CC||pthaugen at gcc dot gnu.org --- Comment #2 from Pat Haugen pthaugen at gcc dot gnu.org --- Seeing the same thing on powerpc64-linux.
[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #18 from David Abdurachmanov david.abdurachmanov at gmail dot com --- Tested the patch on top of final 4.8.1 Cortex-A9 NEON FPU. GCC no more ICE'ing while compiling scipy.
[Bug other/58096] New: gcc.dg/tree-ssa/attr-alias.c fails with r201439
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096 Bug ID: 58096 Summary: gcc.dg/tree-ssa/attr-alias.c fails with r201439 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: bergner at gcc dot gnu.org, dje.gcc at gmail dot com, hubicka at gcc dot gnu.org, marxin.liska at gmail dot com Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux Subject testcase started failing with r201439. PASS: gcc.dg/tree-ssa/attr-alias.c (test for excess errors) PASS: gcc.dg/tree-ssa/attr-alias.c scan-tree-dump-times optimized test 1 FAIL: gcc.dg/tree-ssa/attr-alias.c scan-tree-dump-times optimized test4 1 PASS: gcc.dg/tree-ssa/attr-alias.c scan-tree-dump-not optimized test1 PASS: gcc.dg/tree-ssa/attr-alias.c scan-tree-dump-not optimized test2
[Bug rtl-optimization/58079] internal compiler error: in do_SUBST, at combine.c:711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58079 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #4 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- (In reply to Mikael Pettersson from comment #3) Started with Uros' PR54457 patch in r191928. I'm not sure if that patch was wrong or if it exposed a problem in the mips backend. Looks like a latent combine bug that's being exposed by the better subreg optimisation. simplify_comparison is legitimately widening a QImode comparison to SImode (since the target doesn't support QImode comparisons), but combine_simplify_rtx is then trying to substitute these widened values in-place, which trips the sanity check in do_SUBST. I'm about to post a patch for comments.
[Bug target/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092 --- Comment #6 from Rafał Miłecki zajec5 at gmail dot com --- OK, I've installed cross-mips-linux-gcc package from: http://download.opensuse.org/repositories/home:/duwe:/crosstools/openSUSE_12.2/ and it works. After compiling test.c with: /opt/cross/bin/mips-linux-gcc -v Using built-in specs. COLLECT_GCC=/opt/cross/bin/mips-linux-gcc COLLECT_LTO_WRAPPER=/opt/cross/libexec/gcc/mips-linux/4.5.3/lto-wrapper Target: mips-linux Configured with: ../configure --prefix=/opt/cross --enable-bootstrap=no --build=x86_64-suse-linux --target=mips-linux --enable-languages=c,c++ --with-float=soft --disable-libmudflap --disable-multilib Thread model: posix gcc version 4.5.3 (GCC) I got a correct test.o. So this issue is specific to Linaro or OpenWrt.
[Bug rtl-optimization/58079] internal compiler error: in do_SUBST, at combine.c:711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58079 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-08/msg00326.htm ||l Last reconfirmed||2013-08-06 CC|rdsandiford at googlemail dot com | Ever confirmed|0 |1
[Bug target/58067] ICE in GFortran recog.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067
--- Comment #5 from Alexandre Oliva aoliva at gcc dot gnu.org ---
As Andrew says, the problem with -mtls-dialect=gnu (the default) is lack of TLS
support. The tls_get_addr calls expanded by tls_global_dynamic_64_mode are
not recognized by the corresponding insns because the call address operand (the
__tls_get_addr symbol_ref) doesn't pass the constant_call_address_operand
predicate, configured to always fail in the LARGE code models. I suppose it's
not appropriate to make an exception for __tls_get_addr, and we'd instead have
to make it an indirect call after loading the address from the GOT. We'd need
new relocations and relaxation smarts in binutils for this to work. I guess it
makes more sense to force the GNU2 tls-dialect for LARGE code models, since
that one works, and maybe switch to it by default in other models; we've had it
for long enough already.
As for the non-delegitimized notes we get in both modes, that's fixed with
something along the lines of the following patch:
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -13827,6 +13827,21 @@ ix86_delegitimize_address (rtx x)
x = replace_equiv_address_nv (orig_x, x);
return x;
}
+ if (GET_CODE (x) == PLUS
+ ix86_pic_register_p (XEXP (x, 0))
+ GET_CODE (XEXP (x, 1)) == CONST
+ GET_CODE (XEXP (XEXP (x, 1), 0)) == UNSPEC
+ /* These are used in 64-bit CM_LARGE mode. */
+ (XINT (XEXP (XEXP (x, 1), 0), 1) == UNSPEC_PLTOFF
+ || XINT (XEXP (XEXP (x, 1), 0), 1) == UNSPEC_GOTOFF))
+{
+ x = simplify_gen_subreg (GET_MODE (orig_x),
+ XVECEXP (XEXP (XEXP (x, 1), 0), 0, 0),
+ GET_MODE (x), 0);
+ if (x == NULL_RTX)
+return orig_x;
+ return x;
+}
if (GET_CODE (x) != CONST
|| GET_CODE (XEXP (x, 0)) != UNSPEC
|| (XINT (XEXP (x, 0), 1) != UNSPEC_GOTPCREL
Uros (or anyone), please take this as a starting point; it might require
support for addends, even though I haven't needed them for this one testcase.
Or maybe we don't need them, after all. I'm not sure, so I'll leave it for
someone else who knows better.
[Bug rtl-optimization/58034] [4.8/4.9 Regression] glibc nptl/tst-cleanup2 fail due to scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Wed, 31 Jul 2013, amodra at gmail dot com wrote:
The relevant test case source:
if (setjmp (jmpbuf))
{
puts (Exiting main...);
return 0;
}
sprintf (p, This should segv\n);
return 1;
}
The sprintf is optimised to three loads and stores. The problem occurs due to
the assignment of 1 to the REG holding the function return value being
scheduled before the sprintf expansion.
Well, in valid code this sprintf can't trap (sprintf using glibc
extensions to register format extensions might). Optimizing to three
loads and stores, and then scheduling them, seems a valid optimization to
me. Does -fnon-call-exceptions help? (Though I'd prefer
-fno-builtin-sprintf as a fix for the glibc test.)
[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Paul Pluzhnikov from comment #2) What is the way to turn it on? Compiling test case with -mtls-dialect=gnu2 does appear to improve the picture: g++ -fPIC -O2 -S t.cc -mtls-dialect=gnu2 __cxa_get_globals: leaq_ZL3ccc@TLSDESC(%rip), %rax call*_ZL3ccc@TLSCALL(%rax) addq%fs:0, %rax ret The indirect call goes to _dl_tlsdesc_dynamic in ld-linux-x86-64.so.2 with misaligned stack, and the latter re-aligns it.
[Bug middle-end/58096] [4.9 Regression] gcc.dg/tree-ssa/attr-alias.c fails with r201439
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-06 CC||dje at gcc dot gnu.org Component|other |middle-end Summary|gcc.dg/tree-ssa/attr-alias. |[4.9 Regression] |c fails with r201439|gcc.dg/tree-ssa/attr-alias. ||c fails with r201439 Ever confirmed|0 |1 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- This probably is related to PR middle-end/58094
[Bug target/58067] ICE in GFortran recog.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 --- Comment #6 from Ben Woodard woodard at redhat dot com --- I just rebuilt the trunk with the patch that Alexandre Oliva provided and I can confirm that it solves the problem with notes about non-delegitimized addresses. However, I haven't yet tested the DWARF to make sure that it works as expected. If we do make -mtls-dialect=gnu2 the default or even implied when you specify -mcmodel=large, won't you still need to fix the problem with the unknown instruction just in case someone does -mtls-dialect=gnu or will you just error out saying: -mcmodel=large is not supported within -mtls-dialect=gnu. Personally, I believe that erroring out that way is perfectly acceptable.
[Bug target/58067] ICE in GFortran recog.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 --- Comment #7 from Ben Woodard woodard at redhat dot com --- Created attachment 30622 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30622action=edit Alexandre's patch as a file rather than as text.
[Bug c++/57825] Template specialization for ref qualified member pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/56979] ICE in output_operand: invalid operand for code 'P'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Sat, 3 Aug 2013, rearnsha at gcc dot gnu.org wrote: Although the compiler shouldn't ICE, it's arguable that passing over-aligned values by value to functions is not supportable (c11, for example, does not support over-aligning function arguments even though it does permit over-aligning some other objects) and that this case is really an ICE on invalid. I see no such restriction in C11. You can't use _Alignas directly on a parameter, but if you have somehow constructed an over-aligned type (and, as I noted on the WG14 reflector some time ago, and more recently in N1731, there is no syntax for doing so despite the discussion of such types in C11), being a struct or union with an alignment specifier used therein, nothing I see prohibits passing it to a function - it's simply implementation-defined whether that is a context in which such a type is supported.
[Bug c/57956] missing 'msgstr' section errors when building
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57956 DJ Delorie dj at redhat dot com changed: What|Removed |Added CC||dj at redhat dot com --- Comment #2 from DJ Delorie dj at redhat dot com --- I tracked this down to a PO file that requires a newer version of gettext than the gcc prereq page requires: http://gcc.gnu.org/ml/gcc/2013-07/msg00203.html
[Bug c++/57850] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 --- Comment #7 from Sharad Singhai singhai at gcc dot gnu.org --- I looked at it and this issue seems related to handling of PCH files. The following patch introduced it http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/decl2.c?r1=194363r2=194362pathrev=194363 When only a header file is being compiled then cp_write_global_declarations () returns immediately without doing any extra work. Thus dump code (and everything else) is skipped. I don't know what should be the right course of action here. If it is only the dump functionality that needs to be restored, I can perhaps work around with some restructuring. However, there is a lot of other processing which should be skipped in case of PCH. Suggestions? Thanks, Sharad
[Bug c++/57255] [meta-bug] ref-qualifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57255 Bug 57255 depends on bug 57825, which changed state. Bug 57825 Summary: Template specialization for ref qualified member pointers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
