[Bug c++/66211] [5/6 Regression] Rvalue conversion in ternary operator causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 CC||jakub at gcc dot gnu.org Target Milestone|--- |5.2 Summary|Rvalue conversion in|[5/6 Regression] Rvalue |ternary operator causes |conversion in ternary |internal compiler error |operator causes internal ||compiler error Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r217279.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #13 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 20 May 2015, jakub at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- hashval_t should be unsigned int? Is it some other type on your host, or is CHAR_BIT bigger than 8, or do you have 64-bit unsigned int? Yeah, it looks odd. All hosts should have uint64_t nowadays, so even before honzas patch we _always_ should have gone the mul_mod path. Can you attach pre-processed source with the revision you bisected reverted? (pre-processed source of genmatch.c, that is?) Might be that bconfig.h/system.h combo for your host makes the difference somehow.
[Bug gcov-profile/66209] Out of memory when compiling with --coverage and optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66209 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Blocks||64928 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Maybe related to PR64928 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 [Bug 64928] [4.8/4.9/5/6 Regression] Inordinate cpu time and memory usage in phase opt and generate with -ftest-coverage -fprofile-arcs
[Bug tree-optimization/65961] [6 Regression] ice in vect_is_simple_use_1 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65961 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- It might be mitigated for the testcase in question but the underlying problem didn't get fixed.
[Bug c++/66211] [5/6 Regression] Rvalue conversion in ternary operator causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I will have a look.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- hashval_t should be unsigned int? Is it some other type on your host, or is CHAR_BIT bigger than 8, or do you have 64-bit unsigned int?
[Bug tree-optimization/65961] [6 Regression] ice in vect_is_simple_use_1 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65961 --- Comment #5 from David Binderman dcb314 at hotmail dot com --- As of trunk 20150520, this bug looks fixed to me.
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-05-20
Ever confirmed|0 |1
--- Comment #14 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #13)
Looks that this doesn't work when the operand 1 is equal to the operand 2
which is the case for the above insns 92, 93 and 83. The peephole
removed with the fix in PR65153 transformed these insns prior to
the above peephole so to avoid the problem. The patch below fixes
this case. It looks there are similar peephole patterns,though.
Oleg, if you get the spare time, could you look into these peepholes?
--
diff --git a/config/sh/sh.md b/config/sh/sh.md
index 27f0074..5bc3401 100644
--- a/config/sh/sh.md
+++ b/config/sh/sh.md
@@ -14750,6 +14750,7 @@ label:
TARGET_SH1
peep2_reg_dead_p (3, operands[0])
!reg_overlap_mentioned_p (operands[0], operands[3])
+!reg_overlap_mentioned_p (operands[1], operands[2])
(REGNO (operands[0]) == REGNO (operands[4])
|| REGNO (operands[0]) == REGNO (operands[5]))
(REGNO (operands[2]) == REGNO (operands[4])
Sorry for the long chain of trouble and pain.
Adding the !reg_overlap_mentioned_p (operands[1], operands[2]) condition should
fix the problem. However, the peephole is actually meant to transform
(insn 92 14 15 3 (set (reg:SI 1 r1 [orig:171 D.2078 ] [171])
(reg:SI 2 r2 [172])) 252 {movsi_ie}
(expr_list:REG_DEAD (reg:SI 2 r2 [172])
(nil)))
(insn 93 16 83 3 (set (reg:SI 2 r2)
(const_int 66602 [0x1042a])) 252 {movsi_ie}
(nil))
(insn 83 93 18 3 (set (reg:SI 147 t)
(eq:SI (and:SI (reg:SI 1 r1 [orig:171 D.2078 ] [171])
(reg:SI 2 r2))
(const_int 0 [0]))) 1 {tstsi_t}
(expr_list:REG_DEAD (reg:SI 2 r2)
(expr_list:REG_DEAD (reg:SI 1 r1 [orig:171 D.2078 ] [171])
(nil
into
(insn 93 16 83 3 (set (reg:SI 2 r1)
(const_int 66602 [0x1042a])) 252 {movsi_ie}
(nil))
(insn 83 93 18 3 (set (reg:SI 147 t)
(eq:SI (and:SI (reg:SI 1 r1 [orig:171 D.2078 ] [171])
(reg:SI 2 r2))
(const_int 0 [0]))) 1 {tstsi_t}
(expr_list:REG_DEAD (reg:SI 2 r2)
(expr_list:REG_DEAD (reg:SI 1 r1 [orig:171 D.2078 ] [171])
(nil
I think the check operands[1] / operands[2] check should go into the
preparation statement. operands[0] is dying after this peephole, so I guess
this should work:
{
if (reg_overlap_mentioned_p (operands[1], operands[2]))
std::swap (operands[0], operands[2])
sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3]));
emit_insn (gen_tstsi_t (operands[2],
gen_rtx_REG (SImode, (REGNO (operands[1]);
}
I guess that the following peephole (sh.md line 14733) will also have a similar
problem.
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #16 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #15) Thanks for a quick look! However, I think that the emit_move_insn could also be a source of hidden problems. For instance, if the captured insn Also arguments of emit_move_insn must have the same integer modes. if (reg_overlap_mentioned_p (operands[1], operands[2])) std::swap (operands[0], operands[2]); sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3])); might ICE if operands[0] and operands[2] have different modes and swap happens, though I'm not sure whether such insns are real or not.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #15 from Douglas Mencken dougmencken at gmail dot com ---
I'm going to surround calls to gcc_[checking_]assert (in gcc/hash-table.*) with
#ifdef ENABLE_CHECKING {--disable-checking is in my config already}. Let's see
where it lands.
[Bug tree-optimization/65752] Too strong optimizations int - pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #26 from Chung-Kil Hur gil.hur at sf dot snu.ac.kr --- Thanks for the detailed explanations. The C standard only guarantees that you can convert a pointer to uintptr_t and back, it doesn't guarantee that you can convert a modified uintptr_t back to a pointer that is valid. Thus, doing (int *)((xp + i) - j) is invoking undefined behavior. I didn't know about this rule. I thought this cast is valid because (xp+i)-j is even safely-derived. Could you give a reference for that rule in the standard? Thanks!
[Bug libgcc/66212] Exception handling broken on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66212 --- Comment #1 from Andri Yngvason andri.yngvason at marel dot com --- I've now compiled the same toolchain for i686 and I have the same issue there, so I assume that I'm doing something wrong. It's hard to pin down what I'm doing wrong though. Everything seems to be linked correctly: # ldd stdexcept linux-gate.so.1 (0xb77ad000) libstdc++.so.6 = /lib/libstdc++.so.6 (0xb7633000) libm.so.6 = /lib/libm.so.6 (0xb75ea000) libgcc_s.so.1 = /lib/glibc2.21/libgcc_s.so.1 (0xb75ce000) libc.so.6 = /lib/libc.so.6 (0xb742) /lib/ld-linux.so.2 (0xb77ae000) # ls -l /lib/libstdc++.so.6 /lib/libm.so.6 /lib/libc.so.6 /lib/glibc2.21/libgcc_s.so.1 /lib/ld-linux.so.2 -rw-r--r--1 root root397872 May 20 10:11 /lib/glibc2.21/libgcc_s.so.1 lrwxrwxrwx1 root root10 May 20 10:57 /lib/ld-linux.so.2 - ld-2.21.so lrwxrwxrwx1 root root12 May 20 10:57 /lib/libc.so.6 - libc-2.21.so lrwxrwxrwx1 root root12 May 20 10:57 /lib/libm.so.6 - libm-2.21.so lrwxrwxrwx1 root root19 May 20 10:57 /lib/libstdc++.so.6 - libstdc++.so.6.0.21 I'll try 4.9...
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #17 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 20 May 2015, dougmencken at gmail dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #14 from Douglas Mencken dougmencken at gmail dot com --- sizeof(hashval_t) = 4, CHAR_BIT = 8 Just checked it manually. Built with patch subset, genmatch problem is here again. It isn't related to changes in hash_table_mod1 hash_table_mod2. What's left? abort() replaced by gcc_checking_assert()? Well, it shouldn't segfault in this case either (well - maybe we replace gcc_checking_assert () with gcc_unreachable () with --disable-checking). Indeed we do. That would explain seeing a segfault instead of an assertion failure (so yes, try without --disable-checking)
[Bug target/66215] New: [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
Bug ID: 66215
Summary: [4.8/4.9/5/6 Regression] Wrong after label NOP
emission for -mhotpatch
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Target: 390-linux
Hi.
Starting from r221381 GCC does not place nops right after function label.
Unfortunately, the problematic patch was also backported to gcc4-[89] and
gcc-5.
$ cat /tmp/s390.c
static int foo()
{
return 0;
}
int main(int argc, char **argv)
{
return foo();
}
$ ./xgcc -B. /tmp/s390.c -mhotpatch=2,3 -o o0.s -S -fno-inline
$ cat o0.s | head ..
.text
.align 8
.type foo, @function
nopr%r7 # pre-label NOPs for hotpatch (2 halfwords)
nopr%r7
# alignment for hotpatch
.align 8
foo:
# post-label NOPs for hotpatch (3 halfwords)
.LFB0:
stm %r11,%r14,44(%r15)
.LCFI0:
lr %r11,%r15
.LCFI1:
nop 0
nopr%r7
lhi %r1,0
lr %r2,%r1
l %r4,56(%r11)
lm %r11,%r14,44(%r11)
.LCFI2:
br %r4
Problem is that patched compiler relies that NOTE_INSN_FUNCTION_BEG is at the
beginning of function.
/* Inject nops for hotpatching. */
+ for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
+ {
+ if (NOTE_P (insn) NOTE_KIND (insn) == NOTE_INSN_FUNCTION_BEG)
+ break;
+ }
Problem is that if you use -O2, 256r.sched2 reorders insns after
pro_and_epilogue, where NOTE_INSN_FUNCTION_BEG is placed at the beginning.
On the other hand, if you try -O0, -O1, as the pass is not executed, emission
of NOTE_INSN_FUNCTION_BEG is not reordered.
$ cat s390.c.242r.pro_and_epilogue
foo
(note 1 0 5 NOTE_INSN_DELETED)
(note 5 1 18 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn/f 18 5 19 2 (set (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 56 [0x38])) [1 S4 A8])
(reg:SI 14 %r14)) /tmp/s390.c:7 -1
(nil))
(insn 19 18 20 2 (set (reg:SI 5 %r5)
(unspec_volatile [
(const_int 0 [0])
] UNSPECV_MAIN_POOL)) /tmp/s390.c:7 -1
(nil))
(note 20 19 17 2 NOTE_INSN_PROLOGUE_END)
(insn 17 20 4 2 (set (reg:SI 5 %r5)
(unspec_volatile [
(const_int 0 [0])
] UNSPECV_MAIN_POOL)) 675 {main_pool}
(nil))
(note 4 17 8 2 NOTE_INSN_FUNCTION_BEG)
(insn 8 4 24 2 (set (reg:SI 1 %r1)
(mem/u/c:SI (unspec:SI [
(symbol_ref/u:SI (*.LC0) [flags 0x2])
(reg:SI 5 %r5)
] UNSPEC_LTREF) [2 S4 A32])) /tmp/s390.c:8 68 {*movsi_esa}
(expr_list:REG_EQUAL (symbol_ref:SI (foo) [flags 0x3] function_decl
0x7fc55997e3e0 foo)
(nil)))
(note 24 8 23 2 NOTE_INSN_EPILOGUE_BEG)
(insn/f 23 24 9 2 (set (reg:SI 14 %r14)
(mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 56 [0x38])) [1 S4 A8])) /tmp/s390.c:9 -1
(expr_list:REG_CFA_DEF_CFA (plus:SI (reg/f:SI 15 %r15)
(const_int 96 [0x60]))
(expr_list:REG_CFA_RESTORE (reg:SI 14 %r14)
(nil
(call_insn/u/j 9 23 10 2 (set (reg:SI 2 %r2)
(call (mem:QI (reg:SI 1 %r1) [0 foo S1 A8])
(const_int 0 [0]))) /tmp/s390.c:8 631 {*sibcall_value_br}
(expr_list:REG_CALL_DECL (symbol_ref:SI (foo) [flags 0x3]
function_decl 0x7fc55997e3e0 foo)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(nil))
(barrier 10 9 16)
(note 16 10 0 NOTE_INSN_DELETED)
$ cat s390.c.256r.sched2
(note 1 0 3 NOTE_INSN_DELETED)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 15 2 NOTE_INSN_FUNCTION_BEG)
(insn/f 15 2 16 2 (set (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 56 [0x38])) [1 S4 A8])
(reg:SI 14 %r14)) /tmp/s390.c:2 68 {*movsi_esa}
(expr_list:REG_DEAD (reg:SI 14 %r14)
(nil)))
(insn 16 15 17 2 (set (reg:SI 5 %r5)
(unspec_volatile [
(const_int 0 [0])
] UNSPECV_MAIN_POOL)) /tmp/s390.c:2 675 {main_pool}
(expr_list:REG_UNUSED (reg:SI 5 %r5)
(nil)))
(note 17 16 14 2 NOTE_INSN_PROLOGUE_END)
(insn 14 17 25 2 (set (reg:SI 5 %r5)
(unspec_volatile [
(const_int 0 [0])
] UNSPECV_MAIN_POOL)) 675 {main_pool}
(expr_list:REG_UNUSED (reg:SI 5 %r5)
(nil)))
(note 25 14 21 2 NOTE_INSN_EPILOGUE_BEG)
(insn 21 25 9 2 (set (reg:SI 4 %r4)
(mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 56 [0x38])) [1 S4 A8])) /tmp/s390.c:4 68
{*movsi_esa}
(nil))
(insn 9 21 22 2 (set (reg/i:SI 2 %r2)
(const_int 0 [0])) /tmp/s390.c:4 68 {*movsi_esa}
(nil))
(insn/f 22 9 10 2 (set (reg:SI 14 %r14)
(mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 56
[Bug c/66213] New: unsigned char value range can be greater than sizeof unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66213
Bug ID: 66213
Summary: unsigned char value range can be greater than sizeof
unsigned char
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: z.hege...@t-systems.com
Target Milestone: ---
Unsigned char can be greater than 1 byte (== sizeof(unsigned char))
Example:
#include stdio.h
int main() {
unsigned char a=200, b=80;
int z = a+b;
printf(z=: %d\n, z);
return 0;
}
When data type char or signed char is used in the example above a char overflow
occurs (as expected) but if unsigned char is used the return value can be
greater than 1 byte (or sizeof(unsigned char))
Reason:
Breakpoint 8, 0x004011f6 in main () at char.c:8
(gdb) i r
eax0x50 80
edx0xc8 200
Breakpoint 10, 0x00401215 in main () at char.c:10
0x0040121a 10 z = c+d;
(gdb) ni
(gdb) i r
eax0x50 80
edx0xffc8 -56
Where c and d are signed chars.
When unsigned char is used gcc uses movzx instead of movsx and probably the
sign bit is overwritten.
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Known to work||5.1.0 Target Milestone|--- |6.0 Known to fail||6.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #0) The bug reminds me of bug 66103, but is one is without LTO.
[Bug tree-optimization/65752] Too strong optimizations int - pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #27 from Chung-Kil Hur gil.hur at sf dot snu.ac.kr --- (In reply to Chung-Kil Hur from comment #26) Thanks for the detailed explanations. The C standard only guarantees that you can convert a pointer to uintptr_t and back, it doesn't guarantee that you can convert a modified uintptr_t back to a pointer that is valid. Thus, doing (int *)((xp + i) - j) is invoking undefined behavior. I didn't know about this rule. I thought this cast is valid because (xp+i)-j is even safely-derived. Could you give a reference for that rule in the standard? Thanks! It seems that the following rule might be the one. = 7.20.1.4 Integer types capable of holding object pointers The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer: intptr_t The following type designates an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer: uintptr_t These types are optional. = Right. This does not say that we are allowed to cast a modified integer back to a pointer. What I remember might be from the C++ standard, where safely derived integers are allowed to be cast back to pointers. Umm. This might also be implementation-defined. Anyway, thanks very much for taking your time to respond to my questions!! Best, Gil
[Bug libstdc++/60936] [4.9/5/6 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- Created attachment 35575 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35575action=edit Lightweight __throw_out_of_range_fmt for non-verbose builds This is what I had in mind.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #14 from Douglas Mencken dougmencken at gmail dot com --- sizeof(hashval_t) = 4, CHAR_BIT = 8 Just checked it manually. Built with patch subset, genmatch problem is here again. It isn't related to changes in hash_table_mod1 hash_table_mod2. What's left? abort() replaced by gcc_checking_assert()?
[Bug libgcc/66212] New: Exception handling broken on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66212
Bug ID: 66212
Summary: Exception handling broken on powerpc
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: andri.yngvason at marel dot com
Target Milestone: ---
All exceptions cause the running process to be aborted.
The following program is aborted when trying to unwind the stack:
#include exception
#include stdexcept
#include iostream
using std::cout;
using std::endl;
void foobar()
{
cout ... endl;
throw std::runtime_error(Whoohoo);
cout Wtf? endl;
}
int main(int, char**)
{
cout Throwing standard exception... endl;
try {
foobar();
} catch(std::exception e) {
cout Caught: e.what() endl;
}
cout Done! endl;
return 0;
}
Backtrace:
#0 0x0fbff76c in raise () from /lib/libc.so.6
#1 0x0fc010cc in abort () from /lib/libc.so.6
#2 0x0fd5fc1c in uw_init_context_1 () from /lib/glibc2.21/libgcc_s.so.1
#3 0x0fd60408 in _Unwind_RaiseException () from /lib/glibc2.21/libgcc_s.so.1
#4 0x0fed10ac in __cxa_throw () at
../../../../gcc-5.1.0/libstdc++-v3/libsupc++/eh_throw.cc:82
#5 0x1c28 in foobar() ()
#6 0x1cac in main ()
$ powerpc-marel-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=powerpc-marel-linux-gnu-g++
COLLECT_LTO_WRAPPER=/opt/plutotoolchain/libexec/gcc/powerpc-marel-linux-gnu/5.1.0/lto-wrapper
Target: powerpc-marel-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/opt/plutotoolchain
--target=powerpc-marel-linux-gnu --enable-languages=c,c++
--enable-threads=posix --enable-shared --disable-multilib --enable-__cxa_atexit
--disable-sjlj-exceptions --disable-nls --enable-symvers=gnu --enable-c99
--enable-long-long --enable-profile --with-tune=e300c3 --disable-altivec
Thread model: posix
gcc version 5.1.0 (GCC)
I tried to compile libgcc with debug symbols so that I could see which
assertion fails, but my attempts had no effect. I'd be happy to learn how to
get those debug symbols in there.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #16 from Andreas Schwab sch...@linux-m68k.org --- After, = 32 triggers assert (-- failure). This is backwards. The failure case is sizeof (hashval_t) * CHAR_BIT 32.
[Bug c/66213] unsigned char value range can be greater than sizeof unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66213 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I don't know where you think is a bug. The usual arithmetic conversion are performed on that addition so it is done on ints.
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #17 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Thanks a lot guys for working on this! I'm really glad you're doing this :).
[Bug middle-end/66214] New: [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 Bug ID: 66214 Summary: [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250 Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Target Milestone: --- Created attachment 35574 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35574action=edit Test case (input13.ii): Compile with g++ -std=c++11 -g The bug reminds me of 66103, but is one is without LTO. Compiling the attached code snipped with g++ -std=c++11 -g give the following ICE. Without -g, it doesn't crash: input13.ii:53:34: required from here input13.ii:44:74: error: TYPE_CANONICAL is not compatible template typename _Tp, typename _Alloc = std::allocator _Tp class vector:protected _Vector_base _Tp, [...] input13.ii:44:74: internal compiler error: verify_type failed 0xf3e280 verify_type(tree_node const*) ../../gcc/tree.c:13257 0x96dc04 gen_type_die_with_usage ../../gcc/dwarf2out.c:20250 0x96e2a3 gen_type_die_with_usage ../../gcc/dwarf2out.c:20337 0x97f21c gen_type_die ../../gcc/dwarf2out.c:20434 0x97f21c gen_formal_types_die ../../gcc/dwarf2out.c:18027
[Bug c/66213] unsigned char value range can be greater than sizeof unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66213 --- Comment #2 from zh__ z.hege...@t-systems.com --- Yep, sorry. My bad.
[Bug tree-optimization/65752] Too strong optimizations int - pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #28 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 20 May 2015, gil.hur at sf dot snu.ac.kr wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #27 from Chung-Kil Hur gil.hur at sf dot snu.ac.kr --- (In reply to Chung-Kil Hur from comment #26) Thanks for the detailed explanations. The C standard only guarantees that you can convert a pointer to uintptr_t and back, it doesn't guarantee that you can convert a modified uintptr_t back to a pointer that is valid. Thus, doing (int *)((xp + i) - j) is invoking undefined behavior. I didn't know about this rule. I thought this cast is valid because (xp+i)-j is even safely-derived. Could you give a reference for that rule in the standard? Thanks! It seems that the following rule might be the one. = 7.20.1.4 Integer types capable of holding object pointers The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer: intptr_t The following type designates an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer: uintptr_t These types are optional. = Yes, that's the one I remember. Right. This does not say that we are allowed to cast a modified integer back to a pointer. What I remember might be from the C++ standard, where safely derived integers are allowed to be cast back to pointers. Umm. This might also be implementation-defined. Yeah, what is safely derived is the question here (you might not break the dependency chain in any (non-)obvious way).
[Bug libstdc++/38265] STL treats explicit constructors as converting constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Geoff Romer from comment #14) But see [sequence.reqmts]/p3: i and j denote iterators satisfying input iterator requirements and refer to elements implicitly convertible to value_type. So this is not intended to work per se; a conforming library could disallow it. However, the notes on LWG 536 say Some support, not universal, for respecting the explicit qualifier, so it looks like the standard intentionally permits this as a conforming extension. Which makes the original testcase invalid, so it's a bug in the user's code, not a bug in libstdc++ to accept it. In principle, I think perfect initialization is what's called for here: the range ctor should be explicit if and only if it uses an explicit constructor for value_type. I don't think that would be a good idea. I don't think it follows that X(int) being explicit should mean dequeX(int*, int*) should be explicit. By that logic shared_ptr(unique_ptrT) should be explicit, because unique_ptr(T*) is explicit. int* is not int, and dequeX is not X.
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #15 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #14)
I think the check operands[1] / operands[2] check should go into the
preparation statement. operands[0] is dying after this peephole, so I guess
this should work:
I have confirmed that the following fixes the test case in attachment 35572:
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 223416)
+++ gcc/config/sh/sh.md (working copy)
@@ -14721,6 +14721,9 @@
|| REGNO (operands[2]) == REGNO (operands[5]))
[(const_int 0)]
{
+ if (reg_overlap_mentioned_p (operands[1], operands[2]))
+std::swap (operands[0], operands[2]);
+
sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3]));
emit_insn (gen_tstsi_t (operands[2],
gen_rtx_REG (SImode, (REGNO (operands[1]);
However, I think that the emit_move_insn could also be a source of hidden
problems. For instance, if the captured insn
(set (match_operand:SI 2 arith_reg_dest)
(match_operand:SI 3))
is not a move insn, but some computation like (set (reg) (plus:SI ... )). I'm
not sure what emit_move_insn is going to do in this case. Maybe a better way
would be to copy/re-emit the captured original insn in a different way.
[Bug libstdc++/60936] [4.9/5/6 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 Markus Eisenmann meisenmann@fh-salzburg.ac.at changed: What|Removed |Added CC||meisenmann.lba@fh-salzburg. ||ac.at --- Comment #12 from Markus Eisenmann meisenmann@fh-salzburg.ac.at --- Created attachment 35573 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35573action=edit Using __throw_out_of_range (instead of __throw_out_of_range_fmt), if configured with --disable-libstdcxx-verbose My patch (file gcc-4.9-pr60936.patch) is a fix/work-around as suggested by Jonathan in Comment 4. Calling __throw_out_of_range_fmt is replaced by the (simpler) function __throw_out_of_range(), if the gcc-build is configured with the option --disable-libstdcxx-verbose. Note: I have used the previous call to __throw_out_of_range as used in GCC-release 4.8.4. Maybe the patch has to be applied with the option -p1 (or change the patch-file), because the path begins with 'gcc-4.9.2/' ... Following source-files will be changed (by this patch): [gcc-4.9.2/] libstdc++-v3/include/bits/basic_string.h [gcc-4.9.2/] libstdc++-v3/include/bits/functexcept.h [gcc-4.9.2/] libstdc++-v3/include/bits/stl_bvector.h [gcc-4.9.2/] libstdc++-v3/include/bits/stl_deque.h [gcc-4.9.2/] libstdc++-v3/include/bits/stl_vector.h [gcc-4.9.2/] libstdc++-v3/include/debug/array [gcc-4.9.2/] libstdc++-v3/include/experimental/string_view [gcc-4.9.2/] libstdc++-v3/include/ext/vstring.h [gcc-4.9.2/] libstdc++-v3/include/profile/array [gcc-4.9.2/] libstdc++-v3/include/std/array [gcc-4.9.2/] libstdc++-v3/include/std/bitset [gcc-4.9.2/] libstdc++-v3/src/c++11/functexcept.cc [gcc-4.9.2/] libstdc++-v3/testsuite/util/exception/safety.h Best regards, Markus
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #10 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Perhaps it's better to make one factor larger. Maybe the following will help. $ cat zz1.f90 program p real :: z(2) z = 10 + [real :: 1, 2] print *, z end # you may check your patch $ cat zz2.f90 program p real :: z(2) z = 10. + [real :: 1, 2] print *, z end # you may check your patch --- $ cat zz3.f90 program p real :: z(2) z = [real :: 1, 2] + 10 print *, z end $ gfortran zz3.f90 $ a.out 1. 2. # expected: 11. 12. $ cat zz4.f90 program p real :: z(2) z = [real :: 1, 2] + 10. print *, z end $ gfortran zz4.f90 $ a.out 1. 2. # expected: 11. 12. --- Or to use an other basic operation : $ cat zz5.f90 program p real :: z(2) z = -10 * [real :: 1, 2] print *, z end # you may check your patch $ cat zz6.f90 program p real :: z(2) z = -10. * [real :: 1, 2] print *, z end # you may check your patch
[Bug tree-optimization/65752] Too strong optimizations int - pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #25 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Chung-Kil Hur from comment #24)
(In reply to schwab from comment #23)
gil.hur at sf dot snu.ac.kr gcc-bugzi...@gcc.gnu.org writes:
Since hello is not printed, I think the if-statement is the same as
no-op.
Thus, removing the if-statement should not change the behavior of the
program
according to ISO C11.
Unless you are invoking undefined behaviour.
Andreas.
==
#include stdio.h
int main() {
int x = 0;
uintptr_t xp = (uintptr_t) x;
uintptr_t i, j;
for (i = 0; i xp; i++) { }
j = i;
*(int*)((xp+i)-j) = 15;
printf(%d\n, x);
}
=
This prints 15.
And I do not think there is any UB.
Please correct me if I am wrong.
Then, I add the if-statement.
==
#include stdio.h
int main() {
int x = 0;
uintptr_t xp = (uintptr_t) x;
uintptr_t i, j;
for (i = 0; i xp; i++) { }
j = i;
/** begin ***/
if (j != xp) {
printf(hello\n);
j = xp;
}
/** end */
*(int*)((xp+i)-j) = 15;
printf(%d\n, x);
}
=
This prints 0 without printing hello.
Thus, this raises no UB unless j != xp raises UB.
If you think j != xp raises UB, please explain why and give some reference.
Otherwise, I think it is a bug of GCC.
The C standard only guarantees that you can convert a pointer to uintptr_t and
back, it doesn't guarantee that you can convert a modified uintptr_t back to
a pointer that is valid.
Thus, doing (int *)((xp + i) - j) is invoking undefined behavior.
That you see an effect of this undefined behavior just with the added if
is because that if confuses early GCC optimizations which would have
cancelled i - j to zero, retaining (int *)xp. Instead it enables later
optimization to see that xp - j cancels and thus it is left with (int *)i.
This is because you are essentially computing (xp + xp) - xp == xp but
dependent on what two pieces get cancelled the pointer is based on
either xp (ok) or on i (not ok - that is related to xp only via an
implicit equivalency).
The net result is that I can't see how to detect this kind of situation
in points-to analysis in a way that does not pessimize all pointer-to-integer /
integer-to-pointer conversions. In theory it would be possible to add a
flag similar to -fno-strict-aliasing to do this pessimization (but there
is already -fno-tree-pta which avoids the issue as well).
So in the end my conclusion is that either the testcase invokes undefined
behavior or the C standard has a defect. Thus the bug is WONTFIX unless
somebody can come up with a way to handle these kind of equivalences
in the points-to algorithm in GCC in a way not pessimizing everything.
One might consider an incomplete approach like that in comment #6 but
I am not convinced about this hack (and one would need to evaluate its
effects on code generation).
[Bug target/62231] [4.8/4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231 --- Comment #16 from Andri Yngvason andri.yngvason at marel dot com --- Sorry, Joseph, I wasn't sure if this issue was fixed or not since the status is NEW. I'll report a new issue.
[Bug c++/66211] [5/6 Regression] Rvalue conversion in ternary operator causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- So we fold (and did fold before) 1 0 ? x : y to (float) x (thus an rvalue). Then later we call ocp_convert on that requesting a conversion to int which does 810 converted = fold_if_not_in_template (convert_to_integer (type, e)); where convert_to_integer ends up just doing 910 return build1 (FIX_TRUNC_EXPR, type, expr); and fold then applying the simplification /* If we are converting an integer to a floating-point that can represent it exactly and back to an integer, we can skip the floating-point conversion. */ (if (inside_int inter_float final_int (unsigned) significand_size (TYPE_MODE (inter_type)) = inside_prec - !inside_unsignedp) (convert @0)) and (for cvt (convert view_convert float fix_trunc) (simplify (cvt @0) (if ((GIMPLE useless_type_conversion_p (type, TREE_TYPE (@0))) || (GENERIC type == TREE_TYPE (@0))) @0))) where wrapping the result as (non_lvalue @0) fixes the regression. The bug is of course the C++ frontend folding stuff too early (and too aggressive) here. But for GCC 5 the above might be a good-enough workaround (eventually we can conditionalize building non_lvalue exprs to non-C-frontends).
[Bug c++/52742] Initializing an array using brace initializer and template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52742 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.1 Known to fail||4.7.4, 4.8.0 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- This is fixed in 4.8.1
[Bug c++/66218] New: [c++-concepts] inconsistent deduction for ‘auto’ with a partial-concept-id in a deduction constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66218
Bug ID: 66218
Summary: [c++-concepts] inconsistent deduction for ‘auto’
with a partial-concept-id in a deduction constraint
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 35576
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35576action=edit
testcase.cpp
Compiling this correct program with r223444 of the c++-concepts branch:
#include type_traits
template class T, class U
concept bool Same =
std::is_sameT, U::value;
template class T
concept bool C =
requires(T t) {
{ t } - SameT;
};
template class
constexpr bool f() { return false; }
template C
constexpr bool f() { return true; }
static_assert(fchar(), );
static_assert(fint(), );
static_assert(fdouble(), );
int main() {}
produces errors:
bug2.cpp:19:22: error: inconsistent deduction for ‘auto’: ‘char’ and then ‘int’
static_assert(fint(), );
^
bug2.cpp:19:1: error: static assertion failed:
static_assert(fint(), );
^
bug2.cpp:20:25: error: inconsistent deduction for ‘auto’: ‘char’ and then
‘double’
static_assert(fdouble(), );
^
bug2.cpp:20:1: error: static assertion failed:
static_assert(fdouble(), );
^
It appears that the result of the first deduction is stored in memory instead
of being discarded.
[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||chrbr at gcc dot gnu.org --- Comment #3 from chrbr at gcc dot gnu.org --- patch set posted : (2.1/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01185.html (2.2/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01198.html (4/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01537.html (5.1/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01539.html (5.2/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01558.html (6 /6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01542.html
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug sanitizer/62216] UBSan can read past valid memory region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62216 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- https://llvm.org/bugs/show_bug.cgi?id=20721 is fixed now, closing this one as well.
[Bug c/66220] New: -Wmisleading-indentation false/inconsistent warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220
Bug ID: 66220
Summary: -Wmisleading-indentation false/inconsistent warning
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 35578
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35578action=edit
Testcase to reproduce
The following indenting style generates a false warning:
int test1(int v)
{
int res = 28;
if (v == 2)
{
res = 27;
} else
{
res = 18;
}
return res;
}
test-indent.c: In function 'test1':
test-indent.c:13:5: warning: statement is indented as if it were guarded by...
[-Wmisleading-indentation]
return res;
^
test-indent.c:9:7: note: ...this 'else' clause, but it is not
} else
^
Even though I don't like this style, I don't think it's misleading.
If you change the 'else' to 'else if ()' the warning goes away, that's why
think it's at least inconsistent.
[Bug c++/66211] [5/6 Regression] Rvalue conversion in ternary operator causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jason at redhat dot com Version|unknown |5.1.0 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Unfortunately this causes FAIL: gcc.dg/tree-ssa/foldcast-1.c scan-tree-dump-times original return x; 2 FAIL: gcc.dg/tree-ssa/pr31261.c scan-tree-dump-times original return b 7; 1 FAIL: gfortran.dg/assumed_type_2.f90 -O0 scan-tree-dump-times original sub_ scalar .(struct t1 .) array_class_t1_ptr._data.dat 1 FAIL: gfortran.dg/assumed_type_2.f90 -O1 scan-tree-dump-times original sub_ scalar .(struct t1 .) array_class_t1_ptr._data.dat 1 FAIL: gfortran.dg/assumed_type_2.f90 -O2 scan-tree-dump-times original sub_ scalar .(struct t1 .) array_class_t1_ptr._data.dat 1 FAIL: gfortran.dg/assumed_type_2.f90 -O3 -fomit-frame-pointer scan-tree-dump -times original sub_scalar .(struct t1 .) array_class_t1_ptr._data.dat 1 FAIL: gfortran.dg/assumed_type_2.f90 -O3 -fomit-frame-pointer -funroll-all-loo ps -finline-functions scan-tree-dump-times original sub_scalar .(struct t 1 .) array_class_t1_ptr._data.dat 1 FAIL: gfortran.dg/assumed_type_2.f90 -O3 -fomit-frame-pointer -funroll-loops scan-tree-dump-times original sub_scalar .(struct t1 .) array_class_t1 _ptr._data.dat 1 FAIL: gfortran.dg/assumed_type_2.f90 -O3 -g scan-tree-dump-times original s ub_scalar .(struct t1 .) array_class_t1_ptr._data.dat 1 FAIL: gfortran.dg/assumed_type_2.f90 -Os scan-tree-dump-times original sub_ scalar .(struct t1 .) array_class_t1_ptr._data.dat 1 FAIL: gfortran.dg/c_f_pointer_tests_3.f90 -O scan-tree-dump-times original fptr_array.data = cptr; 1 FAIL: gfortran.dg/c_loc_test_22.f90 -O scan-tree-dump-times original D.[0-9 ]+ = parm.[0-9]+.data;[^;]+ptr[1-4] = D.[0-9]+; 4 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O0 scan-tree-dump-times original fgsl _file.[0-9]+.gsl_file = c_ptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O0 scan-tree-dump-times original fgsl _file.[0-9]+.gsl_func = c_funptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O1 scan-tree-dump-times original fgsl _file.[0-9]+.gsl_file = c_ptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O1 scan-tree-dump-times original fgsl _file.[0-9]+.gsl_func = c_funptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O2 scan-tree-dump-times original fgsl _file.[0-9]+.gsl_file = c_ptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O2 scan-tree-dump-times original fgsl _file.[0-9]+.gsl_func = c_funptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -fomit-frame-pointer scan-tree-dump -times original fgsl_file.[0-9]+.gsl_file = c_ptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -fomit-frame-pointer scan-tree-dump -times original fgsl_file.[0-9]+.gsl_func = c_funptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -fomit-frame-pointer -funroll-all-loo ps -finline-functions scan-tree-dump-times original fgsl_file.[0-9]+.gsl_file = c_ptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -fomit-frame-pointer -funroll-all-loo ps -finline-functions scan-tree-dump-times original fgsl_file.[0-9]+.gsl_func = c_funptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -fomit-frame-pointer -funroll-loops scan-tree-dump-times original fgsl_file.[0-9]+.gsl_file = c_ptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -fomit-frame-pointer -funroll-loops scan-tree-dump-times original fgsl_file.[0-9]+.gsl_func = c_funptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -g scan-tree-dump-times original f gsl_file.[0-9]+.gsl_file = c_ptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -O3 -g scan-tree-dump-times original f gsl_file.[0-9]+.gsl_func = c_funptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -Os scan-tree-dump-times original fgsl _file.[0-9]+.gsl_file = c_ptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_14.f90 -Os scan-tree-dump-times original fgsl _file.[0-9]+.gsl_func = c_funptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_15.f90 -O scan-tree-dump-times original fgsl_ file.[0-9]+.gsl_file = c_ptr.[0-9]+; 1 FAIL: gfortran.dg/c_ptr_tests_15.f90 -O scan-tree-dump-times original fgsl_ file.[0-9]+.gsl_func = c_funptr.[0-9]+; 1 FAIL: gfortran.dg/coarray_31.f90 -O scan-tree-dump original a.y.d._data.dat a = D.[0-9]+.y.d._data.data; FAIL: gfortran.dg/coarray_31.f90 -O scan-tree-dump original a.y.x.data = D. [0-9]+.y.x.data; FAIL: gfortran.dg/coarray_31.f90 -O scan-tree-dump original a.y.z._data.dat a = D.[0-9]+.y.z._data.data; FAIL: gfortran.dg/no_arg_check_2.f90 -O0 scan-tree-dump-times original sub_ scalar .(struct t1 .) array_class_t1_ptr._data.dat 1 FAIL:
[Bug c/66220] -Wmisleading-indentation false/inconsistent warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 CC||dmalcolm at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #1 from Martin Liška marxin at gcc dot gnu.org ---
Following testcase is wrongly compiled event with -O2 optimization level.
$ cat o2-test-case.c
static int a;
int t(int tt)
{
switch (tt)
{
case 1: return a;
}
return 0;
}
$ ./xgcc -B. -mhotpatch=2,3 -O2 -fno-inline -o /tmp/test.s -S o2-test-case.c
$ head -n20 /tmp/test.s
.file o2-test-case.c
.text
.align 8
.globl t
.type t, @function
nopr%r7 # pre-label NOPs for hotpatch (2 halfwords)
nopr%r7
# alignment for hotpatch
.align 8
t:
marxin@marxinbox:~/Programming/gcc2/objdir/gcc head -n20 /tmp/test.s
.file o2-test-case.c
.text
.align 8
.globl t
.type t, @function
nopr%r7 # pre-label NOPs for hotpatch (2 halfwords)
nopr%r7
# alignment for hotpatch
.align 8
t:
# post-label NOPs for hotpatch (3 halfwords)
.LFB0:
st %r14,56(%r15)
nop 0
nopr%r7
.LCFI0:
l %r4,56(%r15)
lhi %r2,0
l %r14,56(%r15)
.LCFI1:
[Bug ada/66217] New: PowerPC rotate/shift/mask instructions not optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66217 Bug ID: 66217 Summary: PowerPC rotate/shift/mask instructions not optimal Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: segher at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- Target: powerpc*-*-* GCC does not generate optimal instruction sequences for rotate/shift/mask sequences; it pretty often makes quite bad code, even, esp. when it involves 64-bit instructions. One part of the problem is that the masks we allow are less general than what the hardware allows. Not a huge problem for the rlwinm instructions, but we shouldn't need mask_operand_wrap there either. Another big part of the problem is our rtx_cost function does not handle rotate-and-mask correctly; it recurses to get the cost of the mask, but then it looks at the mode of it, which is VOIDmode (it is a const_int), and things go south. It would be nice to not need that rtx_cost at all, certainly not for combine (which has access to full insns always), but that is a bigger project. Another problem is with the insert insns. They are not as general as they should be, as before. Also, we should be able to handle things like (a 16) | (b 16), which is an insert insn followed by a normal rotate (or the other way around). This should also make the bswap patterns a little bit simpler.
[Bug c++/66216] [6 Regression] Defaulted Operators and constructors not working with aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66216 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code, ||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 Summary|Defaulted Operators and |[6 Regression] Defaulted |contructors not working |Operators and constructors |with aligned attribute |not working with aligned ||attribute Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- And now it gives an ICE on trunk, so it's regressed from rejects-valid to ice-on-valid-code: a.cc:1:7: internal compiler error: canonical types differ for identical types const CMymy and const CMymy class CMymy ^ 0x103f comptypes(tree_node*, tree_node*, int) /home/jwakely/src/gcc/gcc/cp/typeck.c:1423 0x1033108b structural_comptypes /home/jwakely/src/gcc/gcc/cp/typeck.c:1357 0x103332e7 comptypes(tree_node*, tree_node*, int) /home/jwakely/src/gcc/gcc/cp/typeck.c:1415 0x1033675f compparms(tree_node const*, tree_node const*) /home/jwakely/src/gcc/gcc/cp/typeck.c:1534 0x10379fc7 defaulted_late_check(tree_node*) /home/jwakely/src/gcc/gcc/cp/method.c:1972 0x1029a5ff check_bases_and_members /home/jwakely/src/gcc/gcc/cp/class.c:5808 0x1029c4f3 finish_struct_1(tree_node*) /home/jwakely/src/gcc/gcc/cp/class.c:6582 0x1029ef53 finish_struct(tree_node*, tree_node*) /home/jwakely/src/gcc/gcc/cp/class.c:6888 0x102ebd73 cp_parser_class_specifier_1 /home/jwakely/src/gcc/gcc/cp/parser.c:19868 0x102ebd73 cp_parser_class_specifier /home/jwakely/src/gcc/gcc/cp/parser.c:20096 0x102ebd73 cp_parser_type_specifier /home/jwakely/src/gcc/gcc/cp/parser.c:14734 0x10305447 cp_parser_decl_specifier_seq /home/jwakely/src/gcc/gcc/cp/parser.c:11965 0x1031d9c7 cp_parser_simple_declaration /home/jwakely/src/gcc/gcc/cp/parser.c:11542 0x10315547 cp_parser_block_declaration /home/jwakely/src/gcc/gcc/cp/parser.c:11489 0x10322abf cp_parser_declaration /home/jwakely/src/gcc/gcc/cp/parser.c:11386 0x10320a5f cp_parser_declaration_seq_opt /home/jwakely/src/gcc/gcc/cp/parser.c:11272 0x10320e43 cp_parser_translation_unit /home/jwakely/src/gcc/gcc/cp/parser.c:4107 0x10320e43 c_parse_file() /home/jwakely/src/gcc/gcc/cp/parser.c:33213 0x104b160b c_common_parse_file() /home/jwakely/src/gcc/gcc/c-family/c-opts.c:1067
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 chrbr at gcc dot gnu.org changed: What|Removed |Added Depends on||52144 --- Comment #29 from chrbr at gcc dot gnu.org --- Extend the attribute_target thumb/arm support to -mfpu isas Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 [Bug 52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source
[Bug c++/65835] bootstrap failure: multiple invalid conversions from ‘const char*’ to ‘char*’ [-fpermissive] in winnt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65835 tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from tprince at computer dot org --- The problem appears to have been cleared in trunk by 2015-05-19
[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #2 from Martin Liška marxin at gcc dot gnu.org ---
(In reply to Martin Liška from comment #1)
Following testcase is wrongly compiled event with -O2 optimization level.
$ cat o2-test-case.c
static int a;
int t(int tt)
{
switch (tt)
{
case 1: return a;
}
return 0;
}
$ ./xgcc -B. -mhotpatch=2,3 -O2 -fno-inline -o /tmp/test.s -S o2-test-case.c
$ head -n20 /tmp/test.s
.file o2-test-case.c
.text
.align 8
.globl t
.type t, @function
nopr%r7 # pre-label NOPs for hotpatch (2 halfwords)
nopr%r7
# alignment for hotpatch
.align 8
t:
marxin@marxinbox:~/Programming/gcc2/objdir/gcc head -n20 /tmp/test.s
.file o2-test-case.c
.text
.align 8
.globl t
.type t, @function
nopr%r7 # pre-label NOPs for hotpatch (2 halfwords)
nopr%r7
# alignment for hotpatch
.align 8
t:
# post-label NOPs for hotpatch (3 halfwords)
.LFB0:
st %r14,56(%r15)
nop 0
nopr%r7
.LCFI0:
l %r4,56(%r15)
lhi %r2,0
l %r14,56(%r15)
.LCFI1:
Sorry, this testcase is invalid as I modified the compiler.
Martin
[Bug c++/66216] New: Defaulted Operators and contructors not working with aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66216
Bug ID: 66216
Summary: Defaulted Operators and contructors not working with
aligned attribute
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: npl at chello dot at
Target Milestone: ---
The code below will not compile, faulting with defaulted declaration 'xx' does
not match expected signature.
This behaviour is in any gcc version from 4.7 - 5
// g++ -std=c++11 -c testalign.cpp
class CMymy
{
unsigned char _a;
unsigned char _b;
public:
constexpr CMymy() : _a(), _b() {}
constexpr CMymy(const CMymy ) = default;
CMymy operator=(const CMymy ) = default;
} __attribute__((aligned(2)));
[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 Ever confirmed|0 |1
[Bug target/29256] [4.8/4.9/5/6 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #53 from Bill Schmidt wschmidt at gcc dot gnu.org --- I'm not a fan of a tree-level unroller. It's impossible to make good decisions about unroll factors that early. But your second approach sounds quite promising to me.
[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 chrbr at gcc dot gnu.org changed: What|Removed |Added Blocks||59884 CC||joey.ye at arm dot com --- Comment #2 from chrbr at gcc dot gnu.org --- *** Bug 59884 has been marked as a duplicate of this bug. *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884 [Bug 59884] Unexpected warning pragma GCC target
[Bug target/59884] Unexpected warning pragma GCC target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||chrbr at gcc dot gnu.org Depends on||52144 Resolution|--- |DUPLICATE --- Comment #4 from chrbr at gcc dot gnu.org --- #pragma GCC target relies on the target_attribute work *** This bug has been marked as a duplicate of bug 52144 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 [Bug 52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source
[Bug c++/66211] [5/6 Regression] Rvalue conversion in ternary operator causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Perhaps just guard this particular match.pd pattern with GIMPLE guard for now (until the delayed C++ folding is committed)?
[Bug c/66219] New: The gcc generated section start/stop pointers become undefined when option -flto is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66219
Bug ID: 66219
Summary: The gcc generated section start/stop pointers become
undefined when option -flto is used
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dscao999 at hotmail dot com
Target Milestone: ---
Created attachment 35577
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35577action=edit
This tar contains all the information required for a bug
#include stdio.h
__attribute__ ((__section__(MAP))) long flags[] = {1, 2, 3, 4, 5, 6};
extern const long __start_MAP[];
extern const long __stop_MAP[];
int main(int argc, char *argv[])
{
const long *m;
m = __start_MAP;
while (m __stop_MAP) {
printf(%d , *m);
m++;
}
printf(\n);
return 0;
}
The magic pointers(__start_MAP, __stop_MAP) of sections will become undefined
if option -flto is used.
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 --- Comment #11 from asmwarrior asmwarrior at gmail dot com --- Today, I did the same test as in comment 6 with a more recent gcc 5.1(http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/dongsheng-daily/5.x/gcc-5-win32_5.1.1-20150512.7z/download), but I still get the same bad result.
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- NetBSD 5 and DragonFly BSD fail the test too. I'm going to make libstdc++ assume pthread_once is not exception-aware unless specifically told otherwise for targets where we know it works, such as x86-linux and (hopefully) glibc 2.21
[Bug libstdc++/66078] 20_util/specialized_algorithms/uninitialized_copy/808590.cc fails with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66078 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Ping? I think this is now the only thing preventing me from throwing the switch to default C++14.
[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- IMHO the nops should go immediately before the first real instruction in the function. The point of not emitting it earlier is so that the nops are already covered by debug and unwind info. So, we certainly should skip all NOTEs at the start of the function, and perhaps selected other insns (dunno if e.g. UNSPECV_MAIN_POOL insn emits any code or not). NOTE_INSN_FUNCTION_BEG is not a good place, as it can be preceeded by various prologue instructions, and the nops really have to go before all real instructions (that emit some bytes into the function text section).
[Bug middle-end/66221] New: [CHKP, 6 regression] lto1: error: type variant has different TYPE_ARG_TYPES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66221
Bug ID: 66221
Summary: [CHKP, 6 regression] lto1: error: type variant has
different TYPE_ARG_TYPES
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ienkovich at gcc dot gnu.org
Target Milestone: ---
Check added by r222991 reveals a problem with function types created for
instrumented functions.
cat test1.c
int test1 (const char *p)
{
return (int)(*p);
}
cat test2.c
int test1 (const char *);
int main (int argc, const char **argv)
{
return test1 (argv[0]);
}
gcc test1.c test2.c -O0 -flto -fcheck-pointer-bounds -mmpx
lto1: error: type variant has different TYPE_ARG_TYPES
function_type 0x7f7056a34bd0
type integer_type 0x7f7056843690 int public SI
size integer_cst 0x7f705683fdf8 constant 32
unit size integer_cst 0x7f705683fe10 constant 4
align 32 symtab 0 alias set -1 canonical type 0x7f7056843690 precision
32 min integer_cst 0x7f705683fdb0 -2147483648 max integer_cst 0x7f705683fdc8
2147483647
pointer_to_this pointer_type 0x7f705685a7e0
QI
size integer_cst 0x7f705683fca8 type integer_type 0x7f7056843150
bitsizetype constant 8
unit size integer_cst 0x7f705683fcc0 type integer_type 0x7f70568430a8
sizetype constant 1
align 8 symtab 0 alias set 0 canonical type 0x7f7056a34bd0
arg-types tree_list 0x7f7056a31550
value pointer_type 0x7f7056a34b28 type integer_type 0x7f7056a34a80
char
unsigned DI
size integer_cst 0x7f705683fbb8 constant 64
unit size integer_cst 0x7f705683fbd0 constant 8
align 64 symtab 0 alias set 0 canonical type 0x7f705685a7e0
pointer_to_this pointer_type 0x7f7056a3b1f8
chain tree_list 0x7f7056852938 value void_type 0x7f705685a000 void
pointer_to_this pointer_type 0x7f7056a3b930
function_type 0x7f7056a34c78
type integer_type 0x7f7056843690 int public SI
size integer_cst 0x7f705683fdf8 constant 32
unit size integer_cst 0x7f705683fe10 constant 4
align 32 symtab 0 alias set -1 canonical type 0x7f7056843690 precision
32 min integer_cst 0x7f705683fdb0 -2147483648 max integer_cst 0x7f705683fdc8
2147483647
pointer_to_this pointer_type 0x7f705685a7e0
QI
size integer_cst 0x7f705683fca8 type integer_type 0x7f7056843150
bitsizetype constant 8
unit size integer_cst 0x7f705683fcc0 type integer_type 0x7f70568430a8
sizetype constant 1
align 8 symtab 0 alias set 0 canonical type 0x7f7056a34c78
arg-types tree_list 0x7f7056a31528
value pointer_type 0x7f7056a34b28 type integer_type 0x7f7056a34a80
char
unsigned DI
size integer_cst 0x7f705683fbb8 constant 64
unit size integer_cst 0x7f705683fbd0 constant 8
align 64 symtab 0 alias set 0 canonical type 0x7f705685a7e0
pointer_to_this pointer_type 0x7f7056a3b1f8
chain tree_list 0x7f7056a31500 value pointer_bounds_type
0x7f705685a0a8 __bounds_type
chain tree_list 0x7f7056a314d8 value void_type 0x7f705685a000
void
lto1: internal compiler error: verify_type failed
0xf81484 verify_type(tree_node const*)
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/tree.c:12971
0x6c12c4 lto_fixup_state
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/lto/lto.c:2849
0x6c143b lto_fixup_decls
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/lto/lto.c:2881
0x6c1d2e read_cgraph_and_symbols
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/lto/lto.c:3102
0x6c29b3 lto_main()
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/lto/lto.c:3479
[Bug lto/66180] [6 Regression] many -Wodr false positives when building LLVM with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66180
--- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
If I change foo1.cpp from comment5 to:
#include memory
namespace first{
class A {
int i;
};
}
using namespace first;
class G {
std::unique_ptrA foo() const;
};
std::unique_ptrA G::foo() const { return std::make_uniqueA(); }
it works fine. So it looks like a bug after all, because an anonymous namespace
should be equivalent to:
namespace _compiler_generated_name {
...
}
using namespace _compiler_generated_name;
[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215 --- Comment #4 from Andreas Krebbel krebbel at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) IMHO the nops should go immediately before the first real instruction in the function. The point of not emitting it earlier is so that the nops are already covered by debug and unwind info. So, we certainly should skip all NOTEs at the start of the function, and perhaps selected other insns (dunno if e.g. UNSPECV_MAIN_POOL insn emits any code or not). NOTE_INSN_FUNCTION_BEG is not a good place, as it can be preceeded by various prologue instructions, and the nops really have to go before all real instructions (that emit some bytes into the function text section). UNSPECV_MAIN_POOL does not itself emit code. However, it is used as an anchor to emit insns right after it so we should not skip it here I think. We will try with skipping all the NOTEs as you suggested and we definitely should run all the hotpatch testcases at different optimization levels. Thanks!
[Bug c++/66223] Diagnostic of pure virtual function call broken, including __cxa_pure_virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66223 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 Ever confirmed|0 |1
[Bug c++/66223] New: Diagnostic of pure virtual function call broken, including __cxa_pure_virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66223
Bug ID: 66223
Summary: Diagnostic of pure virtual function call broken,
including __cxa_pure_virtual
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.frey at gmx dot de
Target Milestone: ---
Consider this small and certainly broken program:
struct B {
B* self;
B() : self( this ) { self-f(); }
virtual void f() = 0;
};
struct D : B
{
void f() {}
};
int main()
{
D d;
}
The ctor of B calls (indirectly) the pure virtual function f(), but the vtbl is
still from B, not D (yet). Hence the program crashes. With GCC 4.9, I got:
./a.out
pure virtual method called
terminate called without an active exception
Aborted (core dumped)
Which is a good hint and I got a core dump. Fine so far. With GCC 5.1, I get
this:
./a.out
Segmentation fault (core dumped)
Which is certainly less helpful.
What is actually a lot worse is that even __cxa_pure_virtual is severly broken.
I used to have my own __cxa_pure_virtual method to provide more output
including a backtrace, something like this was my output for GCC 4.9:
./a.out
### EMERGENCY ###
pure virtual function called
### BACKTRACE ###
build/release/test/emergency/pure_virtual_XFAIL(coin::core::output::backtrace()+0x23)
[0x4034a3]
build/release/test/emergency/pure_virtual_XFAIL(__cxa_pure_virtual+0x47)
[0x4031f7]
build/release/test/emergency/pure_virtual_XFAIL() [0x402a09]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7ff9dd52dec5]
build/release/test/emergency/pure_virtual_XFAIL() [0x402b14]
### ABORTING ###
Aborted (core dumped)
After the backtrace was printed to stdout, a core dump was written. With GCC
5.1, all I get is:
./a.out
where at least the result code is not 0 (it's 128 if it helps). But no message
and no core dump.
Further experiments have shown that GCC 5.1 actually calls the terminate
handler (which I also registered via std::set_terminate). This handler prints a
backtrace and some other information when called on other errors, but for a
pure virtual call it seems to be unable to even call a simple write() to
stdout.
Please let me know if you need further help to debug and fix this problem. I
realize it's just a diagnostic in case of calling an unimplemented pure
virtual method which should not be done in the first place, but I think the
current situation is really hurting people when there is absolutely no message
and no core dump and the process just returns with a non-zero exit code.
[Bug c++/39478] please improve recursive template instantiation diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Daniel Frey from comment #3) instead. I'd still like to see GCC to hint at the loop when trying to complete types where the completion of A requires a completed B and the completion of B requires a completed A. Then, what output do you propose for the testcase above? I'm not even sure GCC knows there is cycle. It probably only knows that the type is not complete at a time where the standard says it should be complete, and it doesn't try to figure out why it is not.
[Bug libstdc++/66078] 20_util/specialized_algorithms/uninitialized_copy/808590.cc fails with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66078 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed on trunk.
[Bug c/66220] -Wmisleading-indentation false/inconsistent warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220 David Malcolm dmalcolm at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #3 from David Malcolm dmalcolm at gcc dot gnu.org --- Patch posted as: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01858.html
[Bug libstdc++/66078] 20_util/specialized_algorithms/uninitialized_copy/808590.cc fails with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66078 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Wed May 20 17:11:03 2015 New Revision: 223449 URL: https://gcc.gnu.org/viewcvs?rev=223449root=gccview=rev Log: PR libstdc++/66078 * include/bits/stl_iterator.h (__make_move_if_noexcept_iterator): Add overload for pointers. * testsuite/20_util/specialized_algorithms/uninitialized_copy/ 808590.cc: Add -std=gnu++03 switch. * testsuite/20_util/specialized_algorithms/uninitialized_copy/ 808590-cxx11.cc: Copy of 808590.cc to test with -std=gnu++11. * testsuite/23_containers/vector/modifiers/push_back/ strong_guarantee.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590-cxx11.cc - copied, changed from r223442, trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc trunk/libstdc++-v3/testsuite/23_containers/vector/modifiers/push_back/strong_guarantee.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_iterator.h trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc
[Bug c++/39478] please improve recursive template instantiation diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478 --- Comment #5 from Daniel Frey d.frey at gmx dot de --- I don't know if it is possible for GCC to know, but it feels like it should know. If one type needs to instantiate another type, this goes on until either everything worked or GCC stops to instantiate a sub-type because this is already part of the current stack of template instantiations. Maybe I lack the background to understand what else the compiler could do, but it seems to me that it must somehow detect where to stop and instead bail out with an incomplete type which is then triggering the current error message in the caller which does require the instantiation to be successful. An error message could therefore look like this IMHO: t.cc: In instantiation of 'foobarint ' t.cc:14: instantiated from here foo bar int x; ^ t.cc:14: error: cyclic instantiation dependency in 'foobarint ' t.cc:4: instantiating 'barint' required for 'foobarint ' typename T::type dummy(); ^ t.cc:11: instantiating 'foobarint ' required for 'barint', end of cycle foo bar p; ^
[Bug libstdc++/66145] [5/6 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 Known to work||4.8.4, 4.9.2 Summary|std::ios_base::failure |[5/6 Regression] |objects thrown from |std::ios_base::failure |libstdc++.so use old ABI|objects thrown from ||libstdc++.so use old ABI Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Let's call this a regression, since the testcase used to catch the exception, but now doesn't with the default build settings.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #18 from Douglas Mencken dougmencken at gmail dot com --- try without --disable-checking Okay, doing it now. Meanwhile. Why ``sizeof (hashval_t) * CHAR_BIT'' cannot be checked at configure time, not at buildtime nor runtime?
[Bug c/66222] gcc error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up pass at noopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66222 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-05-20 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Please provide a preprocessed source file (ideally minimalized). av.c has #include EXTERN.h #include perl.h and we really don't have those headers.
[Bug c++/39478] please improve recursive template instantiation diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478 --- Comment #3 from Daniel Frey d.frey at gmx dot de --- Just a reminder that the error message is basically still the same with GCC 4.9 and does not help to understand the cause of the error. Especially real-world cases are therefore extremely hard to understand! I realize that recursion might not be the most appropriate word to describe the problem, maybe loop or cycle would be more helpful. To explain the problem again: The type is incomplete as the error message says, but the real question is: Why can't the compiler complete it like it normally would? It certainly *tried* to, but it failed. This is not obvious from the error message. The loop/cycle that is caused by the attempt to complete the type is not shown in the error message. The Clang error message is slightly better as it at least contains a hint towards typename T::type dummy(); which, as T=barint is trying to access barint::type (which exists and is void), but therefore barint has to be a complete type. Note that the error obviously goes away when you use int dummy(); instead. I'd still like to see GCC to hint at the loop when trying to complete types where the completion of A requires a completed B and the completion of B requires a completed A.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Douglas Mencken from comment #18) try without --disable-checking Okay, doing it now. Meanwhile. Why ``sizeof (hashval_t) * CHAR_BIT'' cannot be checked at configure time, not at buildtime nor runtime? Because it is closer to the code which it wants to guard. And, at least in optimized built, it should be a no-op - optimized away completely if the condition is true, because it can be evaluated at compile time.
[Bug target/66224] PowerPC _GLIBCXX_READ_MEM_BARRIER too weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66224 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target||powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-20 CC||bergner at gcc dot gnu.org, ||munroesj at us dot ibm.com, ||seurer at us dot ibm.com, ||wschmidt at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- Confirmed.
[Bug c/66222] gcc error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up pass at noopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66222
--- Comment #1 from Tong Liu mshzhb at gmail dot com ---
//av.h
/*av.h
*
*Copyright (c) 1991-1999, Larry Wall
*
*You may distribute under the terms of either the GNU General Public
*License or the Artistic License, as specified in the README file.
*
*/
struct xpvav {
char* xav_array; /* pointer to first array element */
SSize_t xav_fill; /* Index of last element present */
SSize_t xav_max;/* Number of elements for which array has space
*/
IV xof_off;/* ptr is incremented by offset */
double xnv_nv; /* numeric value, if any */
MAGIC* xmg_magic; /* magic for scalar array */
HV* xmg_stash; /* class package */
SV**xav_alloc; /* pointer to malloced string */
SV* xav_arylen;
U8 xav_flags;
};
#define AVf_REAL 1 /* free old entries */
#define AVf_REIFY 2 /* can become real */
#define AVf_REUSED 4/* got undeffed--don't turn old memory into SVs now */
#define Nullav Null(AV*)
#define AvARRAY(av) ((SV**)((XPVAV*) SvANY(av))-xav_array)
#define AvALLOC(av) ((XPVAV*) SvANY(av))-xav_alloc
#define AvMAX(av) ((XPVAV*) SvANY(av))-xav_max
#define AvFILLp(av) ((XPVAV*) SvANY(av))-xav_fill
#define AvARYLEN(av)((XPVAV*) SvANY(av))-xav_arylen
#define AvFLAGS(av) ((XPVAV*) SvANY(av))-xav_flags
#define AvREAL(av) (AvFLAGS(av) AVf_REAL)
#define AvREAL_on(av) (AvFLAGS(av) |= AVf_REAL)
#define AvREAL_off(av) (AvFLAGS(av) = ~AVf_REAL)
#define AvREIFY(av) (AvFLAGS(av) AVf_REIFY)
#define AvREIFY_on(av) (AvFLAGS(av) |= AVf_REIFY)
#define AvREIFY_off(av) (AvFLAGS(av) = ~AVf_REIFY)
#define AvREUSED(av)(AvFLAGS(av) AVf_REUSED)
#define AvREUSED_on(av) (AvFLAGS(av) |= AVf_REUSED)
#define AvREUSED_off(av) (AvFLAGS(av) = ~AVf_REUSED)
#define AvREALISH(av) (AvFLAGS(av) (AVf_REAL|AVf_REIFY))
#define AvFILL(av) ((SvRMAGICAL((SV *) (av))) \
? mg_size((SV *) av) : AvFILLp(av))
[Bug c/66222] New: gcc error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up pass at noopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66222 Bug ID: 66222 Summary: gcc error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up pass at noopt Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mshzhb at gmail dot com Target Milestone: --- Created attachment 35579 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35579action=edit source code ABSTRACT: [gcc] error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up pass at noopt DRIVER PASS: DRIVER FAIL:gcc 4.8.2 OPTIONS PASS: noopt OPTIONS FAIL: -O2 -O3 and up MACHINE DETAILS: (Optional: Specify machine name, OS and architecture) lep8244bv detail: Distributor ID: Ubuntu Description:Ubuntu 14.04.2 LTS Release:14.04 Codename: trusty Linux version 3.13.0-35-generic (buildd@fisher02) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #62-Ubuntu SMP Fri Aug 15 01:57:29 UTC 2014 Architecture: ppc64le Byte Order:Little Endian CPU(s):192 On-line CPU(s) list: 0-3,8-11,16-19,24-27,32-35,40-43,48-51,56-59,64-67,72-75,80-83,88-91,96-99,104-107,112-115,120-123,128-131,136-139,144-147,152-155,160-163,168-171,176-179,184-187 Off-line CPU(s) list: 4-7,12-15,20-23,28-31,36-39,44-47,52-55,60-63,68-71,76-79,84-87,92-95,100-103,108-111,116-119,124-127,132-135,140-143,148-151,156-159,164-167,172-175,180-183,188-191 Thread(s) per core:4 Core(s) per socket:6 Socket(s): 4 NUMA node(s): 4 Model: 8286-42A L1d cache: 64K L1i cache: 32K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 0-3,8-11,16-19,24-27,32-35,40-43 NUMA node1 CPU(s): 48-51,56-59,64-67,72-75,80-83,88-91 NUMA node16 CPU(s):96-99,104-107,112-115,120-123,128-131,136-139 NUMA node17 CPU(s):144-147,152-155,160-163,168-171,176-179,184-187 PROBLEM DESCRIPTION: gcc error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up but pass at noopt error information : In file included from /usr/include/stdio.h:937:0, from perlsdio.h:5, from iperlsys.h:203, from perl.h:325, from av.c:16: /usr/include/powerpc64le-linux-gnu/bits/stdio2.h: In function 'sprintf': /usr/include/powerpc64le-linux-gnu/bits/stdio2.h:33:3: error: invalid use of '__builtin_va_arg_pack ()' return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, ^ /usr/include/powerpc64le-linux-gnu/bits/stdio2.h: In function 'snprintf': /usr/include/powerpc64le-linux-gnu/bits/stdio2.h:64:3: error: invalid use of '__builtin_va_arg_pack ()' return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, ^ /usr/include/powerpc64le-linux-gnu/bits/stdio2.h: In function 'fprintf': /usr/include/powerpc64le-linux-gnu/bits/stdio2.h:97:3: error: invalid use of '__builtin_va_arg_pack ()' return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt, ^ /usr/include/powerpc64le-linux-gnu/bits/stdio2.h: In function 'printf': /usr/include/powerpc64le-linux-gnu/bits/stdio2.h:104:3: error: invalid use of '__builtin_va_arg_pack ()' return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ()); ^ /usr/include/powerpc64le-linux-gnu/bits/stdio2.h: In function 'dprintf': /usr/include/powerpc64le-linux-gnu/bits/stdio2.h:141:3: error: invalid use of '__builtin_va_arg_pack ()' return __dprintf_chk (__fd, __USE_FORTIFY_LEVEL - 1, __fmt, ^ - STEPS TO REPRODUCE: (Reduce the code in the README.ksh file as much as possible) /usr/bin/gcc -m64 -D__64BIT__=1 -O3 -mcpu=power8 -fabi-version=4 -std=gnu99 -I_END_XOPTS -DSPEC_CPU2000 -DSPEC_CPU2000_LP64 -DSPEC_CPU2000_LINUX_PPC32 -DSPEC_CPU2000_NEED_BOOL -DHAS_FGETPOS -DHAS_FSETPOS -fno-strict-aliasing -c -o av.o av.c - TESTCASE SOURCE: (reduced where applicable): (this field is optional for SPEC defects) //av.c see attachment
[Bug c/66220] -Wmisleading-indentation false/inconsistent warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220
--- Comment #2 from David Malcolm dmalcolm at gcc dot gnu.org ---
Thanks.
I ran into a variant of this whilst testing -Wmisleading-indentation on the
linux kernel, where a preprocessor macro conditionalizes the if/else; here's
the test case I reduced it to:
/* This variant of KR-style formatting (in the presence of conditional
compilation) shouldn't lead to a warning.
Based on false positive seen with r223098 when compiling
linux-4.0.3:arch/x86/crypto/aesni-intel_glue.c:aesni_init. */
void
fn_36 (void)
{
#if 1 /* e.g. some configuration variable. */
if (flagA) {
foo(0);
foo(1);
foo(2);
} else
#endif
{
foo(3);
foo(4);
foo(5);
}
foo(6); /* We shouldn't warn here. */
}
I have a fix for this, by requiring that the visual column of the guard
(else) be = that of the stmts, which works for all of the testcases
(including the new ones I posted as
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01846.html ), apart from fn_15:
#define FOR_EACH(VAR, START, STOP) for ((VAR) = (START); (VAR) (STOP);
(VAR++)) /* { dg-message 36: ...this 'for' clause, but it is not } */
void fn_15 (void)
{
int i;
FOR_EACH (i, 0, 10) /* { dg-message 3: in expansion of macro } */
foo (i);
bar (i, i); /* { dg-warning statement is indented as if it were guarded
by... } */
}
#undef FOR_EACH
which then fails to report the warning due to it using the location of the
for in the defn of macro FOR_EACH.
Fixing that will require some reworking on how we handle macro expansions.
[Bug target/66224] New: PowerPC _GLIBCXX_READ_MEM_BARRIER too weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66224 Bug ID: 66224 Summary: PowerPC _GLIBCXX_READ_MEM_BARRIER too weak Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- _GLIBCXX_READ_MEM_BARRIER should be lwsync on PowerPC for acquire barrier (fence), not isync.
[Bug target/65730] xtensa: ICE in libstdc++-v3/include/bits/atomic_base.h: In function ‘bool std::atomic_flag_test_and_set_explicit(std::__atomic_flag_base*, std::memory_order)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65730 --- Comment #2 from jcmvbkbc at gcc dot gnu.org --- Author: jcmvbkbc Date: Wed May 20 18:56:14 2015 New Revision: 223452 URL: https://gcc.gnu.org/viewcvs?rev=223452root=gccview=rev Log: Fix PR target/65730 2015-05-20 Max Filippov jcmvb...@gmail.com gcc/ * config/xtensa/xtensa.c (init_alignment_context): Replace MULT by BITS_PER_UNIT with ASHIFT by exact_log2 (BITS_PER_UNIT). Modified: trunk/gcc/ChangeLog trunk/gcc/config/xtensa/xtensa.c
[Bug c++/39478] please improve recursive template instantiation diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Daniel Frey from comment #5) I don't know if it is possible for GCC to know, but it feels like it should know. If one type needs to instantiate another type, this goes on until either everything worked or GCC stops to instantiate a sub-type because this is already part of the current stack of template instantiations. Maybe I But this is not what seems to be happening. Otherwise it would give some error like maximum number of recursive instantiations reached. lack the background to understand what else the compiler could do, but it seems to me that it must somehow detect where to stop and instead bail out with an incomplete type which is then triggering the current error message in the caller which does require the instantiation to be successful. There is indeed a function called can_complete_type_without_circularity() that is invoked in the above testcase. However, the information from this function is never passed down to cxx_incomplete_type_inform(), which is responsible of explaining the problem. If you add a breakpoint at the point of error in typeck2.c you'll see what I mean. I think it should be possible to generate an output like: test.cc: In instantiation of ‘struct barint’: test.cc:4:20: required from ‘struct foobarint ’ test.cc:14:19: required from here test.cc:11:14: error: ‘barT::p’ has incomplete type foo bar p; ^ test.cc:4: note: cyclic instantiation dependency instantiating 'barint' required for 'foobarint ' typename T::type dummy(); ^ test.cc:11: note: instantiating 'foobarint ' required for 'barint', end of cycle foo bar p; Unfortunately, how to achieve this does not look trivial to me and this still requires some thinking on how to pass this info down, and some trial-and-error to understand the correct conditions that can generate the correct message. I personally do not have the time required to do this and, judging for how long this has been open, I'm afraid no developer currently active considers this a priority. If you are motivated, I would humbly encourage you to try to figure out the solution and propose a patch. This may seem a daunting task, but contributing to GCC is much easier than it was just a few years ago (https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps) and you can work on it at your own pace. Even if it takes you one or two years, it will get fixed faster than if you never tried. Even a draft patch can motivate others to work on this. (I will change the status to NEW, but this does not mean that anyone is going to work on this)
[Bug libgcc/66225] libgcc/config/rs6000/morecore.S will not build on systems with an older assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225 --- Comment #3 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Wed May 20 21:39:40 2015 New Revision: 223463 URL: https://gcc.gnu.org/viewcvs?rev=223463root=gccview=rev Log: PR 66225 fix Modified: branches/ibm/ieee-submit/libgcc/config/rs6000/morestack.S
[Bug lto/66229] New: LTO fails with -fauto-profile on mcf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66229
Bug ID: 66229
Summary: LTO fails with -fauto-profile on mcf
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: hubicka at gcc dot gnu.org
Reporter: spop at gcc dot gnu.org
CC: dehao at gcc dot gnu.org, hiraditya at msn dot com
Target Milestone: ---
lto1: internal compiler error: in compute_working_sets, at gcov-io.c:1006
0x790dad compute_working_sets(gcov_ctr_summary const*, gcov_working_set_info*)
../../gcc/gcov-io.c:1006
0xba0faa get_working_sets()
../../gcc/profile.c:264
0xaf0ac7 input_symtab()
../../gcc/lto-cgraph.c:1880
0x6c3da0 read_cgraph_and_symbols
../../gcc/lto/lto.c:3061
0x6c4be9 lto_main()
../../gcc/lto/lto.c:3479
MCF from SPEC 2006 on x86_64-linux and other programs would fail with LTO +
AutoFDO with the following flags:
COPTIMIZE = -Ofast -g3 -fno-strict-aliasing -flto
-fauto-profile=mcf_base.gcc43-64bit.gcov
This fails with both trunk gcc and with the 5.1 release.
Also fails with an empty profile.
We collected the profile with create_gcov from a linux perf data.
We ran gdb on lto1 and have seen that the crash happens in gcov reader of lto:
gcc/gcov-io.c:1006
/* Compute the working set information from the counter histogram in
the profile summary. This is an array of information corresponding to a
range of percentages of the total execution count (sum_all), and includes
the number of counters required to cover that working set percentage and
the minimum counter value in that working set. */
GCOV_LINKAGE void
compute_working_sets (const struct gcov_ctr_summary *summary,
gcov_working_set_t *gcov_working_sets)
{
[...]
/* Next, walk through the histogram in decending order of hotness
and compute the statistics for the working set summary array.
As histogram entries are accumulated, we check to see which
working set entries have had their expected cum_value reached
and fill them in, walking the working set entries in increasing
size of cum_value. */
ws_ix = 0; /* The current entry into the working set array. */
cum = 0; /* The current accumulated counter sum. */
count = 0; /* The current accumulated count of block counters. */
for (h_ix = GCOV_HISTOGRAM_SIZE - 1;
h_ix = 0 ws_ix NUM_GCOV_WORKING_SETS; h_ix--)
{
histo_bucket = summary-histogram[h_ix];
/* If we haven't reached the required cumulative counter value for
the current working set percentage, simply accumulate this histogram
entry into the running sums and continue to the next histogram
entry. */
if (cum + histo_bucket-cum_value working_set_cum_values[ws_ix])
{
cum += histo_bucket-cum_value;
count += histo_bucket-num_counters;
continue;
}
[Here continue is always taken such that ws_ix never gets incremented.]
[...]
}
gcov_nonruntime_assert (ws_ix == NUM_GCOV_WORKING_SETS);
[And this would assert because ws_ix is still 0.]
[Bug c/66230] New: Using optimizations causes program to segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66230 Bug ID: 66230 Summary: Using optimizations causes program to segfault Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gpnuma at centaurean dot com Target Milestone: --- Hello, First I'd like to point out that the code producing this error compiles and runs fine in gcc 4.8.4-1 for Linux and OS/X and Clang 3.5, 3.6 (Linux) and 6.1 (OS/X), but fails with gcc 4.9.2 when using -O3 on both Linux and OS/X (in debug mode it works fine). The platform used for all these tests was x86_64. To reproduce : clone and build https://github.com/centaurean/density with gcc 4.9.2. Then run the following command : ./benchmark -3 some_file This will turn into a segfault. When I add the line [printf(anything);] just before DENSITY_MEMCPY(... here : https://github.com/centaurean/density/blob/master/src/kernel_lion_decode.c#L187, the program runs again normally without any segfault... that's really super strange. The function that fails is called via an array of function pointers, but I don't think that's the problem since it works with any other compiler.
[Bug fortran/66227] New: [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227 Bug ID: 66227 Summary: [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: patnel97269-gfortran at yahoo dot fr Target Milestone: --- Hi, The extends_type_of intrisic return the wrong value for the a polymorphic variable allocated to a daughter class. See small code below. Code tested on version 5.1.0 . implicit none type t1 integer :: a end type t1 type, extends(t1):: t11 integer :: b end type t11 type(t1) a1 type(t11) a11 class(t1), allocatable :: b1,bb1 class(t11), allocatable :: b11 allocate(t11::b1) print *, extends_type_of(b1,a11) ! T print *, extends_type_of(b1,a1) ! T deallocate(b1) allocate(b1,source=a11) print *, extends_type_of(b1,a11) ! T print *, extends_type_of(b1,a1) ! T allocate( b11,source=a11) print *, extends_type_of(b11,a11) ! T print *, extends_type_of(b11,a1) ! T allocate( bb1,source=a1) print *, extends_type_of(bb1,a11) ! F print *, extends_type_of(bb1,a1) ! T end
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #18 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #16) Also arguments of emit_move_insn must have the same integer modes. if (reg_overlap_mentioned_p (operands[1], operands[2])) std::swap (operands[0], operands[2]); sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3])); might ICE if operands[0] and operands[2] have different modes and swap happens, though I'm not sure whether such insns are real or not. Yes, that is true. However, because op0, op1, op2 are all arith_reg_dest the peephole will only match if those are GP regs. Each captured insn will only reference a single GP reg, because DImode moves should have been smashed into SImode moves before the peephole2 pass. Thus, I think it should be safe to just force the mode of op0 to SImode. I'll try it out.
[Bug target/66226] Incorrect code generation ppc, later assignment causes calling argument corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66226 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |target --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This sounds more likegetaddrinfo is over writing past the variable hints.
[Bug libgcc/66212] Exception handling broken on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66212 --- Comment #2 from Jim Wilson wilson at gcc dot gnu.org --- libgcc should be built with debug info by default, but the one in /lib is probably stripped. Try setting LD_LIBRARY_PATH to point at the gcc-5.1 libraries that you built, instead of using the default ones provided by the OS in /lib.
[Bug lto/66228] New: Compiling simple program with -flto -O1 causes mad behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66228 Bug ID: 66228 Summary: Compiling simple program with -flto -O1 causes mad behaviour Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: t...@the-tk.com Target Milestone: --- Created attachment 35582 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35582action=edit This is the wtf.i file left over from running gcc -v -save-temps -flto -O1 wtf.c This code, when compiled with -O1 and -flto and ran with no arguments passed prints: ./a.out: Incorrect number of arguments ./a.out: WTF? And exits returning 1. This behaviour is obviously incorrect. This has been tested on versions (various people): 4.8.4 4.9.2 20150304 5.1.0 20150505 5.1.1 20150519 The version I am personally using is 4.9.2 20150304. Here is the output of `gcc -v -save-temps -flto -O1 wtf.c': Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-4.9-20150304/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 4.9.2 20150304 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-B' '/usr/lib/hardening-wrapper/bin' '-fPIE' '-D' '_FORTIFY_SOURCE=2' '-pie' '-fstack-protector-strong' '-v' '-save-temps' '-flto' '-O1' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1 -E -quiet -v -D _FORTIFY_SOURCE=2 wtf.c -mtune=generic -march=x86-64 -fPIE -fstack-protector-strong -flto -O1 -fpch-preprocess -o wtf.i ignoring nonexistent directory /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include /usr/local/include /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-B' '/usr/lib/hardening-wrapper/bin' '-fPIE' '-D' '_FORTIFY_SOURCE=2' '-pie' '-fstack-protector-strong' '-v' '-save-temps' '-flto' '-O1' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1 -fpreprocessed wtf.i -quiet -dumpbase wtf.c -mtune=generic -march=x86-64 -auxbase wtf -O1 -version -fPIE -fstack-protector-strong -flto -o wtf.s GNU C (GCC) version 4.9.2 20150304 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.2 20150304 (prerelease), GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.2 warning: MPC header version 1.0.2 differs from library version 1.0.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.9.2 20150304 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.2 20150304 (prerelease), GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.2 warning: MPC header version 1.0.2 differs from library version 1.0.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: de1e8c8938fc18eb6d7bf643b5ef22cd COLLECT_GCC_OPTIONS='-B' '/usr/lib/hardening-wrapper/bin' '-fPIE' '-D' '_FORTIFY_SOURCE=2' '-pie' '-fstack-protector-strong' '-v' '-save-temps' '-flto' '-O1' '-mtune=generic' '-march=x86-64' as -v --64 -o wtf.o wtf.s GNU assembler version 2.25.0 (x86_64-unknown-linux-gnu) using BFD version (GNU Binutils) 2.25.0 COMPILER_PATH=/usr/lib/hardening-wrapper/bin/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/usr/lib/hardening-wrapper/bin/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-B' '/usr/lib/hardening-wrapper/bin' '-fPIE' '-D' '_FORTIFY_SOURCE=2' '-pie' '-fstack-protector-strong' '-v' '-save-temps' '-flto' '-O1' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/collect2 -plugin /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
[Bug libgcc/66225] libgcc/config/rs6000/morecore.S will not build on systems with an older assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org --- The proposed patch allows the big endian powerpc build to build and install.
[Bug lto/66229] LTO fails with -fauto-profile on mcf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66229 Dehao Chen dehao at google dot com changed: What|Removed |Added CC||dehao at google dot com --- Comment #1 from Dehao Chen dehao at google dot com --- We have not tested autofdo with lto at all. So I'm not surprised that this fails. Please feel free to send out patches to fix this. Thanks, Dehao
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #25 from Lawrence Velázquez vq at larryv dot me --- (In reply to m...@gcc.gnu.org from comment #22) Though I approved it on list, you should feel free to update with the review points others have and post that version if you wish. Re-roll posted: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01888.html
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #20 from Douglas Mencken dougmencken at gmail dot com --- I'm lost. “Vanilla” 5.1.0 configured without --disable-checking went thru stage2 w/o any issue...
[Bug c/66226] New: Incorrect code generation ppc, later assignment causes calling argument corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66226
Bug ID: 66226
Summary: Incorrect code generation ppc, later assignment causes
calling argument corruption
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: steven.deller at ois dot com
Target Milestone: ---
Created attachment 35581
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35581action=edit
Interim file
In the attached code, a simple assignment rp = res after the call to
getaddrinfo causes the arguments to getaddrinfo to be invalid, most likely the
hints argument, since making that argument NULL also allows the compiled code
to execute successfully.
An assignment following a call should not cause different behavior within the
call.
This only fails on the PowerPC compiler (I only have tested it on AIX). It
fails for versions 4.7.3, 4.8.3 and this reported 4.9.3 version.
The gcc compiler is the version supplied from AdaCore with the GNAT products.
I do not have access to the build information for the compiler.
Regards,
Steven Deller
410-757-6924
tga.c source:
#include sys/socket.h
#include netdb.h
#include stdio.h
int main(int argc, char **argv) {
struct addrinfo *res;
struct addrinfo hints;
int rc;
struct addrinfo *rp;
hints.ai_family = AF_INET; /* IPv4 only */
hints.ai_socktype = SOCK_DGRAM;
hints.ai_flags = 0;
hints.ai_protocol = 0;
hints.ai_canonname = NULL;
hints.ai_addr = NULL;
hints.ai_next = NULL;
rc = getaddrinfo(aix7, NULL, hints, res); // if hints is NULL,
runs fine
rp = res; // rc=11 with this in. Comment out and rc=0.
printf (rc=%d\n, rc);
return 0;
}
output from gcc -v -save-temps tga.c compilation:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../libexec/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/lto-wrapper
Target: powerpc-ibm-aix7.1.0.0
Configured with: ../src/configure --enable-languages=ada,c --with-gnu-as
--with-gnu-ld --with-dwarf2 --disable-shared
--disable-build-poststage1-with-cxx --disable-libsanitizer --disable-libcilkrts
--with-bugurl=URL:mailto:rep...@adacore.com --disable-nls
--without-libiconv-prefix --disable-libmudflap --disable-libstdcxx-pch
--disable-libada --enable-checking=release --enable-multilib --disable-plugin
--with-mpfr=/sully.a/gnatmail/sandbox/gnat-7.3.1/ppc-aix-linux/mpfr/install
--with-gmp=/sully.a/gnatmail/sandbox/gnat-7.3.1/ppc-aix-linux/gmp/install
--with-mpc=/sully.a/gnatmail/sandbox/gnat-7.3.1/ppc-aix-linux/mpc/install
--with-build-time-tools=/sully.a/gnatmail/sandbox/gnat-7.3.1/ppc-aix/gcc/build/buildtools/bin
--prefix=/usr/local/gnat --target=powerpc-ibm-aix7.1.0.0
--host=powerpc-ibm-aix7.1.0.0 --build=i686-pc-linux-gnu
Thread model: aix
gcc version 4.9.3 20141101 for GNAT Pro 7.3.1 (20150118) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps'
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../libexec/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/cc1
-E -quiet -v -iprefix
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/
tga.c -fpch-preprocess -o tga.i
ignoring nonexistent directory
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/../../../../powerpc-ibm-aix7.1.0.0/include
ignoring duplicate directory
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/../../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/include
ignoring duplicate directory
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/../../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/include-fixed
ignoring nonexistent directory
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/../../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/../../../../powerpc-ibm-aix7.1.0.0/include
#include ... search starts here:
#include ... search starts here:
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/include
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/include-fixed
/usr/local/include
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../lib/gcc/../../include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps'
/toolchain/compilers/GNAT-7.3.1/ppc_6xx-aix_5.3/bin/../libexec/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/cc1
-fpreprocessed tga.i -quiet -dumpbase tga.c -auxbase tga -version -o tga.s
GNU C (GCC) version 4.9.3 20141101 for GNAT Pro 7.3.1 (20150118)
(powerpc-ibm-aix7.1.0.0)
compiled by GNU C version 4.9.3 20141101 for GNAT Pro 7.3.1 (20150118),
GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=32768
GNU C (GCC) version 4.9.3 20141101 for GNAT Pro 7.3.1 (20150118)
[Bug c++/66216] [6 Regression] Defaulted Operators and constructors not working with aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66216 --- Comment #2 from James Almer jamrial at gmail dot com --- (In reply to Jonathan Wakely from comment #1) And now it gives an ICE on trunk, so it's regressed from rejects-valid to ice-on-valid-code: a.cc:1:7: internal compiler error: canonical types differ for identical types const CMymy and const CMymy class CMymy This may be a duplicate of pr65936 then, or related.
[Bug libgcc/66225] New: libgcc/config/rs6000/morecore.S will not build on systems with an older assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225 Bug ID: 66225 Summary: libgcc/config/rs6000/morecore.S will not build on systems with an older assembler Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: amodra at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu I downloaded subversion id 223451 of GCC and tried to build it on my big endian power7 system running Sles 11r3, and it would not build due to the use of the .abiversion pseudo op that is not available in either the host assembler or in the Advance Toolchain 7.0 assembler.
[Bug libgcc/66225] libgcc/config/rs6000/morecore.S will not build on systems with an older assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 35580 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35580action=edit Proposed patch to fix the problem I just wrote this patch, and I'm starting a bootstrap build with it.
[Bug target/65730] xtensa: ICE in libstdc++-v3/include/bits/atomic_base.h: In function ‘bool std::atomic_flag_test_and_set_explicit(std::__atomic_flag_base*, std::memory_order)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65730 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from jcmvbkbc at gcc dot gnu.org --- Fixed.
[Bug libgcc/66225] libgcc/config/rs6000/morecore.S will not build on systems with an older assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-05-20 Ever confirmed|0 |1 Severity|normal |blocker
[Bug libgcc/66225] libgcc/config/rs6000/morecore.S will not build on systems with an older assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||amodra at gmail dot com Resolution|--- |FIXED --- Comment #5 from Alan Modra amodra at gmail dot com --- Fixed.
[Bug libgcc/66225] libgcc/config/rs6000/morecore.S will not build on systems with an older assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225 --- Comment #4 from Alan Modra amodra at gcc dot gnu.org --- Author: amodra Date: Wed May 20 23:55:08 2015 New Revision: 223464 URL: https://gcc.gnu.org/viewcvs?rev=223464root=gccview=rev Log: PR libgcc/66225 * config/rs6000/morestack.S: Remove .abiversion 1. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/rs6000/morestack.S
