[Bug target/54061] [4.8 Regression] gcc.c-torture/compile/mipscop-*.c ICEs with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54061 Andrew Pinski changed: What|Removed |Added Summary|[4.8 Regression]|[4.8 Regression] |gcc.c-torture/compile/mipsc |gcc.c-torture/compile/mipsc |op-1.c ICEs with -g |op-*.c ICEs with -g --- Comment #1 from Andrew Pinski 2012-07-21 07:03:19 UTC --- FAIL: gcc.c-torture/compile/mipscop-1.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/mipscop-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/mipscop-2.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/mipscop-2.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/mipscop-3.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/mipscop-3.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/mipscop-4.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/mipscop-4.c -O3 -g (test for excess errors)
[Bug libffi/53014] [4.8 Regression] libffi failures on mips64-linux-gnu with soft-float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53014 --- Comment #2 from Andrew Pinski 2012-07-21 07:06:19 UTC --- This still happens as of today.
[Bug fortran/54035] [OOP] TBP wrongly binds to a generic name if the specific name is the same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54035 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-21 Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2012-07-21 08:50:43 UTC --- Related: PR 42418.
[Bug fortran/54035] [OOP] TBP wrongly binds to a generic name if the specific name is the same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54035 --- Comment #2 from janus at gcc dot gnu.org 2012-07-21 09:35:49 UTC --- The problem is really that we have only one symbol for the specific and generic procedure.
[Bug fortran/42418] PROCEDURE: Rejects interface which is both specific and generic procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42418
--- Comment #6 from janus at gcc dot gnu.org 2012-07-21 09:51:57 UTC ---
The error in comment #0 should be fixable by something like the following:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c(revision 189711)
+++ gcc/fortran/decl.c(working copy)
@@ -4807,9 +4807,17 @@ match_procedure_interface (gfc_symbol **proc_if)
if ((*proc_if)->generic)
{
- gfc_error ("Interface '%s' at %C may not be generic",
- (*proc_if)->name);
- return MATCH_ERROR;
+ /* For generic interfaces, check if there is
+ a specific procedure with the same name. */
+ gfc_interface *gen = (*proc_if)->generic;
+ while (gen && strcmp (gen->sym->name, (*proc_if)->name) != 0)
+gen = gen->next;
+ if (!gen)
+{
+ gfc_error ("Interface '%s' at %C may not be generic",
+ (*proc_if)->name);
+ return MATCH_ERROR;
+}
}
if ((*proc_if)->attr.proc == PROC_ST_FUNCTION)
{
However, I wonder whether this whole generic check does not come to early. If
the generic interface is declared after the PROCEDURE statement, it will not be
triggered. It should probably be moved to resolve.c
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 Uros Bizjak changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[4.6 Regression] Revision |[4.6/4.7/4.8 Regression] |158105 miscompiles |Revision 158105 miscompiles |doduc.f90 |doduc.f90 --- Comment #30 from Uros Bizjak 2012-07-21 10:42:22 UTC --- This still happens with: gcc version 4.8.0 20120720 (experimental) [trunk revision 189718] (GCC) on x86_64-unknown-linux-gnu.
[Bug fortran/54034] [4.8 Regression] doduc benchmark from polyhedron 11 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54034 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #8 from Uros Bizjak 2012-07-21 10:44:26 UTC --- Dup of pr43716. *** This bug has been marked as a duplicate of bug 43716 ***
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 Uros Bizjak changed: What|Removed |Added CC||ubizjak at gmail dot com --- Comment #31 from Uros Bizjak 2012-07-21 10:44:26 UTC --- *** Bug 54034 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 --- Comment #32 from Uros Bizjak 2012-07-21 10:49:31 UTC --- gcc version 4.8.0 20120720 (experimental) [trunk revision 189718] (GCC) ==2822== Memcheck, a memory error detector ==2822== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==2822== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==2822== Command: ./a.out ==2822== MAIN : FIN S2 MAIN : FIN S1 MAIN : FIN S00011 MAIN : FIN S00022 TEMPS = 33. , NITERA : 1 TEMPS = 34.00031044 , NITERA :186 TEMPS = 35.00497388 , NITERA :955 TEMPS = 36.7615 , NITERA : 1512 TEMPS = 37.00012624 , NITERA : 1765 TEMPS = 38.00060760 , NITERA : 2044 TEMPS = 39.00312223 , NITERA : 2327 TEMPS = 40.00168143 , NITERA : 2607 TEMPS = 45.00187475 , NITERA : 4017 TEMPS = 50.00261983 , NITERA : 5492 TEMPS = 55.00263522 , NITERA : 6981 TEMPS = 60.00087007 , NITERA : 8679 ==2822== Invalid read of size 8 ==2822==at 0x4040E8: s00061_ (doduc.f90:568) ==2822==by 0x412AD3: s00013_ (doduc.f90:1150) ==2822==by 0x41B9D4: MAIN__ (doduc.f90:182) ==2822==by 0x400B4C: main (doduc.f90:199) ==2822== Address 0x3fefff770 is not stack'd, malloc'd or (recently) free'd ==2822== I can reproduce it here with Rev. 189737; it also crashes without running valgrind. It crashes (on x86-64 openSUSE Factory) with -O3 -ffast-math [-g] It does not crash with either of the following added: -fno-fast-math -fno-inline-functions -fno-predictive-commoning -fno-tree-vectorize -fno-protect-parens (implied by -Ofast) Nor does it crash with: -O2 -ftree-vectorize -finline-functions -ffpredictive-commoning -ffast-math -m32 -O3 -ffast-math
[Bug c++/54056] Fast run out of memory compiling template specialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54056 --- Comment #1 from Sergey Prokhorenko 2012-07-21 10:58:04 UTC --- I also asked few people to test, this could be reproduced on: g++ (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5) g++-mp-4.6 (MacPorts gcc46 4.6.3_3) 4.6.3 g++-mp-4.7 (MacPorts gcc47 4.7.1_1) 4.7.1 CentOS 6.3 / GCC 4.7.1 custom build They also tested on gcc 4.4.6, 4.2.1, 4.5.3 on the same systems, and with these earlier gcc versions the bug does not happen.
[Bug target/54062] New: extraneous move due to register allocation issue on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54062 Bug #: 54062 Summary: extraneous move due to register allocation issue on x86_64 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Created attachment 27852 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27852 test case The attached test case defines two functions for inserting an element in a doubly-linked circular list. Ideally the two functions should compile to equivalent code, but on x86_64 the "good" function consistently gets an extra move to bridge the prologue to the final insertion block for the case where the list is empty (2nd insn after L6 below): --- bad 2012-07-21 12:29:46.0 +0200 +++ good2012-07-21 12:29:45.0 +0200 @@ -1,4 +1,4 @@ -clocksource_enqueue_bad: +clocksource_enqueue_good: movqclocksource_list(%rip), %rax cmpq$clocksource_list, %rax je .L6 @@ -10,14 +10,15 @@ movq(%rax), %rax cmpq$clocksource_list, %rax jne .L5 - movq(%rdx), %rax + movq(%rdx), %rcx .L2: - leaq8(%rdi), %rcx - movq%rcx, 8(%rax) - movq%rax, 8(%rdi) + leaq8(%rdi), %rax + movq%rax, 8(%rcx) + movq%rcx, 8(%rdi) movq%rdx, 16(%rdi) - movq%rcx, (%rdx) + movq%rax, (%rdx) ret .L6: - movl$clocksource_list, %edx + movl$clocksource_list, %ecx + movq%rcx, %rdx jmp .L2 This occurs with gcc-4.8/4.7/4.6, haven't checked older versions. I'm entering this as a target bug because the extra move is not seen when compiling for sparc64, ppc64, or armv7. gcc-4.6 does a similar mistake when compiling for sparc64 and ppc64, but that goes away with gcc-4.7. For armv7 gcc-4.6 to 4.8 consistently generate equivalent code for both functions. The background is PR54031, a case where trunk briefly miscompiled some Linux kernel code that's technically invalid but has been working for ages. That code is the "bad" function here. The "good" function is a rewrite to avoid the technical problem (computing &ptr->field when ptr doesn't actually point to an object of its type), but that unfortunately causes a code size regression.
[Bug fortran/48820] TR 29113: Implement parts needed for MPI 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48820 --- Comment #18 from Tobias Burnus 2012-07-21 11:02:56 UTC --- Author: burnus Date: Sat Jul 21 11:02:47 2012 New Revision: 189743 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189743 Log: 2012-07-21 Tobias Burnus PR fortran/48820 * trans-intrinsic.c (gfc_conv_intrinsic_bound): Support lbound/ubound with dim= for assumed-rank arrays. * array.c (gfc_set_array_spec): Reject coarrays with assumed shape. * decl.c (merge_array_spec): Ditto. Return gfc_try. (match_attr_spec, match_attr_spec): Update call. 2012-07-21 Tobias Burnus PR fortran/48820 * gfortran.dg/assumed_rank_3.f90: New. * gfortran.dg/assumed_rank_11.f90: New. * gfortran.dg/assumed_rank_1.f90: Update dg-error. * gfortran.dg/assumed_rank_2.f90: Update dg-error. * gfortran.dg/assumed_rank_7.f90: Update dg-error. Added: trunk/gcc/testsuite/gfortran.dg/assumed_rank_11.f90 trunk/gcc/testsuite/gfortran.dg/assumed_rank_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/assumed_rank_1.f90 trunk/gcc/testsuite/gfortran.dg/assumed_rank_2.f90 trunk/gcc/testsuite/gfortran.dg/assumed_rank_6.f90 trunk/gcc/testsuite/gfortran.dg/assumed_rank_7.f90
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #33 from Uros Bizjak 2012-07-21 11:31:18
UTC ---
The NaN is generated as a mask for DFmode ABS_EXPR:
(insn 124 123 125 (set (reg:V2DF 508)
(mem/u/c:V2DF (symbol_ref/u:DI ("*.LC13") [flags 0x2]) [5 S16 A128]))
doduc.f90:5376 -1
(expr_list:REG_EQUAL (const_vector:V2DF [
(const_double:DF +QNaN [+QNaN])
(const_double:DF 0.0 [0x0.0p+0])
])
(nil)))
or V2DFmode ABS_EXPR:
(insn 1648 1647 1649 (set (reg:V2DF 4657)
(mem/u/c:V2DF (symbol_ref/u:DI ("*.LC138") [flags 0x2]) [5 S16 A128]))
doduc.f90:1851 -1
(expr_list:REG_EQUAL (const_vector:V2DF [
(const_double:DF +QNaN [+QNaN])
(const_double:DF +QNaN [+QNaN])
])
(nil)))
Probably, some mixup happens somewhere in RTL optimization passes.
[Bug target/54063] New: [4.8 regression] on powerpc64 gcc 4.8 generates larger code for global variable accesses than gcc 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063
Bug #: 54063
Summary: [4.8 regression] on powerpc64 gcc 4.8 generates larger
code for global variable accesses than gcc 4.7
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@it.uu.se
Consider this trivial test case, which scans for an element in a doubly-linked
list that uses a separate sentinel object to represent the head and tail of the
list:
struct list {
struct list *next, *prev;
int k;
} head = { &head, &head, 0 };
int lookup(int k)
{
struct list *list = head.next;
while (list != &head) {
if (list->k == k)
return 1;
list = list->next;
}
return 0;
}
The code generated by gcc 4.8 and 4.7 on powerpc64-linux for this test case is
similar, except gcc 4.8 generates an additional instruction at the start of the
function when computing the address of the global variable 'head':
@@ -11,25 +11,26 @@
.previous
.type lookup, @function
.L.lookup:
+ addis 10,2,.LANCHOR0@toc@ha
addis 8,2,.LANCHOR0@toc@ha
- ld 9,.LANCHOR0@toc@l(8)
+ ld 9,.LANCHOR0@toc@l(10)
addi 8,8,.LANCHOR0@toc@l
cmpd 7,9,8
The rest is the same, modulo the numbers chosen for the labels.
The test case is reduced from similar code in the Linux kernel, see PR54062.
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 --- Comment #34 from Uros Bizjak 2012-07-21 12:16:42 UTC --- Maybe no problem with gcc at all: Compile doduc.f90 with -g -O3 -ffast-math -ffpe-trap=invalid Starting program: /home/uros/pb11/lin/source/a.out MAIN : FIN S2 MAIN : FIN S1 MAIN : FIN S00011 MAIN : FIN S00022 Program received signal SIGFPE, Arithmetic exception. 0x00402a71 in s00018 (i12=0, i21=0, iorg=0) at doduc.f90:3789 3789 & dtpa = 2.*sens*DABS(TMI(k)/DTMi(k)) (gdb) disass 0x00402a4f <+431>: movsd 0x229e61(%rip),%xmm3# 0x62c8b8 0x00402a57 <+439>: movsd %xmm3,0x100(%rsp) 0x00402a60 <+448>: movsd 0x21c790(%rip),%xmm3# 0x61f1f8 0x00402a68 <+456>: movsd 0x100(%rsp),%xmm6 => 0x00402a71 <+465>: divsd %xmm3,%xmm0 0x00402a75 <+469>: addsd %xmm6,%xmm6 0x00402a79 <+473>: andpd %xmm1,%xmm3 0x00402a7d <+477>: andpd %xmm1,%xmm0 (gdb) i r xmm3 xmm0 xmm3 0 xmm0 0 To me, it looks like invalid test. Any fortraners here to share their opinion?
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 --- Comment #35 from Uros Bizjak 2012-07-21 12:35:17 UTC --- Actually, exception happens at: Starting program: /home/uros/pb11/lin/source/a.out MAIN : FIN S2 MAIN : FIN S1 MAIN : FIN S00011 MAIN : FIN S00022 Program received signal SIGFPE, Arithmetic exception. s00017 () at doduc.f90:1852 1852 IF ( yy.GE.y ) qsec = qsec*y/yy (gdb) bt #0 s00017 () at doduc.f90:1852 #1 0x0041ba3a in doduc () at doduc.f90:186 #2 0x00400ba7 in main (argc=argc@entry=1, argv=0x7fffe163) at doduc.f90:199 #3 0x003c02e21735 in __libc_start_main (main=0x400b80 , argc=1, ubp_av=0x7fffdde8, init=, fini=, rtld_fini=, stack_end=0x7fffddd8) at libc-start.c:226 #4 0x00400bd1 in _start () (gdb) disass $pc-20,+30 Dump of assembler code from 0x40a1f4 to 0x40a212: 0x0040a1f4 : push %rsp 0x0040a1f5 : fisub 0x41(%rsi) 0x0040a1f8 : mulps %xmm1,%xmm0 0x0040a1fb : maxpd %xmm7,%xmm0 0x0040a1ff : mulpd %xmm0,%xmm1 0x0040a203 : cmplepd %xmm3,%xmm0 => 0x0040a208 : divpd %xmm3,%xmm1 0x0040a20c : andpd %xmm0,%xmm1 0x0040a210 : andnpd %xmm2,%xmm0 End of assembler dump. (gdb) i r xmm3 xmm1 xmm3 ( (0x0, 0x0, 0x0, 0x2), (0x0, 0x6), (0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc4, 0x6b, 0x1b, 0xef, 0xc0, 0x60, 0x1b, 0x40), (0x0, 0x0, 0x0, 0x0, 0x6bc4, 0xef1b, 0x60c0, 0x401b), (0x0, 0x0, 0xef1b6bc4, 0x401b60c0), (0x0, 0x401b60c0ef1b6bc4), 0x401b60c0ef1b6bc4 ) xmm1 ( (0x0, 0x0, 0x0, 0xfffe), (0x0, 0xfffe), (0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xea, 0x1e, 0x50, 0xb1, 0x21, 0xbd, 0x2, 0xc0), (0x0, 0x0, 0x0, 0x0, 0x1eea, 0xb150, 0xbd21, 0xc002), (0x0, 0x0, 0xb1501eea, 0xc002bd21), (0x0, 0xc002bd21b1501eea), 0xc002bd21b1501eea )
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 --- Comment #36 from Dominique d'Humieres 2012-07-21 13:40:09 UTC --- > To me, it looks like invalid test. Any fortraners here to share their opinion? Please read comments #23 and #24. One problem with NaN is that they propagate until something trap them. When did you get a successful compilation?
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 --- Comment #37 from Uros Bizjak 2012-07-21 13:51:59 UTC --- (In reply to comment #36) > > To me, it looks like invalid test. Any fortraners here to share their > > opinion? > > Please read comments #23 and #24. One problem with NaN is that they propagate > until something trap them. When did you get a successful compilation? No, the first NaN was born exactly at this instruction. Please note 0 / 0 which is the definition of NaN.
[Bug c++/54055] spurious(?) "invalid use of incomplete type" warning in template definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54055 --- Comment #3 from Jason Merrill 2012-07-21 14:11:11 UTC --- Yes, it was intentional, based on the discussion mentioned in the other comments. I made it a pedwarn rather than a hard error so that affected code would continue to compile.
[Bug fortran/39288] Bind(C): C_LOC of character substrings (F2003 erratum, pending)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39288 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2012-07-21 14:11:41 UTC --- That seems to be fixed in Fortran 2003, Technical Corrigendum 3, cf. ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1815.pdf (search for f03/0129). For the IR, see F03/0129 in ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1805.txt
[Bug fortran/39288] Bind(C): C_LOC of character substrings (F2003 erratum, pending)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39288 Tobias Burnus changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #2 from Tobias Burnus 2012-07-21 14:12:34 UTC --- (In reply to comment #1) > That seems to be fixed in Fortran 2003, Technical Corrigendum 3, cf. I meant: TC 5 (not 3).
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 --- Comment #38 from Dominique d'Humieres 2012-07-21 14:43:10 UTC --- > No, the first NaN was born exactly at this instruction. Please note 0 / 0 > which is the definition of NaN. AFAIU the loop around line 1852, the only possibility for 0/0 is yy==qsec==0, but since 0.1<=y, the line 1852 should not be accessed. If I compile doduc.f90 with '-O3 -ffast-math -ffpe-trap=invalid' I get the "Floating-point exception" with trunk and 4.4. If I compile with -fno-tree-loop-if-convert the exception occurs somewhere else: #3 0x1306e #4 0x10001d17c #5 0x10001eca8 versus #3 0x1a863 #4 0x10001d11e #5 0x10001ec98 !-(poor backtrace on darwin).
[Bug libstdc++/54064] New: C++11 unordered_map emplace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54064 Bug #: 54064 Summary: C++11 unordered_map emplace Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: martin.ale...@hotmail.fr Hello, Sorry for my english I'm french. I noticed an issue with std::unordered_map::emplace member function: it should use the first variadic argument to construct the key, and the other arguments to construct a mapped_type object, instead of constructing directly a std::pair object. For example, we should be able to do that: std::unordered_map> m; m.emplace(1, 2, 3); instead of: std::unordered_map> m; m.emplace(1, std::make_pair(2, 3)); It would be useful to correct this function because it would avoid an extra move operation. Thank you
[Bug libstdc++/54064] C++11 unordered_map emplace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54064 --- Comment #1 from Jonathan Wakely 2012-07-21 17:09:03 UTC --- See http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2006
[Bug fortran/42418] PROCEDURE: Rejects interface which is both specific and generic procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42418 --- Comment #7 from janus at gcc dot gnu.org 2012-07-21 17:10:32 UTC --- (In reply to comment #6) > However, I wonder whether this whole generic check does not come to early. If > the generic interface is declared after the PROCEDURE statement, it will not > be > triggered. It should probably be moved to resolve.c Along this line: module mod procedure(gen) :: f interface gen module procedure spec end interface gen contains subroutine spec() end subroutine end module This is rejected with: procedure(gen) :: f 1 Error: Interface 'gen' of procedure 'f' at (1) must be explicit I'm not sure if this error message is correct. In any case, it is accepted if 'spec' is used as an interface in the PROCEDURE declaration (which seems inconsistent).
[Bug libstdc++/54064] C++11 unordered_map emplace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54064 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely 2012-07-21 17:17:48 UTC --- To be more explicit: it's a known issue, but it has been categorised as "Not A Defect" so we implement what the standard specifies.
[Bug libstdc++/53561] [c++0x] regex_replace is missing overloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53561 Matthias Vallentin changed: What|Removed |Added CC||vallentin at icir dot org --- Comment #2 from Matthias Vallentin 2012-07-21 17:51:57 UTC --- (In reply to comment #1) > Never mind. I just saw that the implementation isn't supposed to be done. The documentation still mentions that regex_replace is not yet implemented: /** @todo Implement this function. */ Any ideas when we can start using it? Matthias
[Bug libstdc++/53561] [c++0x] regex_replace is missing overloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53561 --- Comment #3 from Jonathan Wakely 2012-07-21 18:00:16 UTC --- When someone contributes an implementation of it.
[Bug target/54063] [4.8 regression] on powerpc64 gcc 4.8 generates larger code for global variable accesses than gcc 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063 Mikael Pettersson changed: What|Removed |Added CC||amodra at gcc dot gnu.org --- Comment #1 from Mikael Pettersson 2012-07-21 18:47:30 UTC --- It's caused by Alan Modra's "rs6000 toc reference rtl again" change in r187699: http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00696.html http://gcc.gnu.org/ml/gcc-patches/2012-05/msg6.html Here's the diff in output from r187698 and r187699 on this test case: --- glovar.s-r1876982012-07-21 20:31:01.0 +0200 +++ glovar.s-r1876992012-07-21 20:35:59.0 +0200 @@ -11,8 +11,9 @@ .previous .type lookup, @function .L.lookup: + addis 10,2,.LANCHOR0@toc@ha addis 8,2,.LANCHOR0@toc@ha - ld 9,.LANCHOR0@toc@l(8) + ld 9,.LANCHOR0@toc@l(10) addi 8,8,.LANCHOR0@toc@l cmpd 7,9,8 bne 7,.L4
[Bug target/53633] __attribute__((naked)) should disable -Wreturn-type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53633 Sandra Loosemore changed: What|Removed |Added CC||sandra at codesourcery dot ||com --- Comment #2 from Sandra Loosemore 2012-07-21 20:06:29 UTC --- Paul Brook previously posted a patch for this, but it was never completed or committed: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01088.html I'm going to see if I can do anything to address the previous review comments. Also, that patch doesn't address similar problems in the C++ front end.
[Bug c++/54058] Injected friend functions are not considered when using contextual type info to take a function address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54058 --- Comment #2 from Andy Jost 2012-07-21 21:45:30 UTC --- I think you're right. Section 14.6.5.2 of the 2nd ed. (2003-10-15) has a footnote in section 14.6.5.2. It reads: 131) Friend declarations do not introduce new names into any scope, either when the template is declared of when it is instantiated. Perhaps I just need to provide forward declarations for the friend functions.
[Bug c++/54058] Injected friend functions are not considered when using contextual type info to take a function address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54058 Andy Jost changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andy Jost 2012-07-21 21:48:02 UTC --- Not a bug.
[Bug gcov-profile/35591] value profiling tuning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35591 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-21 CC||steven at gcc dot gnu.org Component|middle-end |gcov-profile Ever Confirmed|0 |1
[Bug gcov-profile/35590] Value profiling: string op -- requires power of 2 value??
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35590 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-21 CC||steven at gcc dot gnu.org Component|middle-end |gcov-profile Ever Confirmed|0 |1
[Bug gcov-profile/35543] Add more strOp for value profiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35543 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-21 CC||steven at gcc dot gnu.org Component|middle-end |gcov-profile Ever Confirmed|0 |1
[Bug gcov-profile/27453] gcov opens files with O_RDWR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27453 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #4 from Steven Bosscher 2012-07-21 23:14:12 UTC --- Right, I don't think this is valid. For the gcno files, perhaps. But the gcda files are for writing. Perhaps this should be closed as WONTFIX.
[Bug gcov-profile/28441] Need atomic increment of gcov counters for MP programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28441 Steven Bosscher changed: What|Removed |Added CC||matz at gcc dot gnu.org, ||rguenth at gcc dot gnu.org, ||steven at gcc dot gnu.org --- Comment #15 from Steven Bosscher 2012-07-21 23:25:38 UTC --- Matz's patch http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00950.html was never committed on the trunk. That's unfortunate, we're living more and more in a multi-threaded world. Also, the atomic operations in GCC 4.8 should make this easier to implement for all targets now (instead of only for i386). Matz, could you have a look and see if you're interested in finishing that nice piece of work of yours? Or if you're not interested, let that know, too, so someone else can pick up the ball where you drop it! :-)
[Bug gcov-profile/32543] Gcov: profile.c total_num_edges_instrumented never incremented (patch included)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32543 --- Comment #1 from Steven Bosscher 2012-07-21 23:37:05 UTC --- Author: steven Date: Sat Jul 21 23:37:02 2012 New Revision: 189748 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189748 Log: PR gcov-profile/32543 * profile.c (branch_prob): Update total_num_edges_instrumented and report the number of edges to instrument. Modified: trunk/gcc/ChangeLog trunk/gcc/profile.c
[Bug gcov-profile/32543] Gcov: profile.c total_num_edges_instrumented never incremented (patch included)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32543 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||steven at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Steven Bosscher 2012-07-21 23:38:16 UTC --- trivial but it still took almost 5 years to do something about it. Sorry it took so long.
[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-21 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Steven Bosscher 2012-07-21 23:57:18 UTC --- A tool to merge multiple gcda files shoulnd't be very difficult to write. I don't think this should be done by the compiler itself, that would greatly complicate things. But a separate tool, gcov-merge say, would work, and this isn't a big job to create using libgcov (and gcov-dump as an example). You'd also be able to merge profile information from different directories. Would something like the above work for you?
[Bug gcov-profile/47793] Relative path in fprofile-use turns into absolute path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47793 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||steven at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Steven Bosscher 2012-07-22 00:02:22 UTC --- I don't see in what way this is not fixed...
[Bug gcov-profile/49340] read_couts_file() not called for -fbranch-probabilities
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49340 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-22 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Steven Bosscher 2012-07-22 00:04:44 UTC --- The best way around this, is to use -fprofile-generate and -fprofile-use. But it's a bug, for sure.
[Bug gcov-profile/50631] g++.dg/bprob/g++-bprob-2.C -fbranch-probabilities FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50631 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-22 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Steven Bosscher 2012-07-22 00:07:38 UTC --- Tru64 is not supported anymore. Rainer, since this is a regression, I haven't closed this PR for now. Do you think this problem should be marked as a regression for GCC 4.7 (and hope someone cares enough to address the issue)? Otherwise, let's close this one.
[Bug gcov-profile/51975] ICE in gcc in convert_move, at expr.c:326 with fprofile-use when source changes from fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51975 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-22 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Steven Bosscher 2012-07-22 00:11:31 UTC --- I think the transformation should just be disabled completely if the checksums don't match. Or if you take this path anyway, you could store the checksums on the struct function instead of re-computing it for every check.
[Bug gcov-profile/53915] gcov can call format_gcov with top > bottom, which is unexpected and gives 99.99%
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53915 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #5 from Steven Bosscher 2012-07-22 00:15:21 UTC --- Is there a small test case for this problem?
[Bug gcov-profile/53546] gcc ICEs when using -fripa at varpool.c:45
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53546 Steven Bosscher changed: What|Removed |Added Status|WAITING |NEW CC||steven at gcc dot gnu.org --- Comment #3 from Steven Bosscher 2012-07-22 00:18:33 UTC --- The proper place to post patches is gcc-patches. Much appreciated if you can post your patch there, with an explanation of the problem and of why your patch fixes it. Is there a test case that fails without Google-specific patches? Otherwise, this should be closed as invalid, because it's not an FSF GCC problem.
[Bug gcov-profile/48361] gcov freezes when using --all-blocks (-a) flag.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48361 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-22 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1
[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618 --- Comment #2 from Andrew Pinski 2012-07-22 00:42:28 UTC --- We have one internally at Cavium which is designed to run afterwards and merge a few gcda file. It is designed for how we run multi-core programs and write a gcda file for each run. And there one here: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00423.html
[Bug target/54065] New: [SH] Prefer @(R0,Rn) addressing for floating-point load/store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54065
Bug #: 54065
Summary: [SH] Prefer @(R0,Rn) addressing for floating-point
load/store
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
The following function
float test00 (float* x)
{
return x[10] + x[1] + x[20] + x[30];
}
compiled with e.g. '-O2 -m4-single -ml' results in:
mov r4,r2
mov r4,r1
add #40,r2
add #4,r1
fmov.s @r2,fr0
fmov.s @r1,fr1
add #76,r1
add #120,r4
faddfr1,fr0
fmov.s @r1,fr1
faddfr1,fr0
fmov.s @r4,fr1
rts
faddfr1,fr0
which would be better as:
mov#40,r0
fmov.s@(r0,r2),fr0
mov#4,r0
fmov.s@(r0,r1),fr1
mov#80,r0
faddfr1,fr0
fmov.s@(r0,r1),fr1
mov#120,r0
faddfr1,fr0
fmov.s@(r0,r4),fr1
rts
faddfr1,fr0
In sh.md (around line 11724) there are some old peephole patterns that were
supposed to handle this case, I guess. However, they seem to be defunct.
[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618 xunxun changed: What|Removed |Added CC||xunxun1982 at gmail dot com --- Comment #3 from xunxun 2012-07-22 06:56:11 UTC --- (In reply to comment #1) > A tool to merge multiple gcda files shoulnd't be very difficult to write. I > don't think this should be done by the compiler itself, that would greatly > complicate things. But a separate tool, gcov-merge say, would work, and this > isn't a big job to create using libgcov (and gcov-dump as an example). You'd > also be able to merge profile information from different directories. > > Would something like the above work for you? But for VC and Intel Compiler they can auto merge all PGO information. Will we make gcc to have the similar behavior?
