[Bug debug/41097] Inlined variable debug location disappears when ptr type
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-08-18 07:22 --- Wait a second are you saying: volatile char * p_name and p_name disappears? Well that is because p_name is no longer volatile but what it points to is. I don't think this is a bug in GCC but rather a misunderstanding on how qualifiers apply to types. If you use a typedef for char*, does it disappear? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41097
[Bug debug/41097] Inlined variable debug location disappears when ptr type
--- Comment #2 from mark at gcc dot gnu dot org 2009-08-18 08:11 --- (In reply to comment #1) Wait a second are you saying: volatile char * p_name and p_name disappears? Well that is because p_name is no longer volatile but what it points to is. Well, obvious p_name still is there, since it will be put in a register to feed into the asm statement. But the debuginfo location for it is missing. I don't think this is a bug in GCC but rather a misunderstanding on how qualifiers apply to types. If you use a typedef for char*, does it disappear? You are right, I misunderstood how the volatile qualifier attached to the type. Using: typedef char * char_ptr; volatile char_ptr p_name = (char_ptr) name; Does what I want. Thanks. That will allow me to write a workaround for what I am seeing using typedef typeof(arg). I am not sure this means the bug is really not there, because I am still a little surprised (confused?) the location expression goes missing in the original (and I assume the variable isn't actually fully optimized away). But since I now have a workaround for that I am already happy. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41097
[Bug c/21920] aliasing violations
--- Comment #147 from rguenth at gcc dot gnu dot org 2009-08-18 09:18 --- *** Bug 41072 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug middle-end/41072] Alias stacked type cast interpretation regression
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-18 09:18 --- 6.5/6 and 6.5/7 specify your code invokes undefined behavior. Use -fno-strict-aliasing for programs you don't want to fix. *** This bug has been marked as a duplicate of 21920 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41072
[Bug c++/41094] Erroneous optimization of pow() with -ffast-math
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-18 09:20 --- Looks like a bug in fold. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2009-08-18 09:20:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41094
[Bug middle-end/41098] New: We should be better in folding pow with integer powers
There are a bunch of missed-optimizations in fold_builtin_pow where we restrict foldings to cases of non-negative base even when the power is an integer. One source of easy missed optimizations is that fold folds x * x to pow (x, 2.0) instead of powi (x, 2) which would make further analysis easier. -- Summary: We should be better in folding pow with integer powers Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41098
[Bug fortran/41099] New: openMP include file causes errors when compiling with standards checking
Due to non-standard code in the supplied openMP header file omp_lib.h compiling with standards checking on results in errors due to the include file and not the users code: Wot now ? uname -a Linux kingswood.nag.co.uk 2.6.27.25-78.2.56.fc9.i686 #1 SMP Thu Jun 18 12:47:50 EDT 2009 i686 i686 i386 GNU/Linux Wot now ? ~/Download/usr/local/gfortran/bin/gfortran --version GNU Fortran (GCC) 4.5.0 20090817 (experimental) [trunk revision 150822] Copyright (C) 2009 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING Wot now ? cat omp.f90 Program annoying Include 'omp_lib.h' End Program annoying Wot now ? ~/Download/usr/local/gfortran/bin/gfortran -fopenmp -std=f95 omp.f90 omp_lib.h:45.15: Included at omp.f90:3: logical*4 omp_get_dynamic, omp_get_nested 1 Error: Nonstandard type declaration LOGICAL*4 at (1) omp_lib.h:47.15: Included at omp.f90:3: logical*4 omp_test_lock, omp_in_parallel 1 Error: Nonstandard type declaration LOGICAL*4 at (1) omp_lib.h:50.15: Included at omp.f90:3: integer*4 omp_get_max_threads, omp_get_num_procs 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:52.15: Included at omp.f90:3: integer*4 omp_get_num_threads, omp_get_thread_num 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:54.15: Included at omp.f90:3: integer*4 omp_test_nest_lock 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:64.15: Included at omp.f90:3: integer*4 omp_get_thread_limit, omp_get_max_active_levels 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:65.15: Included at omp.f90:3: integer*4 omp_get_level, omp_get_ancestor_thread_num 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:66.15: Included at omp.f90:3: integer*4 omp_get_team_size, omp_get_active_level 1 Error: Nonstandard type declaration INTEGER*4 at (1) Wot now ? The nett result is it is difficult to check for non-standard code in programs that include omp_lib.h, which is irritating if portability is extremly important to you. ( Yes, I know there is a work around by using the module rather than including the file, but both should work ! ) Actually this is a more general problem as MPI include files often have similar non-standard code, with the same resulting irritation. What would be nice is some way to say that you wish to ignore all problems caused by a given set of include files. However it would also be nice to fix the include file ! -- Summary: openMP include file causes errors when compiling with standards checking Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian dot bush at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41099
[Bug ada/41100] New: [4.4 regression] Unchecked_Deallocation causes double-free errors
(Forwarding Debian Bug#542158) Unchecked_Deallocation of a record extension containing an Unbounded_String executes incorrectly. Here is a reproducer: with Ada.Strings.Unbounded; use Ada.Strings.Unbounded; package Double_Free is type Test_Base is tagged null record; type Test_Class_Access is access all Test_Base'Class; type Test_Extension is new Test_Base with record Last_Name : Unbounded_String := Null_Unbounded_String; end record; end Double_Free; --- with Ada.Unchecked_Deallocation; with Double_Free; use Double_Free; procedure Main is procedure Free is new Ada.Unchecked_Deallocation (Object = Test_Base'Class, Name = Test_Class_Access); Handle : Test_Class_Access := new Test_Extension; begin Free (Handle); end Main; $ gnatmake main.adb $ ./main *** glibc detected *** main: double free or corruption errors. valgrind --leak-check=full --show-reachable=yes --leak-resolution=high ./main ==5772== Memcheck, a memory error detector. ==5772== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==5772== Using LibVEX rev 1884, a library for dynamic binary translation. ==5772== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==5772== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework. ==5772== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==5772== For more details, rerun with: -v ==5772== ==5772== Invalid free() / delete / delete[] ==5772==at 0x4C2261F: free (vg_replace_malloc.c:323) ==5772==by 0x50A8D84: __gnat_free (in /usr/lib/libgnat-4.4.so.1) ==5772==by 0x403FC4: _ada_main (in /home/reet/double-free/obj/main) ==5772==by 0x40327B: main (in /home/reet/double-free/obj/main) ==5772== Address 0x5b3b040 is 16 bytes inside a block of size 136 alloc'd ==5772==at 0x4C2391E: malloc (vg_replace_malloc.c:207) ==5772==by 0x50A8DC7: __gnat_malloc (in /usr/lib/libgnat-4.4.so.1) ==5772==by 0x403EF0: _ada_main (in /home/reet/double-free/obj/main) ==5772==by 0x40327B: main (in /home/reet/double-free/obj/main) ==5772== ==5772== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 1) ==5772== malloc/free: in use at exit: 136 bytes in 1 blocks. ==5772== malloc/free: 1 allocs, 1 frees, 136 bytes allocated. ==5772== For counts of detected errors, rerun with: -v ==5772== searching for pointers to 1 not-freed blocks. ==5772== checked 203,328 bytes. ==5772== ==5772== ==5772== 136 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==5772==at 0x4C2391E: malloc (vg_replace_malloc.c:207) ==5772==by 0x50A8DC7: __gnat_malloc (in /usr/lib/libgnat-4.4.so.1) ==5772==by 0x403EF0: _ada_main (in /home/reet/double-free/obj/main) ==5772==by 0x40327B: main (in /home/reet/double-free/obj/main) ==5772== ==5772== LEAK SUMMARY: ==5772==definitely lost: 136 bytes in 1 blocks. ==5772== possibly lost: 0 bytes in 0 blocks. ==5772==still reachable: 0 bytes in 0 blocks. ==5772== suppressed: 0 bytes in 0 blocks. Freeing memory of a base type object (Test_Base) works without problems. When the unbounded string field (Name) is removed or replaced (e.g. by an Integer), freeing also works for the type extension. The code has been tested with the following compiler / arch combinations: i386/gnat-4.3 : works i386/gnat-4.4 : works amd64/gnat-4.3 : works amd64/gnat-4.4 : FAILS This bug hurts PolyORB and prevents us from migrating all Ada packages in Debian to gnat-4.4. -- Summary: [4.4 regression] Unchecked_Deallocation causes double- free errors Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41100
[Bug other/41101] New: [4.4 regression] build doesn't terminate (endless loop?)
[forwarded from http://bugs.debian.org/541816] works with trunk and 4.4.1 release, fails with gcc-4.4-branch 20090708 (-O2, but works with -O0 and -O1), seen on at least ix86 and x86_64. Matthias gcc-4.4 -S -O2 -Wall -fno-strict-aliasing gcc44bug.i -- Summary: [4.4 regression] build doesn't terminate (endless loop?) Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
[Bug other/41101] [4.4 regression] build doesn't terminate (endless loop?)
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-08-18 10:48 --- Created an attachment (id=18394) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18394action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
[Bug fortran/41102] New: openMP include file causes errors when compiling with standards checking
Due to non-standard code in the supplied openMP header file omp_lib.h compiling with standards checking on results in errors due to the include file and not the users code: Wot now ? uname -a Linux kingswood.nag.co.uk 2.6.27.25-78.2.56.fc9.i686 #1 SMP Thu Jun 18 12:47:50 EDT 2009 i686 i686 i386 GNU/Linux Wot now ? ~/Download/usr/local/gfortran/bin/gfortran --version GNU Fortran (GCC) 4.5.0 20090817 (experimental) [trunk revision 150822] Copyright (C) 2009 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING Wot now ? cat omp.f90 Program annoying Include 'omp_lib.h' End Program annoying Wot now ? ~/Download/usr/local/gfortran/bin/gfortran -fopenmp -std=f95 omp.f90 omp_lib.h:45.15: Included at omp.f90:3: logical*4 omp_get_dynamic, omp_get_nested 1 Error: Nonstandard type declaration LOGICAL*4 at (1) omp_lib.h:47.15: Included at omp.f90:3: logical*4 omp_test_lock, omp_in_parallel 1 Error: Nonstandard type declaration LOGICAL*4 at (1) omp_lib.h:50.15: Included at omp.f90:3: integer*4 omp_get_max_threads, omp_get_num_procs 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:52.15: Included at omp.f90:3: integer*4 omp_get_num_threads, omp_get_thread_num 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:54.15: Included at omp.f90:3: integer*4 omp_test_nest_lock 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:64.15: Included at omp.f90:3: integer*4 omp_get_thread_limit, omp_get_max_active_levels 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:65.15: Included at omp.f90:3: integer*4 omp_get_level, omp_get_ancestor_thread_num 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:66.15: Included at omp.f90:3: integer*4 omp_get_team_size, omp_get_active_level 1 Error: Nonstandard type declaration INTEGER*4 at (1) Wot now ? The nett result is it is difficult to check for non-standard code in programs that include omp_lib.h, which is irritating if portability is extremly important to you. ( Yes, I know there is a work around by using the module rather than including the file, but both should work ! ) Actually this is a more general problem as MPI include files often have similar non-standard code, with the same resulting irritation. What would be nice is some way to say that you wish to ignore all problems caused by a given set of include files. However it would also be nice to fix the include file ! -- Summary: openMP include file causes errors when compiling with standards checking Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian dot bush at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41102
[Bug middle-end/41098] We should be better in folding pow with integer powers
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-18 10:55 --- I have to XFAIL parts of gcc.dg/builtins-10.c because of PR41094. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||xfail http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41098
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple definitions
--- Comment #18 from ktietz at gcc dot gnu dot org 2009-08-18 11:03 --- This bug is fixed by a recent change to our runtime headers. We support now the NO_INLINE feature for platform headers, too. So, even intrinsic functions aren't emitted anymore, when __NO_INLINE__ is defined. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
[Bug target/37120] g++ failed to compile code dVolume *= 1 + pow(10.0, -5.0);
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-08-18 11:05 --- Ok, as I can't reproduce this anymore, and I got no reply on my question, I close this issue. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37120
[Bug tree-optimization/41101] [4.4 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-18 11:17 --- Pfff... and no, the fix for PR40321 didn't fix it. Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|other |tree-optimization Ever Confirmed|0 |1 Keywords||compile-time-hog, ice- ||checking, ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2009-08-18 11:17:54 date|| Summary|[4.4 regression] build |[4.4 Regression] ICE in |doesn't terminate (endless |compute_antic, at tree-ssa- |loop?) |pre.c:2419 Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
[Bug tree-optimization/41101] [4.4 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-18 11:21 --- Instead it likely broke it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.3 |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
[Bug tree-optimization/41101] [4.4 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-18 11:23 --- It did. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-08-18 11:17:54 |2009-08-18 11:23:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-18 11:24 --- Trunk is broken as well at -O -ftree-pre. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.4.2 |4.4.2 4.5.0 Known to work|4.4.1 4.5.0 |4.4.1 Summary|[4.4 Regression] ICE in |[4.4/4.5 Regression] ICE in |compute_antic, at tree-ssa- |compute_antic, at tree-ssa- |pre.c:2419 |pre.c:2419 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #27 from mahatma at eu dot by 2009-08-18 11:28 --- (In reply to comment #26) *** Bug 40985 has been marked as a duplicate of this bug. *** (In reply to comment #25) Created an attachment (id=18393) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18393action=view) [edit] A patch for gcc 4.4 Are this patch may conflict with your patch? http://gcc.gnu.org/bugzilla/attachment.cgi?id=18340action=view - equal to 32893 solution. I found, once you are broke (make regression) 4.4 branch against 32893 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893#c23 - I found there are your, sorry). May be this is way to suggest more correct sse solution vs. local bugfix for 32893, but while I not understand all - I trying to use both patches. May it be wrong? PS One more sorry, but I want to know ALL ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug c++/41103] New: g++-4.3/4.4 generates wrong code on x86_64
g++-4.3 and 4.4 seem to generate wrong code, when optimizing. 4.2 produce correct code for me the bad code on 4.4 is: 004449a0 fifo_testerboost::lockfree::caching_freelist_t::get(): 4449a0: 41 57 push %r15 4449a2: 48 8d 87 80 00 00 00lea0x80(%rdi),%rax 4449a9: 48 8d 97 98 00 58 00lea0x580098(%rdi),%rdx 4449b0: 48 8d 8f 90 00 00 00lea0x90(%rdi),%rcx 4449b7: 41 56 push %r14 4449b9: 41 55 push %r13 4449bb: 4c 8d 6f 40 lea0x40(%rdi),%r13 4449bf: 41 54 push %r12 4449c1: 55 push %rbp 4449c2: 48 bd ff ff ff ff ffmov$0x,%rbp 4449c9: ff 00 00 4449cc: 49 89 ecmov%rbp,%r12 4449cf: 53 push %rbx 4449d0: 48 89 fbmov%rdi,%rbx 4449d3: 48 81 ec c8 00 00 00sub$0xc8,%rsp 4449da: 48 89 44 24 30 mov%rax,0x30(%rsp) 4449df: 48 8d 87 98 00 00 00lea0x98(%rdi),%rax 4449e6: 48 89 54 24 18 mov%rdx,0x18(%rsp) 4449eb: 48 89 4c 24 20 mov%rcx,0x20(%rsp) 4449f0: 48 89 44 24 38 mov%rax,0x38(%rsp) 4449f5: 0f 1f 00nopl (%rax) 4449f8: 48 8b 03mov(%rbx),%rax 4449fb: 0f ae e8lfence 4449fe: 48 8b 3bmov(%rbx),%rdi 444a01: 48 89 c2mov%rax,%rdx 444a04: 48 21 eaand%rbp,%rdx 444a07: 48 89 eemov%rbp,%rsi 444a0a: 48 8b 4b 40 mov0x40(%rbx),%rcx 444a0e: 48 23 32and(%rdx),%rsi 444a11: 48 39 c7cmp%rax,%rdi 444a14: 0f 85 3c 03 00 00 jne444d56 fifo_testerboost::lockfree::caching_freelist_t::get()+0x3b6 444a1a: 48 89 cfmov%rcx,%rdi 444a1d: 4c 21 e7and%r12,%rdi 444a20: 48 39 facmp%rdi,%rdx 444a23: 0f 84 27 02 00 00 je 444c50 fifo_testerboost::lockfree::caching_freelist_t::get()+0x2b0 444a29: 48 89 c1mov%rax,%rcx 444a2c: 44 8b 76 10 mov0x10(%rsi),%r14d -- oops 444a30: 48 89 74 24 50 mov%rsi,0x50(%rsp) 444a35: 48 c1 e9 30 shr$0x30,%rcx 444a39: 48 89 44 24 40 mov%rax,0x40(%rsp) 444a3e: 83 c1 01add$0x1,%ecx 444a41: 66 89 4c 24 56 mov%cx,0x56(%rsp) 444a46: 48 8b 4c 24 50 mov0x50(%rsp),%rcx 444a4b: f0 48 0f b1 0b lock cmpxchg %rcx,(%rbx) at position 444a2c it segfaults, because the register %rsi is 0 while the correct code of 4.2 is: 00447380 fifo_testerboost::lockfree::caching_freelist_t::get(): 447380: 41 57 push %r15 447382: 48 8d 87 98 00 58 00lea0x580098(%rdi),%rax 447389: 48 8d 97 90 00 00 00lea0x90(%rdi),%rdx 447390: 41 56 push %r14 447392: 41 55 push %r13 447394: 4c 8d af 80 00 00 00lea0x80(%rdi),%r13 44739b: 41 54 push %r12 44739d: 4c 8d 67 40 lea0x40(%rdi),%r12 4473a1: 55 push %rbp 4473a2: 48 89 fdmov%rdi,%rbp 4473a5: 53 push %rbx 4473a6: 48 bb ff ff ff ff ffmov$0x,%rbx 4473ad: ff 00 00 4473b0: 48 83 ec 28 sub$0x28,%rsp 4473b4: 48 89 44 24 10 mov%rax,0x10(%rsp) 4473b9: 48 8d 44 24 24 lea0x24(%rsp),%rax 4473be: 48 89 54 24 08 mov%rdx,0x8(%rsp) 4473c3: 48 89 04 24 mov%rax,(%rsp) 4473c7: 48 8b 55 00 mov0x0(%rbp),%rdx 4473cb: 0f ae e8lfence 4473ce: 48 8b 75 40 mov0x40(%rbp),%rsi 4473d2: 48 89 d7mov%rdx,%rdi 4473d5: 48 21 dfand%rbx,%rdi 4473d8: 48 8b 0fmov(%rdi),%rcx 4473db: 48 21 d9and%rbx,%rcx 4473de: 48 3b 55 00 cmp0x0(%rbp),%rdx 4473e2: 75 e3 jne4473c7 fifo_testerboost::lockfree::caching_freelist_t::get()+0x47 4473e4: 48 89 f0mov%rsi,%rax 4473e7: 48 21 d8and%rbx,%rax 4473ea: 48 39 c7cmp%rax,%rdi 4473ed: 0f 84 42 01 00 00 je 447535 fifo_testerboost::lockfree::caching_freelist_t::get()+0x1b5 4473f3: 8b 41 10mov0x10(%rcx),%eax
[Bug target/40786] Windows %I32 format confusion
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-08-18 11:32 --- Is there a way to make %I32 accepting both types? Something like FMT_LEN_z? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40786
[Bug c++/41103] g++-4.3/4.4 generates wrong code on x86_64
--- Comment #1 from tim at klingt dot org 2009-08-18 11:35 --- Created an attachment (id=18395) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18395action=view) preprocessed source, 4.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41103
[Bug c++/41103] g++-4.3/4.4 generates wrong code on x86_64
--- Comment #2 from tim at klingt dot org 2009-08-18 11:37 --- Created an attachment (id=18396) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18396action=view) preprocessed source, 4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41103
[Bug target/40971] [4.4 Regression] ICE in memory_address
--- Comment #2 from jakub at gcc dot gnu dot org 2009-08-18 11:42 --- Subject: Bug 40971 Author: jakub Date: Tue Aug 18 11:42:07 2009 New Revision: 150869 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150869 Log: PR target/40971 * config/rs6000/rs6000.c (rs6000_legitimize_address): For [DT][FDI]mode ensure the offset isn't 4/8/12 bytes below 0x8000. * gcc.dg/pr40971.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr40971.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40971
[Bug target/40971] [4.4 Regression] ICE in memory_address
--- Comment #3 from jakub at gcc dot gnu dot org 2009-08-18 11:43 --- Subject: Bug 40971 Author: jakub Date: Tue Aug 18 11:43:16 2009 New Revision: 150870 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150870 Log: PR target/40971 * config/rs6000/rs6000.c (rs6000_legitimize_address): For [DT][FDI]mode ensure the offset isn't 4/8/12 bytes below 0x8000. * gcc.dg/pr40971.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr40971.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40971
[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-18 11:47 ---
One reduced testcase, requires both the typedef and the unprototyped foo
(thus, implicit return type int).
typedef long *GEN;
int foo(GEN);
void int_elt_val(GEN nf, GEN x, GEN y, long N, int b)
{
GEN tmp, a;
int i;
while (1)
{
for (i=1; i=N; i++)
{
a = (GEN) (__SIZE_TYPE__) foo(((GEN *)x)[1]);
((GEN *)y)[i] = (GEN) (__SIZE_TYPE__) foo(a);
if (b)
return;
}
tmp=x;
x=y;
y=tmp;
}
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
[Bug c++/41103] g++-4.3/4.4 generates wrong code on x86_64
--- Comment #3 from tim at klingt dot org 2009-08-18 11:50 --- i forgot to mention, i am building with bjam, passing the following options: COLLECT_GCC_OPTIONS='-ftemplate-depth-128' '-O3' '-finline-functions' '-Wno-inline' '-Wall' '-pthread' '-fPIC' '-g' '-v' '-save-temps' '-DBOOST_ALL_NO_LIB=1' '-DBOOST_THREAD_POSIX' '-DBOOST_THREAD_USE_DLL=1' '-DNDEBUG' '-I../../..' '-c' '-o' '../../../bin.v2/libs/lockfree/test/fifo_test.test/gcc-4.4.1/release/threading-multi/fifo_test.o' '-shared-libgcc' '-mtune=generic' when compiling in debug mode, the binary works fine: COLLECT_GCC_OPTIONS='-ftemplate-depth-128' '-O0' '-fno-inline' '-Wall' '-g' '-pthread' '-fPIC' '-g' '-v' '-save-temps' '-DBOOST_ALL_NO_LIB=1' '-DBOOST_THREAD_POSIX' '-DBOOST_THREAD_USE_DLL=1' '-I../../..' '-c' '-o' '../../../bin.v2/libs/lockfree/test/fifo_test.test/gcc-4.4.1/debug/threading-multi/fifo_test.o' '-shared-libgcc' '-mtune=generic' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41103
[Bug ada/41041] -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16
--- Comment #4 from ludovic at ludovic-brenta dot org 2009-08-18 12:01 --- Please change the component of this PR from ada to c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41041
[Bug ada/41040] -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-08-18 12:02 --- Duplicate of 41041, which has the attachments. Also, please change the component of this PR from ada to c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41040
[Bug ada/41096] GNAT run-time missing CFLAGS_FOR_TARGET
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-08-18 12:04 --- Does that imply that Ada cross-compilers are broken? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41096
[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58
--- Comment #10 from ludovic at ludovic-brenta dot org 2009-08-18 12:10 --- Does the fix mean that GNAT does not support large files on any platform? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
[Bug fortran/40976] Merge DECL of procedure call with DECL of gfc_get_function_type
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-18 13:03 --- Another complication is due to: a) Procedure pointer b) Procedure pointer components (Type-bound procedures are no problem as they have always an explicit interface.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976
[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-08-18 13:18 ---
Other one:
typedef long *GEN;
GEN dvmdii(GEN x);
GEN mulii(GEN x);
void int_elt_val(GEN x, GEN y, long N, int b, long k)
{
long i;
GEN r,a;
while (1)
{
for (i=1; i=N; i++)
{
a = muliiGEN*) (x))[1]));
a = muliiGEN*) (x))[k]));
(((GEN*) (y))[i]) = a;
if (b)
return;
}
r=x;
x=y;
y=r;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
[Bug ada/41096] GNAT run-time missing CFLAGS_FOR_TARGET
--- Comment #2 from joel at gcc dot gnu dot org 2009-08-18 13:28 --- If you need CFLAGS_FOR_TARGET set to find the files or specify target specific compiler options required to compile the run-time, then yes. This certainly breaks any cross build that is non-multilib and specifies target specific CPU model CFLAGS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41096
[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58
--- Comment #11 from davek at gcc dot gnu dot org 2009-08-18 13:36 --- (In reply to comment #10) Does the fix mean that GNAT does not support large files on any platform? No need to worry, that was reason why I mentioned it would be necessary to change the 64-bit definition as well, back in comment #5, and that's what I did in the final patch. Large file support in GNAT is entirely unchanged. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
[Bug c++/41094] Erroneous optimization of pow() with -ffast-math
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-18 13:40 --- Subject: Bug 41094 Author: rguenth Date: Tue Aug 18 13:40:18 2009 New Revision: 150874 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150874 Log: 2009-08-18 Richard Guenther rguent...@suse.de PR middle-end/41094 * builtins.c (fold_builtin_pow): Fold pow(pow(x,y),z) to pow(x,y*z) only if x is nonnegative. * gcc.dg/torture/pr41094.c: New testcase. * gcc.dg/torture/builtin-power-1.c: Adjust. * gcc.dg/builtins-10.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr41094.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/builtins-10.c trunk/gcc/testsuite/gcc.dg/torture/builtin-power-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41094
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #28 from hjl dot tools at gmail dot com 2009-08-18 14:01 --- (In reply to comment #27) (In reply to comment #26) *** Bug 40985 has been marked as a duplicate of this bug. *** (In reply to comment #25) Created an attachment (id=18393) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18393action=view) [edit] A patch for gcc 4.4 Are this patch may conflict with your patch? http://gcc.gnu.org/bugzilla/attachment.cgi?id=18340action=vie This is not mine and isn't needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug c++/41104] New: overload resolution does not find templated function (zero - pointer) (2)
I think this is the same as PR23055, but better be safe than sorry... Maybe
Jason can have a look and fix both at once. In any case, both ICC and SunStudio
accept this one too:
template class T
void S(T op, typename T::X const *);
struct Widget { typedef int X; };
void f()
{
Widget w;
S(w, 0);
}
--
Summary: overload resolution does not find templated function
(zero - pointer) (2)
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41104
[Bug c/41046] decNumber leaves printf call in libgcc
--- Comment #5 from jessiecute13 at aol dot com 2009-08-18 14:13 --- Needs tickets for the race in oct9-10 -- jessiecute13 at aol dot com changed: What|Removed |Added BugsThisDependsOn||4210 OtherBugsDependingO||4112 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41046
[Bug c/41049] conversion from integer to decimal float loses trailing zeros
--- Comment #1 from jessiecute13 at aol dot com 2009-08-18 14:13 --- costs for $42.12 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41049
[Bug fortran/40870] [F03] include formal args in backend_decl of PPCs
--- Comment #1 from janus at gcc dot gnu dot org 2009-08-18 14:23 --- Subject: Bug 40870 Author: janus Date: Tue Aug 18 14:23:35 2009 New Revision: 150875 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150875 Log: 2009-08-18 Janus Weil ja...@gcc.gnu.org Paul Thomas pa...@gcc.gnu.org PR fortran/40870 * trans-types.c (gfc_get_ppc_type): Include formal args in backend_decl using the interface symbol. Character types are returned by reference. (gfc_get_derived_type): Prevent infinite recursion loop if a PPC has a derived-type formal arg. 2009-08-18 Janus Weil ja...@gcc.gnu.org Paul Thomas pa...@gcc.gnu.org PR fortran/40870 * gfortran.dg/proc_ptr_comp_13.f90: Extended. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_13.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40870
[Bug c++/41103] g++-4.3/4.4 generates wrong code on x86_64
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-18 14:24 --- Does it work with -fno-strict-aliasing? I suppose this is one case where boost plays tricks with placement new on decls (non-anonymous storage)? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41103
[Bug fortran/40870] [F03] include formal args in backend_decl of PPCs
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-18 14:25 --- Fixed with r150875. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40870
[Bug ada/41105] New: Tickets
Name : Kelly Company : bugzilla Phone : 3057526589 Amount :$9.45 ROW :33 Seat:3 Total:$5.68 -- Summary: Tickets Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jessiecute13 at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41105
[Bug ada/41105] Tickets
spam -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41105
[Bug other/41105] Tickets
--- Comment #1 from charlet at gcc dot gnu dot org 2009-08-18 14:32 --- remove 'ada' component -- charlet at gcc dot gnu dot org changed: What|Removed |Added Component|ada |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41105
[Bug fortran/41106] New: [F03] Procedure Pointers with CHARACTER results
There are some problems with CHARACTER-valued procedure pointers (and procedure pointer components). First example (with PPCs): module m type :: t procedure(character(len=5)), pointer, nopass :: ptr end type contains function abc() character(len=5) :: abc abc = 'abcde' end function abc end module m use m type(t) :: x character(len=5) :: str x%ptr = abc str = x%ptr() end gives the error: test.f90:12:0: internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:477 Second example (similar, but with simple procedure pointers): procedure(character(len=5)), pointer :: pp pp = abc contains function abc() character(len=5) :: abc abc = 'abcde' end function abc end gives: internal compiler error: in gfc_trans_pointer_assignment, at fortran/trans-expr.c:4237 -- Summary: [F03] Procedure Pointers with CHARACTER results Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41106
[Bug c++/41103] g++-4.3/4.4 generates wrong code on x86_64
--- Comment #5 from tim at klingt dot org 2009-08-18 14:36 --- compiling with -fno-strict-aliasing doesn't do any difference. the error is actually related to some code, that does a pointer/tag compression, packing a pointer and an integer to a 64bit pointer [1] in order to deal with the lack of cmpxchg16b instructions on early x86_64 cpus. hth, tim [1] http://tim.klingt.org/git?p=boost_lockfree.git;a=blob;f=boost/lockfree/detail/tagged_ptr_ptrcompression.hpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41103
[Bug fortran/41107] New: Proc-pointer componts: Fix calling DECL for f2c
Follow up to http://gcc.gnu.org/ml/fortran/2009-08/msg00232.html It might be auto-fixed by PR 40976 ... -- Summary: Proc-pointer componts: Fix calling DECL for f2c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41107
[Bug fortran/40976] Merge DECL of procedure call with DECL of gfc_get_function_type
--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-18 14:49 --- For PPC, see also PR 41107 and the link therein. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976
[Bug fortran/41102] openMP include file causes errors when compiling with standards checking
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-18 14:59 --- Confirmed. Patch for the include file: --- libgomp/omp_lib.h.in(revision 150873) +++ libgomp/omp_lib.h.in(working copy) @@ -45 +45 @@ - logical*4 omp_get_dynamic, omp_get_nested + logical(4) omp_get_dynamic, omp_get_nested @@ -47 +47 @@ - logical*4 omp_test_lock, omp_in_parallel + logical(4) omp_test_lock, omp_in_parallel @@ -50 +50 @@ - integer*4 omp_get_max_threads, omp_get_num_procs + integer(4) omp_get_max_threads, omp_get_num_procs @@ -52 +52 @@ - integer*4 omp_get_num_threads, omp_get_thread_num + integer(4) omp_get_num_threads, omp_get_thread_num @@ -54 +54 @@ - integer*4 omp_test_nest_lock + integer(4) omp_test_nest_lock @@ -64,3 +64,3 @@ - integer*4 omp_get_thread_limit, omp_get_max_active_levels - integer*4 omp_get_level, omp_get_ancestor_thread_num - integer*4 omp_get_team_size, omp_get_active_level + integer(4) omp_get_thread_limit, omp_get_max_active_levels + integer(4) omp_get_level, omp_get_ancestor_thread_num + integer(4) omp_get_team_size, omp_get_active_level -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||openmp Last reconfirmed|-00-00 00:00:00 |2009-08-18 14:59:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41102
[Bug fortran/41099] openMP include file causes errors when compiling with standards checking
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-18 15:00 --- *** This bug has been marked as a duplicate of 41102 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41099
[Bug fortran/41102] openMP include file causes errors when compiling with standards checking
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-18 15:00 --- *** Bug 41099 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41102
[Bug fortran/41102] openMP include file causes errors when compiling with standards checking
--- Comment #3 from joseph at codesourcery dot com 2009-08-18 15:58 --- Subject: Re: New: openMP include file causes errors when compiling with standards checking On Tue, 18 Aug 2009, ian dot bush at nag dot co dot uk wrote: Due to non-standard code in the supplied openMP header file omp_lib.h compiling with standards checking on results in errors due to the include file and not the users code: For C and C++, most diagnostics are disabled by default for code in system headers. Shouldn't Fortran do something equivalent? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41102
[Bug fortran/41102] openMP include file causes errors when compiling with standards checking
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-18 16:08 --- (In reply to comment #3) For C and C++, most diagnostics are disabled by default for code in system headers. Shouldn't Fortran do something equivalent? Good question. The problem is that with include somebig_chunk_of_code.f90 one can include other code, which does not necessarily contain just PARAMETERs (constants) and COMMONs but actual code. For instance octopus (tddft.org) does this: It has a MODULE and includes one or two other files in it, which contain subroutines/functions belonging to the MODULE but are for maintenance reasons in a separate file. (Fortran 2008's submodules would be a better replacement.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41102
[Bug libfortran/39668] Wrongly read namelist with two dimensional array.
--- Comment #7 from toon at moene dot org 2009-08-18 16:40 --- The relevant wording in the Standard (2003) is: 9.5.3.4 Data transfer ... The list items for a namelist input statement are processed in the order of the entities specified within the input records. ... To spell it out for this example: 1 is assigned to i(1,1) 2 is assigned to i(2,1) ! Array element order, as no other order is specified. 3 is assigned to i(3,1) ! Ditto. 4 is assigned to i(2,1) ! Overwriting the 2 that was there. 5 is assigned to i(3,1) ! Overwriting the 3 that was there. 6 is assigned to i(2,2) ! Got that ? 7 is assigned to i(3,1) ! Overwriting the 5 that was there. 8 is assigned to i(3,2) ! Hah ! 9 is assigned to i(3,3) ! So there ! i(1,2), i(1,3) and i(2,3) are never set via the namelist I/O and remain at 0. So printing the namelist will get you: 1, 4, 7, 0 (=i(1,2)), 6, 8, 0 (=i(1,3)), 0 (=i(2,3)), 9 which seems perfectly OK with me. Closing the bug report as INVALID, i.e., not a bug. -- toon at moene dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39668
[Bug tree-optimization/41011] ICE in ipcp_lattice_from_jfunc, at ipa-cp.c:328
--- Comment #5 from hjl dot tools at gmail dot com 2009-08-18 16:46 --- This isn't a 4.5 regression since there is no -fwhole-file in gcc 4.4. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.5 Regression] ICE in |ICE in |ipcp_lattice_from_jfunc, at |ipcp_lattice_from_jfunc, at |ipa-cp.c:328|ipa-cp.c:328 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41011
[Bug fortran/41102] openMP include file causes errors when compiling with standards checking
--- Comment #5 from ian dot bush at nag dot co dot uk 2009-08-18 16:46 --- Subject: Re: openMP include file causes errors when compiling with standards checking burnus at gcc dot gnu dot org wrote: --- Comment #4 from burnus at gcc dot gnu dot org 2009-08-18 16:08 --- (In reply to comment #3) For C and C++, most diagnostics are disabled by default for code in system headers. Shouldn't Fortran do something equivalent? Good question. The problem is that with include somebig_chunk_of_code.f90 one can include other code, which does not necessarily contain just PARAMETERs (constants) and COMMONs but actual code. For instance octopus (tddft.org) does this: It has a MODULE and includes one or two other files in it, which contain subroutines/functions belonging to the MODULE but are for maintenance reasons in a separate file. (Fortran 2008's submodules would be a better replacement.) Also Fortran doesn't have the concept of system headers, so how should the compiler decide what is a system header or not ? In some cases, like openMP it's reasonably clear, but for third party software it's difficult. Hence my suggestion in the original bug report to somehow allow the user to specify that diagnostics from certain include files should be ignored. Also thanks for fixing this so quickly, the joys of open source !! I've lodged similar bug reports to Cray ( around 6 months ago ) and IBM ( around 6 years ago !! ) about their mpif.h files with absolutely no joy. Also I hope I'm replying to the right place, I'm new around here ... Ian The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41102
[Bug fortran/41102] openMP include file causes errors when compiling with standards checking
--- Comment #6 from joseph at codesourcery dot com 2009-08-18 16:52 --- Subject: Re: openMP include file causes errors when compiling with standards checking On Tue, 18 Aug 2009, ian dot bush at nag dot co dot uk wrote: Also Fortran doesn't have the concept of system headers, so how should the compiler decide what is a system header or not ? In some cases, like openMP it's reasonably clear, but for third party software it's difficult. Hence my suggestion in the original bug report to somehow allow the user to specify that diagnostics from certain include files should be ignored. System headers are headers in system header directories: directories of headers provided by the system (not necessarily just those that come with GCC) and are searched by default. In the present case, the file is installed by gcc in libsubdir/finclude, and I don't know what other system directories gfortran might search by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41102
[Bug fortran/41102] openMP include file causes errors when compiling with standards checking
--- Comment #7 from ian dot bush at nag dot co dot uk 2009-08-18 16:58 --- Subject: Re: openMP include file causes errors when compiling with standards checking joseph at codesourcery dot com wrote: --- Comment #6 from joseph at codesourcery dot com 2009-08-18 16:52 --- Subject: Re: openMP include file causes errors when compiling with standards checking On Tue, 18 Aug 2009, ian dot bush at nag dot co dot uk wrote: Also Fortran doesn't have the concept of system headers, so how should the compiler decide what is a system header or not ? In some cases, like openMP it's reasonably clear, but for third party software it's difficult. Hence my suggestion in the original bug report to somehow allow the user to specify that diagnostics from certain include files should be ignored. System headers are headers in system header directories: directories of headers provided by the system (not necessarily just those that come with GCC) and are searched by default. In the present case, the file is installed by gcc in libsubdir/finclude, and I don't know what other system directories gfortran might search by default. OK, my misunderstanding on a piece of terminology. Thanks for educating me. But still the option to say please ignore diagnostics generated in this header/include file would be useful, Ian The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41102
[Bug objc/41108] New: ICE in objc_build_ivar_assignment
@interface O
{
}
@end
@protocol E
@end
@class F;
@interface G: O {
}
@end
@interface F: O E {
G *g;
}
-(id)bar:(G *)baz;
@end
@implementation F
-(id)bar:(G *)baz {
self-g = baz;
return self;
}
@end
ICEs with -fobjc-gc -fgnu-runtime (works without -fobjc-gc or with -fobjc-gc
-fnext-runtime). Apparently objc_assign_ivar_fast_decl and
objc_assign_ivar_decl are only initialized for next runtime, but are used
unconditionally even for GNU runtime.
--
Summary: ICE in objc_build_ivar_assignment
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41108
[Bug objc/41108] ICE in objc_build_ivar_assignment
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-08-18 17:32 --- -fobjc-gc should error out for the GNU runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41108
[Bug spam/41105] Tickets
--- Comment #2 from ubizjak at gmail dot com 2009-08-18 17:33 --- Can someone stop this idiot? -- ubizjak at gmail dot com changed: What|Removed |Added Component|other |spam http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41105
[Bug c++/41109] New: [4.5 regression] Argument flagged as unused despite use in sizeof()
I think this is a recent regression:
-
int memory_consumption(const int t) { return sizeof(t); }
int s;
int g() { return memory_consumption(s); }
-
deal.II c++ -c -W -Wunused ../x.cc
../x.cc:1:5: warning: unused parameter 't'
Quite formally, it is probably correct to say that the parameter is unused
because we don't read or write from/to it. But I think it's still a kind of
use to determine its size and the warning should be suppressed in my
opinion.
In the meantime, the warning can of course be trivially suppressed by
saying
sizeof(int)
instead.
W.
--
Summary: [4.5 regression] Argument flagged as unused despite use
in sizeof()
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41109
[Bug c++/41110] New: [4.5 regression] Wrong unused variable warning
This would appear to be a recent regression:
template int struct X { static const int s = 2; };
template typename T int f() {
const unsigned int dim = 2;
return Xdim::s;
}
template int fint();
-
deal.II c++ -c -W -Wunused x.cc
x.cc: In function 'int f() [with T = int]':
x.cc:8:21: instantiated from here
x.cc:4:22: warning: unused variable 'dim'
'dim' is used here, it just is never read from or written to.
W.
--
Summary: [4.5 regression] Wrong unused variable warning
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41110
[Bug testsuite/40704] ^M? in testsuite log leads to binary attachment
--- Comment #5 from hjl at gcc dot gnu dot org 2009-08-18 19:41 --- Subject: Bug 40704 Author: hjl Date: Tue Aug 18 19:40:48 2009 New Revision: 150898 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150898 Log: 2009-08-18 H.J. Lu hongjiu...@intel.com PR testsuite/40704 * test_summary: Filter out \r. Modified: trunk/contrib/ChangeLog trunk/contrib/test_summary -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40704
[Bug c++/41111] New: c++ problems to compile
Im running Debian Etch, gcc 4.1.2 Im studying c++, and just wrote a very basic code. Then I tried to compile. #gcc teste.cpp and got this message: gcc: error trying to exec 'cc1plus': execvp: Arquivo ou diretório não encontrado Ok, so I installed g++. #aptitude install g++ and tried to compile again. #gcc -x c++ teste.cpp -save-temps and now i have this bigger message: teste.o: In function `__static_initialization_and_destruction_0(int, int)': teste.cpp:(.text+0x23): undefined reference to `std::ios_base::Init::Init()' teste.o: In function `__tcf_0': teste.cpp:(.text+0x6c): undefined reference to `std::ios_base::Init::~Init()' teste.o: In function `main': teste.cpp:(.text+0x8e): undefined reference to `std::cout' teste.cpp:(.text+0x93): undefined reference to `std::basic_ostreamchar, std::char_traitschar std::operator std::char_traitschar (std::basic_ostreamchar, std::char_traitschar , char const*)' teste.cpp:(.text+0x9b): undefined reference to `std::basic_ostreamchar, std::char_traitschar std::endlchar, std::char_traitschar (std::basic_ostreamchar, std::char_traitschar )' teste.cpp:(.text+0xa3): undefined reference to `std::basic_ostreamchar, std::char_traitschar ::operator(std::basic_ostreamchar, std::char_traitschar (*)(std::basic_ostreamchar, std::char_traitschar ))' teste.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0' collect2: ld returned 1 exit status And I got these 3 archs, teste.o teste.ii teste.s (from the -save-temps) Any ideas? -- Summary: c++ problems to compile Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jaamfi at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug c++/41111] c++ problems to compile
--- Comment #1 from jaamfi at gmail dot com 2009-08-18 19:50 --- Created an attachment (id=18397) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18397action=view) templates From the compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug c++/41111] c++ problems to compile
--- Comment #2 from jaamfi at gmail dot com 2009-08-18 19:52 --- Created an attachment (id=18398) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18398action=view) from save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug c++/41111] c++ problems to compile
--- Comment #3 from jaamfi at gmail dot com 2009-08-18 19:52 --- Created an attachment (id=18399) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18399action=view) from save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug c++/41111] c++ problems to compile
--- Comment #4 from redi at gcc dot gnu dot org 2009-08-18 19:54 --- use g++ not gcc http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Invoking-G_002b_002b.html -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug c++/41111] c++ problems to compile
--- Comment #5 from jaamfi at gmail dot com 2009-08-18 19:57 --- (In reply to comment #4) use g++ not gcc http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Invoking-G_002b_002b.html thaks jonathan!! it seemed very simple! god bless! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
--- Comment #2 from dominiq at lps dot ens dot fr 2009-08-18 20:03 --- The manual says: -O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload and -ftree-vectorize options. but I see: [karma] f90/bug% gfc -m64 -O2 -ftree-vectorize -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload where_2.f90 [karma] f90/bug% a.out 100 100 100 210 210 210 310 310 337 337 [karma] f90/bug% gfc -m64 -O3 where_2.f90 [karma] f90/bug% a.out 100 100 100 210 210 210 310 310 310 310 Abort What are the missing differences between -O2 and -O3? -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||rguenther at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug tree-optimization/41112] New: [4.5 regression] ACATS c43205b fails at -O2 (tree-sra)
Reduced testcase to be attached, compile in the build dir with: gcc/xgcc -Bgcc -S p.adb -Igcc/ada/rts -O2 +===GNAT BUG DETECTED==+ | 4.5.0 20090818 (experimental) [trunk revision 150875] (i586-suse-linux-gnu) GCC error:| | tree check: expected integer_cst, have var_decl in int_const_binop, | | at fold-const.c:1668 | | Error detected around p.adb:31:4 (gdb) bt #0 internal_error (gmsgid=0xab540b4 tree check: %s, have %s in %s, at %s:%d) at /home/eric/svn/gcc/gcc/diagnostic.c:674 #1 0x0995d788 in tree_check_failed (node=0xf7dd90c0, file=0xaa4cd04 /home/eric/svn/gcc/gcc/fold-const.c, line=1668, function=0xaa4d6a3 int_const_binop) at /home/eric/svn/gcc/gcc/tree.c:7460 #2 0x0894c9ab in int_const_binop (code=PLUS_EXPR, arg1=0xf7dda658, arg2=0xf7dd90c0, notrunc=0) at /home/eric/svn/gcc/gcc/fold-const.c:1668 #3 0x0938768e in build_ref_for_offset_1 (res=0xcc90, type=0xf7dcdaf0, offset=0, exp_type=0xf7dbb9a0) at /home/eric/svn/gcc/gcc/tree-sra.c:1091 #4 0x09387804 in build_ref_for_offset (expr=0xcc90, type=0xf7dcdaf0, offset=0, exp_type=0xf7dbb9a0, allow_ptr=0 '\0') at /home/eric/svn/gcc/gcc/tree-sra.c:1136 (gdb) frame 3 #3 0x0938768e in build_ref_for_offset_1 (res=0xcc90, type=0xf7dcdaf0, offset=0, exp_type=0xf7dbb9a0) at /home/eric/svn/gcc/gcc/tree-sra.c:1091 1091index = int_const_binop (PLUS_EXPR, index, (gdb) p debug_tree(type) array_type 0xf7dcdaf0 p__proc2GP464__T10b type integer_type 0xf7dbb9a0 integer type integer_type 0xf7d0e310 integer sizes-gimplified public visited SI size integer_cst 0xf7d01498 constant 32 unit size integer_cst 0xf7d01284 constant 4 align 32 symtab 0 alias set 2 canonical type 0xf7d0e310 precision 32 min integer_cst 0xf7d01444 -2147483648 max integer_cst 0xf7d01460 2147483647 pointer_to_this pointer_type 0xf7d0ed20 sizes-gimplified public SI size integer_cst 0xf7d01498 32 unit size integer_cst 0xf7d01284 4 align 32 symtab 0 alias set 2 canonical type 0xf7dbb9a0 precision 32 min integer_cst 0xf7d3fb28 -2147483648 max integer_cst 0xf7dc716c 2147483647 RM size integer_cst 0xf7d01498 32 RM min integer_cst 0xf7d01444 -2147483648 RM max integer_cst 0xf7d01460 2147483647 pointer_to_this pointer_type 0xf7dc9230 chain type_decl 0xf7dbba10 integer readonly sizes-gimplified nonaliased-component BLK size integer_cst 0xf7d01690 type integer_type 0xf7d0e070 bit_size_type constant 128 unit size integer_cst 0xf7d016ac type integer_type 0xf7d0e000 long int constant 16 align 32 symtab 0 alias set 6 canonical type 0xf7dcdaf0 domain integer_type 0xf7dcd850 type integer_type 0xf7d0e000 long int sizes-gimplified public visited sizetype SI size integer_cst 0xf7d01498 32 unit size integer_cst 0xf7d01284 4 align 32 symtab 0 alias set -1 canonical type 0xf7d0e000 precision 32 min integer_cst 0xf7d016e4 -2147483648 max integer_cst 0xf7d01700 2147483647 sizes-gimplified public SI size integer_cst 0xf7d01498 32 unit size integer_cst 0xf7d01284 4 align 32 symtab 0 alias set -1 canonical type 0xf7dcd850 precision 32 min var_decl 0xf7dd90c0 D.2323 max var_decl 0xf7dd9180 D.2325 index type integer_type 0xf7dcd770 p__proc2GP464__T9b___XD type integer_type 0xf7d0e310 integer sizes-gimplified SI size integer_cst 0xf7d01498 32 unit size integer_cst 0xf7d01284 4 align 32 symtab 0 alias set 2 canonical type 0xf7dcd770 precision 32 min integer_cst 0xf7dc75b0 -2147483648 max integer_cst 0xf7dc78a4 2147483647 RM size integer_cst 0xf7d01498 32 RM min nop_expr 0xf7dccd60 RM max plus_expr 0xf7dce318 chain type_decl 0xf7dcd7e0 p__proc2GP464__T9b___XD chain type_decl 0xf7dcd8c0 D.2234 pointer_to_this pointer_type 0xf7dd41c0 Looks like the new SRA is not fully prepared to handle arrays with non-constant bounds for its TYPE_DOMAIN. -- Summary: [4.5 regression] ACATS c43205b fails at -O2 (tree-sra) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org GCC target triplet: ix86-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41112
[Bug tree-optimization/41112] [4.5 regression] ACATS c43205b fails at -O2 (tree-sra)
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-08-18 20:32 --- Created an attachment (id=18400) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18400action=view) Reduced testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41112
[Bug fortran/41113] New: spurious _gfortran_internal_pack
gfortran seems to generate a spurious _gfortran_internal_pack if an array that
is component of a type is passed to a subroutine. More precisely, in the
example
CALL S1(d%data)
CALL S1(data)
should basically generate the same pseudocode, but this doesn't happen.
cat test.f90
MODULE M1
TYPE T1
REAL :: data(10)
END TYPE T1
CONTAINS
SUBROUTINE S1(data)
REAL, DIMENSION(*) :: data
END SUBROUTINE S1
END MODULE
SUBROUTINE S2
USE M1
TYPE(T1) :: d
REAL :: data(10)
CALL S1(d%data)
CALL S1(data)
END SUBROUTINE S2
cat test.f90.003t.original
s1 (real(kind=4)[0:] * data)
{
(void) 0;
}
s2 ()
{
struct t1 d;
real(kind=4) data[10];
{
void * D.1554;
struct array1_real(kind=4) parm.0;
parm.0.dtype = 281;
parm.0.dim[0].lbound = 1;
parm.0.dim[0].ubound = 10;
parm.0.dim[0].stride = 1;
parm.0.data = (void *) d.data[0];
parm.0.offset = -1;
D.1554 = _gfortran_internal_pack (parm.0);
s1 (D.1554);
if ((real(kind=4)[0:] *) parm.0.data != (real(kind=4)[0:] *) D.1554)
{
_gfortran_internal_unpack (parm.0, D.1554);
{
void * D.1555;
D.1555 = D.1554;
if (D.1555 != 0B)
{
__builtin_free (D.1555);
}
}
}
}
s1 (data);
}
--
Summary: spurious _gfortran_internal_pack
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113
[Bug debug/37738] Fortran DW_TAG_common_block has incorrect placement/scope
--- Comment #5 from robert dot mance at intel dot com 2009-08-18 21:01 --- (In reply to comment #4) Fixed. Could you please tell me what version of gfortran this is fixed in? I'm working the Intel Fortran compiler debug information at the moment regarding a request to add DW_AT_common_inclusion to our output. Seems like gfortran has actually decided to move in Intel's direction here. I'd like to see the output that gfortran is now creating, and be able to run that version of gfortran here. Thanks. Bob -- robert dot mance at intel dot com changed: What|Removed |Added CC||robert dot mance at intel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37738
[Bug debug/37738] Fortran DW_TAG_common_block has incorrect placement/scope
--- Comment #6 from jakub at gcc dot gnu dot org 2009-08-18 21:17 --- GCC 4.4.0/4.4.1 have it, as well as GCC trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37738
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #11 from ami_stuff at o2 dot pl 2009-08-19 00:28 ---
It ICEs also...
with -m68020 -m68881 -Os options:
/usr/local/amiga/bin/m68k-amigaos-gcc-4.4.1.exe -V 4.4.1 -DHAVE_AV_CONFIG_H -I.
-I/bin/ffmpeg8 -mnobitfield -m68020 -m68881 -std=c99
-Wdeclaration-after-stat
ement -Wdisabled-optimization -fno-math-errno -D_ISOC99_SOURCE
-D_POSIX_C_SOURCE
=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common
-fomit-frame-poin
ter -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual
-Wwrite-stri
ngs -Wundef -Os -c -o libavcodec/mpegvideo.o libavcodec/mpegvideo.c
libavcodec/mpegvideo.c: In function 'init_rl':
libavcodec/mpegvideo.c:760: warning: pointer targets in assignment differ in
sig
nedness
libavcodec/mpegvideo.c:765: warning: pointer targets in assignment differ in
sig
nedness
libavcodec/mpegvideo.c: In function 'MPV_motion_lowres':
libavcodec/mpegvideo.c:1707: error: insn does not satisfy its constraints:
(insn 647 2733 2734 49 libavcodec/mpegvideo.c:1488 (set (reg/v/f:SI 7 d7
[orig:2
93 ptr_y ] [293])
(plus:SI (mem/f:SI (reg:SI 8 a0) [7 S4 A16])
(reg:SI 7 d7 [637]))) 131 {*addsi3_internal} (nil))
libavcodec/mpegvideo.c:1707: internal compiler error: in
reload_cse_simplify_ope
rands, at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
with -m68040 -Os options:
/usr/local/amiga/bin/m68k-amigaos-gcc-4.4.1.exe -V 4.4.1 -DHAVE_AV_CONFIG_H -I.
-I/bin/ffmpeg8 -mnobitfield -m68040 -std=c99 -Wdeclaration-after-statement
-W
disabled-optimization -fno-math-errno -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common -fomit-frame-pointer
-Wal
l -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual -Wwrite-strings
-Wun
def -Os -c -o libavcodec/mpegvideo.o libavcodec/mpegvideo.c
libavcodec/mpegvideo.c: In function 'init_rl':
libavcodec/mpegvideo.c:760: warning: pointer targets in assignment differ in
sig
nedness
libavcodec/mpegvideo.c:765: warning: pointer targets in assignment differ in
sig
nedness
libavcodec/mpegvideo.c: In function 'MPV_motion_lowres':
libavcodec/mpegvideo.c:1707: error: insn does not satisfy its constraints:
(insn 647 2733 2734 49 libavcodec/mpegvideo.c:1488 (set (reg/v/f:SI 7 d7
[orig:2
93 ptr_y ] [293])
(plus:SI (mem/f:SI (reg:SI 8 a0) [7 S4 A16])
(reg:SI 7 d7 [637]))) 131 {*addsi3_internal} (nil))
libavcodec/mpegvideo.c:1707: internal compiler error: in
reload_cse_simplify_ope
rands, at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
with -m68060 -Os options:
/usr/local/amiga/bin/m68k-amigaos-gcc-4.4.1.exe -V 4.4.1 -DHAVE_AV_CONFIG_H -I.
-I/bin/ffmpeg8 -mnobitfield -m68060 -std=c99 -Wdeclaration-after-statement
-W
disabled-optimization -fno-math-errno -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common -fomit-frame-pointer
-Wal
l -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual -Wwrite-strings
-Wun
def -Os -c -o libavcodec/mpegvideo.o libavcodec/mpegvideo.c
libavcodec/mpegvideo.c: In function 'init_rl':
libavcodec/mpegvideo.c:760: warning: pointer targets in assignment differ in
sig
nedness
libavcodec/mpegvideo.c:765: warning: pointer targets in assignment differ in
sig
nedness
libavcodec/mpegvideo.c: In function 'MPV_motion_lowres':
libavcodec/mpegvideo.c:1707: error: insn does not satisfy its constraints:
(insn 637 2688 2689 49 libavcodec/mpegvideo.c:1488 (set (reg/v/f:SI 7 d7
[orig:2
89 ptr_y ] [289])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug testsuite/41114] New: [4.5 Regression] Revision 150889 breasks library tests
Revision 150889: http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00570.html caused: ERROR: Couldn't find library file target-libpath.exp. ERROR: Couldn't find library file target-libpath.exp. ERROR: Couldn't find library file target-libpath.exp. ERROR: Couldn't find library file target-libpath.exp. ERROR: Couldn't find library file target-libpath.exp. ERROR: Couldn't find library file target-libpath.exp. As the result, many library tests no long ran: http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01955.html -- Summary: [4.5 Regression] Revision 150889 breasks library tests Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41114
[Bug testsuite/39655] autogen fixinclude test FAILURES - trunk revision 145337
--- Comment #1 from oliver dot kellogg at eads dot com 2009-08-19 05:45 --- Using trunk r150901 on openSuSE-11.1 i686-pc-linux-gnu, I get: [...] Fixed: Xm/Traversal.h complex.h /usr/src/packages/SOURCES/gcc/fixincludes/tests/base/complex.h differ: byte 262, line 13 *** complex.h 2009-08-19 07:19:12.0 +0200 --- /usr/src/packages/SOURCES/gcc/fixincludes/tests/base/complex.h 2009-08-18 22:01:38.0 +0200 *** *** 10,16 #if defined( AIX_COMPLEX_CHECK ) ! # define _Complex_I (__extension__ 1.0iF) #endif /* AIX_COMPLEX_CHECK */ --- 10,16 #if defined( AIX_COMPLEX_CHECK ) ! #define _Complex_I (__extension__ 1.0iF) #endif /* AIX_COMPLEX_CHECK */ stdint.h /usr/src/packages/SOURCES/gcc/fixincludes/tests/base/stdint.h differ: byte 283, line 13 *** stdint.h2009-08-19 07:19:12.0 +0200 --- /usr/src/packages/SOURCES/gcc/fixincludes/tests/base/stdint.h 2009-08-18 22:01:38.0 +0200 *** 10,50 #if defined( AIX_STDINT_1_CHECK ) ! #define UINT8_MAX (255) ! #define UINT16_MAX(65535) #endif /* AIX_STDINT_1_CHECK */ #if defined( AIX_STDINT_2_CHECK ) ! #define INTPTR_MIN(-INTPTR_MAX-1) ! #define INTPTR_MAX9223372036854775807L ! #define UINTPTR_MAX 18446744073709551615UL #else ! #define INTPTR_MIN(-INTPTR_MAX-1) ! #define INTPTR_MAX2147483647L ! #define UINTPTR_MAX 4294967295UL #endif /* AIX_STDINT_2_CHECK */ #if defined( AIX_STDINT_3_CHECK ) ! #define PTRDIFF_MIN (-PTRDIFF_MAX - 1) ! #define PTRDIFF_MAX __PTRDIFF_MAX__ #else ! #define PTRDIFF_MIN (-PTRDIFF_MAX - 1) ! #define PTRDIFF_MAX __PTRDIFF_MAX__ #endif /* AIX_STDINT_3_CHECK */ #if defined( AIX_STDINT_4_CHECK ) ! #define SIZE_MAX __SIZE_MAX__ #else ! #define SIZE_MAX __SIZE_MAX__ #endif /* AIX_STDINT_4_CHECK */ #if defined( AIX_STDINT_5_CHECK ) ! #define UINT8_C(c) __UINT8_C(c) ! #define UINT16_C(c) __UINT16_C(c) #endif /* AIX_STDINT_5_CHECK */ --- 10,50 #if defined( AIX_STDINT_1_CHECK ) ! #define UINT8_MAX (255U) ! #define UINT16_MAX(65535U) #endif /* AIX_STDINT_1_CHECK */ #if defined( AIX_STDINT_2_CHECK ) ! #define INTPTR_MININT64_MIN ! #define INTPTR_MAXINT64_MAX ! #define UINTPTR_MAX UINT64_MAX #else ! #define INTPTR_MININT32_MIN ! #define INTPTR_MAXINT32_MAX ! #define UINTPTR_MAX UINT32_MAX #endif /* AIX_STDINT_2_CHECK */ #if defined( AIX_STDINT_3_CHECK ) ! #define PTRDIFF_MIN INT64_MIN ! #define PTRDIFF_MAX INT64_MAX #else ! #define PTRDIFF_MIN INT32_MIN ! #define PTRDIFF_MAX INT32_MAX #endif /* AIX_STDINT_3_CHECK */ #if defined( AIX_STDINT_4_CHECK ) ! #define SIZE_MAX UINT64_MAX #else ! #define SIZE_MAXUINT32_MAX #endif /* AIX_STDINT_4_CHECK */ #if defined( AIX_STDINT_5_CHECK ) ! #define UINT8_C(c)__CONCAT__(c,U) ! #define UINT16_C(c) __CONCAT__(c,U) #endif /* AIX_STDINT_5_CHECK */ There were fixinclude test FAILURES make[2]: *** [check] Error 1 make[2]: Leaving directory `/usr/src/packages/BUILD/build-gcc-orig/fixincludes' Should I file a separate bug? -- oliver dot kellogg at eads dot com changed: What|Removed |Added CC||oliver dot kellogg at eads ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39655
