[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code
--- Comment #15 from dodji at gcc dot gnu dot org 2009-12-14 08:24 --- (In reply to comment #13) > The .ii file I have attached? Yes, I was expecting it to be correct, it > compiles without error or warnings with GCC 4.4, even with all warnings > enabled, AFAIK. Fair enough. It was me doing weird things. I submitted a patch to http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00669.html Let's see how it turns out. Thanks for your feedback. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
[Bug libstdc++/42352] -std=c++0x reference binding problem
--- Comment #13 from paolo dot carlini at oracle dot com 2009-12-14 08:39 --- Yes, you understood correctly, that is our policy and nothing changes if you overstate the issue by using the "broken" catch-all. To repeat, our general policy is that any issue corresponding to an ISO DR is not dealt with until the DR has reached at least [Ready] status, because we cannot risk going back and forward between different resolutions and other tentative fixes. Normally the policy is applied even more strictly for C++0x issues, given the experimental nature. 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 reference: http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#1133 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug c++/42356] confused compiler
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-14 08:44 --- I do not have the time to get into the language details, but I think you should investigate the conformance of the code a bit more: recent SunStudio and Comeau also agree with ICC and GCC on this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
[Bug c++/42219] [4.5 Regression] ICE with "const void" as parameter type
--- Comment #5 from reichelt at gcc dot gnu dot org 2009-12-14 08:46 --- Fixed. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42219
[Bug c++/42356] confused compiler
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-14 09:27 --- Likewise VC++ v8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
[Bug rtl-optimization/41455] memcpy not tail called if it's a struct assignment
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41455
[Bug fortran/41599] [OOP] SELECT TYPE with associate-name => exp: Use (sometimes) a restricted pointer
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-14 10:34 --- See also PR 41600 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41599
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #28 from dominiq at lps dot ens dot fr 2009-12-14 10:51 --- (In reply to comment #27) > My current collection of patches and hacks for this problem. Obviously the > "if (0)" in tree-ssa-pre.c will break pr38819 again; apart from that untested, > hence probably miscompiles everything except this testcase here :-) I have not tested the patch (yet), but it seems that replacing "if(0)" with something such as "if(!flag_trapping_math)" could make everybody happy: if you don't want to break pr38819, don't use -fno-trapping-math; if you want speed, use it or use -ffast-math. Would it be acceptable? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug bootstrap/42365] -march=native -mfpmath=sse leads to bootstrap failure
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-14 11:03 --- Add -msse2. -- 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=42365
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #29 from dominiq at lps dot ens dot fr 2009-12-14 11:21 --- On x86_64-apple-darwin10, I don't see any speedup with the patch in comment #27 (not a clean bootstrap, but just an incremental build). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #30 from rguenth at gcc dot gnu dot org 2009-12-14 11:23 --- I fail to see why FRE does not remove the redundant load of *n_9(D). Oh, it is because we first value-number D.1537_58 = *n_9(D); and only after it we value-number D.1529_45 = *n_9(D); This is because while we visit the SCC members in RPO order we do not impose any order on visiting SCCs and those two stmts are not dependent on each other (we neither account for virtual operands nor control dependences there). Old problem. The fix for this is to either wait for the VN rewrite or to collect all SCCs, sort them in RPO order and only then process them. Note that it still can be difficult to impose a total ordering on SCCs (but at least this case should be easy). Another possibility is to artificially grow SCCs and their dependencies by honoring dominating virtual operand uses, not only defs (ugh). For non-memory the missing ordering is not a problem as we do not rely on walking stmts during expression lookup (and that walking only visits dominating expressions). Something to keep in mind for the VN re-implementation as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #31 from rguenth at gcc dot gnu dot org 2009-12-14 11:49 --- Created an attachment (id=19288) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19288&action=view) another hack Sorts the SCCs after collecting them all. Breaks most of the PRE/FRE testcases because it sorts all SCCs, not only those that have no direct dependencies. Not easy to fix though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #32 from rguenther at suse dot de 2009-12-14 12:27 --- Subject: Re: [4.4/4.5 Regression] 50% performance regression On Mon, 14 Dec 2009, matz at gcc dot gnu dot org wrote: > --- Comment #26 from matz at gcc dot gnu dot org 2009-12-14 04:55 --- > And if I fix this problem (so that only one reference to *n_9) remains > I hit the problem that the fortran frontend emits the computation of countm1 > after the loop bound test. No pass is moving code in front of that test as > this is potentially a regression (more evaluations in out-of-bound case). > > And if I fix _that_ I hit the problem of the fix for PR38819. PRE won't move > the division at all, because it could trap :-/ If I disable this I get back > the 4.3 performance. Well. VRP should mark divisions as non-trapping if possible. I see (after fixing the FRE issue): # iftmp.12_8 = PHI <-1(30), 1(12)> D.1588_67 = iftmp.12_8 * D.1529_119; D.1589_68 = (character(kind=4)) D.1588_67; countm1.6_69 = D.1583_64 / D.1589_68; with D.1529_119: [2, +INF] iftmp.12_8: [1, 1] D.1588_67: [2, +INF] D.1589_68: [2, 2147483647] countm1.6_69: [0, 2147483647] so as D.1589_68 is never -1 or zero the division doesn't trap. Now it's easy to mark the stmt in VRP this way but non-trivial to keep track of it in the SCCVN IL. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #33 from rguenth at gcc dot gnu dot org 2009-12-14 12:30 --- Created an attachment (id=19289) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19289&action=view) VRP hack Hack marking divisions non-trapping during VRP (re-using some stmt bit, not updating relevant places to make PRE recognize the non-trappingness). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code
--- Comment #16 from jacob dot benoit dot 1 at gmail dot com 2009-12-14 12:43 --- (In reply to comment #15) > Fair enough. It was me doing weird things. > > I submitted a patch to http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00669.html > Let's see how it turns out. > > Thanks for your feedback. > Thanks for your responsiveness! The whole Eigen team is very pleased about this. By the way, this bug report comes from trying to build the Eigen test suite (development branch). This is a great real-world use case for mixing very complate C++ template stuff with other specific topics such as SSE intrinsics, etc. If you want to test it yourself, install CMake and Mercurial, and do: $ hg clone https://bitbucket.org/eigen/eigen/ $ mkdir eigen-build $ cd eigen-build $ cmake ../eigen $ make check I mention this because I heared that GCC has a list of project it builds before releasing a version, as real-world test cases. Maybe Eigen's test suite can be added to that list? Maybe after we make the next release? (The current stable release, 2.0, didn't trigger this GCC error). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
[Bug tree-optimization/42337] GCC ICE in compute_antic, at tree-ssa-pre.c:2534
--- Comment #4 from mikpe at it dot uu dot se 2009-12-14 12:57 --- This bug is also present in gcc-4.4-20091208 but not in gcc-4.3-20091206. The two fixes listed here apply Ok to 4.4 and solve the problem there w/o regressions (tested on i686, powerpc64, and arm). -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42337
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #34 from rguenth at gcc dot gnu dot org 2009-12-14 12:57 --- "Another possibility is to artificially grow SCCs and their dependencies by honoring dominating virtual operand uses, not only defs (ugh)." what I mean with this is that when finding SCCs we process all uses of a stmt. In case you have a memory load # VUSE <.MEM_3> x_2 = *p_1(D); then you have to consider all dominating DEFs that use .MEM_3 uses of that stmt, not only the single def of .MEM_3 (well, you only have to consider aliasing uses of course). This isn't easyly retrofitted into the non-recursive DFS walk though. Thus, for # .MEM_3 = VDEF <.MEM_5(D)> *p_1(D) = 0; # VUSE <.MEM_3> y_4 = *p_1(D); # VUSE <.MEM_3> x_2 = *p_1(D); when visiting x_2 = *p_1(D); the uses are p_1, y_4 and .MEM_3. y_4 is new because its the DEF in the dominating stmt that uses .MEM_3. This would possibly increase SCC sizes and compile-time a lot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42337] [4.4 Regression] GCC ICE in compute_antic, at tree-ssa-pre.c:2534
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-14 12:59 --- Re-open to mark as regression for 4.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Known to fail||4.4.3 Known to work||4.3.4 4.5.0 Resolution|FIXED | Summary|GCC ICE in compute_antic, |[4.4 Regression] GCC ICE in |at tree-ssa-pre.c:2534 |compute_antic, at tree-ssa- ||pre.c:2534 Target Milestone|4.5.0 |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42337
[Bug tree-optimization/42337] [4.4 Regression] GCC ICE in compute_antic, at tree-ssa-pre.c:2534
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-14 12:59 --- I'll take care of a backport after some more testing on the trunk. -- 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-14 12:59:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42337
[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-12-14 13:03 --- (In reply to comment #16) > I mention this because I heared that GCC has a list of project it builds > before > releasing a version, as real-world test cases. Maybe Eigen's test suite can be > added to that list? Maybe after we make the next release? (The current stable > release, 2.0, didn't trigger this GCC error). Nah, we don't do this anymore (well, testing a specific list of projects). Instead we rely on the community providing feedback during development. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
[Bug tree-optimization/42366] New: ICE in ipa_write_node_info, at ipa-prop.c:2023
static int
f0 (char *s0, char *s1)
{
return __builtin_strlen (s0) > __builtin_strlen (s1);
}
int
f1 (char *s, int j)
{
if (f0 (s, ""))
return 1;
return j;
}
void
f2 (char *s)
{
f1 (s, 0);
}
fails with -O1 -fipa-cp -flto:
> ./cc1 -quiet -O1 -fipa-cp -flto t.i
t.i:23:1: internal compiler error: in ipa_write_node_info, at ipa-prop.c:2023
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
Summary: ICE in ipa_write_node_info, at ipa-prop.c:2023
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, lto
Severity: normal
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=42366
[Bug tree-optimization/42366] ICE in ipa_write_node_info, at ipa-prop.c:2023
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-14 13:15 --- This is btw the topmost ICE that appears when you run all of the testsuite with -flto. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42366
[Bug c/42367] New: long vector operation causes gcc to copy arguments
Why GCC copies vectorized buffers to and from stack ?
Am I doing something wrong ?
===
Compiler:
===
gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
===
Source a.c:
===
typedef int BLOCK512 __attribute__((__vector_size__(512)));
void f (BLOCK512 *d, const BLOCK512 *s0, const BLOCK512 *s1) {
*d = *s0 ^ *s1;
}
===
Command:
===
gcc -O3 a.c -c -o a.o
===
Result (note 3 calls to memcpy):
===
Disassembly of section .text:
:
0: 41 54 push %r12
2: 49 89 fcmov%rdi,%r12
5: 53 push %rbx
6: 48 89 d3mov%rdx,%rbx
9: ba 00 02 00 00 mov$0x200,%edx
e: 48 81 ec 08 06 00 00sub$0x608,%rsp
15: 48 8d bc 24 00 02 00lea0x200(%rsp),%rdi
1c: 00
1d: e8 00 00 00 00 callq 22
1e: R_X86_64_PC32 memcpy+0xfffc
22: 48 8d bc 24 00 04 00lea0x400(%rsp),%rdi
29: 00
2a: 48 89 demov%rbx,%rsi
2d: ba 00 02 00 00 mov$0x200,%edx
32: e8 00 00 00 00 callq 37
33: R_X86_64_PC32 memcpy+0xfffc
37: 66 0f 6f 84 24 00 04movdqa 0x400(%rsp),%xmm0
3e: 00 00
40: 48 89 e6mov%rsp,%rsi
43: 4c 89 e7mov%r12,%rdi
46: ba 00 02 00 00 mov$0x200,%edx
4b: 66 0f ef 84 24 00 02pxor 0x200(%rsp),%xmm0
52: 00 00
54: 66 0f 7f 04 24 movdqa %xmm0,(%rsp)
59: 66 0f 6f 84 24 10 04movdqa 0x410(%rsp),%xmm0
60: 00 00
62: 66 0f ef 84 24 10 02pxor 0x210(%rsp),%xmm0
69: 00 00
6b: 66 0f 7f 44 24 10 movdqa %xmm0,0x10(%rsp)
71: 66 0f 6f 84 24 20 04movdqa 0x420(%rsp),%xmm0
78: 00 00
7a: 66 0f ef 84 24 20 02pxor 0x220(%rsp),%xmm0
81: 00 00
83: 66 0f 7f 44 24 20 movdqa %xmm0,0x20(%rsp)
89: 66 0f 6f 84 24 30 04movdqa 0x430(%rsp),%xmm0
90: 00 00
92: 66 0f ef 84 24 30 02pxor 0x230(%rsp),%xmm0
99: 00 00
9b: 66 0f 7f 44 24 30 movdqa %xmm0,0x30(%rsp)
a1: 66 0f 6f 84 24 40 04movdqa 0x440(%rsp),%xmm0
a8: 00 00
aa: 66 0f ef 84 24 40 02pxor 0x240(%rsp),%xmm0
b1: 00 00
b3: 66 0f 7f 44 24 40 movdqa %xmm0,0x40(%rsp)
b9: 66 0f 6f 84 24 50 04movdqa 0x450(%rsp),%xmm0
c0: 00 00
c2: 66 0f ef 84 24 50 02pxor 0x250(%rsp),%xmm0
c9: 00 00
cb: 66 0f 7f 44 24 50 movdqa %xmm0,0x50(%rsp)
d1: 66 0f 6f 84 24 60 04movdqa 0x460(%rsp),%xmm0
d8: 00 00
da: 66 0f ef 84 24 60 02pxor 0x260(%rsp),%xmm0
e1: 00 00
e3: 66 0f 7f 44 24 60 movdqa %xmm0,0x60(%rsp)
e9: 66 0f 6f 84 24 70 04movdqa 0x470(%rsp),%xmm0
f0: 00 00
f2: 66 0f ef 84 24 70 02pxor 0x270(%rsp),%xmm0
f9: 00 00
fb: 66 0f 7f 44 24 70 movdqa %xmm0,0x70(%rsp)
101: 66 0f 6f 84 24 80 04movdqa 0x480(%rsp),%xmm0
108: 00 00
10a: 66 0f ef 84 24 80 02pxor 0x280(%rsp),%xmm0
111: 00 00
113: 66 0f 7f 84 24 80 00movdqa %xmm0,0x80(%rsp)
11a: 00 00
11c: 66 0f 6f 84 24 90 04movdqa 0x490(%rsp),%xmm0
123: 00 00
125: 66 0f ef 84 24 90 02pxor 0x290(%rsp),%xmm0
12c: 00 00
12e: 66 0f 7f 84 24 90 00movdqa %xmm0,0x90(%rsp)
135: 00 00
137: 66 0f 6f 84 24 a0 04movdqa 0x4a0(%rsp),%xmm0
13e: 00 00
140: 66 0f ef 84 24 a0 02pxor 0x2a0(%rsp),%xmm0
147: 00 00
149: 66 0f 7f 84 24 a0 00movdqa %xmm0,0xa0(%rsp)
150: 00 00
152: 66 0f 6f 84 24 b0 04movdqa 0x4b0(%rsp),%xmm0
159: 00 00
15b: 66 0f ef 84 24 b0 02pxor 0x2b0(%rsp),%xmm0
162: 00 00
164: 66 0f 7f 84 24 b0 00movdqa %xmm0,0xb0(%rsp)
16b: 00 00
16d: 66 0f 6f 84 24 c0 04movdqa 0x4c0(%rsp),%xmm0
174: 00 00
176: 66 0f ef 84 24 c0 02pxor 0x2c0(%rsp),%xmm0
17d: 00 00
17f: 66 0f 7f 84 24 c0 00movdqa %xmm0,0xc0(%rsp)
186: 00 00
188: 66 0f 6f 84 24 d0 04movdqa 0x4d0(%rsp),%xmm0
18f: 00 00
191: 66 0f ef 84 24 d0 02pxor 0x2d0(%rsp),%xmm0
198: 00 00
19a: 66 0f 7f 84 24 d0 00movdqa %xmm0,0xd0(%rsp)
1a1: 00 00
1a3: 66 0f 6f 84 24 e0 04movdqa 0x4e0(%rsp),%xmm0
1aa: 00 00
1ac: 66 0f ef 84 24 e0 02pxor 0x2e0(%rsp),%xmm0
1b3: 00 00
1b5: 66 0f 7f 84 24 e0 00movdqa %xmm0,0xe0(%rsp)
1bc: 0
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -funroll*-loops
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-12-14 13:50 --- We don't fold anything here (because of the volatileness of z4). Thus this can't be a mpc issue but is probably libm issue. I don't know how PPC implements _Complex float and if the HW has excess precision and thus we get extra rounding/truncating when spilling values. -funroll-loops triggers -frename-registers which again would hint at Bernds change. Assuming that the testcase from comment #6 is what this is all about (i?86-linux is fine w/ and w/o -frename-registers and w/ and w/o volatile). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers -fomit-frame-pointers
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-12-14 14:01 --- If no calls remain in the assembly as dominiq suggests then the *call_value_nonlocal_darwin64 pattern must be bogus. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug c++/42356] confused compiler
--- Comment #5 from igodard at pacbell dot net 2009-12-14 14:58 --- There's no question that there was an error here. The report is on the diagnostic. I'm sorry if I hadn't made that clear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
[Bug c++/42260] [4.3/4.4/4.5 Regression] ICE looking up template conversion operator
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-14 16:02:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42260
[Bug ada/42368] New: ada/cio.c uses common names
The cio.c file provides some low level routines used by the Ada run-time. The names of these routines end up in the global namespace. Unfortunately, the names are very generic and can conflict with the application or other libraries. I would like to request that the names of the following routines in this file be changed to prefix them with gnat_ with the possible exception of the VxWorks specific mktemp() at the bottom of the file. Would a patch to do this be acceptable? -- Summary: ada/cio.c uses common names Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42368
[Bug c/42367] long vector operation causes gcc to copy arguments
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-14 16:25 --- Well, nobody tried to optimize non-HW sized vectors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42367
[Bug debug/27672] C frontend does not generate line information for multi-line conditions
--- Comment #3 from tromey at gcc dot gnu dot org 2009-12-14 16:26 --- This seems to work better with svn trunk: Breakpoint 2, func2 () at pr.c:5 5 return 0; (gdb) fini Run till exit from #0 func2 () at pr.c:5 0x080483c3 in main () at pr.c:13 13|| func2 () Value returned is $3 = 0 (gdb) s 14|| func3 ()) (gdb) s func3 () at pr.c:8 8 return 1; (gdb) fini Run till exit from #0 func3 () at pr.c:8 0x080483cc in main () at pr.c:14 14|| func3 ()) Value returned is $4 = 1 (gdb) s 15 return 0; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27672
[Bug tree-optimization/42185] [4.5 Regression] [graphite] expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820
--- Comment #2 from aldyh at gcc dot gnu dot org 2009-12-14 16:38 --- http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00716.html Patch fixes both testcases, but the second testcase has another unrelated SSA bug. -- aldyh at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42185
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2009-12-14 16:47 --- there are several problems: 1/ the target-supports tests fail if called with ObjC/ObjC++ specific flags (e.g. -fgnu-runtime). 2/ there is no specific target-supports test for OBJC2 (which is needed for 64bit Next Runtime support) 3/ The tests for the gnu-runtime library usage are failing in testsuite/lib/objc.exp and obj-c++.exp. [they only detect if -fgnu-runtime is placed in the dg-options, rather than also checking the multilib options]. to allow you guys to test and comment, I'll attach patches for all three problems here - although maybe they should be three separate PRs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug tree-optimization/42284] failing tree check in graphite-sese-to-poly.c for 164.gzip
--- Comment #3 from spop at gcc dot gnu dot org 2009-12-14 16:50 --- Subject: Bug 42284 Author: spop Date: Mon Dec 14 16:49:47 2009 New Revision: 155218 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155218 Log: Fix PR42284. 2009-12-12 Sebastian Pop PR middle-end/42284 * graphite-sese-to-poly.c (rewrite_close_phi_out_of_ssa): Call insert_out_of_ssa_copy_on_edge for anything else than SSA_NAMEs. (detect_commutative_reduction_arg): Simplified. (detect_commutative_reduction): Early return when the argument of the close phi is not of an SSA_NAME. * testsuite/gcc.dg/graphite/pr42284.c: New. Modified: trunk/gcc/ChangeLog.graphite trunk/gcc/graphite-sese-to-poly.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42284
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2009-12-14 16:50 --- Created an attachment (id=19290) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19290&action=view) add support for ObjC/ObjC++ and an effective target OBJ2 test when -fnext-runtime, -fgnu-runtime, nostdinc++ are used the testfile suffix needs to be .m/.mm as appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug tree-optimization/42284] failing tree check in graphite-sese-to-poly.c for 164.gzip
--- Comment #4 from spop at gcc dot gnu dot org 2009-12-14 16:51 --- Subject: Bug 42284 Author: spop Date: Mon Dec 14 16:51:43 2009 New Revision: 155219 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155219 Log: PR middle-end/42284 * testsuite/gcc.dg/graphite/pr42284.c: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr42284.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42284
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #6 from developer at sandoe-acoustics dot co dot uk 2009-12-14 16:54 --- Created an attachment (id=19291) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19291&action=view) changes to recognize correctly which ObjC runtime is in use this (a) tracks the -fgnu-runtime/-fnext-runtime flags to detect which is in force. The libobjc-gnu is added and also made available as a %s substitution. The gnu-includes are added when the gnu runtime is in use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug c/42367] long vector operation causes gcc to copy arguments
--- Comment #2 from Shvaiger_Felix at emc dot com 2009-12-14 16:55 --- vector_size designed as general solution. Section 5.42 (Using vector instructions through built-in functions) of gcc info says: "Specifying a combination that is not valid for the current architecture will cause GCC to synthesize the instructions using a narrower mode. For example, if you specify a variable of type `V4SI' and your architecture does not allow for this specific SIMD type, GCC will produce code that uses 4 `SIs'." It is documented feature, so it is expected to work properly. If not perfectly optimized then at least 'sane'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42367
[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."
--- Comment #96 from jakub at gcc dot gnu dot org 2009-12-14 16:55 --- Subject: Bug 41473 Author: jakub Date: Mon Dec 14 16:55:12 2009 New Revision: 155221 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155221 Log: PR debug/41473 * dwarf2out.c (add_var_loc_to_decl): Don't drop initial empty locations. (new_loc_list): Drop gensym arg. Move generation of ll_symbol... (gen_llsym): ... here. New function. (add_loc_descr_to_loc_list): Removed. (loc_descriptor): Infer mode from CONST_DOUBLEs and CONST_VECTORs. (single_element_loc_list): Removed. (dw_loc_list): Don't create entries without a location. Don't special-case the first node of the list, only single nodes. (single_element_loc_list_p): Simplify. (loc_list_from_tree): Don't use DECL_RTL if loc_list is nonempty. (add_location_or_const_value_attribute): Test var loc for NULL. (convert_cfa_to_fb_loc_list): Adjust calls to new new_loc_list, call gen_llsym if needed. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."
--- Comment #97 from jakub at gcc dot gnu dot org 2009-12-14 16:56 --- Subject: Bug 41473 Author: jakub Date: Mon Dec 14 16:55:52 2009 New Revision: 155222 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155222 Log: PR debug/41473 * dwarf2out.c (AT_loc_list_ptr): New. (resolve_addr): Remove unresolved attributes and loc_list entries. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2009-12-14 16:56 --- Created an attachment (id=19292) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19292&action=view) changes to recognize correctly which ObjC runtime is in use this (a) tracks the -fgnu-runtime/-fnext-runtime flags to detect which is in force. The libobjc-gnu is added and also made available as a %s spec substitution. The gnu-includes are added when the gnu runtime is in use. %s spec substitution is also catered for for the stdc++-v3 library -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #35 from matz at gcc dot gnu dot org 2009-12-14 16:58 --- Exactly my thinking (growing SCCs -> slow, sorting SCCs -> difficult). What I thought about the trapping problem is that in this situation we could ignore the trap test. We start with this situation: bb1: goto bb2 bb2: PHI ; with bbX being dominated by bb1 a = b / c ; with b and c loop invariant Now it's clear that inserting a computation b/c in bb1 does not ever introduce additional traps, as there's no intervening statement that could stop execution without us knowing (in PR38819 it's a call that does exit(0)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #8 from developer at sandoe-acoustics dot co dot uk 2009-12-14
16:59 ---
with the patches above;
testsuite/obj-c++.dg/const-str-9.mm should have:
/* { dg-do compile { target *-*-darwin* } } */
/* { dg-skip-if "" { *-*-darwin* } { "-fgnu-runtime" } { "" } } */
/* { dg-skip-if "" { *-*-darwin* && { lp64 && { ! objc2 } } } { "*" } { "" } }
*/
testsuite/obj-c++.dg/template-4.mm
/* { dg-do run } */
/* { dg-skip-if "" { *-*-darwin* && { lp64 && { ! objc2 } } } { "*" } {
"-fgnu-runtime" } } */
In fact, arguably all the ObjC/ObjC++ tests should have something along these
lines - it should reduce clutter until OBJC2 support is available in FSF gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug tree-optimization/42284] failing tree check in graphite-sese-to-poly.c for 164.gzip
--- Comment #5 from spop at gcc dot gnu dot org 2009-12-14 17:11 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42284
[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."
--- Comment #98 from developer at sandoe-acoustics dot co dot uk 2009-12-14 18:31 --- i686-apple-darwin9 bootstraps without dsymutil fails at 155225, thanks Jakub. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug bootstrap/42369] New: [4.5 Regression] Failed to bootstrap
On Linux/ia32, revision 155225 gave: ../../src-trunk/gcc/config/i386/i386.c:23844: error: duplicate case value ../../src-trunk/gcc/config/i386/i386.c:23842: error: previously used here -- Summary: [4.5 Regression] Failed to bootstrap Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap 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=42369
[Bug bootstrap/42369] [4.5 Regression] Revision 155217 failed to bootstrap
--- Comment #1 from hjl dot tools at gmail dot com 2009-12-14 19:01 --- It is caused by revision 155217: http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00361.html The problem is ;; Single word integer modes without QImode and HImode. (define_mode_iterator SWI48 [SI (DI "TARGET_64BIT")]) with case CODE_FOR_lwp_lwpvalsi3: case CODE_FOR_lwp_lwpvaldi3: case CODE_FOR_lwp_lwpinssi3: case CODE_FOR_lwp_lwpinsdi3: Both CODE_FOR_lwp_lwpvaldi3 and CODE_FOR_lwp_lwpinsdi3 are CODE_FOR_nothing for ia32. I don't think you can use (DI "TARGET_64BIT") in define_mode_iterator. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.5 Regression] Failed to |[4.5 Regression] Revision |bootstrap |155217 failed to bootstrap Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42369
[Bug middle-end/42181] [4.5 Regression] -fgraphite-identity miscompiles or ICEs on air.f90
--- Comment #4 from spop at gcc dot gnu dot org 2009-12-14 19:02 --- Subject: Bug 42181 Author: spop Date: Mon Dec 14 19:02:37 2009 New Revision: 155233 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155233 Log: Fix PR42181. 2009-12-14 Sebastian Pop PR middle-end/42181 * graphite-scop-detection.c (graphite_can_represent_scev): Handle more carefully PLUS_EXPR, MINUS_EXPR, and MULT_EXPR. * testsuite/gfortran.dg/graphite/pr42181.f90: New. Added: branches/graphite/gcc/testsuite/gfortran.dg/graphite/pr42181.f90 Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite-scop-detection.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug middle-end/42181] [4.5 Regression] -fgraphite-identity miscompiles or ICEs on air.f90
--- Comment #5 from spop at gcc dot gnu dot org 2009-12-14 19:03 --- Fixed in the Graphite branch. I will commit it to trunk after test. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug fortran/42354] Invalidly accepts C_LOC in init expressions
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-14 19:11 --- Subject: Bug 42354 Author: dfranke Date: Mon Dec 14 19:10:56 2009 New Revision: 155234 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155234 Log: gcc/fortran/: 2009-12-14 Daniel Franke PR fortran/42354 * expr.c (check_init_expr): Do not check for specification functions. gcc/testsuite/: 2009-12-14 Daniel Franke PR fortran/42354 * gfortran.dg/iso_c_binding_init_expr.f03: New. * gfortran.dg/intrinsic_std_1.f90: Fixed expected error message. * gfortran.dg/function_kinds_5.f90: Likewise. * gfortran.dg/selected_char_kind_3.f90: Likewise. Added: trunk/gcc/testsuite/gfortran.dg/iso_c_binding_init_expr.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/function_kinds_5.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_std_1.f90 trunk/gcc/testsuite/gfortran.dg/selected_char_kind_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42354
[Bug bootstrap/42369] [4.5 Regression] Revision 155217 failed to bootstrap
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-14 19:13 --- Created an attachment (id=19293) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19293&action=view) A patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42369
[Bug tree-optimization/42334] segfault in graphite-poly.h for 200.sixtrack
--- Comment #1 from spop at gcc dot gnu dot org 2009-12-14 19:17 --- Mine. -- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-14 19:17:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42334
[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE
--- Comment #2 from spop at gcc dot gnu dot org 2009-12-14 19:20 --- Mine. -- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-14 19:20:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42178
[Bug fortran/42354] Invalidly accepts C_LOC in init expressions
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-12-14 19:22 --- Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42354
[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity
-- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|spop at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
[Bug tree-optimization/42326] segfault in tree-data-ref.c with Graphite building 200.sixtrack
--- Comment #2 from spop at gcc dot gnu dot org 2009-12-14 19:24 --- Mine. -- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-14 19:24:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42326
[Bug tree-optimization/42326] segfault in tree-data-ref.c with Graphite building 200.sixtrack
--- Comment #3 from spop at gcc dot gnu dot org 2009-12-14 19:41 --- I cannot reproduce this bug (both testcases) on amd64-linux on trunk revision 155219. Could you please try again to see if this has been resolved? Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42326
[Bug bootstrap/42369] [4.5 Regression] Revision 155217 failed to bootstrap
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-14 19:59 --- Subject: Bug 42369 Author: jakub Date: Mon Dec 14 19:59:00 2009 New Revision: 155237 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155237 Log: PR bootstrap/42369 * config/i386/i386.c (ix86_expand_special_args_builtin): Avoid using switch with CODE_FOR_lwp_lwp* cases. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42369
[Bug c++/42370] New: in a void function: "Warning: control reaches end of non-void function"
Test with a SVN build: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/rodrigo/local/gcc/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/home/rodrigo/local/gcc --with-gmp=/home/rodrigo/local/gcc --with-mpfr=/home/rodrigo/local/gcc --with-mpc=/home/rodrigo/local/gcc --enable-lto --enable-languages=c,c++,lto Thread model: posix gcc version 4.5.0 20091212 (experimental) (GCC) The attached code emits a non-sensical warning (both functions return void!). If the lambda is deleted it works as expected. $ g++ -c -std=gnu++0x -o test.o -Wall -save-temps test.cpp test.cpp: In function 'int end()': test.cpp:8:1: warning: no return statement in function returning non-void test.cpp: In function 'int start()': test.cpp:3:1: warning: control reaches end of non-void function -- Summary: in a void function: "Warning: control reaches end of non-void function" Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rodrigorivascosta at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42370
[Bug c++/42370] in a void function: "Warning: control reaches end of non-void function"
--- Comment #1 from rodrigorivascosta at gmail dot com 2009-12-14 20:19 --- Created an attachment (id=19294) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19294&action=view) Simplest test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42370
[Bug c++/42370] in a void function: "Warning: control reaches end of non-void function"
--- Comment #2 from rodrigorivascosta at gmail dot com 2009-12-14 20:21 --- Created an attachment (id=19295) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19295&action=view) Simplest test case Sorry, wrong MIME in the atch 19294 -- rodrigorivascosta at gmail dot com changed: What|Removed |Added Attachment #19294|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42370
[Bug middle-end/42371] New: dead code not eliminated during folding with whole-program
The follwing program:
#include
typedef unsigned char(*Calculable)(void);
unsigned char one() { return 1; }
unsigned char two() { return 2; }
static void print(Calculable calculate)
{
printf("%d\n", calculate());
printf("+1: %d\n", calculate() + 1);
}
int main()
{
print(one);
print(two);
return 0;
}
when compiled with GCC 4.5.0 20091211 with -O3 -fwhole-program, outputs the
following relevant chunk of assembly:
004002e0 <_Z3onev>:
4002e0: b8 01 00 00 00 moveax,0x1
4002e5: c3 ret
4002e6: 66 2e 0f 1f 84 00 00nopWORD PTR cs:[rax+rax*1+0x0]
4002ed: 00 00 00
004002f0 <_Z3twov>:
4002f0: b8 02 00 00 00 moveax,0x2
4002f5: c3 ret
4002f6: 66 2e 0f 1f 84 00 00nopWORD PTR cs:[rax+rax*1+0x0]
4002fd: 00 00 00
00400300 :
400300: 48 83 ec 08 subrsp,0x8
400304: be 01 00 00 00 movesi,0x1
400309: bf 34 04 40 00 movedi,0x400434
40030e: 31 c0 xoreax,eax
400310: e8 73 02 00 00 call 400588
400315: be 02 00 00 00 movesi,0x2
40031a: bf 2c 04 40 00 movedi,0x40042c
40031f: 31 c0 xoreax,eax
400321: e8 62 02 00 00 call 400588
400326: be 02 00 00 00 movesi,0x2
40032b: bf 34 04 40 00 movedi,0x400434
400330: 31 c0 xoreax,eax
400332: e8 51 02 00 00 call 400588
400337: be 03 00 00 00 movesi,0x3
40033c: bf 2c 04 40 00 movedi,0x40042c
400341: 31 c0 xoreax,eax
400343: e8 40 02 00 00 call 400588
400348: 31 c0 xoreax,eax
40034a: 48 83 c4 08 addrsp,0x8
40034e: c3 ret
40034f: 90 nop
GCC correctly folds the functions one() and two(), and does all the
compile-time math (yay!). however, the one() and two() functions are still
emitted to the binary even though they are now dead. There is a concern that
this negatively affects code locality on cache-limited platforms where a
profile-guided optimization is non-trivial. We are currently seeing some cache
misses and this example embodies one of the roadblocks to eliminating them
while keeping the code well-encapsulated.
--
Summary: dead code not eliminated during folding with whole-
program
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt at use dot net
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=42371
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #14 from dominiq at lps dot ens dot fr 2009-12-14 20:42 --- When compiled with '-m64 -O1 -frename-registers' the code in comment #6 fails, but passes with ''-m64 -O1'. > If no calls remain in the assembly as dominiq suggests then the > *call_value_nonlocal_darwin64 pattern must be bogus. I do not see "call", but in both cases ... bl L_casinf$stub ... which I understand as an other form of call. So the darwin math lib seems to work correctly when -frename-registers is not used. I'll attach the assembly generated with/without the option. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|WAITING |UNCONFIRMED Summary|[4.5 Regression] FAIL: |[4.5 Regression] FAIL: |gfortran.dg/complex_intrinsi|gfortran.dg/complex_intrinsi |c_5.f90 -m64 -O -frename- |c_5.f90 -m64 -O -frename- |registers -fomit-frame- |registers |pointers| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
--- Comment #33 from dominiq at lps dot ens dot fr 2009-12-14 20:43 --- Created an attachment (id=19296) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19296&action=view) assembly generated with -frename-registers -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
--- Comment #34 from dominiq at lps dot ens dot fr 2009-12-14 20:45 --- Created an attachment (id=19297) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19297&action=view) assembly generated without -frename-registers -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #15 from dominiq at lps dot ens dot fr 2009-12-14 20:48 --- Created an attachment (id=19298) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19298&action=view) assembly generated with -frename-registers -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
--- Comment #35 from dominiq at lps dot ens dot fr 2009-12-14 20:51 --- Wrong pr. Sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #16 from dominiq at lps dot ens dot fr 2009-12-14 20:54 --- Created an attachment (id=19299) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19299&action=view) assembly generated without -frename-registers -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug c++/42364] C++ testsuite fails with -g
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-14 20:58:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42364
[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
--- Comment #6 from dominiq at lps dot ens dot fr 2009-12-14 21:10 --- The test passes with '-O3 -fno-tree-vectorize' or '-O2 -ftree-vectorize', so its seems that it is a vectorizer problem. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug c++/42364] C++ testsuite fails with -g
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-14 21:28 --- Is c++/42336 related? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42364
[Bug c++/33979] support for char16_t, char32_t
--- Comment #18 from sacolcor at provide dot net 2009-12-14 21:36 --- Should the library support for this be split into a separate bug? Or two bugs, if libstdc++ and glibc both need to handle the new types? -- sacolcor at provide dot net changed: What|Removed |Added CC||sacolcor at provide dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33979
[Bug tree-optimization/42326] segfault in tree-data-ref.c with Graphite building 200.sixtrack
--- Comment #4 from dominiq at lps dot ens dot fr 2009-12-14 21:38 --- I see it for both reduced tests on powerpc-apple-darwin9, revision 155196, in 32 bit mode, but not in the 64 bit one. The compilation goes fine on x86_64-apple-darwin10, revision 155224. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42326
[Bug middle-end/42372] New: Error: undefined symbol `.LPIC7' in operation
attached testcase fails on trunk for arm target with the following optset -c -fgnu89-inline -Os -frename-registers it works ok with -O2 or -O3 /tmp/cc9PcQw8.s: Assembler messages: /tmp/cc9PcQw8.s:438: Error: undefined symbol `.LPIC7' in operation -- Summary: Error: undefined symbol `.LPIC7' in operation Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: arm-oe-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42372
[Bug middle-end/42372] Error: undefined symbol `.LPIC7' in operation
--- Comment #1 from raj dot khem at gmail dot com 2009-12-14 22:51 --- Created an attachment (id=19300) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19300&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42372
[Bug target/26702] .size is not emitted for BSS variables
--- Comment #10 from rearnsha at gcc dot gnu dot org 2009-12-14 23:14 --- While getting the size right is useful, it's not something that can be relied on by users, so this is really an enhancement. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702
[Bug rtl-optimization/29294] 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294
[Bug bootstrap/42369] [4.5 Regression] Revision 155217 failed to bootstrap
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-14 23:25 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42369
[Bug libstdc++/25304] [DR 865] std::fill_n, std::generate_n incorrect signature
--- Comment #20 from paolo dot carlini at oracle dot com 2009-12-14 23:26 --- This is in fact DR 865 and now that the status is [Ready] we can simply re-open it, say in the docs that we implement it already and then close it again. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|SUSPENDED |NEW Last reconfirmed|2005-12-07 23:39:53 |2009-12-14 23:26:16 date|| Summary|std::fill_n, std::generate_n|[DR 865] std::fill_n, |incorrect signature |std::generate_n incorrect ||signature http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug target/38203] attribute `noreturn' isn't effective when -mthumb param is active
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-12-14 23:35 --- There's a lot of debate about whether the ARM behaviour is a good thing or not. Not pushing the return address means that the debugger cannot generate a back-trace in the event that the no-return function is something like abort(); however, we could avoid pushing most of the other registers. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38203
[Bug middle-end/42372] Error: undefined symbol `.LPIC7' in operation
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-14 23:37 --- Confirmed - the work around appears to also be to remove -frename-registers. Reducing testcase. -- ramana 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-14 23:37:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42372
[Bug bootstrap/42093] bootstrap hangs in stage2 run of build/gengtype
--- Comment #3 from ramana at gcc dot gnu dot org 2009-12-14 23:43 ---
I now see a bootstrap failure with build/genmddeps going into an infinite loop
for stage2. This has to be a problem with the the system compiler.
This utility jumps into never never land from read_rtx in read-rtl.c - It's
something that's compiled by the system gcc-4.4 compiler . I've used the lucid
system compiler 4.4.2-ubuntu-5 as the system compiler and for read_rtx I see
the following code being generated - A number of statements including return 1
for the function are removed.
I will have to see if a 4.4 based FSF compiler used as the system code
generates similar code for the function.
b038 :
b038: e92d 4ff0 stmdb sp!, {r4, r5, r6, r7, r8, r9, sl, fp,
lr}
b03c: f8df 926c ldr.w r9, [pc, #620] ; b2ac
b040: b08dsub sp, #52 ; 0x34
b042: f8d9 50c4 ldr.w r5, [r9, #196] ; 0xc4
b046: 9005str r0, [sp, #20]
b048: 9103str r1, [sp, #12]
b04a: 9204str r2, [sp, #16]
b04c: b19dcbz r5, b076
b04e: f8d9 40c8 ldr.w r4, [r9, #200] ; 0xc8
b052: 4d96ldr r5, [pc, #600] ; (b2ac
)
b054: 2c00cmp r4, #0
b056: f000 80eb beq.w b230
b05a: 68a2ldr r2, [r4, #8]
b05c: 2001movsr0, #1
b05e: 9903ldr r1, [sp, #12]
b060: f8d9 30cc ldr.w r3, [r9, #204] ; 0xcc
b064: 600astr r2, [r1, #0]
b066: 9a04ldr r2, [sp, #16]
b068: 6013str r3, [r2, #0]
b06a: 68e3ldr r3, [r4, #12]
b06c: f8c9 30c8 str.w r3, [r9, #200] ; 0xc8
b070: b00dadd sp, #52 ; 0x34
b072: e8bd 8ff0 ldmia.w sp!, {r4, r5, r6, r7, r8, r9, sl, fp,
pc}
b076: 462bmov r3, r5
b078: 498dldr r1, [pc, #564] ; (b2b0
)
b07a: 4a8eldr r2, [pc, #568] ; (b2b4
)
b07c: 200dmovsr0, #13
b07e: f002 fcfb bl da78
b082: 462bmov r3, r5
b084: 498aldr r1, [pc, #552] ; (b2b0
)
b086: 4a8bldr r2, [pc, #556] ; (b2b4
)
b088: f8df a22c ldr.w sl, [pc, #556] ; b2b8
b08c: 4c8bldr r4, [pc, #556] ; (b2bc
)
b08e: 4684mov ip, r0
b090: 200dmovsr0, #13
b092: f8c9 c060 str.w ip, [r9, #96] ; 0x60
b096: f002 fcef bl da78
b09a: 462bmov r3, r5
b09c: 4984ldr r1, [pc, #528] ; (b2b0
)
b09e: 4a85ldr r2, [pc, #532] ; (b2b4
)
b0a0: 4684mov ip, r0
b0a2: f8c9 c064 str.w ip, [r9, #100] ; 0x64
b0a6: f04f 0c52 mov.w ip, #82 ; 0x52
b0aa: f8c9 c068 str.w ip, [r9, #104] ; 0x68
b0ae: f8df c210 ldr.w ip, [pc, #528] ; b2c0
b0b2: 200dmovsr0, #13
b0b4: f8c9 c06c str.w ip, [r9, #108] ; 0x6c
b0b8: f8df c208 ldr.w ip, [pc, #520] ; b2c4
b0bc: f8c9 c070 str.w ip, [r9, #112] ; 0x70
b0c0: f8df c204 ldr.w ip, [pc, #516] ; b2c8
b0c4: f8c9 c074 str.w ip, [r9, #116] ; 0x74
b0c8: f002 fcd6 bl da78
b0cc: 462bmov r3, r5
b0ce: 4978ldr r1, [pc, #480] ; (b2b0
)
b0d0: 4a78ldr r2, [pc, #480] ; (b2b4
)
b0d2: 4684mov ip, r0
b0d4: 200dmovsr0, #13
b0d6: f8c9 c0ac str.w ip, [r9, #172] ; 0xac
b0da: f002 fccd bl da78
b0de: 462bmov r3, r5
b0e0: f8d9 1060 ldr.w r1, [r9, #96] ; 0x60
b0e4: 4a79ldr r2, [pc, #484] ; (b2cc
)
b0e6: 4684mov ip, r0
b0e8: f8c9 c0b0 str.w ip, [r9, #176] ; 0xb0
b0ec: f04f 0cb8 mov.w ip, #184; 0xb8
b0f0: f8c9 c0b4 str.w ip, [r9, #180] ; 0xb4
b0f4: f8df c1d8 ldr.w ip, [pc, #472] ; b2d0
b0f8: f109 0060 add.w r0, r9, #96 ; 0x60
b0fc: f8c9 c0b8 str.w ip, [r9, #184] ; 0xb8
b100: f8df c1d0 ldr.w ip, [pc, #464] ; b2d4
b104: f8c9 c0bc str.w ip, [r9, #188] ; 0xbc
b108: f8df c1cc ldr.w ip, [pc, #460] ; b2d8
b10c: f8c9 c0c0 str.w ip, [r9, #192] ; 0xc0
b110: f7fe fcd0 bl 9ab4
b114: f8d9 1
[Bug libstdc++/25304] [DR 865] std::fill_n, std::generate_n incorrect signature
--- Comment #21 from paolo at gcc dot gnu dot org 2009-12-15 00:08 --- Subject: Bug 25304 Author: paolo Date: Tue Dec 15 00:07:52 2009 New Revision: 155241 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155241 Log: 2009-12-14 Paolo Carlini PR libstdc++/25304, DR 865 [Ready] * include/bits/stl_algobase.h (fill_n): Add comment about DR 865. * include/bits/stl_algo.h (generate_n): Likewise. * include/bits/algorithmfwd.h: Remove obsolete comment. * doc/xml/manual/intro.xml: Add an entry for DR 865. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/xml/manual/intro.xml trunk/libstdc++-v3/include/bits/algorithmfwd.h trunk/libstdc++-v3/include/bits/stl_algo.h trunk/libstdc++-v3/include/bits/stl_algobase.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug libstdc++/25304] [DR 865] std::fill_n, std::generate_n incorrect signature
--- Comment #22 from paolo dot carlini at oracle dot com 2009-12-15 00:10 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug c++/42336] [c++0x] ICE with pointer-to-member-function decltype argument in template function
--- Comment #3 from jason at gcc dot gnu dot org 2009-12-15 01:47 --- I suspect this is the same bug as 42225. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||dodji at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336
[Bug testsuite/40459] g++.dg/abi/mangle*.C fail on darwin
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-15 01:56 --- Any ideas on why we are failing this on x86_64-apple-darwin10? There we are seeing... Executing on host: /sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/gcc/testsuite/g++/../../g++ -B/sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle11.C -nostdinc++ -I/sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/include/x86_64-apple-darwin10.2.0 -I/sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/include -I/sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/libstdc++-v3/testsuite/util -fmessage-length=0 -Wabi -fabi-version=1 -S -o mangle11.s(timeout = 300) /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle11.C: In instantiation of 'void f(typename Q::X) [with Q = S, typename Q::X = int]': /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle11.C:10:24: instantiated from here /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle11.C:4:25: warning: the mangled name of 'void f(typename Q::X) [with Q = S, typename Q::X = int]' will change in a future version of GCC output is: /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle11.C: In instantiation of 'void f(typename Q::X) [with Q = S, typename Q::X = int]': /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle11.C:10:24: instantiated from here /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle11.C:4:25: warning: the mangled name of 'void f(typename Q::X) [with Q = S, typename Q::X = int]' will change in a future version of GCC FAIL: g++.dg/abi/mangle11.C (test for warnings, line 10) FAIL: g++.dg/abi/mangle11.C (test for excess errors) Excess errors: /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle11.C:4:25: warning: the mangled name of 'void f(typename Q::X) [with Q = S, typename Q::X = int]' will change in a future version of GCC Executing on host: /sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/gcc/testsuite/g++/../../g++ -B/sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle12.C -nostdinc++ -I/sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/include/x86_64-apple-darwin10.2.0 -I/sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/include -I/sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/libstdc++-v3/testsuite/util -fmessage-length=0 -Wabi -fabi-version=1 -S -o mangle12.s(timeout = 300) /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle12.C: In instantiation of 'void f(typename Q::X) [with Q = S, typename Q::X = int]': /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle12.C:11:24: instantiated from here /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle12.C:4:30: warning: the mangled name of 'void f(typename Q::X) [with Q = S, typename Q::X = int]' will change in a future version of GCC output is: /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle12.C: In instantiation of 'void f(typename Q::X) [with Q = S, typename Q::X = int]': /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle12.C:11:24: instantiated from here /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle12.C:4:30: warning: the mangled name of 'void f(typename Q::X) [with Q = S, typename Q::X = int]' will change in a future version of GCC FAIL: g++.dg/abi/mangle12.C (test for warnings, line 11) FAIL: g++.dg/abi/mangle12.C (test for excess errors) Excess errors: /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/abi/mangle12.C:4:30: warning: the mangled name of 'void f(typename Q::X) [with Q = S, typename Q::X = int]' will change in a future version of GCC Executing on host: /sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/gcc/testsuite/g++/../../g++ -B/sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc45-4.4.999-20
[Bug c++/42373] New: g++.dg/cpp0x/lambda/lambda-mangle.C scan-assembler weak[ \t]*_?_ZN1RIiE1xMUlvE_clEv fails on x86_64-apple-darwin
On both x86_64-apple-darwin9 and x86_64-apple-darwin10, we are failing the testcase g++.dg/cpp0x/lambda/lambda-mangle.C in the section... FAIL: g++.dg/cpp0x/lambda/lambda-mangle.C scan-assembler weak[ \t]*_?_ZN1RIiE1xMUlvE_clEv Using built-in specs. COLLECT_GCC=/sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/gcc/testsuite/g++/../../g++ Target: x86_64-apple-darwin10.2.0 Configured with: ../gcc-4.5-20091211/configure --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib Thread model: posix gcc version 4.5.0 20091212 (experimental) (GCC) -- Summary: g++.dg/cpp0x/lambda/lambda-mangle.C scan-assembler weak[ \t]*_?_ZN1RIiE1xMUlvE_clEv fails on x86_64-apple-darwin Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin* GCC host triplet: x86_64-apple-darwin* GCC target triplet: x86_64-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42373
[Bug c++/42373] g++.dg/cpp0x/lambda/lambda-mangle.C scan-assembler weak[ \t]*_?_ZN1RIiE1xMUlvE_clEv fails on x86_64-apple-darwin
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-12-15 02:06 --- Created an attachment (id=19301) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19301&action=view) assembly from g++.dg/cpp0x/lambda/lambda-mangle.C Created with... /sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/gcc/testsuite/g++/../../g++ -B/sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle.C -nostdinc++ -I/sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/include/x86_64-apple-darwin10.2.0 -I/sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/include -I/sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc45-4.4.999-20091211/gcc-4.5-20091211/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++0x -fno-inline -S -o lambda-mangle.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42373
[Bug c++/42364] C++ testsuite fails with -g
--- Comment #2 from jason at gcc dot gnu dot org 2009-12-15 02:12 --- Subject: Bug 42364 Author: jason Date: Tue Dec 15 02:11:54 2009 New Revision: 155246 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155246 Log: PR c++/42364 * pt.c (function_parameter_expanded_from_pack_p): Don't require a pack to have a name. (tsubst_decl): Do typedef magic after applying attributes. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/variadic31.C trunk/gcc/testsuite/g++.dg/ext/attrib33.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42364
[Bug fortran/41872] wrong-code: Issues with allocatable scalars
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-12-15 03:02 --- I have started looking at this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41872
[Bug c++/42364] C++ testsuite fails with -g
--- Comment #3 from jason at gcc dot gnu dot org 2009-12-15 03:25 --- How do you make the whole testsuite run with certain flags, anyway? Nothing I'm trying works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42364
[Bug c++/42373] g++.dg/cpp0x/lambda/lambda-mangle.C scan-assembler weak[ \t]*_?_ZN1RIiE1xMUlvE_clEv fails on x86_64-apple-darwin
--- Comment #2 from jason at gcc dot gnu dot org 2009-12-15 03:59 --- Created an attachment (id=19302) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19302&action=view) patch Does this fix it? -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42373
[Bug c++/41449] Partial aggregate initialization not cleaned up on exception
--- Comment #1 from jason at gcc dot gnu dot org 2009-12-15 04:02 --- Perhaps this is related to bug 11633. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41449
[Bug libstdc++/42374] New: 23_containers/map/operators/1_neg.cc fails test for errors on darwin10
The new 23_containers/map/operators/1_neg.cc test case fails... FAIL: 23_containers/map/operators/1_neg.cc (test for errors, line 212) FAIL: 23_containers/map/operators/1_neg.cc (test for errors, line 216) FAIL: 23_containers/map/operators/1_neg.cc (test for excess errors) FAIL: 23_containers/set/operators/1_neg.cc (test for errors, line 287) FAIL: 23_containers/set/operators/1_neg.cc (test for errors, line 291) FAIL: 23_containers/set/operators/1_neg.cc (test for excess errors) on x86_64-apple-darwin10. These appear as... Executing on host: /sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/./gcc/g++ -shared-libgcc -B/sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/src -L/sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/src/.libs -B/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/lib/ -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/include -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/sys-include -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -g -O2 -DLOCALEDIR="." -nostdinc++ -I/sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/include/x86_64-apple-darwin10.2.0 -I/sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/include -I/sw/src/fink.build/gcc45-4.4.999-20091214/gcc-4.5-20091214/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc45-4.4.999-20091214/gcc-4.5-20091214/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc45-4.4.999-20091214/gcc-4.5-20091214/libstdc++-v3/testsuite/util -include bits/stdc++.h -c -o config80787.o config80787.cc(timeout = 600) Executing on host: /sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/./gcc/g++ -shared-libgcc -B/sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/x86_64-apple-darwin10.2.0/libstd...skipping... Executing on host: /sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/./gcc/g++ -shared-libgcc -B/sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/src -L/sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/src/.libs -B/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/lib/ -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/include -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/sys-include -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -g -O2 -DLOCALEDIR="." -nostdinc++ -I/sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/include/x86_64-apple-darwin10.2.0 -I/sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/include -I/sw/src/fink.build/gcc45-4.4.999-20091214/gcc-4.5-20091214/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc45-4.4.999-20091214/gcc-4.5-20091214/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc45-4.4.999-20091214/gcc-4.5-20091214/libstdc++-v3/testsuite/util /sw/src/fink.build/gcc45-4.4.999-20091214/gcc-4.5-20091214/libstdc++-v3/testsuite/23_containers/map/operators/1_neg.cc -include bits/stdc++.h -S -o 1_neg.s(timeout = 600) /sw/src/fink.build/gcc45-4.4.999-20091214/gcc-4.5-20091214/libstdc++-v3/testsuite/23_containers/map/operators/1_neg.cc: In function 'void test01()': /sw/src/fink.build/gcc45-4.4.999-20091214/gcc-4.5-20091214/libstdc++-v3/testsuite/23_containers/map/operators/1_neg.cc:40:32: error: no match for 'operator!=' in 'itr != mapByName.std::map<_Key, _Tp, _Compare, _Alloc>::end [with _Key = std::basic_string, _Tp = unsigned int, _Compare = std::less >, _Alloc = std::allocator, unsigned int> >, std::map<_Key, _Tp, _Compare, _Alloc>::iterator = std::_Rb_tree_iterator, unsigned int> >]()' /sw/src/fink.build/gcc45-4.4.999-20091214/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/include/bits/stl_tree.h:216:7: note: candidate is: bool std::_Rb_tree_iterator<_Tp>::operator!=(const std::_Rb_tree_iterator<_Tp>::_Self&) const [with _Tp = std::pair, std::_Rb_tree_iterator<_Tp>::_Self = std::_Rb_tree_iterator >] /sw/src/fink.build/gcc45-4.4.999-20091214/gcc-4.5-20091214/libstdc++-v3/testsuite/23_containers/map/operators/1_neg.cc:41:32: error: no match for 'operator==' in 'itr == mapByName.std::map<_Key, _Tp, _Compare, _Alloc>::end [with _Key = std::basic_string, _Tp = unsigned int, _Compare = std::less >, _Alloc = std::allocator, unsigned int> >, std::map<_Key, _Tp, _Compare, _Alloc>::iterator = std::_Rb_tree_iterator, unsigned int
[Bug c++/42358] [4.5 Regression][C++0x] Assembler failure on libstdc++-v3/testsuite/23_containers/multimap/init-list.cc with -O0
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-12-13 15:34:12 |2009-12-15 04:07:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42358
[Bug c++/42358] [4.5 Regression][C++0x] Assembler failure on libstdc++-v3/testsuite/23_containers/multimap/init-list.cc with -O0
--- Comment #4 from jason at gcc dot gnu dot org 2009-12-15 04:54 --- Mysterious hash table lookup failure after htab_expand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42358
[Bug other/42375] New: trunk hangs during diffutils configure
the attached code from the diffutils configure script is supposed to check for "working C stack overflow detection" but instead hangs when built with trunk at -O2 or higher. 4.4.2 works. $ gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-unknown-linux-gnu/gcc-bin/4.5.0-pre/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/configure --prefix=/usr --bindir=/usr/x86_64-unknown-linux-gnu/gcc-bin/4.5.0-pre --includedir=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/include --datadir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre --mandir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre/man --infodir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/include/g++-v4 --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --disable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre/python --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo SVN' --enable-lto --enable-checking Thread model: posix gcc version 4.5.0-pre 20091215 (experimental) rev. 155245 (Gentoo SVN) -- Summary: trunk hangs during diffutils configure Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dirtyepic at gentoo dot org GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42375
[Bug other/42375] trunk hangs during diffutils configure
--- Comment #1 from dirtyepic at gentoo dot org 2009-12-15 05:24 --- Created an attachment (id=19303) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19303&action=view) conftest.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42375
[Bug other/42375] trunk hangs during diffutils configure
--- Comment #2 from dirtyepic at gentoo dot org 2009-12-15 05:24 --- Created an attachment (id=19304) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19304&action=view) conftest.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42375
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #36 from tkoenig at gcc dot gnu dot org 2009-12-15 07:09 --- If it is any help, code which traps for a do loop is illegal Fortran, so the compiler may do anything in this case anyway. Is there a function like __builtin_i_dont_care_if_this_traps_or_not_if_it_traps_its_the_users_fault ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
