[Bug fortran/61910] undefined computation in trans-expr.c gfc_conv_cst_int_power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61910 --- Comment #3 from Vittorio Zecca zeccav at gmail dot com --- A fix for the offending instruction at trans-expr.c:2107 n = (unsigned HOST_WIDE_INT) (m 0 ? -m : m); might be n = (unsigned HOST_WIDE_INT) (m 0 ? - (unsigned HOST_WIDE_INT) m : m); So it seems this is not a sanitizer bug.
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #4 from ktkachov at gcc dot gnu.org --- (In reply to Evandro Menezes from comment #3) Created attachment 33246 [details] This patch should fix this issue, though it needs a test-case Please post to gcc-patches with a testcase. I'd prefer if you used TARGET_FP rather than !TARGET_GENERAL_REGS_ONLY
[Bug lto/48200] linking shared library with LTO results in different exported symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 Alan Modra amodra at gmail dot com changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #11 from Alan Modra amodra at gmail dot com --- There's a similar issue when compiling libgcc for powerpc64. libgcc/config/rs6000/ibm-ldouble.c has these aliases: __asm__ (.symver __gcc_qadd,_xlqadd@GCC_3.4\n\t .symver __gcc_qsub,_xlqsub@GCC_3.4\n\t .symver __gcc_qmul,_xlqmul@GCC_3.4\n\t .symver __gcc_qdiv,_xlqdiv@GCC_3.4\n\t .symver .__gcc_qadd,._xlqadd@GCC_3.4\n\t .symver .__gcc_qsub,._xlqsub@GCC_3.4\n\t .symver .__gcc_qmul,._xlqmul@GCC_3.4\n\t .symver .__gcc_qdiv,._xlqdiv@GCC_3.4); Which seem to get dropped if you use -flto.
[Bug c++/62017] New: AddressSanitizer reports *-buffer-overflow in destructor when multiple virtual inheritance is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62017
Bug ID: 62017
Summary: AddressSanitizer reports *-buffer-overflow in
destructor when multiple virtual inheritance is used
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bezkrovatki at gmail dot com
Consider the following sample code (test.cpp):
struct IA
{
virtual ~IA() {}
};
struct IB
{
virtual ~IB() {}
};
struct IC: virtual IA, virtual IB {};
struct CA : virtual IA {};
struct CB: virtual IB {};
struct CC: virtual IC, CA, CB {};
int main()
{
CC c;
return 0;
}
Compile it with g++ 4.9.1 (Debian sid amd64):
g++ -o test.asan -g -O0 -fno-omit-frame-pointer -fsanitize=address test.cpp
Running it gives the following report:
==3591==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff92d37da0 at pc 0x400f58 bp 0x7fff92d37d20 sp 0x7fff92d37d18
WRITE of size 16 at 0x7fff92d37da0 thread T0
#0 0x400f57 in IC::~IC() test.cpp:11
#1 0x401675 in CC::~CC() test.cpp:17
#2 0x400a20 in main test.cpp:22
#3 0x7fd0c55a6b44 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
#4 0x4008b8 (test.asan+0x4008b8)
Address 0x7fff92d37da0 is located in stack of thread T0 at offset 48 in frame
#0 0x400995 in main test.cpp:20
This frame has 1 object(s):
[32, 56) 'c' == Memory access at offset 48 partially overflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow test.cpp:11 IC::~IC()
Shadow bytes around the buggy address:
0x10007259ef60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007259ef70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007259ef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007259ef90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007259efa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
=0x10007259efb0: f1 f1 00 00[00]f4 f3 f3 f3 f3 00 00 00 00 00 00
0x10007259efc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007259efd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007259efe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007259eff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007259f000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Contiguous container OOB:fc
ASan internal: fe
==3591==ABORTING
When an object of type CC is allocated on heap the error is reported as well.
If an object of type CC is aggregated into another type and followed by another
field (e.g. the type of variable 'c' from the sample is
std::pairCC,std::nullptr_t) then the error no is reported.
No error is observed when clang++ 3.4.2 or g++ 4.8.3 is used.
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Target||aarch64-* Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-05 Ever confirmed|0 |1 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- According to the documentation, not defining TARGET_SPILL_CLASS is equivalent to returning NO_REGS for all inputs. The symptoms that you describe indicate a problem elsewhere or an attempt to paper over the problem rather than the correct fix. The smoking gun for me is to suspect an errant pattern with incorrectly marked simd attributes rather than anything else. Look at the way in which the simd attribute is set on *addsi3_aarch64 for e.g. Without a testcase and without instructions to reproduce the problems as per https://gcc.gnu.org/bugs/#report it is not possible to work out what's going on here. Next time please also remember to fill in Target, Known to work, Known to fail and Keywords fields as well.
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 --- Comment #6 from ktkachov at gcc dot gnu.org --- One crude way to look is by looking for the w constraint that signifies usage of FP registers in the md files and seeing whether those usages are properly guarded by the 'simd' attribute or by TARGET_FLOAT/TARGET_SIMD. One quick search shows the absdi2 define_insn_and_split that uses 'w' in its second alternative to emit abs\\t%d0, %d1 but doesn't guard it by the 'simd' attribute. Maybe that's a place to start to construct a testcase
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 --- Comment #7 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to ktkachov from comment #6) One crude way to look is by looking for the w constraint that signifies usage of FP registers in the md files and seeing whether those usages are properly guarded by the 'simd' attribute or by TARGET_FLOAT/TARGET_SIMD. One quick search shows the absdi2 define_insn_and_split that uses 'w' in its second alternative to emit abs\\t%d0, %d1 but doesn't guard it by the 'simd' attribute. Maybe that's a place to start to construct a testcase Thanks, I was about to do this after my morning cuppa :) If this was noticed from a testcase, it should be trivial to work out which pattern it was that had the w registers by just looking at the output with -dp. Anyway I agree that absdi2 looks the most suspicious.
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 --- Comment #8 from ktkachov at gcc dot gnu.org --- Also, James pointed out the patterns in the region of aarch64_movtilow_tilow. They use SIMD registers to move wide values but are not guarded.
[Bug ipa/62015] [4.8/4.9/4.10 Regression] ipa-cp-clone uses a clone that is too specialized for the call context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62015 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||jamborm at gcc dot gnu.org Known to work||4.7.2 Target Milestone|--- |4.8.4 Summary|ipa-cp-clone uses a clone |[4.8/4.9/4.10 Regression] |that is too specialized for |ipa-cp-clone uses a clone |the call context|that is too specialized for ||the call context
[Bug middle-end/61529] [4.10 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61529 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||dehao at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r210538.
[Bug target/62011] False Data Dependency in popcnt instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target|X86_64-*-* |x86_64-*-*, i?86-*-* --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Please clarify - this is a defect in the CPU? Can you point to an official errata? In which case we might want to adjust the scheduler description used for GENERIC tuning (and for the specific broken CPUs). Not sure if we want to disable popcnt use completely.
[Bug ipa/62016] [4.8/4.9/4.10 Regression] very slow compilation at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62016 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-05 Target Milestone|--- |4.8.4 Summary|very slow compilation at|[4.8/4.9/4.10 Regression] |-O3 on x86_64-linux-gnu |very slow compilation at ||-O3 on x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. 4.8 is slowest (very very slow), 4.9 is a lot better but still 100x slower than 4.7. 4.7: TOTAL : 0.09 0.01 0.10 6621 kB 4.8: not finished after 6min 30s 4.9: ipa inlining heuristics : 2.99 (93%) usr 0.12 (92%) sys 3.11 (93%) wall 406507 kB (99%) ggc 4.10 (take with grain of salt - unoptimized and with checking): ipa inlining heuristics : 6.81 (90%) usr 0.15 (94%) sys 6.95 (90%) wall 426678 kB (99%) ggc
[Bug ipa/62016] [4.8/4.9/4.10 Regression] very slow compilation at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62016 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Would be nice to identify what improved 4.9 here and backport that to 4.8. And of course try to fix it for real for 4.10. ISTR the predicate stuff was a major hog.
[Bug bootstrap/62005] [4.10 regression] with --enable-checking=rtl : loop-unroll.c:2095:10: error: function may return address of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Aug 5 08:09:00 2014 New Revision: 213621 URL: https://gcc.gnu.org/viewcvs?rev=213621root=gccview=rev Log: * loop-unroll.c (struct iv_to_split): Remove n_loc and loc fields. (analyze_iv_to_split_insn): Don't initialize them. (get_ivts_expr): Removed. (allocate_basic_variable, insert_base_initialization): Use SET_SRC instead of *get_ivts_expr. (split_iv): Use SET_SRC instead of get_ivts_expr. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-unroll.c
[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||aarch64-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-05 Assignee|unassigned at gcc dot gnu.org |ramana at gcc dot gnu.org Summary|[AArch64] Default use of|[AArch64] High amounts of |the LRA results in extra|GP to FP register moves |code size |using LRA on AArch64 Ever confirmed|0 |1 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- We've noticed this overeagerness hurting in a number of places including SPEC2k(6) for Cortex-A57 and are in the process of fixing up REGISTER_MOVE_COST and MEMORY_MOVE_COST to fix this up for those cores. That is the first source of reducing these number of moves. If you have more examples and more analysis from outside these benchmarks it would be useful to help look for such cases.
[Bug ipa/62016] [4.8/4.9/4.10 Regression] very slow compilation at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62016 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- estimate_calls_size_and_time is responsible: callgrind shows during compilation: PID 8134: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/cc1 -quiet small.c -quiet -dumpbase small.c -mtune=generic -march=x86-64 -auxbase small -O3 -o /tmp/cc5Ji2sS.s sending command status internal to pid 8134 Totals: Ir Th 1 7,602,583,430 Frame: Ir Backtrace for Thread 1 [ 0] 198,528,310,004 estimate_calls_size_and_time(cgraph_node*, int*, int*, int*, unsigned int, vectree_node*, va_heap, vl_ptr, vectree_node*, va_heap, vl_ptr, vecipa_agg_jump_function*, va_heap, vl_ptr) [clone .isra.48.371314.34966] (58874971 x) ... [34] 198,528,323,290 estimate_calls_size_and_time(cgraph_node*, int*, int*, int*, unsigned int, vectree_node*, va_heap, vl_ptr, vectree_node*, va_heap, vl_ptr, vecipa_agg_jump_function*, va_heap, vl_ptr) [clone .isra.48.371314.34966] (58874971 x) [35]7,299,677,321 estimate_calls_size_and_time(cgraph_node*, int*, int*, int*, unsigned int, vectree_node*, va_heap, vl_ptr, vectree_node*, va_heap, vl_ptr, vecipa_agg_jump_function*, va_heap, vl_ptr) [clone .isra.48.371314.34966] (68761 x) [36]7,276,594,294 estimate_calls_size_and_time(cgraph_node*, int*, int*, int*, unsigned int, vectree_node*, va_heap, vl_ptr, vectree_node*, va_heap, vl_ptr, vecipa_agg_jump_function*, va_heap, vl_ptr) [clone .isra.48.371314.34966] (35608 x) [37]7,286,199,223 estimate_node_size_and_time(cgraph_node*, unsigned int, vectree_node*, va_heap, vl_ptr, vectree_node*, va_heap, vl_ptr, vecipa_agg_jump_function*, va_heap, vl_ptr, int*, int*, int*, vecinline_param_summary, va_heap, vl_ptr) [clone .371325] (35570 x) [38]7,382,517,284 do_estimate_edge_time(cgraph_edge*) (35570 x) [39]7,376,457,586 do_estimate_edge_size(cgraph_edge*) (30094 x) [40]7,375,282,471 estimate_edge_size(cgraph_edge*) [clone .371672.55874] (64499 x) [41]7,376,509,640 do_estimate_growth_1(cgraph_node*, void*) [clone .371011] (78 x) [42]7,376,511,655 cgraph_for_node_and_aliases(cgraph_node*, bool (*)(cgraph_node*, void*), void*, bool) (78 x) [43]7,376,515,292 do_estimate_growth(cgraph_node*) (78 x)
[Bug middle-end/62018] New: FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 Bug ID: 62018 Summary: FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, rguenther at suse dot de Host: x86_64-apple-darwin13 Target: x86_64-apple-darwin13 Build: x86_64-apple-darwin13 On x86_64-apple-darwin13 I get the following failures FAIL: gcc.dg/torture/ftrapv-1.c -O0 execution test FAIL: gcc.dg/torture/ftrapv-1.c -O1 execution test FAIL: gcc.dg/torture/ftrapv-1.c -O2 execution test FAIL: gcc.dg/torture/ftrapv-1.c -O3 -fomit-frame-pointer execution test FAIL: gcc.dg/torture/ftrapv-1.c -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gcc.dg/torture/ftrapv-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gcc.dg/torture/ftrapv-1.c -O3 -g execution test FAIL: gcc.dg/torture/ftrapv-1.c -Os execution test FAIL: gcc.dg/torture/ftrapv-1.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/ftrapv-1.c -O2 -flto execution test According Iain Sandoe the tests pass on x86_64-apple-darwin12.
[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-05 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Can you please investigate a bit yourself? The test relies on fork()/wait() to work and properly return the exit status of the forked process.
[Bug ada/62019] New: [4.10 Regression] FAIL: gnat.dg/weak2.adb (test for excess errors) on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62019 Bug ID: 62019 Summary: [4.10 Regression] FAIL: gnat.dg/weak2.adb (test for excess errors) on x86_64-apple-darwin13 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: charlet at adacore dot com, ebotcazou at gcc dot gnu.org, iains at gcc dot gnu.org Host: x86_64-apple-darwin13 Target: x86_64-apple-darwin13 Build: x86_64-apple-darwin13 On x86_64-apple-darwin13 the test gnat.dg/weak2.adb has started to fail between revisions r212916 (OK) and r213046. The error is raised CONSTRAINT_ERROR : erroneous memory access gnatmake: /opt/gcc/work/gcc/testsuite/gnat.dg/weak2.adb compilation error
[Bug ada/62019] [4.10 Regression] FAIL: gnat.dg/weak2.adb (test for excess errors) on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62019 Arnaud Charlet charlet at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-05 Ever confirmed|0 |1 --- Comment #1 from Arnaud Charlet charlet at gcc dot gnu.org --- Yes, I've also noticed that (on x86_64-pc-linux-gnu). As you might have noticed, this was caused by a non Ada (middle end or back end) change. Would be great if you could identify more precisely the change that caused this regressions.
[Bug middle-end/61876] Converting __builtin_round + cast into __builtin_lround is not always equivalent in regards to math errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61876 --- Comment #10 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Tue Aug 5 09:52:21 2014 New Revision: 213628 URL: https://gcc.gnu.org/viewcvs?rev=213628root=gccview=rev Log: [convert.c] PR 61876: Guard transformation to lrint by -fno-math-errno. * convert.c (convert_to_integer): Guard transformation to lrint by -fno-math-errno. Modified: trunk/gcc/ChangeLog trunk/gcc/convert.c
[Bug middle-end/61876] Converting __builtin_round + cast into __builtin_lround is not always equivalent in regards to math errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61876 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.10.0 Resolution|--- |FIXED --- Comment #11 from ktkachov at gcc dot gnu.org --- The lround and lrint cases are fixed on trunk.
[Bug target/62011] False Data Dependency in popcnt instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov amonakov at gcc dot gnu.org --- I think adjusting for scheduling won't help much: rather than making the compiler aware of increased latency, you'd need that either the register allocator avoids using a recently written hard register for popcnt (I'm not aware of such capability), or as a stopgap measure the compiler can issue a dependency-breaking instruction (xor %reg %reg) just before popcnt.
[Bug ada/62019] [4.10 Regression] FAIL: gnat.dg/weak2.adb (test for excess errors) on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62019 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I also noticed it, it comes from Jan's recent changes made to aliasing.
[Bug lto/62020] [4.10 regression] ICE in add_symbol_to_partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62020 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug lto/62020] New: [4.10 regression] ICE in add_symbol_to_partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62020 Bug ID: 62020 Summary: [4.10 regression] ICE in add_symbol_to_partition Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Host: *-*-solaris2.1[01] Target: *-*-solaris2.1[01] Build: *-*-solaris2.1[01] Between 20140725 (r213049) and 20140801 (r213453) occured a testsuite regression on Solaris (both sparc and x86, 32 and 64-bit): FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto -fabi-version=2 (internal compiler error) UNRESOLVED: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o execute -flto -fabi-version=2 The failure boils down to ./lto1 -quiet -fwpa cp_lto_20100302_0.o cp_lto_20100302_1.o lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:232 0x8295962 add_symbol_to_partition /vol/gcc/src/hg/trunk/local/gcc/lto/lto-partition.c:232 0x8295582 add_references_to_partition /vol/gcc/src/hg/trunk/local/gcc/lto/lto-partition.c:94 0x82956ce add_symbol_to_partition_1 /vol/gcc/src/hg/trunk/local/gcc/lto/lto-partition.c:168 0x8295de6 lto_balanced_map(int) /vol/gcc/src/hg/trunk/local/gcc/lto/lto-partition.c:501 0x82901d2 do_whole_program_analysis /vol/gcc/src/hg/trunk/local/gcc/lto/lto.c:3272 0x82901d2 lto_main() /vol/gcc/src/hg/trunk/local/gcc/lto/lto.c:3426 gdb finds #1 0x08295963 in add_symbol_to_partition (part=part@entry=0x9433aa0, node=0xface4040) at /vol/gcc/src/hg/trunk/local/gcc/lto/lto-partition.c:232 232 gcc_assert (node-get_partitioning_class () == SYMBOL_DUPLICATE (gdb) p node-get_partitioning_class() $1 = SYMBOL_PARTITION I can attach the .o files if this helps. Rainer
[Bug tree-optimization/62021] New: ICE in verify_gimple_assign_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62021
Bug ID: 62021
Summary: ICE in verify_gimple_assign_single
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ysrumyan at gmail dot com
For attached simple test-case if we omit 'uniform' specification compiler
produces ICE:
error: incorrect type of vector CONSTRUCTOR elements
Note that for stmt
_38 = {vect_cst_.62_39, vect_cst_.62_39};
we have type mismatch - type of rhs constructor element is vector(2) long
unsigned int whereas type of lhs is vector(4) float*.
If we add 'uniform' specification (through -DUNIFORM option) test compiles
successfully. I assume that ICE must be fixed.
[Bug tree-optimization/62021] ICE in verify_gimple_assign_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62021 --- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 33247 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33247action=edit test-case to reprroduce Test should be compiled with -O2 -fopenmp -march=core-avx2 options. If we add -DUNIFORM ICE will disappeared.
[Bug libstdc++/62022] New: [4.10 regression] 27_io/basic_ofstream/pthread2.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62022 Bug ID: 62022 Summary: [4.10 regression] 27_io/basic_ofstream/pthread2.cc FAILs Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Host: *-*-solaris2.1[01] Target: *-*-solaris2.1[01] Build: *-*-solaris2.1[01] Between 20140725 (r213049) and 20140801 (r213453), 27_io/basic_ofstream/pthread2.cc started to FAIL on Solaris: FAIL: 27_io/basic_ofstream/pthread2.cc execution test (both 32 and 64-bit, sparc and x86, Solaris 10 and 11): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2 (LWP 2)] 0xfe4b2a26 in realfree () from /lib/libc.so.1 (gdb) where #0 0xfe4b2a26 in realfree () from /lib/libc.so.1 #1 0xfe4b30f7 in cleanfree () from /lib/libc.so.1 #2 0xfe4b2509 in _malloc_unlocked () from /lib/libc.so.1 #3 0xfe4b2400 in malloc () from /lib/libc.so.1 #4 0xfe718c26 in operator new (sz=324) at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/new_op.cc:50 #5 0x0805138d in thread_main () at /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/27_io/basic_ofstream/pthread2.cc:36 #6 0xfe516a4c in _thrp_setup () from /lib/libc.so.1 #7 0xfe516cf0 in ?? () from /lib/libc.so.1 #8 0x in ?? () Only happens with current libstdc++.so, ok with 4.8 one provided by vendor. Rainer
[Bug libstdc++/62022] [4.10 regression] 27_io/basic_ofstream/pthread2.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62022 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug libstdc++/62023] New: [4.10 regression] 30_threads/condition_variable_any/50862.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62023 Bug ID: 62023 Summary: [4.10 regression] 30_threads/condition_variable_any/50862.cc FAILs Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Host: *-*-solaris2.1[01] Target: *-*-solaris2.1[01] Build: *-*-solaris2.1[01] Between 20140725 (r213049) and 20140801 (r213453), the 30_threads/condition_variable_any/50862.cc started to FAIL on Solaris (both 32 and 64-bit, sparc and x86, Solaris 10 and 11): FAIL: 30_threads/condition_variable_any/50862.cc execution test terminate called after throwing an instance of 'std::system_error' what(): Enable multithreading to use std::thread: Not owner Abort Happens only with current libstdc++.so, ok with 4.8 one provided by vendor. Rainer
[Bug libstdc++/62023] [4.10 regression] 30_threads/condition_variable_any/50862.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62023 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug c/62024] New: __atomic_always_lock_free is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024 Bug ID: 62024 Summary: __atomic_always_lock_free is not a constant expression Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: amanieu at gmail dot com This line causes an error despite the documentation saying that __atomic_always_lock_free is a constant expression: _Static_assert(__atomic_always_lock_free(sizeof(int), 0), ); test.c:1:16: error: expression in static assertion is not constant
[Bug ada/62019] [4.10 Regression] FAIL: gnat.dg/weak2.adb (test for excess errors) on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62019 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug lto/62020] [4.10 regression] ICE in add_symbol_to_partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62020 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I'm quite sure it's Honzas fault.
[Bug libstdc++/62023] [4.10 regression] 30_threads/condition_variable_any/50862.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62023
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
That exception comes from here in src/c++11/thread.cc
void
thread::_M_start_thread(__shared_base_type __b)
{
if (!__gthread_active_p())
#if __EXCEPTIONS
throw system_error(make_error_code(errc::operation_not_permitted),
Enable multithreading to use std::thread);
Which means the __gthread_active_p() function in libgcc/gthr-posix.h is
returning false (I think the Not owner part is a red herring, due to the
errc::operation_not_permitted enum having the wrong value on Solaris)
[Bug rtl-optimization/61672] [4.9 Regression] Less redundant instructions deleted by pre_delete after r208113.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61672 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Summary|[4.9/4.10 Regression] Less |[4.9 Regression] Less |redundant instructions |redundant instructions |deleted by pre_delete after |deleted by pre_delete after |r208113.|r208113. Known to fail||4.9.1 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- Invalid.
[Bug tree-optimization/62021] ICE in verify_gimple_assign_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62021 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. The constructor is built in vectorizable_simd_clone_call 2958 vec_oprnd0 = build_constructor (atype, ctor_elts); 2959 new_stmt 2960= gimple_build_assign (make_ssa_name (atype, NULL), 2961 vec_oprnd0); (gdb) p debug_generic_expr (atype) vector(4) float * huh. The actual elements in the constructor are of type vector(2) long unsigned int Seems bestn-simdclone-args[i].vector_type seems to miss that we substitute integer types for all pointer types in vectors (pointer element vectors are disallowed)?
[Bug target/62011] False Data Dependency in popcnt instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011 --- Comment #3 from Andev debiandev at gmail dot com --- This seems to be specific to some latest Intel CPUs. I am not sure which other CPUs are affected. There is no official errata for this behavior AFAIK. As Alexander suggested, it would be a great idea to have a work around for this in gcc for these specific CPUs.
[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Can you please investigate a bit yourself? The test relies on fork()/wait() to work and properly return the exit status of the forked process. Where should I start?
[Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from ktkachov at gcc dot gnu.org --- These are fixed now on arm and aarch64, thanks.
[Bug go/61866] FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61866 --- Comment #3 from Ian Lance Taylor ian at airs dot com --- *** Bug 61865 has been marked as a duplicate of this bug. ***
[Bug go/61865] FAIL: go.test/test/fixedbugs/bug272.go execution, -O2 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61865 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Ian Lance Taylor ian at airs dot com --- This is another instance of the bug fixed for PR 61866. *** This bug has been marked as a duplicate of bug 61866 ***
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 --- Comment #6 from Ian Lance Taylor ian at airs dot com --- I don't know why making the types smaller in comment #4 makes any difference. On a system that does not use split stacks, the runtime will allocate a 2M stack for each goroutine (see StackMin in libgo/runtime/proc.c). That is clearly more than large enough to hold a 8192 byte value. The comments in the test about splitting the stack only apply to systems that support stack splitting. This will need more investigation by somebody with access to an Alpha. I guess one simple first step would be to verify that USING_SPLIT_STACK and LINKER_SUPPORTS_SPLIT_STACK are both 0 in the file TARGET/libgo/config.h.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Ian Lance Taylor from comment #6) I don't know why making the types smaller in comment #4 makes any difference. On a system that does not use split stacks, the runtime will allocate a 2M stack for each goroutine (see StackMin in libgo/runtime/proc.c). That is clearly more than large enough to hold a 8192 byte value. The comments in the test about splitting the stack only apply to systems that support stack splitting. This will need more investigation by somebody with access to an Alpha. I guess one simple first step would be to verify that USING_SPLIT_STACK and LINKER_SUPPORTS_SPLIT_STACK are both 0 in the file TARGET/libgo/config.h. I can verify that they are undefined. Maybe the effects of split stack can be ruled out on x86 by forcing it to use libffi closures with non-split stack configuration?
[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- With a debugger? Yerk!-(
[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 --- Comment #3 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 5 Aug 2014, dominiq at lps dot ens.fr wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Can you please investigate a bit yourself? The test relies on fork()/wait() to work and properly return the exit status of the forked process. Where should I start? With a debugger?
[Bug go/61871] FAIL: regexp from libgo testsuite on non-split stack targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61871
--- Comment #1 from Uroš Bizjak ubizjak at gmail dot com ---
Ops, I was also testing with this patch:
--cut here--
Index: go/regexp/all_test.go
===
--- go/regexp/all_test.go(revision 213529)
+++ go/regexp/all_test.go(working copy)
@@ -475,7 +475,7 @@
// This ran out of stack before issue 7608 was fixed.
func TestOnePassCutoff(t *testing.T) {
- MustCompile(`^(?:x{1,1000}){1,1000}$`)
+ MustCompile(`^(?:x{1,1000}){1,500}$`)
}
func BenchmarkLiteral(b *testing.B) {
--cut here--
[Bug target/62025] New: [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025 Bug ID: 62025 Summary: [4.9/4.10 Regression] Miscompilation of openssl sha512.c Product: gcc Version: 4.9.1 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: krebbel at gcc dot gnu.org, rsandifo at gcc dot gnu.org Target: s390-linux Created attachment 33248 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33248action=edit sha.c The following testcase is miscompiled on s390-linux, starting with r207605 (including latest trunk), with e.g. -O2 -m31 -march=z196 -mtune=z10 options.
[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- If I remove the attribute 'no clone', the test succeeds with clang, but fails with at least gcc 4.8.3, 4.9.1, and trunk.
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.2 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- In *.sched1 I see no significant insn changes in between r207604 (works) and r207605 (aborts), just r14 is mentioned live on entry of various bbs. The testcase fails at r207605 also with -O2 -m31 -march=z196 -mtune=z10 -mno-lra. Richard or Andreas, can you please have a look?
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- -fno-shrink-wrap doesn't help.
[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #5 from Evandro Menezes e.menezes at samsung dot com --- Created attachment 33249 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33249action=edit Dhrystone, part 2 of 3 I firstly observed this issue when looking into Dhrystone built with fairly standard options: -O2 -fno-short-enums -fno-inline -fno-inline-functions -fno-inline-small-functions -fno-inline-functions-called-once -fomit-frame-pointer -funroll-all-loops If I add -mno-lra, the code size in dhry_1.o is about 2% smaller.
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 --- Comment #9 from Evandro Menezes e.menezes at samsung dot com --- It seems to me that it's the LRA which is forcing the use of FP registers, so, even if the patterns are fixed, I believe that in the end the combiner would just give up and ICE. With this assumption, which is open to corrections, I believe that the LRA needs to be properly managed according to the options passed on to the target.
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 --- Comment #10 from ktkachov at gcc dot gnu.org --- What we really need here is a preprocessed testcase showing the problem. It should be fairly easy to lock down on the problem then
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 --- Comment #11 from Evandro Menezes e.menezes at samsung dot com --- (In reply to ktkachov from comment #10) What we really need here is a preprocessed testcase showing the problem. It should be fairly easy to lock down on the problem then I'm on it.
[Bug c++/62017] AddressSanitizer reports *-buffer-overflow in destructor when multiple virtual inheritance is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62017 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||jakub at redhat dot com, ||kcc at gcc dot gnu.org, ||y.gribov at samsung dot com --- Comment #1 from Yury Gribov y.gribov at samsung dot com --- Adding sanitizer folks. It seems that size of standalone IC class is 16 but this shortens to 8 (due to virtual inheritance magic) when IC inherited in CC. GCC still emits 16 byte check which causes false positive.
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 --- Comment #12 from Richard Earnshaw rearnsha at gcc dot gnu.org --- aarch64_conditional_register_usage() marks all FP registers as unavailable if !TARGET_FLOAT. So the real question is why this isn't sufficient to disable use of FP registers.
[Bug c/52952] Wformat location info is bad (wrong column number)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #27 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #25) * Cases like: 1: const str[] = something %d; 2: printf(str); Note that clang is able to handle this: manuel@gcc10:~$ clang -Wformat format.c format.c:4:19: warning: more '%' conversions than data arguments [-Wformat] __builtin_printf(str); ^~~ format.c:3:33: note: format string is defined here const char str[] = something %d; ~^
[Bug c/52952] Wformat location info is bad (wrong column number)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #28 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
Testcase:
void foo(void)
{
char str[] = something %d;
__builtin_printf(str);
}
[Bug lto/62026] New: [4.9/4.10 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026 Bug ID: 62026 Summary: [4.9/4.10 Regression] Crash in lto_get_decl_name_mapping Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: d.g.gorbachev at gmail dot com Created attachment 33250 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33250action=edit Testcase Compile this testcase with `-O3 -flto -shared -nostdlib'.
[Bug lto/62026] [4.9/4.10 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- Created attachment 33251 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33251action=edit Backtrace from 4.10.0 Appeared in rev. (208444, 209348].
[Bug ada/62019] [4.10 Regression] FAIL: gnat.dg/weak2.adb (test for excess errors) on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62019 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- r21298O is OK, the test fails starting at r213007. Bootstrapping r212982 fails with In file included from ../../p_work/gcc/cgraphunit.c:164:0: ../../p_work/gcc/cgraphunit.c: In function 'void compile()': ../../p_work/gcc/cgraphunit.c:2249:56: error: 'symtab_alias_target' was not declared in this scope : DECL_ASSEMBLER_NAME (symtab_alias_target (node)-decl)); ^ ../../p_work/gcc/tree.h:2346:56: note: in definition of macro 'DECL_ASSEMBLER_NAME' #define DECL_ASSEMBLER_NAME(NODE) decl_assembler_name (NODE) and r213000 with ../../p_work/gcc/ada/gcc-interface/utils.c: In function 'void rest_of_subprog_body_compilation(tree)': ../../p_work/gcc/ada/gcc-interface/utils.c:2805:48: error: 'cgraph_get_create_node' was not declared in this scope (void) cgraph_get_create_node (subprog_decl); ^ gnatbind -nostdinc -I- -I. -Iada -I../../p_work/gcc/ada -I../../p_work/gcc/ada/gcc-interface -o b_gnatb.adb ada/gnatbind.ali mv b_gnatb.adb b_gnatb.ads ada/ ../../p_work/gcc/ada/gcc-interface/utils.c: In function 'void gnat_write_global_declarations()': ../../p_work/gcc/ada/gcc-interface/utils.c:5760:49: error: 'varpool_node_for_decl' was not declared in this scope node = varpool_node_for_decl (dummy_global); Giving up!
[Bug c++/62027] New: missing dwarf info for struct/union nested in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62027
Bug ID: 62027
Summary: missing dwarf info for struct/union nested in class
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sijun.liu at oracle dot com
Problem: For struct/union defined in class. their dwarf info are missing.
In the following test case, the dwarf info for Un and St are missing.
GNU C++ 4.8.1 -m64 -mtune=generic -march=x86-64 -g -std=c++11
Platform: Solaris 10 on intel chip
-- t.cc
class CLS {
public:
union Un {
int a;
int b;
};
struct St {
int c;
int d;
};
} A;
int main() {
return 1;
}
[Bug c++/62027] missing dwarf info for struct/union nested in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62027 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Well the struct/class are unused.
[Bug testsuite/62028] New: Power64/Linux: FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms SMS succeeded 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62028 Bug ID: 62028 Summary: Power64/Linux: FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms SMS succeeded 0 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ma...@linux-mips.org CC: ma...@linux-mips.org, revital.eres at linaro dot org Target: powerpc-linux-gnu Created attachment 33252 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33252action=edit Test case source I observe this failure: FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms SMS succeeded 0 in 64-bit Power/Linux testing. The test case (source attached) has a loop in `foo' that gets conditionally unrolled on 64-bit Power (but not on 32-bit Power where this test case passes): the incoming value of `ctr' is checked and if less than or equal to 2, then the unrolled loop is branched to, otherwise execution falls through to the regular loop. It is this unrolled loop that the SMS pass catches and handles I believe which is probably correct. What I am not sure of is whether this loop unrolling makes sense performance-wise, especially considering the code size increase from handling the two cases separately; someone with a better understanding of Power pipelines would have to have a look into it. Given the above I can't decide if it's the test case that is wrong and should e.g. exclude 64-bit Power or if this is a genuine failure. The test case binary executes successfully: PASS: gcc.dg/sms-8.c execution test so if a failure, then this is a missed optimisation rather than a code correctness issue. Options used to configure the compiler: --build=i686-pc-linux-gnu --target=powerpc-linux-gnu --with-cpu-32=603e --with-cpu-64=e5500 --with-long-double-128 Options used to build the test case: -O2 -fdiagnostics-color=never -fdump-rtl-sms -ffat-lto-objects -fmodulo-sched -fmodulo-sched-allow-regmoves -fno-diagnostics-show-caret -m64 The same issue triggers if: -mcpu=e6500 is additionally used with the test case.
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 --- Comment #13 from Evandro Menezes e.menezes at samsung dot com --- Created attachment 33253 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33253action=edit Test-case This test-case is a stripped-down version of Dhrystone, where the issue was first observed. Built with just -O2, it ends up with a handful of FMOVs, which are then avoided if -mno-lra is also specified.
[Bug middle-end/62029] New: Requesting new warning: missing const-qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62029
Bug ID: 62029
Summary: Requesting new warning: missing const-qualifier
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mi+gcc at aldan dot algebra.com
To help facilitate const-poisoning of the entire body of C (and C++) code out
there, I'd like to see a new warning, that would fire, when a pointer to any
object in any scope, that could've been marked as const, is not.
For example:
size_t
mylen(char *string)
{
if (string == NULL)
return 0;
else
return strlen(string);
}
void
example(struct object *o)
{
char *text = get_text(o);
size_t len = mylen(text);
}
The above code would warn in mylen, because the function's parameter could be
made const. As the developer fixes the low-level function to address the
warning, the higher level callers of these functions (such as example()) will
start warning -- and that will be a beautiful thing...
Some day the warning may even become part of -Wall.
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 Evandro Menezes e.menezes at samsung dot com changed: What|Removed |Added Attachment #33246|0 |1 is obsolete|| --- Comment #14 from Evandro Menezes e.menezes at samsung dot com --- Created attachment 33254 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33254action=edit Patch For the sake of correctness, this patch uses the more generic flag to qualify the spilling.
[Bug ipa/61602] [4.10 Regression] ICE in lto1 on x86_64-linux-gnu in ipa_single_use, at ipa.c:1257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61602 --- Comment #3 from Zhendong Su su at cs dot ucdavis.edu --- Hi, it would be really nice if this one could be fixed very soon as it keeps popping up during my testing. Many thanks!
[Bug debug/61923] [4.8/4.9/4.10 Regression] -fcompare-debug errors while building Linux kernel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923 --- Comment #5 from Vladimir Makarov vmakarov at gcc dot gnu.org --- The difference after scheduling a block is in DFA state because of additional advance_one_cycle call when debug_insns are present. The situation looks like -g last bb insn last real bb insn - advance_one_cycle -advance_one_cycle debug_insn -advance_one_cycle Last advance cycle is done at the end of processing all bb insns. I'll try to produce a patch tomorrow to fix it which is not easy as schedule_block is now very complicated function working in many modes and containing a lot of gotos.
[Bug rtl-optimization/62030] New: wrong code due to aliasing issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030
Bug ID: 62030
Summary: wrong code due to aliasing issue
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: alias, wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Blocks: 61964
Target: mipsisa64-elf
With a slightly modified version of the testcase for PR 61964 (I have an
optimization pass which does the optimization but I can confirm it with an
upstream GCC with the modified source), I get the failure on mipsisa64-elf.
Here is the testcase:
/* { dg-do run } */
extern void abort (void);
struct node { struct node *next, *prev; } node;
struct head { struct node *first; } heads[5];
int k = 2;
struct head *head = heads[2];
static int __attribute__((noinline))
foo()
{
node.prev = (void *)head;
head-first = node;
struct node *n = head-first;
struct head *h = heads[k];
struct node *next = n-next;
if (n-prev == (void *)h)
h-first = next;
else
n-prev-next = next;
n-next = h-first;
return n-next == node;
}
int main()
{
if (foo ())
abort ();
return 0;
}
Compile with -O2 -march=octeon to see the failure.
CE1 is where the combining of the two stores happen.
[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
Here are the two stores:
(insn 30 25 33 3 (set (mem/f:DI (reg/v/f:DI 200 [ prev ]) [5 MEM[(struct head
*)heads][_8].first+0 S8 A64])
(reg/v/f:DI 199 [ next ])) t.c:22 302 {*movdi_64bit}
(expr_list:REG_DEAD (reg/v/f:DI 200 [ prev ])
(expr_list:REG_DEAD (reg/v/f:DI 199 [ next ])
(nil
(insn 35 34 36 4 (set (mem/f:DI (reg/v/f:DI 200 [ prev ]) [3 prev_11-next+0 S8
A64])
(reg/v/f:DI 199 [ next ])) t.c:24 302 {*movdi_64bit}
(expr_list:REG_DEAD (reg/v/f:DI 200 [ prev ])
(expr_list:REG_DEAD (reg/v/f:DI 199 [ next ])
(nil
Note the reason why I think this does not happen for x86 (or even aarch64) is
due to the constraints on mem operands on MIPS.
