[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618 xunxun xunxun1982 at gmail dot com changed: What|Removed |Added CC||xunxun1982 at gmail dot com --- Comment #3 from xunxun xunxun1982 at gmail dot com 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?
[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-07-22 07:06:47 UTC --- -fprofile-dir= is already implemented.
[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618 --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2012-07-22 10:23:37 UTC --- (In reply to comment #3) (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? xunxun, GCC does merge profile information from different runs into one gcda file. It works differently from ICC in that ICC produces one .dyn file per test run and uses prof_merge to generate merge multiple .dyn files into a summary file. GCC does this merging from multiple runs automatically. What GCC does not do, is merge multiple gcda files (which would be the equivalent of merging multiple pgopti.dpi files with ICC). The issue in this problem report, is that with MPI there will be multiple images of the same program running simultaneously. The different images can't share the same set of gcda files (you'd have races) so each image generates its own set of gcda files. For that, a new merge tool is necessary. Ideally, this tool would also run transparently. One way to do this could be to take multiple arguments for -fprofile-dir and merge profile info from each directory.
[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618 --- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2012-07-22 10:46:30 UTC --- (In reply to comment #2) 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 now, of course, you're going to contribute that? ;-) And there one here: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00423.html This merges results for files without their own gcno file but mentioned more than once in gcda files for multiple source files (e.g. for inline functions in headers). You can't merge multiple gcda files for one source file, but the patch does provide the infrastructure to support this.
[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 #39 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-07-22 10:47:42 UTC --- If I compile with -fno-tree-loop-if-convert the exception occurs somewhere else: It occurs in s00018 in the loop between lines 3782 to 3796 DO j = 1 , n1 dtpar = V0012 IF ( i.EQ.NIV .AND. j.EQ.ISLni ) THEN k1 = 2 DO k = 1 , k1 dtpa = V0012 IF ( DABS(DTMi(k)).GT.eps ) dtpa = 2.*sens*DABS(TMI(k)/DTMi(k)) dtpar = DMIN1(dtpar,dtpa) ENDDO ELSEIF ( DABS(DTGai(i,j)).GT.eps ) THEN dtpar = sens*DABS(TGAi(i,j)/DTGai(i,j)) ENDIF DTTemp = DMIN1(DTTemp,dtpar) ENDDO Before the loop i=2, n1=2, NIV=0, ISLni=0, eps=1.0e-8, sens=0.01, DTTemp=0.05, DTGai(2,1)=3.4750524086054519, DTGai(2,2)=2.8245839253949421, TGAi(2,1)=905.00, and TGAi(2,1)=1040.0. So (i.EQ.NIV .AND. j.EQ.ISLni) is false, DTGai(2,:)eps and dtpar20.0DTTemp, hence the loop does nothing and should not generate any Floating-point exception as it does. If I read correctly the assembly bellow, the loop k1 = 2 DO k = 1 , k1 dtpa = V0012 IF ( DABS(DTMi(k)).GT.eps ) dtpa = 2.*sens*DABS(TMI(k)/DTMi(k)) dtpar = DMIN1(dtpar,dtpa) ENDDO is unrolled and moved outside the 'DO j = 1 , n1' loop when s00018.f90 is compiled with -O2 -ffpe-trap=invalid -fno-trapping-math. The worst part of the optimization and the cause of the floating-point exception seems that the test 'IF ( DABS(DTMi(k)).GT.eps )' is removed (or delayed, even if I replace eps with 1.0) while both TMI and DTMI are filled with zeroes. Note that if I replace IF ( DABS(DTMi(k)).GT.eps ) dtpa = 2.*sens*DABS(TMI(k)/DTMi(k)) with dtpa = 2.*sens*DABS(TMI(k))/max(DABS(DTMi(k)),eps) there is no exception. IMO computing TMI(k)/DTMi(k) without the IF is over-agressive: if DABS(DTMi(k)).LT.eps, dtpa will have to be recomputed. In addition, if the k loop is moved outside the j loop, it should at least protected by IF ( i.EQ.NIV), or better by IF ( i.EQ.NIV .AND. ISLni.GE.1 .AND. ISLni.LE.n1). Also since the ELSEIF depends on j and the IF is taken at most once, moving the k loop outside the j loop seems dubious. Note that the exception is (should be) harmless as it occurs in a dead branch. L29: movl36404(%r9,%rdi,4), %ecx# aaa77.nasl, n1 movsd%xmm9, 936(%r11)# x, aaa11.dtphy movsd856(%r11), %xmm8# aaa11.v22202, sens movl$1, 396(%rsp)#, j testl%ecx, %ecx# n1 jleL41#, movsd19416(%r9), %xmm7# aaa77.dtmi, D.2813 movapd%xmm8, %xmm11# sens, D.2817 movl$0, %edx#, tmp908 movsd19400(%r9), %xmm0# aaa77.tmi, x addsd%xmm8, %xmm11# sens, D.2817 movapd%xmm7, %xmm10# D.2813, D.2814 movq_aaa13_@GOTPCREL(%rip), %rax#, divsd%xmm7, %xmm0# D.2813, x andpd%xmm1, %xmm10# tmp1323, D.2814 movsd19424(%r9), %xmm12# aaa77.dtmi, D.2813 movsd19408(%r9), %xmm7# aaa77.tmi, x movsd944(%r11), %xmm6# aaa11.dttemp, x movl240(%rax), %esi# aaa13.niv, pretmp.160 movl244(%rax), %r14d# aaa13.islni, D.2806 xorl%eax, %eax# pretmp.165 divsd%xmm12, %xmm7# D.2813, x andpd%xmm1, %xmm0# tmp1323, x mulsd%xmm11, %xmm0# D.2817, x ucomisd%xmm0, %xmm2# x, x seta%al#, pretmp.165 ucomisd%xmm3, %xmm10# tmp1324, D.2814 cmovbe%edx, %eax# pretmp.165,, tmp908, pretmp.165 xorl%edx, %edx# ucomisd%xmm2, %xmm2# x, x setp%dl#, addl$1, %ecx#, movl%ecx, 12(%rsp)#, %sfp xorl%ecx, %ecx# movl%edx, 336(%rsp)#, %sfp leaq30032(%r9,%rdi,8), %rdx#, ivtmp.264 andpd%xmm1, %xmm7# tmp1323, x mulsd%xmm11, %xmm7# D.2817, x movapd%xmm3, %xmm11# tmp1324, cmpltsd%xmm10, %xmm11#, D.2814, movapd%xmm11, %xmm10#, tmp923 andpd%xmm11, %xmm0# tmp923, tmp924 movapd%xmm2, %xmm11# x, x andnpd%xmm2, %xmm10# x, tmp921 orpd%xmm0, %xmm10# tmp924, tmp921 ucomisd%xmm10, %xmm10# tmp921, tmp921 setp%cl#, orl336(%rsp), %eax# %sfp, pretmp.165 movl%ecx, 364(%rsp)#, %sfp movl%eax, 336(%rsp)# pretmp.165, %sfp jeL34#, movapd%xmm10, %xmm11# tmp921, x L34: movapd%xmm3, %xmm0# tmp1324, andpd%xmm1, %xmm12# tmp1323, D.2814 xorl%eax, %eax# cmpltsd%xmm12, %xmm0#, D.2814, movapd%xmm1, %xmm10# tmp1323, tmp1385
[Bug c++/54055] spurious(?) invalid use of incomplete type warning in template definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54055 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-07-22 11:27:20 UTC --- Let's close this then.
[Bug middle-end/54066] New: wrong-code at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54066
Bug #: 54066
Summary: wrong-code at -O0
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wbr...@gmail.com
GCC 4.6.3
1
GCC 4.7.1
2
#include iostream
using namespace std;
struct c {
char* Achit;
c() {
Achit = new char[1];
}
unsigned char uint8() {
unsigned char lires = 1;
Achit += 1;
return lires;
};
};
int main() {
c* Lf = new c();
char* Lc1 = Lf-Achit;
Lf-Achit += Lf-uint8();
cout Lf-Achit - Lc1 endl;
}
[Bug rtl-optimization/11261] Weak code generated for JPEG compression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11261 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-22 14:54:11 UTC --- As of rev 189746 the issue is still present. With '-m4-single -O2 -mpretend-cmove' (scheduling disabled by default) the file jidctflt.c from the CSiBE set contains the following sequence: ... sts fpul,r0 ftrcfr7,fpul add #4,r0 shadr6,r0 and r7,r0 mov.b @(r0,r2),r0 mov.b r0,@(1,r1) sts fpul,r0 ftrcfr1,fpul fmovfr5,fr1 faddfr2,fr1 fsubfr2,fr5 add #4,r0 shadr6,r0 and r7,r0 mov.b @(r0,r2),r0 mov.b r0,@(6,r1) sts fpul,r0 ftrcfr6,fpul add #4,r0 shadr6,r0 and r7,r0 mov.b @(r0,r2),r0 mov.b r0,@(2,r1) sts fpul,r0 ftrcfr1,fpul add #4,r0 shadr6,r0 and r7,r0 mov.b @(r0,r2),r0 mov.b r0,@(5,r1) sts fpul,r0 With '-m4-single -O2 -mpretend-cmove -fschedule-insns' it seems to be better. The address index is calculated in different regs than R0 and then copied to R0, as described in comment #5: ftrcfr7,fpul mov r11,r0 sts fpul,r5 faddfr3,fr1 mov.b @(r0,r2),r0 add #4,r4 fmovfr10,fr0 fmacfr0,fr11,fr2 shadr6,r4 mov.b r0,@(7,r1) and r7,r4 ftrcfr1,fpul mov r4,r0 faddfr3,fr2 mov.b @(r0,r2),r0 add #4,r5 sts fpul,r4 fsubfr3,fr6 shadr6,r5 mov.b r0,@(1,r1) and r7,r5 fmovfr5,fr1 ftrcfr6,fpul mov r5,r0 sts fpul,r11 add #4,r4 mov.b @(r0,r2),r0 faddfr2,fr1 shadr6,r4 fsubfr2,fr5 mov.b r0,@(6,r1) and r7,r4 mov r4,r0 ftrcfr1,fpul mov.b @(r0,r2),r0 add #4,r11 sts fpul,r4 shadr6,r11 mov.b r0,@(2,r1) Thus, for this case it might be beneficial to enable sched1 again. Although, looking at some recent sched1 vs. no-sched1 runtime numbers in PR 22553, sched1 it doesn't seem to make a big difference on average.
[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||chrbr at gcc dot gnu.org --- Comment #25 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-22 15:25:05 UTC --- Thanks for the numbers! Although, on average, it doesn't seem to be worth it to enable sched1, it seems to 'fix' PR 11261. Christian, do you have any experience with enabling -fschedule-insns?
[Bug target/53961] internal compiler error: in memory_address_length, at config/i386/i386.c:23341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53961
--- Comment #17 from uros at gcc dot gnu.org 2012-07-22 15:44:55 UTC ---
Author: uros
Date: Sun Jul 22 15:44:51 2012
New Revision: 189756
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189756
Log:
PR target/53961
* config/i386/i386.md (*lea): New insn pattern.
(*lea_1): Remove.
(*leamode_2): Ditto.
(*lea_{3,4,5,6}_zext): Ditto.
* config/i386/constraints.md (j): Remove address constraint.
* config/i386/i386.c (ix86_decompose_address): Allow SImode subreg
of an address.
(ix86_print_operand_address): Handle SImode subreg of an address.
(ix86_avoid_lea_for_add): Reject zero-extended addresses for now.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/constraints.md
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/predicates.md
[Bug rtl-optimization/24815] loop unrolling ends up with too much reg+index addressing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24815
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Target|sh-elf |sh*-*-*
Last reconfirmed|2006-04-24 22:37:46 |2012-07-22
CC||olegendo at gcc dot gnu.org
Depends on||50749
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-22 16:25:55
UTC ---
As of rev 189746 I was able to reproduce the problem with the following reduced
test case:
extern int tbl[1000];
void f (int* b, const int* a)
{
for (int i = 0; i 998; i++)
b[i] = a[tbl[i]];
}
... compiled with '-O2 -m4-single -ml' (no loop unrolling):
mov.l .L6,r3 ! 66movsi_ie/1[length = 2]
mov #0,r7 ! 40movsi_ie/3[length = 2]
mov.w .L7,r2 ! 70*movhi/1[length = 2]
.align 2
.L3:
mov r7,r0 ! 77movsi_ie/2[length = 2]
mov.l @(r0,r3),r1 ! 46movsi_ie/7[length = 2]
dt r2 ! 71dect[length = 2]
shll2 r1 ! 47ashlsi3_std/3[length = 2]
mov r1,r0 ! 78movsi_ie/2[length = 2]
mov.l @(r0,r5),r1 ! 49movsi_ie/7[length = 2]
mov r7,r0 ! 79movsi_ie/2[length = 2]
add #4,r7 ! 51*addsi3_compact[length = 2]
bf/s.L3 ! 72branch_false[length = 2]
mov.l r1,@(r0,r4) ! 50movsi_ie/11[length = 2]
rts
nop ! 83*return_i[length = 4]
.align 1
.L7:
.short998
.L8:
.align 2
.L6:
.long_tbl
... which would be better as:
mov.l .L6,r3
mov.w .L7,r2
.L3:
mov.l @r3+,r0
dt r2
shll2 r0
mov.l @(r0,r5),r1
mov.l r1,@r4
bf/s.L3
add #4,r4
rts
nop
With loop unrolling enabled it looks similar to the code in comment #2.
It seems that this issue also depends on the auto-inc-dec related PR 50749.
[Bug libstdc++/53270] [4.6 Regression] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #36 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-22 16:46:07 UTC --- Author: redi Date: Sun Jul 22 16:46:02 2012 New Revision: 189758 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189758 Log: PR libstdc++/53270 * acinclude.m4 (GLIBCXX_GTHREADS_CXX11_COPY_ASSIGN): Define. * configure.ac (GLIBCXX_GTHREADS_CXX11_COPY_ASSIGN): Use it. * config.h.in: Regenerate. * configure: Likewise. * include/ext/concurrence.h (__copy_gthr_type): Define. (__mutex::__mutex, __recursive_mutex::__recursive_mutex, __cond::__cond): Use it. * include/ext/rope (__copy_gthr_mutex): Define. (_Refcount_Base::_Refcount_Base, _Rope_RopeRep::_Rope_RopeRep): Use it. * src/condition_variable.cc (condition_variable::condition_variable): Use memcpy instead of assignment. Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/acinclude.m4 branches/gcc-4_6-branch/libstdc++-v3/config.h.in branches/gcc-4_6-branch/libstdc++-v3/configure branches/gcc-4_6-branch/libstdc++-v3/configure.ac branches/gcc-4_6-branch/libstdc++-v3/include/ext/concurrence.h branches/gcc-4_6-branch/libstdc++-v3/include/ext/rope branches/gcc-4_6-branch/libstdc++-v3/src/condition_variable.cc
[Bug target/53949] [SH] Add support for mac.w / mac.l instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53949 --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-22 16:47:44 UTC --- If I understand correctly PR 29961 is somewhat related to this.
[Bug libstdc++/53270] [4.6 Regression] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #37 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-22 16:48:03 UTC --- Fixed, at last!
[Bug translation/54067] New: arm-none-eabi with -mapcs and attribute((interrupt)) generates wrong stack alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54067
Bug #: 54067
Summary: arm-none-eabi with -mapcs and attribute((interrupt))
generates wrong stack alignment
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@koios.de
Created attachment 27853
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27853
simple code to reproduce error
If a function has __attribute__((interrupt(IRQ))) set and is compiled with
arm-none-eabi and the option -mapcs, the generated prologue looks something
like
push {ip}
...
push {...}
...
sub sp, sp, ...
the first push {ip} is special when compiling with -mapcs and the function
attribute, but it seems this extra word is ignored when the stack is to be
aligned.
Thus when strd/ldrd instructions are generated accessing the stack you'll end
up in an alignment fault.
[Bug tree-optimization/53881] [4.8 regression] ICE in hoist_edge_and_branch_if_true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53881 --- Comment #7 from David Binderman dcb314 at hotmail dot com 2012-07-22 19:01:50 UTC --- Created attachment 27854 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27854 C source code Flag -O2 required. The compiler said ui.c:7157:1: internal compiler error: in emit_case_bit_tests, at tree-switch-conversion.c:340 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/53881] [4.8 regression] ICE in hoist_edge_and_branch_if_true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53881 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #8 from David Binderman dcb314 at hotmail dot com 2012-07-22 19:04:48 UTC --- This other attached source code crashes the compiler in the same place. I am not sure this bug is really fixed.
[Bug middle-end/54066] [4.6] wrong-code at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54066 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-07-22 19:11:42 UTC --- Lf-Achit += Lf-uint8(); Both the left side and the right side uses Lf-Achit . The above code is equivalent to: Lf-Achit = Lf-uint8() + Lf-Achit; Now the question comes which comes first, the access of Lf-Achit or the function call Lf-uint8(). The answer is it is (explicitly) unspecified by the C++ standard. So the answer is either.
[Bug fortran/54033] gfortran: Passing file as include directory - add diagnostic and ICE with -cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54033
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-07-22
CC||tkoenig at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-07-22
20:06:18 UTC ---
This patch looks OK so far.
Index: scanner.c
===
--- scanner.c (Revision 189754)
+++ scanner.c (Arbeitskopie)
@@ -311,12 +311,31 @@ add_path_to_list (gfc_directorylist **list, const
{
gfc_directorylist *dir;
const char *p;
-
+ struct stat st;
+
p = path;
while (*p == ' ' || *p == '\t') /* someone might do -I include */
if (*p++ == '\0')
return;
+ if (stat (p, st))
+{
+ if (errno != ENOENT)
+ gfc_warning_now (Include directory \%s\: %s, path,
+xstrerror(errno));
+ else
+ /* FIXME: Also support -Wmissing-include-dirs. */
+ gfc_warning_now (Include directory \%s\ does not exist,
+path);
+ return;
+}
+
+ else if (!S_ISDIR (st.st_mode))
+{
+ gfc_warning_now (\%s\ is not a directory, path);
+ return;
+}
+
if (head || *list == NULL)
{
dir = XCNEW (gfc_directorylist);
[Bug tree-optimization/53881] [4.8 regression] ICE in hoist_edge_and_branch_if_true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53881
--- Comment #9 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-07-22 20:18:55 UTC ---
markus@x4 tmp % test.i
int a,b,c;
void
fn1 ()
{
switch (a)
{
case 0:
case 10:
b=c;
out_bcon:
break;
case 3:
goto out_bcon;
}
}
markus@x4 tmp % gcc -c -O2 test.i
test.i: In function ‘fn1’:
test.i:15:1: internal compiler error: in hoist_edge_and_branch_if_true, at
tree-switch-conversion.c:80
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
markus@x4 tmp %
[Bug tree-optimization/53881] [4.8 regression] ICE in hoist_edge_and_branch_if_true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53881 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|NEW --- Comment #10 from Steven Bosscher steven at gcc dot gnu.org 2012-07-22 21:25:39 UTC --- (In reply to comment #8) This other attached source code crashes the compiler in the same place. I am not sure this bug is really fixed. The bug is somewhere else this time. It's a latent bug in tree-cfg.c which relied on labels being canonicalized in group_case_labels. I have a fix.
[Bug tree-optimization/54022] [4.8 regression] ICE in hoist_edge_and_branch_if_true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54022 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2012-07-22 21:29:42 UTC --- . *** This bug has been marked as a duplicate of bug 53881 ***
[Bug tree-optimization/53881] [4.8 regression] ICE in hoist_edge_and_branch_if_true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53881 --- Comment #11 from Steven Bosscher steven at gcc dot gnu.org 2012-07-22 21:29:42 UTC --- *** Bug 54022 has been marked as a duplicate of this bug. ***
[Bug c/54068] New: Compiler passes wrong argument to function when using -O3 and inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54068 Bug #: 54068 Summary: Compiler passes wrong argument to function when using -O3 and inline Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: vog...@gmail.com Created attachment 27855 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27855 Compile this ii file and run it; it shows the described problem In the attached example, gcc passes the wrong parameter to a function. The problem only was observed on a Ubuntu 12.04 i386 platform. It did not occur not on Ubuntu 12.04 amd64. The problem can be avoided by a) omitting the inline statement or b) by commenting out the optimisation attribute in the source code. Here's the output ofgcc -v -save-temps -o it it.cpp Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'it' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-linux-gnu/4.6/cc1plus -E -quiet -v -imultilib . -imultiarch i386-linux-gnu -D_GNU_SOURCE it.cpp -mtune=generic -march=i686 -fpch-preprocess -fstack-protector -o it.ii ignoring nonexistent directory /usr/local/include/i386-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i686-linux-gnu/4.6/../../../../i686-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/include/c++/4.6 /usr/include/c++/4.6/i686-linux-gnu/. /usr/include/c++/4.6/backward /usr/lib/gcc/i686-linux-gnu/4.6/include /usr/local/include /usr/lib/gcc/i686-linux-gnu/4.6/include-fixed /usr/include/i386-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'it' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-linux-gnu/4.6/cc1plus -fpreprocessed it.ii -quiet -dumpbase it.cpp -mtune=generic -march=i686 -auxbase it -version -fstack-protector -o it.s GNU C++ (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (i686-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=89 --param ggc-min-heapsize=111959 GNU C++ (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (i686-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=89 --param ggc-min-heapsize=111959 Compiler executable checksum: 2ed62271b86e2b75137544459bab1a81 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'it' '-mtune=generic' '-march=i686' as --32 -o it.o it.s COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/4.6/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'it' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-linux-gnu/4.6/collect2 --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 -z relro -o it /usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crt1.o /usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crti.o /usr/lib/gcc/i686-linux-gnu/4.6/crtbegin.o -L/usr/lib/gcc/i686-linux-gnu/4.6 -L/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu -L/usr/lib/gcc/i686-linux-gnu/4.6/../../../../lib -L/lib/i386-linux-gnu -L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/i686-linux-gnu/4.6/../../.. it.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i686-linux-gnu/4.6/crtend.o /usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crtn.o
[Bug target/33135] [SH] -ffinite-math-only should not be on by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33135 --- Comment #9 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-22 23:44:49 UTC --- Author: olegendo Date: Sun Jul 22 23:44:45 2012 New Revision: 189761 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189761 Log: PR target/33135 * config/sh/sh.opt (mieee): Use Var instead of Mask. Correct description. * config/sh/sh.c (sh_option_override): Do not change flag_finite_math_only. Set TARGET_IEEE to complement of flag_finite_math_only. * doc/invoke.texi (SH options): Add mno-ieee. Correct description of mieee and mno-ieee behavior. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/sh/sh.c branches/gcc-4_7-branch/gcc/config/sh/sh.opt branches/gcc-4_7-branch/gcc/doc/invoke.texi
[Bug middle-end/54068] Compiler passes wrong argument to function when using optimize attribute with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54068 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end Summary|Compiler passes wrong |Compiler passes wrong |argument to function when |argument to function when |using -O3 and inline|using optimize attribute ||with -O3 Severity|major |normal
[Bug target/33135] [SH] -ffinite-math-only should not be on by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33135 --- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-22 23:50:00 UTC --- Author: olegendo Date: Sun Jul 22 23:49:56 2012 New Revision: 189762 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189762 Log: PR target/33135 * config/sh/sh.opt (mieee): Use Var instead of Mask. Correct description. * config/sh/sh.c (sh_option_override): Do not change flag_finite_math_only. Set TARGET_IEEE to complement of flag_finite_math_only. * doc/invoke.texi (SH options): Add mno-ieee. Correct description of mieee and mno-ieee behavior. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/sh/sh.c branches/gcc-4_6-branch/gcc/config/sh/sh.opt branches/gcc-4_6-branch/gcc/doc/invoke.texi
[Bug target/33135] [SH] -ffinite-math-only should not be on by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33135 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-22 23:52:58 UTC --- Fixed on 4.8, 4.7.2, 4.6.4.
[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 Alan Modra amodra at gmail dot com changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #2 from Alan Modra amodra at gmail dot com 2012-07-23 02:13:53 UTC --- Gultiy as charged. Not splitting the address early loses some opportunities for common subexpression eliminiation. However, splitting the address early a) is inconsistent with the treatment of other powerpc addresses b) can result in incorrect code and/or require hacks (that pessimise scheduling) to prevent incorrect code in other cases, eg. indirect function call sequence. c) can result in silly uses of call-saved regs for the high part of an address calculation around a call or outside of a loop, when it would be far better to just recalculate an address thus freeing the reg for better uses. d) can allow the high/low parts to move in ways that result in the linker disabling optimisation of these sequences for the entire object file (or generating bad code if you have an old linker). eg. another kernel case where the low part moved to a different (hot/cold) section. Overall, I think we get better code by *not* splitting early, particularly for larger functions that run into (c).
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #19 from Daniel Richard G. skunk at iskunk dot org 2012-07-23 04:20:33 UTC --- The good news: The build gets past all of the pthreads-related errors described here, so I think those two changes may be a workable solution. The bad news: I'll still running up against this error: /tmp/gcc-build/./prev-gcc/g++ -B/tmp/gcc-build/./prev-gcc/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -nostdinc++ -B/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/libsupc++/.libs -I/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/tg/freeport/src/gcc/gcc--4.7.1-tera/libstdc++-v3/libsupc++ -L/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -L/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/libsupc++/.libs -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o default-c.o rs6000-c.o \ cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/tg/freeport/arch/aix32/lib -L/tg/freeport/arch/aix32/lib -L/tg/freeport/arch/aix32/lib -lmpc -lmpfr -lgmp -L../zlib -lz ld: 0711-317 ERROR: Undefined symbol: vtable for std::ctypechar ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: error: ld returned 8 exit status gmake[3]: *** [cc1] Error 1 gmake[3]: Leaving directory `/tmp/gcc-build/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/tmp/gcc-build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build' gmake: *** [bootstrap-lean] Error 2 I really need help with this error---this seems to be along the lines of the PatternCursor issue we saw the other day, only this one is more confusing. What do you think is going on here? (FWIW, the objects that want the missing symbol are the various instances of ctype_configure_char.o, which appears to be built from libstdc++-v3/config/os/aix/ctype_configure_char.cc. I *think* the std::ctype template/class is defined in libstdc++-v3/include/bits/locale_facets.h.)
[Bug c++/53549] [4.7/4.8 Regression] g++ and armadillo 3.2.0, operator() is inaccessible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549 --- Comment #14 from Conrad conradsand.arma at gmail dot com 2012-07-23 05:25:29 UTC --- (In reply to comment #13) Fixed. Thanks!
