[Bug middle-end/61335] New: [4.10 Regression] wrong code with -O2 -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61335 Bug ID: 61335 Summary: [4.10 Regression] wrong code with -O2 -fbounds-check Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Created attachment 32868 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32868action=edit reduced testcase The attached testcase is miscompiled with current trunk. A recent regression caused in the day between good: r210955 and bad: r210994 To reproduce compile and run the attached testcase as : gfortran -O2 -fbounds-check cp_units.f90 ; ./a.out BUG : XXXfs^-1XXX integer expected STOP 1 while e.g. '-O2' alone or '-fbound-check -O1' work fine.
[Bug middle-end/61335] [4.10 Regression] wrong code with -O2 -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61335 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- might not mean much, but -fno-tree-vrp fixes the testcase, so possibly caused by r210966 ?
[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Francois-Xavier Coudert from comment #4) This sounds a lot like believing you can build the better product by assigning blame to others, not by building something that works for users. I'm sorry if that's become the GCC philosophy. To be a GCC dev you don't have to adhere to some kind of apple^Mgnu-fandom, and each of them may have a different opinion on a particular subject, so do not mistake the opinion of one developer for a general GCC philosophy. There is no such thing.
[Bug c/61336] New: ICE on alpha: in print_operand_address, at config/alpha/alpha.c:5454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61336
Bug ID: 61336
Summary: ICE on alpha: in print_operand_address, at
config/alpha/alpha.c:5454
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mcree at orcon dot net.nz
Target: alpha
Created attachment 32869
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32869action=edit
Failing preprocessed source being malloc/malloc.c from glibc
ICE noted with Debian gcc-4.8.3 and now verified with trunk when compiling
malloc.c from glibc on alpha. Preprocessed source attached.
/home/mjc/toolchain/gcc-build/./gcc/xgcc -B/home/mjc/toolchain/gcc-build/./gcc/
ccjDEL1Z.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings
-fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes
-mlong-double-128 -mieee -mfp-rounding-mode=d -fpic
In file included from malloc.c:1878:0:
arena.c: In function ‘ptmalloc_unlock_all2’:
arena.c:303:33: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
arena.c:313:25: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
In file included from malloc.c:1878:0:
arena.c: In function ‘_int_new_arena’:
arena.c:768:24: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
malloc.c: In function ‘__libc_mallopt’:
malloc.c:4833:1: internal compiler error: in print_operand_address, at
config/alpha/alpha.c:5468
0x120a110cf print_operand_address(_IO_FILE*, rtx_def*)
../../gcc.git/gcc/config/alpha/alpha.c:5468
0x1206b3aa7 default_print_operand_address(_IO_FILE*, rtx_def*)
../../gcc.git/gcc/targhooks.c:344
0x12039cc87 output_address(rtx_def*)
../../gcc.git/gcc/final.c:3838
0x120a10e83 print_operand(_IO_FILE*, rtx_def*, int)
../../gcc.git/gcc/config/alpha/alpha.c:5345
0x1206b3a77 default_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc.git/gcc/targhooks.c:330
0x12039cb87 output_operand(rtx_def*, int)
../../gcc.git/gcc/final.c:3822
0x12039d267 output_asm_insn
../../gcc.git/gcc/final.c:3720
0x12039ec2f output_asm_insn
../../gcc.git/gcc/final.c:2643
0x12039ec2f final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
../../gcc.git/gcc/final.c:2594
0x12039ef23 final(rtx_def*, _IO_FILE*, int)
../../gcc.git/gcc/final.c:2025
0x12039f533 rest_of_handle_final
../../gcc.git/gcc/final.c:
0x12039f533 execute
../../gcc.git/gcc/final.c:4518
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
{standard input}: Assembler messages:
{standard input}:14226: Warning: end of file in string; '' inserted
{standard input}: Warning: .ent directive without matching .end
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jack Howarth from comment #6) I would also add that you are playing with fire here. Currently no company has a motivation to expend money or resources for fortran development on llvm as long as FSF gcc is buildable. If you start removing competing compilers from bootstrapping FSF gcc, it is much more likely that someone will fund such a llvm-based fortran compiler project. You may get some short-term satisfaction from walling off FSF-gcc from clang, the long-term outcome for the FSF gcc project might not be so happy. Is any company spending money on GCC Fortran development? That would be awesome if it were true! I also doubt that somebody will decide to fund a whole llvm-fortran compiler instead of simply installing GCC 4.2, which should still be able to bootstrap GCC trunk. It would be a strange business decision, unless the goal was to build a proprietary compiler by leeching off volunteer unpaid developers. That would make sense then. Since you are offering advice, let me humbly offer some back to you: Why not instead of starting a confrontation with Andrew and invoking some strange-sounding threats, you propose a patch to fix the problem? That seems to me much more constructive. Moreover, you don't even need to convince Andrew (or me), you just need your patch to be approved by one of the Global Reviewers (or the maintainers responsible for that part of the compiler). See gcc/MAINTAINERS. I don't see your name in that list, perhaps it would be a good time to start the steps to add it: https://gcc.gnu.org/contribute.html BTW, having a user-base without developers coming out of that user-base is useless. If no one from apple-darwin is interested in developing GCC, then it doesn't matter how big the user base is: GCC for apple-darwin will not get developed by magic gnomes (or by people that don't even own Apple hardware). So perhaps it would be in your own interest to do a bit of recruiting in the apple-darwin camp.
[Bug lto/61123] With LTO, -fno-short-enums is ignored, resulting in ABI mis-matching in linking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61123 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- It seems that Tag_ABI_PCS_wchar_t is emitted from the C-family frontends only via config/arm/arm-c.c (as opposed to any other Tags). Probably because the option is c-family specific. This code needs to move to generic handling (the option enum is shared across all frontends, so that's not a reason to keep it in a C specific file).
[Bug fortran/61337] New: Wrong indexing and runtime crash with unlimited polymorphic array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61337 Bug ID: 61337 Summary: Wrong indexing and runtime crash with unlimited polymorphic array. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com module array_list type container class(*), allocatable :: items(:) end type contains subroutine add_item(a, e) type(container),allocatable,intent(inout) :: a(:) class(*),intent(in) :: e(:) type(container),allocatable :: tmp(:) if (.not.allocated(a)) then allocate(a(1)) allocate(a(1)%items(size(e)), source = e) else call move_alloc(a,tmp) allocate(a(size(tmp)+1)) a(1:size(tmp)) = tmp allocate(a(size(tmp)+1)%items(size(e)), source = e) end if end subroutine end module use array_list type(container), allocatable :: a_list(:) call add_item(a_list, [1, 2]) call print(a_list(1)) contains subroutine print(c) type(container), intent(in) :: c if (allocated(c%items)) then select type (x=c%items) type is (integer) print *, x end select end if end subroutine end gfortran-4.9 alist-bug.f90 -fcheck=all -g -fbacktrace ./a.out 2 0 Expected: 1 2 With call add_item(a_list, [1, 2]) call add_item(a_list, [1, 2]) do i = 1, size(a_list) call print(a_list(i)) end do it crashes SIGSEGVs on line: allocate(a(size(tmp)+1)%items(size(e)), source = e) Tested and works on Solaris Studio 12.4. sunf90 alist-bug.f90 ./a.out 1 2 1 2
[Bug lto/61334] [4.10 Regression] lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61334 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- easiest is to avoid using strnlen
[Bug lto/61334] [4.10 Regression] lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61334 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug tree-optimization/61335] [4.10 Regression] wrong code with -O2 -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61335 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-28 Component|middle-end |tree-optimization Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, investigating.
[Bug target/61044] Computed goto on AVR fails to use word-addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61044 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Wed May 28 08:42:25 2014 New Revision: 210999 URL: http://gcc.gnu.org/viewcvs?rev=210999root=gccview=rev Log: PR target/61044 * doc/extend.texi (Local Labels): Note that label differences are not supported for AVR. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug target/61044] Computed goto on AVR fails to use word-addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61044 --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Wed May 28 08:44:23 2014 New Revision: 211000 URL: http://gcc.gnu.org/viewcvs?rev=211000root=gccview=rev Log: PR target/61044 * doc/extend.texi (Local Labels): Note that label differences are not supported for AVR. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/doc/extend.texi
[Bug tree-optimization/61335] [4.10 Regression] wrong code with -O2 -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61335 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Wow, really old serious bug in VRP.
[Bug target/61044] Computed goto on AVR fails to use word-addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61044 --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Wed May 28 08:48:03 2014 New Revision: 211001 URL: http://gcc.gnu.org/viewcvs?rev=211001root=gccview=rev Log: PR target/61044 * doc/extend.texi (Local Labels): Note that label differences are not supported for AVR. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/doc/extend.texi
[Bug target/61044] Computed goto on AVR fails to use word-addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61044 --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Wed May 28 08:50:18 2014 New Revision: 211002 URL: http://gcc.gnu.org/viewcvs?rev=211002root=gccview=rev Log: PR target/61044 * doc/extend.texi (Local Labels): Note that label differences are not supported for AVR. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/doc/extend.texi
[Bug tree-optimization/61335] [4.10 Regression] wrong code with -O2 -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61335 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32870 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32870action=edit patch
[Bug target/61044] Computed goto on AVR fails to use word-addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61044 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Target Milestone|--- |4.9.1 --- Comment #8 from Georg-Johann Lay gjl at gcc dot gnu.org --- Closed as INVALID after adding a note to the manual that label differences are not supported for AVR.
[Bug tree-optimization/61338] New: too many permutation in a vectorized reverse loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61338
Bug ID: 61338
Summary: too many permutation in a vectorized reverse loop
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
in this example gcc generates 4 permutations for foo (while none is required)
On the positive side the code for bar (which is a more realistic use case)
seems optimal.
float x[1024];
float y[1024];
float z[1024];
void foo() {
for (int i=0; i512; ++i)
x[1023-i] += y[1023-i]*z[512-i];
}
void bar() {
for (int i=0; i512; ++i)
x[1023-i] += y[i]*z[i+512];
}
c++ -Ofast -march=haswell -S revloop.cc; cat revloop.s
__Z3foov:
LFB0:
vmovdqaLC0(%rip), %ymm2
xorl%eax, %eax
leaq4064+_x(%rip), %rdx
leaq4064+_y(%rip), %rsi
leaq2020+_z(%rip), %rcx
.align 4,0x90
L2:
vpermd(%rdx,%rax), %ymm2, %ymm0
vpermd(%rcx,%rax), %ymm2, %ymm1
vpermd(%rsi,%rax), %ymm2, %ymm3
vfmadd231ps%ymm1, %ymm3, %ymm0
vpermd%ymm0, %ymm2, %ymm0
vmovaps%ymm0, (%rdx,%rax)
subq$32, %rax
cmpq$-2048, %rax
jneL2
vzeroupper
ret
LFE0:
.section __TEXT,__text_cold,regular,pure_instructions
LCOLDE1:
.text
LHOTE1:
.section __TEXT,__text_cold,regular,pure_instructions
LCOLDB2:
.text
LHOTB2:
.align 4,0x90
.globl __Z3barv
__Z3barv:
LFB1:
vmovdqaLC0(%rip), %ymm1
leaq2048+_z(%rip), %rdx
leaq_y(%rip), %rcx
leaq4064+_x(%rip), %rax
leaq4096+_z(%rip), %rsi
.align 4,0x90
L6:
vmovaps(%rdx), %ymm2
addq$32, %rdx
vpermd(%rax), %ymm1, %ymm0
addq$32, %rcx
vfmadd231ps-32(%rcx), %ymm2, %ymm0
subq$32, %rax
vpermd%ymm0, %ymm1, %ymm0
vmovaps%ymm0, 32(%rax)
cmpq%rsi, %rdx
jneL6
vzeroupper
ret
LFE1:
[Bug lto/61334] [4.10 Regression] lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61334 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-28 CC||tschwinge at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Patch posted at https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02396.html; please test.
[Bug tree-optimization/61338] too many permutation in a vectorized reverse loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61338
--- Comment #1 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
if I write it reverse
void foo2() {
for (int i=511; i=0; --i)
x[1023-i] += y[1023-i]*z[512-i];
}
its ok
__Z4foo2v:
LFB1:
leaq2048+_x(%rip), %rdx
xorl%eax, %eax
leaq4+_z(%rip), %rsi
leaq2048+_y(%rip), %rcx
.align 4,0x90
L6:
vmovaps(%rdx,%rax), %ymm1
vmovups(%rsi,%rax), %ymm0
vfmadd132ps(%rcx,%rax), %ymm1, %ymm0
vmovaps%ymm0, (%rdx,%rax)
addq$32, %rax
cmpq$2048, %rax
jneL6
vzeroupper
ret
[Bug c/61339] New: wide-int.h: 3 * mismatched tags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61339 Bug ID: 61339 Summary: wide-int.h: 3 * mismatched tags Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com 1. ../../src/trunk/gcc/wide-int.h:987:1: warning: 'wide_int_storage' defined as a class here but previously declared as a struct [-Wmismatched-tags] $ fgrep -n wide_int_storage *.h | egrep class|struct wide-int.h:287:struct wide_int_storage; wide-int.h:987:class GTY(()) wide_int_storage 2. ../../src/trunk/gcc/wide-int.h:639:1: warning: 'generic_wide_int' defined as a class template here but previously declared as a struct template [-Wmismatched-tags] $ fgrep -n generic_wide_int *.h *.c | egrep class|struct wide-int.h:285:template typename T struct generic_wide_int; wide-int.h:639:class GTY(()) generic_wide_int : public storage 3. ../../src/trunk/gcc/wide-int.h:1127:1: warning: 'fixed_wide_int_storage' defined as a class template here but previously declared as a struct template [-Wmismatched-tags] $ fgrep -n fixed_wide_int_storage *.h *.c | egrep class|struct wide-int.h:286:template int N struct fixed_wide_int_storage; wide-int.h:1127:class GTY(()) fixed_wide_int_storage
[Bug c/61340] New: ipa-pure-const.c, ipa-reference.c: possible missing switch cases ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61340 Bug ID: 61340 Summary: ipa-pure-const.c, ipa-reference.c: possible missing switch cases ? Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com 1. trunk/gcc/ipa-pure-const.c:1270:16: warning: enumeration value 'IPA_REF_ALIAS' not handled in switch [-Wswitch] Source code is switch (ref-use) Some code to deal with the IPA_REF_ALIAS might be a good idea. 2. trunk/gcc/ipa-reference.c:474:15: warning: enumeration value 'IPA_REF_ALIAS' not handled in switch [-Wswitch] Source code is switch (ref-use)
[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152 --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Wed May 28 09:33:04 2014 New Revision: 211004 URL: http://gcc.gnu.org/viewcvs?rev=211004root=gccview=rev Log: gcc/ PR libgcc/61152 * config/dbx.h (License): Add Runtime Library Exception. * config/newlib-stdint.h (License): Same. * config/rtems.h (License): Same * config/initfini-array.h (License): Same * config/v850/v850.h (License): Same. * config/v850/v850-opts.h (License): Same * config/v850/rtems.h (License): Same. Modified: trunk/gcc/ChangeLog trunk/gcc/config/dbx.h trunk/gcc/config/initfini-array.h trunk/gcc/config/newlib-stdint.h trunk/gcc/config/rtems.h trunk/gcc/config/v850/rtems.h trunk/gcc/config/v850/v850-opts.h trunk/gcc/config/v850/v850.h
[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152 --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Wed May 28 09:35:19 2014 New Revision: 211005 URL: http://gcc.gnu.org/viewcvs?rev=211005root=gccview=rev Log: gcc/ PR libgcc/61152 * config/dbx.h (License): Add Runtime Library Exception. * config/newlib-stdint.h (License): Same. * config/rtems.h (License): Same * config/initfini-array.h (License): Same * config/v850/v850.h (License): Same. * config/v850/v850-opts.h (License): Same * config/v850/rtems.h (License): Same. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/dbx.h branches/gcc-4_9-branch/gcc/config/initfini-array.h branches/gcc-4_9-branch/gcc/config/newlib-stdint.h branches/gcc-4_9-branch/gcc/config/rtems.h branches/gcc-4_9-branch/gcc/config/v850/rtems.h branches/gcc-4_9-branch/gcc/config/v850/v850-opts.h branches/gcc-4_9-branch/gcc/config/v850/v850.h
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- Some comments: original shell: 1:1.86:2.9 + -Ofast : 1:1.37:1.8 (gcc 4.10.0 r210749). Does this mean that there is a problem with -Ofast and -fopenmp? The Wallclock time are: original shell: 46.49s:25.83s:16.02s + -Ofast : 7.82s:5.72s:4.21s Estimating an Amdahl's law: s+p/n (s serial time, p parallel time, n number of threads), based on n=1 and 2, gives original shell: s= 5.17s, p=41.32s, time for n=4: 15.50s, + -Ofast : s=3.63s, p=4.19s, time for n=4: 4.68s. This crude estimate shows that the serial time is only slightly improved with -Ofast while the parallel one is an order of magnitude faster with it. Could you give the Wallclock time for the different cases in comment 0?
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- ... (gcc 4.10.0 r210749) ... Forgot to say: Target: x86_64-apple-darwin13, Corei7, 4 cores, 8 threads, 2.8Ghz (turbo 3.8Ghz), cache 8Mb. Note that the turbo mode may make the serial test faster.
[Bug c++/60245] function with using defined parameter not accepted as constexpr parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60245 Florent Hivert florent.hivert at lri dot fr changed: What|Removed |Added Version|4.8.1 |4.9.0 --- Comment #3 from Florent Hivert florent.hivert at lri dot fr --- The problem remains with the newly released gcc 4.9.0. I upgraded the version tag.
[Bug c/61339] wide-int.h: 3 * mismatched tags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61339 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- This is a really stupid warning that only exists because the MS compiler has (or had) a bug that treats 'struct' and 'class' differently. GCC (and Clang) correctly implement the C++ standard which says it doesn't matter.
[Bug c++/60430] static_assert and reference to const/constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60430 Florent Hivert florent.hivert at lri dot fr changed: What|Removed |Added Version|4.8.1 |4.9.0 --- Comment #1 from Florent Hivert florent.hivert at lri dot fr --- The problem remains with the newly released GCC 4.9.0. I've upgraded the tag.
[Bug c++/60967] ICE with range for in template function with C++11 and cilkplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60967 --- Comment #1 from Florent Hivert florent.hivert at lri dot fr --- The problem doesn't occur anymore with the released version (I was using the cilkplus branch development version). Should this be closed as invalid or should someone find if there is a duplicate ?
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Note, libgomp is optimized for Linux futexes, it has bare support for other targets, so unless somebody steps up and submits and maintains a port for other OSes, those will keep using pthread_* APIs with no particular performance work. So, if you want to do any benchmarking, do it on Linux, not on darwin. Also, benchmarking -O0 code is weird. The benchmark looks prehistoric too, even OpenMP 3.1 has min/max reductions.
[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr --- BTW, having a user-base without developers coming out of that user-base is useless. If no one from apple-darwin is interested in developing GCC, then it doesn't matter how big the user base is: GCC for apple-darwin will not get developed by magic gnomes (or by people that don't even own Apple hardware). So perhaps it would be in your own interest to do a bit of recruiting in the apple-darwin camp. In my paranoid days I have the feeling that I don't exist on the gcc lists!-(although I am only interested by gfortran and optimization, I do what I can to keep the test suite as clean as possible for darwin: bug reports, debugging when I can, ...). Iain Sandoe may have a similar feeling too, even if he has a significant contribution in fixing darwin problem. I also acknowledge that most of the GCC developers are quite helpful and that some of them consider their duty to fix their bugs even on darwin. However I consider that comments such that darwin is broken by design, darwin sucks, ... are unprofessional. Last thing I want to say, I have seen several bugs blamed to drawing that were gcc bugs and also several unfixable on darwin features that got fixed by gcc improvements.
[Bug c++/61341] New: internal compiler error: in tsubst, at cp/pt.c:11313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61341
Bug ID: 61341
Summary: internal compiler error: in tsubst, at cp/pt.c:11313
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
GCC 4.8.2
templatetypename ...T /* 1 */
struct X
{
};
templatetypename T
struct XXT, XT/* 2 */
{
T i;
};
templatetypename ...T
struct XXT, T.. /* 3 */
{
const int static value = sizeof...(T);
};
templateint
struct Y
{
};
template
struct Y2
{
const static int value;
};
int main(int ARGC, char *ARGV[])
{
//Xint, int xii; // 1
//xii.i; // error
//XXint, Xint xxixi; // 2
//xxixi.i; // ok
YXXint, int, double, Xdouble, int, double ::value::value;
}
[Bug tree-optimization/61338] too many permutation in a vectorized reverse loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61338
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-05-28
Blocks||53947
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Confirmed. We fail to detect that all DRs are accessed reverse which is the
case where we can drop the permutes. We also fail to reverse the
positive vectors if they happen to be lower in number:
float x[1024];
float y[1024];
float z[1024];
void foo() {
for (int i=0; i512; ++i)
x[i] += y[1023-i]*z[512-i];
}
produces
.L2:
vpermd (%rdx), %ymm1, %ymm0
subq$32, %rdx
vpermd (%rcx), %ymm1, %ymm2
addq$32, %rax
vfmadd213ps -32(%rax), %ymm2, %ymm0
subq$32, %rcx
vmovaps %ymm0, -32(%rax)
cmpq$z-28, %rdx
jne .L2
instead of permuting the result before storing it.
[Bug c++/61341] internal compiler error: in tsubst, at cp/pt.c:11313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61341
--- Comment #1 from Ivan Sorokin vanyacpp at gmail dot com ---
Reduced case:
templateclass ...T
struct X
{};
templateclass ...T
void foo(XT, T.. a);
void test()
{
foo(Xint, int, double(), Xdouble, int, double());
}
[Bug c/61339] add mismatch between struct and class to non-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61339 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-28 CC||manu at gcc dot gnu.org Summary|wide-int.h: 3 * mismatched |add mismatch between struct |tags|and class to non-bugs Ever confirmed|0 |1 Severity|minor |enhancement --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #1) This is a really stupid warning that only exists because the MS compiler has (or had) a bug that treats 'struct' and 'class' differently. GCC (and Clang) correctly implement the C++ standard which says it doesn't matter. I don't think patches that fix the mismatch will be rejected, but also don't expect someone else to care enough to write them and submit them. On the other hand, it would be handy to keep this around as a reminder to add this to the list of non-bugs for future reference: https://gcc.gnu.org/bugs/#nonbugs And also in case someone is actually interested in adding this warning (perhaps it could be enabled by -fms-extensions).
[Bug c/61340] ipa-pure-const.c, ipa-reference.c: possible missing switch cases ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61340 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to David Binderman from comment #0) 1. trunk/gcc/ipa-pure-const.c:1270:16: warning: enumeration value 'IPA_REF_ALIAS' not handled in switch [-Wswitch] Source code is switch (ref-use) Some code to deal with the IPA_REF_ALIAS might be a good idea. 2. trunk/gcc/ipa-reference.c:474:15: warning: enumeration value 'IPA_REF_ALIAS' not handled in switch [-Wswitch] Source code is switch (ref-use) GCC's -Wswitch does not catch this?
[Bug tree-optimization/61335] [4.10 Regression] wrong code with -O2 -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61335 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed May 28 11:07:06 2014 New Revision: 211012 URL: http://gcc.gnu.org/viewcvs?rev=211012root=gccview=rev Log: 2014-05-28 Richard Biener rguent...@suse.de PR tree-optimization/61335 * tree-vrp.c (vrp_visit_phi_node): If the compare of old and new range fails, drop to varying. * gfortran.dg/pr61335.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr61335.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug middle-end/61045] [4.7/4.8/4.9/4.10 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61045 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- /* Put the constant on the side where it doesn't overflow and is of lower absolute value than before. */ cst = int_const_binop (TREE_CODE (arg0) == TREE_CODE (arg1) ? MINUS_EXPR : PLUS_EXPR, const2, const1); if (!TREE_OVERFLOW (cst) tree_int_cst_compare (const2, cst) == tree_int_cst_sgn (const2)) const2 is -1 here and cst is 1. So that means just checking for lower absolute value is wrong. A sign-change is obviously not ok either.
[Bug c/61342] New: Segfault when using default clause and VLA in OpenMP task
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61342
Bug ID: 61342
Summary: Segfault when using default clause and VLA in OpenMP
task
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: philippe.virouleau at imag dot fr
Created attachment 32871
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32871action=edit
produced output
I got a segmentation fault from gcc when compiling a code using variable length
array inside an open mp task, with default(none) specified.
The minimal example that triggers the segfault with my gcc is the following :
int main()
{
int x = 2;
int y = 2;
double f_[2][2];
double (*f)[x][y] = (double (*)[x][y])f_;
#pragma omp parallel
#pragma omp master
{
for (int i = 0; i x; i++)
for (int j = 0; j y; j++)
#pragma omp task default(none) shared(f) firstprivate(i, j)
{
(*f)[i][j] = 1;
}
}
}
Attached is the is the produced stacktrace (with command line and gcc version),
and my operating system is Debian (Linux daisy 3.14-1-amd64 #1 SMP Debian
3.14.4-1 (2014-05-13) x86_64 GNU/Linux).
Note that removing the default(none) makes the code compile normally
[Bug tree-optimization/61335] [4.10 Regression] wrong code with -O2 -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61335 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #13) In my paranoid days I have the feeling that I don't exist on the gcc lists!-(although I am only interested by gfortran and optimization, I do what I can to keep the test suite as clean as possible for darwin: bug reports, debugging when I can, ...). Iain Sandoe may have a similar feeling too, even if he has a significant contribution in fixing darwin problem. Why is that so? Do you mean your patches aren't reviewed fast enough? There are three darwin maintainers. If you are unsatisfied with their work, I would suggest to try to approach them in private. Perhaps they will be happy to delegate some maintainership duties or suggest some way to improve communication. Patches going unreviewed is a general problem in GCC not restricted to Darwin. Nobody has found a good solution to this problem yet. I also acknowledge that most of the GCC developers are quite helpful and that some of them consider their duty to fix their bugs even on darwin. However I consider that comments such that darwin is broken by design, darwin sucks, ... are unprofessional. So ignore those comments. Even smart people say stupid things from time to time. Many people that write in the GCC lists (or bug reports) don't even contribute to GCC. When I started working on GCC diagnostics, many GCC devs told me that there will never be native color diagnostics. Now we have colors and the Apocalypse hasn't arrived. See also points 1 and 9 at https://gcc.gnu.org/wiki/GCC_Research about negative feedback. I think the approach of FX was exactly right: Expose your case and send a patch. If you cannot convince someone, then convince others. Last thing I want to say, I have seen several bugs blamed to drawing that were gcc bugs and also several unfixable on darwin features that got fixed by gcc improvements. Sure. I personally think that GCC is better off supporting Darwin than not, but I wouldn't personally work on Darwin since I only care about Linux. It is only logical that people using Darwin are the ones working on it. The quality of Darwin support in GCC is only a function of the number of people working on it, not a hidden agenda, design or philosophy. (The same is true for every other language or port or part of the compiler. The only reason why Clang has better diagnostics than GCC is that there were 191 contributors to Clang last year, while I would be surprised if more than 20 people contributed to the C/C++ FEs during the same time.)
[Bug other/61300] powerpc64le miscompile with KR-style function definition at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Alan Modra from comment #1) So, the writes way past this is writing into the parameter save area. compare_kr is assuming that it was called with a parameter save area because it isn't prototyped, but that is quite wrong because when compiling the function body we don't know how the function was called. A call may well have a prototype in scope, and thus not set up a parameter save area. It's a bug in rs6000_function_parms_need_stack. This function can't blindly test !prototype_p (fun). So you can simply drop that check instead as it seems to be an optimization only? Thus Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 211011) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -10492,7 +10492,7 @@ rs6000_function_parms_need_stack (tree f fun = TREE_TYPE (fun); /* Varargs functions need the parameter save area. */ - if (!prototype_p (fun) || stdarg_p (fun)) + if (stdarg_p (fun)) return true; INIT_CUMULATIVE_INCOMING_ARGS (args_so_far_v, fun, NULL_RTX); ?
[Bug lto/61256] [4.10 regression] Building spec2000/252.eon with LTO got a compfail after r210522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61256 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/61306] [4.10 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61306 --- Comment #4 from Thomas Preud'homme thomas.preudhomme at arm dot com --- I finally managed to find the root cause for the bootstrap failure with my current fix. I shall be able to improve my fix and should hopefully be ready tomorrow.
[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-28 Ever confirmed|0 |1 --- Comment #6 from Marc Glisse glisse at gcc dot gnu.org --- With current trunk, for the vector version, the most obvious optimization failure is the following: _57 = (unsigned long) MEM[(void *)._79 + 12B]; _36 = (unsigned long) MEM[(void *)._79 + 4B]; _51 = _57 - _36; _3 = _51 /[ex] 4; _26 = _3; _27 = _26 + 1; _31 = _27 * 4; etc. _51 should be folded to 8 (then we have the usual useless /4*4, but with a constant it would be ok). This part is a 4.9/4.10 regression, gcc-4.8 managed to get the constant 12: __builtin_memcpy (_33, ._80, 12);
[Bug other/61300] powerpc64le miscompile with KR-style function definition at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300 --- Comment #4 from Alan Modra amodra at gmail dot com --- You could do that, but smaller stack frames is one of the nice features of the ELFv2 ABI! What I called the quick and dirty fix seems to be the way to go, as the scheme I had in mind to avoid a new INCOMING_REG_PARM_STACK_SPACE target macro only works with very old versions of gcc.. See https://gcc.gnu.org/ml/gcc/2014-05/msg00302.html
[Bug c/61340] ipa-pure-const.c, ipa-reference.c: possible missing switch cases ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61340 --- Comment #2 from David Binderman dcb314 at hotmail dot com --- (In reply to Manuel López-Ibáñez from comment #1) GCC's -Wswitch does not catch this? On checking the gcc trunk build logs, yes. Only clang can find the problem, not trunk gcc. I had a look in gcc/testsuite/ for a file that clang can find the problem in, but trunk gcc can't. The first one is gcc.c-torture/compile/pr39845.c This might be worth a deeper look.
[Bug sanitizer/61314] Building GCC 4.9.0 breaks in libbacktrace on Ubuntu Lucid and Precise using libfaketime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61314 Georg Koppen gk at torproject dot org changed: What|Removed |Added Summary|Building GCC 4.9.0 breaks |Building GCC 4.9.0 breaks |in libbacktrace on Ubuntu |in libbacktrace on Ubuntu |Lucid Lynx |Lucid and Precise using ||libfaketime --- Comment #3 from Georg Koppen gk at torproject dot org --- I made some more tests. Building on UbuntuPrecise is breaking as well with a similar error while compiling 4.9.0 and not faking timestamps with libfaketime works both on Lucid and Precise. This seems to support my analysis in comment 2.
[Bug middle-end/61045] [4.7/4.8/4.9/4.10 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61045 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed May 28 12:44:11 2014 New Revision: 211018 URL: http://gcc.gnu.org/viewcvs?rev=211018root=gccview=rev Log: 2014-05-28 Richard Biener rguent...@suse.de PR middle-end/61045 * fold-const.c (fold_comparison): When folding X +- C1 CMP Y +- C2 to X CMP Y +- C2 +- C1 also ensure the sign of the remaining constant operand stays the same. * gcc.dg/pr61045.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr61045.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/61045] [4.7/4.8/4.9/4.10 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61045 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed May 28 12:46:39 2014 New Revision: 211019 URL: http://gcc.gnu.org/viewcvs?rev=211019root=gccview=rev Log: 2014-05-28 Richard Biener rguent...@suse.de Backport from mainline 2014-05-28 Richard Biener rguent...@suse.de PR middle-end/61045 * fold-const.c (fold_comparison): When folding X +- C1 CMP Y +- C2 to X CMP Y +- C2 +- C1 also ensure the sign of the remaining constant operand stays the same. * gcc.dg/pr61045.c: New testcase. 2014-05-05 Richard Biener rguent...@suse.de PR middle-end/61010 * fold-const.c (fold_binary_loc): Consistently avoid canonicalizing X CST away from a CST that is the mask of a mode. * gcc.dg/torture/pr61010.c: New testcase. 2014-04-28 Richard Biener rguent...@suse.de PR tree-optimization/60979 * graphite-scop-detection.c (scopdet_basic_block_info): Reject SCOPs that end in a block with a successor with abnormal predecessors. * gcc.dg/graphite/pr60979.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/graphite/pr60979.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr61045.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr61010.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/fold-const.c branches/gcc-4_9-branch/gcc/graphite-scop-detection.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/60979] [4.9 Regression] ICE: in gimple_redirect_edge_and_branch_force, at tree-cfg.c:5544, w/ -O -ftree-loop-linear or -fgraphite-identity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60979 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/60979] [4.9 Regression] ICE: in gimple_redirect_edge_and_branch_force, at tree-cfg.c:5544, w/ -O -ftree-loop-linear or -fgraphite-identity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60979 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed May 28 12:46:39 2014 New Revision: 211019 URL: http://gcc.gnu.org/viewcvs?rev=211019root=gccview=rev Log: 2014-05-28 Richard Biener rguent...@suse.de Backport from mainline 2014-05-28 Richard Biener rguent...@suse.de PR middle-end/61045 * fold-const.c (fold_comparison): When folding X +- C1 CMP Y +- C2 to X CMP Y +- C2 +- C1 also ensure the sign of the remaining constant operand stays the same. * gcc.dg/pr61045.c: New testcase. 2014-05-05 Richard Biener rguent...@suse.de PR middle-end/61010 * fold-const.c (fold_binary_loc): Consistently avoid canonicalizing X CST away from a CST that is the mask of a mode. * gcc.dg/torture/pr61010.c: New testcase. 2014-04-28 Richard Biener rguent...@suse.de PR tree-optimization/60979 * graphite-scop-detection.c (scopdet_basic_block_info): Reject SCOPs that end in a block with a successor with abnormal predecessors. * gcc.dg/graphite/pr60979.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/graphite/pr60979.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr61045.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr61010.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/fold-const.c branches/gcc-4_9-branch/gcc/graphite-scop-detection.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/61010] [4.8 Regression] Infinite recursion in fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed May 28 12:46:39 2014 New Revision: 211019 URL: http://gcc.gnu.org/viewcvs?rev=211019root=gccview=rev Log: 2014-05-28 Richard Biener rguent...@suse.de Backport from mainline 2014-05-28 Richard Biener rguent...@suse.de PR middle-end/61045 * fold-const.c (fold_comparison): When folding X +- C1 CMP Y +- C2 to X CMP Y +- C2 +- C1 also ensure the sign of the remaining constant operand stays the same. * gcc.dg/pr61045.c: New testcase. 2014-05-05 Richard Biener rguent...@suse.de PR middle-end/61010 * fold-const.c (fold_binary_loc): Consistently avoid canonicalizing X CST away from a CST that is the mask of a mode. * gcc.dg/torture/pr61010.c: New testcase. 2014-04-28 Richard Biener rguent...@suse.de PR tree-optimization/60979 * graphite-scop-detection.c (scopdet_basic_block_info): Reject SCOPs that end in a block with a successor with abnormal predecessors. * gcc.dg/graphite/pr60979.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/graphite/pr60979.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr61045.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr61010.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/fold-const.c branches/gcc-4_9-branch/gcc/graphite-scop-detection.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug other/61300] powerpc64le miscompile with KR-style function definition at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300 --- Comment #5 from Alan Modra amodra at gmail dot com --- Actually, to work the patch in comment #3 would need to be - if (!prototype_p (fun) || stdarg_p (fun)) + if (1) return true;
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 --- Comment #11 from Jack Howarth howarth.at.gcc at gmail dot com --- (In reply to Jakub Jelinek from comment #10) Also, benchmarking -O0 code is weird. Is gcc really optimizing that low by default? Certainly it is at least doing -O1 when not passed a -O* optimization flag? In any case, shouldn't the optimization be somewhat orthogonal to this problem since, by normalizing to the one process timing, we are just looking at the effect of the overhead in the processes?
[Bug c++/61343] New: [C++11] Missing default initialization for class with default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61343
Bug ID: 61343
Summary: [C++11] Missing default initialization for class with
default constructor
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tejohnson at google dot com
The following test case does not call the default constructor when expected:
/
#include iostream
struct Foo {
int value;
Foo() noexcept {
std::cout this constructed. Setting value to twelve.\n;
value = 12;
}
};
static thread_local Foo a{};
static thread_local Foo b;
static __attribute__((noinline)) void UseA() {
const int value = a.value;
std::cout Value of A: value \n;
}
static __attribute__((noinline)) void UseB() {
const int value = b.value;
std::cout Value of B: value \n;
}
int main(int argc, char** argv) {
// std::cout Address of A: a \n;
// std::cout Address of B: b \n;
UseA();
UseA();
UseB();
UseB();
UseA();
UseA();
return 0;
}
//
When compiled with the current trunk compiler it gives the output:
Value of A: 0
Value of A: 0
0x7f2bc9150728 constructed. Setting value to twelve.
0x7f2bc9150724 constructed. Setting value to twelve.
Value of B: 12
Value of B: 12
Value of A: 12
Value of A: 12
I would expect something like:
0x7ffa4bc63720 constructed. Setting value to twelve.
0x7ffa4bc63724 constructed. Setting value to twelve.
Value of A: 12
Value of A: 12
Value of B: 12
Value of B: 12
Value of A: 12
Value of A: 12
It appears as though the empty brace initialization for 'a', which should
result in the user-defined default constructor being invoked, does not actually
do so. Instead the object is zero-initialized until accessing 'b', which
finally causes the default constructor for 'a' to be run as well.
Google ref: b/15250505
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is gcc really optimizing that low by default? ... AFAIK the default optimization in gcc is -O0. Now before drawing conclusions you should answer my question in comment 8.
[Bug pch/60982] Very long compilation of precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60982 Yuriy Chernyshov georgthegreat at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Yuriy Chernyshov georgthegreat at gmail dot com --- Hi! According to my what my system administrator told to be, it is impossible to build GCC-4.6 and higher due to kernel incompatibility. I'll close this as invalid.
[Bug c++/60430] static_assert and reference to const/constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60430 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Version|4.9.0 |4.8.1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- THere's no need to update the version - if the bug is still open t hat means it's still a bug in later versions, and by changing it you've lost the information that the bug is present in 4.8
[Bug c/61328] valgrind finds problem in find_bswap_or_nop_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61328 --- Comment #3 from David Binderman dcb314 at hotmail dot com --- (In reply to David Binderman from comment #0) Maybe if (!source_expr2) return NULL_TREE; if (n1.size != n2.size) return NULL_TREE; would be better code. I tried out my proposed solution and it didn't seem to help. Current working assumption is that something somewhere isn't setting the size field. Maybe blindly zeroing out the entire struct might be a way forward.
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 --- Comment #13 from Jack Howarth howarth.at.gcc at gmail dot com --- (In reply to Dominique d'Humieres from comment #12) Is gcc really optimizing that low by default? ... AFAIK the default optimization in gcc is -O0. Now before drawing conclusions you should answer my question in comment 8. Without optimization flags on a 16-core MacPro under darwin13, the timings for one, two and four OMP processes are… clang-3.4.1 (clang-omp/openmp) 82.913658 sec: 41.704652 sec: 22.256563 sec gcc 4.8.3 96.409755 sec: 50.521193 sec: 28.822280 sec gcc 4.9.0 96.341129 sec: 50.563898 sec: 28.850048 sec at -O1 clang-3.4.1 (clang-omp/openmp) 19.371284 sec: 9.743520 sec: 5.938325 sec gcc 4.8.3 38.253825 sec: 21.149855 sec: 13.426259 sec gcc 4.9.0 38.170274 sec: 21.022076 sec: 13.402209 sec at -O2 clang-3.4.1 (clang-omp/openmp) 15.621070 sec: 7.890557 sec: 5.384909 sec gcc 4.8.3 18.473835 sec: 11.278842 sec: 8.954324 sec gcc 4.9.0 18.468089 sec: 11.208950 sec: 8.949956 sec at -O3 clang-3.4.1 (clang-omp/openmp) 15.627173 sec: 8.073639 sec: 5.870642 sec gcc 4.8.3 18.535541 sec: 11.258917 sec: 8.951850 sec gcc 4.9.0 17.088016 sec: 10.685973 sec: 8.884664 sec at -Os clang-3.4.1 (clang-omp/openmp) 19.365366 sec: 9.732779 sec: 5.360228 sec gcc 4.8.3 19.523171 sec: 11.657896 sec: 8.993581 sec gcc 4.9.0 18.472308 sec: 11.224615 sec: 8.959600 sec at -Ofast clang-3.4.1 (clang-omp/openmp) 12.533942 sec: 6.371977 sec: 5.358282 sec gcc 4.8.3 15.593206 sec: 9.804462 sec: 8.581757 sec gcc 4.9.0 14.145020 sec: 9.089317 sec: 8.449206 sec
[Bug ipa/61160] [4.9/4.10 Regression] wrong code with -O3 (or ICE: verify_cgraph_node failed: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- This seems to be IPA-CP related, so I will have a look.
[Bug rtl-optimization/61325] [4.10 regression] aarch64_be build fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61325 Vladimir Makarov vmakarov at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org --- The patch for PR60969 just triggered a bug. Process_address in lea-constraints.c just did one transformation ind * scale + base + dips = base2 = base + dips, ind * scale + base2. The new address is still illegal as we changed memory mode from DI to QI and scale is still 4. So we need to do more one transformation. I hope to make a patch and commit it tomorrow.
[Bug c++/61242] [4.9/4.10 Regression] Bogus no matching function for call to ‘Foo::Create(brace-enclosed initializer list)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61242 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed May 28 15:55:03 2014 New Revision: 211024 URL: http://gcc.gnu.org/viewcvs?rev=211024root=gccview=rev Log: PR c++/61242 * call.c (build_aggr_conv): Ignore passed in flags. (build_array_conv, build_complex_conv): Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist84.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/57543] decltype needs explicit 'this' pointer in member function declaration of template class with trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57543 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org
[Bug c++/61343] [C++11] Missing default initialization for class with default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61343 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-28 Ever confirmed|0 |1
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Alternative patch committed to trunk. Fixed.
[Bug c++/47202] Endless recursion during mangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47202 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed May 28 16:38:23 2014 New Revision: 211026 URL: http://gcc.gnu.org/viewcvs?rev=211026root=gccview=rev Log: PR c++/47202 gcc/cp/ * decl.c (cxx_comdat_group): Return a decl. * optimize.c (cdtor_comdat_group): Get its DECL_ASSEMBLER_NAME. gcc/ * cgraph.h (symtab_node::get_comdat_group_id): New. * cgraphunit.c (analyze_functions): Call it. * symtab.c (dump_symtab_node): Likewise. * tree.c (decl_comdat_group_id): New. * tree.h: Declare it. * lto-streamer-out.c (write_symbol): Use it. * trans-mem.c (ipa_tm_create_version_alias): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h trunk/gcc/cgraphunit.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/mangle.c trunk/gcc/cp/optimize.c trunk/gcc/lto-streamer-out.c trunk/gcc/symtab.c trunk/gcc/trans-mem.c trunk/gcc/tree.c trunk/gcc/tree.h
[Bug c++/47202] Endless recursion during mangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47202 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Fixed on trunk; we now complain about excessive recursion.
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #9 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Thanks.
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- It is fixed, isn't it?
[Bug target/61336] ICE on alpha: in print_operand_address, at config/alpha/alpha.c:5454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61336 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||rth at gcc dot gnu.org, ||ubizjak at gmail dot com --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- The problem here is, that some inline asm tries to print the symbol name using offsetable memory constraint. This generates: (gdb) p debug_rtx (insn) (insn:TI 58 57 59 (asm_operands/v (990: nop .pushsection .note.stapsdt,?,note .balign 4 .4byte 992f-991f,994f-993f,3 991: .asciz stapsdt 992: .balign 4 993: .8byte 990b .8byte _.stapsdt.base .8byte 0 .asciz libc .asciz memory_mallopt_mxfast .asciz %n0@%1 %n2@%3 994: .balign 4 .popsection ) () 0 [ (const_int 4 [0x4]) (reg:SI 11 $11 [orig:103 value ] [103]) (const_int -8 [0xfff8]) (mem/c:DI (symbol_ref:DI (global_max_fast) [flags 0x6] var_decl 0x2eaf430 global_max_fast) [5 global_max_fast+0 S8 A64]) ] [ (asm_input:SI (n) malloc.c:4764) (asm_input:SI (nor) malloc.c:4764) (asm_input:SI (n) malloc.c:4764) (asm_input:DI (nor) malloc.c:4764) ] [] malloc.c:4764) malloc.c:4764 -1 (nil)) $15 = void which in fact contains invalid unsplit symbol reference to global_max_fast. So, we can either allow unsplit symbol references using following patch: --cut here-- Index: alpha.c === --- alpha.c (revision 210950) +++ alpha.c (working copy) @@ -5450,7 +5450,6 @@ print_operand_address (FILE *file, rtx addr) offset = INTVAL (addr); break; -#if TARGET_ABI_OPEN_VMS case SYMBOL_REF: fprintf (file, %s, XSTR (addr, 0)); return; @@ -5463,7 +5462,6 @@ print_operand_address (FILE *file, rtx addr) INTVAL (XEXP (XEXP (addr, 0), 1))); return; -#endif default: gcc_unreachable (); } --cut here-- or your souce should be fixed to avoid memory operands in inline asm.
[Bug c++/57543] decltype needs explicit 'this' pointer in member function declaration of template class with trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57543 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Looking a bit more into it.
[Bug fortran/61337] Wrong indexing and runtime crash with unlimited polymorphic array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61337 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-28 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed on 4.8 up to trunk. If the first test is compiled with -fsanitize=address, execution fails with ==63209==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000105f54d28 at pc 0x105f5433c bp 0x7fff59cb0150 sp 0x7fff59cb0148 READ of size 4 at 0x000105f54d28 thread T0 #0 0x105f5433b (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1533b) #1 0x105f51a56 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x12a56) #2 0x105f544dc (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x154dc) #3 0x105f54883 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x15883) #4 0x7fff8edb75fc (/usr/lib/system/libdyld.dylib+0x35fc) 0x000105f54d28 is located 0 bytes to the right of global variable 'A.21' from 'pr61337.f90' (0x105f54d20) of size 8 0x000105f54d28 is located 56 bytes to the left of global variable 'options.23' from 'pr61337.f90' (0x105f54d60) of size 36 ... The modified case (call add_item twice) fails with ==63217==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0001084c0ce8 at pc 0x1084c0112 bp 0x7fff57744130 sp 0x7fff57744128 READ of size 4 at 0x0001084c0ce8 thread T0 #0 0x1084c0111 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x15111) #1 0x1084bd82c (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1282c) #2 0x1084c02b4 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x152b4) #3 0x1084c07c3 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x157c3) #4 0x7fff8edb75fc (/usr/lib/system/libdyld.dylib+0x35fc) 0x0001084c0ce8 is located 0 bytes to the right of global variable 'A.21' from 'pr61337_1.f90' (0x1084c0ce0) of size 8 0x0001084c0ce8 is located 56 bytes to the left of global variable 'A.24' from 'pr61337_1.f90' (0x1084c0d20) of size 8
[Bug fortran/60853] Failure to disambiguate generic with unlimited polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60853 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-28 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed. The code compiles if I use subroutine copyFromScalar(this, scalar) class (Vector), intent(inout) :: this type (Vector), intent(in) :: scalar end subroutine copyFromScalar subroutine copyFromArray(this, array) class (Vector), intent(inout) :: this class (Vector), intent(in) :: array(:) end subroutine copyFromArray
[Bug fortran/59344] warning for needless pointer attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59344 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||diagnostic Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-28 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Please provide the man power otherwise you'll never get it.
[Bug target/61044] Computed goto on AVR fails to use word-addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61044 --- Comment #9 from Georg-Johann Lay gjl at gcc dot gnu.org --- (In reply to Senthil Kumar Selvaraj from comment #3) The primary reason I added the diff relocs was to prevent linker relaxation messing up DWARF line number information - as you know, relaxation can shorten instruction sequences, and the addresses in DWARF then go out of sync. I guess I must add some user documentation about this, but ideally, this is supposed to be transparent to the user - just passing -mrelax to the compiler should work. I turned diff reloc generation on only if -mlink-relax is passed because this is what other ports (xtensa) do, and I wasn't sure of the consequences of resolving every subtraction expression at link time. Resolving label differences at assemble time serves a faster linking process, but that argument does not apply to avr: We don't have magabytes of code that have to be fixed at load time by a dynamic linker. And you don't know at assemble time how the linker is called. One example is debugging through code that comes from a library and has been linked against the application. It's not very common but possible and yet another plus (besides simplicity with less options and less GCC/Binutils dependency) for always emitting label differences as relocs.
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 --- Comment #14 from Jack Howarth howarth.at.gcc at gmail dot com --- Without optimization flags on a 24-core x86_64 Fedora 15 box, the timings for one, two and four OMP processes are… clang-3.4.0 (clang-omp/openmp) 69.988439 sec: 34.962212 sec: 17.641935 sec gcc 4.6.3 81.324524 sec: 40.878640 sec: 20.741782 sec gcc 4.8 branch svn 80.953598 sec: 40.650732 sec: 20.635248 sec at -O1 clang-3.4.0 (clang-omp/openmp) 16.187348 sec: 8.189783 sec: 4.293277 sec gcc 4.6.3 32.315830 sec: 16.233432 sec: 8.257077 sec gcc 4.8 branch svn 32.292952 sec: 16.270113 sec: 8.258137 sec at -O2 clang-3.4.0 (clang-omp/openmp) 13.463402 sec: 6.690053 sec: 3.570961 sec gcc 4.6.3 15.671699 sec: 7.895216 sec: 4.133647 sec gcc 4.8 branch svn 15.639710 sec: 7.878182 sec: 4.120302 sec at -O3 clang-3.4.0 (clang-omp/openmp) 13.260507 sec: 6.698891 sec: 3.559403 sec gcc 4.6.3 15.947264 sec: 7.991567 sec: 4.158251 sec gcc 4.8 branch svn 15.607232 sec: 7.861177 sec: 4.150581 sec at -Os clang-3.4.0 (clang-omp/openmp) 16.266355 sec: 8.229083 sec: 4.236148 sec gcc 4.6.3 16.921628 sec: 8.539645 sec: 4.447783 sec gcc 4.8 branch svn 15.914723 sec: 8.658947 sec: 4.719782 sec at -Ofast clang-3.4.0 (clang-omp/openmp) 10.822510 sec: 5.500982 sec: 3.484604 sec gcc 4.6.3 13.752500 sec: 6.764537 sec: 3.601730 sec gcc 4.8 branch svn 13.224638 sec: 6.658421 sec: 3.556949 sec
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 --- Comment #11 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Yes, weird, thanks.
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 Jack Howarth howarth.at.gcc at gmail dot com changed: What|Removed |Added CC||howarth.at.gcc at gmail dot com --- Comment #12 from Jack Howarth howarth.at.gcc at gmail dot com --- (In reply to m...@gcc.gnu.org from comment #11) Yes, weird, thanks. A find that gcc trunk at r211023 bootstrap fines against the clang 3.4svn-based compilers from Xcode 5.1.1. However I am still puzzled why, considering that it is agreed that the casts are useless and ignored by gcc, why they weren't just removed? I did find that freebsd has been doing this… http://svnweb.freebsd.org/base/head/contrib/gcc/longlong.h?view=patchr1=211505r2=211504pathrev=211505
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- Because they are not ignored and are not useless.
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 --- Comment #14 from Dominique d'Humieres dominiq at lps dot ens.fr --- Because they are not ignored and are not useless. See https://gcc.gnu.org/ml/gcc/2014-05/msg00332.html.
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 --- Comment #15 from Mike Stump mikestump at comcast dot net --- Short answer, error checking. Remove them and one removes some error checking.
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 --- Comment #16 from Jack Howarth howarth.at.gcc at gmail dot com --- (In reply to Mike Stump from comment #15) Short answer, error checking. Remove them and one removes some error checking. Will the current fix have any impact on our having the complete wide-int functionality on darwin?
[Bug c++/61344] New: Wswitch does not work with enum bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61344
Bug ID: 61344
Summary: Wswitch does not work with enum bitfields
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
For this testcase:
typedef union tree_node *tree;
enum built_in_function { BUILT_IN_ACOS, BUILT_IN_FPCLASSIFY, BUILT_IN_ISFINITE
};
struct tree_function_decl {
__extension__ enum built_in_function function_code : 11;
};
union tree_node {
struct tree_function_decl function_decl;
};
static tree
convert_arguments (tree fundecl)
{
switch (((fundecl)-function_decl.function_code))
{
case BUILT_IN_ISFINITE:
case BUILT_IN_FPCLASSIFY:
return (tree) 0;
}
return fundecl;
}
clang prints:
test.c:12:11: warning: enumeration value 'BUILT_IN_ACOS' not handled in switch
[-Wswitch]
switch (((fundecl)-function_decl.function_code))
^
but gcc does not print anything with -Wswitch.
This is because it is an enum bitfield.
Related to PR53874.
[Bug c/53874] -Wswitch-enum not properly working with bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53874 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-28 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Confirmed. Related to PR61344. Clang does print a warning: test2.c:17:10: warning: enumeration values 'A', 'B', and 'C' not explicitly handled in switch [-Wswitch-enum] switch(bla-my_enum) ^ (and a better warning than gcc, printing three times the same warning is not very nice).
[Bug target/61202] gcc generates invalid sqdmulh instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61202 Carrot carrot at google dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Carrot carrot at google dot com --- (In reply to java4ada from comment #5) Will this bug cover 4.8.x as well? (or file separate bug for 4.8.x) Yes. I have committed the patch to 4.8 branch.
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 --- Comment #17 from Manuel López-Ibáñez manu at gcc dot gnu.org --- The changelog was wrong. This is why bugzilla didn't catch the commit. It should have said: PR bootstrap/61146 instead of PR bootstrap/PR61146 It would be nice to have a commit hook that catches this kind of thing.
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 --- Comment #18 from Dominique d'Humieres dominiq at lps dot ens.fr --- Revision 211023 Author:fxcoudert Date:Wed May 28 15:17:29 2014 UTC (4 hours, 39 minutes ago) Log Message: PR bootstrap/PR61146 * wide-int.cc: Do not include longlong.h when compiling with clang.
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 --- Comment #19 from Mike Stump mikestump at comcast dot net --- Nope.
[Bug rtl-optimization/61345] New: [4.10 Regression] ICE (segfault) in combine while compiling the linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61345
Bug ID: 61345
Summary: [4.10 Regression] ICE (segfault) in combine while
compiling the linux kernel
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target: aarch64*-linux-gnu
Simple Testcase (compiled with -O2):
unsigned grab_cache_page_write_begin(unsigned flags, unsigned capabilities)
{
unsigned gfp_mask;
unsigned gfp_notmask = 0;
gfp_mask = flags ((1 25) - 1);
if (!(capabilities 0x0001))
gfp_mask |= 0x100u;
return (gfp_mask ~gfp_notmask);
}
[Bug rtl-optimization/61345] [4.10 Regression] ICE (segfault) in combine while compiling the linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61345 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-28 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I am going to fix this.
[Bug target/61345] [4.10 Regression] ICE (segfault) in combine while compiling the linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61345 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|rtl-optimization|target --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Turns out it is a target issue: t.c: In function ‘grab_cache_page_write_begin’: t.c:9:1: internal compiler error: Segmentation fault } ^ 0xb87e72 crash_signal /data1/src/gcc-cavium/toolchain-ilp32/scripts/../src/gcc/toplev.c:337 0xeca46f aarch64_rtx_costs /data1/src/gcc-cavium/toolchain-ilp32/scripts/../src/gcc/config/aarch64/aarch64.c:5627 0xecabdf aarch64_rtx_costs_wrapper /data1/src/gcc-cavium/toolchain-ilp32/scripts/../src/gcc/config/aarch64/aarch64.c:5792 0xb1674a rtx_cost(rtx_def*, rtx_code, int, bool) /data1/src/gcc-cavium/toolchain-ilp32/scripts/../src/gcc/rtlanal.c:3878 0xec9adb aarch64_rtx_costs /data1/src/gcc-cavium/toolchain-ilp32/scripts/../src/gcc/config/aarch64/aarch64.c:5367 0xecabdf aarch64_rtx_costs_wrapper /data1/src/gcc-cavium/toolchain-ilp32/scripts/../src/gcc/config/aarch64/aarch64.c:5792 0xb1674a rtx_cost(rtx_def*, rtx_code, int, bool) /data1/src/gcc-cavium/toolchain-ilp32/scripts/../src/gcc/rtlanal.c:3878 0xec99b5 aarch64_rtx_costs /data1/src/gcc-cavium/toolchain-ilp32/scripts/../src/gcc/config/aarch64/aarch64.c:5331 0xecabdf aarch64_rtx_costs_wrapper /data1/src/gcc-cavium/toolchain-ilp32/scripts/../src/gcc/config/aarch64/aarch64.c:5792 0xb1674a rtx_cost(rtx_def*, rtx_code, int, bool) /data1/src/gcc-cavium/toolchain-ilp32/scripts/../src/gcc/rtlanal.c:3878 0x10d0103 set_src_cost /data1/src/gcc-cavium/toolchain-ilp32/scripts/../src/gcc/rtl.h:1565
[Bug target/61345] [4.10 Regression] ICE (segfault) in combine while compiling the linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61345 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Caused by: https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01543.html
[Bug debug/55585] compile time hog at -O1 -fboundscheck -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55585 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-28 Ever confirmed|0 |1 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- On trunk (4.10) r211028, I get [Book15] f90/bug% time gfc pr55585.f90 -fbounds-check -O1 -g -fstrict-aliasing 12.597u 0.169s 0:13.02 97.9%0+0k 89+40io 2600pf+0w [Book15] f90/bug% time gfc pr55585.f90 -fbounds-check -O1 -g 91.778u 0.739s 1:32.54 99.9%0+0k 20+29io 402pf+0w [Book15] f90/bug% time gfc pr55585.f90 -fbounds-check -O1 31.269u 0.320s 0:31.60 99.9%0+0k 3+10io 400pf+0w [Book15] f90/bug% time gfc pr55585.f90 -fbounds-check -O2 13.154u 0.117s 0:13.28 99.8%0+0k 2+14io 250pf+0w [Book15] f90/bug% time gfc pr55585.f90 -fbounds-check 15.805u 0.329s 0:16.14 99.8%0+0k 3+14io 597pf+0w [Book15] f90/bug% time gfc pr55585.f90 3.030u 0.063s 0:03.10 99.6%0+0k 0+5io 110pf+0w
[Bug tree-optimization/61346] New: VRP chooses bad bounds for variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61346
Bug ID: 61346
Summary: VRP chooses bad bounds for variable
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
CC: cmang at google dot com
The attached file, which is a Go test case converted to C code, should compile
and run without error. It works with GCC 4.6.3 and GCC 4.9 branch with and
without optimization. It works with mainline with -O0 and -O1. It fails with
mainline with -O2.
I think the problem is in the VRP pass. I see this in 067.vrp1:
i_3: [data$len_58, 9223372036854775806] EQUIVALENCES: { i_65 } (1 elements)
This is flat out wrong, as inspection of 066.mergephi2 shows that the ideally
correct range of i_3 should be something like [0, data$len_58]. What's
particularly odd is that i_3 is even set to i_1, and the range of i_1 is
VARYING.
[Bug tree-optimization/61346] VRP chooses bad bounds for variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61346 --- Comment #1 from Ian Lance Taylor ian at airs dot com --- Created attachment 32872 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32872action=edit test case
[Bug tree-optimization/61346] VRP chooses bad bounds for variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61346 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Was this before or after revision 211012? There was a bug in VRP which was also exposed by Fortran bounds checking: bug 61335.
[Bug tree-optimization/61346] VRP chooses bad bounds for variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61346 --- Comment #4 from Ian Lance Taylor ian at airs dot com --- This was before 211012. It may be fixed. I will check.
