[Bug middle-end/62103] Incorrect folding of bitfield in a union on big endian targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62103 --- Comment #12 from Thomas Preud'homme --- Author: thopre01 Date: Wed Feb 4 08:22:45 2015 New Revision: 220390 URL: https://gcc.gnu.org/viewcvs?rev=220390&root=gcc&view=rev Log: 2015-02-04 Thomas Preud'homme gcc/ PR middle-end/62103 * tree-ssa-sccvn.c (fully_constant_vn_reference_p): Use TYPE_PRECISION to compute size of referenced value in the constant case. gcc/testsuite/ PR middle-end/62103 * gcc.c-torture/execute/bitfld-7.c: New test adapted from bitfld-6.c to use 24 bits for bitfield b. Added: trunk/gcc/testsuite/gcc.c-torture/execute/bitfld-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug rtl-optimization/64756] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64756 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC|jakub at gcc dot gnu.org | Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467 --- Comment #7 from renlin at gcc dot gnu.org --- Author: renlin Date: Wed Feb 4 09:24:56 2015 New Revision: 220392 URL: https://gcc.gnu.org/viewcvs?rev=220392&root=gcc&view=rev Log: [PATCH][libstdc++][Testsuite] isctype test fails for newlib. libstdc++-v3/ 2015-02-02 Matthew Wahab PR libstdc++/64467 * testsuite/28_regex/testsuiteraits/char/isctype.cc (test01): Add newlib special case for '\n'. * test01estsuite/28_regex/traits/wchar_t/isctype.cc (test01): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc trunk/libstdc++-v3/testsuite/28_regex/traits/wchar_t/isctype.cc
[Bug fortran/64932] [5.0] ICE on module end, gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64932 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-04 CC||burnus at gcc dot gnu.org Known to work||4.7.2, 4.8.2 Ever confirmed|0 |1 Known to fail||5.0 --- Comment #1 from Tobias Burnus --- Reduced test case: module coo_graphs implicit none type :: dynamic_array integer :: length, capacity, min_capacity integer, allocatable :: array(:) end type type :: coo_graph type(dynamic_array) :: edges(2) integer, private :: ne end type coo_graph contains subroutine coo_dump_edges(g, edges) class(coo_graph), intent(in) :: g integer, intent(out) :: edges(:,:) end subroutine coo_dump_edges end module coo_graphs
[Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812
Timo Teräs changed:
What|Removed |Added
CC||timo.teras at iki dot fi
--- Comment #3 from Timo Teräs ---
I can reproduce this, but unfortunately I don't have minimalistic test case
yet.
As a workaround removing -fvisibility-inlines-hidden from the build flags,
makes things work in the libreoffice.
What is involved / happening is:
The non-virtual thunks are in a DSO, but marked hidden. This is caused by
-fvisibility-inlines-hidden. The ::acquire members are virtual, but with inline
implementation (no inline marking / attribute though). The class itself is
marked __attribute__((visibility("default"))).
It appears that the places getting these unresolved symbols are trying to call
external symbol, even though it's inline implementation.
Apparently optimization flags, code context affects when this happens.
The symptoms sounds very much similar to what was in llvm:
http://llvm.org/bugs/show_bug.cgi?id=12255
[Bug fortran/64932] [4.9/5.0 Regression] ICE in gfc_conv_descriptor_data_get for generated finalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64932 Tobias Burnus changed: What|Removed |Added Target Milestone|--- |4.9.3 Summary|[5.0] ICE on module end,|[4.9/5.0 Regression] ICE in |gfc_conv_descriptor_data_ge |gfc_conv_descriptor_data_ge |t |t for generated finalizer --- Comment #2 from Tobias Burnus --- The problem seems to occur in the finalizer, i.e. __final_coo_graphs_Coo_graph for the component ref (ptr2 is of type coo_graph): ptr2->edges which is an array_type - but with fixed bounds; it fails in gfc_conv_descriptor_data_get for line 157 gcc_assert (GFC_DESCRIPTOR_TYPE_P (type));
[Bug fortran/64933] New: ASSOCIATE on a character variable does not allow substring expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64933 Bug ID: 64933 Summary: ASSOCIATE on a character variable does not allow substring expressions Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: olivier.marsden at ecmwf dot int Created attachment 34662 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34662&action=edit gfortran 5.0 ICE output for test case The following program is generating an ICE with gcc-5-20150201, and fails with ASSOCIATE(should_work=>char_var) Error: Associate-name 'should_work' at (1) is used as array for gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux) The ICE output is attached. program test_this implicit none character(len=15) :: char_var ASSOCIATE(should_work=>char_var) should_work = "test succesful" print *, should_work(5:14) END ASSOCIATE end program
[Bug fortran/64933] ASSOCIATE on a character variable does not allow substring expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64933 --- Comment #1 from Olivier Marsden --- Comment on attachment 34662 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34662 gfortran 5.0 ICE output for test case > > print *, should_work(5:15) > 1 >internal compiler error: Segmentation fault >0xb7c62f crash_signal >../../gcc-5-20150201/gcc/toplev.c:383 >0x6ebf4b gfc_conv_scalarized_array_ref >../../gcc-5-20150201/gcc/fortran/trans-array.c:3068 >0x6ec911 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*) >../../gcc-5-20150201/gcc/fortran/trans-array.c:3205 >0x719865 gfc_conv_variable >../../gcc-5-20150201/gcc/fortran/trans-expr.c:2203 >0x716f92 gfc_conv_expr(gfc_se*, gfc_expr*) >../../gcc-5-20150201/gcc/fortran/trans-expr.c:6836 >0x71c3e4 gfc_conv_expr_reference(gfc_se*, gfc_expr*) >../../gcc-5-20150201/gcc/fortran/trans-expr.c:6928 >0x742c0f gfc_trans_transfer(gfc_code*) >../../gcc-5-20150201/gcc/fortran/trans-io.c:2394 >0x6e2777 trans_code >../../gcc-5-20150201/gcc/fortran/trans.c:1853 >0x740670 build_dt >../../gcc-5-20150201/gcc/fortran/trans-io.c:1921 >0x6e2797 trans_code >../../gcc-5-20150201/gcc/fortran/trans.c:1825 >0x75a11c gfc_trans_block_construct(gfc_code*) >../../gcc-5-20150201/gcc/fortran/trans-stmt.c:1457 >0x6e2887 trans_code >../../gcc-5-20150201/gcc/fortran/trans.c:1755 >0x70e088 gfc_generate_function_code(gfc_namespace*) >../../gcc-5-20150201/gcc/fortran/trans-decl.c:5844 >0x69f880 translate_all_program_units >../../gcc-5-20150201/gcc/fortran/parse.c:5341 >0x69f880 gfc_parse_file() >../../gcc-5-20150201/gcc/fortran/parse.c:5538 >0x6df605 gfc_be_parse_file >../../gcc-5-20150201/gcc/fortran/f95-lang.c:228 >Please submit a full bug report, >with preprocessed source if appropriate. >Please include the complete backtrace with any bug report. >
[Bug middle-end/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 Hans de Goede changed: What|Removed |Added CC||jwrdegoede at fedoraproject dot or ||g --- Comment #15 from Hans de Goede --- Hi Segher, Great to hear that you're working on this. I just hit this while trying to get the u-boot SPL (bootstrap loader, which must fit in internal SoC SRAM) down in size, so it would be great to see a fix for this. Regards, Hans
[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631 --- Comment #16 from Eric Botcazou --- > The cost of expression "p + ((sizetype)(99 - i_6(D)) + 1) * 4" computed > using normal +/-/* operators on sparc64 is 18, but the cost is 32 if it is > computed as "p + ((sizetype)(99 - i_6(D)) + 1) << 2", which is returned by > get_shiftadd_cost. How do you get the first number exactly? Note that the costs of shiftadd is completely skewed (by a factor of 3) because expmed.c computes it as a multadd instead of a shiftadd: Breakpoint 2, init_expmed_one_mode (all=0x7fffd540, mode=QImode, speed=1) at /home/eric/svn/gcc/gcc/expmed.c:219 219 set_shiftadd_cost (speed, mode, m, set_src_cost (all->shift_add, speed)); (gdb) p debug_rtx(all->shift_add) (plus:QI (mult:QI (reg:QI 109 [0]) (const_int 2 [0x2])) (reg:QI 109 [0])) but this should ensure that the costs are roughly the same for the expressions. > From the assembly code, it seems the computation is expensive on sparc64, I > may skip the test for these architectures if no other solutions. The hitch is that the code generated for 32-bit SPARC (where the test passes) is the optimal one and is also valid for 64-bit SPARC.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux and aarch64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 Maxim Kuvyrkov changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu.org --- Comment #48 from Maxim Kuvyrkov --- Discussing this issue with Arnd Bergmann (kernel developer) and Christophe Lyon, here is the analysis and how, I think, we should fix it: The /manifesting/ issue is that definitions of __kernel_old_uid_t and __kernel_old_gid_t have changed in AArch64 kernel headers several months ago. This was a correct bug fix on kernel's part. For various reason libsanitizer uses its own definitions of corresponding data types (instead of including kernel headers), which, still, should match the kernel definitions. The /underlying/ issue is that libsanitizer is trying to handle compat syscalls that should never occur in userspace. Specifically, at least __NR_getresuid16 and __NR_setresuid16 will never occur in native AArch64 code and are present in the kernel for benefit of AArch32 applications running on AArch64 systems. More generally, all references to __NR_uid16 and __NR_gid16 syscalls should be surrounded with #ifdef __NR_uid32 // References to __NR_uid16 are OK #endif ... and similar for __NR_gid16 syscalls. Quoting Arnd: When __NR_uid32 is present, then __NR_uid refers to the uid16 version. If __NR_uid32 does not exist, this means that __NR_uid refers to the uid32 version. In summary, this problem affects several targets, of which AArch64 is one. I believe the fix is confined to lib/sanitizer_common/sanitizer_common_syscalls.inc and is a fairly mechanical one. The last bit of business left is for someone to implement the above fix, test it, and commit to both LLVM and GCC.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux and aarch64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 Maxim Kuvyrkov changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |christophe.lyon at st dot com --- Comment #49 from Maxim Kuvyrkov --- Christophe, Are you working on this issue?
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888 --- Comment #29 from Jakub Jelinek --- Perhaps you can emit another symbol covering the original size plus padding in that case on targets where linker can do something so problematic. So you'd end up having e.g. symbol varfoo addr=0x1234500 size=32 __asan_var.varfoo addr=0x1234500 size=64 (replace . with whatever char can be used in object format's identifiers and if at all possible is not allowed in C/C++ identifiers). Or would Mach-O still attempt to tear it appart? That would sound like a bug to me.
[Bug target/64408] fr30-elf ICE in extract_insn, at recog.c:2202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64408 --- Comment #1 from Nick Clifton --- Author: nickc Date: Wed Feb 4 13:42:26 2015 New Revision: 220400 URL: https://gcc.gnu.org/viewcvs?rev=220400&root=gcc&view=rev Log: PR target/64408 * config/fr30/predicates.md (di_operand): Add SUBREG to the list of accepted codes. (nonimmediate_di_operand): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/fr30/predicates.md
[Bug target/64408] fr30-elf ICE in extract_insn, at recog.c:2202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64408 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Fixed by: https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00247.html
[Bug target/64407] xstormy16-elf: ICE in simplify_const_unary_operation, at simplify-rtx.c:1730
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64407 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- This is fixed in the mainline sources. I have not tracked where though. Cheers Nick
[Bug rtl-optimization/64905] unsigned short is loaded with 4-byte load (movl)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64905 Uroš Bizjak changed: What|Removed |Added CC||law at redhat dot com Component|target |rtl-optimization --- Comment #4 from Uroš Bizjak --- It looks the failure is due to: emit-rtl.c: REGNO_POINTER_ALIGN (HARD_FRAME_POINTER_REGNUM) = STACK_BOUNDARY; The testcase forces the pointer to %rbp (== HARD_FRAME_POINTER_REGNUM in the above line), so the predicate thinks that the value in %rbp is aligned, since %rbp has its REGNO_POINTER_ALIGN set to STACK_BOUNDARY. Looks like generic RTL infrastructure problem to me, the REGNO_POINTER_ALIGNMENT of hard_frame_pointer should be cleared when H_F_P is omitted and reused.
[Bug debug/64817] [5 Regression] compilation hangs at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64817 --- Comment #7 from Alexandre Oliva --- Author: aoliva Date: Wed Feb 4 14:23:33 2015 New Revision: 220404 URL: https://gcc.gnu.org/viewcvs?rev=220404&root=gcc&view=rev Log: Avoid allocating memory when trying but failing to simplify XOR of AND. for gcc/ChangeLog PR debug/64817 * simplify-rtx.c (simplify_binary_operation_1): Rewrite simplification of XOR of AND to not allocate new rtx before committing to a simplification. Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c
[Bug debug/64817] [5 Regression] compilation hangs at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64817 --- Comment #8 from Alexandre Oliva --- Author: aoliva Date: Wed Feb 4 14:23:47 2015 New Revision: 220405 URL: https://gcc.gnu.org/viewcvs?rev=220405&root=gcc&view=rev Log: Simplify XOR of (AND or IOR) of XOR. for gcc/ChangeLog PR debug/64817 * simplify-rtx.c (simplify_binary_operation_1): Simplify one of two XORs that have an intervening AND or IOR. Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c
[Bug debug/64817] [5 Regression] compilation hangs at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64817 --- Comment #9 from Alexandre Oliva --- Author: aoliva Date: Wed Feb 4 14:24:00 2015 New Revision: 220406 URL: https://gcc.gnu.org/viewcvs?rev=220406&root=gcc&view=rev Log: Fix signedness of compares expanding debug exprs. for gcc/ChangeLog PR debug/64817 * cfgexpand.c (expand_debug_expr): Compute unsignedp from operands for tcc_comparison exprs. Fix typos. for gcc/testsuite/ChangeLog PR debug/64817 * gcc.dg/pr64817-3.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr64817-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog
[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #22 from Jakub Jelinek --- Considering this fixed with latest PR64817 fixes.
[Bug c++/64934] New: The french text of --version is not proper french
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64934 Bug ID: 64934 Summary: The french text of --version is not proper french Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pierreblavy at yahoo dot fr Hello! gcc --version displays gcc (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1) Copyright © 2014 Free Software Foundation, Inc. Ce logiciel est libre; voir les sources pour les conditions de copie. Il n'y a PAS GARANTIE; ni implicite pour le MARCHANDAGE ou pour un BUT PARTICULIER. We say in french : Ce logiciel est un logiciel libre, voir les sources pour les conditions de copie, de distribution et de modification. Il est fourni en l'état, sans aucune sorte de garantie explicite ou implicite, y compris les garanties de commercialisation ou d'adaptation dans un but particulier. Or, if you need a shorder text: Ceci est un logiciel LIBRE. Il est fourni tel quel sans AUCUNE GARANTIE. Pour plus de détail, voir les sources. - Replacing the "voir les sources" by a link to the license file will be helpful. -Citing the type of license (GPL3 I presume) will be more useful than saying "logiciel libre" For a GPL french traduction, please see : http://www.linux-france.org/article/these/gpl.html Best regards.
[Bug target/64935] New: [5 Regression] compare debug failure during building of Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935 Bug ID: 64935 Summary: [5 Regression] compare debug failure during building of Linux kernel Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu Created attachment 34663 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34663&action=edit unreduced testcase trippels@gcc2-power8 linux-3.17.6 % GCC_COMPARE_DEBUG=1 /home/trippels/gcc_test/usr/local/bin/gcc -std=gnu89 -O2 -c wp512.i gcc: error: wp512.i: -fcompare-debug failure (length) Creduce is running...
[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631 --- Comment #17 from Eric Botcazou --- This looks a generic problem in get_shiftadd_cost to me, it ought to mimic the algorithms in expmed.c, something like: @@ -3597,22 +3597,26 @@ get_shiftadd_cost (tree expr, machine_mo tree multop = TREE_OPERAND (mult, 0); int m = exact_log2 (int_cst_value (cst)); int maxm = MIN (BITS_PER_WORD, GET_MODE_BITSIZE (mode)); - int sa_cost; - bool equal_p = false; + int as_cost, sa_cost; + bool mult_in_op1; if (!(m >= 0 && m < maxm)) return false; - if (operand_equal_p (op1, mult, 0)) -equal_p = true; + mult_in_op1 = operand_equal_p (op1, mult, 0); + as_cost = add_cost (speed, mode) + shift_cost (speed, mode, m); + + /* If the target has a cheap shift-and-add or shift-and-sub instruction, + use that in preference to a shift insn followed by an add insn. */ sa_cost = (TREE_CODE (expr) != MINUS_EXPR ? shiftadd_cost (speed, mode, m) - : (equal_p + : (mult_in_op1 ? shiftsub1_cost (speed, mode, m) : shiftsub0_cost (speed, mode, m))); - res = new_cost (sa_cost, 0); - res = add_costs (res, equal_p ? cost0 : cost1); + + res = new_cost (MIN (as_cost, sa_cost), 0); + res = add_costs (res, mult_in_op1 ? cost0 : cost1); STRIP_NOPS (multop); if (!is_gimple_val (multop))
[Bug translation/64934] The french text of --version is not proper french
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64934 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||fxcoudert at gcc dot gnu.org Component|c++ |translation --- Comment #1 from Tobias Burnus --- BTW: GCC translations are handled via http://translationproject.org/team/fr.html
[Bug c++/64936] New: regex, ECMA treated as posix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64936
Bug ID: 64936
Summary: regex, ECMA treated as posix
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pierreblavy at yahoo dot fr
Hi!
I've tested gcc regex with the following code (seen on
http://en.cppreference.com/w/cpp/regex/syntax_option_type). According to this
website, I expect ECMA to match zzxa, and not zzxayy. I don't know if it's gcc
or cppreference.com that's wrong.
--- test code ---
int main()
{
std::string str = "zzxayyzz";
std::regex re1(".*(a|xayy)"); // ECMA
std::regex re2(".*(a|xayy)", std::regex::extended); // POSIX
std::cout << "Searching for .*(a|xayy) in zzxayyzz:\n";
std::smatch m;
std::regex_search(str, m, re1);
std::cout << " ECMA (depth first search) match: " << m[0] << '\n'; //expect
zzxa, have zzxayy ==> WRONG
std::regex_search(str, m, re2);
std::cout << " POSIX (leftmost longest) match: " << m[0] << '\n'; //expect
zzxayy, have zzxayy ==> OK
}
[Bug translation/64934] The french text of --version is not proper french
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64934 --- Comment #2 from Tobias Burnus --- The link I posted was regarding the translation of the strings: "This is free software; see the source for copying conditions. There is NO\n" "warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n" "\n" and "This is free software; see the source for copying conditions.\n" "There is NO warranty; not even for MERCHANTABILITY or \n" "FITNESS FOR A PARTICULAR PURPOSE.\n" "\n" If one wants to change the English version, it would be a different bug component. Regarding the license: A simple link doesn't help as GCC uses multiple licenses: GPL3+ for the compiler, GPL3+ with GCC exception for several libraries, LGPL2+ or BSD license for some other libraries.
[Bug c++/64901] [4.9/5 Regression] overriding final function defined out of line does not lead to an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64901 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Feb 4 15:38:50 2015 New Revision: 220409 URL: https://gcc.gnu.org/viewcvs?rev=220409&root=gcc&view=rev Log: 2015-02-04 Ville Voutilainen PR c++/64901 * decl.c (duplicate_decls): Also duplicate DECL_FINAL_P and DECL_OVERRIDE_P. Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/decl.c branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/override1.C
[Bug c++/64901] [4.9/5 Regression] overriding final function defined out of line does not lead to an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64901 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.3 --- Comment #4 from Paolo Carlini --- Fixed for 4.9.3.
[Bug go/64900] gotools don't link on Solaris 11/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64900
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Ian Lance Taylor ---
> Normally libgo.so will get the symbol _Unwind_GetLanguageSpecificData from
> libgcc_s.so. The first step here is to find out why that didn't happen. Was
> libgo.so not linked against libgcc_s.so? Does libgcc_s.so not define
It wasn't: it turns out that Solaris 11/SPARC and x86 differ in their
libgcc spec (sparc vs. x86):
*libgcc:
-%{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared:%{!s
hared-libgcc:-lgcc -lgcc_eh}%{shared-libgcc:-lgcc_s
-lgcc}}%{shared:%{shared-lib
gcc:-lgcc_s}%{!shared-libgcc:-lgcc
+%{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libg
cc:-lgcc --as-needed -lgcc_s --no-as-needed}%{shared-libgcc:-lgcc_s%{!shared:
-l
gcc
On x86, --as-needed support in gld was disabled due to binutils PR
ld/12320 (cf. gcc/configure.ac), thus libgcc_s is only linked with
-shared when explicitly specifying -shared-libgcc.
> _Unwind_GetLanguageSpecificData?
It does.
The following patch allowed me to correctly link libgo.so with
libgcc_s.so, and as expected, gotools also link without problems:
diff --git a/libgo/Makefile.am b/libgo/Makefile.am
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -1991,7 +1991,8 @@ libgo_go_objs = \
unicode/utf8.lo
libgo_ldflags = \
--version-info $(libtool_VERSION) $(PTHREAD_CFLAGS) $(AM_LDFLAGS)
+-version-info $(libtool_VERSION) -Wc,-shared-libgcc \
+$(PTHREAD_CFLAGS) $(AM_LDFLAGS)
libgo_libadd = \
$(libgo_go_objs) ../libbacktrace/libbacktrace.la \
Rainer
[Bug rtl-optimization/64905] unsigned short is loaded with 4-byte load (movl)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64905 H.J. Lu changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #5 from H.J. Lu --- (In reply to Uroš Bizjak from comment #4) > It looks the failure is due to: > > emit-rtl.c: REGNO_POINTER_ALIGN (HARD_FRAME_POINTER_REGNUM) = > STACK_BOUNDARY; > > The testcase forces the pointer to %rbp (== HARD_FRAME_POINTER_REGNUM in the > above line), so the predicate thinks that the value in %rbp is aligned, > since %rbp has its REGNO_POINTER_ALIGN set to STACK_BOUNDARY. > > Looks like generic RTL infrastructure problem to me, the > REGNO_POINTER_ALIGNMENT of hard_frame_pointer should be cleared when H_F_P > is omitted and reused. Like this diff --git a/gcc/ira.c b/gcc/ira.c index ea2b69f..a7cf476 100644 --- a/gcc/ira.c +++ b/gcc/ira.c @@ -2313,6 +2313,8 @@ ira_setup_eliminable_regset (void) if (frame_pointer_needed) df_set_regs_ever_live (HARD_FRAME_POINTER_REGNUM, true); + else +REGNO_POINTER_ALIGN (HARD_FRAME_POINTER_REGNUM) = 0; COPY_HARD_REG_SET (ira_no_alloc_regs, no_unit_alloc_regs); CLEAR_HARD_REG_SET (eliminable_regset);
[Bug target/64935] [5 Regression] compare debug failure during building of Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-04 CC||mkuvyrkov at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Started with r220316. Creduce came up with an invalid testcase. Re-reducing...
[Bug target/64935] [5 Regression] compare debug failure during building of Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- Created attachment 34664 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34664&action=edit Test case failing with g++ -fsanitize=address test.ii The attached test case fails for me with GCC_COMPARE_DEBUG=yes g++ test.ii -fsanitize=address with the same message: g++: error: test.ii: -fcompare-debug failure (length)
[Bug target/64935] [5 Regression] compare debug failure during building of Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935 --- Comment #3 from Tobias Burnus --- (In reply to Tobias Burnus from comment #2) > The attached test case fails for me with > with the same message: > g++: error: test.ii: -fcompare-debug failure (length) That's with x86-64-gnu-linux in my case.
[Bug go/64900] gotools don't link on Solaris 11/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64900 --- Comment #3 from Ian Lance Taylor --- Unfortunately that patch breaks the build on x86 GNU/Linux. The problem is that the split-stack support (the __morestack symbol) must be linked into the shared library directly, not via -lgcc_s. So it's necessary to link with -lgcc also. The correct link on x86 GNU/Linux is -lgcc -lgcc_s, but using -shared-libgcc only links with -lgcc_s. I think -lgcc -lgcc_s should also work on x86 Solaris, as the problematic symbol is in -lgcc_eh, not -lgcc. But I'm not sure about the best way to get that, as not all systems support -lgcc_s.
[Bug middle-end/64937] New: [5 Regression] compare debug failure with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64937 Bug ID: 64937 Summary: [5 Regression] compare debug failure with -fsanitize=address Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Split-off from PR64935, which shows the same message but is caused by a different revision. The attached test case fails for me with GCC_COMPARE_DEBUG=yes g++ test.ii -fsanitize=address with the same message: g++: error: test.ii: -fcompare-debug failure (length) Test case is attachment 34664 Works with current 4.9 branch, fails with today's trunk and also with r220315 (the other PR, PR64935, works with that revision).
[Bug debug/64935] [5 Regression] compare debug failure during building of Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935 --- Comment #4 from Tobias Burnus --- (In reply to Markus Trippelsdorf from comment #1) > Started with r220316. Mine (comment 2) also fails with r220315 - but it is also a 5.0 regression. Hence, I filled a new PR for it: PR64937.
[Bug tree-optimization/64878] [5 Regression] Miscompilation of nntpgrab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
--- Comment #5 from Sebastian Pop ---
Created attachment 34665
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34665&action=edit
fix
The problem is that we jump thread twice across the loop latch:
first, from
case '{':
a = 0;
b = 15;
f = f10 ();
x->c2++;
break;
through the loop latch to:
case 0:
if (c == ' ')
x->c2++;
else if (c == '/')
{
a = 4;
j = x->c2++;
}
else
a = b;
and second, from "a = b;" again across the loop latch to case 15.
Attached patch fixes the wrong code and passes make check.
[Bug target/64408] fr30-elf ICE in extract_insn, at recog.c:2202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64408 --- Comment #3 from Yaakov Selkowitz --- (In reply to Nick Clifton from comment #2) > Fixed by: > > https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00247.html Fix confirmed with 4.9.2; thanks.
[Bug c/47781] warnings from custom printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #13 from Tom Tromey --- (In reply to jos...@codesourcery.com from comment #12) > On Thu, 29 Jan 2015, tromey at gcc dot gnu.org wrote: > > > E.g., firefox has a logging printf that accepts "%hs" to print char16_t* > > strings. This extension means that printf checking can't be used here. > > Requiring a plugin to deal with this situation would also be difficult. > > However letting one write __attribute__((printf, 1, 2, "hs", char16_t*)) > > would solve this nicely. > > Do you then take this as being length modifier 'h' followed by format > specifier 's', or is it a complete specifier on its own with everything > that would otherwise be length and specifier being reparsed as an > extension if it can't be parsed as a standard format? Do the flags "-wp" > and "cR" for %s formats apply to this format? I see what you mean -- maybe "simple" isn't straightforward. I have been reconsidering the plugin approach given some new things I learned about the details of the firefox code (namely that it doesn't faithfully follow printf semantics, sigh). One additional note for this bug is that it would be nice if any such addition by a plugin worked properly with -Wmissing-format-attribute.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux and aarch64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 clyon at gcc dot gnu.org changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #50 from clyon at gcc dot gnu.org --- Yes, I am looking at it.
[Bug tree-optimization/64878] [5 Regression] Miscompilation of nntpgrab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878 --- Comment #6 from Jakub Jelinek --- (In reply to Sebastian Pop from comment #5) > Created attachment 34665 [details] > fix Thanks for working on this. s/accross/across/. Please mail it to gcc-patches once you test it.
[Bug debug/64935] [5 Regression] compare debug failure during building of Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935 Maxim Kuvyrkov changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mkuvyrkov at gcc dot gnu.org --- Comment #5 from Maxim Kuvyrkov --- Will investigate tomorrow. The patch in question fixed a debug miscompare problem on arm-linux-gnueabi.
[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922 Jan Hubicka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #5 from Jan Hubicka --- Yes, I will take a look. Removal of args is still on my TODO list :(
[Bug middle-end/64937] [5 Regression] compare debug failure with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64937 Tobias Burnus changed: What|Removed |Added Target Milestone|--- |5.0 --- Comment #1 from Tobias Burnus --- That's with x86-64-gnu-linux. It already failed with r218247; I currently don't plan to bisect it further.
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888 --- Comment #30 from Eric Christopher --- That might be reasonable. As far as I know ld64 doesn't do that yet, but I know it's been thought about.
[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 Paul Thomas changed: What|Removed |Added CC||jaydub66 at gmail dot com --- Comment #6 from Paul Thomas --- (In reply to H.J. Lu from comment #2) > I got > > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > > Backtrace for this error: > #0 0xF763FACE > #1 0xF763EBDE > #2 0xF773CBBF > #3 0x8048BA5 in __final_main_T2.3337 at class_allocate_18.f90:? > #4 0x8048D68 in __final_main_T3.3328 at class_allocate_18.f90:? > #5 0x8048A59 in MAIN__ at class_allocate_18.f90:? > FAIL: gfortran.dg/class_allocate_18.f90 -O1 execution test > > But I couldn't reproduce it on another machine. I will keep an eye on it. Hi HJ, Given that the error is sporadic, are you sure that the offending revisions are not 220125 and 220130 - PR64230. The error messages that you are getting are remarkably similar to the original report for this PR. In the case of PR62044, the fix only applies to allocation with MOLD = derived type. class_allocate_18.f90 involves a CLASS entity and does not use MOLD = anything. I will investigate if there is not some horrible kludge that is spoofing up the allocate expression in class_allocate_18.f90 by passing the typespec through a hidden MOLD expression. If this is not the case, there is nothing that I can do. I'll come back to you in about twenty minutes. I have put Janus in copy. Cheers Paul
[Bug rtl-optimization/64688] [4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688 --- Comment #18 from Vladimir Makarov --- (In reply to Jeffrey A. Law from comment #17) > > Vlad & Jakub are in the best position to decide if this ought to be > backported. I am agree with Jakub. I'd wait for 2 weeks. Frequently a fix in this part of LRA results in other bugs.
[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 --- Comment #7 from H.J. Lu --- (In reply to Paul Thomas from comment #6) > (In reply to H.J. Lu from comment #2) > > I got > > > > Program received signal SIGSEGV: Segmentation fault - invalid memory > > reference. > > > > Backtrace for this error: > > #0 0xF763FACE > > #1 0xF763EBDE > > #2 0xF773CBBF > > #3 0x8048BA5 in __final_main_T2.3337 at class_allocate_18.f90:? > > #4 0x8048D68 in __final_main_T3.3328 at class_allocate_18.f90:? > > #5 0x8048A59 in MAIN__ at class_allocate_18.f90:? > > FAIL: gfortran.dg/class_allocate_18.f90 -O1 execution test > > > > But I couldn't reproduce it on another machine. I will keep an eye on it. > > Hi HJ, > > Given that the error is sporadic, are you sure that the offending revisions > are not 220125 and 220130 - PR64230. The error messages that you are getting > are remarkably similar to the original report for this PR. > I don't know for sure. This failure seems more consistent on 4.9 branch than on trunk.
[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922 --- Comment #6 from Jan Hubicka --- Created attachment 34666 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34666&action=edit Patch I am testing. The following patch fixes the parameters, but I do not get any ubsan_unreachable calls. Jakub, can you take a look, please?
[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922 --- Comment #7 from Jakub Jelinek --- (In reply to Jan Hubicka from comment #6) > Created attachment 34666 [details] > Patch I am testing. > > The following patch fixes the parameters, but I do not get any > ubsan_unreachable calls. Jakub, can you take a look, please? Have you compiled the testcase with -fsanitize=alignment,bool,enum -O2 -D_GLIBCXX_USE_CXX11_ABI=0 , against recentish libstdc++ headers?
[Bug c/47781] warnings from custom printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #14 from Manuel López-Ibáñez --- (In reply to Tom Tromey from comment #13) > I have been reconsidering the plugin approach given some new things > I learned about the details of the firefox code (namely that it doesn't > faithfully follow printf semantics, sigh). > > One additional note for this bug is that it would be nice if any > such addition by a plugin worked properly with -Wmissing-format-attribute. Note that plugins can define attributes. Perhaps one way to go about this would be to create a plugin that parsed some kind of GCC_printf_format_info attribute that matches GCC internal printf checking. Then move GCC own format checking to use this attribute and enable the plugin by default when building GCC. This will give you as much flexibility as GCC format checking supports, and the plugin will be developed, build, tested and distributed alongside GCC. Users outside GCC just need to use the plugin and add the attributes to their own printf-style functions. Moreover, since the plugin is developed alongside GCC, it would be logical to add whatever hooks the plugin needs. Moreover, nothing stops users from creating some kind of intermediate language that simplifies custom printf attribute syntax. Probably some C preprocessor magic could be enough. The challenge is the define the syntax of the attribute, but I think this challenge is unavoidable for whoever wants to implement this. You may present a simplified syntax to the user, but you still need to handle correctly all the complexity and corner cases in c-format.c.
[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 --- Comment #8 from Paul Thomas --- (In reply to H.J. Lu from comment #7) > (In reply to Paul Thomas from comment #6) > > (In reply to H.J. Lu from comment #2) > > > I got > > > > > > Program received signal SIGSEGV: Segmentation fault - invalid memory > > > reference. > > > > > > Backtrace for this error: > > > #0 0xF763FACE > > > #1 0xF763EBDE > > > #2 0xF773CBBF > > > #3 0x8048BA5 in __final_main_T2.3337 at class_allocate_18.f90:? > > > #4 0x8048D68 in __final_main_T3.3328 at class_allocate_18.f90:? > > > #5 0x8048A59 in MAIN__ at class_allocate_18.f90:? > > > FAIL: gfortran.dg/class_allocate_18.f90 -O1 execution test > > > > > > But I couldn't reproduce it on another machine. I will keep an eye on it. > > > > Hi HJ, > > > > Given that the error is sporadic, are you sure that the offending revisions > > are not 220125 and 220130 - PR64230. The error messages that you are getting > > are remarkably similar to the original report for this PR. > > > > I don't know for sure. This failure seems more consistent on 4.9 branch > than on trunk. Dear HJ, I can confirm that the part of resolve.c modified in r220191 is not visited by the compilation of class_allocate_18.f90. If I have understood correctly, -fPIC is not supported on x86_64 and so, unless I am mistaken, I cannot help you further. Please let me know if there is anything that I can do to help. Best regards Paul
[Bug target/64477] [4.9 Regression] x86 sse unnecessary GPR spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64477 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.9.3 |5.0 --- Comment #11 from Uroš Bizjak --- The fix is too risky for release branches (4.9-), where RA won't perform a r->m fixup on disabled alternative if Yi is used. The gcc will generate a dead store for TARGET_INTER_UNIT_MOVES_TO_VEC targets with vec_set_0, which is a minor issue. -mtune=generic generates correct code, since TARGET_INTER_UNIT_MOVES_TO_VEC is disabled in this case.
[Bug rtl-optimization/64907] Suboptimal code (saving rbx on stack in order to save another reg in rbx)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64907
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #2 from Vladimir Makarov ---
(In reply to H.J. Lu from comment #1)
> Still happens with 5.0.
It is an interesting case but I don't think it will be fixed for GCC-5.0. It
is hard for me to decide how to fix it. But even if I knew how do it it would
need a lot of changes in RA.
Before LRA we have:
2: r91:SI=di:SI
REG_DEAD di:SI
3: NOTE_INSN_FUNCTION_BEG
6: r92:SI=zero_extend(r91:SI#0)
7: di:SI=r92:SI
REG_DEAD r92:SI
8: call [`put_16bit'] argc:0
REG_DEAD di:SI
REG_CALL_DECL `put_16bit'
9: {r93:SI=r91:SI 0>>0x10;clobber flags:CC;}
REG_DEAD r91:SI
REG_UNUSED flags:CC
10: di:SI=r93:SI
REG_DEAD r93:SI
11: call [`put_16bit'] argc:0
P91 gets bx which is saved on in prologue/epilogue according to ABI. P91 can
not get di because of the conflict with its usage in insn range [7..8].
If we spill p91, we get the same code as before
2: bx:SI=di:SI
19: NOTE_INSN_DELETED
3: NOTE_INSN_FUNCTION_BEG
6: di:SI=zero_extend(bx:HI)
8: call [`put_16bit'] argc:0
REG_CALL_DECL `put_16bit'
16: di:SI=bx:SI
9: {di:SI=di:SI 0>>0x10;clobber flags:CC;}
11: call [`put_16bit'] argc:0
REG_CALL_DECL `put_16bit'
12: barrier
That is because of inheritance in LRA. If we spill p91 and prohibit the
inheritance, we get even worse code
2: [sp:DI+0xc]=di:SI
3: NOTE_INSN_FUNCTION_BEG
6: di:SI=zero_extend([sp:DI+0xc])
8: call [`put_16bit'] argc:0
REG_CALL_DECL `put_16bit'
16: di:SI=[sp:DI+0xc]
9: {di:SI=di:SI 0>>0x10;clobber flags:CC
11: call [`put_16bit'] argc:0
REG_CALL_DECL `put_16bit'
12: barrier
I don't think that the PR is important. If we already used ebx somewhere (it
means code with higher register pressure), the code would be ideal because ebx
is already saved for other purposes. So it is mostly a problem for such small
functions only.
Currently I see two solutions: implementation of splitting in IRA which will
be complicated or propagating di from insn 2 to insn 6 in the later code by
some later pass. It would be even more complicated as we need somehow to
decide that IRA should spill p91 and don't do inheritance for it in LRA.
Still I'll think about how to fix it in LRA. But again most probably the PR
will be not fixed for GCC-5.0.
[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 --- Comment #9 from Dominique d'Humieres --- > If I have understood correctly, -fPIC is not supported on x86_64 and so, > unless I am mistaken, I cannot help you further. This is not how I understand comment 1. Note that if I compile with -fsanitize=address, the executable crashes with allocated! = ==73209==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020e040 at pc 0x000103b59dbd bp 0x7fff5c0a6fa0 sp 0x7fff5c0a6f98 READ of size 8 at 0x6020e040 thread T0 #0 0x103b59dbc (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11dbc) #1 0x103b595aa (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x115aa) #2 0x103b59889 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11889) #3 0x103b5a7a6 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x127a6) #4 0x7fff8fd1e5c8 (/usr/lib/system/libdyld.dylib+0x35c8) #5 0x0 () 0x6020e040 is located 0 bytes to the right of 16-byte region [0x6020e030,0x6020e040) allocated by thread T0 here: #0 0x103b8d1fa (/opt/gcc/gcc4.10w/lib/libasan.2.dylib+0x2f1fa) #1 0x103b59642 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11642) #2 0x103b5a7a6 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x127a6) #3 0x7fff8fd1e5c8 (/usr/lib/system/libdyld.dylib+0x35c8) #4 0x0 () SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ?? Shadow bytes around the buggy address: 0x1c041bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c041bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c041bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c041be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c041bf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 01 fa =>0x1c041c00: fa fa 00 fa fa fa 00 00[fa]fa 07 fa fa fa 07 fa 0x1c041c10: fa fa 06 fa fa fa 00 06 fa fa 00 00 fa fa 03 fa 0x1c041c20: fa fa 00 06 fa fa 00 07 fa fa 00 fa fa fa 00 00 0x1c041c30: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00 0x1c041c40: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00 0x1c041c50: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00 I see this for r220302, r220156, r220109, and r219830 (i.e., all the revisions I have tested). Note that Janus has removed the -fsanitize=undefined option at r220181, while it worked for me provided I ran the test after install.
[Bug libstdc++/64929] [5 Regression] FAIL: libstdc++-prettyprinters/48362.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64929 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 64695 ***
[Bug libstdc++/64695] [5 Regression] FAIL: libstdc++-prettyprinters/cxx11.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64695 --- Comment #3 from H.J. Lu --- *** Bug 64929 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 --- Comment #10 from Dominique d'Humieres --- This is probably a duplicate of pr64849.
[Bug libstdc++/64695] [5 Regression] FAIL: libstdc++-prettyprinters/cxx11.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64695 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED CC||redi at gcc dot gnu.org Resolution|FIXED |--- --- Comment #4 from H.J. Lu --- It is caused by r219785 which changed std::tuple implementation and requires updating class StdTuplePrinter in python/libstdcxx/v6/printers.py
[Bug jit/64257] JIT documentation is not yet on the GCC website
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64257 --- Comment #7 from David Malcolm --- Author: dmalcolm Date: Wed Feb 4 19:11:48 2015 New Revision: 220412 URL: https://gcc.gnu.org/viewcvs?rev=220412&root=gcc&view=rev Log: More fixes for update_web_docs_svn for jit docs (PR jit/64257) gcc/jit/ChangeLog: PR jit/64257 * docs/conf.py (html_theme): Change from 'pyramid' to 'sphinxdoc'. maintainer-scripts/ChangeLog: PR jit/64257 * update_web_docs_svn: Update build of jit docs to use EPEL6 variant install of sphinx 1.0.8, rather than 0.6.6. Modified: trunk/gcc/jit/ChangeLog trunk/gcc/jit/docs/conf.py trunk/maintainer-scripts/ChangeLog trunk/maintainer-scripts/update_web_docs_svn
[Bug c/64868] C front-end rejects valid syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64868 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-02-04 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 34667 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34667&action=edit gcc5-pr64868.patch Untested fix.
[Bug debug/64935] [5 Regression] compare debug failure during building of Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935
--- Comment #6 from Markus Trippelsdorf ---
trippels@gcc2-power8 % cat wp512.i
int a[] = {}, b[] = {}, c[] = {}, d[] = {}, e[] = {}, f[] = {}, h[] = {};
int g[] = { 0 };
int i, l, s, w, x, y, z, t2, t3, t5;
unsigned long j, m, o, t4;
long k, n, p, q, r, t, u, v, t1;
fn1 ()
{
int t6;
for (; i; i++)
{
t5 = a[q] ^ b[p >> 1] ^ c[o >> 1 & 1] ^ d[n >> 1 & 1] ^ e[m >> 1 & 1]
^ f[l >> 1 & 1] ^ g[0] ^ h[j & 1];
t4 = a[j] ^ b[q >> 1] ^ c[p] ^ d[o] ^ e[n] ^ f[m] ^ g[l >> 8] ^ h[k];
t3 = a[k >> 1] ^ b[j & 5] ^ d[p >> 32] ^ e[o >> 4] ^ f[n >> 6]
^ g[m >> 8] ^ h[l];
t2 = a[l >> 6] ^ b[k & 1] ^ c[j >> 1] ^ d[q >> 32] ^ e[p >> 4]
^ f[o >> 6] ^ g[n >> 8] ^ h[m & 1];
t1 = a[m >> 6] ^ b[l & 1] ^ c[k & 15] ^ d[j >> 2] ^ e[q >> 4] ^ f[p >> 6]
^ g[o >> 8] ^ h[n & 1];
z = a[n >> 56] ^ b[m & 15] ^ c[l & 15] ^ d[k >> 2] ^ e[j >> 4]
^ f[q >> 6] ^ g[p >> 8] ^ h[o & 1];
y = a[o >> 56] ^ b[n & 15] ^ c[m >> 40] ^ d[l >> 2] ^ e[k >> 4]
^ f[j >> 6] ^ g[q >> 8] ^ h[p & 1];
x = a[p >> 56] ^ b[o & 15] ^ c[n >> 40] ^ d[m >> 2] ^ e[l >> 4]
^ f[k >> 6] ^ g[j >> 8] ^ h[q & 1];
q = j = t4;
k = t3;
l = t2;
m = t1;
n = z;
o = y;
p = a[t6] ^ b[0] ^ c[w] ^ d[v] ^ e[u] ^ f[t] ^ g[s] ^ h[r];
t4 = a[r >> 1] ^ b[t6 & 1] ^ d[w >> 1] ^ e[v >> 1] ^ f[u >> 1]
^ g[t >> 1] ^ h[s];
t3 = a[s >> 6] ^ b[r & 1] ^ c[t6 & 5] ^ d[0] ^ e[w >> 4] ^ f[v >> 6]
^ g[u >> 8] ^ h[t & 1];
t2 = a[t >> 6] ^ b[s] ^ c[r & 15] ^ d[t6 >> 1] ^ e[0] ^ f[w >> 6]
^ g[v >> 8] ^ h[u & 1];
t1 = a[u >> 6] ^ b[t & 15] ^ c[s & 5] ^ d[r >> 32] ^ e[t6 >> 4]
^ g[w >> 8] ^ h[v & 1];
z = a[v >> 56] ^ b[u >> 48 & 1] ^ c[t >> 40 & 1] ^ d[s] ^ e[r >> 1 & 1]
^ f[t6 >> 1 & 1] ^ g[0] ^ h[w & 1] ^ z;
t6 = t5;
r = t4;
s = 0;
t = u = t1;
v = z;
w = y;
}
}
trippels@gcc2-power8 % GCC_COMPARE_DEBUG=1 gcc -std=gnu89 -O2 -c wp512.i
gcc: error: wp512.i: -fcompare-debug failure (length)
[Bug rtl-optimization/64905] unsigned short is loaded with 4-byte load (movl)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64905 --- Comment #6 from hjl at gcc dot gnu.org --- Author: hjl Date: Wed Feb 4 19:35:17 2015 New Revision: 220414 URL: https://gcc.gnu.org/viewcvs?rev=220414&root=gcc&view=rev Log: Clear hard frame pointer alignment if not needed When hard frame pointer isn't needed, the register for hard frame pointer may be reused. This patch clears alignment on hard frame pointer if hard frame pointer isn't needed. gcc/ PR rtl-optimization/64905 * lra-eliminations.c (setup_can_eliminate): Clear hard frame pointer alignment if it isn't needed. gcc/testsuite/ PR rtl-optimization/64905 * gcc.target/i386/pr64905.c: New file. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/64905] unsigned short is loaded with 4-byte load (movl)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64905 H.J. Lu changed: What|Removed |Added Known to work||5.0 Known to fail||4.8.5, 4.9.3 --- Comment #7 from H.J. Lu --- Fixed in 5.0 so far.
[Bug rtl-optimization/64905] unsigned short is loaded with 4-byte load (movl)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64905 --- Comment #8 from Dominique d'Humieres --- AFAICT only the ChangeLogs have been committed.
[Bug target/64938] New: [4.9 Regression] ICE in symtab_remove_unreachable_nodes, at ipa.c:547 on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64938
Bug ID: 64938
Summary: [4.9 Regression] ICE in
symtab_remove_unreachable_nodes, at ipa.c:547 on
arm-linux-gnueabihf
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Created attachment 34668
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34668&action=edit
test case
$ arm-linux-gnueabihf-gcc -c -g -O2 -std=c++11 -Wno-attributes
-Wno-non-template-friend test.ii
test.ii:66:53: internal compiler error: in symtab_remove_unreachable_nodes, at
ipa.c:547
H Scopes::favScopes() const { return m_scopes; }
^
Please submit a full bug report,
with preprocessed source if appropriate.
configured with --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard
--with-mode=thumb
not seen on the trunk, introduced by backporting the fix for PR63970. Reverting
this backport lets the test case build.
[Bug target/64882] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64882 --- Comment #14 from uros at gcc dot gnu.org --- Author: uros Date: Wed Feb 4 20:00:48 2015 New Revision: 220415 URL: https://gcc.gnu.org/viewcvs?rev=220415&root=gcc&view=rev Log: Backport from mainline 2015-01-31 Uros Bizjak PR target/64882 * config/i386/predicates.md (address_no_seg_operand): Reject non-CONST_INT_P operands in invalid mode. Backport from mainline 2015-01-31 Uros Bizjak * config/i386/i386.md (*prefetch_prefetchw1): Remove mode of address_operand 0. Rename from *prefetch_prefetchwt1_. * config/i386/predicates.md (address_no_seg_operand): Call address_operand with VOIDmode. (vsib_address_operand): Ditto. testsuite/ChangeLog: Backport from mainline 2015-01-31 Uros Bizjak PR target/64882 * gcc.dg/torture/pr64882.c: New test. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.md branches/gcc-4_9-branch/gcc/config/i386/predicates.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/64938] [4.9 Regression] ICE in symtab_remove_unreachable_nodes, at ipa.c:547 on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64938 --- Comment #1 from Matthias Klose --- couldn't find any approval email on gcc-patches for the backport. Was this supposed to go to the gcc-4.9 google branch?
[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922 --- Comment #8 from Jakub Jelinek --- So, with the patch you've posted I get: $ /usr/src/gcc/obj/gcc/g++ -B /usr/src/gcc/obj/gcc/ `/usr/src/gcc/obj/x86_*/libstdc++-v3/scripts/testsuite_flags --build-includes` -E -o x.ii x.cc -O2 -D_GLIBCXX_USE_CXX11_ABI=0 $ /usr/src/gcc/obj/gcc/cc1plus -fsanitize=alignment,bool,enum,unreachable -O2 x.ii -quiet $ gcc -o x x.s /usr/src/gcc/obj/x86_64-unknown-linux-gnu/libsanitizer/ubsan/.libs/libubsan.a -lpthread -ldl /usr/src/gcc/obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so -Wl,-rpath,/usr/src/gcc/obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/ $ ./pol6 a x.cc:39:3: runtime error: execution reached a __builtin_unreachable() call And the unreachable calls in there are IMHO wrong.
[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922 --- Comment #9 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #8) > So, with the patch you've posted I get: > $ /usr/src/gcc/obj/gcc/g++ -B /usr/src/gcc/obj/gcc/ > `/usr/src/gcc/obj/x86_*/libstdc++-v3/scripts/testsuite_flags > --build-includes` -E -o x.ii x.cc -O2 -D_GLIBCXX_USE_CXX11_ABI=0 > $ /usr/src/gcc/obj/gcc/cc1plus -fsanitize=alignment,bool,enum,unreachable > -O2 x.ii -quiet > $ gcc -o x x.s > /usr/src/gcc/obj/x86_64-unknown-linux-gnu/libsanitizer/ubsan/.libs/libubsan. > a -lpthread -ldl > /usr/src/gcc/obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++. > so > -Wl,-rpath,/usr/src/gcc/obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/ > $ ./pol6 a > x.cc:39:3: runtime error: execution reached a __builtin_unreachable() call > > And the unreachable calls in there are IMHO wrong. /g++ -> /xg++ ./pol6 -> ./x Sorry, for the typos.
[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922 --- Comment #10 from Jakub Jelinek --- Created attachment 34669 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34669&action=edit x.ii Preprocessed source.
[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922 --- Comment #11 from Jan Hubicka --- Author: hubicka Date: Wed Feb 4 20:28:49 2015 New Revision: 220417 URL: https://gcc.gnu.org/viewcvs?rev=220417&root=gcc&view=rev Log: PR middle-end/64922 * gimple.c: Include gimple-ssa.h. (maybe_remove_unused_call_args): New function. * gimple.h (maybe_remove_unused_call_args): Declare. * cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Use it. * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): Likewise. * gimple-fold.c (gimple_fold_call): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/gimple-fold.c trunk/gcc/gimple.c trunk/gcc/gimple.h trunk/gcc/tree-ssa-pre.c
[Bug c/64939] New: ICE in extract_insn, at recog.c:2202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939 Bug ID: 64939 Summary: ICE in extract_insn, at recog.c:2202 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kbrow1i at gmail dot com While trying to build clisp-2.48 on 64-bit Cygwin: $ gcc -v -save-temps -I/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/gllib -ggdb -O2 -pipe -Wimplicit-function-declaration -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DUNICODE -I. -I$(/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/clisp -K boot -B /home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build -N /home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -q -b)/linkkit -c regexi.m.c -o regexi.o gcc: warning: -pipe ignored because -save-temps specified Using built-in specs. COLLECT_GCC=gcc Target: x86_64-pc-cygwin Configured with: /cygdrive/i/szsz/tmpp/gcc/gcc-4.9.2-2.x86_64/src/gcc-4.9.2/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.2-2.x86_64/src/gcc-4.9.2 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id Thread model: posix gcc version 4.9.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-I' '/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/gllib' '-ggdb' '-O2' '-pipe' '-Wimplicit-function-declaration' '-Wextra' '-Wswitch' '-Wcomment' '-Wpointer-arith' '-Wimplicit' '-Wreturn-type' '-Wmissing-declarations' '-Wno-sign-compare' '-Wno-format-nonliteral' '-O' '-falign-functions=4' '-D' 'UNICODE' '-I' '.' '-I' '/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/linkkit' '-c' '-o' 'regexi.o' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe -E -quiet -v -I /home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/gllib -I . -I /home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/linkkit -Dunix -idirafter /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../lib/../include/w32api -idirafter /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api -D UNICODE regexi.m.c -mtune=generic -march=x86-64 -Wimplicit-function-declaration -Wextra -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -falign-functions=4 -ggdb -fworking-directory -O2 -O -fpch-preprocess -o regexi.m.i ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/include" ignoring duplicate directory "/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api" #include "..." search starts here: #include <...> search starts here: /home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/gllib . /home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/linkkit /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include-fixed /usr/include /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../lib/../include/w32api End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-I' '/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/gllib' '-ggdb' '-O2' '-pipe' '-Wimplicit-function-declaration' '-Wextra' '-Wswitch' '-Wcomment' '-Wpointer-arith' '-Wimplicit' '-Wreturn-type' '-Wmissing-declarations' '-Wno-sign-compare' '-Wno-format-nonliteral' '-O' '-falign-functions=4' '-D' 'UNICODE' '-I' '.' '-I' '/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/linkkit' '-c' '-o' 'regexi.o' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe -fpreprocessed regexi.m.i -quiet -dumpbase regexi.m.c -mtune=generic -march=x86-64 -auxbase-strip regexi.o -ggdb -O2 -O -Wimplicit-function-declaration -Wextra -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-d
[Bug c/64939] ICE in extract_insn, at recog.c:2202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939 --- Comment #1 from Ken Brown --- Created attachment 34670 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34670&action=edit Preprocessed source
[Bug middle-end/64937] [5 Regression] compare debug failure with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64937 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I'll have a look tomorrow.
[Bug target/64882] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64882 --- Comment #15 from uros at gcc dot gnu.org --- Author: uros Date: Wed Feb 4 21:46:01 2015 New Revision: 220418 URL: https://gcc.gnu.org/viewcvs?rev=220418&root=gcc&view=rev Log: Backport from mainline 2015-01-31 Uros Bizjak PR target/64882 * config/i386/predicates.md (address_no_seg_operand): Reject non-CONST_INT_P operands in invalid mode. Backport from mainline 2015-01-31 Uros Bizjak * config/i386/predicates.md (lea_address_operand): Call address_operand with VOIDmode. (vsib_address_operand): Ditto. testsuite/ChangeLog: Backport from mainline 2015-01-31 Uros Bizjak PR target/64882 * gcc.dg/torture/pr64882.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr64882.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/predicates.md branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/64882] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64882 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Uroš Bizjak --- Fixed everywhere.
[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467 --- Comment #8 from Hans-Peter Nilsson --- Hm, considering the recently-applied patch at r220392, why does my autotester still see these fail at r220396?
[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922
--- Comment #12 from Jan Hubicka ---
OK, the devirtualization I see is for
_Z3getI10Code_BlockEbR2CSRKSsPT_.part.3.constprop.7
when it is inlined to
_ZN4FileC2ERKSs
outer type of original context is:
$6 = {offset = 0, speculative_offset = 0, outer_type = 0x7631f498,
speculative_outer_type = 0x0, maybe_in_construction = 0, maybe_derived_type =
1,
where outer_type is Code_Block. It gets combined with:
$10 = {offset = 0, speculative_offset = 0, outer_type = 0x76cb,
speculative_outer_type = 0x0, maybe_in_construction = 0, maybe_derived_type =
0,
speculative_maybe_derived_type = 0, invalid = 0, dynamic = 1}
where outer_type is basic_string
These two types are not related, so we go for invalid. The first type is
derived from fact that operator >> takes reference to Code_Block that seems OK.
The other is determined by
std::basic_string::basic_string (&D.13149, "X", &D.13150);
that is passed to
_62 = get (_30, &D.13149, _36);
So I think we confuse argument 2 of get with argument 1 of
get.part.3.
[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922 --- Comment #13 from Jan Hubicka --- Created attachment 34671 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34671&action=edit Patch I am testing OK, the problem is that we first speculatively devirtualize to the target while inlining. Martin's ipa-prop code does not expect that and forgets to update parm_index of the call to reflect effect of inlining (it was written expecting only full devirt)
[Bug c++/53637] NRVO not applied in branches when it could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637 marc at kdab dot com changed: What|Removed |Added CC||marc at kdab dot com --- Comment #1 from marc at kdab dot com --- Similar situation in https://codereview.qt-project.org/#/c/104079/1/src/network/ssl/qsslellipticcurve_openssl.cpp,unified (click on the comment in line 61 to see GCC 4.9.3 (from svn) disassembly. Qt is full of functions structured like that and it's not an option to rewrite them all. Lawrence Crowl calls (N)RVO the most important optimisation in C++, and it's really sad that GCC doesn't apply NRVO even in those cases where there is only one possible object returned per basic block, ie. where the compiler knows which object will be returned by at the time of construction of each object. It's even more sad that this report has been sitting here, unconfirmed and ignored by the GCC developers, for 19 months.
[Bug c/64868] C front-end rejects valid syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64868 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Feb 4 22:32:36 2015 New Revision: 220420 URL: https://gcc.gnu.org/viewcvs?rev=220420&root=gcc&view=rev Log: PR c/64824 PR c/64868 gcc/c/ * c-parser.c (c_parser_omp_atomic): Handle RDIV_EXPR. gcc/cp/ * parser.c (cp_parser_omp_atomic): Handle RDIV_EXPR. gcc/c-family/ * c-omp.c (c_finish_omp_atomic): Use TRUNC_DIV_EXPR instead of RDIV_EXPR. Use build_binary_op instead of build2_loc. libgomp/ * testsuite/libgomp.c/pr64824.c: New test. * testsuite/libgomp.c/pr64868.c: New test. * testsuite/libgomp.c++/pr64824.C: New test. * testsuite/libgomp.c++/pr64868.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr64824.C trunk/libgomp/testsuite/libgomp.c++/pr64868.C trunk/libgomp/testsuite/libgomp.c/pr64824.c trunk/libgomp/testsuite/libgomp.c/pr64868.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-omp.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/libgomp/ChangeLog
[Bug middle-end/64824] ICE in gimple verification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64824 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Wed Feb 4 22:32:36 2015 New Revision: 220420 URL: https://gcc.gnu.org/viewcvs?rev=220420&root=gcc&view=rev Log: PR c/64824 PR c/64868 gcc/c/ * c-parser.c (c_parser_omp_atomic): Handle RDIV_EXPR. gcc/cp/ * parser.c (cp_parser_omp_atomic): Handle RDIV_EXPR. gcc/c-family/ * c-omp.c (c_finish_omp_atomic): Use TRUNC_DIV_EXPR instead of RDIV_EXPR. Use build_binary_op instead of build2_loc. libgomp/ * testsuite/libgomp.c/pr64824.c: New test. * testsuite/libgomp.c/pr64868.c: New test. * testsuite/libgomp.c++/pr64824.C: New test. * testsuite/libgomp.c++/pr64868.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr64824.C trunk/libgomp/testsuite/libgomp.c++/pr64868.C trunk/libgomp/testsuite/libgomp.c/pr64824.c trunk/libgomp/testsuite/libgomp.c/pr64868.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-omp.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/libgomp/ChangeLog
[Bug c/64868] C front-end rejects valid syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64868 --- Comment #3 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/64824] ICE in gimple verification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64824 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-02-04 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/51571] No named return value optimization while adding a dummy scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51571 marc at kdab dot com changed: What|Removed |Added CC||marc at kdab dot com --- Comment #4 from marc at kdab dot com --- I would like to strongly oppose the notion that this "just a missed optimisation and not very critical, really". NRVO is not just "an optimisation". It's actually one that is explcitly permitted to change observable behaviour of the program and it's extremely powerful. And it it _required_ for performant C++. Just try to return a std::vector by value to see the importance of this optimisation. This is not missed optimisation. This is premature pessimisation. You could just as well stop all optimisation work for the C++ frontend until this is implemented, because any other optimisation effords are dwarfed by the overhead when NRVO is expected by the developer but not applied. Please make this a top priority. Every C++ program will benefit both in text size and in runtime performance - dramatically.
[Bug c++/58055] [meta-bug] RVO / NRVO improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055 marc at kdab dot com changed: What|Removed |Added CC||marc at kdab dot com --- Comment #5 from marc at kdab dot com --- I have no clue about the architecture of GCC, but it sounds to me that NRVO is definitely a front-end optimisation, because it's allowed to change observable behaviour. E.g., you can elide the copy ctor and dtor even if they have side effects. Once you go into some intermediate representation, the information that a set of given side effects can be entirely removed is probably irrevocably lost.
[Bug c++/64940] New: Question: is it possible to build a single gcc/g++ that will work on mult. OS versions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64940 Bug ID: 64940 Summary: Question: is it possible to build a single gcc/g++ that will work on mult. OS versions? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bill.torpey at ullink dot com We're trying to build a single gcc/g++ toolchain that can run from a network-mounted filesystem, and be usable from multiple OS versions. In our specific case, we need to support RH/CentOS 5 & 6. Our approach has been to build on RH5 with the idea that glibc is backward-compatible. That mostly works, but with one major problem. When building on RH5, the gcc build creates a features.h in include-fixed that is specific to RH5. (Specifically, __USE_XOPEN2K8 is not defined, which causes compile errors when building on RH6). Is there a way to build gcc/g++ in a generic fashion such that include-fixed does not contain a features.h, but instead picks up the (OS-specific) version from /usr/include? FWIW, we've google'd ourselves silly trying to answer this question, and the only solution appears to be to build a "cross" compiler, but it's not clear how to do that. In particular, the approach we've tried (specifying --target=x86_64-unknown-linux-gnu to configure) doesn't seem to prevent the creation of a system-specific features.h. Any suggestions would be much appreciated!
[Bug c++/53637] NRVO not applied where there are two different variables involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-02-04
Summary|NRVO not applied in |NRVO not applied where
|branches when it could be |there are two different
||variables involved
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
The problem is that GCC does not do NRVO when there are two different variables
used. If the variable was the same, GCC would do the correct thing.
That is:
Foo bar(int i) {
Foo result;
if (i > 1) {
return result;
} else {
return result;
}
}
NRVO is applied.
[Bug c++/64940] Question: is it possible to build a single gcc/g++ that will work on mult. OS versions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64940 --- Comment #1 from Andrew Pinski --- You can call fix-includes after installing the toolchain if needed.
[Bug ipa/64686] [5 Regression] ICE: in edge_badness, at ipa-inline.c:912 during Firefox LTO build with enabled checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64686
--- Comment #7 from Jan Hubicka ---
It is an ordering issue. We are adding edges to heap and resolving speculations
at once that means that we have temporarily wrong summaries. I am testing the
following that should not affect codegen in any important way except for random
changes of functions with the same priority.
Index: ipa-inline.c
===
--- ipa-inline.c(revision 220417)
+++ ipa-inline.c(working copy)
@@ -1702,6 +1702,7 @@ inline_small_functions (void)
{
bool update = false;
struct cgraph_edge *next;
+ bool has_speculative = false;
if (dump_file)
fprintf (dump_file, "Enqueueing calls in %s/%i.\n",
@@ -1719,12 +1720,17 @@ inline_small_functions (void)
gcc_assert (!edge->aux);
update_edge_key (&edge_heap, edge);
}
- if (edge->speculative && !speculation_useful_p (edge, edge->aux !=
NULL))
+ if (edge->speculative)
+ has_speculative = true;
+ }
+ if (has_speculative)
+ for (edge = node->callees; edge; edge = next)
+ if (edge->speculative && !speculation_useful_p (edge,
+ edge->aux != NULL))
{
edge->resolve_speculation ();
update = true;
}
- }
if (update)
{
struct cgraph_node *where = node->global.inlined_to
[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922 --- Comment #14 from Jan Hubicka --- Author: hubicka Date: Wed Feb 4 22:59:30 2015 New Revision: 220423 URL: https://gcc.gnu.org/viewcvs?rev=220423&root=gcc&view=rev Log: PR middle-end/64922 * ipa-prop.c (update_indirect_edges_after_inlining): Correctly update edges that become speculative. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c
[Bug ipa/64896] [5 Regression] ICE in get_address_mode, at rtlanal.c:5442
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64896
--- Comment #5 from Jan Hubicka ---
Hmm, an RTL expansion issue. We optimize m_fn2 as
B D::m_fn2() const (const struct D * const this)
{
;; basic block 2, loop depth 0
;;pred: ENTRY
MEM[(struct B *)&] = 0;
MEM[(struct B *)& + 4B] = 0;
MEM[(struct B *)& + 8B] = 0;
return ;
;;succ: EXIT
}
and we want to store
unit size
align 32 symtab 0 alias set 5 canonical type 0x76c55000
fields
private nonlocal decl_3 DI file /aux/hubicka/t.ii line 7 col 5
size
unit size
align 32 offset_align 128
offset
bit offset context
chain >
context
full-name "class B"
X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown
pointer_to_this chain >
used ignored regdecl BLK file /aux/hubicka/t.ii line 27 col 13 size
unit size
align 32 context
(parallel:BLK [
(expr_list:REG_DEP_TRUE (reg:DI 87 [ ])
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:SI 88 [ +8 ])
(const_int 8 [0x8]))
])>
into its DECL_RTL but somehow we end up not doing that correctly.
Without -fipa-icf we produce:
B D::m_fn2() const (const struct D * const this)
{
struct B D.2398;
:
D.2398.m_location.m_x = 0;
D.2398.m_location.m_y = 0;
D.2398.m_size = 0;
return D.2398;
}
that looks equivalent but gets compiled well.
We decide to unify m_fn1 and m_fn2 as:
virtual B F::m_fn1() const (const struct F * const this)
{
struct B D.2396;
:
D.2396.m_location.m_x = 0;
D.2396.m_location.m_y = 0;
D.2396.m_size = 0;
return D.2396;
}
B D::m_fn2() const (const struct D * const this)
{
:
= F::m_fn1 (this_2(D)); [tail call]
return ;
}
which eventually gets inlined back of course (I will teach ICF to skip thunk
creation when inline sequence is shorter).
The inliner produces:
B D::m_fn2() const (const struct D * const this)
{
struct B D.2413;
:
D.2413.m_location.m_x = 0;
D.2413.m_location.m_y = 0;
D.2413.m_size = 0;
= D.2413;
return ;
}
I suppose the extra store is the problem.
Implementing wrapper by hand gives me:
B D::m_fn5() const (const struct D * const this)
{
str
[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123 --- Comment #26 from Jan Hubicka --- Author: hubicka Date: Wed Feb 4 23:26:40 2015 New Revision: 220424 URL: https://gcc.gnu.org/viewcvs?rev=220424&root=gcc&view=rev Log: PR gcov/64123 * gcov-io.c (gcov_var): Export. Modified: trunk/gcc/ChangeLog trunk/gcc/gcov-io.c
[Bug c++/64940] Question: is it possible to build a single gcc/g++ that will work on mult. OS versions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64940 --- Comment #2 from Bill Torpey --- Thanks for the quick reply! Unfortunately, the approach you suggest won't work for what we want to do, which is to have a *single* network-mounted gcc that can be used from both. That means we need a "generic" gcc, and it's not clear how to produce one (or if that is even possible).
[Bug target/64938] [4.9 Regression] ICE in symtab_remove_unreachable_nodes, at ipa.c:547 on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64938 --- Comment #2 from Matthias Klose --- Author: doko Date: Wed Feb 4 23:36:22 2015 New Revision: 220426 URL: https://gcc.gnu.org/viewcvs?rev=220426&root=gcc&view=rev Log: 2015-02-04 Matthias Klose PR target/64938 Backport from mainline 2015-01-15 Jan Hubicka PR ipa/64068 PR ipa/64559 * ipa.c (symbol_table::remove_unreachable_nodes): Do not put abstract origins into boundary. 2015-02-04 Matthias Klose Backport from mainline 2015-01-15 Martin Liska * g++.dg/ipa/pr64068.C: New test. * gcc.dg/ipa/PR64559.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr64068.C branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/ipa/PR64559.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ipa.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug ipa/64559] [5 Regression] ICE at -Os on x86_64-linux-gnu in remove_unreachable_nodes, at ipa.c:582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64559 --- Comment #5 from Matthias Klose --- Author: doko Date: Wed Feb 4 23:36:22 2015 New Revision: 220426 URL: https://gcc.gnu.org/viewcvs?rev=220426&root=gcc&view=rev Log: 2015-02-04 Matthias Klose PR target/64938 Backport from mainline 2015-01-15 Jan Hubicka PR ipa/64068 PR ipa/64559 * ipa.c (symbol_table::remove_unreachable_nodes): Do not put abstract origins into boundary. 2015-02-04 Matthias Klose Backport from mainline 2015-01-15 Martin Liska * g++.dg/ipa/pr64068.C: New test. * gcc.dg/ipa/PR64559.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr64068.C branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/ipa/PR64559.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ipa.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug ipa/64068] [5 Regression] ICE: in remove_unreachable_nodes, at ipa.c:546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64068 --- Comment #11 from Matthias Klose --- Author: doko Date: Wed Feb 4 23:36:22 2015 New Revision: 220426 URL: https://gcc.gnu.org/viewcvs?rev=220426&root=gcc&view=rev Log: 2015-02-04 Matthias Klose PR target/64938 Backport from mainline 2015-01-15 Jan Hubicka PR ipa/64068 PR ipa/64559 * ipa.c (symbol_table::remove_unreachable_nodes): Do not put abstract origins into boundary. 2015-02-04 Matthias Klose Backport from mainline 2015-01-15 Martin Liska * g++.dg/ipa/pr64068.C: New test. * gcc.dg/ipa/PR64559.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr64068.C branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/ipa/PR64559.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ipa.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256 --- Comment #6 from Zoltan Hidvegi --- Created attachment 34672 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34672&action=edit Patch to limit dbx stabstring length to 32000
