[Bug middle-end/59776] [4.8 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59776 --- Comment #15 from Jakub Jelinek --- Author: jakub Date: Thu Mar 6 07:59:29 2014 New Revision: 208366 URL: http://gcc.gnu.org/viewcvs?rev=208366&root=gcc&view=rev Log: Backport from mainline 2014-02-11 Richard Henderson Jakub Jelinek PR debug/59776 * tree-sra.c (load_assign_lhs_subreplacements): Add VIEW_CONVERT_EXPR around drhs if type conversion to lacc->type is not useless. * gcc.dg/guality/pr59776.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/guality/pr59776.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-sra.c
[Bug fortran/52370] [4.7/4.8 Regression] Spurious "may be used uninitialized" warning for check of optional argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52370 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Thu Mar 6 08:00:49 2014 New Revision: 208367 URL: http://gcc.gnu.org/viewcvs?rev=208367&root=gcc&view=rev Log: Backport from mainline 2014-02-11 Jakub Jelinek PR fortran/52370 * trans-decl.c (gfc_build_dummy_array_decl): Set TREE_NO_WARNING on decl if sym->attr.optional. * gfortran.dg/pr52370.f90: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/pr52370.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/trans-decl.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c/60101] [4.7/4.8 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Thu Mar 6 08:01:57 2014 New Revision: 208368 URL: http://gcc.gnu.org/viewcvs?rev=208368&root=gcc&view=rev Log: Backport from mainline 2014-02-12 Jakub Jelinek PR c/60101 * c-common.c (merge_tlist): If copy is true, call new_tlist, if false, add ADD itself, rather than vice versa. (verify_tree): For COND_EXPR, don't call merge_tlist with non-zero copy. For SAVE_EXPR, only call merge_tlist once. * c-c++-common/pr60101.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr60101.c Modified: branches/gcc-4_8-branch/gcc/c-family/ChangeLog branches/gcc-4_8-branch/gcc/c-family/c-common.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/43546] [4.7/4.8 Regression] ICE: in assign_stack_local_1, at function.c:353 with -mpreferred-stack-boundary=2 -msseregparm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43546 --- Comment #18 from Jakub Jelinek --- Author: jakub Date: Thu Mar 6 08:02:46 2014 New Revision: 208369 URL: http://gcc.gnu.org/viewcvs?rev=208369&root=gcc&view=rev Log: Backport from mainline 2014-02-13 Jakub Jelinek PR target/43546 * expr.c (compress_float_constant): If x is a hard register, extend into a pseudo and then move to x. * gcc.target/i386/pr43546.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr43546.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/expr.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Thu Mar 6 08:10:08 2014 New Revision: 208370 URL: http://gcc.gnu.org/viewcvs?rev=208370&root=gcc&view=rev Log: Backport from mainline 2014-02-19 Jakub Jelinek PR preprocessor/58844 * macro.c (enter_macro_context): Only push macro_real_token_count (macro) tokens rather than macro->count tokens, regardless of CPP_OPTION (pfile, track-macro-expansion). * c-c++-common/cpp/pr58844-1.c: New test. * c-c++-common/cpp/pr58844-2.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/cpp/pr58844-1.c branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/cpp/pr58844-2.c Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/libcpp/ChangeLog branches/gcc-4_8-branch/libcpp/macro.c
[Bug c/37743] Bogus printf format warning with __builtin_bswap32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743
--- Comment #15 from Jakub Jelinek ---
Author: jakub
Date: Thu Mar 6 08:11:20 2014
New Revision: 208371
URL: http://gcc.gnu.org/viewcvs?rev=208371&root=gcc&view=rev
Log:
Backport from mainline
2014-02-19 Jakub Jelinek
PR c/37743
* c-common.c (c_common_nodes_and_builtins): When initializing
c_uint{16,32,64}_type_node, also set corresponding
uint{16,32,64}_type_node to the same value.
* g++.dg/ext/builtin-bswap1.C: New test.
* c-c++-common/pr37743.c: New test.
Added:
branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr37743.c
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/ext/builtin-bswap1.C
Modified:
branches/gcc-4_8-branch/gcc/c-family/ChangeLog
branches/gcc-4_8-branch/gcc/c-family/c-common.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/56490] [4.7/4.8 Regression] -Wall triggering infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56490 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Thu Mar 6 08:12:02 2014 New Revision: 208372 URL: http://gcc.gnu.org/viewcvs?rev=208372&root=gcc&view=rev Log: * Makefile.in (tree-ssa-uninit.o): Depend on $(PARAMS_H). Backport from mainline 2014-02-21 Jakub Jelinek PR tree-optimization/56490 * params.def (PARAM_UNINIT_CONTROL_DEP_ATTEMPTS): New param. * tree-ssa-uninit.c: Include params.h. (compute_control_dep_chain): Add num_calls argument, return false if it exceed PARAM_UNINIT_CONTROL_DEP_ATTEMPTS param, pass num_calls to recursive call. (find_predicates): Change dep_chain into normal array, add num_calls variable and adjust compute_control_dep_chain caller. (find_def_preds): Likewise. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/Makefile.in branches/gcc-4_8-branch/gcc/params.def branches/gcc-4_8-branch/gcc/tree-ssa-uninit.c
[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED Ever confirmed|1 |0 --- Comment #10 from Alexandre Oliva --- Fixed by reversal of the faulty patch. We should eventually tweak vt_add_function_parameter so as to preserve VALUEs recursively, adding dataflow_set binds for all of them, like we do for top-level MEMs (and their addresses) and REGs. We'll probably have to work harder to preserve these intermediate equivalences in spite of the removal of the base VALUEs when their REGs are reset and their loc lists become empty. Just marking the VALUEs as preserved won't stop that, and when we get to preserving them in the separate preserved table, they'll be gone already. Regarding preserved values as non-useless will likely cause lots of values to be preserved that currently aren't. This may very well get us better debug info, but I'm not sure at what cost.
[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381 Alexandre Oliva changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Alexandre Oliva --- Oops, really fixed now ;-)
[Bug tree-optimization/60276] [4.7 Regression] -O3 autovectorizer breaks on a particular loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Thu Mar 6 08:23:36 2014 New Revision: 208373 URL: http://gcc.gnu.org/viewcvs?rev=208373&root=gcc&view=rev Log: PR tree-optimization/60276 * tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Avoid a -Wsign-compare warning. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/tree-vect-data-refs.c
[Bug ipa/60026] [4.8 Regression] ICE at -O3 on valid code (with the optimize pragma) on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60026 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- Hopefully fixed now.
[Bug middle-end/59776] [4.8 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59776 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Jakub Jelinek --- Fixed.
[Bug preprocessor/56824] [4.8 regression] pragma GCC diagnostic push/pop fail with GCC diagnostic ignored "-Waggregate-return"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56824 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.8.3 Resolution|--- |FIXED --- Comment #14 from Jakub Jelinek --- Hopefully fixed now.
[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.8.3 Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug preprocessor/60436] [4.8/4.9 Regression] C preprocessor segfaults on assembly file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60436 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-06 CC||trippels at gcc dot gnu.org Known to work||4.7.3 Target Milestone|--- |4.8.4 Summary|C preprocessor segfaults on |[4.8/4.9 Regression] C |assembly file |preprocessor segfaults on ||assembly file Ever confirmed|0 |1 Known to fail||4.8.3, 4.9.0 --- Comment #1 from Markus Trippelsdorf --- Confirmed. Both trunk and 4.8.3 segfault. 4.7.3 is fine. /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/cc1 -o /dev/null -E -lang-asm -quiet -v -D ABCDEFGHIJKLM ghc3240_8.s #0 0x00c7136e in get_data_from_adhoc_loc(line_maps*, unsigned int) () #1 0x00c67fe8 in expand_location(unsigned int) () #2 0x004cc7b3 in preprocess_file(cpp_reader*) () #3 0x00c806df in c_common_init() () #4 0x00c7c90c in c_objc_common_init() () #5 0x00cc12fb in toplev_main(int, char**) () #6 0x77756fb0 in __libc_start_main () from /lib/libc.so.6 #7 0x00c7bb1a in _start () /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1 -o /dev/null -E -lang-asm -quiet -v -D ABCDEFGHIJKLM ghc3240_8.s #0 0x00aeeaac in expand_location_1(unsigned int, bool) [clone .lto_priv.2583] () #1 0x00b60b10 in preprocess_file(cpp_reader*) () #2 0x00b53316 in c_common_init() () #3 0x00b1190b in c_objc_common_init() () #4 0x00aeb141 in toplev_main(int, char**) () #5 0x77756fb0 in __libc_start_main () from /lib/libc.so.6 #6 0x00ae56e9 in _start () Valgrind shows: ==28570== Invalid read of size 4 ==28570==at 0xAEEAAC: expand_location_1(unsigned int, bool) [clone .lto_priv.2583] (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0xB60B0F: preprocess_file(cpp_reader*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0xB53315: c_common_init() (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0xB1190A: c_objc_common_init() (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0xAEB140: toplev_main(int, char**) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0x4D70FAF: (below main) (in /lib64/libc-2.19.so) ==28570== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==28570== ==28570== Invalid read of size 4 ==28570==at 0xAEEAAC: expand_location_1(unsigned int, bool) [clone .lto_priv.2583] (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0xB6DB50: location_get_source_line(expanded_location, int*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0xAEF365: diagnostic_show_locus(diagnostic_context*, diagnostic_info const*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0xAEC294: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0x4DC59B: internal_error(char const*, ...) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0xA377DB: crash_signal(int) [clone .lto_priv.1176] (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0x4D8508F: ??? (in /lib64/libc-2.19.so) ==28570==by 0xAEEAAB: expand_location_1(unsigned int, bool) [clone .lto_priv.2583] (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0xB60B0F: preprocess_file(cpp_reader*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0xB53315: c_common_init() (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0xB1190A: c_objc_common_init() (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570==by 0xAEB140: toplev_main(int, char**) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1) ==28570== Address 0x610 is not stack'd, malloc'd or (recently) free'd Could be related to PR58893.
[Bug c++/60434] False -Wformat warnings about %lld and %Lf are given on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60434 --- Comment #2 from Egor Suvorov --- Created attachment 32283 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32283&action=edit Output of gcc with '-v -save-temps -std=c++11 -Wformat'
[Bug libstdc++/60441] New: Incorrect textual representation for std::mersenne_twister_engine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60441
Bug ID: 60441
Summary: Incorrect textual representation for
std::mersenne_twister_engine
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: koherde at hotmail dot com
The textual representation of std::mersenne_twister_engine should consist of n
values (n being the state size). libstdc++ uses a textual representation that
consists of n+1 values.
--
#include
#include
#include
int main()
{
std::mt19937 r;
std::stringstream ss;
ss << r;
int valueCount = 0;
std::uint32_t val;
while (ss >> val)
{
++valueCount;
}
std::cout << r.state_size << std::endl;
std::cout << valueCount << std::endl;
}
--
Output:
624
625
Expected output:
624
624
[Bug c++/60434] False -Wformat warnings about %lld and %Lf are given on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60434
--- Comment #3 from Egor Suvorov ---
Yes, here is result both with C++03 and with C++11 (they're absolutely the
same):
a.cpp: In function 'int main()':
a.cpp:5:19: warning: format '%f' expects argument of type 'double', but
argument 2 has type 'long double' [-Wformat=]
printf("%f\n", x); // Undefined
^
a.cpp:6:20: warning: format '%lf' expects argument of type 'double', but
argument 2 has type 'long double' [-Wformat=]
printf("%lf\n", x); // Undefined
^
a.cpp:7:20: warning: unknown conversion type character 'L' in format
[-Wformat=]
printf("%Lf\n", x); // Expected '123.45' in C++11
^
a.cpp:7:20: warning: too many arguments for format [-Wformat-extra-args]
a.cpp:12:20: warning: unknown conversion type character 'L' in format
[-Wformat=]
printf("%Lf\n", y); // Undefined
^
a.cpp:12:20: warning: too many arguments for format [-Wformat-extra-args]
[Bug libgcc/59339] vtable_verify objects still trying to be installed even when disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59339 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-06 Target Milestone|--- |4.9.0 Summary|vtable_verify objects still |vtable_verify objects still |trying to be linked on |trying to be installed even |Android |when disabled Ever confirmed|0 |1 --- Comment #3 from Uroš Bizjak --- I also see this on x86_64 linux build. Although not a regression, I think that this build problem should be fixed before 4.9 is released.
[Bug c/60442] New: No -Wparentheses warning for "if (a += b)"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60442
Bug ID: 60442
Summary: No -Wparentheses warning for "if (a += b)"
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
The gcc trunk emits -Wparentheses warnings for "if(a = b)" and "if(a = a + b)",
but not "if(a += b)"
$: cat s.c
int b;
int f(int a) {
if (a = b)
return 0;
else if (a = a + b)
return 3;
else if (a += b) /* <- no warning here*/
return 2;
else
return 1;
}
$: gcc-trunk -Wparentheses -c s.c
s.c: In function ‘f’:
s.c:3:3: warning: suggest parentheses around assignment used as truth value
[-Wparentheses]
if (a = b)
^
s.c:5:3: warning: suggest parentheses around assignment used as truth value
[-Wparentheses]
else if (a = a + b)
^
$:
[Bug preprocessor/60436] [4.8/4.9 Regression] C preprocessor segfaults on assembly file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60436 --- Comment #2 from Markus Trippelsdorf --- ASAN:SIGSEGV = ==20669==ERROR: AddressSanitizer: SEGV on unknown address 0x0018 (pc 0x023044cf sp 0x7fff99677740 bp 0x8001 T0) #0 0x23044ce in get_data_from_adhoc_loc(line_maps*, unsigned int) ../../gcc/libcpp/line-map.c:156 #1 0x22c9240 in expand_location_1 ../../gcc/gcc/input.c:142 #2 0x22cb68d in expand_location(unsigned int) ../../gcc/gcc/input.c:724 #3 0x7a3cd9 in scan_translation_unit ../../gcc/gcc/c-family/c-ppoutput.c:214 #4 0x7a3cd9 in preprocess_file(cpp_reader*) ../../gcc/gcc/c-family/c-ppoutput.c:101 #5 0x7a05df in c_common_init() ../../gcc/gcc/c-family/c-opts.c:1040 #6 0x68bccd in c_objc_common_init() ../../gcc/gcc/c/c-objc-common.c:65 #7 0x1251227 in lang_dependent_init ../../gcc/gcc/toplev.c:1712 #8 0x1251227 in do_compile ../../gcc/gcc/toplev.c:1900 #9 0x1251227 in toplev_main(int, char**) ../../gcc/gcc/toplev.c:1990 #10 0x7f051b6cafaf in __libc_start_main (/lib/libc.so.6+0x1ffaf) #11 0x5beb60 (/var/tmp/gcc_sani/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1+0x5beb60) AddressSanitizer can not provide additional info.
[Bug preprocessor/60436] [4.8/4.9 Regression] C preprocessor segfaults on assembly file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60436 --- Comment #3 from Jakub Jelinek --- Strange, can't reproduce this myself using the same options, neither in bootstrapped cc1, nor in non-bootstrapped -O0 built, nor bootstrapped cc1 under valgrind, both 4.8 (older and latest) and trunk. I'd have thought this would be r200376, but that is fixed on the trunk and now (since today) on the 4.8 branch too.
[Bug c/60442] No -Wparentheses warning for "if (a += b)"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60442 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I'm not convinced there is anything wrong. The reason to warn about if(a = b) or if(a = a + b) is that way too often people just mean to write if(a == b) or if(a == a + b) instead, but confusing += for == happens orders of magnitude less often.
[Bug target/60443] New: Target specific options that change the ABI should be marked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60443 Bug ID: 60443 Summary: Target specific options that change the ABI should be marked Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: lto Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Currently there is no way to handle ABI-changing target options conservatively in lto-wrapper (complain if there are mismatches inbetween files, make sure to carry them over to link-time). This is because explicitely handling them is not possible (the OPT_ enum is different for each target). ABI changing options should be marked in the .opt files with a flag that can be checked instead.
[Bug target/60387] The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60387 --- Comment #7 from Nistor, Mihail-Marian --- Hello, Doe to the fact that the gcc is not compatible with the DWARF and PPC ABI for the PPC processors, as you said that is a fact of life and we need to live with it. Users must always be informed when a compiler does not comply with an ABI, so please add a notice in the release note to inform the user that the ppc gcc is not compatible with the DWARF and PPC ABI. And please also add information about exception from these standards and provide information about the new DWARF register number mapping that is used by gcc in the .eh_frame section. My 2 cents. Mihai
[Bug c/60442] No -Wparentheses warning for "if (a += b)"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60442 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic --- Comment #2 from Jonathan Wakely --- I agree with Jakub, the warning is meant to catch typographical errors, not assignments used as truth values in general. There's nothing wrong with using assignments as truth values, as long as that's what you actually intended to type.
[Bug target/60387] The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60387 Nistor, Mihail-Marian changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #8 from Nistor, Mihail-Marian --- Hello, Doe to the fact that the gcc is not compatible with the DWARF and PPC ABI for the PPC processors, as you said that is a fact of life and we need to live with it. Users must always be informed when a compiler does not comply with an ABI, so please add a notice in the release note to inform the user that the ppc gcc is not compatible with the DWARF and PPC ABI. And please also add information about exception from these standards and provide information about the new DWARF register number mapping that is used by gcc in the .eh_frame section. My 2 cents. Mihai
[Bug middle-end/60435] GCC failes to apply CSE for va_arg with different types whose representations match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60435 --- Comment #1 from Richard Biener --- Can't verify it as there isn't a compilable testcase. But I guess this is just because GCC doesn't have a code hoisting pass, not because of int vs. long. See PR23286 of which this is a duplicate I think.
[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60424 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-06 Depends on||60427 Ever confirmed|0 |1 --- Comment #5 from Richard Biener --- Looks related, yes. Confirmed btw.
[Bug c/60444] New: No -Wmaybe-uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60444
Bug ID: 60444
Summary: No -Wmaybe-uninitialized warning
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
The auto variable "x" may be uninitialized if "b" is not zero.
$: cat s.c
extern void foo();
int test(int b) {
int x;
if (b) {
foo();
} else {
x = 1;
}
return x;
}
$: gcc-trunk -Wmaybe-uninitialized -c s.c -O3
[Bug target/60387] The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60387 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #9 from Andrew Pinski --- Please read the links I gave. They give the background on what is going on and why even we cannot change it. Having the eh_frame being different from debug_frame is now part of the GNU ABI and cannot be changed.
[Bug middle-end/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |WAITING
Last reconfirmed||2014-03-06
Component|libgcc |middle-end
Ever confirmed|0 |1
--- Comment #5 from Richard Biener ---
Can you identify the inlined call? Is it
if (pSLL && y == pSLL->scanline) {
loadAET(&AET, pSLL->edgelist);
pSLL = pSLL->next;
}
or
if (pSLL && y == pSLL->scanline) {
loadAET(&AET, pSLL->edgelist);
computeWAET(&AET);
pSLL = pSLL->next;
}
?
Can you also show the correct and the invalid assembly snippet?
Not sure if it is possible, but having a "driver" around this (in
a separate compilation-unit) that calls PolygonRegion, verifying correct output
for correct input
and thus showing the miscompile would be nice (so there is a runtime
testcase). It doesn't matter if linking requires Qt.
I am somewhat lost in that large function ;)
[Bug preprocessor/60436] [4.8/4.9 Regression] C preprocessor segfaults on assembly file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60436 Markus Trippelsdorf changed: What|Removed |Added CC||dehao at gcc dot gnu.org --- Comment #4 from Markus Trippelsdorf --- Probably started with r191494.
[Bug middle-end/60445] New: [4.9 Regression] 473.astar miscompares with -Ofast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60445 Bug ID: 60445 Summary: [4.9 Regression] 473.astar miscompares with -Ofast Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target: x86_64-*-*, i?86-*-* Seen on x86_64 with -Ofast and on both x86_64 and i?86 with -Ofast -flto -march=native. *** Miscompare of BigLakes2048.out, see /gcc/spec/cpu2006/benchspec/CPU2006/473.astar/run/run_peak_ref_x86_64-linux.0002/BigLakes2048.out.mis 0009: Total way length : 761939 Total way length : 741884 ^ 0012: Reg ways quantity : 4603 Reg ways quantity : 4314 ^ 0013: Total reg way length : 1417263 Total reg way length : 786132 ^ 0017: Total river way length : 173223 Total river way length : 163674 ^ ... *** Miscompare of rivers.out, see /gcc/spec/cpu2006/benchspec/CPU2006/473.astar/run/run_peak_ref_x86_64-linux.0002/rivers.out.mis 0008: Ways quantity : 16536 Ways quantity : 16353 ^ 0009: Total way length : 5106389 Total way length : 5086593 ^ 0012: Reg ways quantity : 39579 Reg ways quantity : 34944 ^
[Bug middle-end/60445] [4.9 Regression] 473.astar miscompares with -Ofast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60445 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.9.0 --- Comment #1 from Richard Biener --- Last revision working with plain -Ofast on x86_64: r208303 First revision failing with plain -Ofast on x86_64: r208335 astar is short C++ code. It works with -O2.
[Bug preprocessor/60436] [4.8/4.9 Regression] C preprocessor segfaults on assembly file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60436 --- Comment #5 from Markus Trippelsdorf --- markus@x4 tmp % gdb --args /var/tmp/gcc_test/usr/local/bin/g++ -DTABLES_NEXT_TO_CODE -x assembler-with-cpp -c ghc3240_8.s Reading symbols from /var/tmp/gcc_test/usr/local/bin/g++...done. (gdb) run Starting program: /var/tmp/gcc_test/usr/local/bin/g++ -DTABLES_NEXT_TO_CODE -x assembler-with-cpp -c ghc3240_8.s [New process 7553] process 7553 is executing new program: /var/tmp/gcc_test/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1 Program received signal SIGABRT, Aborted. [Switching to process 7553] 0x77604ff4 in raise () from /lib/libc.so.6 (gdb) bt #0 0x77604ff4 in raise () from /lib/libc.so.6 #1 0x776063e7 in abort () from /lib/libc.so.6 #2 0x00f25198 in linemap_location_from_macro_expansion_p (set=, location=, location@entry=2147483542) at ../../gcc/libcpp/line-map.c:948 #3 0x00f252ff in linemap_lookup (set=set@entry=0x77ff8000, line=line@entry=2147483542) at ../../gcc/libcpp/line-map.c:642 #4 0x00f253bc in linemap_macro_loc_to_exp_point (set=0x77ff8000, location=2147483542, original_map=original_map@entry=0x7fffdfb8) at ../../gcc/libcpp/line-map.c:1181 #5 0x00f25611 in linemap_resolve_location (set=, loc=, loc@entry=2147483542, lrk=, map=map@entry=0x7fffdfb8) at ../../gcc/libcpp/line-map.c:1262 #6 0x00f0e3ae in expand_location_1 (loc=loc@entry=2147483542, expansion_point_p=expansion_point_p@entry=true) at ../../gcc/gcc/input.c:164 #7 0x00f0f08e in expand_location (loc=loc@entry=2147483542) at ../../gcc/gcc/input.c:724 #8 0x005ec236 in maybe_print_line_1 (stream=0x15e2860, src_loc=2147483542) at ../../gcc/gcc/c-family/c-ppoutput.c:314 #9 maybe_print_line (src_loc=src_loc@entry=2147483542) at ../../gcc/gcc/c-family/c-ppoutput.c:351 #10 0x005ec7fb in do_line_change (pfile=0x15d8cd0, token=0x15d9210, src_loc=2147483542, parsing_args=0) at ../../gcc/gcc/c-family/c-ppoutput.c:420 #11 0x00f240b4 in _cpp_lex_token (pfile=0x15d8cd0) at ../../gcc/libcpp/lex.c:2078 #12 0x00f28d10 in cpp_get_token_1 (pfile=0x15d8cd0, location=0x1d81, location@entry=0x7fffe134) at ../../gcc/libcpp/macro.c:2359 #13 0x00f28f75 in cpp_get_token_with_location (pfile=pfile@entry=0x15d8cd0, loc=loc@entry=0x7fffe134) at ../../gcc/libcpp/macro.c:2541 #14 0x005ec9d8 in scan_translation_unit (pfile=0x15d8cd0) at ../../gcc/gcc/c-family/c-ppoutput.c:176 #15 preprocess_file (pfile=0x15d8cd0) at ../../gcc/gcc/c-family/c-ppoutput.c:101 #16 0x005eb3e9 in c_common_init () at ../../gcc/gcc/c-family/c-opts.c:1040 #17 0x0057dd7e in c_objc_common_init () at ../../gcc/gcc/c/c-objc-common.c:65 #18 0x0099f477 in lang_dependent_init (name=0x7fffe73b "ghc3240_8.s") at ../../gcc/gcc/toplev.c:1712 #19 do_compile () at ../../gcc/gcc/toplev.c:1900 #20 toplev_main (argc=14, argv=0x7fffe2c8) at ../../gcc/gcc/toplev.c:1990 #21 0x775f0fb0 in __libc_start_main () from /lib/libc.so.6 #22 0x005306a1 in _start () (gdb) location@entry=2147483542 = 0x7F96 is near "#define MAX_SOURCE_LOCATION 0x7FFF"
[Bug lto/60427] [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427 --- Comment #3 from Richard Biener --- Author: rguenth Date: Thu Mar 6 11:19:13 2014 New Revision: 208379 URL: http://gcc.gnu.org/viewcvs?rev=208379&root=gcc&view=rev Log: 2014-03-06 Richard Biener PR middle-end/60445 PR lto/60424 PR lto/60427 Revert 2014-03-04 Paulo Matos * tree-streamer.c (record_common_node): Assert we don't record nodes with type double. (preload_common_node): Skip type double, complex double and double pointer since it is now frontend dependent due to fshort-double option. * gcc.dg/lto/pr55113_0.c: New testcase. Removed: trunk/gcc/testsuite/gcc.dg/lto/pr55113_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-streamer.c
[Bug middle-end/60445] [4.9 Regression] 473.astar miscompares with -Ofast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60445 --- Comment #2 from Richard Biener --- Author: rguenth Date: Thu Mar 6 11:19:13 2014 New Revision: 208379 URL: http://gcc.gnu.org/viewcvs?rev=208379&root=gcc&view=rev Log: 2014-03-06 Richard Biener PR middle-end/60445 PR lto/60424 PR lto/60427 Revert 2014-03-04 Paulo Matos * tree-streamer.c (record_common_node): Assert we don't record nodes with type double. (preload_common_node): Skip type double, complex double and double pointer since it is now frontend dependent due to fshort-double option. * gcc.dg/lto/pr55113_0.c: New testcase. Removed: trunk/gcc/testsuite/gcc.dg/lto/pr55113_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-streamer.c
[Bug middle-end/60445] [4.9 Regression] 473.astar miscompares with -Ofast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60445 --- Comment #3 from Richard Biener --- Ok, the -flto fails I can reproduce locally and are caused by r208312 (now reverted). Still trying to reproduce with plain -Ofast as seen on one of the testers...
[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60424 --- Comment #6 from Richard Biener --- Author: rguenth Date: Thu Mar 6 11:19:13 2014 New Revision: 208379 URL: http://gcc.gnu.org/viewcvs?rev=208379&root=gcc&view=rev Log: 2014-03-06 Richard Biener PR middle-end/60445 PR lto/60424 PR lto/60427 Revert 2014-03-04 Paulo Matos * tree-streamer.c (record_common_node): Assert we don't record nodes with type double. (preload_common_node): Skip type double, complex double and double pointer since it is now frontend dependent due to fshort-double option. * gcc.dg/lto/pr55113_0.c: New testcase. Removed: trunk/gcc/testsuite/gcc.dg/lto/pr55113_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-streamer.c
[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60424 Bug 60424 depends on bug 60427, which changed state. Bug 60427 Summary: [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug lto/60427] [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60424 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Confirmed fixed.
[Bug libgcc/59339] vtable_verify objects still trying to be installed even when disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59339 Rainer Orth changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2014-03/msg00278.htm ||l CC||ro at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #4 from Rainer Orth --- Patch submitted.
[Bug target/60431] [PATCH] [TIC6X] target description missing abssi2 insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60431 Wojciech Migda changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Wojciech Migda --- misread documentation.
[Bug middle-end/60445] [4.9 Regression] 473.astar miscompares with -Ofast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60445 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- So fixed now?
[Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58595 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Thu Mar 6 12:07:07 2014 New Revision: 208380 URL: http://gcc.gnu.org/viewcvs?rev=208380&root=gcc&view=rev Log: PR target/58595 * config/arm/arm.c (arm_tls_symbol_p): Remove. (arm_legitimize_address): Call legitimize_tls_address for any arm_tls_referenced_p expression, handle constant addend. Call it before testing for !TARGET_ARM. (thumb_legitimize_address): Don't handle arm_tls_symbol_p here. * gcc.dg/tls/pr58595.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tls/pr58595.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/58572] [4.9 regression] make bootstrap-lean leads to installation failure (doing extra rebuilds and invoking system compiler)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Or perhaps if the *prev* directories are missing during install, symlink them to the latest stage ones for the duration of make install?
[Bug target/60446] New: [PATCH] [TIC6X] implementing abssf2/absdf2 insns, _fabs/_fabsf/__builtin_c6x_fabs/__builtin_c6x_fabsf intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60446
Bug ID: 60446
Summary: [PATCH] [TIC6X] implementing abssf2/absdf2 insns,
_fabs/_fabsf/__builtin_c6x_fabs/__builtin_c6x_fabsf
intrinsics
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wojtek.golf at interia dot pl
Host: Linux wmigda-desktop 3.11.0-13-generic #20-Ubuntu SMP
Wed Oct 23 17:26:33 UTC 2013 i686 i686 i686 GNU/Linux
Target: tic6x-none-elf
Build: tic6x-none-elf-gcc-4.8.3 (GCC) 4.8.3 20140303
(prerelease)
TI's SPRU187u document lists _fabs and _fabsf intrinsics, being resolved to
absdp and abssp, respectively. TIC6X machine definition lacks specification of
abs:SF and abs:DF alike instructions and _fabs/_fabsf intrinsics. This patch is
intended to amend that.
According to SPRUFE8B abssp and absdp are available for C67 family (TARGET_FP).
gcc already can inline fabs/fabsf but these require the header. When
implemented, __builtin_c6x_fabs/__builtin_c6x_fabsf may be used without pulling
in any headers, or _fabs/_fabsf when c6x_intrinsics.h is included.
ChangeLog
2014-03-06 Wojciech Migda
* gcc/config/c6x/c6x.c: added __builtin_c6x_fabs{,f} intrinsics.
* gcc/config/c6x/c6x.md: added abssf2/absdf2 instructions.
* gcc/config/c6x/c6x_intrinsics.h: definitions for _fabs and _fabsf.
* gcc/testsuite/gcc.target/tic6x/fpabs-scan.c: new testcases for fabs,
_fabs, and __builtin_c6x_fabs, as well as their 'float' variants.
Bootstrapping and testing
Host: Linux wmigda-desktop 3.11.0-13-generic #20-Ubuntu SMP Wed Oct 23 17:26:33
UTC 2013 i686 i686 i686 GNU/Linux
Target: tic6x-none-elf
Results for the new testcases (run with make check-gcc
RUNTESTFLAGS="CFLAGS_FOR_TARGET='$CFLAGS_FOR_TARGET
--sysroot=${CXTOOLS}${TRIPLET}/sysroot' -v -v tic6x.exp")
PASS: gcc.target/tic6x/fpabs-scan.c (test for excess errors)
PASS: gcc.target/tic6x/fpabs-scan.c scan-assembler-times abssp 3
PASS: gcc.target/tic6x/fpabs-scan.c scan-assembler-times absdp 3
Patch attached.
Thanks.
[Bug target/60446] [PATCH] [TIC6X] implementing abssf2/absdf2 insns, _fabs/_fabsf/__builtin_c6x_fabs/__builtin_c6x_fabsf intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60446 --- Comment #1 from Wojciech Migda --- Created attachment 32284 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32284&action=edit Proposed patch
[Bug target/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 Jorn Wolfgang Rennecke changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #8 from Jorn Wolfgang Rennecke --- Created attachment 32285 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32285&action=edit patch made as an example how to debug gcc here is a patch - not regtested. you might also consider to put the three non-constriant uses of [satisfies_constraint_]"U" in predicates.md into a different constraint /vpredicate. And delete the unused fix_bit_operand,
[Bug libgcc/59339] vtable_verify objects still trying to be installed even when disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59339 --- Comment #5 from Rainer Orth --- Author: ro Date: Thu Mar 6 12:24:11 2014 New Revision: 208381 URL: http://gcc.gnu.org/viewcvs?rev=208381&root=gcc&view=rev Log: Don't install vtv_*.o unless --enable-vtable-verify (PR libgcc/59339) PR libgcc/59339 * config.host (*-*-linux*, frv-*-*linux*, *-*-kfreebsd*-gnu) (*-*-knetbsd*-gnu, *-*-gnu*, *-*-kopensolaris*-gnu): Only add vtv_*.o to extra_parts if enable_vtable_verify. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config.host
[Bug libgcc/59339] vtable_verify objects still trying to be installed even when disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59339 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Rainer Orth --- Fixed for 4.9.0.
[Bug middle-end/60445] [4.9 Regression] 473.astar miscompares with -Ofast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60445 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- I think so.
[Bug target/60387] The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60387 --- Comment #10 from Nistor, Mihail-Marian --- Could you please show me where this information is in the GNU ABI? My request is to add all exceptions from the standards to release note.
[Bug target/60387] The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60387 --- Comment #11 from Jakub Jelinek --- But what exceptions are you talking about? I believe for .dwarf_frame PPC now emits the psABI mandated register numbers, and .eh_frame, being a GCC invention, simply has different register numbering, there is no reason why it would need to follow the psABI, it has it's own ABI (of course it would be better if it used the same register numbering, and it does on most targets). So what exactly you want to document and why?
[Bug fortran/60447] New: Empty .s file created when using -E flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447 Bug ID: 60447 Summary: Empty .s file created when using -E flag Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com > touch test.f90 > gfortran -E -cpp test.f90 # 1 "test.f90" # 1 "" # 1 "test.f90" > ls -l test.s -rw-r--r-- 1 lada users 0 6. bře 13.47 test.s C and C++ front-ends do not do this > touch test.c > gfortran -E -cpp test.c # 1 "test.c" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "test.c" > ls -l test.s ls: cannot access test.s: No such file or directory
[Bug fortran/60236] gfortran.dg/vect/pr32380.f fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60236 Bernd Edlinger changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Bernd Edlinger --- should be fixed now.
[Bug c/60197] ICE with _Cilk_spawn in expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60197 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Thu Mar 6 13:41:46 2014 New Revision: 208382 URL: http://gcc.gnu.org/viewcvs?rev=208382&root=gcc&view=rev Log: PR c/60197 c-family/ * cilk.c (contains_cilk_spawn_stmt): New function. (contains_cilk_spawn_stmt_walker): Likewise. (recognize_spawn): Give error on invalid use of _Cilk_spawn. * c-common.h (contains_cilk_spawn_stmt): Add declaration. c/ * c-typeck.c (c_finish_return): Call contains_cilk_spawn_stmt instead of checking tree code. cp/ * typeck.c (check_return_expr): Call contains_cilk_spawn_stmt instead of checking tree code. testsuite/ * c-c++-common/cilk-plus/CK/pr60197.c: New test. * c-c++-common/cilk-plus/CK/pr60197-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197-2.c trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.h trunk/gcc/c-family/cilk.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/60197] ICE with _Cilk_spawn in expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60197 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #6 from Marek Polacek --- Fixed.
[Bug libstdc++/60448] New: swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 Bug ID: 60448 Summary: swap_ranges does not use ADL correctly Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: public at alisdairm dot net Created attachment 32286 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32286&action=edit Demonstrate swap_ranges does not find swap via ADL The attached program does not correctly use ADL to find the 'swap' member implemented inside the tagged local class in C++11/C++1y builds. It is not expected to compile in C++03 or earlier dialects. The problem compiles and runs as expected on Clang 3.4 with libc++ in both C++11 and C++1y modes.
[Bug fortran/60447] Empty .s file created when using -E flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Use the -o option.
[Bug fortran/60447] Empty .s file created when using -E flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447 kargl at gcc dot gnu.org changed: What|Removed |Added CC|kargl at gcc dot gnu.org | Severity|normal |trivial
[Bug fortran/60447] Empty .s file created when using -E flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447 --- Comment #2 from Vladimir Fuka --- -o option for what?
[Bug preprocessor/60436] [4.8/4.9 Regression] C preprocessor segfaults on assembly file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60436 Markus Trippelsdorf changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #6 from Markus Trippelsdorf --- (In reply to Markus Trippelsdorf from comment #4) > Probably started with r191494. No, sorry. This issue started with r192715.
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #1 from Alisdair Meredith --- Created attachment 32287 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32287&action=edit Cleaner tagging scheme for the local class Simplified the example to more directly expose the local class via ADL without any funky casts.
[Bug fortran/60447] Empty .s file created when using -E flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Vladimir Fuka from comment #2) > -o option for what? % ls *.s ls: No match. % ls foo.* foo.F90 % gfortran46 -E -o foo.f90 -cpp foo.F90 % ls foo.* *.s foo.F90 foo.f90
[Bug ada/60411] ADA canadian cross build fails.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #2 from Bernd Edlinger --- when I revert this check-inm the build-succeeds: http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=208150
[Bug preprocessor/60436] [4.8/4.9 Regression] C preprocessor segfaults on assembly file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60436 --- Comment #7 from Markus Trippelsdorf --- Adding "-nostdinc" is a simple workaround.
[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253 --- Comment #7 from Akim Demaille --- Hi all, I'd really love to have some feedback on this issue. It looks like nobody is having a look at this. Thanks for all the good work, and sorry for insisting.
[Bug fortran/60447] Empty .s file created when using -E flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447 --- Comment #4 from Vladimir Fuka --- I see, but I just wanted to print the content or pipe it somewhere, so I don't think that resolves it.
[Bug fortran/60447] Empty .s file created when using -E flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447 --- Comment #5 from Steve Kargl --- On Thu, Mar 06, 2014 at 02:45:38PM +, vladimir.fuka at gmail dot com wrote: > > I see, but I just wanted to print the content or pipe it somewhere, so I don't > think that resolves it. > I did not say that it resolves the problem (as I obviously did not close the PR). I'm showing you a way to eliminate the spurious *.s file if it really bothers you.
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #2 from Jonathan Wakely --- (In reply to Alisdair Meredith from comment #1) > Created attachment 32287 [details] > Cleaner tagging scheme for the local class > > Simplified the example to more directly expose the local class via ADL > without any funky casts. Clang and G++ both reject this because the swap call is ambiguous
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #3 from Jonathan Wakely --- I don't understand what we can be doing wrong in the library, we just call std::iter_swap(it1, it2) which calls swap(*it1, *it2) unqualified.
[Bug bootstrap/58572] [4.9 regression] make bootstrap-lean leads to installation failure (doing extra rebuilds and invoking system compiler)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572
--- Comment #8 from Jakub Jelinek ---
Created attachment 32288
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32288&action=edit
gcc49-pr58572.patch
That didn't work for some reason (tried that just manually, after make
bootstrap-lean did ln -sf {,prev-}x86_64-unknown-linux-gnu, but make install
still failed when using g++ which doesn't grok -Wnarrowing and -Wno-narrowing
(used a shell script wrapper around /usr/bin/g++ that rejected those options).
But this patch worked, apparently libstdc++-v3 headers already use #pragma GCC
system_header, so this patch shouldn't make a difference warning-wise, but it
makes a difference for -MMD.
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448
--- Comment #4 from Jonathan Wakely ---
Looks like the difference between libc++ and libstdc++ is whether std::swap()
is declared before std::swap_ranges or not, this reproduces the same behaviour,
with swapper replacing swap_ranges:
namespace tagged
{
template
struct Swappable {};
template
void swap(Swappable & a, Swappable & b) {
static_cast(a).swap(static_cast(b));
}
} // namespace tagged
namespace std
{
template
void do_std_swap(T& a, T& b)
{
T tmp = static_cast(a);
a = static_cast(b);
b = static_cast(tmp);
}
#ifdef SWAP_FIRST
template
void swap(T& a, T& b)
{
do_std_swap(a, b);
}
#endif
template
void swapper(T t)
{
swap(*t, *t);
}
#ifndef SWAP_FIRST
template
void swap(T& a, T& b)
{
do_std_swap(a, b);
}
#endif
}
int main()
{
struct local : tagged::Swappable {
local(int x) : data(x) {}
local(local const &) = delete;
local(local &&) = delete;
local & operator=(local const &) = delete;
local & operator=(local &&) = delete;
void swap(local & other) {
auto x = other.data;
other.data = this->data;
this->data = x;
}
private:
int data;
};
local l{1};
std::swapper(&l);
}
When SWAP_FIRST is defined G++ and Clang call std::swap, otherwise they find
tagged::swap by ADL.
[Bug c++/60384] [4.9 Regression] [c++1y] ICE with invalid typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60384 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini --- Looking into it.
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448
--- Comment #5 from Jonathan Wakely ---
Slightly different version of that last test:
namespace tagged
{
template
struct Swappable {};
#ifndef NO_CUSTOM_SWAP
template
void swap(Swappable & a, Swappable & b) {
static_cast(a).swap(static_cast(b));
}
#endif
} // namespace tagged
namespace std
{
#ifdef SWAP_FIRST
template
void swap(T& a, T& b);
#endif
template
void swapper(T t)
{
swap(*t, *t);
}
template
void swap(T& a, T& b)
{
T tmp = static_cast(a);
a = static_cast(b);
b = static_cast(tmp);
}
}
int main()
{
struct local : tagged::Swappable {
local(int x) : data(x) {}
local(local const &) = delete;
local(local &&) = delete;
local & operator=(local const &) = delete;
local & operator=(local &&) = delete;
void swap(local & other) {
auto x = other.data;
other.data = this->data;
this->data = x;
}
private:
int data;
};
local l{1};
std::swapper(&l);
}
I must be guessing something wrong about libc++'s std::swap_ranges(), because
if it was declared before std::swap() then it would never work with any type
that doesn't provide its own swap() overload, as demonstrated by compiling the
above with NO_CUSTOM_SWAP defined.
So I don't know exactly what's going on, but I'm not convinced libstdc++ is
doing anything wrong.
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #6 from Marc Glisse --- libc++ sfinae constrains std::swap.
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #7 from Marc Glisse --- (In reply to Marc Glisse from comment #6) > libc++ sfinae constrains std::swap. More precisely: they do have swap declared before iter_swap, if you remove the =delete it is ambiguous with libc++ as well, it just happens that the template constraints disable the std swap in this particular case. So I don't think libstdc++ is doing anything wrong. I don't understand why ADL should get this to work. No function is more specialized than the other, and ADL doesn't disable unqualified lookup. But then again I am bad at understanding this text, it looks to me like it says ADL shouldn't even happen, which is clearly not the case...
[Bug target/60410] [4.7/4.8/4.9 Regression] -fshort-double ICEs x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60410 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rth at gcc dot gnu.org, ||uros at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r189974, but that is just because it added an assertion. The question is, if -fshort-double really has to be supported on x86_64/i686 (as ABI changing option), what to do with the intrinsics, grep double config/i386/*intrin*.h shows quite a lot of intrinsics that use double, and various builtins really assume DFmode arguments/return values/V*DF vectors etc. So, perhaps we could just override ix86_builtin_type_tab[(int)IX86_BT_DOUBLE] if double_type_node doesn't have DFmode TYPE_MODE to some DFmode REAL_TYPE (that would likely fix this ICE), and perhaps tweak the *intrin*.h headers to use typedef double __real_double __attribute__((__mode__(__DFmode__))); instead of double (perhaps not this part, it will very unlikely do the right thing, perhaps just tell people not to use the intrinsics).
[Bug lto/60449] New: Merging function DECLs discards leaf attribute which causes cfg verifier to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449 Bug ID: 60449 Summary: Merging function DECLs discards leaf attribute which causes cfg verifier to fail Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org I've come across this verify_flow_info failure when attempting to LTO build Firefox. I'm attaching a small testcase (I'm using trunk revision 208276 on x86-64-linux), to reproduce do: $ ~/gcc/trunk/inst/bin/gcc -c -O2 -flto gtod1.c $ ~/gcc/trunk/inst/bin/gcc -c -O2 -flto gtod2.c $ ~/gcc/trunk/inst/bin/gcc -O2 -flto gtod1.o gtod2.o gtod2.c: In function ‘main’: gtod2.c:41:5: error: control flow in the middle of basic block 6 int main (void) ^ gtod2.c:41:5: error: control flow in the middle of basic block 6 gtod2.c:41:5: error: control flow in the middle of basic block 6 gtod2.c:41:5: internal compiler error: verify_flow_info failed The order of .o files in the linking stage is important. My artificial testcase declares gettimeofday itself, twice, each time with different attributes on purpose. When building FF, all declarations claim to come from /usr/include/sys/time.h, I do not know why some of them lost or did not get their attributes. The problem with loosing the leaf attribute is that calls from function that calls setjmp are considered control flow statements unless they are without side effects or leaf (see stmt_ends_bb_p, is_ctrl_altering_stmt and call_can_make_abnormal_goto). Therefore, if a leaf attribute is lost, calls to that functions suddenly may need to break BBs or face the verifiers wrath.
[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449 --- Comment #1 from Martin Jambor --- Created attachment 32289 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32289&action=edit Part one of a testcase
[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449 --- Comment #2 from Martin Jambor --- Created attachment 32290 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32290&action=edit Part two of a testcase
[Bug fortran/60447] Empty .s file created when using -E flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447
--- Comment #6 from Steve Kargl ---
On Thu, Mar 06, 2014 at 03:01:52PM +, sgk at troutmask dot
apl.washington.edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447
>
> --- Comment #5 from Steve Kargl ---
> On Thu, Mar 06, 2014 at 02:45:38PM +, vladimir.fuka at gmail dot com
> wrote:
> >
> > I see, but I just wanted to print the content or pipe it somewhere,
> > so I don't think that resolves it.
> >
>
> I did not say that it resolves the problem (as I obviously
> did not close the PR). I'm showing you a way to eliminate
> the spurious *.s file if it really bothers you.
Possible patch.
Index: cpp.c
===
--- cpp.c(revision 207633)
+++ cpp.c(working copy)
@@ -536,16 +536,13 @@ gfc_cpp_init_0 (void)
if (gfc_cpp_preprocess_only ())
{
+ /* If only cpp is desired, then a hack is needed to redirect assembler
+ output (actually nothing as -E implies -fsyntax-only) to another
+ file, otherwise the output from preprocessing is lost. */
+ asm_file_name = gfc_cpp_option.temporary_filename;
+
if (gfc_cpp_option.output_filename)
{
- /* This needs cheating: with "-E -o ", the user wants the
- preprocessed output in . However, if nothing is done
- about it is also used for assembler output. Hence, it
- is necessary to redirect assembler output (actually nothing
- as -E implies -fsyntax-only) to another file, otherwise the
- output from preprocessing is lost. */
- asm_file_name = gfc_cpp_option.temporary_filename;
-
print.outf = fopen (gfc_cpp_option.output_filename, "w");
if (print.outf == NULL)
gfc_fatal_error ("opening output file %s: %s",
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #200 from Martin Jambor --- I currently cannot build Firefox with LTO due to PR 60449 (yeah, I know, using gcc configured with checking makes life hard, sometimes unnecessarily). I get errors like /home/mjambor/mozilla/mzc2/media/libvpx/vp8/encoder/onyx_if.c:4884:5: error: control flow in the middle of basic block 7
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #201 from Markus Trippelsdorf --- With current gcc trunk and mozilla-central trunk Firefox crashes on startup when build with -flto (--enable-optimize=-O3): 0x75ce5d8f in nsCOMPtr_base::assign_with_AddRef(nsISupports*) [clone .constprop.13162] () from /var/tmp/moz-build-dir/dist/bin/libxul.so (gdb) bt #0 0x75ce5d8f in nsCOMPtr_base::assign_with_AddRef(nsISupports*) [clone .constprop.13162] () from /var/tmp/moz-build-dir/dist/bin/libxul.so #1 0x73fe60eb in nsSocketTransport::OnSocketDetached(PRFileDesc*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #2 0x73eb74ac in nsSocketTransportService::DetachSocket(nsSocketTransportService::SocketContext*, nsSocketTransportService::SocketContext*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #3 0x73fff28f in nsSocketTransportService::Run() () from /var/tmp/moz-build-dir/dist/bin/libxul.so #4 0x74059c6a in nsThread::ProcessNextEvent(bool, bool*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #5 0x75ce5b39 in NS_ProcessNextEvent(nsIThread*, bool) [clone .constprop.13167] () from /var/tmp/moz-build-dir/dist/bin/libxul.so #6 0x745af7a0 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #7 0x73ec649d in MessageLoop::Run() () from /var/tmp/moz-build-dir/dist/bin/libxul.so #8 0x73fe7a56 in nsThread::ThreadFunc(void*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #9 0x77e7757c in _pt_root () from /var/tmp/moz-build-dir/dist/bin/libnspr4.so #10 0x77bc41e2 in start_thread () from /lib/libpthread.so.0 #11 0x774932ad in clone () from /lib/libc.so.6 When I build with PGO/LTO Firefox crashes later (when I close a tab with e.g.: https://github.com/JuliaLang/julia/pull/6018 ): Program received signal SIGSEGV, Segmentation fault. 0x751645ed in PL_DHashTableEnumerate(PLDHashTable*, PLDHashOperator (*)(PLDHashTable*, PLDHashEntryHdr*, unsigned int, void*), void*) () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so (gdb) bt #0 0x751645ed in PL_DHashTableEnumerate(PLDHashTable*, PLDHashOperator (*)(PLDHashTable*, PLDHashEntryHdr*, unsigned int, void*), void*) () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #1 0x75754d32 in PresShell::Destroy() () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #2 0x75754831 in nsDocumentViewer::DestroyPresShell() () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #3 0x755ee5c4 in nsDocumentViewer::Hide() () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #4 0x757b72eb in nsDocShell::SetVisibility(bool) () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #5 0x75a589a4 in nsFrameLoader::Hide() () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #6 0x75a588f6 in nsHideViewer::Run() () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #7 0x753b97de in nsContentUtils::RemoveScriptBlocker() () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #8 0x753cc954 in nsDocument::EndUpdate(unsigned int) () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #9 0x75651dd6 in mozilla::dom::XULDocument::EndUpdate(unsigned int) () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #10 0x7549673b in nsINode::doRemoveChildAt(unsigned int, bool, nsIContent*, nsAttrAndChildArray&) () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #11 0x75496085 in nsXULElement::RemoveChildAt(unsigned int, bool) () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #12 0x75494df9 in nsINode::RemoveChild(nsINode&, mozilla::ErrorResult&) () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #13 0x75494a00 in mozilla::dom::NodeBinding::removeChild(JSContext*, JS::Handle, nsINode*, JSJitMethodCallArgs const&) [clone .lto_priv.13709] () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #14 0x753b01e7 in mozilla::dom::GenericBindingMethod(JSContext*, unsigned int, JS::Value*) () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #15 0x75262744 in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #16 0x7524a14c in Interpret(JSContext*, js::RunState&) () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #17 0x75249801 in js::RunScript(JSContext*, js::RunState&) () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #18 0x752627ec in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) () from /var/tmp/firefox-destdir/usr/lib/firefox-30.0a1/libxul.so #19 0x752a574c in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsign
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #8 from Alisdair Meredith --- I agree with Mark's analysis. I was trying to force use of swap on a local class, and found a pattern that worked for libc++ but missed that neither template would be more specialized - my original attempt used friends ands not valid for other reasons. The key is that libc++ SFINAEs swap on the type requirements, while libstdc++ defers the error until swap is instantiated. I am still surprised that I get an error for calling the move operations of 'local' though (in the second example) rather than getting an ambiguous lookup. I think the first example is unambiguously a user-error (mine) by this analysis.
[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-06 CC||trippels at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #3 from Markus Trippelsdorf --- Confirmed.
[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449 --- Comment #4 from Martin Jambor --- Created attachment 32291 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32291&action=edit Untested proposed fix Untested proposed fix
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #202 from H.J. Lu --- LTO miscompiles 435.gromacs in SPEC CPU 2006 on x32 with -mx32 -O3 -funroll-loops -ffast-math since r208165 (PR 60418). Can you try r208163?
[Bug preprocessor/60436] [4.8/4.9 Regression] C preprocessor segfaults on assembly file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60436 --- Comment #8 from joseph at codesourcery dot com --- Implicit preincludes should probably be disabled when preprocessing .S files (though I don't know if that would help with this issue).
[Bug debug/56974] c++ ref qualifiers not represented in DWARF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56974
Jan Kratochvil changed:
What|Removed |Added
CC||jan.kratochvil at redhat dot
com
--- Comment #1 from Jan Kratochvil ---
"&&": g++-4.8.2 for 'void f(int &&r) {}' produces DW_TAG_rvalue_reference_type.
Or do you mean something else?
[Bug debug/56974] c++ ref qualifiers not represented in DWARF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56974
--- Comment #2 from Tom Tromey ---
(In reply to Jan Kratochvil from comment #1)
> "&&": g++-4.8.2 for 'void f(int &&r) {}' produces
> DW_TAG_rvalue_reference_type.
>
> Or do you mean something else?
"ref qualifiers" is a term from C++11 relating to the
mechanism for putting constraints on the receiver
of a method call. E.g.:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00024.html
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #9 from H.J. Lu --- One pass removes a preheader in if (_47 > 0) goto ; else goto ; : : # n_20 = PHI <1(3), n_269(7)> and becomes: if (_47 > 0) goto ; else goto ; : # n_20 = PHI <1(2), n_269(6)> The next pass adds the preheader back: if (_47 > 0) goto ; else goto ; : # n_264 = PHI <1(2)> : # n_20 = PHI which changes the loop behavior and generates different results.
[Bug middle-end/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #6 from Allan Jensen ---
(In reply to Richard Biener from comment #5)
> Can you identify the inlined call? Is it
>
> if (pSLL && y == pSLL->scanline) {
> loadAET(&AET, pSLL->edgelist);
> pSLL = pSLL->next;
> }
>
> or
>
> if (pSLL && y == pSLL->scanline) {
> loadAET(&AET, pSLL->edgelist);
> computeWAET(&AET);
> pSLL = pSLL->next;
> }
>
> ?
>
It is the first one (at least that is the one I have triggered).
> Can you also show the correct and the invalid assembly snippet?
I haven't really been able to identify it except that between code from loadAET
and the following while loop, there appears to be no code loading the variable
pAET which controls the loop, it appears to be loaded before loadAET, even
though loadAET may change it.
Note that I have made a work-around for the issue by making AET a pointer to an
EdgeTableEntry on the heap instead of an object on the stack. I believe somehow
the aliasing between AET and the pointers in loadAET which may point to it is
lost by GCC.
>
> Not sure if it is possible, but having a "driver" around this (in
> a separate compilation-unit) that calls PolygonRegion, verifying correct
> output for correct input
> and thus showing the miscompile would be nice (so there is a runtime
> testcase). It doesn't matter if linking requires Qt.
>
> I am somewhat lost in that large function ;)
I posted like this in case the description would be enough to make someone know
where to look. If you need to debug it and dig into it, I will try to make a
proper reduced test case.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #203 from Markus Trippelsdorf --- (In reply to H.J. Lu from comment #202) > LTO miscompiles 435.gromacs in SPEC CPU 2006 on x32 with > > -mx32 -O3 -funroll-loops -ffast-math > > since r208165 (PR 60418). Can you try r208163? Yes. Unfortunately with r208163 Firefox still crashes on startup.
[Bug target/60387] The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60387 --- Comment #12 from Nistor, Mihail-Marian --- The ppc gcc uses the DWARF register number mapping that is defined by the psABI, but the main problem is: the psABI is for AI32/64 architectures. The DWARF register number mapping is also used to encode all debug data information so the affected DWARF sections are: .debug_info and .debug_frame. The ppc gcc must document division from the PPC ABI standard (see an example at comment 2). It should also specify that the internal/unofficial DWARF register number mapping will be used for .eh_frame and DWARF standard. The AI32/64 ABI consists of the following: psABI, ABI-EH and SWCONV (see more information at http://mentorembedded.github.io/cxx-abi/abi.html on 1.5 Base Document). An important notice here is the primary API for this architecture (psABI) refers ABI-EH and SWCONV documents. In the SWCONV document the AI32/64 describes how the debugger should access the data that are particular for this architecture (see more information in 11. Stack Unwinding and Exception Handling chapter). I didn’t see any documents on how the support is done for PPC architecture. This document must be provided and the PPC ABI must refer to it. I don’t think that the most important rules from the “11.3 Coding Conventions for Reliable Unwinding” chapter from SWCONV were followed by the ppc gcc implementation. The “prolog” and “epilog” ranges do not obey these rules defined in 11 chapter. Until the above problems is solved we have a reference from DWARF3/4 that should be resolved by using undocumented ABI (the test case is: the debugger should compute the location for a local variable that is related to the frame base (DW_AT_location is defined as DW_OP_fbreg) and the value for DW_AT_frame_base is defined as DW_OP_call_frame_cfa for current function). I have been looking to see a full specification and implementation for this custom solution.
[Bug c/60442] No -Wparentheses warning for "if (a += b)"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60442 --- Comment #3 from Chengnian Sun --- (In reply to Jakub Jelinek from comment #1) > I'm not convinced there is anything wrong. The reason to warn about if(a = > b) or if(a = a + b) is that way too often people just mean to write if(a == > b) > or if(a == a + b) instead, but confusing += for == happens orders of > magnitude less often. Thanks, Jakub and Jonathan.
[Bug c/60442] No -Wparentheses warning for "if (a += b)"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60442 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #4 from Marek Polacek --- I agree with Jakub and Jonathan. Closing.
