[Bug rtl-optimization/42433] New: -Os generates wrong code when stdcall function with 3+ arguments does double tail call via function pointer.
The bug occurs when I compile the following code:
===
__attribute__((stdcall)) int (*P)(int A, int B, int C) = 0;
__attribute__((stdcall)) int X(int A, int B, int C)
{
if(A) return P(A, B, C);
return P(42, B, C);
}
===
(This is the full file after trimming everything unrelated to the problem. You
can paste this in a file.)
Note that P is a callback. It got filled in somewhere else, but this is all the
code needed to see the problem manifest itself. The bug only shows up if:
* P is a function pointer.
* Both P and X are stdcall.
* P and X have at least three arguments.
* Tail call optimisation is done.
* Double call optimisation is done.
For the last two reasons I tagged the bug rtl-optimisation, since I think it's
highly likely that it's an optimisation problem. I compile this code using the
following command:
$ gcc bug.cpp -S bug.s -Os -fomit-frame-pointer -masm=intel
The last two parameters are not necessary to make the bug manifest itself, but
this way it hides in a lot less generated assembler output. No errors or
warnings are generated, but the result is:
==
.file bug.cpp
.intel_syntax
.globl _P
.bss
.align 4
_P:
.space 4
.text
.align 2
.globl __z1x...@12
.def__z1x...@12;.scl2; .type 32; .endef
__z1x...@12:
pushebx
mov edx, DWORD PTR [esp+8]
mov ecx, DWORD PTR [esp+12]
mov eax, DWORD PTR [esp+16]
testedx, edx
jne L3
mov DWORD PTR [esp+16], eax
mov DWORD PTR [esp+12], ecx
mov DWORD PTR [esp+8], 42
L3:
pop ebx
jmp ebx
==
(Note that numbers are decimal.)
When not all the conditions for the bug to appear are fulfilled, whatever
register the final jmp takes gets set to the right value using a mov
instruction. But in this case, the mov instruction doesn't get emitted and the
register is wrong. So instead of calling the callback function, the code jumps
to the Elysian Fields.
Note: I don't know why it push-pops ebx, since it doesn't get touched.
Similarly, I don't know what some of the mov instructions are hoping to
accomplish. Otherwise, the code is correct, and if the bug-triggering
conditions mentioned aren't present, the callback gets called and correctly
returns the right result.
Version: gcc.exe (GCC) 3.4.5 (mingw-vista special r3)
Platform: x86 Win32
--
Summary: -Os generates wrong code when stdcall function with 3+
arguments does double tail call via function pointer.
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: congruwer at yahoo dot co dot uk
GCC build triplet: Idem. I apologize.
GCC host triplet: Don't know what this is or how to obtain it and a web
search did
GCC target triplet: Likewise.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42433
[Bug target/42433] -Os generates wrong code when stdcall function with 3+ arguments does double tail call via function pointer.
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-19 09:30 --- First can you try a newer GCC since 3.4.x is no longer supported. 4.3.4 is the latest release. Second sicne this is a modified version of GCC, you should report the bug to the place where you got the binary/ -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|rtl-optimization|target GCC build triplet|Idem. I apologize. |i686-pc-mingw32 GCC host triplet|Don't know what this is or |i686-pc-mingw32 |how to obtain it and a web | |search did | GCC target triplet|Likewise. |i686-pc-mingw32 Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42433
[Bug fortran/28484] F2003: system_clock with real-type count_rate does not compile
--- Comment #12 from jb at gcc dot gnu dot org 2009-12-19 10:50 --- Since the actual implementation of system_clock has no use for non-integer count rates, this should be implemented by creating an integer temporary in the frontend and then calling the existing functions. Also, note that as of r155359 the integer(8) version of system_clock now provides microsecond resolution. In the future, this could be improved further by switching to using clock_gettime(CLOCK_MONOTONIC,...) which in addition to providing better resolution also gives a monotonic clock instead of a realtime clock that gettimeofday() gives. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28484
[Bug fortran/42434] New: Documentation should provide advise about clock resolutions
The gfortran documentation should advise the user about the clock resolutions she/he might expect when calling the various clock intrinsics DATE_AND_TIME, SYSTEM_CLOCK, and CPU_TIME. -- Summary: Documentation should provide advise about clock resolutions Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42434
[Bug target/42433] -Os generates wrong code when stdcall function with 3+ arguments does double tail call via function pointer.
--- Comment #2 from congruwer at yahoo dot co dot uk 2009-12-19 10:57 --- (In reply to comment #1) First can you try a newer GCC since 3.4.x is no longer supported. I do apologize - the updater never notified me so I just assumed I was using the latest stable release. I have updated and the problem appears to be fixed. For reference, the new output is: == .file bug.cpp .intel_syntax noprefix .text .globl __z1x...@12 .def__z1x...@12;.scl2; .type 32; .endef __z1x...@12: LFB0: pushebx LCFI0: sub esp, 8 LCFI1: mov ebx, DWORD PTR [esp+16] mov edx, DWORD PTR [esp+20] mov ecx, DWORD PTR [esp+24] testebx, ebx mov eax, DWORD PTR _P jne L4 mov DWORD PTR [esp+24], ecx mov DWORD PTR [esp+20], edx mov DWORD PTR [esp+16], 42 L4: pop edx pop ecx pop ebx jmp eax LFE0: .globl _P .bss .align 4 _P: .space 4 == As you can see, this code is correct, if perhaps a bit more convoluted than strictly necessary. (Same as above + it allocates stack space that it never uses. But it's correct and therefore, this bug will be deemed fixed.) Many many thanks for your quick response and my deepest apologies for unwittingly wasting your time. -- congruwer at yahoo dot co dot uk changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42433
[Bug fortran/39654] ABI bug: FTELL intrinsic function not capable of large files
--- Comment #6 from jb at gcc dot gnu dot org 2009-12-19 11:03 --- (In reply to comment #5) (In reply to comment #4) (In reply to comment #3) Gentlemen, What is the word on this? A WONTFIX? Certainly this should be fixed, eventually. Whether it will be fixed for 4.5 or sometime later remains to be seen. Personally, I don't think it's particularly high priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #42 from rguenth at gcc dot gnu dot org 2009-12-19 11:25 --- Subject: Bug 42108 Author: rguenth Date: Sat Dec 19 11:24:49 2009 New Revision: 155360 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155360 Log: 2009-12-19 Richard Guenther rguent...@suse.de PR tree-optimization/42108 * tree-ssa-sccvn.c (last_vuse_ptr): New variable. (vn_reference_lookup_2): Update last seen VUSE. (vn_reference_lookup_3): Avoid updating last seen VUSE after translating. (visit_reference_op_load): Use last seen VUSE from the first lookup when entering into the table. * gfortran.dg/pr42108.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr42108.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file
--- Comment #14 from dfranke at gcc dot gnu dot org 2009-12-19 11:38 --- (In reply to comment #7) Support for this type of format has now been added to xgettext. The support will be contained in gettext 0.18. I got as far as recreating the .pot for testing. Tried to compile the updated gettext (comment #7) from git, but the dependencies, e.g. full Java and C#/Mono envvironments, are too numerous to follow that route. Thus waiting for gettext-0.18 to be released. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-12-18 09:56:10 |2009-12-19 11:38:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
[Bug lto/42401] wrong-code with -flto
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-19 11:41 --- Subject: Bug 42401 Author: rguenth Date: Sat Dec 19 11:41:14 2009 New Revision: 155361 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155361 Log: 2009-12-19 Richard Guenther rguent...@suse.de PR lto/42401 * lto-streamer-out.c (tree_is_indexable): Local statics are indexable. (lto_output_tree_ref): Adjust assert. * g++.dg/lto/20091219_0.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/lto/20091219_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42401
[Bug lto/42401] wrong-code with -flto
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-12-19 11:41 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Keywords|missed-optimization | Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42401
[Bug debug/42425] ICE declaring local class
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-19 12:15 --- We free too many DECL and TYPE contexts which confuses dwarf2out.c. Now in the end the contexts shouldn't drag in too many extra trees though 1) we'd need support for streaming NAMESPACE_DECLs 2) we should be able to get rid of most abstract DECLs and references to them, they are the source of most bloat in the lto streams for C++ code. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-19 12:15:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42425
[Bug rtl-optimization/14319] incorrect optimization of union of structs with common initial sequences
--- Comment #8 from dvilleneuve at kronos dot com 2009-12-19 14:41 --- (In reply to comment #7) *** Bug 42432 has been marked as a duplicate of this bug. *** Sorry for the duplicate. Seems I did not search enough... The resolution I've found for DR 257 is that there are no defects and that the standard does not need to be changed. The argument of DR 257 is about asking why the wording of 6.5.2.3#5 would be necessary (i.e., not redundant with the rest of the standard). DR 257 mentions 2 possibilities: a) padding: DR 257 rules that out, concluding that 6.5.2.3#5 is not needed for that case. b) aliasing from two different structs: DR 257 raises a special case with no common initial prefix and concludes on that specific case that 6.5.2.3#5 is not needed for that case too. However, the bug currently raised falls in neither a) nor b). It's about aliasing two different structs that actually have a common initial prefix. So maybe the wording of 6.5.2.3#5 is needed for _that_ case. But if we choose the interpretation brought by RTH in comment #1, to the effect that the common initial sequence should be accessed through a union, then there is no need for the wording of 6.5.2.3#5 specifying anywhere that a declaration of the complete type of the union is visible, because it's not possible to access u.x.x without such a declaration in scope. Since resolution to DR 257 seems to confirm that the wording is the intended one (including that no words are meaningless and redundant), then the above interpretation cannot stand. Therefore, I would say that the mere visibility of the union when compiling f in the example instructs the compiler that xp and yp are possible aliases. Again from DR 257, if one wants to tell the compiler that no such aliasing occurs, the restrict keyword can then be used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319
[Bug libstdc++/42352] -std=c++0x reference binding problem
--- Comment #14 from rwgk at yahoo dot com 2009-12-19 15:09 --- (In reply to comment #13) That said, this specific issue has been moved yesterday to [Tentatively Ready] and it's safe enough to simply re-add for now the C++03 set of overloads (we don't implement yet the C++0x allocator model), I'll do that later today. For the records, I can now use -std=c++0x again for everything we have (I tested with svn rev. 155354). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared
--- Comment #18 from armand dot potter at free dot fr 2009-12-19 15:44 --- Configure is as follow: /tmp/gcc-4.4.2/configure --enable-shared --enable-clocale=gnu --enable-__cxa_atexit --libexecdir=/usr/lib --enable-threads=posix --enable-languages=c,c++ --build=i686-pc-linux-gnu --host=x86_64-mine-linux-gnu --target=x86_64-mine-linux-gnu Here is the error: make[2]: Entering directory `/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3' make AR_FLAGS=rc CC_FOR_BUILD=gcc CC_FOR_TARGET=x86_64-mine-linux-gnu-gcc CFLAGS=-g -O2 -pipe -march=athlon64 CXXFLAGS=-O2 -pipe -march=athlon64 -D_GNU_SOUR CE CFLAGS_FOR_BUILD= CFLAGS_FOR_TARGET=-g -O2 -pipe -march=athlon64 INSTALL=/usr/bin/install -c INSTALL_DATA=/usr/bin/install -c -m 644 INSTALL_PROGRAM=/usr/b in/install -c INSTALL_SCRIPT=/usr/bin/install -c LDFLAGS= LIBCFLAGS=-g -O2 -pipe -march=athlon64 LIBCFLAGS_FOR_TARGET=-g -O2 -pipe -march=athlon64 MAKE=make MAKEINFO=makeinfo --split-size=500 --split-size=500 PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh RUNTESTFLAGS= exec_prefix=/usr infodir=/usr/share/inf o libdir=/usr/lib includedir=/usr/include prefix=/usr tooldir=/usr/x86_64-mine-linux-gnu gxx_include_dir=/usr/include/c++/4.4.2 AR=/usr/lib/gcc/x86_64-mine-li nux-gnu/4.4.2/../../../../x86_64-mine-linux-gnu/bin/ar AS=/usr/lib/gcc/x86_64-mine-linux-gnu/4.4.2/../../../../x86_64-mine-linux-gnu/bin/as LD=/usr/lib/gcc/x86_64-min e-linux-gnu/4.4.2/../../../../x86_64-mine-linux-gnu/bin/ld RANLIB=/usr/lib/gcc/x86_64-mine-linux-gnu/4.4.2/../../../../x86_64-mine-linux-gnu/bin/ranlib NM=/usr/lib/gc c/x86_64-mine-linux-gnu/4.4.2/../../../../x86_64-mine-linux-gnu/bin/nm NM_FOR_BUILD= NM_FOR_TARGET=/usr/lib/gcc/x86_64-mine-linux-gnu/4.4.2/../../../../x86_64-mine-li nux-gnu/bin/nm DESTDIR= WERROR= all-recursive make[3]: Entering directory `/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3' Making all in include make[4]: Entering directory `/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include' mkdir -p ./x86_64-mine-linux-gnu/bits/stdtr1c++.h.gch x86_64-mine-linux-gnu-c++ -x c++-header -O2 -pipe -march=athlon64 -D_GNU_SOURCE -I/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/x86_64-mine-linux-gnu -I/ tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include -I/tmp/gcc-4.4.2/libstdc++-v3/libsupc++ -O2 -g /tmp/gcc-4.4.2/libstdc++-v3/include/precompiled/stdtr1c++.h -o x86 _64-mine-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch In file included from /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1/cfenv:46, from /tmp/gcc-4.4.2/libstdc++-v3/include/precompiled/stdtr1c++.h:33: /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:49: error: '::fenv_t' has not been declared /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:50: error: '::fexcept_t' has not been declared /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:53: error: '::feclearexcept' has not been declared /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:54: error: '::fegetexceptflag' has not been declared /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:55: error: '::feraiseexcept' has not been declared /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:56: error: '::fesetexceptflag' has not been declared /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:57: error: '::fetestexcept' has not been declared /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:59: error: '::fegetround' has not been declared /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:60: error: '::fesetround' has not been declared /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:62: error: '::fegetenv' has not been declared /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:63: error: '::feholdexcept' has not been declared /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:64: error: '::fesetenv' has not been declared /tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:65: error: '::feupdateenv' has not been declared make[4]: *** [x86_64-mine-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch] Error 1 make[4]: Leaving directory `/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/tmp/gcc-build' make: *** [all] Error 2 And with -E | grep -i fenv: subway:/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include$ x86_64-mine-linux-gnu-c++ -x c++-header -O2 -pipe -march=athlon64 -D_GNU_SOURCE -I/tmp/gcc-build/x86_64-mine-linux-gnu/libstdc++-v3/include/x86_64-mine-linux-gnu
[Bug rtl-optimization/42429] Miscompilation of 2fish on s390
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-19 16:06 --- Created an attachment (id=19350) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19350action=view) 2fish.c Updated testcase with lots of asm scheduling barriers inserted, still failing (and with no- added to optimize attribute not failing). It seems the first problem is in between the two asms with 5 nops, i.e. in computation of CALC_K (w, 2, 0xB3, 0xC6, 0xE8, 0xF4); Correct value is ctx-w[2] = 0x78ea11ea; ctx-w[3] = 0xa1980bae; but the miscompiled version gives 0x5c764146 and 0xb9f6c375. This macro only depends on the mds and q0 const arrays and on const * key pointer, so doesn't need to depend on any automatic variables in the function. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #19347|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42429
[Bug c++/28300] In-class partial specialization of class accepted
--- Comment #4 from jason at gcc dot gnu dot org 2009-12-19 16:37 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28300
[Bug fortran/40824] F2003: GENERIC interface with generic name = derived-type name
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-19 17:58 --- This is going to be big trouble to fix. I do not know how we can easily distinguish between two symbols with the same name and different flavours. Maybe derived types should not be in the symtree but in one of their own? Confirmed Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-19 17:58:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40824
[Bug fortran/40849] String extraction for translation fails when concatenating with preprocessor symbols
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-19 18:02 --- Goran, What you say is manifestly so. However, as a native English speaker I have no need of translation. Have CC'd Tobias in the hope that it is as irritating to a German as a Swede :-) Thanks for the report. Confirmed Paul -- pault 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 Last reconfirmed|-00-00 00:00:00 |2009-12-19 18:02:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40849
[Bug rtl-optimization/42429] Miscompilation of 2fish on s390
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-19 18:40 ---
After sched1 we have:
(insn 6094 6056 6069 83 u4.c:511 (set (reg:QI 5621)
(mem/s/u/j:QI (plus:SI (reg/f:SI 5441)
(reg:SI 5619)) [0 q1 S1 A8])) 73 {*movqi} (expr_list:REG_DEAD
(reg:SI 5619)
(expr_list:REG_EQUAL (mem/s/u/j:QI (plus:SI (reg:SI 5619)
(symbol_ref:SI (q1) [flags 0x402] var_decl
0x7f2ced1c55a0 q1)) [0 q1 S1 A8])
(nil
...
(insn 6096 6058 6071 83 u4.c:511 (parallel [
(set (subreg:SI (reg:QI 5620) 0)
(xor:SI (subreg:SI (reg:QI 5621) 0)
(subreg:SI (reg:QI 5622) 0)))
(clobber (reg:CC 33 %cc))
]) 392 {*xorsi3} (expr_list:REG_DEAD (reg:QI 5622)
(expr_list:REG_DEAD (reg:QI 5621)
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)
The register pressure is extremely high (unnecessarily so, but that's tree opt
issue), so reg:QI 5621 is
spilled:
(insn 10902 6056 10903 83 u4.c:511 (set (reg:SI 14 %r14)
(symbol_ref:SI (q1) [flags 0x402] var_decl 0x7f2ced1c55a0 q1)) 65
{*movsi_larl} (nil))
(insn 10903 10902 10901 83 u4.c:511 (set (reg:QI 9 %r9)
(mem/s/u/j:QI (plus:SI (reg:SI 14 %r14)
(reg:SI 3 %r3 [5619])) [0 q1 S1 A8])) 73 {*movqi} (nil))
(insn 10901 10903 6094 83 u4.c:511 (set (reg:SI 14 %r14)
(const_int 4096 [0x1000])) 67 {*movsi_esa} (nil))
(insn 6094 10901 10904 83 u4.c:511 (set (mem/c:QI (plus:SI (plus:SI (reg/f:SI
15 %r15)
(reg:SI 14 %r14))
(const_int 519 [0x207])) [7 %sfp+-137 S1 A8])
(reg:QI 9 %r9)) 73 {*movqi} (expr_list:REG_EQUAL (mem/s/u/j:QI (plus:SI
(reg:SI 3 %r3 [5619])
(symbol_ref:SI (q1) [flags 0x402] var_decl 0x7f2ced1c55a0
q1)) [0 q1 S1 A8])
(nil)))
...
(insn 10912 10913 6096 83 u4.c:511 (set (reg:SI 4 %r4)
(const_int 4096 [0x1000])) 67 {*movsi_esa} (nil))
(insn 6096 10912 10915 83 u4.c:511 (parallel [
(set (reg:SI 0 %r0)
(xor:SI (reg:SI 0 %r0 [+-3 ])
(mem/c:SI (plus:SI (plus:SI (reg/f:SI 15 %r15)
(reg:SI 4 %r4))
(const_int 516 [0x204])) [7 %sfp+-140 S1 A8])))
(clobber (reg:CC 33 %cc))
]) 392 {*xorsi3} (nil))
Note it is spilled as QImode and restored using SImode.
But then DSE2 kills insn 6094:
**scanning insn=6094
cselib lookup (reg:SI 14 %r14) = 8095
cselib lookup (reg/f:SI 15 %r15) = 1
cselib value 12760 0x254ba00 (plus:SI (plus:SI (reg/f:SI 15 %r15)
(reg:SI 14 %r14))
(const_int 519 [0x207]))
...
**scanning insn=6096
cselib lookup (reg:SI 4 %r4) = 8095
cselib lookup (reg/f:SI 15 %r15) = 1
cselib lookup (reg/f:SI 15 %r15) = 1
cselib lookup (reg:SI 4 %r4) = 8095
cselib lookup (reg/f:SI 15 %r15) = 1
cselib lookup (plus:SI (plus:SI (reg/f:SI 15 %r15)
(reg:SI 4 %r4))
(const_int 516 [0x204])) = 12757
mem: (plus:SI (plus:SI (reg/f:SI 15 %r15)
(reg:SI 4 %r4))
(const_int 516 [0x204]))
after canon_rtx address: (plus:SI (plus:SI (reg/f:SI 15 %r15)
(reg:SI 4 %r4))
(const_int 516 [0x204]))
expanding: r4 into: (const_int 4096 [0x1000])
after cselib_expand address: (plus:SI (reg/f:SI 15 %r15)
(const_int 4612 [0x1204]))
after canon_rtx address: (plus:SI (reg/f:SI 15 %r15)
(const_int 4612 [0x1204]))
cselib lookup (reg/f:SI 15 %r15) = 1
varying cselib base=1 offset = 4612
processing cselib load mem:(mem/c:SI (plus:SI (plus:SI (reg/f:SI 15 %r15)
(reg:SI 4 %r4))
(const_int 516 [0x204])) [7 %sfp+-140 S1 A8])
processing cselib load against insn 6094
processing cselib load against insn 10898
mems_found = 0, cannot_delete = true
...
cselib lookup (reg/f:SI 15 %r15) = 1
varying cselib base=1 offset = 4612
processing cselib store [4612..4616)
trying store in insn=6094 gid=-1[4615..4616)
Locally deleting insn 6094
deferring deletion of insn with uid = 6094.
trying store in insn=10898 gid=-1[1223..1224)
...
deleting insn with uid = 6094.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42429
[Bug middle-end/42435] New: [4.5 regression] gfortran.dg/graphite/pr42285.f90
On Linux/ia32, revision 155361 gave Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/testsuite/gfortran/../../gfortran -B/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/gfortran/../../ /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/graphite/pr42285.f90 -O -O2 -floop-interchange -S -o pr42285.s(timeout = 300) /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/graphite/pr42285.f90: In function 'efgrdm':^M /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/graphite/pr42285.f90:3:0: internal compiler error: Segmentation fault^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html for instructions.^ Revision 155359 is OK. This test doesn't fail on Linux/x86-64. Revision 155360: http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00504.html may be the cause. -- Summary: [4.5 regression] gfortran.dg/graphite/pr42285.f90 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42435
[Bug middle-end/42435] [4.5 Regression] gfortran.dg/graphite/pr42285.f90
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5 regression]|[4.5 Regression] |gfortran.dg/graphite/pr42285|gfortran.dg/graphite/pr42285 |.f90|.f90 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42435
[Bug middle-end/42435] [4.5 Regression] gfortran.dg/graphite/pr42285.f90
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-19 18:56 --- I didn't see it with multilib testing on x86_64 either. Trying native i?86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42435
[Bug middle-end/42435] [4.5 Regression] gfortran.dg/graphite/pr42285.f90
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-19 19:05 --- Huh, it only fails from the testsuite harness, not when executing outside of that environment?! When I decrease the outside stack size limit it no longer fails in either case (decrease from 8MB to 1MB). Valgrind shows ==22802== Invalid read of size 4 ==22802==at 0x8BE74C0: lst_do_interchange_1 (graphite-interchange.c:709) ==22802==by 0x8BE754D: lst_do_interchange (graphite-interchange.c:730) ==22802==by 0x8BE7575: lst_do_interchange (graphite-interchange.c:734) ==22802==by 0x8BE7575: lst_do_interchange (graphite-interchange.c:734) ==22802==by 0x8BE760B: scop_do_interchange (graphite-interchange.c:748) ==22802==by 0x8B32895: apply_poly_transforms (graphite-poly.c:260) ==22802==by 0x8B2C2A9: graphite_transform_loops (graphite.c:276) ==22802==by 0x871F954: graphite_transforms (tree-ssa-loop.c:300) ==22802==by 0x850297B: execute_one_pass (passes.c:1561) ==22802== Address 0x4acf7b8 is 8 bytes inside a block of size 12 free'd ==22802==at 0x4024866: free (vg_replace_malloc.c:325) ==22802==by 0x8BE65FD: free_lst (graphite-poly.h:704) ==22802==by 0x8BE69B2: lst_try_interchange_loops (graphite-interchange.c:639) ==22802==by 0x8BE7355: lst_try_interchange (graphite-interchange.c:670) ==22802==by 0x8BE74AF: lst_do_interchange_1 (graphite-interchange.c:710) etc. thus this looks like a dup of PR42178. *** This bug has been marked as a duplicate of 42178 *** -- 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=42435
[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-19 19:05 --- *** Bug 42435 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42178
[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-12-19 19:05 --- Re-open. It's still broken on the trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42178
[Bug tree-optimization/42334] segfault in graphite-poly.h for 200.sixtrack
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-19 19:06 --- Re-open. Not fixed on the trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42334
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #43 from rguenth at gcc dot gnu dot org 2009-12-19 19:29 --- Btw, with the patch from comment #33 LIM will now hoist the division properly and the performance regression would be fixed(?). The patch will though likely cause verification issues with -fnon-call-exceptions for one and infrastructure-wise is still a hack. Now testing the orginal testcase on i?86 doesn't show a performance improvement though (but it's marginally faster than with 4.3). Interestingly with -mfpmath=sse -march=native trunk is a lot slower than 4.3 (but 4.3 isn't much faster than trunk w/o that options). The patch from comment #33 seems to recover that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42436] New: VRP should mark non-trapping integer divisions
In PR42108 a division is found to be non-trapping by VRP but neither PRE nor LIM can make use of that information (well, because VRP doesn't mark the divisions in any meaningful way). -- Summary: VRP should mark non-trapping integer divisions Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org OtherBugsDependingO 42108 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42436
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #44 from rguenth at gcc dot gnu dot org 2009-12-19 19:41 --- PR42436 now tracks the possible VRP and middle-end improvement. Only the PRE fixing possibility would count as a regression fix IMHO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42436] VRP should mark non-trapping integer divisions
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-19 19:42 --- I'll take care of this during 4.6 development. -- 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 Last reconfirmed|-00-00 00:00:00 |2009-12-19 19:42:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42436
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #17 from kargl at gcc dot gnu dot org 2009-12-19 19:45 --- Closing as won't fix. Currently, gfortran produces nan + i nan for finite-complex / 0 or finite-complex / (0,0) with its FE constanting folding and when the middle-end generates code. The Fortran standard does not provide any guidance with respect to exceptional FP values, and trying to get the same output of an equivalent C program is not required by either standard. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug fortran/42418] PROCEDURE: Rejects interface which is both specific and generic procedure
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-19 20:27 --- (In reply to comment #1) The following program is also rejected, unless the marked line is removed/comment out. At a glance, it looks OK - and ifort, NAG f95 and g95 accept it. The error message is: print *, fun(enisoc, [0.0]) 1 Error: ELEMENTAL non-INTRINSIC procedure 'enisoc' is not allowed as an actual argument at (1) This one I can not confirm. With a clean trunk at r155303 I do not see the error message on x86_64-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42418
[Bug libstdc++/42352] -std=c++0x reference binding problem
--- Comment #15 from paolo dot carlini at oracle dot com 2009-12-19 20:29 --- Good ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug c/42437] New: incorrect code on taking address of vectored type argument
Very simple source, but total mess in generated code !
Or, am I doing something wrong ?
Source a.c:
typedef int v4si __attribute__((__vector_size__(16), __may_alias__));
typedef long long int64_t;
int64_t xor128fold (v4si s) {
int64_t *p = (int64_t*)s;
return p[0] ^ p[1];
}
-O1 gives ugly, but kind of correct code
gcc -O1 a.c -c -o a.o
objdump -xd a.o
xor128fold:
0: 66 0f 7f 44 24 d8 movdqa %xmm0,0xffd8(%rsp)
6: 48 8b 44 24 d8 mov0xffd8(%rsp),%rax
b: 66 0f 7f 44 24 e8 movdqa %xmm0,0xffe8(%rsp)
11: 48 33 44 24 f0 xor0xfff0(%rsp),%rax
16: c3 retq
-O2 (and -O3) gives entirely incorrect code
xor128fold:
0: 66 0f 7f 44 24 d8 movdqa %xmm0,0xffd8(%rsp)
6: 48 8b 44 24 d8 mov0xffd8(%rsp),%rax
b: 48 33 44 24 f0 xor0xfff0(%rsp),%rax
10: 66 0f 7f 44 24 e8 movdqa %xmm0,0xffe8(%rsp)
16: c3 retq
Compiler
gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --prefix path omitted
Thread model: posix
gcc version 4.4.2 (GCC)
Older compiler (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46))
was able to generate correct code with -O1 (with or w/o may_alias in
typedef).
It generates same correct code with -O2/-O3 with may_alias in typedef.
xor128fold:
0: 66 0f 7f 44 24 e8 movdqa %xmm0,0xffe8(%rsp)
6: 48 8b 44 24 e8 mov0xffe8(%rsp),%rax
b: 48 33 44 24 f0 xor0xfff0(%rsp),%rax
10: c3 retq
It generates totally incorrect code with -O2/-O3 without may_alias in
typedef.
xor128fold:
0: 48 8b 44 24 e8 mov0xffe8(%rsp),%rax
5: 48 33 44 24 f0 xor0xfff0(%rsp),%rax
a: c3 retq
--
Summary: incorrect code on taking address of vectored type
argument
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Shvaiger_Felix at emc dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42437
[Bug tree-optimization/42438] New: Fix for PR38819 is too conservative
See PR42108. Basically we still can PRE a possibly trapping division in if (b) tmp = a/b; tmp = a/b; because there is no invisible exit along the paths to the insertion point. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108#c41 hints at what we should instead do. -- Summary: Fix for PR38819 is too conservative Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization 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=42438
[Bug tree-optimization/42438] Fix for PR38819 is too conservative
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-19 21:09 --- Created an attachment (id=19351) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19351action=view) unoptimized prototype -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42438
[Bug tree-optimization/42438] Fix for PR38819 is too conservative
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-19 21:09 --- Mine. -- 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 Last reconfirmed|-00-00 00:00:00 |2009-12-19 21:09:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42438
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #45 from rguenth at gcc dot gnu dot org 2009-12-19 21:10 --- (In reply to comment #41) Indeed. The PRE issue could be fixed by fixing PR38819 not in the way it is done now but properly detect the invalid situations during ANTIC computation and simply never mark trapping expressions so. At the current point its hard to tell if the insertion is valid because the original expression is always executed if the insertion point is - simply because we no longer know where the original expression was. Thus, the proper place (err, I think at least) is during translating ANTIC_OUT through the basic-block to ANTIC_IN (thus, in clean()). It might be a bit expensive, though pre-computing if a basic-block possibly exits the CFG could speed this up significantly. Another proper place would be to add fake edges to exit for each such point in the CFG (basically split blocks at each possibly noreturn call and add an edge to exit). But that might be even more expensive. Doing this in a straight-forward way shows that the division isn't partially redundant: bb 4: # j_2 = PHI 1(3), j_101(7) jmini_55 = j_2 - i_1; D.1530_57 = *nnd_28(D); if (i_1 D.1530_57) goto bb 7; else goto bb 5; bb 5: D.1576_60 = D.1530_57 - i_1; D.1577_64 = (character(kind=4)) D.1576_60; D.1583_68 = (character(kind=4)) D.1582_45; countm1.6_69 = D.1577_64 / D.1583_68; ... if (countm1.6_69 == 0) goto bb 7; else goto bb 6; bb 6: ... if (countm1.6_81 == 0) goto bb 7; else goto bb 6; bb 7: ... if (j_2 == D.1560_49) goto bb 8; else goto bb 4; bb 8: i_103 = i_1 + 1; if (i_1 == D.1582_45) goto bb 9; else goto bb 3; The division may be not executed if i nnd is always true which it is if nnd is = 2. Thus fixing PRE is not the solution here (LIM will still move the expensive division if it is proven to not trap by VRP though). That is, computing coumtm before the loop entry check as suggested by Michael. But then going with the VRP solution sounds like a better idea to me (to fix this particular regression, that is). PR42438 tracks the PRE issue now which IMHO is unrelated to this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug c/42437] incorrect code on taking address of vectored type argument
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-19 21:28 --- You need the may_alias attribute on int64_t, not on v4si. -- 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=42437
[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code
--- Comment #18 from dodji at gcc dot gnu dot org 2009-12-19 22:40 --- Subject: Bug 42225 Author: dodji Date: Sat Dec 19 22:40:37 2009 New Revision: 155363 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155363 Log: Fix PR c++/42225, take 2 gcc/cp/ChangeLog: PR c++/42225 * pt.c (push_template_decl_real): Set DECL_CONTEXT of template type parms to their containing template decl. * typeck.c (comp_template_parms_position): Split this from structural_comptypes. (incompatible_template_type_parms_p): Renamed incompatible_dependent_typedefs_p into this. Change the function to handle comparison between TEMPLATE_TYPE_PARMs only. (structural_comptypes): Use comp_template_parms_position in TEMPLATE_TEMPLATE_PARM and BOUND_TEMPLATE_TEMPLATE_PARM cases. Use incompatible_template_type_parms_p in TEMPLATE_TYPE_PARM case. * mangle.c (decl_mangling_context): Template type parms don't have a mangling context. * tree.c (cp_set_underlying_type): Set type structural equality only for TEMPLATE_TYPE_PARMs. gcc/testsuite/ChangeLog: PR c++/42225 * g++.dg/template/typedef26.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/typedef26.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code
--- Comment #19 from dodji at gcc dot gnu dot org 2009-12-19 22:43 --- This should now be fixed in trunk for 4.5 -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
[Bug c++/42058] [4.3/4.4 Regression] Trouble with invalid array initialization
--- Comment #4 from dodji at gcc dot gnu dot org 2009-12-19 23:02 --- Shouldn't this bug be closed as it has been fixed in trunk for 4.5 and the target milestone is set to 4.5.0 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42058
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #15 from js-gcc at webkeks dot org 2009-12-20 00:31 --- After looking some more at the code, I might have an idea what's causing the issue: __objc_gnu_init calls __objc_exec_class on _OBJC_MODULES. Is it possible that this call is not made for some reason if you link your lib as a dll? That would mean the classes are never loaded into the runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug c/42439] New: Linux kernel BUILD_BUG_ON() broke
The linux kernel uses a special macro BUILD_BUG_ON() that uses some tricks using bitfields to evaluate constant expressions at compile time and error out if they are violated. One of the BUILD_BUG_ON()s in a recent kernel now fail with gcc 4.5 snapshot (gcc version 4.5.0 20091219 (experimental) (GCC)), when 4.4 and earlier work. The actual expression is evaluated correctly (I replaced it with a different form and that worked) I'll be submitting a workaround to the kernel, but it might be some sort of regression. I'm attaching the preprocessed file % gcc44 fs/compat_ioctl.i -O2 -c (as expected) % gcc45 fs/compat_ioctl.i -O2 -c linux-2.6.33-rc1-ak/fs/compat_ioctl.c: In function 'compat_ioctl_check_table': linux-2.6.33-rc1-ak/fs/compat_ioctl.c:1653:24: error: bit-field 'anonymous' width not an integer constant (fails) -- Summary: Linux kernel BUILD_BUG_ON() broke Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andi-gcc at firstfloor dot org GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42439
[Bug c/42439] Linux kernel BUILD_BUG_ON() broke
--- Comment #1 from andi-gcc at firstfloor dot org 2009-12-20 00:54 --- Created an attachment (id=19352) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19352action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42439
[Bug tree-optimization/42027] [4.5 Regression] Performance regression in convolution loop optimization
--- Comment #19 from matz at gcc dot gnu dot org 2009-12-20 01:16 --- Subject: Bug 42027 Author: matz Date: Sun Dec 20 01:15:46 2009 New Revision: 155367 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155367 Log: PR tree-optimization/42027 * cfgexpand.c (expand_gimple_cond): Use jumpy sequence for , , | and || if jumps are cheap. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
[Bug c/42439] Linux kernel BUILD_BUG_ON() broke
--- Comment #2 from joseph at codesourcery dot com 2009-12-20 01:16 ---
Subject: Re: New: Linux kernel BUILD_BUG_ON() broke
This is a different sort of not-an-integer-constant-expression from the
previous cases the kernel was found to use with invalid unevaluated
operands (I asked in http://gcc.gnu.org/ml/gcc/2009-04/msg00678.html if
it was being used for bit-field widths).
const int max = [valid expression];
((void)(sizeof(struct { int:-!!(max = (1 16)); })));
Here, you are using a const variable in what's meant to be an integer
constant expression, which is only valid for C++ not C. Much the same
workaround as applied for enums in
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg02022.html would probably
work for this, but it's clearly a different undocumented extension being
used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42439
[Bug c++/42058] [4.3/4.4 Regression] Trouble with invalid array initialization
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-20 01:33 --- Maybe I should not have set the milestone ;) Seriously, normally I have no idea if somebody wants to backport the fix, and simply unassign myself... up to you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42058
[Bug lto/42441] New: lto segfaults
I started trying to build the linux kernel with LTO, but quickly ran into % gcc45 -flto -O2 -nostdlib -r -o init/built-in.o init/main.o init/version.o init/mounts.o init/initramfs.o init/calibrate.o In function 'error': lto1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /usr/local/bin/gcc45 returned 1 exit status collect2: lto-wrapper returned 1 exit status Seems error itself is broken? gcc version 4.5.0 20091219 (experimental) (GCC) -- Summary: lto segfaults Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andi-gcc at firstfloor dot org GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42441
[Bug lto/42441] lto segfaults
--- Comment #1 from andi-gcc at firstfloor dot org 2009-12-20 02:26 --- Created an attachment (id=19353) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19353action=view) object files for lto -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42441
[Bug c/42440] optimization bug with btwowc(EOF) in wchar.h
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-20 03:41 ---
So we have:
extern wint_t __btowc_alias (int __c) __asm (btowc);
extern __inline wint_t
__attribute__ ((__nothrow__)) btowc (int __c)
{ return (__builtin_constant_p (__c) __c = '\0' __c = '\x7f'
? (wint_t) __c : __btowc_alias (__c)); }
if (btowc ((-1)) != (0xu))
I don't know if what people expect this to happen really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42440
[Bug lto/42441] lto segfaults
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-20 05:11 --- can you attach the preprocessed sources that were used to create the .o's? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42441
