[Bug fortran/45777] Alias analysis broken for arrays where LHS or RHS is a component ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45777 --- Comment #13 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-08 09:38:17 UTC --- Author: tkoenig Date: Sat Jan 8 09:38:13 2011 New Revision: 168596 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168596 Log: 2011-01-08 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/45777 * symbol.c (gfc_symbols_could_alias): Strip gfc_ prefix, make static and move in front of its only caller, to ... * trans-array.c (symbols_could_alias): ... here. Pass information about pointer and target status as arguments. Allocatable arrays don't alias anything unless they have the POINTER attribute. (gfc_could_be_alias): Keep track of pointer and target status when following references. Also check if typespecs of components match those of other components or symbols. 2011-01-08 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/45777 * gfortran.dg/dependency_39.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_39.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/45777] Alias analysis broken for arrays where LHS or RHS is a component ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45777 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.0 Known to fail|4.5.0, 4.6.0|4.5.2 --- Comment #14 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-08 10:04:00 UTC --- Fixed on trunk, backport to 4.5 pending.
[Bug fortran/36462] [F2003] Audit intrinsics for KIND arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36462 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Keywords|wrong-code | CC||tkoenig at gcc dot gnu.org Summary|KIND argument in INDEX |[F2003] Audit intrinsics |results in wrong code |for KIND arguments --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-08 10:07:18 UTC --- Adjusting Subject, removing wrong-code.
[Bug libobjc/47031] libobjc uses mutexes for properties
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031 --- Comment #7 from Nicola Pero nicola at gcc dot gnu.org 2011-01-08 11:39:38 UTC --- Usually, the lock is not held. If it is, you do a little trick: You spin 10 times and if you still could not get the lock, it's likely the current thread is blocking another thread from releasing the spinlock. Again, quite unlikely, as the spinlock is only held for an extremely short amount of time. However, if it happens that after 10 spins you still could not get the lock, you call sched_yield() to NOT waste resources. So, in the worst case, you waste 10 spins. That's basically 10 compares. That's nothing compared to a user/kernelspace switch, which is often 10 times more. Well, but locking a mutex on Linux is implemented on top of futexes and does not require a user/kernelspace switch unless the lock is already held (in which case a spinlock requires a switch too). ;-) So, basically on Linux the standard mutexes are already optimized and perform not as fast but almost as fast as spinlocks in the uncontended case, but without the problems of spinlocks in the contented case (my benchmarks confirm that; there is nothing like the 10x difference you mention in the uncontented case). :-) Maybe you benchmarked or used other platforms in the past; and you may have a very good point there. If objc_mutex_lock() and objc_mutex_unlock() actually do always perform a system call each on some systems, the mutex-protected accessor could be so much slower (100x ?) than the spinlock-protected accessor (in the non-contented case) that it may make sense to multiply the number of accessor locks (say, to 64) to reduce the chance of contention and then use spinlocks there. :-) On the other hand, mutexes are easy to port, have been ported and are known to work well out of the box, so in terms of maintenance of other platforms I wouldn't mind sticking with them for all the other, less-used platforms too. They may not be fast, but at least they always work. ;-) It would still be good to try a worst-case benchmark of spinlocks in the highly contended case. I am assuming the performance would be really really bad, but then I may just be wrong. ;-) Thanks
[Bug objc/47078] [4.6 Regression] ICE on invalid type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47078 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.08 12:07:28 Target Milestone|--- |4.6.0 Summary|ICE on invalid type |[4.6 Regression] ICE on ||invalid type Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-01-08 12:07:28 UTC --- Yes, this is confirmed in GCC 4.6 (5 January 2011). Older versions of GCC (eg, 4.0 and 4.2) seem to produce a reasonable error instead of crashing. Thanks
Re: [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests
One failure is /tmp/ccJSP9PV.lto.o: In function `main':^M ccWUIi0z.o:(.text.startup+0x1d): undefined reference to `g_ebp_save'^M ccWUIi0z.o:(.text.startup+0x23): undefined reference to `g_esp_save'^M ccWUIi0z.o:(.text.startup+0x3b): undefined reference to `g_edi'^M ccWUIi0z.o:(.text.startup+0x41): undefined reference to `g_esi'^M ccWUIi0z.o:(.text.startup+0x47): undefined reference to `g_ebx'^M ccWUIi0z.o:(.text.startup+0x4d): undefined reference to `g_ebp'^M ccWUIi0z.o:(.text.startup+0x53): undefined reference to `g_esp'^M collect2: ld returned 1 exit status^M Hmm, this does not seem to be dependent on plugin implementation, but it seems like bug in 32bit only testcase. The testcase seems to use: int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX; int g_ebp, g_ebp_save, g_esp, g_esp_save; int n_error; and __asm__ __volatile__ ( movl %ebp, ASMNAME(g_ebp_save)\n\t movl %esp, ASMNAME(g_esp_save)\n\t ); I guess either g_ebp_save needs externally_visible attribute or the asm statement needs to be modified to use g_ebp_save as an destination. I think this testcase is yours, so perhaps you can fix it? Was there some reason to use the ASMNAME hack instead of memory output constraint? Thanks, Honza
[Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222 --- Comment #2 from Jan Hubicka hubicka at ucw dot cz 2011-01-08 13:43:27 UTC --- One failure is /tmp/ccJSP9PV.lto.o: In function `main':^M ccWUIi0z.o:(.text.startup+0x1d): undefined reference to `g_ebp_save'^M ccWUIi0z.o:(.text.startup+0x23): undefined reference to `g_esp_save'^M ccWUIi0z.o:(.text.startup+0x3b): undefined reference to `g_edi'^M ccWUIi0z.o:(.text.startup+0x41): undefined reference to `g_esi'^M ccWUIi0z.o:(.text.startup+0x47): undefined reference to `g_ebx'^M ccWUIi0z.o:(.text.startup+0x4d): undefined reference to `g_ebp'^M ccWUIi0z.o:(.text.startup+0x53): undefined reference to `g_esp'^M collect2: ld returned 1 exit status^M Hmm, this does not seem to be dependent on plugin implementation, but it seems like bug in 32bit only testcase. The testcase seems to use: int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX; int g_ebp, g_ebp_save, g_esp, g_esp_save; int n_error; and __asm__ __volatile__ ( movl %ebp, ASMNAME(g_ebp_save)\n\t movl %esp, ASMNAME(g_esp_save)\n\t ); I guess either g_ebp_save needs externally_visible attribute or the asm statement needs to be modified to use g_ebp_save as an destination. I think this testcase is yours, so perhaps you can fix it? Was there some reason to use the ASMNAME hack instead of memory output constraint? Thanks, Honza
[Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47223 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-01-08 14:01:47 UTC --- Try to configure with `--disable-shared --enable-shared=lto-plugin'.
Re: [Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
What is the failure? Honza
[Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47223 --- Comment #2 from Jan Hubicka hubicka at ucw dot cz 2011-01-08 14:38:20 UTC --- What is the failure? Honza
[Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47223 --- Comment #3 from coolypf coolypf at qq dot com 2011-01-08 14:42:14 UTC --- (In reply to comment #2) What is the failure? Honza when configuring target-libgcc, failed with xgcc cannot create executable config.log shows 'liblto_plugin-0.dll not found' maybe -fuse-linker-plugin option not handled correctly
[Bug objc/47078] [4.6 Regression] ICE on invalid type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47078 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |nicola at gcc dot gnu.org |gnu.org | --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-01-08 14:54:18 UTC --- I have a patch ready (testing). A similar problem affects objc++ as well; the patch fixes that too. Thanks
Re: [Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
when configuring target-libgcc, failed with xgcc cannot create executable config.log shows 'liblto_plugin-0.dll not found' maybe -fuse-linker-plugin option not handled correctly Yes, it seems that linker plugin handling on cygwin is not done well. Is linker plugin built for you and does the linker support it? Honza
[Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47223 --- Comment #4 from Jan Hubicka hubicka at ucw dot cz 2011-01-08 14:56:10 UTC --- when configuring target-libgcc, failed with xgcc cannot create executable config.log shows 'liblto_plugin-0.dll not found' maybe -fuse-linker-plugin option not handled correctly Yes, it seems that linker plugin handling on cygwin is not done well. Is linker plugin built for you and does the linker support it? Honza
[Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47223 --- Comment #5 from coolypf coolypf at qq dot com 2011-01-08 15:05:29 UTC --- (In reply to comment #4) when configuring target-libgcc, failed with xgcc cannot create executable config.log shows 'liblto_plugin-0.dll not found' maybe -fuse-linker-plugin option not handled correctly Yes, it seems that linker plugin handling on cygwin is not done well. Is linker plugin built for you and does the linker support it? Honza lto and linker plugin was OK in 20110101 snapshot in which '-fuse-linker-plugin' was off by default but in rev 168594, the option becomes on by default this option causes checking LTOPLUGINSONAME in gcc/gcc.c (line 6812 around), which is not built with '--disable-shared' something is wrong either with makefile or with gcc/gcc.c
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 Yu Simin silver24k at gmail dot com changed: What|Removed |Added CC||silver24k at gmail dot com --- Comment #2 from Yu Simin silver24k at gmail dot com 2011-01-08 15:12:12 UTC --- *** Bug 47116 has been marked as a duplicate of this bug. ***
[Bug c++/47116] Linking error: multiple definition of `non-virtual thunk to ...'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47116 Yu Simin silver24k at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Yu Simin silver24k at gmail dot com 2011-01-08 15:12:11 UTC --- duplicate of PR47218 *** This bug has been marked as a duplicate of bug 47218 ***
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 --- Comment #3 from Yu Simin silver24k at gmail dot com 2011-01-08 15:13:42 UTC --- A simple test in PR47116: http://gcc.gnu.org/bugzilla/attachment.cgi?id=22866
Re: [Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
lto and linker plugin was OK in 20110101 snapshot in which '-fuse-linker-plugin' was off by default but in rev 168594, the option becomes on by default Yes, I've changed the default when linker is detected to have linker support and lto-plugin is build. this option causes checking LTOPLUGINSONAME in gcc/gcc.c (line 6812 around), which is not built with '--disable-shared' something is wrong either with makefile or with gcc/gcc.c How this worked before? On windows I would expect LTOPLUGINSONAME to point to the plugin DLL... Honza
[Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47223 --- Comment #6 from Jan Hubicka hubicka at ucw dot cz 2011-01-08 15:17:54 UTC --- lto and linker plugin was OK in 20110101 snapshot in which '-fuse-linker-plugin' was off by default but in rev 168594, the option becomes on by default Yes, I've changed the default when linker is detected to have linker support and lto-plugin is build. this option causes checking LTOPLUGINSONAME in gcc/gcc.c (line 6812 around), which is not built with '--disable-shared' something is wrong either with makefile or with gcc/gcc.c How this worked before? On windows I would expect LTOPLUGINSONAME to point to the plugin DLL... Honza
[Bug tree-optimization/46367] [4.6 Regression] ICE during cgraph edge cloning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46367 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 15:25:17 UTC --- Fixed.
[Bug gcov-profile/38292] [4.3/4.4/4.5/4.6 Regression] corrupted profile info with -O[23] -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38292 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.08 15:32:01 CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail|| --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 15:32:01 UTC --- Richard's reorg of profiling to SSA uncovered some of issues with pureconst functions that are fixed in the current mainline. Can you, please, check if that solves your problem?
[Bug middle-end/45566] [4.5/4.6 Regression] ICE: in convert_to_eh_region_ranges, at except.c:2446 with -freorder-blocks-and-partition -fnon-call-exceptions -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45566 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.08 15:37:08 CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 15:37:08 UTC --- confirmed.
[Bug tree-optimization/18687] [4.3/4.4/4.5/4.6 Regression] 200% compile time regression compared to gcc-3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Known to fail|| --- Comment #52 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 16:02:07 UTC --- hashes oprofile is as follows: samples %app name symbol name 8237 2.9617 libc-2.11.1.so _int_malloc 6877 2.4727 cc1 bitmap_set_bit 5820 2.0927 cc1 htab_find_slot_with_hash 4238 1.5238 cc1 operand_equal_p 4233 1.5220 cc1 record_reg_classes.constprop.9 4069 1.4631 cc1 bitmap_bit_p 3780 1.3592 libc-2.11.1.so memset 3399 1. cc1 nonzero_bits1 2992 1.0758 cc1 ggc_internal_alloc_stat 2516 0.9047 libc-2.11.1.so _int_free 2454 0.8824 as /usr/bin/as 2244 0.8069 cc1 fold_binary_loc 2229 0.8015 libc-2.11.1.so malloc 1909 0.6864 libc-2.11.1.so free 1857 0.6677 cc1 constrain_operands.part.12 1696 0.6098 cc1 is_gimple_reg 1688 0.6069 cc1 et_splay 1667 0.5994 cc1 note_stores 1632 0.5868 cc1 walk_tree_1 1585 0.5699 cc1 for_each_rtx_1 1577 0.5670 cc1 pool_alloc 1572 0.5652 cc1 tree_strip_nop_conversions and the other testcase: samples %image name app name symbol name 5195 5.1031 cc1 cc1 operand_equal_p 2848 2.7976 cc1 cc1 bitmap_set_bit 2080 2.0432 libc-2.11.1.so libc-2.11.1.so _int_malloc 1879 1.8458 cc1 cc1 htab_find_slot_with_hash 1432 1.4067 cc1 cc1 bitmap_bit_p 1298 1.2750 cc1 cc1 mem_attrs_htab_eq 1290 1.2672 cc1 cc1 record_reg_classes.constprop.9 1063 1.0442 cc1 cc1 walk_tree_1 1010 0.9921 cc1 cc1 tree_strip_nop_conversions 1004 0.9862 cc1 cc1 bitmap_ior_into 963 0.9460 libc-2.11.1.so libc-2.11.1.so memset 934 0.9175 cc1 cc1 df_worklist_dataflow 882 0.8664 cc1 cc1 mark_all_vars_used_1 806 0.7917 as as /usr/bin/as 795 0.7809 opreport opreport /usr/bin/opreport 793 0.7790 cc1 cc1 ggc_internal_alloc_stat 784 0.7701 cc1 cc1 is_gimple_reg 732 0.7190 cc1 cc1 constrain_operands.part.12 701 0.6886 cc1 cc1 bitmap_ior_and_compl 672 0.6601 cc1 cc1 et_splay 650 0.6385 libc-2.11.1.so libc-2.11.1.so _int_free 612 0.6012 cc1 cc1 for_each_rtx_1 608 0.5972 libc-2.11.1.so libc-2.11.1.so memcpy 603 0.5923 libc-2.11.1.so libc-2.11.1.so malloc 596 0.5855 cc1 cc1 bitmap_elt_insert_after 581 0.5707 cc1 cc1 ix86_decompose_address 570 0.5599 cc1 cc1 bitmap_copy 568 0.5580 cc1 cc1 cse_insn so apparently not much of surprise.
[Bug tree-optimization/18687] [4.3/4.4/4.5/4.6 Regression] 200% compile time regression compared to gcc-3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687 --- Comment #53 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 16:10:38 UTC --- Concerning Steven's comment, for infcode the time report is: callgraph optimization: 0.07 ( 1%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 139 kB ( 0%) ggc cfg cleanup : 0.22 ( 2%) usr 0.00 ( 0%) sys 0.19 ( 2%) wall 2591 kB ( 1%) ggc trivially dead code : 0.08 ( 1%) usr 0.00 ( 0%) sys 0.06 ( 1%) wall 0 kB ( 0%) ggc df scan insns : 0.08 ( 1%) usr 0.00 ( 0%) sys 0.08 ( 1%) wall 11 kB ( 0%) ggc df reaching defs : 0.09 ( 1%) usr 0.00 ( 0%) sys 0.14 ( 1%) wall 0 kB ( 0%) ggc df live regs : 0.49 ( 4%) usr 0.00 ( 0%) sys 0.43 ( 4%) wall 0 kB ( 0%) ggc df liveinitialized regs: 0.37 ( 3%) usr 0.00 ( 0%) sys 0.44 ( 4%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.16 ( 1%) usr 0.00 ( 0%) sys 0.12 ( 1%) wall 1805 kB ( 1%) ggc register information : 0.06 ( 1%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc alias analysis: 0.14 ( 1%) usr 0.00 ( 0%) sys 0.12 ( 1%) wall 8010 kB ( 4%) ggc alias stmt walking: 0.09 ( 1%) usr 0.02 ( 7%) sys 0.09 ( 1%) wall 268 kB ( 0%) ggc parser: 0.16 ( 1%) usr 0.02 ( 7%) sys 0.20 ( 2%) wall 11320 kB ( 6%) ggc tree gimplify : 0.15 ( 1%) usr 0.02 ( 7%) sys 0.15 ( 1%) wall 16123 kB ( 8%) ggc tree CFG cleanup : 0.18 ( 2%) usr 0.01 ( 3%) sys 0.13 ( 1%) wall 881 kB ( 0%) ggc tree VRP : 0.43 ( 4%) usr 0.02 ( 7%) sys 0.38 ( 3%) wall 20850 kB (10%) ggc tree copy propagation : 0.06 ( 1%) usr 0.00 ( 0%) sys 0.14 ( 1%) wall 1638 kB ( 1%) ggc tree PTA : 0.35 ( 3%) usr 0.00 ( 0%) sys 0.35 ( 3%) wall 331 kB ( 0%) ggc tree SSA rewrite : 0.11 ( 1%) usr 0.01 ( 3%) sys 0.13 ( 1%) wall 6269 kB ( 3%) ggc tree SSA incremental : 0.17 ( 1%) usr 0.01 ( 3%) sys 0.16 ( 1%) wall 1321 kB ( 1%) ggc dominator optimization: 0.18 ( 2%) usr 0.00 ( 0%) sys 0.17 ( 1%) wall 5507 kB ( 3%) ggc tree CCP : 0.19 ( 2%) usr 0.00 ( 0%) sys 0.10 ( 1%) wall 1065 kB ( 1%) ggc tree reassociation: 0.06 ( 1%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 1273 kB ( 1%) ggc tree PRE : 0.52 ( 5%) usr 0.02 ( 7%) sys 0.65 ( 6%) wall 6675 kB ( 3%) ggc tree FRE : 0.23 ( 2%) usr 0.02 ( 7%) sys 0.24 ( 2%) wall 801 kB ( 0%) ggc tree forward propagate: 0.06 ( 1%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 751 kB ( 0%) ggc tree aggressive DCE : 0.09 ( 1%) usr 0.00 ( 0%) sys 0.16 ( 1%) wall 2770 kB ( 1%) ggc tree DSE : 0.06 ( 1%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 34 kB ( 0%) ggc scev constant prop: 0.06 ( 1%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 4368 kB ( 2%) ggc tree iv optimization : 0.22 ( 2%) usr 0.02 ( 7%) sys 0.27 ( 2%) wall 18289 kB ( 9%) ggc dominance computation : 0.07 ( 1%) usr 0.01 ( 3%) sys 0.08 ( 1%) wall 0 kB ( 0%) ggc out of ssa: 0.08 ( 1%) usr 0.00 ( 0%) sys 0.13 ( 1%) wall 3 kB ( 0%) ggc expand: 1.08 ( 9%) usr 0.00 ( 0%) sys 1.08 ( 9%) wall 17470 kB ( 9%) ggc forward prop : 0.16 ( 1%) usr 0.00 ( 0%) sys 0.14 ( 1%) wall 2050 kB ( 1%) ggc CSE : 0.36 ( 3%) usr 0.00 ( 0%) sys 0.30 ( 3%) wall 173 kB ( 0%) ggc dead store elim1 : 0.10 ( 1%) usr 0.00 ( 0%) sys 0.11 ( 1%) wall 1638 kB ( 1%) ggc dead store elim2 : 0.11 ( 1%) usr 0.00 ( 0%) sys 0.13 ( 1%) wall 1696 kB ( 1%) ggc loop invariant motion : 0.07 ( 1%) usr 0.00 ( 0%) sys 0.10 ( 1%) wall 0 kB ( 0%) ggc CPROP : 0.19 ( 2%) usr 0.00 ( 0%) sys 0.22 ( 2%) wall 2907 kB ( 1%) ggc PRE : 0.08 ( 1%) usr 0.00 ( 0%) sys 0.09 ( 1%) wall 89 kB ( 0%) ggc CSE 2 : 0.28 ( 2%) usr 0.00 ( 0%) sys 0.20 ( 2%) wall 118 kB ( 0%) ggc combiner : 0.36 ( 3%) usr 0.00 ( 0%) sys 0.42 ( 4%) wall 7042 kB ( 3%) ggc integrated RA : 0.56 ( 5%) usr 0.00 ( 0%) sys 0.52 ( 4%) wall 2972 kB ( 1%) ggc reload: 0.30 ( 3%) usr 0.00 ( 0%) sys 0.34 ( 3%) wall 833 kB ( 0%) ggc reload CSE regs : 0.27 ( 2%) usr 0.00 ( 0%) sys 0.29 ( 2%) wall 3270 kB ( 2%) ggc hard reg cprop: 0.06 ( 1%) usr 0.00 ( 0%) sys 0.07 ( 1%) wall 21 kB ( 0%) ggc scheduling 2 : 0.38 ( 3%) usr 0.00 ( 0%) sys 0.40 ( 3%) wall 211 kB ( 0%) ggc reorder blocks: 0.07 ( 1%) usr 0.00 ( 0%) sys 0.08 ( 1%) wall 2178 kB ( 1%) ggc final : 0.16 ( 1%) usr 0.01 ( 3%) sys 0.15 ( 1%) wall 99
[Bug libobjc/47031] libobjc uses mutexes for properties
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031 --- Comment #8 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2011-01-08 16:14:28 UTC --- Yeah, but Linux is just one of the many OSes supported by GCC. And I don't know of any other OS that uses futexes fors pthread mutexes. It would still be good to try a worst-case benchmark of spinlocks in the highly contended case. I am assuming the performance would be really really bad, but then I may just be wrong. ;-) As I said: I doubt it, as it's only 10 spins and then the control is given to another thread. Benchmarking Mutexes, Futexes and Spinlocks in the highligh contended case would be interesting. I guess all three are almost equal in this case, but differ a lot in the less contended case.
[Bug tree-optimization/21485] [4.3/4.4/4.5/4.6 Regression] missed load PRE, PRE makes i?86 suck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2008-10-03 23:54:40 |2011-02-06 23:54:40 CC||hubicka at gcc dot gnu.org, ||vmakarov at redhat dot com Known to fail||4.6.0 --- Comment #44 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 16:21:07 UTC --- Seems that even in IRA world we made no progress j...@evans:/abuild/jh/trunk-3/build-inst2/gcc ./xgcc -B ./ -O3 reg.i j...@evans:/abuild/jh/trunk-3/build-inst2/gcc tim e./a.out If 'tim' is not a typo you can run the following command to lookup the package that contains the binary: command-not-found tim bash: tim: command not found j...@evans:/abuild/jh/trunk-3/build-inst2/gcc time ./a.out 1000.8 real0m5.179s user0m5.176s sys 0m0.000s j...@evans:/abuild/jh/trunk-3/build-inst2/gcc gcc-4.3 -O3 reg.i j...@evans:/abuild/jh/trunk-3/build-inst2/gcc time ./a.out 1180.8 real0m5.195s user0m5.192s sys 0m0.000s j...@evans:/abuild/jh/trunk-3/build-inst2/gcc -fno-tree-pre -fno-inline -fschedule-insns makes no difference Adding vladimir to list as it is partly RA issue
[Bug tree-optimization/46469] [4.6 Regression] ICE: verify_cgraph_node failed: inline clone is needed at -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46469 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 16:34:03 UTC --- Author: hubicka Date: Sat Jan 8 16:33:57 2011 New Revision: 168598 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168598 Log: PR tree-optmization/46469 * ipa.c (function_and_variable_visibility): Clear needed flags on nodes with external decls; handle weakrefs merging correctly. * g++.dg/torture/pr46469.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr46469.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 --- Comment #4 from Dave Korn davek at gcc dot gnu.org 2011-01-08 16:35:31 UTC --- (In reply to comment #3) A simple test in PR47116: http://gcc.gnu.org/bugzilla/attachment.cgi?id=22866 Thankyou, that should make debugging it easier :)
[Bug tree-optimization/46469] [4.6 Regression] ICE: verify_cgraph_node failed: inline clone is needed at -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46469 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 16:37:20 UTC --- Fixed.
[Bug fortran/47224] New: ICE with procedure pointer component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47224 Summary: ICE with procedure pointer component Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: m.a.hul...@tue.nl The code below gives: t.f90: In function ‘poisson_natboun_surface’: t.f90:23:0: internal compiler error: in gfc_walk_variable_expr, at fortran/trans-array.c:7325 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Note, that if xg(:) is replaced with xg it compiles normally. module element_defs_m use kind_defs_m type coefficients_t procedure (dum_vfunc), pointer, nopass :: vfunc = null() end type coefficients_t contains function dum_vfunc ( n, x ) integer, intent(in) :: n real, intent(in), dimension(:) :: x real, dimension(n) :: dum_vfunc dum_vfunc = 0 end function dum_vfunc end module element_defs_m module poisson_elements_m use element_defs_m implicit none contains subroutine poisson_natboun_surface ( coefficients ) type(coefficients_t), intent(in) :: coefficients real, allocatable, dimension(:) :: xg, normal real :: a integer :: ndim = 3 a = dot_product ( normal, coefficients%vfunc ( ndim, xg(:) ) ) end subroutine poisson_natboun_surface end module poisson_elements_m
[Bug lto/47225] New: [4.6.0 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225
Summary: [4.6.0 regression]: cross-compile fails while
configuring libgcc with xgcc: fatal error:
-fuse-linker-plugin, but liblto_plugin.so not found
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: john.tyt...@aaug.net
Cross compile 4.6.0 trunk r168599, target arm-unknown-eabi configured as:
configure --target=arm-unknown-eabi
--prefix=/home/joty/projects/gccsdk/riscos7/cross
--with-gmp=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc
--with-mpfr=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc
--with-mpc=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc
--with-system-zlib
--with-ppl=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc
--with-host-libstdcxx=-Wl,-lstdc++
--with-cloog=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc
--enable-lto
--with-libelf=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc
--disable-threads --disable-multilib --disable-shared --with-newlib
--enable-interwork --disable-nls --disable-libquadmath
--enable-checking=release --enable-languages=c,c++
fails while configuring arm-unknown-eabi/libgcc with:
--8--
configure:3020:
/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/./gcc/xgcc
-B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/./gcc/
-nostdinc
-B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/newlib/
-isystem
/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/newlib/targ-include
-isystem
/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/newlib/libc/include
-B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libgloss/arm
-L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libgloss/libnosys
-L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libgloss/arm
-B/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/bin/
-B/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/lib/ -isystem
/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/include -isystem
/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/sys-include-o
conftest -g -O2 conftest.c 5
xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.
configure:3023: $? = 1
configure:3211: checking for suffix of object files
configure:3233:
/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/./gcc/xgcc
-B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/./gcc/
-nostdinc
-B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/newlib/
-isystem
/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/newlib/targ-include
-isystem
/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/newlib/libc/include
-B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libgloss/arm
-L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libgloss/libnosys
-L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libgloss/arm
-B/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/bin/
-B/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/lib/ -isystem
/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/include -isystem
/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/sys-include-c -g
-O2 conftest.c 5
xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.
configure:3237: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL http://www.gnu.org/software/libgcc/;
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3251: error: in
`/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libgcc':
configure:3254: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
--8--
There is indeed no liblto_plugin.so found in my build tree.
With r168592 I had the last confirmed successful build.
Re: [Bug lto/47225] New: [4.6.0 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
There is indeed no liblto_plugin.so found in my build tree. With r168592 I had the last confirmed successful build. Seems like plugin autodetection somehow screws up. Do you get the lto-plugin/Makefile configured? What is it building there? Honza
[Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #1 from Jan Hubicka hubicka at ucw dot cz 2011-01-08 17:58:59 UTC --- There is indeed no liblto_plugin.so found in my build tree. With r168592 I had the last confirmed successful build. Seems like plugin autodetection somehow screws up. Do you get the lto-plugin/Makefile configured? What is it building there? Honza
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 --- Comment #5 from Dave Korn davek at gcc dot gnu.org 2011-01-08 18:06:07 UTC --- Bug is caused by the change at rev 167795 applied to fix PR46667. http://gcc.gnu.org/viewcvs?view=revisionrevision=167795
[Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-01-08 18:07:00 UTC --- I got the same failure with gold: FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto -flto-partition=none execution test FAIL: g++.dg/torture/stackalign/unwind-0.C -O2 -flto -flto-partition=none (test for excess errors) FAIL: g++.dg/torture/stackalign/unwind-0.C -O2 -flto (test for excess errors) FAIL: g++.dg/torture/stackalign/unwind-1.C -O2 -flto -flto-partition=none (test for excess errors) FAIL: g++.dg/torture/stackalign/unwind-1.C -O2 -flto (test for excess errors) FAIL: g++.dg/torture/stackalign/unwind-2.C -O2 -flto -flto-partition=none (test for excess errors) FAIL: g++.dg/torture/stackalign/unwind-2.C -O2 -flto (test for excess errors) FAIL: g++.dg/torture/stackalign/unwind-3.C -O2 -flto -flto-partition=none (test for excess errors) FAIL: g++.dg/torture/stackalign/unwind-3.C -O2 -flto (test for excess errors) FAIL: g++.dg/torture/stackalign/unwind-4.C -O2 -flto -flto-partition=none (test for excess errors) FAIL: g++.dg/torture/stackalign/unwind-4.C -O2 -flto (test for excess errors) FAIL: g++.dg/torture/stackalign/unwind-5.C -O2 -flto -flto-partition=none (test for excess errors) FAIL: g++.dg/torture/stackalign/unwind-5.C -O2 -flto (test for excess errors) FAIL: g++.dg/torture/stackalign/unwind-6.C -O2 -flto -flto-partition=none (test for excess errors) FAIL: g++.dg/torture/stackalign/unwind-6.C -O2 -flto (test for excess errors)
[Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-01-08 18:20:58 UTC --- (In reply to comment #2) Hmm, this does not seem to be dependent on plugin implementation, but it seems like bug in 32bit only testcase. The testcase seems to use: int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX; int g_ebp, g_ebp_save, g_esp, g_esp_save; int n_error; and __asm__ __volatile__ ( movl %ebp, ASMNAME(g_ebp_save)\n\t movl %esp, ASMNAME(g_esp_save)\n\t ); I guess either g_ebp_save needs externally_visible attribute or the asm statement needs to be modified to use g_ebp_save as an destination. I tried diff --git a/gcc/testsuite/g++.dg/torture/stackalign/test-unwind.h b/gcc/testsuite/g++.dg/torture/stackalign/test-unwind.h index b07b27c..ff56027 100644 --- a/gcc/testsuite/g++.dg/torture/stackalign/test-unwind.h +++ b/gcc/testsuite/g++.dg/torture/stackalign/test-unwind.h @@ -47,8 +47,13 @@ copy (char *p, int size) __builtin_strncpy (p, good, size); } -int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX; -int g_ebp, g_ebp_save, g_esp, g_esp_save; +int g_edi __attribute__((externally_visible)) =INIT_EDI; +int g_esi __attribute__((externally_visible)) =INIT_ESI; +int g_ebx __attribute__((externally_visible)) = INIT_EBX; +int g_ebp __attribute__((externally_visible)); +int g_esp __attribute__((externally_visible)); +int g_ebp_save __attribute__((externally_visible)); +int g_esp_save __attribute__((externally_visible)); int n_error; int and it doesn't make a difference. I think this testcase is yours, so perhaps you can fix it? Was there some reason to use the ASMNAME hack instead of memory output constraint? We want to verify the contents of registers.
[Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #2 from John Tytgat John.Tytgat at aaug dot net 2011-01-08 18:22:14 UTC --- I'm giving the --disable-shared configure option for building cross-compiler as I'm not interested in shared target libraries and it looks like this is passed on to lto-plugin which is only relevant for the host. This is configure call for lto-plugin: --8-- $ /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/lto-plugin/configure --cache-file=./config.cache --with-system-zlib --with-newlib --prefix=/home/joty/projects/gccsdk/riscos7/cross --with-gmp=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --with-mpfr=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --with-mpc=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --with-system-zlib --with-ppl=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --with-host-libstdcxx=-Wl,-lstdc++ --with-cloog=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --enable-lto --with-libelf=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --disable-threads --disable-multilib --disable-shared --with-newlib --enable-interwork --disable-nls --disable-libquadmath --enable-checking=release --enable-languages=c,c++,lto --program-transform-name=s^arm-unknown-eabi- --disable-option-checking --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=arm-unknown-eabi --srcdir=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/lto-plugin --8-- and the buildoutput for the lto-plugin part: --8-- make[4]: Entering directory `/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/lto-plugin' /bin/bash ./libtool --tag=CC --tag=disable-static --mode=compile gcc -DHAVE_CONFIG_H -I. -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/lto-plugin -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/lto-plugin/../include -DHAVE_CONFIG_H -Wall -Werror -O0 -g -c -o lto-plugin.lo /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/lto-plugin/lto-plugin.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/lto-plugin -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/lto-plugin/../include -DHAVE_CONFIG_H -Wall -Werror -O0 -g -c /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/lto-plugin/lto-plugin.c -o lto-plugin.o /bin/bash ./libtool --tag=CC --tag=disable-static --mode=link gcc -Wall -Werror -O0 -g -bindir /home/joty/projects/gccsdk/riscos7/cross/libexec/gcc/arm-unknown-eabi/4.6.0 -o liblto_plugin.la -rpath /home/joty/projects/gccsdk/riscos7/cross/libexec/gcc/arm-unknown-eabi/4.6.0 lto-plugin.lo ../libiberty/pic/libiberty.a *** Warning: Linking the shared library liblto_plugin.la against the *** static library ../libiberty/pic/libiberty.a is not portable! libtool: link: ar rc .libs/liblto_plugin.a ../libiberty/pic/libiberty.a lto-plugin.o libtool: link: ranlib .libs/liblto_plugin.a libtool: link: ( cd .libs rm -f liblto_plugin.la ln -s ../liblto_plugin.la liblto_plugin.la ) /bin/bash ./libtool --tag=disable-static --mode=install /usr/bin/install -c liblto_plugin.la `pwd`/../gcc/ libtool: install: /usr/bin/install -c .libs/liblto_plugin.lai /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/lto-plugin/../gcc/liblto_plugin.la libtool: install: /usr/bin/install -c .libs/liblto_plugin.a /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/lto-plugin/../gcc/liblto_plugin.a libtool: install: chmod 644 /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/lto-plugin/../gcc/liblto_plugin.a libtool: install: ranlib /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/lto-plugin/../gcc/liblto_plugin.a libtool: install: warning: remember to run `libtool --finish /home/joty/projects/gccsdk/riscos7/cross/libexec/gcc/arm-unknown-eabi/4.6.0' make all-am make[5]: Entering directory `/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/lto-plugin' make[5]: Leaving directory `/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/lto-plugin' make[4]: Leaving directory `/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/lto-plugin' --8-- I.e. only static library of lto-plugin gets built.
Re: [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
I tried
-int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX;
-int g_ebp, g_ebp_save, g_esp, g_esp_save;
+int g_edi __attribute__((externally_visible)) =INIT_EDI;
+int g_esi __attribute__((externally_visible)) =INIT_ESI;
+int g_ebx __attribute__((externally_visible)) = INIT_EBX;
+int g_ebp __attribute__((externally_visible));
+int g_esp __attribute__((externally_visible));
+int g_ebp_save __attribute__((externally_visible));
+int g_esp_save __attribute__((externally_visible));
Weird, for me it seems to work as expected:
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[1]# cat t.c
__attribute__ ((externally_visible))
int a;
main()
{
asm(movl %eax, a);
}
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t.c -flto
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# cat t2.c
int a;
main()
{
asm(movl %eax, a);
}
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t2.c -flto
/abuild/jh/trunk-install/x86_64-unknown-linux-gnu/bin/ld:
/tmp/ccP7Lfjk.ltrans0.ltrans.o: in function
main:ccP7Lfjk.ltrans0.o(.text.startup+0x3): error: undefined reference to 'a'
collect2: ld returned 1 exit status
Perhaps some extra var needs annotation?
int n_error;
int
and it doesn't make a difference.
I think this testcase is yours, so perhaps you can fix it?
Was there some reason to use the ASMNAME hack instead of memory output
constraint?
We want to verify the contents of registers.
Still, I think the cleanest way is:
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# cat t3.c
int a;
main()
{
asm __volatile__ (movl %%eax, %0:=m(a));
}
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t3.c -flto
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]#
It avoids the ASMNAME hack and makes outputs explicit.
[Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
--- Comment #5 from Jan Hubicka hubicka at ucw dot cz 2011-01-08 18:54:30 UTC
---
I tried
-int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX;
-int g_ebp, g_ebp_save, g_esp, g_esp_save;
+int g_edi __attribute__((externally_visible)) =INIT_EDI;
+int g_esi __attribute__((externally_visible)) =INIT_ESI;
+int g_ebx __attribute__((externally_visible)) = INIT_EBX;
+int g_ebp __attribute__((externally_visible));
+int g_esp __attribute__((externally_visible));
+int g_ebp_save __attribute__((externally_visible));
+int g_esp_save __attribute__((externally_visible));
Weird, for me it seems to work as expected:
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[1]# cat t.c
__attribute__ ((externally_visible))
int a;
main()
{
asm(movl %eax, a);
}
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t.c -flto
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# cat t2.c
int a;
main()
{
asm(movl %eax, a);
}
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t2.c -flto
/abuild/jh/trunk-install/x86_64-unknown-linux-gnu/bin/ld:
/tmp/ccP7Lfjk.ltrans0.ltrans.o: in function
main:ccP7Lfjk.ltrans0.o(.text.startup+0x3): error: undefined reference to 'a'
collect2: ld returned 1 exit status
Perhaps some extra var needs annotation?
int n_error;
int
and it doesn't make a difference.
I think this testcase is yours, so perhaps you can fix it?
Was there some reason to use the ASMNAME hack instead of memory output
constraint?
We want to verify the contents of registers.
Still, I think the cleanest way is:
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# cat t3.c
int a;
main()
{
asm __volatile__ (movl %%eax, %0:=m(a));
}
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t3.c -flto
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]#
It avoids the ASMNAME hack and makes outputs explicit.
Re: [Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
I.e. only static library of lto-plugin gets built. Ahh, static library for lto-plugin is of course pointless thing. I guess we want to disable plugin when --disable-shared is passed. I will see if my autoconf-fu is on par to do so. Still, it is bit sad situation - you are right that you are not interested in shared libraries for cross, but you might be still interested in plugin for LTO. Either we need to document the dependency (and warn when plugin is available but shared libs are disabled) or just enable shared libs for the plugin itself. I am adding paolo to CC, he should know best what to do here. Honza
[Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #3 from Jan Hubicka hubicka at ucw dot cz 2011-01-08 18:58:09 UTC --- I.e. only static library of lto-plugin gets built. Ahh, static library for lto-plugin is of course pointless thing. I guess we want to disable plugin when --disable-shared is passed. I will see if my autoconf-fu is on par to do so. Still, it is bit sad situation - you are right that you are not interested in shared libraries for cross, but you might be still interested in plugin for LTO. Either we need to document the dependency (and warn when plugin is available but shared libs are disabled) or just enable shared libs for the plugin itself. I am adding paolo to CC, he should know best what to do here. Honza
Re: [Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
Hi, is this dup of PR47225? I.e. is the --disable-shared the problem? Honza
[Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47223 --- Comment #7 from Jan Hubicka hubicka at ucw dot cz 2011-01-08 18:58:46 UTC --- Hi, is this dup of PR47225? I.e. is the --disable-shared the problem? Honza
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 --- Comment #6 from Dave Korn davek at gcc dot gnu.org 2011-01-08 19:00:25 UTC --- (In reply to comment #5) Bug is caused by the change at rev 167795 applied to fix PR46667. http://gcc.gnu.org/viewcvs?view=revisionrevision=167795 Full details at http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00446.html: It turns out that resolve_unique_function() is not called at all for the thunk function any more, where previously it was called from assemble_start_function called from cgraph_expand_function. This is because gimple_expand_cfg() isn't called for these thunk functions; they are emitted through a call chain that looks like: (gdb) bt #0 assemble_start_function (decl=0x7fe32f00, fnname=0x7fe41860 _ZThn4_N7FooBase3BarEv) at /gnu/gcc/gcc-patched/gcc/varasm.c:1524 #1 0x007aa73c in cgraph_expand_function (node=0x7ff80c30) at /gnu/gcc/gcc-patched/gcc/cgraphunit.c:1328 #2 0x007ad210 in cgraph_optimize () at /gnu/gcc/gcc-patched/gcc/cgraphunit.c:1567 #3 0x007ad69a in cgraph_finalize_compilation_unit () at /gnu/gcc/gcc-patched/gcc/cgraphunit.c:1031 #4 0x004ce825 in cp_write_global_declarations () at /gnu/gcc/gcc-patched/gcc/cp/decl2.c:3974 #5 0x0080ed6d in toplev_main (argc=14, argv=0x5079f78) at /gnu/gcc/gcc-patched/gcc/toplev.c:591 #6 0x0060699f in main (argc=Cannot access memory at address 0x0 ) at /gnu/gcc/gcc-patched/gcc/main.c:36 That's the main part of it.
Re: [Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
Hi,
since lto plugin already enables shared libiberty, this patch extends the
machinery
for plugin itself too.
Does it fix your problem? I seem to be able to bootstrap (C only) with
disable-shared.
Index: configure
===
--- configure (revision 168596)
+++ configure (working copy)
@@ -640,6 +640,7 @@ CFLAGS_FOR_TARGET
DEBUG_PREFIX_CFLAGS_FOR_TARGET
SYSROOT_CFLAGS_FOR_TARGET
stage1_languages
+extra_host_lto_plugin_configure_flags
extra_host_libiberty_configure_flags
clooginc
clooglibs
@@ -6237,6 +6238,7 @@ if test -d ${srcdir}/gcc; then
# If LTO is enabled, add the LTO front end.
extra_host_libiberty_configure_flags=
+ extra_host_lto_plugin_configure_flags=
if test $enable_lto = yes ; then
case ,${enable_languages}, in
*,lto,*) ;;
@@ -6245,10 +6247,12 @@ if test -d ${srcdir}/gcc; then
if test ${build_lto_plugin} = yes ; then
configdirs=$configdirs lto-plugin
extra_host_libiberty_configure_flags=--enable-shared
+ extra_host_lto_plugin_configure_flags=--enable-shared
fi
fi
+
missing_languages=`echo ,$enable_languages, | sed -e s/,all,/,/ -e
s/,c,/,/ `
potential_languages=,c,
Index: configure.ac
===
--- configure.ac(revision 168596)
+++ configure.ac(working copy)
@@ -1810,6 +1810,7 @@ if test -d ${srcdir}/gcc; then
# If LTO is enabled, add the LTO front end.
extra_host_libiberty_configure_flags=
+ extra_host_lto_plugin_configure_flags=
if test $enable_lto = yes ; then
case ,${enable_languages}, in
*,lto,*) ;;
@@ -1818,9 +1819,11 @@ if test -d ${srcdir}/gcc; then
if test ${build_lto_plugin} = yes ; then
configdirs=$configdirs lto-plugin
extra_host_libiberty_configure_flags=--enable-shared
+ extra_host_lto_plugin_configure_flags=--enable-shared
fi
fi
AC_SUBST(extra_host_libiberty_configure_flags)
+ AC_SUBST(extra_host_lto_plugin_configure_flags)
missing_languages=`echo ,$enable_languages, | sed -e s/,all,/,/ -e
s/,c,/,/ `
potential_languages=,c,
Index: Makefile.def
===
--- Makefile.def(revision 168596)
+++ Makefile.def(working copy)
@@ -145,7 +145,8 @@ host_modules= { module= libtermcap; no_c
missing=maintainer-clean; };
host_modules= { module= utils; no_check=true; };
host_modules= { module= gnattools; };
-host_modules= { module= lto-plugin; bootstrap=true; };
+host_modules= { module= lto-plugin; bootstrap=true;
+
extra_configure_flags='@extra_host_lto_plugin_configure_flags@'; };
target_modules = { module= libstdc++-v3;
bootstrap=true;
Index: Makefile.in
===
--- Makefile.in (revision 168596)
+++ Makefile.in (working copy)
@@ -45248,7 +45248,7 @@ configure-lto-plugin:
libsrcdir=$$s/lto-plugin; \
$(SHELL) $${libsrcdir}/configure \
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
- --target=${target_alias} $${srcdiroption} \
+ --target=${target_alias} $${srcdiroption}
@extra_host_lto_plugin_configure_flags@ \
|| exit 1
@endif lto-plugin
@@ -45282,7 +45282,8 @@ configure-stage1-lto-plugin:
$(SHELL) $${libsrcdir}/configure \
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} $${srcdiroption} \
- $(STAGE1_CONFIGURE_FLAGS)
+ $(STAGE1_CONFIGURE_FLAGS) \
+ @extra_host_lto_plugin_configure_flags@
@endif lto-plugin-bootstrap
.PHONY: configure-stage2-lto-plugin maybe-configure-stage2-lto-plugin
@@ -45315,7 +45316,8 @@ configure-stage2-lto-plugin:
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} $${srcdiroption} \
--with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGE2_CONFIGURE_FLAGS)
+ $(STAGE2_CONFIGURE_FLAGS) \
+ @extra_host_lto_plugin_configure_flags@
@endif lto-plugin-bootstrap
.PHONY: configure-stage3-lto-plugin maybe-configure-stage3-lto-plugin
@@ -45348,7 +45350,8 @@ configure-stage3-lto-plugin:
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} $${srcdiroption} \
--with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGE3_CONFIGURE_FLAGS)
+ $(STAGE3_CONFIGURE_FLAGS) \
+ @extra_host_lto_plugin_configure_flags@
@endif lto-plugin-bootstrap
.PHONY: configure-stage4-lto-plugin maybe-configure-stage4-lto-plugin
@@ -45381,7 +45384,8 @@ configure-stage4-lto-plugin:
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} $${srcdiroption} \
--with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGE4_CONFIGURE_FLAGS)
+
[Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz 2011-01-08 19:15:24 UTC
---
Hi,
since lto plugin already enables shared libiberty, this patch extends the
machinery
for plugin itself too.
Does it fix your problem? I seem to be able to bootstrap (C only) with
disable-shared.
Index: configure
===
--- configure(revision 168596)
+++ configure(working copy)
@@ -640,6 +640,7 @@ CFLAGS_FOR_TARGET
DEBUG_PREFIX_CFLAGS_FOR_TARGET
SYSROOT_CFLAGS_FOR_TARGET
stage1_languages
+extra_host_lto_plugin_configure_flags
extra_host_libiberty_configure_flags
clooginc
clooglibs
@@ -6237,6 +6238,7 @@ if test -d ${srcdir}/gcc; then
# If LTO is enabled, add the LTO front end.
extra_host_libiberty_configure_flags=
+ extra_host_lto_plugin_configure_flags=
if test $enable_lto = yes ; then
case ,${enable_languages}, in
*,lto,*) ;;
@@ -6245,10 +6247,12 @@ if test -d ${srcdir}/gcc; then
if test ${build_lto_plugin} = yes ; then
configdirs=$configdirs lto-plugin
extra_host_libiberty_configure_flags=--enable-shared
+ extra_host_lto_plugin_configure_flags=--enable-shared
fi
fi
+
missing_languages=`echo ,$enable_languages, | sed -e s/,all,/,/ -e
s/,c,/,/ `
potential_languages=,c,
Index: configure.ac
===
--- configure.ac(revision 168596)
+++ configure.ac(working copy)
@@ -1810,6 +1810,7 @@ if test -d ${srcdir}/gcc; then
# If LTO is enabled, add the LTO front end.
extra_host_libiberty_configure_flags=
+ extra_host_lto_plugin_configure_flags=
if test $enable_lto = yes ; then
case ,${enable_languages}, in
*,lto,*) ;;
@@ -1818,9 +1819,11 @@ if test -d ${srcdir}/gcc; then
if test ${build_lto_plugin} = yes ; then
configdirs=$configdirs lto-plugin
extra_host_libiberty_configure_flags=--enable-shared
+ extra_host_lto_plugin_configure_flags=--enable-shared
fi
fi
AC_SUBST(extra_host_libiberty_configure_flags)
+ AC_SUBST(extra_host_lto_plugin_configure_flags)
missing_languages=`echo ,$enable_languages, | sed -e s/,all,/,/ -e
s/,c,/,/ `
potential_languages=,c,
Index: Makefile.def
===
--- Makefile.def(revision 168596)
+++ Makefile.def(working copy)
@@ -145,7 +145,8 @@ host_modules= { module= libtermcap; no_c
missing=maintainer-clean; };
host_modules= { module= utils; no_check=true; };
host_modules= { module= gnattools; };
-host_modules= { module= lto-plugin; bootstrap=true; };
+host_modules= { module= lto-plugin; bootstrap=true;
+extra_configure_flags='@extra_host_lto_plugin_configure_flags@'; };
target_modules = { module= libstdc++-v3;
bootstrap=true;
Index: Makefile.in
===
--- Makefile.in(revision 168596)
+++ Makefile.in(working copy)
@@ -45248,7 +45248,7 @@ configure-lto-plugin:
libsrcdir=$$s/lto-plugin; \
$(SHELL) $${libsrcdir}/configure \
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
- --target=${target_alias} $${srcdiroption} \
+ --target=${target_alias} $${srcdiroption}
@extra_host_lto_plugin_configure_flags@ \
|| exit 1
@endif lto-plugin
@@ -45282,7 +45282,8 @@ configure-stage1-lto-plugin:
$(SHELL) $${libsrcdir}/configure \
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} $${srcdiroption} \
- $(STAGE1_CONFIGURE_FLAGS)
+ $(STAGE1_CONFIGURE_FLAGS) \
+ @extra_host_lto_plugin_configure_flags@
@endif lto-plugin-bootstrap
.PHONY: configure-stage2-lto-plugin maybe-configure-stage2-lto-plugin
@@ -45315,7 +45316,8 @@ configure-stage2-lto-plugin:
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} $${srcdiroption} \
--with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGE2_CONFIGURE_FLAGS)
+ $(STAGE2_CONFIGURE_FLAGS) \
+ @extra_host_lto_plugin_configure_flags@
@endif lto-plugin-bootstrap
.PHONY: configure-stage3-lto-plugin maybe-configure-stage3-lto-plugin
@@ -45348,7 +45350,8 @@ configure-stage3-lto-plugin:
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} $${srcdiroption} \
--with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGE3_CONFIGURE_FLAGS)
+ $(STAGE3_CONFIGURE_FLAGS) \
+ @extra_host_lto_plugin_configure_flags@
@endif lto-plugin-bootstrap
.PHONY: configure-stage4-lto-plugin maybe-configure-stage4-lto-plugin
@@ -45381,7 +45384,8 @@ configure-stage4-lto-plugin:
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} $${srcdiroption} \
--with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGE4_CONFIGURE_FLAGS)
+
Re: [Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
Hi, I posed patch to the aforementioned PR, hopefully it will fix this one too.
[Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47223 --- Comment #8 from Jan Hubicka hubicka at ucw dot cz 2011-01-08 19:16:09 UTC --- Hi, I posed patch to the aforementioned PR, hopefully it will fix this one too.
[Bug fortran/46896] [4.3/4.4/4.5/4.6 Regression] Wrong code with transpose(a) passed to subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46896 --- Comment #13 from Paul Thomas pault at gcc dot gnu.org 2011-01-08 19:17:06 UTC --- Author: pault Date: Sat Jan 8 19:17:03 2011 New Revision: 168600 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168600 Log: 2011-01-08 Paul Thomas pa...@gcc.gnu.org PR fortran/46896 * trans-expr.c (gfc_conv_procedure_call): With a non-copying procedure argument (eg TRANSPOSE) use a temporary if there is any chance of aliasing due to host or use association. (arrayfunc_assign_needs_temporary): Correct logic for function results and do not use a temporary for implicitly PURE variables. Use a temporary for Cray pointees. * symbol.c (gfc_add_save): Explicit SAVE not compatible with implicit pureness of containing procedure. * decl.c (match_old_style_init, gfc_match_data): Where decl would fail in PURE procedure, set implicit_pure to zero. * gfortran.h : Add implicit_pure to structure symbol_attr and add prototype for function gfc_implicit_pure. * expr.c (gfc_check_pointer_assign, gfc_check_vardef_context): Where decl would fail in PURE procedure, reset implicit_pure. * io.c (match_vtag, gfc_match_open, gfc_match_close, gfc_match_print, gfc_match_inquire, gfc_match_wait): The same. * match.c (gfc_match_critical, gfc_match_stopcode, sync_statement, gfc_match_allocate, gfc_match_deallocate): The same. * parse.c (decode_omp_directive): The same. (parse_contained): If not PURE, set implicit pure attribute. * resolve.c (resolve_formal_arglist, resolve_structure_cons, resolve_function, resolve_ordinary_assign) : The same. (gfc_implicit_pure): New function. * module.c (mio_symbol_attribute): Introduce AB_IMPLICIT_PURE to ab_attribute enum and use it in this function. 2011-01-08 Paul Thomas pa...@gcc.gnu.org PR fortran/46896 * gfortran.dg/transpose_optimization_2.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/transpose_optimization_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/io.c trunk/gcc/fortran/match.c trunk/gcc/fortran/module.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.08 19:19:57 CC||bonzini at gnu dot org, ||hubicka at gcc dot gnu.org AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 19:19:57 UTC --- mine.
[Bug lto/41782] lto/gold: -flto -user-linker-plugin dies with internal error in gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41782 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hubicka at gcc dot gnu.org Resolution||WORKSFORME --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 19:44:30 UTC --- Works for me evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# /abuild/jh/trunk-install/bin/ld --version GNU gold (GNU Binutils; SUSE Linux Enterprise 11 2.20.0.20100122-0.7.9) 1.9 Copyright 2008 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# /abuild/jh/trunk-install/bin/g++ --version g++ (GCC) 4.6.0 20110108 (experimental) Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. So I guess the problem is fixed at 4.6 branch - there was a lot of improvments for plugin symtabs there.
[Bug objc/47078] [4.6 Regression] ICE on invalid type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47078 --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-01-08 19:44:34 UTC --- Author: nicola Date: Sat Jan 8 19:44:30 2011 New Revision: 168601 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168601 Log: In gcc/: 2011-01-08 Nicola Pero nicola.p...@meta-innovation.com PR objc/47078 * c-parser.c (c_parser_objc_type_name): If the type is unknown, for error recovery purposes behave as if it was not specified so that the default type is usd. In gcc/testsuite/: 2011-01-08 Nicola Pero nicola.p...@meta-innovation.com PR objc/47078 * objc.dg/invalid-method-2.m: New. * obj-c++.dg/invalid-method-2.mm: New. In gcc/cp/: 2011-01-08 Nicola Pero nicola.p...@meta-innovation.com PR objc/47078 * parser.c (cp_parser_objc_typename): If the type is unknown, for error recovery purposes behave as if it was not specified so that the default type is used. Added: trunk/gcc/testsuite/obj-c++.dg/invalid-method-2.mm trunk/gcc/testsuite/objc.dg/invalid-method-2.m Modified: trunk/gcc/ChangeLog trunk/gcc/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug objc/47078] [4.6 Regression] ICE on invalid type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47078 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.6.0 Resolution||FIXED --- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2011-01-08 19:46:16 UTC --- Fixed in trunk. Thanks
[Bug lto/42402] ICE in propagate, at ipa-reference.c:1244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42402 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hubicka at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 19:48:50 UTC --- Fixed in 4.6 branch, given the state of LTO support on 4.5, I don't think there are plans to backport all the (quite involved) changes.
[Bug lto/42613] -save-temps doesn't work completely for -fwhopr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42613 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 19:50:50 UTC --- I think the original issue was fixed. I am still bothered with -save-temps sometimes sending the files into /tmp however.
[Bug objc/46710] fast enumeration tests failing on ia64-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46710 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.6.0 Known to fail||4.6.0 Severity|major |critical --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-01-08 19:54:20 UTC --- This is still happening - http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg00641.html It's very bad because from the test results it seems that the code compiles, but then fails when executing. :-( I asked Andreas for more information, but he couldn't provide any. Thanks
[Bug lto/43659] -flto doesn't remember -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43659 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.08 19:54:57 CC||hubicka at gcc dot gnu.org Known to work||4.6.0 Ever Confirmed|0 |1 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 19:54:57 UTC --- This was fixed on mainline by patch of mine http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00210.html perhaps it can be backported.
[Bug lto/43891] -fwropr misses mismatch of function return types causing an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43891 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 19:56:59 UTC --- Richard, this works for me and I think we was chatting about fixing this issue some time ago. So shold be fixed on mainline.
[Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #6 from John Tytgat John.Tytgat at aaug dot net 2011-01-08 19:58:00 UTC --- That patch results in successful build. And lto works as well.
[Bug lto/44904] Maybe bogus Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? warnings in Mozilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44904 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 20:02:15 UTC --- Seems gone now. evans:/abuild/jh/trunk-3/build-inst2/gcc/tc/tc2/:[0]# /abuild/jh/trunk-install/bin/g++ -O2 -flto -r -nostdlib tc/*.ii ../../../layout/style/nsCSSStyleRule.cpp: In member function 'DOMCSSStyleRuleImpl* DOMCSSDeclarationImpl::DomRule()': ../../../layout/style/nsCSSStyleRule.cpp:1037:53: warning: invalid access to non-static data member 'DOMCSSStyleRuleImpl::mDOMDeclaration' of NULL object [-Winvalid-offsetof] ../../../layout/style/nsCSSStyleRule.cpp:1037:53: warning: (perhaps the 'offsetof' macro was used incorrectly) [-Winvalid-offsetof] In file included from ../../../layout/style/nsCSSRuleProcessor.h:52:0, from ../../../layout/style/nsCSSStyleSheet.cpp:48: ../../../layout/style/nsCSSRules.h: In member function 'nsCSSFontFaceRule* nsCSSFontFaceStyleDecl::ContainingRule()': ../../../layout/style/nsCSSRules.h:292:77: warning: invalid access to non-static data member 'nsCSSFontFaceRule::mDecl' of NULL object [-Winvalid-offsetof] ../../../layout/style/nsCSSRules.h:292:77: warning: (perhaps the 'offsetof' macro was used incorrectly) [-Winvalid-offsetof] ../../../layout/style/nsCSSRules.h: In member function 'const nsCSSFontFaceRule* nsCSSFontFaceStyleDecl::ContainingRule() const': ../../../layout/style/nsCSSRules.h:299:83: warning: invalid access to non-static data member 'nsCSSFontFaceRule::mDecl' of NULL object [-Winvalid-offsetof] ../../../layout/style/nsCSSRules.h:299:83: warning: (perhaps the 'offsetof' macro was used incorrectly) [-Winvalid-offsetof]
[Bug target/45007] LTO ICE with __builtin_ms_va_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45007 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Known to work||4.6.0 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 20:04:32 UTC --- Works with mainline tree.
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 20:08:26 UTC --- Does --param hot-bb-frequency-fraction=10 work here? This is weird!-( I have done the following profiling and it shows that -flto prevents the inlining of __perdida_m_MOD_perdida, while -fno-inline-functions restores it. This contradicts what the manual says: -finline-functions Integrate all simple functions into their callers. The compiler heuristically decides which functions are simple enough to be worth integrating in this way. Disabling autoinlining of small function can allow other inlining (inlining functions called once or inlining for size), so this is not completely unexpected.
[Bug lto/46083] gcc.dg/initpri1.c FAILs with -flto/-fwhopr (attribute constructor/destructor doesn't work)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46083 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.08 20:14:33 AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 20:14:33 UTC --- mine.
[Bug lto/46492] Several C++ LTO testcases fail to link on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46492 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.08 20:40:48 Ever Confirmed|0 |1 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 20:40:48 UTC --- Is this fixed with http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00081.html (already comitted)? It seems like the same issue.
[Bug lto/46578] 416.gamess in SPEC CPU 2006 is miscompiled by LTO with gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46578 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 20:44:28 UTC --- Are there any noticeable differences in the resolution files passed to the plugin?
[Bug debug/47209] ICE: SIGSEGV in should_emit_struct_debug (dwarf2out.c:627) with -f{no-,}emit-struct-debug-{baseonly,reduced} -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47209
Zdenek Sojka zsojka at seznam dot cz changed:
What|Removed |Added
Summary|ICE: SIGSEGV in |ICE: SIGSEGV in
|should_emit_struct_debug|should_emit_struct_debug
|(dwarf2out.c:627) with |(dwarf2out.c:627) with
|-femit-struct-debug-baseonl |-f{no-,}emit-struct-debug-{
|y -g|baseonly,reduced} -g
--- Comment #3 from Zdenek Sojka zsojka at seznam dot cz 2011-01-08 20:45:38
UTC ---
It fails the same way with -f{no-,}emit-struct-debug-reduced and
-f{no-,}emit-struct-debug-baseonly , with very similiar crash location and the
same backtrace:
$ gcc -femit-struct-debug-reduced -g pr47209.C
==15753== Invalid read of size 2
==15753==at 0x78AC90: should_emit_struct_debug (dwarf2out.c:624)
pr47209.C:6:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ gcc -fno-emit-struct-debug-reduced -g pr47209.C
==15579== Invalid read of size 2
==15579==at 0x78AC90: should_emit_struct_debug (dwarf2out.c:624)
pr47209.C:6:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ gcc -femit-struct-debug-baseonly -g pr47209.C
==5087== Invalid read of size 2
==5087==at 0x78AC0E: should_emit_struct_debug (dwarf2out.c:627)
pr47209.C:6:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ gcc -fno-emit-struct-debug-baseonly -g pr47209.C
==13603== Invalid read of size 2
==13603==at 0x78AC0E: should_emit_struct_debug (dwarf2out.c:627)
pr47209.C:6:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
(In reply to comment #1)
I don't know if the code is valid or invalid (I have no clue what is the
meaning of base::foo;).
According to people ##C++ at irc.freenode.org, it is equivalent to using
base::foo;, in some pre-standard notation (if I understood that correctly).
[Bug debug/47209] ICE: SIGSEGV in should_emit_struct_debug (dwarf2out.c:627) with -f{no-,}emit-struct-debug-{baseonly,reduced} -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47209
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2011-01-08 20:55:20
UTC ---
Well, the issue here seems to be that in should_emit_struct_debug
TYPE_STUB_DECL (type) for provided type is a NULL_TREE. In next two
if-statements this result is used unconditionally. I am not sure if the
underlying issue is related to some other place in c++ FE (I assume so), but
following patch at least avoid segfault.
Index: dwarf2out.c
===
--- dwarf2out.c (revision 168601)
+++ dwarf2out.c (working copy)
@@ -620,12 +620,14 @@
return DUMP_GSTRUCT (type, usage, criterion, generic, false, true);
type_decl = TYPE_STUB_DECL (type);
+ if (type_decl != NULL_TREE)
+{
+ if (criterion == DINFO_STRUCT_FILE_SYS DECL_IN_SYSTEM_HEADER
(type_decl))
+ return DUMP_GSTRUCT (type, usage, criterion, generic, false, true);
- if (criterion == DINFO_STRUCT_FILE_SYS DECL_IN_SYSTEM_HEADER (type_decl))
-return DUMP_GSTRUCT (type, usage, criterion, generic, false, true);
-
- if (matches_main_base (DECL_SOURCE_FILE (type_decl)))
-return DUMP_GSTRUCT (type, usage, criterion, generic, true, true);
+ if (matches_main_base (DECL_SOURCE_FILE (type_decl)))
+ return DUMP_GSTRUCT (type, usage, criterion, generic, true, true);
+}
return DUMP_GSTRUCT (type, usage, criterion, generic, false, false);
}
[Bug c++/47226] New: GCC doesn't expand template parameter pack that appears in a lambda-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
Summary: GCC doesn't expand template parameter pack that
appears in a lambda-expression
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com
GCC doesn't like this:
void slurp(...) { }
templateint ...N
void print() {
slurp([]() - int {
(void) N; // or something fancy...
return 0;
}() ...);
}
void f() { print1, 2(); }
Error:
error: parameter packs not expanded with '...':
I think the draft (n3225) says this should expand N and result in:
slurp(
[]() - int {
(void) 1; // or something fancy...
return 0;
}(),
[]() - int {
(void) 2; // or something fancy...
return 0;
}());
[Bug lto/46905] -flto -fno-lto does not disable lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 20:59:58 UTC --- Linker plugin has also problem of doing LTO even when not asked for. I will look into it once slib LTO bits are settled.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #25 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 21:06:27 UTC --- With current mainline and release checking compiler, I can for first time build mozilla with debug info. 7.5GB of RAM is needed.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #26 from Alexey Feldgendler alexey at feldgendler dot ru 2011-01-08 21:10:50 UTC --- This is a great success, although I have to say it's still way too much RAM to ask for. In particular, this excludes the possiblity of compiling on a 32-bit architecture.
[Bug lto/45089] -Os -g -fwhopr dwarf2out ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45089 --- Comment #13 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 21:22:42 UTC --- Confirmed that mozilla now builds with debug info.
[Bug target/45814] ICE in extract_insn, at recog.c:2127
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45814 --- Comment #2 from Ryan Mansfield rmansfield at qnx dot com 2011-01-08 21:23:40 UTC --- Nope, still broken on trunk for me. $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: arm-unknown-linux-gnu Configured with: ../configure --target=arm-unknown-linux-gnu --prefix=//home/ryan/crosstool/4.2-20080312-glibc-2.3.6/arm-unknown-linux-gnu --with-headers=//home/ryan/crosstool/4.2-20080312-glibc-2.3.6/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include --with-local-prefix=//home/ryan/crosstool/4.2-20080312-glibc-2.3.6/arm-unknown-linux-gnu/arm-unknown-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c++ --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 4.6.0 20110108 (experimental) [trunk revision 168603] (GCC) $ ./xgcc -B. -march=armv6 -mfpu=vfp -mfloat-abi=softfp -O3 t.i -mapcs-frame -c t.i: In function 'SendTg': t.i:25:7: warning: incompatible implicit declaration of built-in function 'memset' [enabled by default] t.i:39:1: error: unrecognizable insn: (insn 155 154 156 6 (set (reg:HI 4 r4) (reg:SI 77 s14)) t.i:30 -1 (nil)) t.i:39:1: internal compiler error: in extract_insn, at recog.c:2109 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug lto/44951] debug info ICE in whopr build due to missing -g at compile time.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44951 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 21:26:01 UTC --- This seem to work now. Richi, I think you fixed this some time ago by not zeroing the fields by default?
[Bug c++/44846] Violation of one-definition rule
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44846 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08 21:28:15 UTC --- The workaround was comitted to the mainline, but the duplicated decl issue probably remains.
Re: [Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
There is a lot of room for improvement in the WPA memory use, but I am not sure how much we can still fit in 4.6.0...
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #27 from Jan Hubicka hubicka at ucw dot cz 2011-01-08 21:35:00 UTC --- There is a lot of room for improvement in the WPA memory use, but I am not sure how much we can still fit in 4.6.0...
[Bug fortran/46017] Reject ALLOCATE(a, a%b) as a%b depends on the allocation status of a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46017 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-08 22:05:20 UTC --- Fixed on trunk, closing.
[Bug fortran/43136] Excess copy-in/copy-out with character argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43136 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-08 22:18:31 UTC --- We have to watch out for aliasing here; if foo changes the arguments, we have to have a copy. Compare PR 47065.
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #17 from Laurent GUERBY laurent at guerby dot net 2011-01-08 22:48:51 UTC --- For reference ACATS is now clean on arm-linux as well: http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg00648.html LAST_UPDATED: Fri Jan 7 00:49:12 UTC 2011 (revision 168562) Native configuration is armv7l-unknown-linux-gnueabi === acats Summary === # of expected passes2321 # of unexpected failures0 Thanks Eric :).
[Bug c++/47227] New: GCC ignores conversion function template specializatons if a derived class' conversion function converts to the same type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47227
Summary: GCC ignores conversion function template
specializatons if a derived class' conversion function
converts to the same type
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com
Unless I'm missing something, the following is ambiguous:
templatetypename T1, typename T2
struct A { };
struct base {
templatetypename T2, typename T1
operator AT1, T2();
};
struct derived : base {
templatetypename T1, typename T2
operator AT1, T2();
};
int main() {
derived().operator Aint, int();
}
However, GCC always wants to take the derived class version.
The reason for ambiguity is:
Aparam-#1#1, param-#1#2 is another type than Aparam-#1#2, param-#1#1 (prior
to deduction. When collecting candidates, 14.5.2/6 says:
A specialization of a conversion function template is not found by name
lookup. Instead, any conversion function templates visible in the context of
the use are considered. For each such operator, if argument deduction
succeeds
(14.8.2.3), the resulting specialization is used as if found by name lookup.
In the context of the use, both functions templates are visible, so both are
sent to argument deduction. Deduction will succeed, so *the specialization is
used as if found by name lookup*. Name lookup cannot find declarations that are
hidden, so this quite clearly requires the above to be ambiguous, and doesn't
allow the base-class version to be filtered out later on. Hiding only takes
place prior to deduction:
templatetypename T1, typename T2
struct A { };
struct base {
templatetypename T1, typename T2
operator AT1, T2();
};
struct derived : base {
templatetypename T1, typename T2
operator AT1, T2();
};
int main() {
derived().operator Aint, int();
}
Now that is not ambiguous anymore, and will call the derived class version,
because in the context of the use, the base-class version is hidden (12.3/5 and
3/8).
Note that by constructing cases making the base-class version more specialized
than the derived class version, we could actually make this a rejects-valid
bug:
templatetypename T1, typename T2
struct A { };
struct base {
templatetypename T1, typename T2
operator AT1*, T2();
};
struct derived : base {
private:
templatetypename T1, typename T2
operator AT1, T2();
};
int main() {
derived().operator Aint*, int();
}
Comeau accepts this one just fine, while GCC rejects it, thinking the
base-version is hidden.
[Bug fortran/46405] Preprocessor generated code can exceed 132 characters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405 --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-08 22:59:45 UTC --- Author: tkoenig Date: Sat Jan 8 22:59:42 2011 New Revision: 168604 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168604 Log: 2011-01-08 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/46405 * invoke.texi: Mention -ffree-line-length-none and -ffixed-line-length-none for preprocessing. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi
[Bug fortran/46405] Preprocessor generated code can exceed 132 characters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-08 23:01:25 UTC --- Recommendation mentioned in documentation, closing.
[Bug lto/46905] -flto -fno-lto does not disable lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 --- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 2011-01-08 23:16:25 UTC --- slim lto will take some time (next stage1) i also plan to drop most of the code because with forced plugin the elf code in collect2 should not be needed anymore.
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr-ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #12 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-08
23:35:40 UTC ---
(In reply to comment #11)
(In reply to comment #10)
Can this be closed? Is there something left to do here?
As of gfortran 4.4.4 (and 4.5.1) the program in comment #7 does not compile
but
gives the same error:
Error: CHARACTER argument 'buf' to 'c_loc' at (1) must have a length of 1
This might be sufficient to fix it.
Index: resolve.c
===
--- resolve.c (Revision 168596)
+++ resolve.c (Arbeitskopie)
@@ -2547,9 +2547,7 @@ is_scalar_expr_ptr (gfc_expr *expr)
switch (ref-type)
{
case REF_SUBSTRING:
- if (ref-u.ss.length != NULL
- ref-u.ss.length-length != NULL
- ref-u.ss.start
+ if (ref-u.ss.start
ref-u.ss.start-expr_type == EXPR_CONSTANT
ref-u.ss.end
ref-u.ss.end-expr_type == EXPR_CONSTANT)
[Bug lto/46905] -flto -fno-lto does not disable lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 --- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org 2011-01-08 23:56:48 UTC --- And to add: if you have more fixes for -fno-lto please add them now, don't wait.
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 --- Comment #7 from Dave Korn davek at gcc dot gnu.org 2011-01-09 00:47:15 UTC --- Created attachment 22932 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22932 proposed patch Ensures thunks get a section name assigned in cgraphunit.c#assemble_thunk(). Taking this for a bootstrap/test cycle.
Re: [Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
Consider the patch pre-approved if it passes testing. Thanks!
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 --- Comment #8 from Jan Hubicka hubicka at ucw dot cz 2011-01-09 00:57:12 UTC --- Consider the patch pre-approved if it passes testing. Thanks!
Re: [Bug lto/46905] -flto -fno-lto does not disable lto
slim lto will take some time (next stage1) I was chatting about this with Diego yesterday and he seems to be fine with the basic slim LTO patch getting in. So it seems to me that we might get the slim LTO patch for 4.6.0 and flip the default for 4.7.0 i also plan to drop most of the code because with forced plugin the elf code in collect2 should not be needed anymore. I don't know. Current collect2 code is utterly broken by using wrong symbol table at first place. With GNU LD getting plugin support the situation got better, but we still have darwin target where we have no linker support at all. Apple linker has plugin, so probably one can write plugin glue, but until that happens, we probably want to keep collect2 path somehow useable. What I am aware of WRT plugin and LTO is that currently plugin force LTO by default. I.e. gcc -flto t.c -c gcc t.o will result in WHOPR while producing a.out I ended up enabling plugin by defualt since that is a must for plugin, but plugin should be extended to work out whether -flto was passed on the command line (or be better told by the driver as we don't want to duplicate parsing everywhere) and when lto is not passed do not claim objects that are not slim. Honza
[Bug lto/46905] -flto -fno-lto does not disable lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 --- Comment #7 from Jan Hubicka hubicka at ucw dot cz 2011-01-09 01:10:25 UTC --- slim lto will take some time (next stage1) I was chatting about this with Diego yesterday and he seems to be fine with the basic slim LTO patch getting in. So it seems to me that we might get the slim LTO patch for 4.6.0 and flip the default for 4.7.0 i also plan to drop most of the code because with forced plugin the elf code in collect2 should not be needed anymore. I don't know. Current collect2 code is utterly broken by using wrong symbol table at first place. With GNU LD getting plugin support the situation got better, but we still have darwin target where we have no linker support at all. Apple linker has plugin, so probably one can write plugin glue, but until that happens, we probably want to keep collect2 path somehow useable. What I am aware of WRT plugin and LTO is that currently plugin force LTO by default. I.e. gcc -flto t.c -c gcc t.o will result in WHOPR while producing a.out I ended up enabling plugin by defualt since that is a must for plugin, but plugin should be extended to work out whether -flto was passed on the command line (or be better told by the driver as we don't want to duplicate parsing everywhere) and when lto is not passed do not claim objects that are not slim. Honza
[Bug debug/47209] ICE: SIGSEGV in should_emit_struct_debug (dwarf2out.c:627) with -f{no-,}emit-struct-debug-{baseonly,reduced} -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47209 --- Comment #5 from Zdenek Sojka zsojka at seznam dot cz 2011-01-09 01:17:54 UTC --- Created attachment 22933 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22933 different testcase (In reply to comment #4) Well, the issue here seems to be that in should_emit_struct_debug TYPE_STUB_DECL (type) for provided type is a NULL_TREE. In next two if-statements this result is used unconditionally. I am not sure if the underlying issue is related to some other place in c++ FE (I assume so), but following patch at least avoid segfault. It fixes attached testcase as well: Without patch: $ gcc -fopenmp -femit-struct-debug-reduced -g pr47209-2.C ==10408== Invalid read of size 2 ==10408==at 0x78AD70: should_emit_struct_debug (dwarf2out.c:624) ==10408==by 0x7B9790: gen_tagged_type_die (dwarf2out.c:20117) ==10408==by 0x7BA774: gen_typedef_die.part.160 (dwarf2out.c:20266) ==10408==by 0x7B84BB: gen_decl_die (dwarf2out.c:21056) ==10408==by 0x7AC9BD: gen_type_die_with_usage (dwarf2out.c:20412) ==10408==by 0x7AD0F5: gen_type_die_with_usage (dwarf2out.c:20454) ==10408==by 0x7B8355: gen_decl_die (dwarf2out.c:21119) ==10408==by 0x7B5DFE: gen_subprogram_die (dwarf2out.c:19330) ==10408==by 0x7B8142: gen_decl_die (dwarf2out.c:21033) ==10408==by 0x7BB678: dwarf2out_function_decl (dwarf2out.c:21415) ==10408==by 0x8141FC: rest_of_handle_final (final.c:4296) ==10408==by 0x93B5D5: execute_one_pass (passes.c:1553) ==10408==by 0x93B8C4: execute_pass_list (passes.c:1608) ==10408==by 0x93B8D6: execute_pass_list (passes.c:1609) ==10408==by 0x93B8D6: execute_pass_list (passes.c:1609) ==10408==by 0xA7B995: tree_rest_of_compilation (tree-optimize.c:422) ==10408==by 0xC40D21: cgraph_expand_function (cgraphunit.c:1519) ==10408==by 0xC436DC: cgraph_optimize (cgraphunit.c:1672) ==10408==by 0xC43969: cgraph_finalize_compilation_unit (cgraphunit.c:1042) ==10408==by 0x5B7E2C: cp_write_global_declarations (decl2.c:3974) ==10408==by 0xA25165: toplev_main (toplev.c:591) ==10408==by 0x6369BBC: (below main) (in /lib64/libc-2.11.2.so) ==10408== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==10408== pr47209-2.C: In function 'built-in': pr47209-2.C:9:9: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. With patch: $ gcc -fopenmp -femit-struct-debug-reduced -g pr47209-2.C -c (no output)
[Bug lto/46769] LTO failed to build gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46769 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2010-12-03 13:29:21 |2011-01-08 13:29:21 CC||hubicka at gcc dot gnu.org --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-09 01:28:34 UTC --- Hmm, the reduced testcase no longer reproduce for me. The original testcase fails still.
[Bug lto/44463] whopr does not work with weak functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-09 02:11:27 UTC --- Well, walking the alias pairs don't seem to be that easy after all. If I understand it right, we first merge the decls and then read the alias pairs. This means that we don't really have the information if the decl in question was prevailed by decl from other file, right? We really need to know that Honza
[Bug libstdc++/41816] ldconfig warnings vs. libstdc++.so.6.0.14-gdb.py
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816 Rob rob1weld at aol dot com changed: What|Removed |Added CC||rob1weld at aol dot com --- Comment #5 from Rob rob1weld at aol dot com 2011-01-09 03:23:40 UTC --- (In reply to comment #4) would it be possible to get a configure flag specifying where to install these files, which we could then set to gdb's auto-load directory? Google has a tough time with the search string unless you break it up since _some_ WebPages add spaces between various parts of the string. (EG: / usr / local / lib / libstdc + +. so.6.0.14-gdb.py). There is this (as best I can tell from the translation) suggested fix: Korean - English: http://translate.google.ca/translate?hl=ensl=kou=http://lunatine.springnote.com/pages/6524343ei=PCcpTanIOITWtQOU18H9Bgsa=Xoi=translatect=resultresnum=1ved=0CB4Q7gEwAAprev=/search%3Fq%3D%2522/usr/local/lib/libstdc%252B%252B.so.6.0.14-gdb.py%2522%2BGDB%2B7.2%2Binstallation%26hl%3Den%26biw%3D1177%26bih%3D764%26prmd%3Divns Origonal URL: http://lunatine.springnote.com/pages/6524343 Rob
[Bug fortran/47224] ICE with procedure pointer component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47224 --- Comment #1 from Martien Hulsen m.a.hulsen at tue dot nl 2011-01-09 07:35:28 UTC --- The second line should be removed. Modified code: module element_defs_m type coefficients_t procedure (dum_vfunc), pointer, nopass :: vfunc = null() end type coefficients_t contains function dum_vfunc ( n, x ) integer, intent(in) :: n real, intent(in), dimension(:) :: x real, dimension(n) :: dum_vfunc dum_vfunc = 0 end function dum_vfunc end module element_defs_m module poisson_elements_m use element_defs_m implicit none contains subroutine poisson_natboun_surface ( coefficients ) type(coefficients_t), intent(in) :: coefficients real, allocatable, dimension(:) :: xg, normal real :: a integer :: ndim = 3 a = dot_product ( normal, coefficients%vfunc ( ndim, xg(:) ) ) end subroutine poisson_natboun_surface end module poisson_elements_m
