[Bug target/56253] fp-contract does not work with SSE and AVX FMAs (neither FMA4 nor FMA3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56253 --- Comment #13 from Agner Fog agner at agner dot org --- Thank you. I agree that integer overflow should be well-defined when using intrinsics. Is it possible to do the same optimization with boolean vector intrinsics, such as _mm_and_epi32 and _mm_or_ps to enable optimizations such as algebraic reduction and constant propagation?
[Bug lto/63333] lto, 1to1 segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 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 --- (In reply to Avi Kivity from comment #2) I managed to narrow it down to 400 lines (before preprocessing), strangely in one file. Now, practically anything I touch turns the segfault into link errors. Is this useful? I could share it privately. You could try one of the methods of: https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction I recommend C-reduce, because it produces the most minimal testcases.
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #33 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #32) Patch for SH untyped_call config/sh/sh.md (untyped_call): Clobber function value registers before call. (Sorry for butting in; I'm CC'ed with the purpose of observing issues likely to pop up for my own ports.) Will clobbering function-value registers before the call not cause problems on SH5, where function-value registers and parameters registers overlap (IIUC)? For reference, i386.md emits a blockage (i.e. *using* and clobbering all registers).
[Bug target/63351] Optimization: contract broadcast intrinsics when AVX512 is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63351
--- Comment #3 from Kirill Yukhin kyukhin at gcc dot gnu.org ---
Hello,
For AVX-512F (zmm-s)
We have a patch which enables such as stuff basing
on combiner machinery: a new subst which allows
`broadcasted' version of patterns.
Combiner can combine (load-bcst + actual insn)
into (actual insn w/ bcst-ed mem-op).
This patch generates emb. bcts for such a cases:
+/* { dg-options -O3 -mavxavx512f } */
+/* { dg-final { scan-assembler-times vpmulps\[
\\t\]+\[^\n\]*.*1to16.*%zmm\[0-9\]\[\\n\] 1 } } */
+
+#define N 16
+
+float f1 (float *c1_p, float *c2_p)
+{
+
+ float a[N];
+ float b[N];
+ float c[N];
+ float c1 = *c1_p;
+ float c2 = *c2_p;
+ int i;
+
+ for (i = 0; i N; i++)
+ {
+a[i] = c1;
+b[i] = c2;
+ }
+
+ for (i = 0; i N; i++)
+ {
+c[i] = a[i] * b[i];
+ }
+
+ return c[(int)(c1 + c2) % N];
+}
The patch almost no impact on Spec2006 (one of the reasons
is the combiner not working through bb-s).
For AVX-512VL ([xy]mm-s)
Such an optimization should be also applicable, when
all new patterns will reach the trunk.
[Bug target/56253] fp-contract does not work with SSE and AVX FMAs (neither FMA4 nor FMA3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56253 --- Comment #14 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Agner Fog from comment #13) Is it possible to do the same optimization with boolean vector intrinsics, such as _mm_and_epi32 and _mm_or_ps to enable optimizations such as algebraic reduction and constant propagation? Anything we already do with vector extensions should be easy, and that includes constant propagation in and |. The sightly harder part is transformations that are only valid if v is a bool vector (like replacing v!=0 with just v), i.e. each component is either 0 or -1. We can test constants, we know the result of comparisons is boolean, we know , | and ^ preserve that property, but it isn't a purely local property so it requires a bit more work.
[Bug target/56253] fp-contract does not work with SSE and AVX FMAs (neither FMA4 nor FMA3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56253 --- Comment #15 from Marc Glisse glisse at gcc dot gnu.org --- Oups, sorry, or_ps may be harder, because representing it with vector extensions requires casts to integer vectors, which makes it much harder to actually generate or_ps in the backend (there is at least one PR about that), so we probably won't do it soon.
[Bug c++/63249] [OpenMP] Spurious »set but not used« warnings when actually used in OpenMP target's array section's lower-bound and length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63249 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Sep 25 06:47:43 2014 New Revision: 215580 URL: https://gcc.gnu.org/viewcvs?rev=215580root=gccview=rev Log: PR c++/63249 * semantics.c (handle_omp_array_sections_1): Call mark_rvalue_use on low_bound and length. * g++.dg/gomp/pr63249.C: New test. * c-c++-common/gomp/pr63249.c: New test. 2014-09-25 Thomas Schwinge tho...@codesourcery.com PR c++/63249 * c-parser.c (c_parser_omp_variable_list): Call mark_exp_read on low_bound and length. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr63249.c trunk/gcc/testsuite/g++.dg/gomp/pr63249.C Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/63249] [OpenMP] Spurious »set but not used« warnings when actually used in OpenMP target's array section's lower-bound and length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63249 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Sep 25 06:50:58 2014 New Revision: 215581 URL: https://gcc.gnu.org/viewcvs?rev=215581root=gccview=rev Log: PR c++/63249 * semantics.c (handle_omp_array_sections_1): Call mark_rvalue_use on low_bound and length. * g++.dg/gomp/pr63249.C: New test. * c-c++-common/gomp/pr63249.c: New test. 2014-09-25 Thomas Schwinge tho...@codesourcery.com PR c++/63249 * c-parser.c (c_parser_omp_variable_list): Call mark_exp_read on low_bound and length. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/gomp/pr63249.c branches/gcc-4_9-branch/gcc/testsuite/g++.dg/gomp/pr63249.C Modified: branches/gcc-4_9-branch/gcc/c/ChangeLog branches/gcc-4_9-branch/gcc/c/c-parser.c branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/semantics.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/63348] [5 Regression] gcc.dg/pr43670.c fail on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 --- Comment #5 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to baoshan from comment #1) I believe this regression is introduced by the code for cleanup_barriers() in jump.c of patch https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02164.html: The call insn was followed by a barrier insn, the try_split() would emit another barrier insn after call insn for this case( I don't know why, please let me know the reason); after applying that patch and with option -g there would be a note instruction between the call and barrier insns which result no barrier insn is emitted by try_split(). Can you please try the patch at [1]? [1] https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02180.html
[Bug c++/63366] New: C++ __complex is not equivalent to __complex double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63366 Bug ID: 63366 Summary: C++ __complex is not equivalent to __complex double Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org Created attachment 33559 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33559action=edit Testcase showing that __complex is not equivalent to __complex double in C++ In function grokdeclarator () in cp/decl.c there is the following comment: /* If we just have complex, it is equivalent to complex double, but if any modifiers at all are specified it is the complex form of TYPE. E.g, complex short is complex short int. */ However in practice __complex is equivalent to __complex int. The attached testcase shows the problem and can be modified to try against __complex int. Best regards.
[Bug c++/63249] [OpenMP] Spurious »set but not used« warnings when actually used in OpenMP target's array section's lower-bound and length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63249 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #34 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Hans-Peter Nilsson from comment #33) Will clobbering function-value registers before the call not cause problems on SH5, where function-value registers and parameters registers overlap (IIUC)? Yes. I've forgot about SH5. Thanks for pointing it out. The patch should be conditionalized for SH5 on which this issue won't happen. For reference, i386.md emits a blockage (i.e. *using* and clobbering all registers). It looks all ports including SH emit a blockage after storing the function return values to a memory block, not before the call.
[Bug c++/63367] New: internal compiler error: tree check: expected function_decl, have template_decl in warn_hidden, at cp/class.c:2824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63367
Bug ID: 63367
Summary: internal compiler error: tree check: expected
function_decl, have template_decl in warn_hidden, at
cp/class.c:2824
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cas43 at cs dot stanford.edu
When trying to compile this:
class A {virtual void f();};
class B : public A {templateclass T void f();};
Run like this:
g++ -Woverloaded-virtual -c prog.cpp
I get this output:
prog.cpp:2:7: internal compiler error: tree check: expected function_decl, have
template_decl in warn_hidden, at cp/class.c:2824
class B : public A {templateclass T void f();};
^
0xdf6bf4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../s-trunk/gcc/tree.c:9167
0x64165c tree_check(tree_node*, char const*, int, char const*, tree_code)
../../s-trunk/gcc/tree.h:2733
0x64165c warn_hidden
../../s-trunk/gcc/cp/class.c:2824
0x64165c finish_struct_1(tree_node*)
../../s-trunk/gcc/cp/class.c:6518
0x641df4 finish_struct(tree_node*, tree_node*)
../../s-trunk/gcc/cp/class.c:6698
0x66fd32 cp_parser_class_specifier_1
../../s-trunk/gcc/cp/parser.c:19627
0x672690 cp_parser_class_specifier
../../s-trunk/gcc/cp/parser.c:19855
0x672690 cp_parser_type_specifier
../../s-trunk/gcc/cp/parser.c:14531
0x68d594 cp_parser_decl_specifier_seq
../../s-trunk/gcc/cp/parser.c:11772
0x693549 cp_parser_simple_declaration
../../s-trunk/gcc/cp/parser.c:11362
0x6748c3 cp_parser_block_declaration
../../s-trunk/gcc/cp/parser.c:11311
0x69eff5 cp_parser_declaration
../../s-trunk/gcc/cp/parser.c:11208
0x69dca8 cp_parser_declaration_seq_opt
../../s-trunk/gcc/cp/parser.c:11094
0x69f502 cp_parser_translation_unit
../../s-trunk/gcc/cp/parser.c:4059
0x69f502 c_parse_file()
../../s-trunk/gcc/cp/parser.c:32089
0x7c6112 c_common_parse_file()
../../s-trunk/gcc/c-family/c-opts.c:1043
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
Compiler:
Using built-in specs.
COLLECT_GCC=/home/craig/new-gcc/i-trunk/bin/g++
COLLECT_LTO_WRAPPER=/home/craig/new-gcc/i-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../s-trunk/configure --prefix=/home/craig/new-gcc/i-trunk
Thread model: posix
gcc version 5.0.0 20140924 (experimental) (GCC)
[Bug c/63368] New: undefined reference to `__sync_val_compare_and_swap_8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368
Bug ID: 63368
Summary: undefined reference to `__sync_val_compare_and_swap_8'
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mathieu.malaterre at gmail dot com
If I am reading the online documentation properly:
https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins
__sync_val_compare_and_swap on some targets will result in a function call
(where direct code generation is not available or not yet implemented).
It seems to be happening in my testcase, however __sync_val_compare_and_swap_8
does not seems to be defined anywhere else.
Steps:
$ cat t.c
#include stdint.h
int main()
{
int64_t x = 0, y = 1;
y = __sync_val_compare_and_swap(x, x, y);
return 0;
}
$ gcc t.c
/tmp/cc6JIpFx.o: In function `main':
t.c:(.text+0x64): undefined reference to `__sync_val_compare_and_swap_8'
collect2: ld returned 1 exit status
$ gcc t.c -lgcc_s
/tmp/ccu3ReMZ.o: In function `main':
t.c:(.text+0x64): undefined reference to `__sync_val_compare_and_swap_8'
collect2: ld returned 1 exit status
$ gcc t.c -lgcc
/tmp/ccO8gyeR.o: In function `main':
t.c:(.text+0x64): undefined reference to `__sync_val_compare_and_swap_8'
collect2: ld returned 1 exit status
[Bug target/63351] Optimization: contract broadcast intrinsics when AVX512 is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63351 --- Comment #4 from Kirill Yukhin kyukhin at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) ;; _7 = __builtin_ia32_pbroadcastd512_gpr_mask (b_1(D), _6, -1); (insn 7 6 8 (set (reg:SI 101) (reg/v:SI 99 [ b ])) ./include/avx512fintrin.h:3566 -1 (nil)) (insn 8 7 9 (set (reg:V16SI 102) (subreg:V16SI (reg/v:V8DI 83 [ __Y ]) 0)) ./include/avx512fintrin.h:3566 -1 (nil)) (insn 9 8 10 (set (reg:HI 103) (const_int -1 [0x])) ./include/avx512fintrin.h:3566 -1 (nil)) (insn 10 9 11 (set (reg:V16SI 100) (vec_merge:V16SI (vec_duplicate:V16SI (reg:SI 101)) (reg:V16SI 102) (reg:HI 103))) ./include/avx512fintrin.h:3566 -1 (nil)) (insn 11 10 0 (set (reg:V16SI 85 [ D.15281 ]) (reg:V16SI 100)) ./include/avx512fintrin.h:3566 -1 (nil)) which looks really awkward - or even bogus (insn 10). What's the semantics of _mm512_set1_epi32? This was generic approach when adding support for new built-ins. Straight-forward one would add following built-ins for almost every new insn: res = op_built_in (x) res = op_built_in_mask (x, res, mask) res = op_built_in_mask_zero (x, mask) Resulting up to 3 built-ins per new instruction (+ emb. rounding is also possible). We decided to add built-in for `op_built_in_mask' only resulting: res = op_built_in_mask (a, _mm512_undefined (), -1) res = op_built_in_mask (x, res, mask) res = op_built_in_mask (x, 0, mask) relying on optimizations to use proper pattern for all 3 cases. BTW, this is covered by tests. E.g. `__builtin_ia32_pbroadcastd512_gpr_mask' checked in `gcc.target/i386/avx512f-vpbroadcastd-1.c'. If compile it with `-O2' you could see that for: x = _mm512_set1_epi32 (z); following assembler is generated: movlz(%rip), %eax # 5 *movsi_internal/1 [length = 7] vpbroadcastd%eax, %zmm0 # 9 *avx512f_vec_dup_gprv16si [length = 6] vmovdqa64 %zmm0, x(%rip) # 12*movv8di_internal/3 [length = 11] It seems that all of the intrinsics expand to sth weird as the above (the vec_merge), even _mm512_add_epi32. I'm quite sure this doesn't make the combiners job easier. Definitely.
[Bug c/63368] undefined reference to `__sync_val_compare_and_swap_8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Libatomic includes them in 4.9 and above. As it says not yet implemented you need one for the target you are using.
[Bug c++/63367] internal compiler error: tree check: expected function_decl, have template_decl in warn_hidden, at cp/class.c:2824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63367 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- dup. *** This bug has been marked as a duplicate of bug 61945 ***
[Bug c++/61945] [5 Regression] tree check fail with -Woverloaded-virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||cas43 at cs dot stanford.edu --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 63367 has been marked as a duplicate of this bug. ***
[Bug c/63368] Provide an implementation for `__sync_val_compare_and_swap_8' on powerpc (32bits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368 Mathieu Malaterre mathieu.malaterre at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- Summary|undefined reference to |Provide an implementation |`__sync_val_compare_and_swa |for |p_8'|`__sync_val_compare_and_swa ||p_8' on powerpc (32bits) --- Comment #2 from Mathieu Malaterre mathieu.malaterre at gmail dot com --- Thanks for the clarification. I've re-open the bug for a request to support __sync_val_compare_and_swap (64bits) on PowerPC 32bits.
[Bug sanitizer/63369] New: many asan test cases fail on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63369 Bug ID: 63369 Summary: many asan test cases fail on ARM Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org with the trunk revision 215254 from 09/14 2014 I see the following asan test casese fail on armv7l-unknown-linux-gnueabihf FAIL: c-c++-common/asan/global-overflow-1.c -O2 output pattern test, is = FAIL: c-c++-common/asan/global-overflow-1.c -O3 -fomit-frame-pointer output pattern test, is = FAIL: c-c++-common/asan/global-overflow-1.c -O3 -g output pattern test, is = FAIL: c-c++-common/asan/global-overflow-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test, is = FAIL: c-c++-common/asan/global-overflow-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test, is = FAIL: c-c++-common/asan/heap-overflow-1.c -O0 output pattern test, is = FAIL: c-c++-common/asan/heap-overflow-1.c -O1 output pattern test, is = FAIL: c-c++-common/asan/heap-overflow-1.c -O2 output pattern test, is = FAIL: c-c++-common/asan/heap-overflow-1.c -O3 -fomit-frame-pointer output pattern test, is = FAIL: c-c++-common/asan/heap-overflow-1.c -O3 -g output pattern test, is = FAIL: c-c++-common/asan/heap-overflow-1.c -Os output pattern test, is = FAIL: c-c++-common/asan/heap-overflow-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test, is = FAIL: c-c++-common/asan/heap-overflow-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O0 output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O1 output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O2 output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O3 -fomit-frame-pointer output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O3 -g output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -Os output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O0 output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O1 output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O2 output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O3 -fomit-frame-pointer output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O3 -g output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -Os output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O2 -flto -fuse-linker-plugin
[Bug c/63368] Provide an implementation for `__sync_val_compare_and_swap_8' on powerpc (32bits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- -latomic is there already.
[Bug debug/63300] 'const volatile' sometimes stripped in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63300 --- Comment #4 from Andreas Krebbel krebbel at gcc dot gnu.org --- Author: krebbel Date: Thu Sep 25 07:37:36 2014 New Revision: 215582 URL: https://gcc.gnu.org/viewcvs?rev=215582root=gccview=rev Log: 2014-09-25 Andreas Arnez ar...@linux.vnet.ibm.com PR 63300/debug * tree.c (check_base_type): New. (check_qualified_type): Exploit new helper function above. * tree.h (check_base_type): New prototype. * dwarf2out.c (get_nearest_type_subqualifiers): New. (modified_type_die): Fix handling for qualifiers. Qualifiers to peel off are now determined using get_nearest_type_subqualifiers. 2014-09-25 Mark Wielaard m...@redhat.com PR 63300/debug * gcc.dg/debug/dwarf2/stacked-qualified-types-1.c: New testcase. * gcc.dg/debug/dwarf2/stacked-qualified-types-2.c: Likewise. * gcc.dg/guality/pr63300-const-volatile.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/debug/dwarf2/stacked-qualified-types-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/stacked-qualified-types-2.c trunk/gcc/testsuite/gcc.dg/guality/pr63300-const-volatile.c Modified: trunk/gcc/dwarf2out.c trunk/gcc/tree.c trunk/gcc/tree.h
[Bug lto/63333] lto, 1to1 segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 --- Comment #4 from rguenther at suse dot de rguenther at suse dot de --- On Thu, 25 Sep 2014, a...@cloudius-systems.com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 --- Comment #2 from Avi Kivity a...@cloudius-systems.com --- I managed to narrow it down to 400 lines (before preprocessing), strangely in one file. Now, practically anything I touch turns the segfault into link errors. Is this useful? I could share it privately. It's already useful.
[Bug tree-optimization/63341] [4.8/4.9/5 Regression] Vectorization miscompilation with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Sep 25 08:12:49 2014 New Revision: 215583 URL: https://gcc.gnu.org/viewcvs?rev=215583root=gccview=rev Log: PR tree-optimization/63341 * tree-vectorizer.h (vect_create_data_ref_ptr, vect_create_addr_base_for_vector_ref): Add another tree argument defaulting to NULL_TREE. * tree-vect-data-refs.c (vect_create_data_ref_ptr): Add byte_offset argument, pass it down to vect_create_addr_base_for_vector_ref. (vect_create_addr_base_for_vector_ref): Add byte_offset argument, add that to base_offset too if non-NULL. * tree-vect-stmts.c (vectorizable_load): Add byte_offset variable, for dr_explicit_realign_optimized set it to vector byte size - 1 instead of setting offset, pass byte_offset down to vect_create_data_ref_ptr. * gcc.dg/vect/pr63341-1.c: New test. * gcc.dg/vect/pr63341-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr63341-1.c trunk/gcc/testsuite/gcc.dg/vect/pr63341-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h
[Bug tree-optimization/63341] [4.8/4.9/5 Regression] Vectorization miscompilation with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Sep 25 08:17:32 2014 New Revision: 215585 URL: https://gcc.gnu.org/viewcvs?rev=215585root=gccview=rev Log: PR tree-optimization/63341 * tree-vectorizer.h (vect_create_data_ref_ptr, vect_create_addr_base_for_vector_ref): Add another tree argument defaulting to NULL_TREE. * tree-vect-data-refs.c (vect_create_data_ref_ptr): Add byte_offset argument, pass it down to vect_create_addr_base_for_vector_ref. (vect_create_addr_base_for_vector_ref): Add byte_offset argument, add that to base_offset too if non-NULL. * tree-vect-stmts.c (vectorizable_load): Add byte_offset variable, for dr_explicit_realign_optimized set it to vector byte size - 1 instead of setting offset, pass byte_offset down to vect_create_data_ref_ptr. * gcc.dg/vect/pr63341-1.c: New test. * gcc.dg/vect/pr63341-2.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr63341-1.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr63341-2.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-vect-data-refs.c branches/gcc-4_9-branch/gcc/tree-vect-stmts.c branches/gcc-4_9-branch/gcc/tree-vectorizer.h
[Bug tree-optimization/63341] [4.8/4.9/5 Regression] Vectorization miscompilation with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Sep 25 08:19:14 2014 New Revision: 215587 URL: https://gcc.gnu.org/viewcvs?rev=215587root=gccview=rev Log: PR tree-optimization/63341 * tree-vectorizer.h (vect_create_data_ref_ptr, vect_create_addr_base_for_vector_ref): Add another tree argument defaulting to NULL_TREE. * tree-vect-data-refs.c (vect_create_data_ref_ptr): Add byte_offset argument, pass it down to vect_create_addr_base_for_vector_ref. (vect_create_addr_base_for_vector_ref): Add byte_offset argument, add that to base_offset too if non-NULL. * tree-vect-stmts.c (vectorizable_load): Add byte_offset variable, for dr_explicit_realign_optimized set it to vector byte size - 1 instead of setting offset, pass byte_offset down to vect_create_data_ref_ptr. * gcc.dg/vect/pr63341-1.c: New test. * gcc.dg/vect/pr63341-2.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr63341-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr63341-2.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-vect-data-refs.c branches/gcc-4_8-branch/gcc/tree-vect-stmts.c branches/gcc-4_8-branch/gcc/tree-vectorizer.h
[Bug tree-optimization/63341] [4.8/4.9/5 Regression] Vectorization miscompilation with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed now.
[Bug c/63368] Provide an implementation for `__sync_val_compare_and_swap_8' on powerpc (32bits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368
--- Comment #4 from Mathieu Malaterre mathieu.malaterre at gmail dot com ---
As stated in my original report I am running a PowerPC/32bits machine (not an
ARM based one).
AFAIK gcc 4.9.1 does not provide such implementation [*]. Could you please
clarify what you mean by 'libatomic is there already' ?
[*]
% cat t.c
#include stdint.h
int main()
{
int64_t x = 0, y = 1;
y = __sync_val_compare_and_swap(x, x, y);
return 0;
}
% gcc -v t.c -latomic
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc-linux-gnu/4.9/lto-wrapper
Target: powerpc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-15'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-powerpc/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-powerpc
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-powerpc
--with-arch-directory=ppc --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-secureplt --disable-softfloat --with-cpu=default32
--disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux
--enable-multiarch --with-long-double-128 --enable-multilib
--enable-checking=release --build=powerpc-linux-gnu --host=powerpc-linux-gnu
--target=powerpc-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-15)
COLLECT_GCC_OPTIONS='-v'
/usr/lib/gcc/powerpc-linux-gnu/4.9/cc1 -quiet -v -imultiarch powerpc-linux-gnu
-D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux
-Asystem=linux -Asystem=unix -Asystem=posix t.c -msecure-plt -quiet -dumpbase
t.c -auxbase t -version -o /tmp/ccNTY4Ab.s
GNU C (Debian 4.9.1-15) version 4.9.1 (powerpc-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 6.0.0, MPFR version 3.1.2-p3,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory /usr/local/include/powerpc-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../../powerpc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/powerpc-linux-gnu/4.9/include
/usr/local/include
/usr/lib/gcc/powerpc-linux-gnu/4.9/include-fixed
/usr/include/powerpc-linux-gnu
/usr/include
End of search list.
GNU C (Debian 4.9.1-15) version 4.9.1 (powerpc-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 6.0.0, MPFR version 3.1.2-p3,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c43d4b06b119d970361c68b09a8c4f80
COLLECT_GCC_OPTIONS='-v'
as -v -a32 -mppc -many -mbig -o /tmp/cckOC6zg.o /tmp/ccNTY4Ab.s
GNU assembler version 2.24.51 (powerpc-linux-gnu) using BFD version (GNU
Binutils for Debian) 2.24.51.20140918
COMPILER_PATH=/usr/lib/gcc/powerpc-linux-gnu/4.9/:/usr/lib/gcc/powerpc-linux-gnu/4.9/:/usr/lib/gcc/powerpc-linux-gnu/:/usr/lib/gcc/powerpc-linux-gnu/4.9/:/usr/lib/gcc/powerpc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/powerpc-linux-gnu/4.9/:/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../powerpc-linux-gnu/:/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../../lib/:/lib/powerpc-linux-gnu/:/lib/../lib/:/usr/lib/powerpc-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v'
/usr/lib/gcc/powerpc-linux-gnu/4.9/collect2 -plugin
/usr/lib/gcc/powerpc-linux-gnu/4.9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/powerpc-linux-gnu/4.9/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc3I7gDk.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/
--build-id --eh-frame-hdr -V -m elf32ppclinux --hash-style=gnu -dynamic-linker
/lib/ld.so.1
/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../powerpc-linux-gnu/crt1.o
/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../powerpc-linux-gnu/crti.o
/usr/lib/gcc/powerpc-linux-gnu/4.9/crtbegin.o
-L/usr/lib/gcc/powerpc-linux-gnu/4.9
-L/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../powerpc-linux-gnu
-L/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../../lib -L/lib/powerpc-linux-gnu
-L/lib/../lib -L/usr/lib/powerpc-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/powerpc-linux-gnu/4.9/../../.. /tmp/cckOC6zg.o -latomic -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
[Bug sanitizer/63369] many asan test cases fail on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63369 Maxim Ostapenko chefmax at gcc dot gnu.org changed: What|Removed |Added CC||chefmax at gcc dot gnu.org --- Comment #1 from Maxim Ostapenko chefmax at gcc dot gnu.org --- Can't reproduce this with armv7-unknown-linux-gnueabi on current GCC, because libsanitizer merge from upstream happened (r215527). Could you try to use more recent GCC (after r215527)?
[Bug c/48850] Bogus overflow in constant expression warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48850 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Seems to be fixed now: the overflow in constant expression is gone.
[Bug testsuite/63305] ASan reported heap-buffer-overflow in gcc.target/i386/avx256-unaligned-load{store}-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63305
--- Comment #2 from Maxim Ostapenko chefmax at gcc dot gnu.org ---
Still fails on trunk:
$ ./xgcc -B./
~/workspace/downloads/gcc/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-7.c
-fsanitize=address -O3 -dp -mavx -mavx256-split-unaligned-load -o /tmp/a.out
-L../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs
-B../x86_64-unknown-linux-gnu/libsanitizer/asan/
-Wl,-R,../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs -fdump-tree-asan
$ /tmp/a.out
=
==4263==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60c0c000
at pc 0x00400b9c bp 0x7fff6dad1c20 sp 0x7fff6dad1c18
WRITE of size 8 at 0x60c0c000 thread T0
#0 0x400b9b in do_test (/tmp/a.out+0x400b9b)
#1 0x400845 in main (/tmp/a.out+0x400845)
#2 0x7f13038b976c in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
#3 0x400894 (/tmp/a.out+0x400894)
0x60c0c000 is located 0 bytes to the right of 128-byte region
[0x60c0bf80,0x60c0c000)
allocated by thread T0 here:
#0 0x7f1303ceeaa9 in __interceptor_malloc
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_malloc_linux.cc:38
#1 0x40098d in foo (/tmp/a.out+0x40098d)
SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 do_test
Shadow bytes around the buggy address:
0x0c187fff97b0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
0x0c187fff97c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c187fff97d0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c187fff97e0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
0x0c187fff97f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=0x0c187fff9800:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fff9810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fff9820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fff9830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fff9840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fff9850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
Container overflow: fc
Array cookie:ac
ASan internal: fe
==4263==ABORTING
$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-unknown-linux-gnu
Configured with: /home/max/workspace/downloads/gcc/configure
--enable-languages=c,c++ --disable-bootstrap --prefix=/usr/gcc-5.0.0
--with-local-prefix=/usr/local --enable-gnu-indirect-function --with-fpmath=sse
Thread model: posix
gcc version 5.0.0 20140925 (experimental) (GCC)
At line 36:
for (i = N; i = 0; i--)
{
*cp++ = str;
*dp++ = str;
}
Here cp itself is char **, so we move cp on sizeof (char *) on each loop
iteration.
Since N == 128 here, we have 129 iterations, so size of array cp points to
should be 129 * sizeof (char *). Correct?
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #35 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #32) Created attachment 33557 [details] Patch for SH untyped_call * config/sh/sh.md (untyped_call): Clobber function value registers before call. I'm just wondering ... how did/does that work without LRA (i.e. with IRA)?
[Bug c/63368] Provide an implementation for `__sync_val_compare_and_swap_8' on powerpc (32bits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- ppc32 doesn't have a 64-bit CAS instruction, so this would need to be done with a global lock, not an atomic instruction.
[Bug testsuite/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, there must be some difference that isn't visible in the serialized output, which would imply the values fail to do a proper round trip, so we're not writing them with enough precision. Maybe we should use hexfloat output for serializing distributions, not decimal.
[Bug libstdc++/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|testsuite |libstdc++ Version|unknown |4.9.0 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- The issue is not with VERIFY, which is just an assertion and so all it has to do is check for true or false. The assertion fails because distribution's operator== is saying the distributions are not equal, so either the operator== is buggy (but that would probably fail on all platforms) or the issue is in the serialization or deserialization. Could you please add -fno-access-control to the dg-options flags at the top of the file and replace the VERIFY check with the following: std::cout (u._M_param._M_lambda == v._M_param._M_lambda) '\n'; std::cout (u._M_param._M_mu == v._M_param._M_mu) '\n'; std::cout (u._M_param._M_nu == v._M_param._M_nu) '\n'; std::cout (u._M_gd1 == v._M_gd1) '\n'; std::cout (u._M_gd2 == v._M_gd2) '\n';
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #36 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #35) I'm just wondering ... how did/does that work without LRA (i.e. with IRA)? I'm not sure about the old reload. LRA makes only 3 uses of r0 and it's relatively easy to see what is going on there with .reload comments. The old reload makes many uses of r0 and it looks not easy to see how does that work.
[Bug c++/61945] [5 Regression] tree check fail with -Woverloaded-virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- I have a patch.
[Bug c++/63366] C++ __complex is not equivalent to __complex double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63366 thopre01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-25 Assignee|unassigned at gcc dot gnu.org |thopre01 at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/61945] [5 Regression] tree check fail with -Woverloaded-virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Sep 25 12:56:57 2014 New Revision: 215597 URL: https://gcc.gnu.org/viewcvs?rev=215597root=gccview=rev Log: PR c++/61945 * class.c (warn_hidden): Check for FUNCTION_DECL. * g++.dg/warn/pr61945.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/pr61945.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug c++/61945] [5 Regression] tree check fail with -Woverloaded-virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug sanitizer/63369] many asan test cases fail on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63369 --- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Maxim Ostapenko from comment #1) Can't reproduce this with armv7-unknown-linux-gnueabi on current GCC, because libsanitizer merge from upstream happened (r215527). Could you try to use more recent GCC (after r215527)? sure, I will try the next snapshot and come back with the results.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Created attachment 33560 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33560action=edit initial patch Here's an initial patch, but I'm not sure how to write an expression to test that doesn't call any non-trivial function like operator new.
[Bug other/63370] New: abi::__cxa_demangle fails when demangling globally defined lambda (or typeid.name returns wrong value)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63370
Bug ID: 63370
Summary: abi::__cxa_demangle fails when demangling globally
defined lambda (or typeid.name returns wrong value)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: vprimachenko at ya dot ru
Created attachment 33561
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33561action=edit
sample code which reproduces the bug
a c++11 lambda expression `[]()-void{}` defined in the `main` function gets
`Z4mainEUlvE_` as typeid.name which can be demangled to `main::{lambda()#1}`
using `abi::__cxa_demangle`. However a globally defined lambda gets reported
as just `UlvE_` and the demangle function fails with status code of -2 (error
mangled_name is not a valid name under the C++ ABI mangling rules.)
[Bug target/63335] GCC:failures for vector double on calls to bif vec_[all|any]_[nge|nle]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335 --- Comment #4 from Bill Schmidt wschmidt at gcc dot gnu.org --- Author: wschmidt Date: Thu Sep 25 14:06:09 2014 New Revision: 215599 URL: https://gcc.gnu.org/viewcvs?rev=215599root=gccview=rev Log: [gcc] 2014-09-25 Bill Schmidt wschm...@linux.vnet.ibm.com PR target/63335 * config/rs6000/rs6000-c.c (altivec_build_resolved_builtin): Exclude VSX_BUILTIN_XVCMPGEDP_P from special handling. [gcc/testsuite] 2014-09-25 Bill Schmidt wschm...@linux.vnet.ibm.com PR target/63335 * gcc.target/powerpc/pr63335.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr63335.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000-c.c trunk/gcc/testsuite/ChangeLog
[Bug c++/63356] [4.8/4.9/5 Regression] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- What version of GCC works? That is, how is this a regression?
[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Summary|[4.8/4.9/5 Regression] |Compilation failure where |Compilation failure where |clang does not have |clang does not have |problems |problems| --- Comment #11 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Richard Biener from comment #10) What version of GCC works? That is, how is this a regression? You're right it isn't.
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #2 from camm at debian dot org --- Created attachment 33563 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33563action=edit gdb transcript showing longjmp clobbering of f31
[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 Nick Clifton nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #6 from Nick Clifton nickc at redhat dot com --- Created attachment 33562 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33562action=edit Patch to fix typo in sync.md This bug is due to a typo in the sync.md file. I will be applying the uploaded patch to fix it shortly.
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #3 from camm at debian dot org --- Additional transcript showing the 0 f31 value is transmitted to the return of the original call through Lnk23 in L2.
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #4 from camm at debian dot org --- Created attachment 33564 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33564action=edit additional gdb transcript showing 0 f31 transmitted to return of Lnk23 in L2
[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 --- Comment #7 from Nick Clifton nickc at gcc dot gnu.org --- Author: nickc Date: Thu Sep 25 15:01:46 2014 New Revision: 215602 URL: https://gcc.gnu.org/viewcvs?rev=215602root=gccview=rev Log: PR target/62218 * config/sh/sync.md (atomic_fetch_nandmode_soft_imask): Fix typo in instruction sequence. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sync.md
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Attachment #33560|0 |1 is obsolete|| --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Created attachment 33565 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33565action=edit new patch how does this look?
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #5 from Andreas Schwab sch...@linux-m68k.org --- Please make sure all functions are called exactly as they are defined.
[Bug target/63335] GCC:failures for vector double on calls to bif vec_[all|any]_[nge|nle]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335 --- Comment #5 from Bill Schmidt wschmidt at gcc dot gnu.org --- Author: wschmidt Date: Thu Sep 25 15:12:42 2014 New Revision: 215603 URL: https://gcc.gnu.org/viewcvs?rev=215603root=gccview=rev Log: [gcc] 2014-09-25 Bill Schmidt wschm...@linux.vnet.ibm.com PR target/63335 * config/rs6000/rs6000-c.c (altivec_build_resolved_builtin): Exclude VSX_BUILTIN_XVCMPGEDP_P from special handling. [gcc/testsuite] 2014-09-25 Bill Schmidt wschm...@linux.vnet.ibm.com PR target/63335 * gcc.target/powerpc/pr63335.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/pr63335.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/rs6000/rs6000-c.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/63335] GCC:failures for vector double on calls to bif vec_[all|any]_[nge|nle]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335 --- Comment #6 from Bill Schmidt wschmidt at gcc dot gnu.org --- Author: wschmidt Date: Thu Sep 25 15:15:06 2014 New Revision: 215604 URL: https://gcc.gnu.org/viewcvs?rev=215604root=gccview=rev Log: [gcc] 2014-09-25 Bill Schmidt wschm...@linux.vnet.ibm.com PR target/63335 * config/rs6000/rs6000-c.c (altivec_build_resolved_builtin): Exclude VSX_BUILTIN_XVCMPGEDP_P from special handling. [gcc/testsuite] 2014-09-25 Bill Schmidt wschm...@linux.vnet.ibm.com PR target/63335 * gcc.target/powerpc/pr63335.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/pr63335.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/rs6000/rs6000-c.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/63371] New: kind() with function name (not call) as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63371 Bug ID: 63371 Summary: kind() with function name (not call) as argument Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org From https://groups.google.com/forum/#!topic/comp.lang.fortran/lbaOSWKSmhQ That's either a wrong-code or accepts-invalid issue, it requires some digging. But the output 0 is surely wrong and if it is valid, it makes only sense for functions and one has to be careful with generics. Example, which prints 0 instead of 2. Using a subroutine, it is even accepted instead of plainly rejected (hence accepts-invalid): INTERFACE FUNCTION f() INTEGER(SELECTED_INT_KIND(4)) :: f END FUNCTION f END INTERFACE PRINT *, KIND(f) END ! (just to provide a definition) FUNCTION f() INTEGER(SELECTED_INT_KIND(4)) :: f END FUNCTION f
[Bug target/63335] GCC:failures for vector double on calls to bif vec_[all|any]_[nge|nle]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Bill Schmidt wschmidt at gcc dot gnu.org --- Work is complete.
[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Target||sh*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-25 CC||olegendo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org --- Please do not close this PR yet -- backports to 4.9 and 4.8 will follow.
[Bug libstdc++/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 --- Comment #4 from Richard PALO richard at netbsd dot org --- Could you please add -fno-access-control to the dg-options flags at the top of the file and replace the VERIFY check with the following: std::cout (u._M_param._M_lambda == v._M_param._M_lambda) '\n'; std::cout (u._M_param._M_mu == v._M_param._M_mu) '\n'; std::cout (u._M_param._M_nu == v._M_param._M_nu) '\n'; std::cout (u._M_gd1 == v._M_gd1) '\n'; std::cout (u._M_gd2 == v._M_gd2) '\n'; Hi, seems I needed to add an #include iostream but anyway, the output is: 1 1 1 1 0 BTW, I did this manually as I'm not very proficient with `runtest`, isn't there a shortcut to somehow run only this test?
[Bug testsuite/63305] ASan reported heap-buffer-overflow in gcc.target/i386/avx256-unaligned-load{store}-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63305 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 33566 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33566action=edit A patch Please try this.
[Bug fortran/63371] kind() with function name (not call) as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63371 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-25 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- I get 0 with gfortran from 4.3.1 up to trunk (5.0). Compiling the test with gfortran 4.3 gives the warning pr63371.f90: In function 'f': pr63371.f90:11: warning: Function return value not set
[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 --- Comment #9 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Thu Sep 25 15:50:38 2014 New Revision: 215607 URL: https://gcc.gnu.org/viewcvs?rev=215607root=gccview=rev Log: gcc/ PR target/62218 * config/sh/sync.md (atomic_test_and_set_soft_imask): Fix typo in instruction sequence. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sync.md
[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 --- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Thu Sep 25 15:53:31 2014 New Revision: 215608 URL: https://gcc.gnu.org/viewcvs?rev=215608root=gccview=rev Log: gcc/ Backport from mainline 2014-09-25 Nick Clifton ni...@redhat.com 2014-09-25 Oleg Endo olege...@gcc.gnu.org PR target/62218 * config/sh/sync.md (atomic_fetch_nandmode_soft_imask, atomic_test_and_set_soft_imask): Fix typo in instruction sequence. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/sh/sync.md
[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 --- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Thu Sep 25 16:00:58 2014 New Revision: 215609 URL: https://gcc.gnu.org/viewcvs?rev=215609root=gccview=rev Log: gcc/ 2014-09-25 Oleg Endo olege...@gcc.gnu.org Backport from mainline 2014-09-25 Nick Clifton ni...@redhat.com 2014-09-25 Oleg Endo olege...@gcc.gnu.org PR target/62218 * config/sh/sync.md (atomic_fetch_nandmode_soft_imask, atomic_test_and_set_soft_imask): Fix typo in instruction sequence. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/sh/sync.md
[Bug libstdc++/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332
--- Comment #5 from Richard PALO richard at netbsd dot org ---
By the way, in gdb, here are the complete u and v variables after
serialisation:
gdb) p u
$1 = {_M_param = {_M_lambda = 2, _M_mu = 1.5, _M_nu = 3}, _M_gd1 = {
_M_param = {_M_alpha = 2, _M_beta = 0.5, _M_malpha = 2,
_M_a2 = 0.25819888974716108}, _M_nd = {_M_param = {_M_mean = 0,
_M_stddev = 1}, _M_saved = -1.0868180442613568,
_M_saved_available = true}}, _M_gd2 = {_M_param = {_M_alpha = 3,
_M_beta = 0.5, _M_malpha = 3, _M_a2 = 0.20412414523193152}, _M_nd = {
_M_param = {_M_mean = 0, _M_stddev = 1}, _M_saved = 0.18913187340436784,
_M_saved_available = true}}}
(gdb) p v
$2 = {_M_param = {_M_lambda = 2, _M_mu = 1.5, _M_nu = 3}, _M_gd1 = {
_M_param = {_M_alpha = 2, _M_beta = 0.5, _M_malpha = 2,
_M_a2 = 0.25819888974716108}, _M_nd = {_M_param = {_M_mean = 0,
_M_stddev = 1}, _M_saved = -1.0868180442613568,
_M_saved_available = true}}, _M_gd2 = {_M_param = {_M_alpha = 3,
_M_beta = 0.5, _M_malpha = 3, _M_a2 = 0.20412414523193152}, _M_nd = {
_M_param = {_M_mean = 0, _M_stddev = 1}, _M_saved = 0.1891318734043678,
_M_saved_available = true}}}
I notice _M_saved in v is truncated by 1 (the trailing '4')...
that is, 16 and not 17 digits after the decimal are copied.
[Bug libstdc++/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 --- Comment #6 from Richard PALO richard at netbsd dot org --- sorry, I meant to say M_gd2._M_saved
[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Oleg Endo olegendo at gcc dot gnu.org --- Fixed on trunk, 4.9 and 4.8. Thanks for reporting.
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #6 from camm at debian dot org --- Here is another transcript showing the innermost setjmp/longjmp pair corrupting the f31 register. It is a little complicated as there is an inner call to the same code which proceeds successfully.
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #37 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #36) I'm not sure about the old reload. LRA makes only 3 uses of r0 and it's relatively easy to see what is going on there with .reload comments. The old reload makes many uses of r0 and it looks not easy to see how does that work. Hm, there's still this open PR 23868 ... maybe it's somehow related or even fixed with LRA + attachment 33557 ...
[Bug libstdc++/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Aha, so that's the culprit. I really think we should be outputting in an exact format, not via conversion to/from decimal. BTW, I did this manually as I'm not very proficient with `runtest`, isn't there a shortcut to somehow run only this test? Yep, in the $target/libstdc++-v3 build dir: make check RUNTESTFLAGS=conformance.exp=ext/random/k_distribution/operators/serialize.cc You can also use shell wildcards e.g. RUNTESTFLAGS=conformance.exp=ext/*
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #7 from camm at debian dot org --- Created attachment 33567 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33567action=edit gdb transcript showing innermost setjmp/longjmp f31 clobber
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #3 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Looks good so far. I think this is a sufficient start for implementing the
library traits. Does the patch cover template cases as well? Such as
struct B {B();};
template class T struct C : T
{
};
SA(__calls_nontrivial_fn(CB()));
Anyway, I'll give it a spin.
[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-25 CC||rth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Henderson rth at gcc dot gnu.org --- Confirmed. Given the pointer to cgo/out.go above, the patch for this at https://launchpadlibrarian.net/183252940/0001-compiler-symbol-names-should-have-.-replaced-with-_.patch looks correct to me.
[Bug go/61877] [5 Regression]: reflect: cannot use []string as type string in Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-25 CC||rth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Henderson rth at gcc dot gnu.org --- Confirmed.
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #38 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #34) For reference, i386.md emits a blockage (i.e. *using* and clobbering all registers). It looks all ports including SH emit a blockage after storing the function return values to a memory block, not before the call. Hm, you're right, but to me that indicates the patch covering-up a bug elsewhere than in the sh port.
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #8 from Peter Bergner bergner at gcc dot gnu.org --- (In reply to camm from comment #6) Here is another transcript showing the innermost setjmp/longjmp pair corrupting the f31 register. I've looked at the longjmp code and it seems fine to me. Since you said offline that your code works correctly when compiled with optimization and fails without optimization, that too would clear setjmp/longjmp from being the guilty party, since both runs are using the same setjmp/longjmp glibc library code. That said, if longjmp() is indeed returning a clobbered value for f31, then it is my guess that the jmpbuf being passed to longjmp is being clobbered somewhere between the setjmp call and the longjmp call. Can you set a watch point on the jmpbuf and try and track down where it is being clobbered?
[Bug c++/63372] New: -fshort-double causes stor-layout ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63372 Bug ID: 63372 Summary: -fshort-double causes stor-layout ICE Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: andi-gcc at firstfloor dot org Created attachment 33568 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33568action=edit test case This came up while running the opentuner gccflags, which automatically searches for better performance compiler flags g++50 matrix.i -O0 -fshort-double gcc version 4.9.0 20130617 (experimental) (GCC) Test case is not reduced. built-in:0:0: internal compiler error: in layout_type, at stor-layout.c:2127 0x8c85a9 layout_type(tree_node*) ../../gcc/gcc/stor-layout.c:2126 0xa4d0c8 make_vector_type ../../gcc/gcc/tree.c:9406 0xa80660 ix86_get_builtin_type ../../gcc/gcc/config/i386/i386.c:25817 0xa80740 ix86_get_builtin_func_type ../../gcc/gcc/config/i386/i386.c:25867 0xa8e5c4 def_builtin ../../gcc/gcc/config/i386/i386.c:27143 0xa8e5c4 ix86_init_mmx_sse_builtins ../../gcc/gcc/config/i386/i386.c:28667 0xa8e5c4 ix86_init_builtins ../../gcc/gcc/config/i386/i386.c:30405 0x605c89 c_define_builtins ../../gcc/gcc/c-family/c-common.c:5161 0x605c89 c_common_nodes_and_builtins() ../../gcc/gcc/c-family/c-common.c:5609 0x50126f cxx_init_decl_processing() ../../gcc/gcc/cp/decl.c:3671 0x557cb8 cxx_init() ../../gcc/gcc/cp/lex.c:249 0x8cf7d7 lang_dependent_init ../../gcc/gcc/toplev.c:1696 0x8cf7d7 do_compile ../../gcc/gcc/toplev.c:1858 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/63373] New: ELF symbol sizes for variable-length objects are too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63373
Bug ID: 63373
Summary: ELF symbol sizes for variable-length objects are too
small
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: srk31 at srcf dot ucam.org
Created attachment 33569
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33569action=edit
Source files used in the bug description
Suppose I have an object file containing a data object of some variable-length
type.
$ cat section-size-test.c
struct blah
{
float foo;
int i[];
};
struct blah b = { 42.0, { 1, 2, 3, 4, 0 } };
$ cc -c -o section-size-test.o section-size-test.c
Now I have an object of size 24 bytes. From ELF's point of view, we have a
section of size 24 but a symbol of size only 4.
$ readelf -Ss section-size-test.o
There are 9 section headers, starting at offset 0xc8:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .text PROGBITS 0040
AX 0 0 1
[ 2] .data PROGBITS 0040
0018 WA 0 0 4
[ 3] .bss NOBITS 0058
WA 0 0 1
[ 4] .comment PROGBITS 0058
0024 0001 MS 0 0 1
[ 5] .note.GNU-stack PROGBITS 007c
0 0 1
[ 6] .shstrtab STRTAB 007c
0045 0 0 1
[ 7] .symtab SYMTAB 0308
00c0 0018 8 7 8
[ 8] .strtab STRTAB 03c8
0017 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Symbol table '.symtab' contains 8 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS section-size-test.c
2: 0 SECTION LOCAL DEFAULT1
3: 0 SECTION LOCAL DEFAULT2
4: 0 SECTION LOCAL DEFAULT3
5: 0 SECTION LOCAL DEFAULT5
6: 0 SECTION LOCAL DEFAULT4
7: 4 OBJECT GLOBAL DEFAULT2 b
The bug is that when copy relocations are used, the variable-length part of the
object will get thrown away. I think the symbol size should also be 24 (hence
filing a gcc bug not a binutils bug).
Continuing: I create a shared library out of this object file, and an
executable that depends on my object.
$ cat exe.c
struct blah
{
float foo;
int i[];
};
extern struct blah b;
int main(void)
{
return (unsigned long long) b % 32;
}
$ cc -shared -o section-size-test.so section-size-test.o
$ cc -o exe exe.c section-size-test.so
Now the executable is using a copy reloc to address my variable-length object.
$ objdump -RT exe
exe: file format elf64-x86-64
DYNAMIC SYMBOL TABLE:
w D *UND*
_ITM_deregisterTMCloneTable
DF *UND* GLIBC_2.2.5 __libc_start_main
w D *UND* __gmon_start__
w D *UND*
_Jv_RegisterClasses
w D *UND*
_ITM_registerTMCloneTable
00601038 gD .data Base_edata
00601040 gD .bss Base_end
00601038 gD .bss Base__bss_start
00400550 gDF .init Base_init
00601038 gDO .bss 0004 b
00400724 gDF .fini Base_fini
DYNAMIC RELOCATION RECORDS
OFFSET TYPE VALUE
00600ff8 R_X86_64_GLOB_DAT __gmon_start__
00601038 R_X86_64_COPY b
00601018 R_X86_64_JUMP_SLOT
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #9 from camm at debian dot org --- Created attachment 33570 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33570action=edit the setjmp buffer does not appear to be clobbered
[Bug target/60410] [4.8/4.9/5 Regression] -fshort-double ICEs x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60410 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 63372 has been marked as a duplicate of this bug. ***
[Bug c++/63372] -fshort-double causes stor-layout ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63372
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||trippels at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
dup.
It's completely broken for all supported versions:
markus@x4 ~ % echo int main () {} | g++ -fshort-double -x c++ -
built-in: internal compiler error: in layout_type, at stor-layout.c:2194
*** This bug has been marked as a duplicate of bug 60410 ***
[Bug c++/63372] -fshort-double causes stor-layout ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63372 --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org --- Actually don't even need the test case, the error happens with an empty file too.
[Bug target/60410] [4.8/4.9/5 Regression] -fshort-double ICEs x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60410 --- Comment #9 from Andi Kleen andi-gcc at firstfloor dot org --- Should we just disable the option? If it hasn't worked since 4.5 probably noone needs it.
[Bug rtl-optimization/63348] [5 Regression] gcc.dg/pr43670.c fail on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 --- Comment #6 from baoshan pangbw at gmail dot com --- (In reply to Uroš Bizjak from comment #5) (In reply to baoshan from comment #1) I believe this regression is introduced by the code for cleanup_barriers() in jump.c of patch https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02164.html: The call insn was followed by a barrier insn, the try_split() would emit another barrier insn after call insn for this case( I don't know why, please let me know the reason); after applying that patch and with option -g there would be a note instruction between the call and barrier insns which result no barrier insn is emitted by try_split(). Can you please try the patch at [1]? [1] https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02180.html It fixes the issue, Thanks for your quick action.
[Bug rtl-optimization/63348] [5 Regression] gcc.dg/pr43670.c fail on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 --- Comment #7 from uros at gcc dot gnu.org --- Author: uros Date: Thu Sep 25 17:58:35 2014 New Revision: 215613 URL: https://gcc.gnu.org/viewcvs?rev=215613root=gccview=rev Log: PR rtl-optimization/63348 * emit-rtl.c (try_split): Do not emit extra barrier. Modified: trunk/gcc/ChangeLog trunk/gcc/emit-rtl.c
[Bug rtl-optimization/63348] [5 Regression] gcc.dg/pr43670.c fail on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Uroš Bizjak ubizjak at gmail dot com --- Fixed, I hope.
[Bug c++/63364] GCC optimizer causing memory corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63364 --- Comment #4 from ncomputers.org contact at ncomputers dot org --- (In reply to Andrew Pinski from comment #3) (In reply to ncomputers.org from comment #2) Can we write your name in our website? Andrew Pinski taught us something new. I guess. Ok, here is where we mention your name: http://ncomputers.org/content/code.php?src=answers/reference%20const%20non-const.cpp If you want, that we change something, please let us know it.
[Bug rtl-optimization/63259] Detecting byteswap sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org, ||thopre01 at gcc dot gnu.org --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org --- Thomas just recently did some bswap patterns work, maybe he's got an idea.
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #10 from Peter Bergner bergner at gcc dot gnu.org --- Adding Uli to the bugzilla, since he implemented all of the ELFv2 ABI call changes. Uli, any ideas on what might be going on here? It looks to me, that ELFv1 and ELFv2 use the same exact jmpbuf layout and setjmp/longjmp code, so that looks to be correct and not buggy.
[Bug target/62233] unnecessary shift instructions to prepare loop counter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62233
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Target|powerpc64le |powerpc64le sh*-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-09-25
CC||olegendo at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
On SH, the original code above looks OK (no extra shifts generated), however,
changing it to:
void clear2 (S* s )
{
int i;
int len = s-l;
int* p = s-b;
for (i = 0; i len; i++)
p[i] = 0;
}
results in:
mov.l @r4,r1
cmp/pl r1
bf/s.L13
add #4,r4
shll2 r1
add #-4,r1
shlr2 r1
mov #0,r2
add #1,r1
.align 2
.L10:
mov.l r2,@r4
dt r1
bf/s.L10
add #4,r4
.L13:
rts
nop
This looks very similar to what is happening in PR 55190.
BTW, compiling the two functions with -O3 results in a detected memset, while
at -O2 a memset is not detected.
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #11 from camm at debian dot org --- Created attachment 33571 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33571action=edit gdb transcript showing jmp_buf is unchanged across setjmp longjmp
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #12 from camm at debian dot org --- Created attachment 33572 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33572action=edit setjmp does write to jmp_buf, but not at the end of the buffer.
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #13 from camm at debian dot org --- Created attachment 33573 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33573action=edit gdb transcript shoinwg f31 is correct on entry to setjmp
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #14 from camm at debian dot org --- Created attachment 33574 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33574action=edit continuation of gdb.7 showing no stfd fp31,((39)*8)(3) executed
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #15 from camm at debian dot org --- Created attachment 33575 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33575action=edit setjmp saves f31, then zeroes out the result with stvxv3,0,r5
[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed.
[Bug ipa/61688] [5 Regression] ICE: tree check: expected record_type or union_type or qual_union_type, have array_type in ipa_binfo_from_known_type_jfunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61688 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- Indeed, this one was fixed.
[Bug ipa/61890] [5 Regression] g++.dg/ipa/devirt-23.C FAILs with -O2 -fno-devirtualize-speculatively -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61890 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail|4.10.0 |5.0 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed now.
[Bug middle-end/45631] devirtualization with profile feedback does not work for function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- Any news on this code?
[Bug middle-end/45631] Indirect call profiling can be improved to handle multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631 davidxl xinliangli at gmail dot com changed: What|Removed |Added CC||xur at google dot com --- Comment #8 from davidxl xinliangli at gmail dot com --- (In reply to Jan Hubicka from comment #7) Any news on this code? Rong, I think it is probably good time to extract the multi-target value profiling code and upstream it. David
