[Bug pch/11654] incorrect stabs when using pre-compiled headers
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11654
[Bug pch/9471] #pragma system_header vs. precompiled headers
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9471
[Bug c++/7221] wrong linkage of typedef-named classes
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7221
[Bug target/37033] [4.4 Regression] Revision 138733 breaks -g vs -g0 for PCH
--- Comment #10 from geoffk at gcc dot gnu dot org 2008-11-28 07:34 --- Yes, the test is still valid. It is reporting a real problem. I will suggest a change to __GCC_HAVE_DWARF2_CFI_ASM that permits the testcase to continue working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37033
[Bug middle-end/38283] FAIL: libgomp.fortran/pr25162.f
--- Comment #6 from danglin at gcc dot gnu dot org 2008-11-28 04:44 --- (gdb) p debug_tree (decl) unit size align 64 symtab 0 alias set -1 canonical type 7af79af8 fields BLK file /test/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/pr25162.f line 9 col 0 size unit size align 64 offset_align 64 offset bit offset context >> addressable public static ignored common tls-local-exec decl_3 BLK defer-output file /test/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/pr25162.f line 10 col 0 size unit size align 64 context chain > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38283
[Bug rtl-optimization/38280] [4.4 regression] Revision 142207 breaks 416.gamess/481.wrf in SPEC CPU 2006
--- Comment #4 from Joey dot ye at intel dot com 2008-11-28 03:39 --- 142250 doesn't fix this regression. 416.gamess and 481.wrf still fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38280
[Bug middle-end/38283] FAIL: libgomp.fortran/pr25162.f
--- Comment #5 from danglin at gcc dot gnu dot org 2008-11-28 03:35 ---
(gdb) p debug_tree ($r26)
unit size
align 32 symtab 0 alias set -1 canonical type 7af7ec30
fields
unsigned SI file
/test/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/pr25162.f line 14 col 0
size
unit size
align 32 offset_align 64
offset
bit offset context chain >>
addressable asm_written public static ignored common BLK file
/test/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/pr25162.f line 14 col 0
size unit size
align 32 context
(mem/s/c:BLK (symbol_ref:SI ("__emutls_v.testcom_") [flags 0x200] ) [0 __emutls_v.testcom_+0 S16 A32])>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38283
[Bug c++/38297] O2 causes invalid code
--- Comment #5 from andrew at warnux dot com 2008-11-28 02:33 --- Thanks! I guess I learned something new today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297
[Bug java/38298] New: libjava link failures.
during building latest 4.4 snapshot i've got a linker error: (...) /bin/sh ./libtool --tag=GCJ --mode=link /home/users/pluto/rpm/BUILD/gcc-4.4-20081121/builddir/gcc/gcj -B/home/users/pluto/rpm/BUILD/gcc-4.4-20081121/builddir/x86_64-pld-linux/libjava/ -B/home/users/pluto/rpm/BUILD/gcc-4.4-20081121/builddir/gcc/ -L/home/users/pluto/rpm/BUILD/gcc-4.4-20081121/builddir/x86_64-pld-linux/libjava -fomit-frame-pointer -O2 -march=x86-64 -Wl,--as-needed -Wl,-z,relro -Wl,-z,combreloc -o grmic --main=gnu.classpath.tools.rmic.Main -rpath /usr/lib64/../lib64 -shared-libgcc -L/home/users/pluto/rpm/BUILD/gcc-4.4-20081121/builddir/x86_64-pld-linux/libjava/.libs libgcj-tools.la libtool: link: /home/users/pluto/rpm/BUILD/gcc-4.4-20081121/builddir/gcc/gcj -B/home/users/pluto/rpm/BUILD/gcc-4.4-20081121/builddir/x86_64-pld-linux/libjava/ -B/home/users/pluto/rpm/BUILD/gcc-4.4-20081121/builddir/gcc/ -fomit-frame-pointer -O2 -march=x86-64 -Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,combreloc -o .libs/grmic --main=gnu.classpath.tools.rmic.Main -shared-libgcc -L/home/users/pluto/rpm/BUILD/gcc-4.4-20081121/builddir/x86_64-pld-linux/libjava/.libs -L/home/users/pluto/rpm/BUILD/gcc-4.4-20081121/builddir/x86_64-pld-linux/libjava ./.libs/libgcj-tools.so -Wl,-rpath -Wl,/usr/lib64/../lib64 ./.libs/libgcj-tools.so: undefined reference to `fmod' collect2: ld returned 1 exit status make[3]: *** [grmic] Error 1 -- Summary: libjava link failures. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: x86_64-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38298
[Bug c/21920] aliasing violations
--- Comment #131 from pinskia at gcc dot gnu dot org 2008-11-28 02:20 --- *** Bug 38297 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||andrew at warnux dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c++/38297] O2 causes invalid code
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-11-28 02:20 --- Yep you are violating C++ aliasing rules as you are accessing a char * as an unsigned char*. It would be ok if you accessed a char as an unsigned char but you are accessing the pointers instead. It is not the size which matters but rather the types which are being accessed here. *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297
[Bug c++/38297] O2 causes invalid code
--- Comment #3 from andrew at warnux dot com 2008-11-28 01:59 --- unsigned char char and byte are the same size (1 byte), so why is there a problem? -- andrew at warnux dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297
[Bug c++/38297] O2 causes invalid code
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-28 01:38 --- What is byte typedef? Is it unsigned char or signed char? If so then you are violating aliasing rules by modifying a char* via that pointer type. Yes char/unsigned char/signed char are special but their pointer types are not. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297
[Bug debug/37982] Extraneous DW_TAG_variable tag
--- Comment #5 from jan dot kratochvil at redhat dot com 2008-11-28 01:36 --- (In reply to comment #4) > First, I think the DIE representing the defining declaration of A::elsewhere > in class2.c should have a DW_AT_specification pointing back to the DIE > representing the declaration or A::elsewhere in class.h. Already present: non-defining declaration is , the defining declaration is . properly points by DW_AT_specification to its . > Second, I think the DIE of the defining declaration of A::elsewhere in class2 > should have a DW_AT_const_value attribute whose value should be the constant > "211". > > This can be deduced from the dwarf2 spec, section [4.1 Data Object Entries], > point 9, pdf page 35, spec page 33 that reads: > > "9. An entry describing a variable whose value is constant and not represented > by an object in the address space of the program, or an entry describing a > named constant, does not have a location attribute. DW_AT_const_value is more for Fortran constants which are an equivalent of C #define. In the sample code here `static const int' is in .rodata, it has its address (DW_AT_location) and can be tracked by `rwatch' (read-watchpoint). [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [15] .rodata PROGBITS 00400658 0658 0014 A 0 0 8 Symbol table '.symtab' contains 73 entries: Num:Value Size TypeBind Vis Ndx Name 55: 00400668 4 OBJECT GLOBAL DEFAULT 15 _ZN1A9elsewhereE It should be sufficient the type entry at <0xe1> (not shown in the sample dump here) is already correctly DW_TAG_const_type. > And third, as you pointed out, the DIE of the declaration of A::elsewhere > should not appear twice in the class.c compilation unit. It should only appear > once, in the scope of the A class. Two vs. one DIE is not a mistake but more a minor optimization (such optimization is already Bug debug/37941). With single DIE it would look OK to me. With two DIEs there are currently these problems: (1) DW_AT_name is now `elsewhere' while it should be either `A::elsewhere' or whole DW_TAG_variable should be enclosed by DW_TAG_class_type for `A'. It may be Bug c++/37590. (Non-standard DW_AT_MIPS_linkage_name should be removed in the future.) (2) Defining declaration <86> should point by DW_AT_specification to its non-defining declaration <37>. (The DWARF citation is here from Dodji.) (But I do not see these two problems as real issues for debugging.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug c++/38297] O2 causes invalid code
--- Comment #1 from andrew at warnux dot com 2008-11-28 00:32 --- I guess you want this too: gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297
[Bug c++/38297] New: O2 causes invalid code
I am compiling with g++ on a 64 bit Ubuntu OS. I spent days trying to find out
why my programs kept crashing. I found that when using O2 optimizations the
problem is there, when using O1 it is not a problem.
I am not using any compiler options other than stripping symbols, hiding
warnings, and O2.
Here is a very simple test case that causes the bug every time.
void RefTest(byte*& p)
{
++p;
}
void RefTest(char*& p)
{
++p;
}
char* c= "0123";
char* p= c;
RefTest((byte*&)p);
cout << p << endl; // 0123
RefTest(p);
cout << p << endl; // 123
return 0;
--
Summary: O2 causes invalid code
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew at warnux dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297
[Bug middle-end/38283] FAIL: libgomp.fortran/pr25162.f
--- Comment #4 from danglin at gcc dot gnu dot org 2008-11-27 23:49 --- Size of __emutls_v.testcom_ block is wrong, as well as generated code. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Component|libgomp |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38283
[Bug rtl-optimization/38280] [4.4 regression] Revision 142207 breaks 416.gamess/481.wrf in SPEC CPU 2006
--- Comment #3 from hjl at gcc dot gnu dot org 2008-11-27 23:30 --- Subject: Bug 38280 Author: hjl Date: Thu Nov 27 23:28:44 2008 New Revision: 142250 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142250 Log: 2008-11-27 Vladimir Makarov <[EMAIL PROTECTED]> PR rtl-optimization/38280 * ira-build.c (loop_is_inside_p, regno_allocno_order_compare_func, ira_rebuild_regno_allocno_list): New functions. (regno_allocnos): New static variable. (remove_unnecessary_allocnos): Allocate/deallocate regno_allocnos. Call ira_rebuild_regno_allocno_list. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/ira-build.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38280
[Bug fortran/38290] ICE with invalid proc-pointer
--- Comment #2 from janus at gcc dot gnu dot org 2008-11-27 22:50 --- I also tried to compile the other procptr examples from the WikiBooks page, which is linked in comment #0. The only remaining problem I found was: program bsp implicit none abstract interface subroutine up() end subroutine up end interface procedure( up ) , pointer :: pptr pptr => add contains function add( a, b ) integer :: add integer, intent( in ) :: a, b add = a + b end function add end program bsp This is currently accepted by gfortran, although invalid, and is rejected e.g. by ifort with error #8179: The procedure pointer and the procedure target must both be functions or subroutines. Inserting a statement like print *, pptr() produces an ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug fortran/36526] pointer in pure function
--- Comment #7 from pault at gcc dot gnu dot org 2008-11-27 22:23 --- Fixed on trunk and 4.3. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36526
[Bug fortran/36526] pointer in pure function
--- Comment #6 from pault at gcc dot gnu dot org 2008-11-27 22:21 --- Subject: Bug 36526 Author: pault Date: Thu Nov 27 22:20:27 2008 New Revision: 142248 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142248 Log: 2008-11-27 Paul Thomas <[EMAIL PROTECTED]> PR fortran/36526 * interface.c (check_intents): Correct error where the actual arg was checked for a pointer argument, rather than the formal. 2008-11-27 Paul Thomas <[EMAIL PROTECTED]> PR fortran/36526 * gfortran.dg/pure_formal_proc_2.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/pure_formal_proc_2.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/interface.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36526
[Bug fortran/38289] "procedure( ), pointer" rejected
--- Comment #3 from janus at gcc dot gnu dot org 2008-11-27 22:16 --- (In reply to comment #2) > Is this enough? I guess so :) -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-27 22:16:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38289
[Bug fortran/38290] ICE with invalid proc-pointer
--- Comment #1 from janus at gcc dot gnu dot org 2008-11-27 22:09 ---
The test case can be further compressed to a 3-liner
procedure( up ) :: p
call p
end
and is fixed by the following simple patch
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 142171)
+++ gcc/fortran/resolve.c (working copy)
@@ -2748,7 +2748,8 @@ resolve_specific_s0 (gfc_code *c, gfc_sy
/* See if we have an intrinsic interface. */
if (sym->ts.interface != NULL && !sym->ts.interface->attr.abstract
- && !sym->ts.interface->attr.subroutine)
+ && !sym->ts.interface->attr.subroutine
+ && sym->ts.interface->attr.intrinsic)
{
gfc_intrinsic_sym *isym;
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-11-27 22:09:01
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug target/38287] [4.1/4.2/4.3 regression] segfault at -O2 -fPIC -mcpu=v8
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-11-27 21:20 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-11-27 21:14:18 |2008-11-27 21:20:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38287
[Bug target/38287] [4.1/4.2/4.3 regression] segfault at -O2 -fPIC -mcpu=v8
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-11-27 21:14 --- Reproducible on Solaris as well (with -mcpu=v8 since -mcpu=v9 is the default). -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|sparc-linux-gnu |sparc*-*-* Known to work|4.4.0 |3.4.6 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-11-27 21:14:18 date|| Summary|wrong-code with -O2 -fPIC on|[4.1/4.2/4.3 regression] |sparc-linux-gnu |segfault at -O2 -fPIC - ||mcpu=v8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38287
[Bug fortran/38289] "procedure( ), pointer" rejected
--- Comment #2 from mikael at gcc dot gnu dot org 2008-11-27 21:12 --- Is this enough? Index: decl.c === --- decl.c (révision 142242) +++ decl.c (copie de travail) @@ -4094,6 +4094,7 @@ match_procedure_decl (void) /* Get the type spec. for the procedure interface. */ old_loc = gfc_current_locus; m = gfc_match_type_spec (¤t_ts, 0); + gfc_gobble_whitespace (); if (m == MATCH_YES || (m == MATCH_NO && gfc_peek_ascii_char () == ')')) goto got_ts; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38289
[Bug rtl-optimization/38280] [4.4 regression] Revision 142207 breaks 416.gamess/481.wrf in SPEC CPU 2006
--- Comment #2 from vmakarov at redhat dot com 2008-11-27 20:32 --- The problem was in violation of allocno order in regno_allocno_map list. This order is very important for many algorithms (allocno info propagation, conflict propagation and IR flattening). For example, loop 0: no usage of R loop 1: a1 representing R loop 2: a2 representing R After removing Loop1, we move a1 to loop 0. Allocnos on upper levels should be after allocnos on lower levels in regno_allocno_map list. Before removing loop we had a1 a2 in the list which is ok because they are on the same loop level. After removing loop 1, we have again a1 and a2 which is not ok because a1 now corresponds to loop 0 containing loop 1 and as a consequence should be after a2. We had no problem before the patch because we removed always a loop and all its subloops (removing loops based on register pressure) and the order violation was not possible. I'll submit a patch solving the problem today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38280
[Bug fortran/38282] Add the remaining HPF bit intrinsics
--- Comment #2 from w6ws at earthlink dot net 2008-11-27 19:32 --- Tobias, Steven, If you would like to usurp this request and use it to implement the complete set of F2008 bit intrinsics, please feel free to do so. For completeness, one other HPF bit intrinsic is ILEN - which counts the number of bits needed to represent an integer. This is not in the F2008 draft, but is occasionally useful. A few comments on the draft F2008 intrinsics: DSHIFTL/DSHIFTR - Cray-1 intrinsics. Occasionally handy. Represented the hardware vector "snake" instruction. SHIFTA - Lots of systems have this instruction in hardware, but not the Cray-1. So it went into the Cray compilers somewhat later. SHIFTL/SHIFTR - Cray-1 intrinsics. Better than ISHFT because the compiler always knows which shift instruction to generate. MASKL/MASKR - Shades of the MASK intrinsic on 60-bit CDC systems, which represented a hardware instruction. MERGE_BITS - On the Cray-1, it was called CSMG. Hardware instruction. One final instrinsic: IBCHNG. This was part of the old "Industrial Real-Time Fortran" Standard. IBCHNG allows the caller to 'flip' a specific bit to its complement. The IRTF bit intrinsics were the basis for the Milspec-1753 bit intrinsics, and then F90. But somehow IBCHNG got lost along the way. Nonetheless, a number of compilers (ifort, cray, sun, sgi, probably ibm, etc) also implement IBCHNG. (We could talk about the IRTF ISHL (logical shift), ISHA (arithmetic shift), and ISHC (circular shift) which are also implemented in some compilers. But since the F90 ISHFT and ISHFTC, and F2008 SHIFTA cover these cases in a Standard-conforming way, I would not recommend implementing them in gfortran.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug c/38295] Support pointer difference as constant in static initializer
--- Comment #8 from gnu at behdad dot org 2008-11-27 18:55 --- If they are asked to be put in different sections, sure, it will err. But doesn't gcc already use relative calls for many static functions in the same unit? Let me back out: my request is: add gcc extension to support some way to implement vtables that do not need (many) relocations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
[Bug c/38295] Support pointer difference as constant in static initializer
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-11-27 18:53 --- Also the linker could do some branch relaxation which causes the size to be different based on the layout of the functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
[Bug c/38295] Support pointer difference as constant in static initializer
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-11-27 18:52 --- (In reply to comment #5) > If the two functions are in the same compilation unit (and static), it's known > at compile time, isn't it? Not always since they could be in different sections via -ffunction-sections or the user put them into different sections. The layout of the sections is not known until link time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
[Bug c/38295] Support pointer difference as constant in static initializer
--- Comment #5 from gnu at behdad dot org 2008-11-27 18:35 --- If the two functions are in the same compilation unit (and static), it's known at compile time, isn't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
[Bug c/38295] Support pointer difference as constant in static initializer
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-11-27 18:33 --- (In reply to comment #2) > I'm not following. Why arrays? Those are pointers, and their difference is > known at compile time. Not at compile time really, the difference is known at link time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
[Bug c/38295] Support pointer difference as constant in static initializer
--- Comment #3 from gnu at behdad dot org 2008-11-27 18:32 --- Oh, I see what you mean. Yes, I said in my report that this is undefined/unsupported/... according to the C standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
[Bug c/38295] Support pointer difference as constant in static initializer
--- Comment #2 from gnu at behdad dot org 2008-11-27 18:31 --- I'm not following. Why arrays? Those are pointers, and their difference is known at compile time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
[Bug c/38295] Support pointer difference as constant in static initializer
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-27 18:28 --- Differences between two different arrays don't make sense really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
[Bug c/38296] New: documentation: improve documentation of __builtin_constant_p()
Because __builtin_constant_p() is sometimes (ab)used as a static analyzer, the documentation should give more details what is expected to work, and what you should not use it for. (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359) Here is my suggestion, please incorporate it into the gcc 4.4.0 documentation if you consider it appropriate: - __builtin_constant_p() can return 1 even if during the execution of the program it never is a constant for example: the optimizer splits the case when a value is zero and non-zero, and fully expands the zero case, considering the variable is zero. This doesn't mean that during a real execution the value can ever be zero. This can happen for example if the optimizer cannot "see" that a certain value is impossible. - __builtin_constant_p() is not a static analyzer, as it doesn't offer soundness or completeness guarantees for the analysis it makes - when you write optimized code for the __builtin_constant_p() == 1 case, you should not treat invalid constant values as build time errors, instead you should fall back to using the generic code at runtime (which should handle the invalid cases anyway). The reason is because gcc may constant-propagate/expand a value that may not be reached ever, because of the reasons described above. for example, instead of doing this: __builtin_constant_p(val) ? (VALID(val) ? OPTIMIZED(val) : __build_error()) : generic_case(val) Do this: (__builtin_constant_p(val) && VALID(val)) ? OPTIMIZED(val) : generic_case(val); What happens if you don't take the above advice: anytime gcc's optimizer is changed, your code may break -- Summary: documentation: improve documentation of __builtin_constant_p() Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38296
[Bug c/38295] New: Support pointer difference as constant in static initializer
The feature I'm proposing is not supported by the C standard, so I'm proposing
a gcc extension.
I am wondering if it's possible to make the difference of two function pointer
be a constant value if the two functions are defined as static and in the same
file. That would allow for function pointer tables that live in .rodata
instead of .data. Something like:
#include
typedef int (*func_t) (void);
static int func_base (void)
{
return 0;
}
static int func0 (void)
{
return 0;
}
static int func1 (void)
{
return 1;
}
size_t funcs[] = {
func0 - func_base,
func1 - func_base
};
int
main (void)
{
int i;
for (i = 0; i < 2; i++)
printf ("%d: %d\n", i, ((func_t)(funcs[i] + func_base))());
}
--
Summary: Support pointer difference as constant in static
initializer
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at behdad dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
[Bug other/38294] Enable multilib support for mingw
--- Comment #1 from nightstrike at gmail dot com 2008-11-27 17:43 --- Created an attachment (id=16785) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16785&action=view) My first crack at enabling the support -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
[Bug c++/38278] [4.4 Regression] C++ namespace collision
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38278
[Bug tree-optimization/38079] gcc segfaults when using -ftree-vectorizer-verbose=9
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38079
[Bug rtl-optimization/38281] [4.4 Regression] ice: Segmentation fault
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38281
[Bug other/38294] Enable multilib support for mingw
-- nightstrike at gmail dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
[Bug other/38294] New: Enable multilib support for mingw
Now that we have a viable header set and libraries for x86_64-pc-mingw32, we are able to support multilib. This needs to be enabled. -- Summary: Enable multilib support for mingw Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nightstrike at gmail dot com GCC target triplet: x86_64-*-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
[Bug c++/38278] [4.4 Regression] C++ namespace collision
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38278
[Bug rtl-optimization/38245] [4.4 Regression] apparent improper segfault in compiler output
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug middle-end/38237] [4.4 regression] multiple weak directives
--- Comment #2 from jsm28 at gcc dot gnu dot org 2008-11-27 17:36 --- Setting to P5, please restore to P3 if the assembler for some primary or secondary target complains about the multiple directives or incorrectly assembles the file because of them. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38237
[Bug target/38293] [4.4 regression] libgfortran build failure on spu-elf
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38293
[Bug rtl-optimization/38280] [4.4 regression] Revision 142207 breaks 416.gamess/481.wrf in SPEC CPU 2006
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-11-27 17:32 --- Setting to P4, please restore to P3 if a C or C++ test showing this problem is found. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38280
[Bug rtl-optimization/38272] [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-11-27 17:31 --- Setting to P4, please restore to P3 if a C or C++ test showing this problem is found. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38272
[Bug middle-end/37851] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3617
-- grosser at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|grosser at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37851
[Bug target/38293] New: [4.4 regression] libgfortran build failure on spu-elf
libgfortran fails to build on the trunk when building a cross compiler targeting spu-elf. Fixing the first two build failures and seeing more. This is a regression compared to 4.3 see http://gcc.gnu.org/ml/fortran/2008-11/msg00090.html -- Summary: [4.4 regression] libgfortran build failure on spu-elf Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com GCC target triplet: spu-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38293
[Bug tree-optimization/38261] [4.4 Regression] gcc.dg/torture/ipa-pta-1.c & gcc.dg/tree-ssa/alias-2.c fail with -fpic/-fPIC
--- Comment #2 from ghazi at gcc dot gnu dot org 2008-11-27 16:59 --- (In reply to comment #1) > Can you use ./contrib/gcc_update to update your gcc source tree > so that we can tell which revisions you are using? Thanks. Done, however it only works for 4.3 and trunk, not 4.2. I assume that's intentional, i.e. the mechanism in gcc_update never got backported for the 4.2 branch? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-27 16:59:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38261
[Bug gcov-profile/38292] New: corrupted profile info with -O[23] -fprofile-use
seen with a profiled build (make profile-opt PROFILE_TASK='$(srcdir)/Lib/test/regrtest.py') building python-3.0rc3 on i486-linux-gnu. Using pybench as the PROFILE_TASK doesn't show this bug). Seen PR22471, but this one was reported long ago. What other information should be provided for this kind of report? gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -fprofile-use -I. -IInclude -I../Include -DPy_BUILD_CORE -o Modules/config.o Modules/config.c ../Python/thread.c: In function 'PyThread_acquire_lock': ../Python/thread.c:419: error: corrupted profile info: number of executions for edge 16-3 thought to be -1 ../Python/thread.c:419: error: corrupted profile info: number of executions for edge 16-17 thought to be 5657524 make[3]: *** [Python/thread.o] Error 1 -- Summary: corrupted profile info with -O[23] -fprofile-use Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38292
[Bug bootstrap/38286] configure: error: cannot compute suffix of object files - cannot find as
--- Comment #2 from huffton at googlemail dot com 2008-11-27 16:19 --- Brian Thanks for the speedy response. I hadn't realised that "as" was not part of the compiler (I am new at this). I have compiled binutils and all is fine now. Marking bug as invalid as it is not a bug. Cheers PaulH -- huffton at googlemail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38286
[Bug middle-end/22141] [4.2/4.3/4.4 Regression] Missing optimization when storing structures
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg01406.html Status|NEW |ASSIGNED Last reconfirmed|2008-01-17 15:47:39 |2008-11-27 15:42:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
[Bug fortran/38252] [4.4 Regression] Empty function with CONTAINS triggers Internal Error
--- Comment #5 from mikael at gcc dot gnu dot org 2008-11-27 15:40 ---
(In reply to comment #4)
> I will investigate more next week-end (unless someone beats me ;-))
>
I'm investigating now.
The first patch was probably wrong.
I'm testing this one at the moment:
Index: parse.c
===
--- parse.c (r�vision 142242)
+++ parse.c (copie de travail)
@@ -1576,7 +1576,7 @@ typedef struct
{
enum
{ ORDER_START, ORDER_USE, ORDER_IMPORT, ORDER_IMPLICIT_NONE,
-ORDER_IMPLICIT, ORDER_SPEC, ORDER_EXEC
+ORDER_IMPLICIT, ORDER_SPEC, ORDER_EXEC, ORDER_CONTAINS
}
state;
gfc_statement last_statement;
@@ -1658,6 +1658,10 @@ verify_st_order (st_state *p, gfc_statement st, bo
p->state = ORDER_EXEC;
break;
+case ST_CONTAINS:
+ p->state = ORDER_CONTAINS;
+ break;
+
default:
gfc_internal_error ("Unexpected %s statement in verify_st_order() at
%C",
gfc_ascii_statement (st));
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mikael at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2008-11-24 22:52:46 |2008-11-27 15:40:17
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38252
[Bug bootstrap/38286] configure: error: cannot compute suffix of object files - cannot find as
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38286
[Bug c++/38076] FAIL: g++.dg/other/anon5.C
--- Comment #3 from dominiq at lps dot ens dot fr 2008-11-27 15:33 --- Fixed by revision 142163. Closing. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38076
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- Comment #52 from dominiq at lps dot ens dot fr 2008-11-27 15:31 --- *** Bug 37105 has been marked as a duplicate of this bug. *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug c++/37105] stackalign failures
--- Comment #3 from dominiq at lps dot ens dot fr 2008-11-27 15:31 --- *** This bug has been marked as a duplicate of 37012 *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37105
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #23 from steven at gcc dot gnu dot org 2008-11-27 15:26 --- Created an attachment (id=16784) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16784&action=view) less unpolished version of tree code hoisting This fixes some bugs in the proof-of-concept patch: 1. Don't hoist things out of loops. We have to look at ANTIC_IN of the block we hoist into, not the union of ANTIC_IN of all its successors. 2. Add a constraint that the hoisted expression must be computed in one of the successors of the block we're hoisting too. Also added comment so that the uninitiated don't have their eye balls dropping out in confusion ;-) I might actually post this for GCC 4.5 if it subsumes the RTL code hoisting pass. -- steven at gcc dot gnu dot org changed: What|Removed |Added Attachment #16751|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug fortran/38285] Wrong I/O output: Interaction between F and P for output
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-11-27 14:21 --- I will see what I can do. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-27 14:21:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38285
[Bug fortran/38291] Rejects I/O with POS= if FMT=*
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-11-27 14:20 --- I am on it. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-27 14:20:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38291
[Bug fortran/38291] New: Rejects I/O with POS= if FMT=*
Found at http://de.wikibooks.org/wiki/Fortran:_Fortran_2003:_Ein-_und_Ausgabe The following is valid and the error message is bogus: read( 50, *, pos = 1 ) 1 Error: FMT=* is not allowed with a REC= specifier at (1). open(50,access='stream') read( 50, *, pos = 1 ) end -- Summary: Rejects I/O with POS= if FMT=* Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: rejects-valid 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=38291
[Bug fortran/38289] "procedure( ), pointer" rejected
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-27 13:44 --- Something for you? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38289
[Bug fortran/38290] New: ICE with invalid proc-pointer
Found at http://de.wikibooks.org/wiki/Fortran:_Fortran_2003:_Zeiger The following program gives an ICE: hjff.f90:4.34: procedure( up ), pointer :: pptr => null() 1 Error: Interface 'up' of procedure 'pptr' at (1) must be explicit hjff.f90:4.15: procedure( up ), pointer :: pptr => null() 1 Error: Symbol 'up' at (1) has no IMPLICIT type f951: internal compiler error: in resolve_specific_s0, at fortran/resolve.c:2758 Please submit a full bug report, program bsp implicit none procedure( up ), pointer :: pptr => null() pptr => ooops call pptr end program bsp -- Summary: ICE with invalid proc-pointer Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code 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=38290
[Bug fortran/38289] New: "procedure( ), pointer" rejected
Found at http://de.wikibooks.org/wiki/Fortran:_Fortran_2003:_Zeiger The following is rejected because of the space in "( )". With "()" it compiles: procedure( ), pointer :: pptr => null() 1 Error: Syntax error in PROCEDURE statement at (1) -- Summary: "procedure( ), pointer" rejected Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: rejects-valid 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=38289
[Bug fortran/32795] allocatable components are nullified prematurely
--- Comment #16 from burnus at gcc dot gnu dot org 2008-11-27 13:24 --- (Most problems have been fixed, except of the one in comment 0.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32795
[Bug bootstrap/38288] New: i386/i386.c: 7 * set but not used variables
I just tried to build the GNU gcc version 4.4.0 snapshot 20081121 with the Intel C compiler, which said ../../src/gcc-4.4-20081121/gcc/config/i386/i386.c(4315): warning #593: variable "f" was set but never used ../../src/gcc-4.4-20081121/gcc/config/i386/i386.c(7479): warning #593: variable "total_size" was set but never used ../../src/gcc-4.4-20081121/gcc/config/i386/i386.c(8886): warning #593: variable "reason" was set but never used ../../src/gcc-4.4-20081121/gcc/config/i386/i386.c(8887): warning #593: variable "reason_rtx" was set but never used ../../src/gcc-4.4-20081121/gcc/config/i386/i386.c(13074): warning #593: variable "op1" was set but never used ../../src/gcc-4.4-20081121/gcc/config/i386/i386.c(13520): warning #593: variable "arithmetics_cost"was set but never used ../../src/gcc-4.4-20081121/gcc/config/i386/i386.c(16432): warning #593: variable "piece_size_mask" was set but never used I checked the source code and I agree with the Intel compiler. Suggest delete all seven set but not used variables. -- Summary: i386/i386.c: 7 * set but not used variables Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38288
[Bug fortran/34143] alloc_comp_constructor.f90 fails with -fdefault-integer-8
--- Comment #15 from burnus at gcc dot gnu dot org 2008-11-27 13:21 --- I think PR is fixed on the trunk (4.4) [-> back porting?], except of the issue of comment 13 (-> different PR?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
[Bug target/38287] New: wrong-code with -O2 -fPIC on sparc-linux-gnu
[forwarded from http://bugs.debian.org/506713]
seen with 4.1, 4.2, 4.3 branches, not on the trunk
Functions compiled for SPARC with both -O2 and -fPIC options, which
return structures and require global data, may have incorrect code
generated for them.
The following example is based on Qt 3, which is affected by this bug
(see #490999). The code should of course print "1 + 1 = 2" but when
compiled for SPARC with -O2 -fPIC it prints "1 + 1 = 0" (or may crash).
The first two instructions generated for QTime::addMSecs() are a save
using %sp and a load relative to %sp which depends on the *old* value of
%sp.
This example appears to be compiled correctly if I remove either option
or reduce the value of MSECS_PER_DAY such that it can be an immediate
constant.
Ben.
#include
class QTime
{
public:
explicit QTime(int ms = 0) : ds(ms) {}
static QTime currentTime() { return QTime(); }
QTime addMSecs(int ms) const;
int msecs() const { return ds; }
private:
unsigned ds;
};
static const unsigned MSECS_PER_DAY = 8640;
QTime QTime::addMSecs( int ms ) const
{
QTime t;
if ( ms < 0 ) {
// % not well-defined for -ve, but / is.
int negdays = (MSECS_PER_DAY-ms) / MSECS_PER_DAY;
t.ds = ((int)ds + ms + negdays*MSECS_PER_DAY)
% MSECS_PER_DAY;
} else {
t.ds = ((int)ds + ms) % MSECS_PER_DAY;
}
return t;
}
int main(int argc, char* argv[] )
{
std::cout << "1 + 1 = " << QTime(1).addMSecs(1).msecs() << std::endl;
}
--
Summary: wrong-code with -O2 -fPIC on sparc-linux-gnu
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: sparc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38287
[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
--- Comment #15 from tehila at il dot ibm dot com 2008-11-27 12:57 --- (In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > Thanks, Andrey. > > I think there are 2 "issues" here: > > 1. register-renaming. (more related to this PR, I think) > > 2. schuedule-insns. > > Both of them slows compilation. > > With ARG4, on SPU, I see: > > -O1: 9m28.355s > > -O1 -fno-rename-registers:0m19.196s > > -O2: 184m37.492s (not >1000 as I wrote, but >100) > > -O2 -fno-rename-registers: 31m29.482s > > -O2 -fno-schedule-insns: 10m26.851s > > -O2 -fno-rename-registers -fno-schedule-insns: 0m39.425s > Do you see this on ppc to spu cross? How was your compiler configured? Yes (ppc(ppu) to spu cross). Configuration: --target=spu --disable-shared --disable-threads --disable-checking --with-headers --with-newlib --with-system-zlib --enable-languages=c --disable-nls --enable-version-specific-runtime-libs --disable-libssp --program-prefix=spu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
--- Comment #14 from abel at gcc dot gnu dot org 2008-11-27 12:50 --- (In reply to comment #13) > (In reply to comment #12) > Thanks, Andrey. > I think there are 2 "issues" here: > 1. register-renaming. (more related to this PR, I think) > 2. schuedule-insns. > Both of them slows compilation. > With ARG4, on SPU, I see: > -O1: 9m28.355s > -O1 -fno-rename-registers:0m19.196s > -O2: 184m37.492s (not >1000 as I wrote, but >100) > -O2 -fno-rename-registers: 31m29.482s > -O2 -fno-schedule-insns: 10m26.851s > -O2 -fno-rename-registers -fno-schedule-insns: 0m39.425s Do you see this on ppc to spu cross? How was your compiler configured? I will try again with the full test case when you'll tell me your configure options. (For my reduced test case, all scheduling was around 10% without register renaming, as you can see from cc1 output, which is why I didn't look further into this.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
--- Comment #13 from tehila at il dot ibm dot com 2008-11-27 12:20 --- (In reply to comment #12) Thanks, Andrey. I think there are 2 "issues" here: 1. register-renaming. (more related to this PR, I think) 2. schuedule-insns. Both of them slows compilation. With ARG4, on SPU, I see: -O1: 9m28.355s -O1 -fno-rename-registers:0m19.196s -O2: 184m37.492s (not >1000 as I wrote, but >100) -O2 -fno-rename-registers: 31m29.482s -O2 -fno-schedule-insns: 10m26.851s -O2 -fno-rename-registers -fno-schedule-insns: 0m39.425s Should I open a different PR for scheduling? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
[Bug c/38286] configure: error: cannot compute suffix of object files - cannot find as
--- Comment #1 from brian at dessent dot net 2008-11-27 11:29 --- Subject: Re: New: configure: error: cannot compute suffix of object files - cannot find as The assembler is not part of gcc. You need to build and install binutils for your target (which will result in the cross-assembler and cross-linker) before attempting to build the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38286
[Bug fortran/38282] Add the remaining HPF bit intrinsics
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-27 11:14 --- (In reply to comment #0) > POPCNT and POPPAR are present in many other compilers And (even) more interestingly they are part of the Fortran 2008 Candidate Release (as you also mentioned): 13.7.128 POPCNT (I) Description. Number of one bits. Class. Elemental function. Argument. I shall be of type integer. Result Characteristics. Default integer. Result Value. The result value is equal to the number of one bits in the sequence of bits of I. The model for the interpretation of an integer value as a sequence of bits is in 13.3. 13.7.129 POPPAR (I) Description. Parity expressed as 0 or 1. Class. Elemental function. Argument. I shall be of type integer. Result Characteristics. Default integer. Result Value. POPPAR (I) has the value 1 if POPCNT (I) is odd, and 0 if POPCNT (I) is even. * * * For completeness: Fortran 2008 and also the HPF standard also list the following "Array Reduction Functions" (HPF): - IALL - Bitwise AND of all the elements of ARRAY along dimension DIM corresponding to the true elements of the mask - IANY - Bitwise OR of all the elements of ARRAY along dimension DIM corresponding to the true elements of MASK. - IPARITY - Bitwise exclusive OR of all the elements of ARRAY along dimension DIM corresponding to the true elements of MASK. - PARITY - True if and only if an odd number of values are true in MASK along dimension DIM. And Fortran 2008 also the following elemental procedures for bits: - DSHIFTL(I,J,SHIFT) - Combined left shift - DSHIFTR(I,J,SHIFT) - Combined right shift - SHIFTA - Right shift with fill. - SHIFTL - Left shift - SHIFTR - Right shift - MASKL Left justified mask - MASKR - Right justified mask - BGE - True if and only if I is bitwise greater than or equal to J - BGT - True if and only if I is bitwise greater than J. - BLE - True if and only if I is bitwise less than or equal to J - BLT - True if and only if I is bitwise less than J. - MERGE_BITS - Merge of bits under mask -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug c/38286] New: configure: error: cannot compute suffix of object files - cannot find as
Create build dir: $ mkdir -p /home/paul/Programs/gcc/arm $ cd /home/paul/Programs/gcc/arm Ran configure: $ /home/paul/Programs/gcc/gcc-4.3.2/configure --target arm-linux-elf --srcdir=/home/paul/Programs/gcc/gcc-4.3.2/ --prefix=/home/paul/Programs/gcc/gcc-arm --program-prefix=arm- --with-local-prefix=/home/paul/Programs/gcc/gcc-arm/local --enable-languages=c Completed OK. Ran make $ make ... Checking multilib configuration for libgcc... mkdir -p -- arm-linux-elf/libgcc Configuring in arm-linux-elf/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... no checking for mawk... mawk checking build system type... i686-pc-linux-gnu checking host system type... arm-linux-elf checking for arm-linux-elf-ar... arm-linux-elf-ar checking for arm-linux-elf-lipo... arm-linux-elf-lipo checking for arm-linux-elf-nm... /home/paul/Programs/gcc/arm/./gcc/nm checking for arm-linux-elf-ranlib... arm-linux-elf-ranlib checking for arm-linux-elf-strip... arm-linux-elf-strip checking whether ln -s works... yes checking for arm-linux-elf-gcc... /home/paul/Programs/gcc/arm/./gcc/xgcc -B/home/paul/Programs/gcc/arm/./gcc/ -B/home/paul/Programs/gcc/gcc-arm/arm-linux-elf/bin/ -B/home/paul/Programs/gcc/gcc-arm/arm-linux-elf/lib/ -isystem /home/paul/Programs/gcc/gcc-arm/arm-linux-elf/include -isystem /home/paul/Programs/gcc/gcc-arm/arm-linux-elf/sys-include checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [configure-target-libgcc] Error 1 make[1]: Leaving directory `/home/paul/Programs/gcc/arm' make: *** [all] Error 2 --- The relevant section in configure.log is: --- configure:2567: checking for suffix of object files configure:2588: /home/paul/Programs/gcc/arm/./gcc/xgcc -B/home/paul/Programs/gcc/arm/./gcc/ -B/home/paul/Programs/gcc/gcc-arm/arm-linux-elf/bin/ -B/home/paul/Programs/gcc/gcc-arm/arm-linux-elf/lib/ -isystem /home/paul/Programs/gcc/gcc-arm/arm-linux-elf/include -isystem /home/paul/Programs/gcc/gcc-arm/arm-linux-elf/sys-include -c -O2 -g -g -O2 conftest.c >&5 exec: 79: : Permission denied configure:2591: $? = 1 --- Running the command manually with strace reveals that gcc is calling "gcc/as", which is looking for a previous cross compiling version of "as". There is no "as" built yet as far as I can see (No other "as", no "xas" no "arm-as"), and I do not have an older cross compiler installed. Changing as to be not executable makes gcc call "as" from the build system. This fails, I believe it wants a cross compiler version. I am unsure as to why "as" has not been built, would it be built later in the process, or has it failed silently? Cheers PaulH -- Summary: configure: error: cannot compute suffix of object files - cannot find as Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: huffton at googlemail dot com GCC build triplet: x86-linux-elf GCC host triplet: x86-linux-elf GCC target triplet: arm-linux-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38286
[Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57
--- Comment #8 from dennis dot wassel at googlemail dot com 2008-11-27 10:32 --- (In reply to comment #6) > This ICE is different than the one you reported first: this fails in the > debug dumps function. Could you report the backtrace using the following > flags: > > gfortran -O3 -ftree-vectorize -ftree-parallelize-loops=2 -c ma57.f Found the error report function and put a breakpoint on it. This is where the trouble stems from: Starting program: /localdata/libexec/gcc/i686-pc-linux-gnu/4.3.2/f951 ma57.f -ffixed-form -quiet -dumpbase ma57.f -mtune=athlon64 -march=athlon64 -auxbase ma57 -O3 -version -ftree-vectorize -ftree-parallelize-loops=2 -fintrinsic-modules-path /localdata/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/finclude -o /tmp/cc2PjThK.s Failed to read a valid object file image from memory. GNU F95 (GCC) version 4.3.2 (i686-pc-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Breakpoint 2, pp_printf (pp=0x87a3050, msg=0x862be16 "In function %qs") at pretty-print.c:772 (gdb) bt #0 pp_printf (pp=0x87a3050, msg=0x862be16 "In function %qs") at pretty-print.c:772 #1 0x08218c00 in lhd_print_error_function (..., file=0x87c56d8 "ma57.f", ...) at langhooks.c:408 #2 0x08177791 in diagnostic_report_current_function at diagnostic.c:268 #3 0x08177d79 in default_diagnostic_starter at diagnostic.c:306 #4 0x08177a42 in diagnostic_report_diagnostic at diagnostic.c:421 #5 0x0817811f in error (gmsgid=0x86d295c "edge from %d to %d should be marked irreducible") at diagnostic.c:558 #6 0x08557f9a in verify_loop_structure () at cfgloop.c:1433 #7 0x08304d0a in parallelize_loops () at tree-parloops.c:1801 #8 0x08355be5 in tree_parallelize_loops () at tree-ssa-loop.c:486 #9 0x082466ea in execute_one_pass (pass=0x875c440) at passes.c:1122 #10 0x082469ef in execute_pass_list (pass=0x875c440) at passes.c:1175 #11 0x08246a10 in execute_pass_list (pass=0x875c100) at passes.c:1176 #12 0x08246a10 in execute_pass_list (pass=0x875b900) at passes.c:1176 #13 0x082fe85a in tree_rest_of_compilation (fndecl=0xb7a575b0) at tree-optimize.c:404 #14 0x084081fd in cgraph_expand_function (node=0xb79e5680) at cgraphunit.c:1157 #15 0x08408cc5 in cgraph_optimize () at cgraphunit.c:1220 #16 0x080e7c95 in gfc_be_parse_file (set_yydebug=0) at fortran/f95-lang.c:264 #17 0x082ca6f8 in toplev_main (argc=18, argv=0xbf9c8714) at toplev.c:1042 #18 0x08127aff in main (argc=142225528, argv=0x8be3d70) at main.c:35 If I remove both the -march and -mtune options, the error message changes (different edge numbers/indices/whatever) to ma57.f: In function 'ma57od': ma57.f:2724: error: edge from 694 to 704 should be marked irreducible ma57.f:2724: error: basic block 704 should be marked irreducible ma57.f:2724: error: edge from 704 to 697 should be marked irreducible ma57.f:2724: error: basic block 697 should be marked irreducible ma57.f:2724: error: edge from 697 to 120 should be marked irreducible ma57.f:2724: confused by earlier errors, bailing out Cheers, Dennis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37951
[Bug c++/38278] [4.4 Regression] C++ namespace collision
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-27 10:29 --- Introduced by PR28513 fix http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142056 -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38278
[Bug middle-end/38284] verify_stmts failed when compile with -O2 -fira -fipa-pta -fPIC
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-27 10:18 --- Still -fipa-pta is necessary to reproduce the failure. ipa-pta is broken, so, wontfix. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38284
[Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57
--- Comment #7 from dennis dot wassel at googlemail dot com 2008-11-27 10:09 --- (In reply to comment #6) > This ICE is different than the one you reported first: this fails in the > debug dumps function. Could you report the backtrace using the following > flags: > > gfortran -O3 -ftree-vectorize -ftree-parallelize-loops=2 -c ma57.f This does not produce an ICE but the following fatal error (just checked: it's exactly the same as the one in my first post without -ftree-vectorize) gfortran -O3 -ftree-vectorize -ftree-parallelize-loops=2 -c ma57.f ma57.f: In function 'ma57od': ma57.f:2724: error: edge from 840 to 850 should be marked irreducible ma57.f:2724: error: basic block 850 should be marked irreducible ma57.f:2724: error: edge from 850 to 843 should be marked irreducible ma57.f:2724: error: basic block 843 should be marked irreducible ma57.f:2724: error: edge from 843 to 160 should be marked irreducible ma57.f:2724: confused by earlier errors, bailing out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37951
[Bug rtl-optimization/38281] [4.4 Regression] ice: Segmentation fault
--- Comment #4 from jakub at gcc dot gnu dot org 2008-11-27 10:01 ---
Yeah, that looks reasonable (though I wonder if other places that use PATTERN
in
distribute_notes don't need similar treatment).
Simplified testcase below. Are you going to post it to gcc-patches?
inline unsigned short
foo (unsigned short x, unsigned short y)
{
if (y == 0)
return x;
return x / y;
}
unsigned short a, b, c;
extern int baz (int, int);
void
bar (void)
{
int d = 0x3D75D162;
a = foo (b > d, baz (0, 1));
for (c = 0; c; c = 1)
;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38281
[Bug fortran/38285] Wrong I/O output: Interaction between F and P for output
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-27 09:37 --- This is a regression with regards to g77. The email itself (for completeness): http://j3-fortran.org/pipermail/j3/2008-November/002084.html The problem only occurs for a d (Fw.d) of "0", for, e.g., "4PF14.1" gfortran and the other compilers print: "3742.0". Thus, I think the problem is the special case for abs(internal number) < 0 together with Fw.d with d == 0. >From the F2003 standard: "10.7.5 P editing" "The kP edit descriptor temporarily changes (9.4.1) the scale factor for the connection to k. The scale factor affects the editing of F, E, EN, ES, D, and G edit descriptors for numeric quantities." [...] "(1) On [...] F output editing, the scale factor effect is that the externally represented number equals the internally represented number multiplied by 10^k." -- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.3 4.2.1 4.3.2 4.4.0 Known to work||3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38285
[Bug fortran/38285] New: Wrong I/O output: Interaction between F and P for output
Found on the J3 mailing list. gfortran is the compiler which prints "0.0"as second number (4.1 to 4.4); ifort, g95, NAG f95, openf95 and sunf95 print the 3742 twice. Van Snyder writes: The list items in subclause 10.8.5 "P editing" of 08-007r2 that begin "On output,..." are silent concerning the effect of P editing on F editing for output. The specification of the effect of P on F during output is hiding in the first list item, which begins "On input," With the little program program F_and_P print 1, 3742.0, 0.3742 1 format ( f14.0, 4pf14.0 ) end program F_and_P five of my six compilers produce a program that (correctly) prints 3742. 3742. while one (incorrectly) prints 3742. . This treatment of F and P interaction goes back to F66 (7.2.3.5.1, 7.2.3.6.2), F77 (13.5.7.1, 13.5.9.2.1), and f90/95 (10.6.5, 10.5.1.2.1). The effect of P on F output would be more clearly explained in a separate list item, say between the second and third items. I don't think it's possible to rearrange the first list item both to be correct and not to hide either the input or output effect. -- Summary: Wrong I/O output: Interaction between F and P for output Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code 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=38285
