[Bug debug/60643] ICE with -O1 and -g on mips (internal compiler error: in dwarf2out_var_location, at dwarf2out.c:20810)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60643 --- Comment #12 from Khem Raj raj.khem at gmail dot com --- I would like to reopen this bug. As there is more information to explain this issue. This issue will happen if you first build cross binutils and add the installation path to PATH variable and then configure gcc to cross build for mips. All you need is cross assembler available in PATH when configuring gcc. If gcc configure script does not find assembler then many probes fail and it gets configured differently. I could see that when cross assembler is not in path then the resulting gcc is able to compile the sample program however when assembler is in PATH then the issue starts to show up. I am not sure how Andrew built his toolchain but it seems he is not adding binutils to the path before configuring cross gcc. Steps. configure and install cross binutils ( especially assembler ) Add the install path to PATH variable configure and compile cross gcc Try out the example ( it will cause the ICE as explained) btw it happens with gcc 4.8 as well as 4.9 in same fashion and I have verified that OE patches don't make any difference here. I could see it happen on latest FSF 4.9 branch see below is the diff between gcc/config.log between two cases explained above -gcc_cv_as='' +gcc_cv_as='/home/ubuntu/work/dizzy/build-pacexi3v2/tmp/sysroots/x86_64-linux/usr/bin/mipsel-rdk-linux/mipsel-rdk-linux-as' gcc_cv_ld='' gcc_cv_nm='' gcc_cv_objdump='' @@ -6067,7 +6205,7 @@ target='mipsel-rdk-linux-gnu' target_alias='mipsel-rdk-linux' target_cpu='mipsel' -target_cpu_default='MASK_SPLIT_ADDRESSES' +target_cpu_default='(MASK_SPLIT_ADDRESSES)|MASK_EXPLICIT_RELOCS' target_noncanonical='mipsel-rdk-linux' target_os='linux-gnu' target_subdir='mipsel-rdk-linux' @@ -6278,13 +6416,31 @@ #define HAVE_DLFCN_H 1 #define LT_OBJDIR .libs/ #define PLUGIN_LD_SUFFIX +#define HAVE_GAS_BALIGN_AND_P2ALIGN 1 +#define HAVE_GAS_MAX_SKIP_P2ALIGN 1 +#define HAVE_GAS_WEAK 1 +#define HAVE_GAS_WEAKREF 1 #define HAVE_GNU_INDIRECT_FUNCTION 0 +#define HAVE_AS_LEB128 1 #define HAVE_GAS_CFI_DIRECTIVE 0 -#define HAVE_GAS_CFI_PERSONALITY_DIRECTIVE 0 -#define HAVE_GAS_CFI_SECTIONS_DIRECTIVE 0 -#define HAVE_GAS_SHF_MERGE 0 +#define HAVE_GAS_CFI_PERSONALITY_DIRECTIVE 1 +#define HAVE_GAS_CFI_SECTIONS_DIRECTIVE 1 +#define USE_AS_TRADITIONAL_FORMAT 1 +#define HAVE_GAS_SHF_MERGE 1 #define HAVE_COMDAT_GROUP 0 +#define HAVE_GAS_DISCRIMINATOR 1 +#define HAVE_AS_TLS 1 #define HAVE_LTO_PLUGIN 0 +#define HAVE_AS_NO_SHARED 1 +#define HAVE_AS_GNU_ATTRIBUTE 1 +#define HAVE_GAS_MICROMIPS 1 +#define HAVE_AS_DTPRELWORD 1 +#define HAVE_AS_DSPR1_MULT 1 +#define HAVE_AS_NAN 1 +#define HAVE_AS_GDWARF2_DEBUG_FLAG 1 +#define HAVE_AS_GSTABS_DEBUG_FLAG 1 +#define HAVE_AS_DEBUG_PREFIX_MAP 1 +#define HAVE_AS_LINE_ZERO 1 #define HAVE_LD_EH_FRAME_CIEV3 0 #define ENABLE_LTO 1
[Bug c++/63454] [5 Regression] internal compiler error: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63454 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- I don't see any ICE for gcc 5.0.0 20141004 (experimental). Could you retry that one?
[Bug libfortran/63460] New: Some namelists cannot be read from stdin (unit 5): Fortran runtime error: End of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63460 Bug ID: 63460 Summary: Some namelists cannot be read from stdin (unit 5): Fortran runtime error: End of file Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: toon at moene dot org The following Fortran program, when compiled with gfortran 4.9.1 or trunk (5.0), cannot read a valid namelist file from stdin (unit 5). Reading it from another unit (or as an internal file) proceeds fine. Fortran program: character*10 file /'noot.hdf'/ character*5 aap(10) /10*/ integer par(10) /10*3/ namelist /namlis/ file, aap, par read (5, namlis) write(6, namlis) end Namelist file (which is redirected to stdin): NAMLIS file='aap.hdf', aap(5)='noot', par(5)=6 /
[Bug libfortran/63460] [4.9/5 Regression] Some namelists cannot be read from stdin (unit 5): Fortran runtime error: End of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63460 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-05 CC||jvdelisle at gcc dot gnu.org Summary|Some namelists cannot be|[4.9/5 Regression] Some |read from stdin (unit 5): |namelists cannot be read |Fortran runtime error: End |from stdin (unit 5): |of file |Fortran runtime error: End ||of file Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Revision r208241 (2014-03-01) is OK, r208311 (2014-03-04) is not, likely r208302 (pr60148).
[Bug c/52952] Wformat location info is bad (wrong column number)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Attachment #33647|0 |1 is obsolete|| --- Comment #32 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Created attachment 33648 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33648action=edit dynamically create locations from loc + offset
[Bug c/52952] Wformat location info is bad (wrong column number)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #33 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #32) Created attachment 33648 [details] dynamically create locations from loc + offset This version is able to handle macros: format.c: In function ‘foo’: format.c:5:18: warning: format ‘%d’ expects a matching ‘int’ argument [-Wformat=] #define FORMAT %d ^ format.c:9:20: note: in definition of macro ‘FORMAT3’ #define FORMAT3(x) x ^ format.c:21:29: note: in expansion of macro ‘FORMAT’ __builtin_printf(FORMAT3 (FORMAT)); ^ format.c:23:31: warning: format ‘%d’ expects a matching ‘int’ argument [-Wformat=] __builtin_printf(FORMAT3 (%d)); ^ format.c:9:20: note: in definition of macro ‘FORMAT3’ #define FORMAT3(x) x ^ format.c:5:18: warning: format ‘%d’ expects a matching ‘int’ argument [-Wformat=] #define FORMAT %d ^ format.c:28:20: note: in expansion of macro ‘FORMAT’ __builtin_printf(FORMAT); ^ The approach followed is based on reserving space for one token in every macro map. If this is expensive, the alternative could be to reserve the virtual location for the additional token, but not reserve the memory until the virtual location is requested. The code assumes that the new location is immediately used, otherwise a subsequent location may overwrite it. The problem is that the virtual locations of macro maps are consecutive, thus we cannot simply dynamically create virtual locations without reserving some of them in advance. Perhaps this is good enough for a first commit? Dodji, what do you think?
[Bug c/52952] Wformat location info is bad (wrong column number)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #34 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #27) (In reply to Manuel López-Ibáñez from comment #25) * Cases like: 1: const str[] = something %d; 2: printf(str); Note that clang is able to handle this: manuel@gcc10:~$ clang -Wformat format.c format.c:4:19: warning: more '%' conversions than data arguments [-Wformat] __builtin_printf(str); ^~~ format.c:3:33: note: format string is defined here const char str[] = something %d; ~^ Note to myself: Supporting this requires tracking the location of the initializer. Perhaps we could track this explicitly in var_decl. Or by adding an expression around the initializer. Then, we would need to pass the additional location to the point of warning_at, so we can print the note when appropriate.
[Bug c/52952] Wformat location info is bad (wrong column number)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #35 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #13) I guess the C/C++ FEs could for non-trivial string literals put into a hash table mapping from locus_t (of ADDR_EXPR around STRING_CST) to the first cpp token for that string, then the diagnostic code could go from there. Trivial string literal above would be a string literal that doesn't have any prefixes (L/u/u8/U and variants with R), isn't contatenated from several parts and didn't need to be translated. So, printf (%.*d); (the common case) wouldn't have to be recorded, while printf (R(%) . R(*) d); would need that. For trivial string literals you'd just shift the locus by the offset, for non-trivial look up the tokens and process them again, looking at where the corresponding byte would appear to come from. Perhaps we could use ADHOC_LOCATIONS to implement this? That is, for multi-string/prefixed string constants, the adhoc data could contain the additional location. Then, on-the-fly offset locations could be generated by looking at each piece, if the offset is longer than the piece, then try the next piece and adjust the offset for the characters already seen in previous pieces. Simple strings will not have any adhoc data, so they will work as usual.
[Bug tree-optimization/56829] Feature request: generic builtin to support control flow in vectorized code (movemask, vec_any/all_*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56829 --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch --- just to add the OpenCL syntax and doc https://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/any.html
[Bug c/63461] New: Inconsistent behaviour on ARM64 when inline assembly with .text directive is followed by a static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63461 Bug ID: 63461 Summary: Inconsistent behaviour on ARM64 when inline assembly with .text directive is followed by a static variable Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: akiss at inf dot u-szeged.hu On ARM64/Ubuntu 14.04.1 with the stock gcc (Ubuntu/Linaro 4.8.2-19ubuntu1) I've experienced the following: First, I wrote a macro with inline assembly containing a .text directive followed by a static variable (still in the macro). Then, I expanded that macro multiple times. The generated assembly output contains a .data directive before the first variable declaration but not afterwards. This caused problems with dynamically linking shared libraries in WebKit (https://bugs.webkit.org/show_bug.cgi?id=137434). gcc details: Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libitm --disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-arm64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-arm64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-arm64 --with-arch-directory=arm64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-multiarch --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu Thread model: posix gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-19ubuntu1)
[Bug c/63461] Inconsistent behaviour on ARM64 when inline assembly with .text directive is followed by a static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63461 --- Comment #1 from Akos Kiss akiss at inf dot u-szeged.hu --- Created attachment 33649 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33649action=edit Example C source code
[Bug debug/63239] DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 --- Comment #2 from Mark Wielaard mark at gcc dot gnu.org --- Author: mark Date: Sun Oct 5 15:25:03 2014 New Revision: 215901 URL: https://gcc.gnu.org/viewcvs?rev=215901root=gccview=rev Log: PR debug/63239 Add DWARF representation for C++11 deleted member function. include/ChangeLog * dwarf2.def (DW_AT_GNU_deleted): New attribute. gcc/ChangeLog * dwarf2out.c (gen_subprogram_die): When a member function is explicitly deleted then add a DW_AT_GNU_deleted attribute. * langhooks.h (struct lang_hooks_for_decls): Add function_decl_deleted_p langhook. * langhooks-def.h (LANG_HOOKS_FUNCTION_DECL_DELETED_P): Define. (LANG_HOOKS_DECLS): Add LANG_HOOKS_FUNCTION_DECL_DELETED_P. gcc/cp/ChangeLog * cp-objcp-common.h (LANG_HOOKS_FUNCTION_DECL_DELETED_P): Define. (cp_function_decl_deleted_p): New prototype. * cp-objcp-common.c (cp_function_deleted_p): New function. gcc/testsuite/ChangeLog * g++.dg/debug/dwarf2/deleted-member-function.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/deleted-member-function.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-objcp-common.c trunk/gcc/cp/cp-objcp-common.h trunk/gcc/dwarf2out.c trunk/gcc/langhooks-def.h trunk/gcc/langhooks.h trunk/gcc/testsuite/ChangeLog trunk/include/ChangeLog trunk/include/dwarf2.def
[Bug c/63461] Inconsistent behaviour on ARM64 when inline assembly with .text directive is followed by a static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63461 --- Comment #3 from Akos Kiss akiss at inf dot u-szeged.hu --- Created attachment 33651 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33651action=edit Assembly output
[Bug c/63461] Inconsistent behaviour on ARM64 when inline assembly with .text directive is followed by a static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63461 --- Comment #2 from Akos Kiss akiss at inf dot u-szeged.hu --- Created attachment 33650 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33650action=edit Preprocessed source
[Bug debug/63243] [meta-bug] RH GDB project tracker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63243 Bug 63243 depends on bug 63239, which changed state. Bug 63239 Summary: DWARF does not represent C++ deleted methods https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug debug/63239] DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 Mark Wielaard mark at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Mark Wielaard mark at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00272.html
[Bug c/63461] Inconsistent behaviour on ARM64 when inline assembly with .text directive is followed by a static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63461 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andreas Schwab sch...@linux-m68k.org --- Don't do that then. Switching sections behind the compiler's back is undefined.
[Bug c/63461] Inconsistent behaviour on ARM64 when inline assembly with .text directive is followed by a static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63461 --- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com --- Use .pushsection and .popsection .
Kushi Aole
You have been approved by Kushi Aole-UK the sum of 85.00 GBP with draw number:22330KHO577345 and Serial number 1509/14. Reply for more details
[Bug libstdc++/63456] unordered_map incorrectly frees _M_single_bucket. Patch Included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63456 François Dumont fdumont at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-05 CC||fdumont at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from François Dumont fdumont at gcc dot gnu.org --- I of course confirm the bug. Occur only if you copy assign to an empty instance from a non-empty one like this: std::unordered_setint s1, s2; s2.insert(2); s1 = s2; Thanks for reporting.
[Bug libfortran/63460] [4.9/5 Regression] Some namelists cannot be read from stdin (unit 5): Fortran runtime error: End of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63460 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- That would likely be something I did. I will start looking at it today.
[Bug libstdc++/63456] unordered_map incorrectly frees _M_single_bucket. Patch Included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63456 --- Comment #2 from François Dumont fdumont at gcc dot gnu.org --- Author: fdumont Date: Sun Oct 5 18:44:46 2014 New Revision: 215905 URL: https://gcc.gnu.org/viewcvs?rev=215905root=gccview=rev Log: 2014-10-05 François Dumont fdum...@gcc.gnu.org PR libstdc++/63456 * include/bits/hashtable.h (_M_uses_single_bucket(__bucket_type*)): Test the parameter. * testsuite/23_containers/unordered_set/63456.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_set/63456.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable.h
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #13 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Ian Lance Taylor from comment #12) Can people on systems for which the recover.go test currently fails please try this patch and let me know whether it fixes the problem? Thanks. Unfortunately, the patched libgo still fails on alpha.
[Bug libstdc++/63456] unordered_map incorrectly frees _M_single_bucket. Patch Included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63456 --- Comment #3 from François Dumont fdumont at gcc dot gnu.org --- Author: fdumont Date: Sun Oct 5 19:36:15 2014 New Revision: 215906 URL: https://gcc.gnu.org/viewcvs?rev=215906root=gccview=rev Log: 2014-10-05 François Dumont fdum...@gcc.gnu.org PR libstdc++/63456 * include/bits/hashtable.h (_M_uses_single_bucket(__bucket_type*)): Test the parameter. * testsuite/23_containers/unordered_set/63456.cc: New. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/23_containers/unordered_set/63456.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/hashtable.h
[Bug libstdc++/63456] unordered_map incorrectly frees _M_single_bucket. Patch Included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63456 François Dumont fdumont at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.2 --- Comment #4 from François Dumont fdumont at gcc dot gnu.org --- Now fixed on trunk and 4.9 branch. Thanks again.
[Bug libstdc++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #15 from Agustín Bergé kaballo86 at hotmail dot com --- (In reply to Jonathan Wakely from comment #14) Agustin, do you have a copyright assignment? I do not have one. The attached tuple is derived from libstdc++'s tuple and I have left the license in place, wouldn't that be enough? I did not intend for the attachment to be a patch (it is not a patch, I did not consider coding styles, I did not run tests, etc), but merely a proof of concept implementation so that others could measure the compile-time performance win of a flat implementation.
[Bug c/63462] New: [RFC] gcc should prevent from overwriting source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63462 Bug ID: 63462 Summary: [RFC] gcc should prevent from overwriting source file Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: wkoszek at gmail dot com Suggestion: prevent GCC from overwriting source code files when invoked as: gcc source.c -o source.c Background: I use command completion heavily. Very often while in coding mood I do: gcc myfile.c -o myfTAB not to type myfile, which is long. But after completion kicks in, I sometimes forget to do BACKSPACEBACKSPACE. And .c file gets overwritten. It'd be nice to have GCC catch this. And if you really want to do it, maybe run GCC with: --yes-im-sure-i-want-to-overwrite-my-source-code switch.
[Bug libfortran/63460] [4.9/5 Regression] Some namelists cannot be read from stdin (unit 5): Fortran runtime error: End of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63460 --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- The following fixes this: Index: unit.c === --- unit.c(revision 215870) +++ unit.c(working copy) @@ -580,6 +580,7 @@ init_units (void) u-flags.position = POSITION_ASIS; u-flags.sign = SIGN_SUPPRESS; u-flags.decimal = DECIMAL_POINT; + u-flags.delim = DECIMAL_UNSPECIFIED; u-flags.encoding = ENCODING_DEFAULT; u-flags.async = ASYNC_NO; u-flags.round = ROUND_UNSPECIFIED; I will commit to trunk as obvious and simple after regression testing.
[Bug target/63435] Bad code with weak vs localalias on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435 --- Comment #4 from Andrew Dixie gcc at dixie dot net.nz --- I tried gcc-5-20140928 snapshot This snapshot doesn't generate a localalias for the testcase, and it generates very few localalias symbols in general. There was only one localalias symbol produced in the entire gcc build tree: [1228] m 0x041c 1 10x6b 0x ._ZNKSt14error_category23default_error_conditionEi.localalias.7 [1492] m 0x0b30 2 10x6b 0x _ZNKSt14error_category23default_error_conditionEi.localalias.7 [1578] m 0x0c6c 2 10x6b 0x _ZNKSt14error_category23default_error_conditionEi.localalias.7 Maybe there is something else wrong with gcc-4.9 that is causing it to generate localalias symbols too aggressively? We forced symtab_node::noninterposable_alias to return NULL on AIX. This resolved all the failures we were seeing in our application testsuite.
[Bug libfortran/63460] [4.9/5 Regression] Some namelists cannot be read from stdin (unit 5): Fortran runtime error: End of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63460 --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sun Oct 5 21:11:37 2014 New Revision: 215908 URL: https://gcc.gnu.org/viewcvs?rev=215908root=gccview=rev Log: 2014-10-05 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/63460 * io/unit.c (init_units): Initialize the DELIM flag to UNSPECIFIED for the STDIN unit so that the flag is correctly set later. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unit.c
[Bug rtl-optimization/63463] New: [5.0 regression] FAIL: gnat.dg/regpat1.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63463 Bug ID: 63463 Summary: [5.0 regression] FAIL: gnat.dg/regpat1.adb execution test Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: jiong.wang at arm dot com Target: powerpc-*-* $ ADA_INCLUDE_PATH=powerpc64-linux/32/libada/adainclude ADA_OBJECTS_PATH=powerpc64-linux/32/libada/adainclude gcc/gnatmake --GCC=gcc/xgcc --GNATBIND=gcc/gnatbind --GNATLINK=gcc/gnatlink -cargs -Bgcc -largs --GCC=gcc/xgcc\ -Bgcc\ \ -m32 -margs --RTS=powerpc64-linux/32/libada -q -f ../gcc/testsuite/gnat.dg/regpat1.adb -fno-diagnostics-show-caret -fdiagnostics-color=never -lm -m32 -o ./regpat1.exe $ ./regpat1.exe raised STORAGE_ERROR : stack overflow or erroneous memory access 63b061625a6529716998bef4efe2f7b4f58e is the first bad commit commit 63b061625a6529716998bef4efe2f7b4f58e Author: jiwang jiwang@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Wed Sep 24 18:30:34 2014 + Improve prepare_shrink_wrap to sink more instructions gcc/ * shrink-wrap.c (move_insn_for_shrink_wrap): Add further check when !REG_P (src) to release more instruction sink opportunities. gcc/testsuite/ * gcc.target/aarch64/shrink_wrap_symbol_ref_1.c: New testcase. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215563 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug rtl-optimization/63463] [5.0 regression] FAIL: gnat.dg/regpat1.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63463 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug tree-optimization/63464] New: compare one character to many: faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
Bug ID: 63464
Summary: compare one character to many: faster
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
This is inspired by reading this post:
http://stackoverflow.com/questions/26124620/why-does-msvc-emit-a-useless-movsx-before-performing-this-bit-test
which shows that bit testing can provide a very efficient lookup table for
small sizes, and in particular when we want to test if a character belongs to a
predefined set.
char*f1(char*s){
while (*s == ' ' || *s == ',' || *s == '\r' || *s == '\n')
++s;
return s;
}
char*f2(char*s){
long n = (1L ' ') | (1L ',') | (1L '\r') | (1L '\n');
int m = max(max(' ',','),max('\r','\n'));
while(*s = m (n (1L *s)))
++s;
return s;
}
On x86_64, the first one compiles to a bunch of cmpb+sete, combined with orl.
The second one has one cmpb+jg but uses btq+jc for the main job. A simple
benchmark on a string full of ',' shows running times of 158 vs 32, a very
large win for f2 (suspicious actually, but if I only test ' ', ',' and '\r', I
get the less surprising 50 for f1, which still shows f2 far ahead).
As is, it only works with characters less than 64, but more general versions
are possible with a bit more overhead (like applying the same to *s-64 after
testing its sign, or looking up the (*s/64)th element in a regular lookup table
and bit testing against that, etc).
The running time of 32 is exactly the same I get with a larger lookup table:
char issep[256]={0,0,...};
while(issep[*s])...
In this particular case, vectorization might also be an option, either the loop
kind if the string is likely to be long, but we don't even try because we can't
compute the number of iterations, or the slp kind by broadcasting *s, comparing
to all chars at once and reducing.
This PR is a bit vague and we cannot implement every weird optimization, but I
expect this type of comparison might be common enough that it would be worth
looking at. If you disagree, feel free to close, I never write code like that
myself ;-)
[Bug c++/63377] Bad diagnostic - expected unqualified-id instead of no type named __ in namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63377
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-10-05
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
Terrible. Confirmed.
Smaller testcase:
namespace std {}
int main() {
try {}
catch (const std::invalid_argument) {}
}
[Bug preprocessor/61891] line-map.c: file command-line left but not entered during `cabal install -p haskell-src-exts`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61891 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-10-05 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 --- Waiting for an answer from reporter.
[Bug c/63357] Warn for P P and P || P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63357 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-05 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- We could also put it in Wlogical-op for now. It seems it would require the same conditions (for example, to not warn about different macros that expand to the same thing).
[Bug preprocessor/61638] warning: multi-line comment unclear and has false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61638 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-05 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Sure, why not? But someone still has to implement it.
[Bug c++/63444] Compilation consumes 2.5G memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63444 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||memory-hog Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-05 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 --- Trunk requires 4G in x86_64: Execution times (seconds) phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 1248 kB ( 0%) ggc phase parsing : 7.38 ( 2%) usr 1.60 ( 7%) sys 9.03 ( 2%) wall 278534 kB ( 6%) ggc phase lang. deferred: 84.37 (17%) usr 5.28 (22%) sys 109.09 (20%) wall 1828691 kB (42%) ggc phase opt and generate : 393.72 (80%) usr 16.61 (70%) sys 412.23 (77%) wall 2197480 kB (51%) ggc phase check debug info: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc phase finalize : 4.50 ( 1%) usr 0.14 ( 1%) sys 4.64 ( 1%) wall 0 kB ( 0%) ggc |name lookup: 5.02 ( 1%) usr 1.41 ( 6%) sys 6.21 ( 1%) wall 243368 kB ( 6%) ggc |overload resolution: 23.85 ( 5%) usr 1.92 ( 8%) sys 28.75 ( 5%) wall 759029 kB (18%) ggc garbage collection : 51.11 (10%) usr 0.15 ( 1%) sys 51.26 (10%) wall 0 kB ( 0%) ggc dump files : 0.66 ( 0%) usr 1.19 ( 5%) sys 1.75 ( 0%) wall 0 kB ( 0%) ggc callgraph construction : 6.19 ( 1%) usr 0.67 ( 3%) sys 8.38 ( 2%) wall 81259 kB ( 2%) ggc callgraph optimization : 2.08 ( 0%) usr 1.48 ( 6%) sys 3.59 ( 1%) wall 57933 kB ( 1%) ggc ipa dead code removal : 1.59 ( 0%) usr 0.09 ( 0%) sys 1.60 ( 0%) wall 0 kB ( 0%) ggc ipa inheritance graph : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 54 kB ( 0%) ggc ipa virtual call target : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 1 kB ( 0%) ggc ipa devirtualization: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 1999 kB ( 0%) ggc ipa cp : 0.69 ( 0%) usr 0.01 ( 0%) sys 0.70 ( 0%) wall 15293 kB ( 0%) ggc ipa inlining heuristics : 3.51 ( 1%) usr 0.07 ( 0%) sys 3.55 ( 1%) wall 51806 kB ( 1%) ggc ipa function splitting : 0.56 ( 0%) usr 0.02 ( 0%) sys 0.60 ( 0%) wall 7633 kB ( 0%) ggc ipa comdats : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc ipa reference : 0.13 ( 0%) usr 0.00 ( 0%) sys 0.13 ( 0%) wall 0 kB ( 0%) ggc ipa profile : 0.25 ( 0%) usr 0.00 ( 0%) sys 0.25 ( 0%) wall 0 kB ( 0%) ggc ipa pure const : 0.63 ( 0%) usr 0.00 ( 0%) sys 0.54 ( 0%) wall 560 kB ( 0%) ggc ipa SRA : 0.51 ( 0%) usr 0.08 ( 0%) sys 0.63 ( 0%) wall 43906 kB ( 1%) ggc ipa free lang data : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc ipa free inline summary : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc cfg construction: 0.13 ( 0%) usr 0.02 ( 0%) sys 0.18 ( 0%) wall 5393 kB ( 0%) ggc cfg cleanup : 3.32 ( 1%) usr 0.07 ( 0%) sys 2.97 ( 1%) wall 9380 kB ( 0%) ggc CFG verifier: 21.65 ( 4%) usr 0.82 ( 3%) sys 22.38 ( 4%) wall 0 kB ( 0%) ggc trivially dead code : 1.42 ( 0%) usr 0.01 ( 0%) sys 1.34 ( 0%) wall 0 kB ( 0%) ggc df scan insns : 1.48 ( 0%) usr 0.00 ( 0%) sys 1.45 ( 0%) wall 510 kB ( 0%) ggc df multiple defs: 0.83 ( 0%) usr 0.02 ( 0%) sys 0.69 ( 0%) wall 0 kB ( 0%) ggc df reaching defs: 1.65 ( 0%) usr 0.00 ( 0%) sys 1.51 ( 0%) wall 0 kB ( 0%) ggc df live regs: 7.63 ( 2%) usr 0.00 ( 0%) sys 8.09 ( 2%) wall 0 kB ( 0%) ggc df liveinitialized regs: 3.10 ( 1%) usr 0.03 ( 0%) sys 2.63 ( 0%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.83 ( 0%) usr 0.00 ( 0%) sys 0.87 ( 0%) wall 0 kB ( 0%) ggc df live reg subwords: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 4.01 ( 1%) usr 0.02 ( 0%) sys 3.89 ( 1%) wall 17388 kB ( 0%) ggc register information: 0.93 ( 0%) usr 0.01 ( 0%) sys 0.83 ( 0%) wall 0 kB ( 0%) ggc alias analysis : 2.45 ( 1%) usr 0.05 ( 0%) sys 2.40 ( 0%) wall 46805 kB ( 1%) ggc alias stmt walking : 2.22 ( 0%) usr 0.33 ( 1%) sys 2.86 ( 1%) wall 1075 kB ( 0%) ggc register scan : 0.29 ( 0%) usr 0.00 ( 0%) sys 0.40 ( 0%) wall 297 kB ( 0%) ggc rebuild jump labels : 0.69 ( 0%) usr 0.01 ( 0%) sys 0.63 ( 0%) wall 0 kB ( 0%) ggc preprocessing : 0.50 (
[Bug c++/61501] spurious conversion warning with -Wconversion when calling isnan(double x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61501 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- This seems fixed in GCC 5.0. (At least I cannot reproduce it).
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||oliver at bway dot net --- Comment #26 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 61435 has been marked as a duplicate of this bug. ***
[Bug c++/61435] -imacros switch breaks warning/error reporting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61435 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- This seems fixed by the patches committed in PR60723 *** This bug has been marked as a duplicate of bug 60723 ***
[Bug libfortran/63460] [4.9/5 Regression] Some namelists cannot be read from stdin (unit 5): Fortran runtime error: End of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63460 --- Comment #5 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sun Oct 5 23:45:45 2014 New Revision: 215909 URL: https://gcc.gnu.org/viewcvs?rev=215909root=gccview=rev Log: 2014-10-05 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/63460 Backport from trunk. * io/unit.c (init_units): Initialize the DELIM flag to UNSPECIFIED for the STDIN unit so that the flag is correctly set later. Modified: branches/gcc-4_9-branch/libgfortran/ChangeLog branches/gcc-4_9-branch/libgfortran/io/unit.c
[Bug c/61416] incorrect struct tag in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61416 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-05 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 --- Anyway confirmed.
[Bug preprocessor/61386] inaccurate location for missing headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61386 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-05 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Sure, could you provide a patch? Or at least investigate what needs to be changed?
[Bug libfortran/63460] [4.9/5 Regression] Some namelists cannot be read from stdin (unit 5): Fortran runtime error: End of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63460 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Fixed on 4.9 and 5.
[Bug c++/60916] truncated error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60916 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-05 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- The error within notes is also quite confusing, it is not clear if the additional errors are explaining the notes or are separate errors. Clang makes this much clearer: test.cc:19:10: error: no matching function for call to 'wrapper' return wrapperchar, f (); ^~~~ test.cc:6:5: note: candidate template ignored: invalid explicitly-specified argument for template parameter 'F' int wrapper () ^ test.cc:12:5: note: candidate template ignored: invalid explicitly-specified argument for template parameter 'T2' int wrapper () ^ GCC at least could do: t.cc: In function ‘int docall()’: t.cc:19:28: error: no matching function for call to ‘wrapper()’ return wrapperchar, f (); ^ t.cc:19:28: note: candidates are: t.cc:6:5: note: #1 'templateclass T, int (* F)(const T*) int wrapper()' int wrapper () ^ t.cc:6:5: note: template argument deduction/substitution failed: could not convert template argument ‘f’ to ‘int (*)(const char*)’ t.cc:12:5: note: #2 'templateclass T1, class T2, int (* F)(const T1*, const T2*) int wrapper()' int wrapper () ^ t.cc:12:5: note: template argument deduction/substitution failed:
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-06 CC||manu at gcc dot gnu.org Component|preprocessor|c++ Ever confirmed|0 |1 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- For some reason, it thinks that false comes from a system-header. Weird.
[Bug c/63450] Optimizing -O3 generates rep ret on an almost empty function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63450 --- Comment #3 from Luis Colorado lc at luiscoloradosistemas dot com --- just one thing. When you compile a completely empty function you get `rep ret' in one line, instead of that on two lines. The result is some assemblers (gnu as at version 2.20, for example) complainting it as an error and you don't get a good compilation.
[Bug bootstrap/61763] [4.9 Regression] gcc-4.9.0 Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61763 --- Comment #5 from Douglas Mencken dougmencken at gmail dot com --- Re-tried without forcing -O3, and with default -O2 4.9.1 doesn't complain on stages 23 comparison.
