[Bug rtl-optimization/52714] [4.7/4.8/4.9 regression] ICE in fixup_reorder_chain, at cfglayout.c:880
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2012-03-25 00:00:00 |2013-12-25
[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763 --- Comment #15 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Steven Bosscher from comment #14) Lots of hot/cold partitioning fixes have been committed in the past few weeks. Uros, so you still see this bug with a recent trunk? I still see the failure with trunk revision 206059 [1]. [1] http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg01719.html
[Bug c++/59596] New: Unable to get the rpm file GCC 4.2 version for Linux X86_64 bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59596 Bug ID: 59596 Summary: Unable to get the rpm file GCC 4.2 version for Linux X86_64 bit Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vishwaradhya.j at hcl dot com Hi Team, We are unable to get/download the rpm file GCC 4.2 version for Linux X86_64 bit. This is required for our project to convert the CPP files into mex files. Please let us know how do we proceed? Regards Vishwaradhya
[Bug c++/59596] Unable to get the rpm file GCC 4.2 version for Linux X86_64 bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59596 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- The GCC project generally does not provide binaries, see http://gcc.gnu.org/install/binaries.html.
[Bug tree-optimization/59597] New: Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 Bug ID: 59597 Summary: Performance degradation on Coremark after r205074 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: izamyatin at gmail dot com Target: x86 Created attachment 31510 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31510action=edit reduced test Degradation could be seen at -Ofast for the attached test which similar to the Coremark codes It seems that jump threading here performs unnecessary nodes duplication and as a result if-conversion doesn't happen.
[Bug tree-optimization/54742] Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 --- Comment #34 from Igor Zamyatin izamyatin at gmail dot com --- Done - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597
[Bug lto/59582] LTO discards symbol that defined as weak elsewhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59582 Joey Ye joey.ye at arm dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Joey Ye joey.ye at arm dot com --- Thanks HJ. Binutils 2.24 does solve it.
[Bug lto/59582] LTO discards symbol that defined as weak elsewhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59582 --- Comment #5 from Joey Ye joey.ye at arm dot com --- HJ, do you know which patch fixed this issue? I might need to backport it into local 2.23 branch.
[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Attachment #30656|0 |1 is obsolete|| --- Comment #12 from Mikael Morin mikael at gcc dot gnu.org --- Created attachment 31511 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31511action=edit Patch fixing both comment #4 and comment #6 Let's hope it's not too late to put this under the christmas tree. This patch does forces pointer association of components of a derived type which has already been loaded. I don't like it much, as it is dependent on the order of the symbol contents as specified by the mio_symbol code.
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris Linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-25 Ever confirmed|0 |1 --- Comment #14 from H.J. Lu hjl.tools at gmail dot com --- I couldn't tell what the problem is. I have no problem to configure GCC with /export/gnu/import/git/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++ --prefix=/usr/local --enable-gnu-indirect-function --with-arch=native --with-cpu=native --with-fpmath=sse on a non-AVX machine with AVX binutils. x86_avx.cc was compiled with /export/build/gnu/gcc-native/build-x86_64-linux/./gcc/xg++ -B/export/build/gnu/gcc-native/build-x86_64-linux/./gcc/ -nostdinc++ -nostdinc++ -I/export/build/gnu/gcc-native/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/build/gnu/gcc-native/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/export/gnu/import/git/gcc/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gcc/libstdc++-v3/include/backward -I/export/gnu/import/git/gcc/libstdc++-v3/testsuite/util -L/export/build/gnu/gcc-native/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/export/build/gnu/gcc-native/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/export/build/gnu/gcc-native/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/export/gnu/import/git/gcc/libitm -I/export/gnu/import/git/gcc/libitm/config/linux/x86 -I/export/gnu/import/git/gcc/libitm/config/linux -I/export/gnu/import/git/gcc/libitm/config/x86 -I/export/gnu/import/git/gcc/libitm/config/posix -I/export/gnu/import/git/gcc/libitm/config/generic -I/export/gnu/import/git/gcc/libitm -march=i486 -mtune=i686 -fomit-frame-pointer -mrtm -Wall -pthread -Werror -mavx -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -D_GNU_SOURCE -m32 -MT x86_avx.lo -MD -MP -MF .deps/x86_avx.Tpo -c /export/gnu/import/git/gcc/libitm/config/x86/x86_avx.cc -o x86_avx.o There is -mavx in CXXFLAGS. But it won't be used at run-time since my machine doesn't have AVX.
[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-25 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed: r206002 gives 5.771u 0.002s 0:05.77 100.0%0+0k 0+0io 0pf+0w and gcc version 4.8.2 2.728u 0.001s 0:02.73 99.6%0+0k 0+0io 2pf+0w The change occurred between r205073 (2013-11-20, fast) and r205099 (2013-11-20, slow).
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris Linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 --- Comment #15 from David Kredba nheghathivhistha at gmail dot com --- For me it looks like that GCC build process is taking from some internal definition that AVX should be present on Core2 and enables it for libitm. Patch attached in this bug report works for gcc-4.9-20131222 fine too. Known to fail can contain 4.8.2 (and 4.9.0 branch too if possible). Gcc knows that there is no AVX, both for 4.8.2 and 4.9.0 snapshot but both versions enable AVX for libitim for me: 4.9.0: gcc -march=native -Q --help=targetThe following options are target specific: -m128bit-long-double [disabled] -m32 [disabled] -m3dnow [disabled] -m3dnowa [disabled] -m64 [enabled] -m80387 [enabled] -m8bit-idiv [disabled] -m96bit-long-double [enabled] -mabi=sysv -mabm [disabled] -maccumulate-outgoing-args[disabled] -maddress-mode= short -madx [disabled] -maes [disabled] -malign-double[disabled] -malign-functions=0 -malign-jumps=0 -malign-loops=0 -malign-stringops [enabled] -mandroid [disabled] -march= core2 -masm=att -mavx [disabled] -mavx2[disabled] -mavx256-split-unaligned-load [disabled] -mavx256-split-unaligned-store[disabled] -mavx512cd[disabled] -mavx512er[disabled] -mavx512f [disabled] -mavx512pf[disabled] -mbionic [disabled] -mbmi [disabled] -mbmi2[disabled] -mbranch-cost=0 -mcld [disabled] -mcmodel= 32 -mcpu= -mcrc32 [disabled] -mcx16[enabled] -mdispatch-scheduler [disabled] -mdump-tune-features [disabled] -mf16c[disabled] -mfancy-math-387 [enabled] -mfentry [enabled] -mfma [disabled] -mfma4[disabled] -mforce-drap [disabled] -mfp-ret-in-387 [enabled] -mfpmath= 387 -mfsgsbase[disabled] -mfused-madd -mfxsr[enabled] -mglibc [enabled] -mhard-float [enabled] -mhle [disabled] -mieee-fp [enabled] -mincoming-stack-boundary=0 -minline-all-stringops[disabled] -minline-stringops-dynamically[disabled] -mintel-syntax -mlarge-data-threshold= 0x1 -mlong-double-64 [disabled] -mlong-double-80 [enabled] -mlwp [disabled] -mlzcnt [disabled] -mmemcpy-strategy= -mmemset-strategy= -mmmx [enabled] -mmovbe [disabled] -mms-bitfields[disabled] -mno-align-stringops [disabled] -mno-default [disabled] -mno-fancy-math-387 [disabled] -mno-push-args[disabled] -mno-red-zone [disabled] -mno-sse4 [disabled] -momit-leaf-frame-pointer [disabled] -mpc32[disabled] -mpc64[disabled] -mpc80[disabled] -mpclmul [disabled] -mpopcnt [disabled] -mprefer-avx128 [disabled] -mpreferred-stack-boundary= 0 -mprfchw [disabled] -mpush-args [enabled] -mrdrnd [disabled] -mrdseed [disabled] -mrecip
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris Linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 --- Comment #16 from H.J. Lu hjl.tools at gmail dot com --- (In reply to David Kredba from comment #15) For me it looks like that GCC build process is taking from some internal definition that AVX should be present on Core2 and enables it for libitm. Patch attached in this bug report works for gcc-4.9-20131222 fine too. Known to fail can contain 4.8.2 (and 4.9.0 branch too if possible). Gcc knows that there is no AVX, both for 4.8.2 and 4.9.0 snapshot but both What is exactly the problem? How can I reproduce it? versions enable AVX for libitim for me: That is intentional. AVX is always compiled in if your binutils supports it. When you copy the same GCC run-time library binaries you built on non-AVX machine, including libitm, to an AVX machine, the AVX functions are checked and used at the run-time if OS/HW support AVX.
[Bug c++/59598] New: very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598
Bug ID: 59598
Summary: very simple code using file open for read
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lirex.software at gmail dot com
this portion of the code works ONLY IF the code line characters_count++; is
absent:
characters_count=0;
stream = fopen (argv[1],r);
while ((c = fgetc(stream)) != EOF)
{
characters_count++;
printf(total characters are %s\n, characters_count);
}
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #1 from Denis Kolesnik lirex.software at gmail dot com --- Created attachment 31512 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31512action=edit C++ source file
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #2 from Denis Kolesnik lirex.software at gmail dot com --- echo off PATH=%PATH%;c:\MinGW\bin;C:\MinGW\x86_64-w64-mingw32\bin set application_file=main_app2 gcc replace_1.c
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- With -W -Wall you get some warnings which expose what is going wrong: t.c: In function ‘main’: t.c:46: warning: format ‘%s’ expects type ‘char *’, but argument 2 has type ‘int’ t.c:49: warning: format ‘%s’ expects type ‘char *’, but argument 2 has type ‘int’ Using %d instead works.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #4 from Denis Kolesnik denis.v.koles...@safe-mail.net --- MY OS is MS Windows 8.1 64x licensed
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #5 from Denis Kolesnik denis.v.koles...@safe-mail.net --- thanks my mind possibly poisoned by some mushrooms(not by me), that is why I do not notice such simple things and can not find it.
[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris Linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 --- Comment #17 from David Kredba nheghathivhistha at gmail dot com --- I can't bootstrap 4.9.0 snapshots without patch attached. My machine is Core2 Quad where are not any avx instructions available. All is compiled from sources (Gentoo) but libitm x86_avx.lo crashes bootstrap. -march=native is by gcc translated to core2 what is correct. I saw qt 4.8.5 qmake reporting AVX available too, which is wrong. After I used -mno-avx it stopped doing it. Gcc knows there is no avx. Binutils reports AVX instruction set support anyway as supported - it can work with it in code. The fact that code produced will not run on host system is not burning them looks like. I recompiled them with -mno-avx to be sure that tests for AVX will fail but GNU as reports them an thus libitm still crashes bootstrap. In my opinion if gcc cannot trust GNU AS it should tell itsef to libitm configure what instructions sets are really available. I think that reproducing needs machine where CPU does not know what AVX is. Thank you.
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris Linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 --- Comment #18 from H.J. Lu hjl.tools at gmail dot com --- (In reply to David Kredba from comment #17) I think that reproducing needs machine where CPU does not know what AVX is. I have non-AVX machines and I have no problems with bootstrapping GCC 4.9.0 on them. So far no one has described how to reproduce the issue.
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled by -mno-avx but supported by as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|WAITING |NEW Summary|Build fails in x86_avx.cc |Build fails in x86_avx.cc |if AVX disabled but |if AVX disabled by -mno-avx |supported by as (Solaris |but supported by as |Linux) | --- Comment #19 from H.J. Lu hjl.tools at gmail dot com --- When -mno-avx is added to CXXFLAGS, x86_avx.cc failed to compile: /bin/sh ./libtool --tag=CXX --mode=compile /export/build/gnu/gcc-misc/build-x86_64-linux/./gcc/xg++ -B/export/build/gnu/gcc-misc/build-x86_64-linux/./gcc/ -nostdinc++ -nostdinc++ -I/export/build/gnu/gcc-misc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/build/gnu/gcc-misc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/export/gnu/import/git/gcc/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gcc/libstdc++-v3/include/backward -I/export/gnu/import/git/gcc/libstdc++-v3/testsuite/util -L/export/build/gnu/gcc-misc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/export/build/gnu/gcc-misc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/export/build/gnu/gcc-misc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/gcc-4.9.0/x86_64-unknown-linux-gnu/bin/ -B/usr/gcc-4.9.0/x86_64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.9.0/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.9.0/x86_64-unknown-linux-gnu/sys-include-DHAVE_CONFIG_H -I. -I/export/gnu/import/git/gcc/libitm -I/export/gnu/import/git/gcc/libitm/config/linux/x86 -I/export/gnu/import/git/gcc/libitm/config/linux -I/export/gnu/import/git/gcc/libitm/config/x86 -I/export/gnu/import/git/gcc/libitm/config/posix -I/export/gnu/import/git/gcc/libitm/config/generic -I/export/gnu/import/git/gcc/libitm -march=i486 -mtune=i686 -fomit-frame-pointer -mrtm -Wall -Werror -Wc,-pthread -mavx -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -mno-avx -D_GNU_SOURCE -m32 -MT x86_avx.lo -MD -MP -MF .deps/x86_avx.Tpo -c -o x86_avx.lo /export/gnu/import/git/gcc/libitm/config/x86/x86_avx.cc
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled by -mno-avx but supported by as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 --- Comment #20 from H.J. Lu hjl.tools at gmail dot com --- (In reply to David Kredba from comment #17) I can't bootstrap 4.9.0 snapshots without patch attached. My machine is Core2 Quad where are not any avx instructions available. All is compiled from sources (Gentoo) but libitm x86_avx.lo crashes bootstrap. -march=native is by gcc translated to core2 what is correct. The problem is -mno-avx is added by hand. GCC won't use generate AVX instructions with -march=native only if your machine supports AVX. x86_avx.cc is compiled with -mavx on purpose. libitm checks if AVX is supported at run-time and uses x86_avx if AVX is supported. -mno-avx shouldn't added by hand to bootstrap GCC. I think we should close this bug as WONTFIX.
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled by -mno-avx but supported by as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 --- Comment #21 from Ryan Hill dirtyepic at gentoo dot org --- Well in practice we've had to have users build GCC with -mno-avx on no less than three occasions since 4.4 due to compiler bugs on certain chips (usually newer chips + old releases), so it'd be nice to have it just work. If x86_avx.cc must be compiled with -mavx then can it be appended after user CFLAGS? That should make everyone happy.
[Bug fortran/59599] New: Compiler internal error on intrinsic ichar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59599 Bug ID: 59599 Summary: Compiler internal error on intrinsic ichar Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fmartinez at gmv dot com Created attachment 31513 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31513action=edit Source code generatin the execption When using the optional paramenter kind in the invocation of intrinsic function ichar the following exception is thrown: m_util_convert.f90:767:0: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:8006 res = ichar( cpk, kind=1 ) ^ Source file attached
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled by -mno-avx but supported by as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 --- Comment #22 from H.J. Lu hjl.tools at gmail dot com --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01877.html
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled by -mno-avx but supported by as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 --- Comment #23 from H.J. Lu hjl.tools at gmail dot com --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01877.html
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled by -mno-avx but supported by as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug target/59422] Support more targets for function multi versioning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59422 --- Comment #2 from uros at gcc dot gnu.org --- Author: uros Date: Wed Dec 25 22:22:24 2013 New Revision: 206200 URL: http://gcc.gnu.org/viewcvs?rev=206200root=gccview=rev Log: gcc/ 2013-12-25 Allan Sandfeld Jensen sandf...@kde.org H.J. Lu hongjiu...@intel.com PR target/59422 * config/i386/i386.c (get_builtin_code_for_version): Handle PROCESSOR_HASWELL, PROCESSOR_SILVERMONT, PROCESSOR_BTVER1, PROCESSOR_BTVER2, PROCESSOR_BDVER3 and PROCESSOR_BDVER4. Change priority of PROCESSOR_BDVER1 to P_PROC_XOP. (fold_builtin_cpu): Add ivybridge, haswell, bonnell, silvermont, bobcat and jaguar CPU names. Add sse4a, fma4, xop and fma ISA names. libgcc/ 2013-12-25 Allan Sandfeld Jensen sandf...@kde.org H.J. Lu hongjiu...@intel.com PR target/59422 * config/i386/cpuinfo.c (enum processor_types): Add AMD_BOBCAT and AMD_JAGUAR. (enum processor_subtypes): Add AMDFAM15H_BDVER3, AMDFAM15H_BDVER4, INTEL_COREI7_IVYBRIDGE and INTEL_COREI7_HASWELL. (enum processor_features): Add FEATURE_SSE4_A, FEATURE_FMA4, FEATURE_XOP and FEATURE_FMA. (get_amd_cpu): Handle AMD_BOBCAT, AMD_JAGUAR, AMDFAM15H_BDVER2 and AMDFAM15H_BDVER3. (get_intel_cpu): Handle INTEL_COREI7 and INTEL_COREI7_HASWELL. (get_available_features): Handle FEATURE_FMA, FEATURE_SSE4_A, FEATURE_FMA4 and FEATURE_XOP. testsuite/ 2013-12-25 Allan Sandfeld Jensen sandf...@kde.org PR target/59422 * gcc.target/i386/funcspec-5.c (test_fma, test_xop, test_no_fma, test_no_xop, test_arch_corei7, test_arch_corei7_avx, test_arch_core_avx2, test_arch_bdver1, test_arch_bdver2, test_arch_bdver3, test_tune_corei7, test_tune_corei7_avx, test_tune_core_avx2, test_tune_bdver1, test_tune_bdver2 and test_tune_bdver3): New function prototypes. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/funcspec-5.c trunk/libgcc/ChangeLog trunk/libgcc/config/i386/cpuinfo.c trunk/libgo/go/net/dial_test.go
[Bug fortran/59599] Compiler internal error on intrinsic ichar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59599 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-25 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Reduced test character(1) cpk(2) integer res(2) cpk = 'a' res = ichar( cpk, kind=1 ) print *, ichar( cpk, kind=1 ) end pr59599_red.f90:4:0: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:8008 res = ichar( cpk, kind=1 ) ICE for all revisions I have tried from 4.4. If the line res = ichar( cpk, kind=1 ) is commented, the ICE is pr59599_red.f90:3:0: internal compiler error: in gfc_trans_transfer, at fortran/trans-io.c:2324 print *, ichar( cpk, kind=1 ) Note that cpm has to be an array.
[Bug target/59422] Support more targets for function multi versioning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59422 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-12/msg01862.htm ||l Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- Fixed.
[Bug target/59587] cpu_names in i386.c is accessed with wrong index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59587 --- Comment #3 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Wed Dec 25 22:44:04 2013 New Revision: 206202 URL: http://gcc.gnu.org/viewcvs?rev=206202root=gccview=rev Log: Remove target_cpu_default/cpu_names Add processor names to processor_target_table and use it instead of target_cpu_default and cpu_names. PR target/59587 * config/i386/i386.c (struct ptt): Add a field for processor name. (processor_target_table): Sync with processor_type. Add processor names. (cpu_names): Removed. (ix86_option_override_internal): Default x_ix86_tune_string to processor_target_table[TARGET_CPU_DEFAULT].name. (ix86_function_specific_print): Assert arch and tune PROCESSOR_max. Use processor_target_table to print arch and tune names. * config/i386/i386.h (TARGET_CPU_DEFAULT): Default to PROCESSOR_GENERIC. (target_cpu_default): Removed. (processor_type): Reordered. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h
[Bug debug/51358] incorrect/missing location for function arg, -O0, without VTA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358 --- Comment #11 from Frank Ch. Eigler fche at redhat dot com --- This problem continues to hit in gcc 4.8.2.
[Bug sanitizer/59600] New: no_sanitize_address mishandled when function is inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 Bug ID: 59600 Summary: no_sanitize_address mishandled when function is inlined Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: eggert at gnu dot org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Created attachment 31514 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31514action=edit Compile and link with '-fsanitize=address -O2' and run to illustrate the bug A function declared with __attribute__ ((no_sanitize_address)) will attempt to sanitize its addresses if the function happens to be inlined in another function that lacks the attribute. This will cause the code to dump core even when it's not supposed to. I discovered this problem when trying to use address sanitization in Emacs. To reproduce the problem on an x86-64 platform, compile the attached program with 'gcc -fsanitize=address -O2'. It will dump core because the commented address is sanitized even though it's in a no_sanitize_address function. Compiling with -DTHIS_WORKS_AROUND_THE_BUG works around the bug by adding a noinline attribute to the function in question, but user code shouldn't have to do that.
[Bug sanitizer/59600] no_sanitize_address mishandled when function is inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #1 from Yury Gribov y.gribov at samsung dot com --- Created attachment 31515 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31515action=edit Draft patch Fails for me as well. Given that Asan runs long after inliner this behavior is expected. Perhaps it makes sense to prohibit inline for unsanitized functions? We'll loose some performance but no_sanitize_address semantics would be more transparent for users. Here's a crude patch which seems to fix repro and also show no regressions for `make check-c RUNTESTFLAGS=asan.exp'.
[Bug target/59601] New: [4.9 Regression] __attribute__ ((target(arch=corei7))) won't match Westmere processor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59601 Bug ID: 59601 Summary: [4.9 Regression] __attribute__ ((target(arch=corei7))) won't match Westmere processor Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: ubizjak at gmail dot com g++.dg/ext/mv1.C fails on Westmere processor at run-time since -march=westmere wasn't supported befor and now __attribute__ ((target(arch=corei7))) is turned into __attribute__ ((target(arch=nehalem))) which won't match Westmere at run-time. We have 2 choices: 1. No change. __attribute__ ((target(arch=corei7))) won't match Westmere and function won't be optimized for Westmere. 2. Make PROCESSOR_NEHALEM to match corei7 for function versioning. But __attribute__ ((target(arch=nehalem))) function may be used on Westmere. I think it is OK since function versioning doesn't support extra ISAs on Westmere.
[Bug sanitizer/59600] no_sanitize_address mishandled when function is inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 --- Comment #2 from Kostya Serebryany kcc at gcc dot gnu.org --- We had this problem in clang before http://llvm.org/viewvc/llvm-project?view=revisionrevision=187967
[Bug sanitizer/59600] no_sanitize_address mishandled when function is inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Yury Gribov from comment #1) Created attachment 31515 [details] Draft patch Why can't you just set DECL_UNINLINABLE on the function decl in handle_no_sanitize_undefined_attribute in c-common.c just like how handle_noinline_attribute handles it?
[Bug sanitizer/59600] no_sanitize_address mishandled when function is inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #3) (In reply to Yury Gribov from comment #1) Created attachment 31515 [details] Draft patch Why can't you just set DECL_UNINLINABLE on the function decl in handle_no_sanitize_undefined_attribute in c-common.c just like how handle_noinline_attribute handles it? Or better yet handle the case where the attributes diff inside function_attribute_inlinable_p so you don't lose that much optimizations only when the attributes differ.
[Bug sanitizer/59600] no_sanitize_address mishandled when function is inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added Attachment #31515|0 |1 is obsolete|| --- Comment #5 from Yury Gribov y.gribov at samsung dot com --- Created attachment 31516 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31516action=edit New patch based on Andrew's review (In reply to Andrew Pinski from comment #3) Or better yet handle the case where the attributes diff inside function_attribute_inlinable_p so you don't lose that much optimizations only when the attributes differ. Yup and this would also work for non-C-family frontends. How about this patch then?
