[Bug sanitizer/61530] New: [4.10 Regression] segfault with asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530 Bug ID: 61530 Summary: [4.10 Regression] segfault with asan Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Current trunk started failing in the day between good: r211692 bad: r211720 gfortran -c -fsanitize=address bug.f90 bug.f90: In function ‘mainlb’: bug.f90:3:0: internal compiler error: Segmentation fault SUBROUTINE mainlb(n, m, x, l, u, nbd, f, g, factr, pgtol, ws, wy, ^ 0xa5ba8f crash_signal ../../gcc/gcc/toplev.c:337 0xa6f206 contains_struct_check ../../gcc/gcc/tree.h:2835 0xa6f206 build_check_stmt ../../gcc/gcc/asan.c:1824 0xa74dbb instrument_mem_region_access ../../gcc/gcc/asan.c:1984 0xa759a1 instrument_builtin_call ../../gcc/gcc/asan.c:2105 0xa759a1 maybe_instrument_call ../../gcc/gcc/asan.c:2178 0xa759a1 transform_statements ../../gcc/gcc/asan.c:2245 0xa7663c asan_instrument ../../gcc/gcc/asan.c:2625 0xa7663c execute ../../gcc/gcc/asan.c:2700 Please submit a full bug report, cat bug.f90 MODULE cp_lbfgs CONTAINS SUBROUTINE mainlb(n, m, x, l, u, nbd, f, g, factr, pgtol, ws, wy, csave, lsave, isave, dsave) CHARACTER(len=60):: task IF (task == 'START') THEN IF (task(1:5) == 'NEW_X') GOTO 777 IF (task(1:4) == 'STOP') THEN IF (task(7:9) == 'CPU') THEN CALL dcopy(n,t,1,x,1) ENDIF ENDIF ENDIF 222 CONTINUE IF (info /= 0 .OR. iback = 20) THEN IF (col == 0) THEN IF (info == 0) THEN ENDIF task = 'ABNORMAL_TERMINATION_IN_LNSRCH' GOTO 222 ENDIF ENDIF 777 CONTINUE END SUBROUTINE mainlb END MODULE cp_lbfgs
[Bug target/61330] [4.10 Regression] Thumb ICE for case 920507-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Target|aarch64*-*-*, arm*-*-*, |aarch64*-*-*, arm*-*-*,
|powerpc*-*-*|powerpc*-*-*, alpha*-*-*
CC||ubizjak at gmail dot com
--- Comment #4 from Uroš Bizjak ubizjak at gmail dot com ---
Also happens on alpha-linux-gnu. The backtrace with -O2 -ffat-lto-objects,
obtained from x86_64-pc-linux-gnu crosscompiler is:
920507-1.c: In function ‘x’:
920507-1.c:5:16: error: invalid register name for ‘a’
register int *a asm(unknown_register); /* { dg-error invalid register }
*/
^
920507-1.c:3:1: internal compiler error: in symtab_get_node, at cgraph.h:1073
x(void)
^
0xc6d5ab decl_section_name(tree_node const*)
../../gcc-svn/trunk/gcc/cgraph.h:1070
0xcd690b alpha_in_small_data_p
../../gcc-svn/trunk/gcc/config/alpha/alpha.c:683
0xcb8271 default_encode_section_info(tree_node*, rtx_def*, int)
../../gcc-svn/trunk/gcc/varasm.c:6573
0x90c349 rest_of_decl_compilation(tree_node*, int, int)
../../gcc-svn/trunk/gcc/passes.c:215
0x6139fa expand_one_hard_reg_var
../../gcc-svn/trunk/gcc/cfgexpand.c:1109
0x6139fa expand_one_var
../../gcc-svn/trunk/gcc/cfgexpand.c:1296
0x613cd9 expand_used_vars_for_block
../../gcc-svn/trunk/gcc/cfgexpand.c:1339
0x61f0ee expand_used_vars
../../gcc-svn/trunk/gcc/cfgexpand.c:1806
0x6200d3 execute
../../gcc-svn/trunk/gcc/cfgexpand.c:5671
[Bug target/58945] Improve atomic_compare_and_swap*_doubleword pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58945 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- Steven, do you have any ETA for this fix?
[Bug bootstrap/61508] [4.10 regression] fold-const.c:14863:55: error: cannot convert 'const char*' to 'const_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61508 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-06-17 CC||hubicka at gcc dot gnu.org, ||tschwinge at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Schwinge tschwinge at gcc dot gnu.org --- http://news.gmane.org/find-root.php?message_id=%3C87lhswhwdf.fsf%40kepler.schwinge.homeip.net%3E.
[Bug middle-end/61430] [4.10 regression] ICE in lra_create_copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61430 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Presumably fixed now.
[Bug c++/61531] New: Optimizer completely removes some bitset code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61531
Bug ID: 61531
Summary: Optimizer completely removes some bitset code
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Ulrich.Windl at rz dot uni-regensburg.de
I wrote a simple test code for bitset that the default optimization complete
removes. Only -O0 keept the code. However the default code should output. Thus
I consider the optimization bad. Preprocessed input will follow, but here is
the basic test:
---
~/src/C++/bitsettest cat bstest.cc
#includeiostream
#includebitset
int main(int argc, char *argv[])
{
std::bitset32 b;
#if 0
std::cout size b.size() std::endl;
#endif
b.set(2);
if (b.test(2))
std::cout set 2 std::endl;
if (b[3])
std::cout set 3 std::endl;
return 0;
}
~/src/C++/bitsettest make
g++ -Wall -Wextra -Wshadow -pipe -O2 -g --save-temps-c -o bstest.o
bstest.cc
g++: warning: -pipe ignored because -save-temps specified
bstest.cc:4: warning: unused parameter ‘argc’
bstest.cc:4: warning: unused parameter ‘argv’
g++ -o bstest bstest.o
~/src/C++/bitsettest
(gdb) disassemble /m main
Dump of assembler code for function main(int, char**):
4 int main(int argc, char *argv[])
0x004008b0 +0: sub$0x8,%rsp
5 {
6 std::bitset32 b;
7
8 #if 0
9 std::cout size b.size() std::endl;
10 #endif
11 b.set(2);
12 if (b.test(2))
13 std::cout set 2 std::endl;
14 if (b[3])
15 std::cout set 3 std::endl;
16 return 0;
17 }
0x004008d2 +34:xor%eax,%eax
0x004008d4 +36:add$0x8,%rsp
0x004008d8 +40:retq
End of assembler dump.
---
[Bug c++/61531] Optimizer completely removes some bitset code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61531 --- Comment #1 from Ulrich Windl Ulrich.Windl at rz dot uni-regensburg.de --- Exact version of g++ is that of SLES11 SP3 for x86_64 (gcc-c++-4.3-62.198).
[Bug c++/61531] Optimizer completely removes some bitset code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61531 --- Comment #2 from Ulrich Windl Ulrich.Windl at rz dot uni-regensburg.de --- Created attachment 32948 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32948action=edit Preprocessed source (gzip compressed)
[Bug c++/61531] Optimizer completely removes some bitset code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61531
--- Comment #3 from Ulrich Windl Ulrich.Windl at rz dot uni-regensburg.de ---
Here's (for completeness) the code when I use -O0:
~/src/C++/bitsettest make
g++ -Wall -Wextra -Wshadow -O0 -g --save-temps-c -o bstest.o bstest.cc
bstest.cc:4: warning: unused parameter ‘argc’
bstest.cc:4: warning: unused parameter ‘argv’
g++ -o bstest bstest.o
~/src/C++/bitsettest gdb bstest
GNU gdb (GDB) SUSE (7.5.1-0.7.29)
[...]
Dump of assembler code for function main(int, char**):
4 int main(int argc, char *argv[])
0x0040095e +0: push %rbp
0x0040095f +1: mov%rsp,%rbp
0x00400962 +4: push %rbx
0x00400963 +5: sub$0x38,%rsp
0x00400967 +9: mov%edi,-0x34(%rbp)
0x0040096a +12:mov%rsi,-0x40(%rbp)
5 {
6 std::bitset32 b;
0x0040096e +16:lea-0x30(%rbp),%rdi
0x00400972 +20:callq 0x400a7a std::bitset32ul::bitset()
7
8 #if 0
9 std::cout size b.size() std::endl;
10 #endif
11 b.set(2);
0x00400977 +25:lea-0x30(%rbp),%rdi
0x0040097b +29:mov$0x1,%edx
0x00400980 +34:mov$0x2,%esi
0x00400985 +39:callq 0x400bf0
std::bitset32ul::set(unsigned long, bool)
12 if (b.test(2))
0x0040098a +44:lea-0x30(%rbp),%rdi
0x0040098e +48:mov$0x2,%esi
0x00400993 +53:callq 0x400c28
std::bitset32ul::test(unsigned long) const
0x00400998 +58:test %al,%al
0x0040099a +60:je 0x4009b8 main(int, char**)+90
13 std::cout set 2 std::endl;
0x0040099c +62:mov$0x400d6d,%esi
0x004009a1 +67:mov$0x602080,%edi
0x004009a6 +72:callq 0x4007e0
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt
0x004009ab +77:mov%rax,%rdi
0x004009ae +80:mov$0x400800,%esi
0x004009b3 +85:callq 0x4007f0 _ZNSolsEPFRSoS_E@plt
14 if (b[3])
0x004009b8 +90:lea-0x20(%rbp),%rdi
0x004009bc +94:lea-0x30(%rbp),%rsi
0x004009c0 +98:mov$0x3,%edx
0x004009c5 +103: callq 0x400bbe
std::bitset32ul::operator[](unsigned long)
0x004009ca +108: lea-0x20(%rbp),%rdi
0x004009ce +112: callq 0x400a9c
std::bitset32ul::reference::operator bool() const
0x004009d3 +117: mov%eax,%ebx
0x004009d5 +119: lea-0x20(%rbp),%rdi
0x004009d9 +123: callq 0x400a92
std::bitset32ul::reference::~reference()
0x004009de +128: test %bl,%bl
0x004009e0 +130: je 0x4009fe main(int, char**)+160
15 std::cout set 3 std::endl;
0x004009e2 +132: mov$0x400d73,%esi
0x004009e7 +137: mov$0x602080,%edi
0x004009ec +142: callq 0x4007e0
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt
0x004009f1 +147: mov%rax,%rdi
0x004009f4 +150: mov$0x400800,%esi
0x004009f9 +155: callq 0x4007f0 _ZNSolsEPFRSoS_E@plt
16 return 0;
0x004009fe +160: mov$0x0,%eax
17 }
0x00400a03 +165: add$0x38,%rsp
0x00400a07 +169: pop%rbx
0x00400a08 +170: leaveq
0x00400a09 +171: retq
End of assembler dump.
(gdb)
[Bug c++/61531] Optimizer completely removes some bitset code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61531 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- 4.3 is ancient and unsupported. Can you try to reproduce with 4.8 or later? (I don't see it with 4.4, which is the oldest I have here)
[Bug c++/61531] Optimizer completely removes some bitset code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61531 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-06-17 Ever confirmed|0 |1
[Bug libstdc++/61532] New: [4.10 regression] make_signed and make_unsigned wchar_t have started failing in the libstdc++ testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61532 Bug ID: 61532 Summary: [4.10 regression] make_signed and make_unsigned wchar_t have started failing in the libstdc++ testsuite. Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ramana at gcc dot gnu.org Somewhere between 210455 and 210475 these tests started failing on arm-none-linux-gnueabihf. I see the same failures on aarch64-none-elf too. FAIL: 20_util/make_signed/requirements/typedefs-1.cc (test for excess errors) FAIL: 20_util/make_signed/requirements/typedefs-2.cc (test for excess errors) FAIL: 20_util/make_unsigned/requirements/typedefs-1.cc (test for excess errors) FAIL: 20_util/make_unsigned/requirements/typedefs-2.cc (test for excess errors) FAIL: tr1/2_general_utilities/shared_ptr/modifiers/reset_neg.cc (test for errors, line 36) All with static_assert( is_sametest23_type, volatile signed wchar_t::value, or their equivalent. In C on ARM the wchar_t type is defined to unsigned int on AAPCS configurations which is true for Linux, I'm not sure what we do in C++ but I expect this to be the same. I suspect there is something underlying here for all targets that define wchar_t to be unsigned int by default. Looking at other testresults in June it looks like atleast the first 2 tests fail on powerpc-linux and powerpc-aix regards Ramana
[Bug libstdc++/61532] [4.10 regression] make_signed and make_unsigned wchar_t have started failing in the libstdc++ testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61532 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-17 Target Milestone|--- |4.10.0 Ever confirmed|0 |1
[Bug libstdc++/61532] [4.10 regression] make_signed and make_unsigned wchar_t have started failing in the libstdc++ testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61532 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Targets that define wchar_t as unsigned int are not conforming to the C++ standard, which requires wchar_t to be a distinct type, not a typedef. I can look into a hack to detect non-conforming targets, but probably not until next week.
[Bug sanitizer/61530] [4.10 Regression] segfault with asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #1 from Yury Gribov y.gribov at samsung dot com --- Mine.
[Bug libstdc++/61532] [4.10 regression] make_signed and make_unsigned wchar_t have started failing in the libstdc++ testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61532 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- This is likely to also be failing on the 4.9 branch, since the weekend
[Bug libstdc++/61532] [4.10 regression] make_signed and make_unsigned wchar_t have started failing in the libstdc++ testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61532 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug libstdc++/61532] [4.10 regression] make_signed and make_unsigned wchar_t have started failing in the libstdc++ testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61532 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #2) This is likely to also be failing on the 4.9 branch, since the weekend I was about to add 4.9 but then couldn't find a link to post. (In reply to Jonathan Wakely from comment #1) Targets that define wchar_t as unsigned int are not conforming to the C++ standard, which requires wchar_t to be a distinct type, not a typedef. The standard appears to say in Section 3.9.1 (basic.fundamental) #5 that the Type wchar_t shall have the same size, signedness, and alignment requirements (3.11) as one of the other integral types, called its underlying type. That's my interpretation from n3337. I can look into a hack to detect non-conforming targets, but probably not until next week. Please do take a look. Ramana
[Bug libstdc++/61532] [4.9/4.10 regression] make_signed and make_unsigned wchar_t have started failing in the libstdc++ testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61532 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Known to work||4.9.0 Target Milestone|4.10.0 |4.9.1 Summary|[4.10 regression] |[4.9/4.10 regression] |make_signed and |make_signed and |make_unsigned wchar_t have |make_unsigned wchar_t have |started failing in the |started failing in the |libstdc++ testsuite.|libstdc++ testsuite. Known to fail||4.10.0, 4.9.1
[Bug c++/61531] Optimizer completely removes some bitset code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61531 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- It works for me. g++ t.C -O2 ./a.out set 2 this is with rpm -q gcc43-c++ gcc43-c++-4.3.4_20091019-0.22.17 rpm -q --changelog gcc43-c++ | head * Thu Nov 10 2011 rguent...@suse.com - Fix altivec comparison builtins. [bnc#729378]
[Bug sanitizer/61530] [4.10 Regression] segfault with asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug middle-end/61529] [4.10 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61529 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-17 Component|tree-optimization |middle-end Target Milestone|--- |4.10.0 Summary|ICE on valid code at -O3 on |[4.10 Regression] ICE on |x86_64-linux-gnu in |valid code at -O3 on |check_probability, at |x86_64-linux-gnu in |basic-block.h:953 |check_probability, at ||basic-block.h:953 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug lto/61012] [4.9/4.10 Regression] lto1: errors during merging of translation units (error: variable ‘link’ redeclared as function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||khimov at altell dot ru --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 61526 has been marked as a duplicate of this bug. ***
[Bug libstdc++/61532] [4.9/4.10 regression] make_signed and make_unsigned wchar_t have started failing in the libstdc++ testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61532 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- Writing signed wchar_t doesn't seem legal to me, and clang and intel warn or reject such code.
[Bug lto/61526] relocation R_X86_64_PC32 in shared object with static and extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61526
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
I think this is a duplicate of PR61012. That is, works on the branch head for
me.
Reduced testcase that fails with 4.9.0:
static void *master;
void *foo () { return master; }
---
extern void *master;
void *bar () { return master; }
and using -flto-partition=1to1 at link.
*** This bug has been marked as a duplicate of bug 61012 ***
[Bug middle-end/61508] [4.10 regression] fold-const.c:14863:55: error: cannot convert 'const char*' to 'const_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61508 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|bootstrap |middle-end Resolution|--- |FIXED --- Comment #2 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Fixed in r211727.
[Bug lto/61012] [4.9/4.10 Regression] lto1: errors during merging of translation units (error: variable ‘link’ redeclared as function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jun 17 09:07:41 2014 New Revision: 211728 URL: https://gcc.gnu.org/viewcvs?rev=211728root=gccview=rev Log: 2014-06-17 Richard Biener rguent...@suse.de PR lto/61012 * gcc.dg/lto/pr61526_0.c: New testcase. * gcc.dg/lto/pr61526_1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/lto/pr61526_0.c trunk/gcc/testsuite/gcc.dg/lto/pr61526_1.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug lto/61012] [4.9/4.10 Regression] lto1: errors during merging of translation units (error: variable ‘link’ redeclared as function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jun 17 09:08:02 2014 New Revision: 211729 URL: https://gcc.gnu.org/viewcvs?rev=211729root=gccview=rev Log: 2014-06-17 Richard Biener rguent...@suse.de PR lto/61012 * gcc.dg/lto/pr61526_0.c: New testcase. * gcc.dg/lto/pr61526_1.c: Likewise. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/lto/pr61526_0.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/lto/pr61526_1.c Modified: branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Ilya Mikhaltsou morpheby at gmail dot com changed: What|Removed |Added CC||morpheby at gmail dot com --- Comment #8 from Ilya Mikhaltsou morpheby at gmail dot com --- Created attachment 32949 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32949action=edit Patch to compile gcc on OS X 10.10 Yosemite Fixed everything I encountered during build. GCC compiled successfully in three-stage build and is working fine for me.
[Bug target/61533] New: gcc.target/i386/fuse-caller-save.c FAILs on 64-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61533 Bug ID: 61533 Summary: gcc.target/i386/fuse-caller-save.c FAILs on 64-bit Solaris/x86 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: tom at codesourcery dot com, ubizjak at gmail dot com Host: i386-pc-solaris2.1[01] Target: i386-pc-solaris2.1[01] Build: i386-pc-solaris2.1[01] The new gcc.target/i386/fuse-caller-save.c test FAILs on Solaris 10 and 11/x86 with gas and -m64: FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-not .cfi_def_cfa_offset FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-not .cfi_offset It's compiled like this: /var/gcc/regression/trunk/11-gcc-gas/build/gcc/xgcc -B/var/gcc/regression/trunk/11-gcc-gas/build/gcc/ /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/fuse-caller-save.c -fno-diagnostics-show-caret -fdiagnostics-color=never -mclear-hwcap -O2 -fuse-caller-save -S -m64 -o fuse-caller-save.s I'm attaching the assembler output. Rainer
[Bug target/61533] gcc.target/i386/fuse-caller-save.c FAILs on 64-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61533 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug target/61533] gcc.target/i386/fuse-caller-save.c FAILs on 64-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61533 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org --- Created attachment 32950 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32950action=edit assembler output
[Bug lto/61526] relocation R_X86_64_PC32 in shared object with static and extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61526 Roman Khimov khimov at altell dot ru changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Roman Khimov khimov at altell dot ru --- Just tried the fix for PR61012 and indeed, it solves the problem. Thanks.
[Bug libstdc++/61519] Seemingly incorrect vtable reference when libstdc++ built with RTTI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61519 Matthew Iselin matthew at theiselins dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Matthew Iselin matthew at theiselins dot net --- Buggy loader wasn't honoring addend in ELF RELA relocations. Apologies for the noise.
[Bug target/61483] [AArch64] builtin va_start incorrectly initializes the field of va_list for incoming unnamed arguments on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61483 --- Comment #1 from Yufeng Zhang yufeng at gcc dot gnu.org --- Author: yufeng Date: Tue Jun 17 09:39:22 2014 New Revision: 211733 URL: https://gcc.gnu.org/viewcvs?rev=211733root=gccview=rev Log: gcc/ PR target/61483 * config/aarch64/aarch64.c (aarch64_layout_arg): Add new local variable 'size'; calculate 'size' right in the front; use 'size' to compute 'nregs' (when 'allocate_ncrn != 0') and pcum-aapcs_stack_words. gcc/testsuite/ PR target/61483 * gcc.target/aarch64/aapcs64/type-def.h (struct hfa_fx2_t): New type. * gcc.target/aarch64/aapcs64/va_arg-13.c: New test. * gcc.target/aarch64/aapcs64/va_arg-14.c: Ditto. * gcc.target/aarch64/aapcs64/va_arg-15.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-13.c trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-14.c trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-15.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/type-def.h
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-17 Ever confirmed|0 |1 --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Ilya Mikhaltsou from comment #8) Created attachment 32949 [details] Patch to compile gcc on OS X 10.10 Yosemite Fixed everything I encountered during build. GCC compiled successfully in three-stage build and is working fine for me. Hi Ilya, If you want to see this working for future versions of GCC, perhaps it would be better to get your patch into the official GCC. Check https://gcc.gnu.org/contribute.html
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-17 Ever confirmed|0 |1 --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Nicholas from comment #9) Manuel, I have filed a patch to gcc-patches. https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00862.html Great! unfortunately I don't have any power to approve patches. You'll have to wait until one of the CPP/C/C++ maintainers approves it. Perhaps you can ping the patch once per week (see the mailing list archives for examples of people pinging patches). Does it fix the problem reported by Matt in PR6142 also?
[Bug sanitizer/61530] [4.10 Regression] segfault with asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530 --- Comment #2 from Yury Gribov y.gribov at samsung dot com --- Created attachment 32951 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32951action=edit Proposed patch This seems to fix the ICE (I haven't yet done complete bootstrap, just Asan tests).
[Bug target/61533] gcc.target/i386/fuse-caller-save.c FAILs on 64-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61533 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Rainer Orth from comment #1) Created attachment 32950 [details] assembler output The test assumes that frame pointer is omitted.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #10 from Ilya Mikhaltsou morpheby at gmail dot com --- (In reply to Manuel López-Ibáñez from comment #9) (In reply to Ilya Mikhaltsou from comment #8) Created attachment 32949 [details] Patch to compile gcc on OS X 10.10 Yosemite Fixed everything I encountered during build. GCC compiled successfully in three-stage build and is working fine for me. Hi Ilya, If you want to see this working for future versions of GCC, perhaps it would be better to get your patch into the official GCC. Check https://gcc.gnu.org/contribute.html Thanks. I think, it may be better first to ensure this works for everybody affected. Anyway, I hope someone else picks it up from there.
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- The solution I'm testing is to give every tuple hierarchy a distinct base class, differentiated by an unused template argument that depends on the types of all the elements, so the base classes can be at the same address. The downside is this produces additional instantiations for programs using different tuple types that have common tails, e.g. tupleA,B,C and tupleD,B,C would no longer share any code. Those class instantiation shouldn't generate much code, so maybe that's not an issue
[Bug c/61534] New: Wlogical-op should not warn when either operand comes from macro expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61534
Bug ID: 61534
Summary: Wlogical-op should not warn when either operand comes
from macro expansion
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
#define DEFINED (x != 0)
int foo(int x)
{
if (!DEFINED x != 0) return 0;
return 1;
}
manuel@gcc10:~$ ~/test1/210581/build/gcc/cc1 -Wlogical-op test.c
foo
test.c: In function ‘foo’:
test.c:5:16: warning: logical ‘and’ of mutually exclusive tests is always false
[-Wlogical-op]
if (!DEFINED x != 0) return 0;
^
Clang does not warn. This was the reason -Wlogical-op was moved out of -Wextra
(PR40172).
[Bug c/60759] improve -Wlogical-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60759 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-17 Summary|-Wlogical-op should perhaps |improve -Wlogical-op |warn about two-way implicit | |conversions | Ever confirmed|0 |1 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- GCC's -Wlogical-op warns for this: pr60759.c:6:12: warning: logical ‘or’ applied to non-boolean constant [-Wlogical-op] return y || 3; ^ However, GCC does not warn when both operands are constants or neither is a constant. I think it is clear that it should warn for the former case. The conditions at which it should warn are the same (it warns even if the result is used in a boolean context). The latter case is more controversial. Moreover, in this case the context is significant: int a = foo(1) || foo(2); // warn bool a = foo(1) || foo(2); // do NOT warn Someone would need to check how much code will be wrongly warned and how to minimize the amount of false positives.
[Bug c/53131] -Wlogical-op: ready for prime time in -Wall ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53131 --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #7) In fact, the main show-stopper for adding -Wlogical-op to -Wextra (or -Wall) is PR40172, which was the reason it was moved out of -Wextra in the first place. Since PR40172 was closed without fixing the real problem, I opened PR61534. As far as I am aware, this is the only issue preventing -Wlogical-op to be moved back to -Wextra. As always, patches welcome.
[Bug c++/61531] Optimizer completely removes some bitset code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61531 --- Comment #6 from Ulrich Windl Ulrich.Windl at rz dot uni-regensburg.de --- (In reply to Richard Biener from comment #5) rpm -q gcc43-c++ gcc43-c++-4.3.4_20091019-0.22.17 rpm -q --changelog gcc43-c++ | head * Thu Nov 10 2011 rguent...@suse.com - Fix altivec comparison builtins. [bnc#729378] Could be SUSE-specific: Although I have all updates for the product installed, my version is older (Fri Jan 09 2009, as indicated in comment #1).
[Bug tree-optimization/61515] [4.10 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords|memory-hog | Blocks||47344 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Richard Biener from comment #7) (In reply to Richard Biener from comment #6) 4.9 at -Os takes 5min and ~2.2GB of ram (points-to takes 20%, DF 33%) trunk at -Os takes 15min and ~2.1GB of ram (dominator optimization takes 67%) trunk at -O1 takes 14min and ~2GB of ram (still DOM at 62%) So it seems that on trunk DOM regressed a lot. Confirmed as 4.10 regression. With -O1 -fno-tree-dominator-opts behavior is sane: df reaching defs: 86.99 (28%) usr 36.53 (66%) sys 124.04 (34%) wall 0 kB ( 0%) ggc tree PTA: 10.31 ( 3%) usr 0.15 ( 0%) sys 10.47 ( 3%) wall 1948 kB ( 0%) ggc tree SSA incremental: 98.24 (31%) usr 8.39 (15%) sys 106.63 (29%) wall 13570 kB ( 1%) ggc tree loop invariant motion: 14.46 ( 5%) usr 0.10 ( 0%) sys 14.54 ( 4%) wall 14421 kB ( 1%) ggc scev constant prop : 11.14 ( 4%) usr 0.02 ( 0%) sys 11.18 ( 3%) wall 28795 kB ( 2%) ggc TOTAL : 312.1055.72 368.92 1523092 kB 312.10user 55.84system 6:09.34elapsed 99%CPU (0avgtext+0avgdata 2073876maxresident)k 19664inputs+13880outputs (130major+38202143minor)pagefaults 0swaps (well, sane apart from DF and SSA incremental), but with DOM not disabled we get df reaching defs: 108.63 (11%) usr 8.83 (38%) sys 117.08 (12%) wall 0 kB ( 0%) ggc tree PTA: 10.51 ( 1%) usr 0.09 ( 0%) sys 10.60 ( 1%) wall 1948 kB ( 0%) ggc tree SSA incremental: 99.41 (10%) usr 9.17 (39%) sys 108.93 (11%) wall 13474 kB ( 1%) ggc dominator optimization : 617.08 (63%) usr 0.32 ( 1%) sys 618.97 (61%) wall 56878 kB ( 3%) ggc tree loop invariant motion: 2.15 ( 0%) usr 0.11 ( 0%) sys 2.25 ( 0%) wall 12012 kB ( 1%) ggc scev constant prop : 13.31 ( 1%) usr 0.02 ( 0%) sys 13.36 ( 1%) wall 28348 kB ( 2%) ggc TOTAL : 981.9823.25 1007.67 1625119 kB 981.98user 23.34system 16:47.79elapsed 99%CPU (0avgtext+0avgdata 2071112maxresident)k 184inputs+66416outputs (5major+18571554minor)pagefaults 0swaps (yes, this is with release checking) The testcase has _lots_ of loops (~11000), inside a big outer one, the maximum nesting isn't too big (10 from what I can see). SSA incremental is likely loop-closed SSA rewrite - didn't check. It should be possible to reduce the testcase somewhat if needed. Eventually the soulution for DOM is to disable the new path-based threading (if that turns out to be the issue) for -fno-expensive-optimizations (that is, optimize 2).
[Bug tree-optimization/61515] [4.10 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32952 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32952action=edit stripped down testcase Stripped down, now it starts to fall off a bit: tree SSA incremental: 1.48 ( 7%) usr 0.42 (33%) sys 1.96 ( 8%) wall 1882 kB ( 1%) ggc dominator optimization : 10.57 (50%) usr 0.03 ( 2%) sys 12.44 (48%) wall 6918 kB ( 4%) ggc TOTAL : 21.12 1.2725.67 191269 kB (just cutting in half three times from the bottom and appending } until it compiles again)
[Bug libstdc++/61532] [4.9/4.10 regression] make_signed and make_unsigned wchar_t have started failing in the libstdc++ testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61532 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Marc Glisse from comment #4) Writing signed wchar_t doesn't seem legal to me, and clang and intel warn or reject such code. Yeah, it's a GCC extension, and I thought I'd replaced the uses of it in the tests with something portable, but apparently not!
[Bug target/61535] SIGBUS in gen_group_rtx compiling 64-bit gcc.dg/vect/vect-singleton_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61535 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug target/61535] New: SIGBUS in gen_group_rtx compiling 64-bit gcc.dg/vect/vect-singleton_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61535 Bug ID: 61535 Summary: SIGBUS in gen_group_rtx compiling 64-bit gcc.dg/vect/vect-singleton_1.c Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: alalaw01 at gcc dot gnu.org, ebotcazou at gcc dot gnu.org Host: sparc-sun-solaris2.1[01] Target: sparc-sun-solaris2.1[01] Build: sparc-sun-solaris2.1[01] The new gcc.dg/vect/vect-singleton_1.c test FAILs on 64-bit Solaris 10 and 11/SPARC: FAIL: gcc.dg/vect/vect-singleton_1.c (internal compiler error) FAIL: gcc.dg/vect/vect-singleton_1.c (test for excess errors) FAIL: gcc.dg/vect/vect-singleton_1.c -flto -ffat-lto-objects (internal compiler error) FAIL: gcc.dg/vect/vect-singleton_1.c -flto -ffat-lto-objects (test for excess errors) E.g. $ ./cc1 -fpreprocessed vect-singleton_1.i -quiet -m64 -o vect-singleton_1.s /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/vect-singleton_1.c: In function 'test_vadd_f32': /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/vect-singleton_1.c:30:91: internal compiler error: Bus Error TEST (float, float32x1_t, f32) ^ 0x7046bb crash_signal /vol/gcc/src/hg/trunk/local/gcc/toplev.c:337 0x41dca0 gen_group_rtx(rtx_def*) /vol/gcc/src/hg/trunk/local/gcc/expr.c:1598 0x4c87eb expand_function_start(tree_node*) /vol/gcc/src/hg/trunk/local/gcc/function.c:4787 0x338e13 execute /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:5692 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] gen_group_rtx (orig=0xfb4c0d90) at /vol/gcc/src/hg/trunk/local/gcc/expr.c:1598 1598 if (i) (gdb) where #0 gen_group_rtx (orig=0xfb4c0d90) at /vol/gcc/src/hg/trunk/local/gcc/expr.c:1598 #1 0x004c87ec in expand_function_start (subr=0xfb49c380) at /vol/gcc/src/hg/trunk/local/gcc/function.c:4787 #2 0x00338e14 in (anonymous namespace)::pass_expand::execute ( this=optimized out, fun=0xfb423248) at /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:5692 #3 0x00633c3c in execute_one_pass (pass=pass@entry=0x1014b40) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2180 #4 0x00634120 in execute_pass_list_1 (pass=0x1014b40, pass@entry=0x1012768) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2233 #5 0x00634188 in execute_pass_list (fn=0xfb423248, pass=0x1012768) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2244 #6 0x00362788 in expand_function (node=0xfb4a8380) at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1787 #7 0x003657d4 in output_in_order () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2019 #8 compile () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2260 #9 0x00365b04 in finalize_compilation_unit () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2342 #10 0x001fb80c in c_write_global_declarations () at /vol/gcc/src/hg/trunk/local/gcc/c/c-decl.c:10452 #11 0x0070477c in compile_file () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:562 #12 0x00706cd0 in do_compile () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1918 #13 toplev_main (argc=7, argv=0xffbff484) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1994 #14 0x001dbd04 in _start () Running again with display/i $pc, one sees there's an unaligned access: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] gen_group_rtx (orig=0xfb4c0d90) at /vol/gcc/src/hg/trunk/local/gcc/expr.c:1598 1598 if (i) 1: x/i $pc = 0x41dca0 gen_group_rtx(rtx_def*)+36: ld [ %g3 + 8 ], %g3 (gdb) p/x $g3 $2 = 0xafafafaf truss shows Incurred fault #5, FLTACCESS %pc = 0x0041DCA0 siginfo: SIGBUS BUS_ADRALN addr=0xAFAFAFB7 Received signal #10, SIGBUS [caught] siginfo: SIGBUS BUS_ADRALN addr=0xAFAFAFB7 Rainer
[Bug target/61535] SIGBUS in gen_group_rtx compiling 64-bit gcc.dg/vect/vect-singleton_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61535 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org --- Created attachment 32953 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32953action=edit preprocessed input
[Bug tree-optimization/61536] New: [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 Bug ID: 61536 Summary: [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ramana at gcc dot gnu.org rev: 211358 https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg00821.html rev: 211354 https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg00803.html Test suite differences in g++ , libstdc++ with link time failures that look like FAIL: g++.dg/opt/typeinfo1.C -std=gnu++1y (test for excess errors) Excess errors: typeinfo1.C:(.text+0x18): undefined reference to `std::type_info::operator==(std::type_info const) const' typeinfo1.C:(.text.startup+0x20): undefined reference to `std::type_info::operator==(std::type_info const) const' typeinfo1.C:(.text.startup+0x44): undefined reference to `std::type_info::operator==(std::type_info const) const'
Admissions Open for B.Tech, M.Tech,MCA,MBA..Apply now
Hello Professionals, Greetings from ISMS. MBA,EMBA,BBA,Btech, Mtech,Diploma ,B.Com any degree from recognized University, GOOD NEWS! - For working Professionals as well as for fresher. Have a Btech, Mtech,Diploma ,MBA Masters Certification along, without affecting your current employment study. Global 100% Placement Assistance. GIVE US AN OPPORTUNITY TO MAKE YOUR CAREER: Please reply to this mail providing following details to obtain detail information about our Institute, Course, Exams etc. Name: Contact : Email Id : Course of Interest: Specialization: Qualification: Work Experience: City: State: Country: When you're ready to make the time, my help is just a phone call or e-mail away. With your success in mind, For ISMS Indian School of Management Studies, Alzira :- +91 9769085109 Email :- alz...@ismsedu.com Website :- http://www.ismseducations.com/
[Bug tree-optimization/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||link-failure Target||arm-none-linux-gnueabihf Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-17 Known to work||4.8.0, 4.8.1, 4.8.2, 4.8.3, ||4.9.0 Target Milestone|--- |4.10.0 Ever confirmed|0 |1
[Bug tree-optimization/61515] [4.10 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
All time is spent in invalidate_equivalencies.
/* A new value has been assigned to LHS. If necessary, invalidate any
equivalences that are no longer valid. */
static void
invalidate_equivalences (tree lhs, vectree *stack)
{
for (unsigned int i = 1; i num_ssa_names; i++)
if (ssa_name (i) SSA_NAME_VALUE (ssa_name (i)) == lhs)
record_temporary_equivalence (ssa_name (i), NULL_TREE, stack);
if (SSA_NAME_VALUE (lhs))
record_temporary_equivalence (lhs, NULL_TREE, stack);
}
this is obviously quadratic ... nearly all calls are from
static gimple
record_temporary_equivalences_from_stmts_at_dest (edge e,
vectree *stack,
tree (*simplify) (gimple,
gimple),
bool backedge_seen)
{
...
else if (backedge_seen)
invalidate_equivalences (gimple_get_lhs (stmt), stack);
}
return stmt;
}
I think you should record a bitmap of SSA names you need to invalidate
equivalences to and only at the end of this do a single scan over all SSA
names.
[Bug tree-optimization/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||paolo at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Linkage for this passes if --static is given on the command line which indicates this must be related to r211355-211357.
[Bug tree-optimization/61515] [4.9/4.10 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Target Milestone|4.10.0 |4.9.1 Summary|[4.10 Regression] Extremely |[4.9/4.10 Regression] |long compile time for |Extremely long compile time |generated code |for generated code Known to fail||4.9.1 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Same code on the 4.9 branch now.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo at gcc dot gnu.org | Component|tree-optimization |libstdc++ Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Pretty sure it's my change because typeinfo::before and typeinfo::operator== are special on some targets and I couldn't notice on x86-linux: #if !__GXX_TYPEINFO_EQUALITY_INLINE // In old abi, or when weak symbols are not supported, there can // be multiple instances of a type_info object for one // type. Uniqueness must use the _name value, not object address. bool before(const type_info __arg) const _GLIBCXX_NOEXCEPT; bool operator==(const type_info __arg) const _GLIBCXX_NOEXCEPT; however, I can get to this only next week, I'm traveling now, thus, if you like, feel free to revert for now my commit and close this bug.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- By the way, it would be useful if you could confirm the analysis, thus run nm on your runtime .so and double check that those two symbols are there, but t, instead of T.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #3) By the way, it would be useful if you could confirm the analysis, thus run nm on your runtime .so and double check that those two symbols are there, but t, instead of T. It certainly looks like your change broke it and I was trying to tighten the symbol regexps rather than reverting your changes completely but didn't fully succeed yet. (In reply to Paolo Carlini from comment #3) By the way, it would be useful if you could confirm the analysis, thus run nm on your runtime .so and double check that those two symbols are there, but t, instead of T. An nm comparison showed the difference of one symbol on libstdc++.so _ZNKSt9type_info6beforeERKS_ Sounds pretty much like that's the issue. If you're ok, I'm happy to currently just revert your change and we can deal with this later ?
[Bug sanitizer/61530] [4.10 Regression] segfault with asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530 --- Comment #3 from Yury Gribov y.gribov at samsung dot com --- Bootstrapped and regtested successfully on x64. Let's wait for Jakub's comments.
[Bug sanitizer/61530] [4.10 Regression] segfault with asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-17 Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- LGTM, just please use some other function name than error, error is a glibc function and it is unnecessary to override it with something unrelated. Also, patches should go to gcc-patches...
[Bug middle-end/61268] [4.10 regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61268 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|sparc-sun-solaris2.11 |sparc-sun-solaris2.1[01] CC||rsandifo at gcc dot gnu.org Host|sparc-sun-solaris2.11 |sparc-sun-solaris2.1[01] Build|sparc-sun-solaris2.11 |sparc-sun-solaris2.1[01] --- Comment #1 from Rainer Orth ro at gcc dot gnu.org --- Richard, a reghunt has confirmed that this regression was caused by this patch: 2014-05-17 Richard Sandiford rdsandif...@googlemail.com * emit-rtl.h (replace_equiv_address, replace_equiv_address_nv): Add an inplace argument. Store the new address in the original MEM when true. * emit-rtl.c (change_address_1): Likewise. (adjust_address_1, adjust_automodify_address_1, offset_address): Update accordingly. * rtl.h (plus_constant): Add an inplace argument. * explow.c (plus_constant): Likewise. Try to reuse the original PLUS when true. Avoid generating (plus X (const_int 0)). * function.c (instantiate_virtual_regs_in_rtx): Adjust the PLUS in-place. Pass true to plus_constant. (instantiate_virtual_regs_in_insn): Pass true to replace_equiv_address. I'm attaching the preprocessed testcase. The failure can be reproduced with cc1 -fpreprocessed limits-fndefn.i -quiet -g -O3 -o limits-fndefn.s Haven't tried in a cross compiler, though. Rainer
[Bug middle-end/61268] [4.10 regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61268 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org --- Created attachment 32954 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32954action=edit preprocessed input
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks. Before reverting the whole thing, please see if something like the patchlet I'm going to attach works for you. It should.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Created attachment 32955 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32955action=edit Draft
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #7 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #6) Created attachment 32955 [details] Draft I see other failures that include operator std::type_info::operator!= , so I'll see how to extend this if it fixes the basic issues. ZNKSt9type_infone* (In reply to Paolo Carlini from comment #6) Created attachment 32955 [details] Draft
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|NEW CC|hubicka at gcc dot gnu.org | --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Uhmm, we aren't actually checking the arm-linux ABI in libstc++/config, thus if you are missing operator!=, which is inline for all targets (and not exported for all the targets for which we check the ABI), I'm afraid all the bets are off: before my changes you may have relied on *any* inline symbol, elsewhere too. I would then recommend reverting for now my changes and closing this bug. Thanks.
[Bug target/61533] gcc.target/i386/fuse-caller-save.c FAILs on 64-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61533 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Rainer Orth from comment #1) Created attachment 32950 [details] assembler output The test assumes that frame pointer is omitted. It passes indeed with -fomit-frame-pointer added on both i386-pc-solaris2.11 and x86_64-unknown-linux-gnu. I suppose the patch is ok then? Rainer
[Bug target/61483] [AArch64] builtin va_start incorrectly initializes the field of va_list for incoming unnamed arguments on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61483
--- Comment #2 from Yufeng Zhang yufeng at gcc dot gnu.org ---
Author: yufeng
Date: Tue Jun 17 13:50:50 2014
New Revision: 211739
URL: https://gcc.gnu.org/viewcvs?rev=211739root=gccview=rev
Log:
gcc/
PR target/61483
* config/aarch64/aarch64.c (aarch64_layout_arg): Add new local
variable 'size'; calculate 'size' right in the front; use
'size' to compute 'nregs' (when 'allocate_ncrn != 0') and
pcum-aapcs_stack_words.
gcc/testsuite/
PR target/61483
* gcc.target/aarch64/aapcs64/type-def.h (struct hfa_fx2_t): New type.
* gcc.target/aarch64/aapcs64/va_arg-13.c: New test.
* gcc.target/aarch64/aapcs64/va_arg-14.c: Ditto.
* gcc.target/aarch64/aapcs64/va_arg-15.c: Ditto.
Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-13.c
- copied unchanged from r211733,
trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-13.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-14.c
- copied unchanged from r211733,
trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-14.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-15.c
- copied unchanged from r211733,
trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-15.c
Modified:
branches/gcc-4_9-branch/ (props changed)
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/aarch64/aarch64.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/type-def.h
branches/gcc-4_9-branch/libjava/classpath/ (props changed)
Propchange: branches/gcc-4_9-branch/
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_9-branch/libjava/classpath/
('svn:mergeinfo' modified)
[Bug c++/61537] New: template parameter lists wrongly detected on struct or class keyword on parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61537
Bug ID: 61537
Summary: template parameter lists wrongly detected on struct
or class keyword on parameters
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexander.adam at informatik dot tu-chemnitz.de
Created attachment 32956
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32956action=edit
sample code
When I define a template method outside of its template class declaration, it
cannot use the class or struct keyword on normal parameters.
This worked up to gcc 4.8. If I remove the struct or class keyword, everything
works fine again. I tried -std=c++98 without success.
If I write the definition inside the class Base { ... }; it also works.
When I try to compile the code (see attachment), I get the following error:
$ g++ main.cc
main.cc:17:38: error: too many template-parameter-lists
void BaseT::do_sth(S param, struct Dummy) // not working
^
main.cc:17:6: error: prototype for ‘void BaseT::do_sth(S, int)’ does not
match any in class ‘BaseT’
void BaseT::do_sth(S param, struct Dummy) // not working
^
main.cc:11:18: error: candidate is: templateclass T templateclass S void
BaseT::do_sth(S, Dummy)
void do_sth(S param, struct Dummy dummy);
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.0-6'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.0 (Debian 4.9.0-6)
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- Well, up to you really: maybe operator!= is special for you because it just thinly wraps operator== which is exported for you. If adding back *only* that additional export under the macro works, all your tests are fine, it would be great. Otherwise, just revert. Sorry again for the breakage.
[Bug target/61533] gcc.target/i386/fuse-caller-save.c FAILs on 64-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61533 --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to r...@cebitec.uni-bielefeld.de from comment #3) The test assumes that frame pointer is omitted. It passes indeed with -fomit-frame-pointer added on both i386-pc-solaris2.11 and x86_64-unknown-linux-gnu. I suppose the patch is ok then? Yes, I think that -fomit-frame-pointer should be added unconditionally to the dg-options. Patch is preapproved for mainline SVN.
[Bug c++/61531] Optimizer completely removes some bitset code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61531 Ulrich Windl Ulrich.Windl at rz dot uni-regensburg.de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Ulrich Windl Ulrich.Windl at rz dot uni-regensburg.de --- As Richard Biener found out (and told me offline), the effect observed is not a gcc issue, but a gdb issue (gdb 7.5.1 from SUSE): While objdump -d displays the correct assembly code, gdb's disassemble main also does, but gdb's disassemble /m main does not: It leaves the impression that main() is just an empty routine. Sorry for causing trouble!
[Bug target/61533] gcc.target/i386/fuse-caller-save.c FAILs on 64-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61533 --- Comment #5 from Rainer Orth ro at gcc dot gnu.org --- Author: ro Date: Tue Jun 17 13:58:11 2014 New Revision: 211740 URL: https://gcc.gnu.org/viewcvs?rev=211740root=gccview=rev Log: Compile gcc.target/i386/fuse-caller-save.c with -fomit-frame-pointer (PR target/61533) PR target/61533 * gcc.target/i386/fuse-caller-save.c: Add -fomit-frame-pointer to dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
[Bug middle-end/61268] [4.10 regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61268 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||https://gcc.gnu.org/ml/gcc- ||patches/2014-06/msg01357.ht ||ml Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #3 from Rainer Orth ro at gcc dot gnu.org --- Fixed for 4.10.0.
[Bug middle-end/61268] [4.10 regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61268 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW URL|https://gcc.gnu.org/ml/gcc- | |patches/2014-06/msg01357.ht | |ml | Last reconfirmed||2014-06-17 Resolution|FIXED |--- Assignee|ro at gcc dot gnu.org |unassigned at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Rainer Orth ro at gcc dot gnu.org --- Sorry, wrong PR.
[Bug target/61533] gcc.target/i386/fuse-caller-save.c FAILs on 64-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61533 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||https://gcc.gnu.org/ml/gcc- ||patches/2014-06/msg01357.ht ||ml Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #6 from Rainer Orth ro at gcc dot gnu.org --- Fixed for 4.10.0.
[Bug web/60119] Bugzilla URLs don't work with https.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60119 Gerald Pfeifer gerald at pfeifer dot com changed: What|Removed |Added CC||gerald at pfeifer dot com Resolution|INVALID |FIXED --- Comment #4 from Gerald Pfeifer gerald at pfeifer dot com --- Now they do. :-) I just verified that https://gcc.gnu.org/PR60119 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60119 work and show this very bug in an act of self reference. :-)
[Bug target/61483] [AArch64] builtin va_start incorrectly initializes the field of va_list for incoming unnamed arguments on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61483
--- Comment #3 from Yufeng Zhang yufeng at gcc dot gnu.org ---
Author: yufeng
Date: Tue Jun 17 14:15:03 2014
New Revision: 211741
URL: https://gcc.gnu.org/viewcvs?rev=211741root=gccview=rev
Log:
gcc/
PR target/61483
* config/aarch64/aarch64.c (aarch64_layout_arg): Add new local
variable 'size'; calculate 'size' right in the front; use
'size' to compute 'nregs' (when 'allocate_ncrn != 0') and
pcum-aapcs_stack_words.
gcc/testsuite/
PR target/61483
* gcc.target/aarch64/aapcs64/type-def.h (struct hfa_fx2_t): New type.
* gcc.target/aarch64/aapcs64/va_arg-13.c: New test.
* gcc.target/aarch64/aapcs64/va_arg-14.c: Ditto.
* gcc.target/aarch64/aapcs64/va_arg-15.c: Ditto.
Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-13.c
- copied unchanged from r211733,
trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-13.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-14.c
- copied unchanged from r211733,
trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-14.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-15.c
- copied unchanged from r211733,
trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-15.c
Modified:
branches/gcc-4_8-branch/ (props changed)
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/aarch64/aarch64.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/type-def.h
branches/gcc-4_8-branch/libjava/classpath/ (props changed)
Propchange: branches/gcc-4_8-branch/
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_8-branch/libjava/classpath/
('svn:mergeinfo' modified)
[Bug target/61483] [AArch64] builtin va_start incorrectly initializes the field of va_list for incoming unnamed arguments on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61483 Yufeng Zhang yufeng at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.9.1 |4.8.4 --- Comment #4 from Yufeng Zhang yufeng at gcc dot gnu.org --- Have fixed the issue in trunk 211733, and backport to 4.9 and 4.8 branches (211739 and 211741).
[Bug rtl-optimization/61509] GCC miscompilation on ARM during RTL optimization when compiled with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61509 --- Comment #7 from William King quentusrex at gmail dot com --- While I haven't had a chance to run through more than a handful of call scenarios, building FreeSWITCH on the Raspberry Pi with GCC 4.9.0 does not have the same problem.
[Bug go/61498] [4.10 regression] Many 64-bit Go tests SEGV in scanblock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61498 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #2 from Ian Lance Taylor ian at airs dot com --- Should be fixed now, I hope. Indeed, SPARC results look good again (expect for PR ipa/61495 when using gas). Thanks. Rainer
[Bug c/61520] False warning: array subscript is below array bounds (-Warray-bounds -O -ftree-vrp -funroll-loops)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61520
--- Comment #1 from Sergei Golubchik vuvova at gmail dot com ---
A slightly modified version:
static const int powers10[]= { 0, 1, 10, 100 };
int remove_leading_zeroes(unsigned int decimals, unsigned int var)
{
decimals%= 2;
while (var powers10[decimals--]) ;
return decimals;
}
assembly:
remove_leading_zeroes:
andl$1, %edi
movl%edi, %edx
leal-1(%rdi), %eax
cmplpowers10(,%rdx,4), %esi
jae .L2
movl%eax, %ecx
leal-2(%rdi), %edx
cmplpowers10(,%rcx,4), %esi
movl%edx, %eax
jae .L2
leal-3(%rdi), %eax
subl$4, %edi
cmplpowers10(,%rdx,4), %esi
cmovb %edi, %eax
.L2:
rep ret
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #10 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #9) Well, up to you really: maybe operator!= is special for you because it just thinly wraps operator== which is exported for you. If adding back *only* that additional export under the macro works, all your tests are fine, it would be great. Otherwise, just revert. Sorry again for the breakage. I'll play with it and see what else comes out of it. thanks for the prompt response and the help here. Ramana
[Bug sanitizer/61530] [4.10 Regression] segfault with asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530 Yuri Gribov tetra2005 at gmail dot com changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #5 from Yuri Gribov tetra2005 at gmail dot com --- Actually the fix may not handle unaligned addresses properly. I think we should rather stick with start and end bytes for memory regions in builtins. What's your opinion?
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #2) Pretty sure it's my change because typeinfo::before and typeinfo::operator== are special on some targets and I couldn't notice on x86-linux: #if !__GXX_TYPEINFO_EQUALITY_INLINE // In old abi, or when weak symbols are not supported, there can // be multiple instances of a type_info object for one // type. Uniqueness must use the _name value, not object address. bool before(const type_info __arg) const _GLIBCXX_NOEXCEPT; bool operator==(const type_info __arg) const _GLIBCXX_NOEXCEPT; Doh ! And the comment above that actually refers to ARM EABI systems which includes Linux. however, I can get to this only next week, I'm traveling now, thus, if you like, feel free to revert for now my commit and close this bug.
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 --- Comment #6 from Eelis gcc-bugzilla at contacts dot eelis.net --- Clang's libc++ (which gives the expected result) might be another source of inspiration.
[Bug c++/61538] New: g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
Bug ID: 61538
Summary: g++ compiled binary, linked to glibc libpthread, hangs
on SGI MIPS R1x000 systems on Linux
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kumba at gentoo dot org
CC: toolchain at gentoo dot org
Host: mips-unknown-linux-gnu
Target: mips-unknown-linux-gnu
Build: mips-unknown-linux-gnu
I appear to have run into a regression in g++/libstdc++, starting with at least
4.8.2, where a simple binary built by g++ and linked to glibc-2.19's libpthread
causes the binary to hang on a kernel futex() syscall (syscall #4328 in o32
ABI) until killed or interrupted w/ ctrl-C.
I have replicated this problem in an o32 environment, as well as an n32 and n64
multilib environment.
So far, the identified trigger conditions are:
- Must be an R1-based SGI system (SGI O2 w/ RM7000 does not reproduce)
- Must compile testcase w/ 'g++' (compiling with 'gcc' works fine)
- Must link w/ -lpthread from at least glibc-2.19 (doesn't seem to trigger on
older versions).
- Must be gcc-4.8.2 or greater (gcc-4.6.4 and gcc-4.7.3 both work fine).
I ran into this while getting Linux support for the SGI Octane operational
again and rebuilding a ~5-year old Gentoo userland on the machine. I at first
thought it was a problem with old libs still living on the system that I
haven't purged just yet, but I have been able to recreate the problem in a
clean n32/n64 Gentoo stage3 chroot.
The Octane in particular has an R14000 CPU module installed right now, though I
can also trigger the condition on an R12000 CPU module as well. I don't have
any other working R1x000-capable SGI hardware available at the moment to test
this on, so this could still be a quirky bug in the Octane's kernel, but I
believe this is less likely since I can trigger the problem only with specific
versions of libstdc++.
Sample C code that I can use to trigger the issue with from Python-3.3.5's
configure script (where it etsts for thread support):
# cat conftest.c
void foo();int main(){foo();}void foo(){}
Compiler command line:
# g++ -o conftest conftest.c -lpthread
# ./conftest
hang
Overriding LD_PRELOAD to use libstdc++ from an earlier gcc:
# LD_PRELOAD=/usr/lib/gcc/mips-unknown-linux-gnu/4.9.0/libstdc++.so.6
./conftest
hang
# LD_PRELOAD=/usr/lib/gcc/mips-unknown-linux-gnu/4.8.2/libstdc++.so.6
./conftest
hang
# LD_PRELOAD=/usr/lib/gcc/mips-unknown-linux-gnu/4.7.3/libstdc++.so.6
./conftest
returns
I don't have much more than that at the moment, but let me know if there are
specific command outputs needed to further determine what the cause of this
problem is.
[Bug c++/61539] New: ICE: in unify_one_argument, at cp/pt.c:15465 validate(value_store, new_tokens, (T*)0, 0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61539
Bug ID: 61539
Summary: ICE: in unify_one_argument, at cp/pt.c:15465
validate(value_store, new_tokens, (T*)0, 0);
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ilja.j.honkonen at nasa dot gov
Created attachment 32957
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32957action=edit
Compressed eigen.ii (original is 3.9 MB)
Tried to create a custom validator for boost::program_options
(http://www.boost.org/doc/libs/1_55_0/doc/html/program_options/howto.html#idp163429032)
for an Eigen type (http://eigen.tuxfamily.org/dox/classEigen_1_1Matrix.html)
using variadic templates. This seems to work:
namespace Eigen {
template
class Scalar,
int Rows,
int Cols,
int Options,
int MaxRows,
int MaxCols
void validate(
boost::any value,
const std::vectorstd::string all_parsed,
Eigen::Matrix
Scalar,
Rows,
Cols,
Options,
MaxRows,
MaxCols
*,
long
) {
...
but the variadic version causes an ICE:
namespace Eigen {
template class... T void validate(
boost::any value,
const std::vectorstd::string all_parsed,
Eigen::MatrixT...*,
long
) {
...
Compile command and output:
g++-mp-4.8 -v -save-temps -I source -std=c++11 -W -Wall -Wextra -pedantic
-O3 -I /opt/local/include/eigen3 -I /opt/local/include -L
/opt/local/lib -lboost_coroutine-mt -lboost_system-mt -lboost_random-mt
-lboost_program_options-mt tests/program_options/eigen.cpp -o
tests/program_options/eigen.exe
Using built-in specs.
COLLECT_GCC=g++-mp-4.8
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin13/4.8.2/lto-wrapper
Target: x86_64-apple-darwin13
Configured with:
/opt/local/var/macports/build/_opt_mports_dports_lang_gcc48/gcc48/work/gcc-4.8.2/configure
--prefix=/opt/local --build=x86_64-apple-darwin13
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.8
--with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-cloog=/opt/local
--enable-cloog-backend=isl --disable-cloog-version-check
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc48 4.8.2_0'
Thread model: posix
gcc version 4.8.2 (MacPorts gcc48 4.8.2_0)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.2' '-v' '-save-temps' '-I'
'source' '-std=c++11' '-Wall' '-Wextra' '-Wpedantic' '-O3' '-I'
'/opt/local/include/eigen3' '-I' '/opt/local/include' '-L/opt/local/lib' '-o'
'tests/program_options/eigen.exe' '-shared-libgcc' '-mtune=core2'
/opt/local/libexec/gcc/x86_64-apple-darwin13/4.8.2/cc1plus -E -quiet -v -I
source -I /opt/local/include/eigen3 -I /opt/local/include -D__DYNAMIC__
tests/program_options/eigen.cpp -fPIC -mmacosx-version-min=10.9.2 -mtune=core2
-std=c++11 -Wall -Wextra -Wpedantic -O3 -fpch-preprocess -o eigen.ii
ignoring nonexistent directory
/opt/local/lib/gcc48/gcc/x86_64-apple-darwin13/4.8.2/../../../../../x86_64-apple-darwin13/include
ignoring duplicate directory /opt/local/include
as it is a non-system directory that duplicates a system directory
#include ... search starts here:
#include ... search starts here:
source
/opt/local/include/eigen3
/opt/local/include/gcc48/c++/
/opt/local/include/gcc48/c++//x86_64-apple-darwin13
/opt/local/include/gcc48/c++//backward
/opt/local/lib/gcc48/gcc/x86_64-apple-darwin13/4.8.2/include
/opt/local/include
/opt/local/lib/gcc48/gcc/x86_64-apple-darwin13/4.8.2/include-fixed
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.2' '-v' '-save-temps' '-I'
'source' '-std=c++11' '-Wall' '-Wextra' '-Wpedantic' '-O3' '-I'
'/opt/local/include/eigen3' '-I' '/opt/local/include' '-L/opt/local/lib' '-o'
'tests/program_options/eigen.exe' '-shared-libgcc' '-mtune=core2'
/opt/local/libexec/gcc/x86_64-apple-darwin13/4.8.2/cc1plus -fpreprocessed
eigen.ii -fPIC -quiet -dumpbase eigen.cpp -mmacosx-version-min=10.9.2
-mtune=core2 -auxbase eigen -O3 -Wall -Wextra -Wpedantic -std=c++11 -version -o
eigen.s
GNU C++ (MacPorts gcc48 4.8.2_0) version 4.8.2 (x86_64-apple-darwin13)
compiled by GNU C version 4.8.2, GMP version 5.1.2, MPFR version 3.1.1-p2,
MPC version 1.0.1
warning:
[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #1 from Joshua Kinard kumba at gentoo dot org --- Forgot the gcc -v info: gcc -v Using built-in specs. COLLECT_GCC=/usr/mips-unknown-linux-gnu/gcc-bin/4.9.0/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/mips-unknown-linux-gnu/4.9.0/lto-wrapper Target: mips-unknown-linux-gnu Configured with: /usr/obj/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/configure --host=mips-unknown-linux-gnu --build=mips-unknown-linux-gnu --prefix=/usr --bindir=/usr/mips-unknown-linux-gnu/gcc-bin/4.9.0 --includedir=/usr/lib/gcc/mips-unknown-linux-gnu/4.9.0/include --datadir=/usr/share/gcc-data/mips-unknown-linux-gnu/4.9.0 --mandir=/usr/share/gcc-data/mips-unknown-linux-gnu/4.9.0/man --infodir=/usr/share/gcc-data/mips-unknown-linux-gnu/4.9.0/info --with-gxx-include-dir=/usr/lib/gcc/mips-unknown-linux-gnu/4.9.0/include/g++-v4 --with-python-dir=/share/gcc-data/mips-unknown-linux-gnu/4.9.0/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.0 p1.0, pie-0.6.0' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point --with-abi= --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath --enable-lto --without-cloog Thread model: posix gcc version 4.9.0 (Gentoo 4.9.0 p1.0, pie-0.6.0)
[Bug tree-optimization/61515] [4.9/4.10 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #12 from Jeffrey A. Law law at redhat dot com --- Fundamentally we don't have a way to know what equivalences we need to invalidate. Invalidation is, umm, painful. The question in my mind is why are we getting so many invalidations to start with. That's the first thing to look at. Honestly though, I really wonder if handling backedges is worth the effort, even though it's important for one benchmark.
[Bug middle-end/56964] ICE with -fno-sync-libcalls when target lacks atomic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56964 rwahl at gmx dot de changed: What|Removed |Added CC||rwahl at gmx dot de --- Comment #1 from rwahl at gmx dot de --- I can reproduce this too when building multilib cross compiler: cat gcc-4.8.3/build-arm-pp-linux-uclibcgnueabi/arm-pp-linux-uclibcgnueabi/libatomic/config.log ... configure:12468: checking for __atomic_test_and_set for size 1 configure:12487: /home/nb/builds/toolchain-010/tmp_cross/build/gcc-4.8.3/build-arm-pp-linux-uclibcgnueabi/./gcc/xgcc -B/home/nb/builds/toolchain-010/tmp_cross/build/gcc-4.8.3/build-arm-pp-linux-uclibcgnueabi/./gcc/ -B/home/nb/builds/toolchain-010/tmp_cross/build_root_2//bin/ -B/home/nb/builds/toolchain-010/tmp_cross/build_root_2//lib/ -isystem /home/nb/builds/toolchain-010/tmp_cross/build_root_2//arm-pp-linux-uclibcgnueabi/include --sysroot=/home/nb/builds/toolchain-010/tmp_cross/build_root_2//arm-pp-linux-uclibcgnueabi -o conftest -Os -fno-sync-libcallsconftest.c 5 conftest.c: In function 'main': conftest.c:40:27: internal compiler error: Segmentation fault __atomic_test_and_set(x, 0); ^ Please submit a full bug report, ... Under different build circumstances the build of conftest.c even just hangs which was my original problem I was trying to solve and it took me half a day to dig around and find that bug report.
[Bug c++/61539] [4.8/4.9/4.10 Regression] ICE: in unify_one_argument, at cp/pt.c:15465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61539
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-06-17
CC||trippels at gcc dot gnu.org
Target Milestone|--- |4.8.5
Summary|ICE: in unify_one_argument, |[4.8/4.9/4.10 Regression]
|at cp/pt.c:15465|ICE: in unify_one_argument,
|validate(value_store, |at cp/pt.c:15465
|new_tokens, (T*)0, 0); |
Ever confirmed|0 |1
Known to fail||4.10.0, 4.8.3, 4.9.0
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Confirmed.
markus@x4 tmp % cat test.ii
template typename _CharT class A;
template typename class B;
template class charT class C;
template class Cchar
{
virtual void xparse (int , const BAchar ) const;
};
template class T, class charT = char class G : CcharT
{
public:
G (void *) {}
void default_value (const T );
void xparse (int , const BAcharT ) const;
};
template class T, class charT
void validate (int , const BAcharT , T *, int);
template class T, class charT
void GT, charT::xparse (int p1, const BAcharT p2) const
{
validate (p1, p2, (T *)0, 0);
}
template class T GT *value (T *) { GT *r = new GT(0); }
namespace Eigen
{
template typename T struct D;
template typename, int, int, int = 0 ?: 0, int = 0, int = 0 class F;
template typename _Scalar, int _Rows, int _Cols, int _Options, int _MaxRows,
int _MaxCols
struct DF_Scalar, _Rows, _Cols, _Options, _MaxRows, _MaxCols
{
typedef _Scalar Scalar;
};
template typename, int, int, int, int, int _MaxCols class F
{
public:
typedef typename Eigen::DF::Scalar Scalar;
F (const Scalar , const Scalar , const Scalar );
};
template class... T
void validate (int , const BAchar , Eigen::FT... *);
}
int main (int, char *[])
{
Eigen::Fdouble, 3, 1 a (0, 0, 0);
value (a)-default_value (Eigen::Fdouble, 3, 1(0, 0, 0));
}
markus@x4 tmp % clang++ -w -c -std=c++11 test.ii
markus@x4 tmp % g++ -c -std=c++11 test.ii
test.ii: In substitution of ‘templateclass ... T void Eigen::validate(int,
const BAchar , Eigen::FT ...*) [with T = missing]’:
test.ii:20:30: required from ‘void GT, charT::xparse(int, const BAcharT
) const [with T = Eigen::Fdouble, 3, 1; charT = char]’
test.ii:46:1: required from here
test.ii:20:30: internal compiler error: in unify_one_argument, at cp/pt.c:16504
validate (p1, p2, (T *)0, 0);
^
0x5e66fc unify_one_argument
../../gcc/gcc/cp/pt.c:16503
0x5e7562 unify_pack_expansion
../../gcc/gcc/cp/pt.c:17322
0x5e5b6b unify
../../gcc/gcc/cp/pt.c:18077
0x4fccc7 try_class_unification
../../gcc/gcc/cp/pt.c:17084
0x5e2bff unify
../../gcc/gcc/cp/pt.c:18105
0x5e2dec unify
../../gcc/gcc/cp/pt.c:17973
0x5e64f7 unify_one_argument
../../gcc/gcc/cp/pt.c:16509
0x5e894c type_unification_real
../../gcc/gcc/cp/pt.c:16581
0x5f2973 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:16019
0x55e9d1 add_template_candidate_real
../../gcc/gcc/cp/call.c:3008
0x55f4ac add_template_candidate
../../gcc/gcc/cp/call.c:3105
0x55f4ac add_candidates
../../gcc/gcc/cp/call.c:5233
0x561cf9 perform_overload_resolution
../../gcc/gcc/cp/call.c:3953
0x56430a build_new_function_call(tree_node*, vectree_node*, va_gc,
vl_embed**, bool, int)
../../gcc/gcc/cp/call.c:4030
0x6e1d74 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2365
0x5b7446 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14958
0x5c7a4e tsubst_expr
../../gcc/gcc/cp/pt.c:14137
0x5c8455 tsubst_expr
../../gcc/gcc/cp/pt.c:13563
0x5c8a37 tsubst_expr
../../gcc/gcc/cp/pt.c:13735
0x5c55ae instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:20047
Please submit a full bug report,
[Bug bootstrap/61388] [4.8 Regression] linux/microblaze fails to build: undefined machine-specific constraint at this point: Q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61388 --- Comment #5 from Rose Garcia rose.garcia-eggl2fk at yopmail dot com --- (In reply to Michael Eager from comment #3) What sources are you building? GCC 4.8.3 release tarball, as already mentioned. When I build --target=microblaze-xilinx-elf from the current sources, I see the same warning message for microblaze.md that you list. I do not see the other errors. Constraint Q is defined in constraints.md. others building gcc 4.8.3 reported the same problem. the problem is that this patch entered the *stable* release series between 4.8.2 and 4.8.3, and apparently depends on changes from the 4.9.x devel branch. this patch reportedly fixes the problem: http://www.openadk.org/cgi-bin/gitweb.cgi?p=openadk.git;a=blob;f=toolchain/gcc/patches/4.8.3/miscompile.microblaze;h=d575054aa9a6b9c6081753289dcfc4b3e47c5af7;hb=HEAD
[Bug c++/61539] [4.8/4.9/4.10 Regression] ICE: in unify_one_argument, at cp/pt.c:15465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61539
--- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Another smaller testcase (clang rejects this):
markus@x4 tmp % cat foo.ii
template class class A;
template class Achar
{
virtual void m_fn1 (int , const int ) const;
};
template typename, int class B;
template class, class = int class C : Achar
{
public:
C (void *) {}
void m_fn1 (int , const int ) const;
};
CBdouble, 0 *a = new CBdouble, 0(0);
template class... T void validate (BT... *);
template class T, class charT
void CT, charT::m_fn1 (int , const int ) const
{
validate ((T *)0);
}
markus@x4 tmp % g++ -c -std=c++11 foo.ii
foo.ii: In substitution of ‘templateclass ... T void validate(BT ...*)
[with T = missing]’:
foo.ii:18:19: required from ‘void C template-parameter-1-1,
template-parameter-1-2 ::m_fn1(int, const int) const [with
template-parameter-1-1 = Bdouble, 0; template-parameter-1-2 = int]’
foo.ii:19:1: required from here
foo.ii:18:19: internal compiler error: in unify_one_argument, at cp/pt.c:16504
PR60942 looks like a dup.
[Bug ipa/61540] New: internal compiler error in try_make_edge_direct_virtual_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61540 Bug ID: 61540 Summary: internal compiler error in try_make_edge_direct_virtual_call Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: jamborm at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org Created attachment 32958 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32958action=edit Simple testcase $ ~/gcc/trunk/inst/bin/g++ pr.C -O3 -fno-early-inlining -S pr.C:38:1: internal compiler error: in try_make_edge_direct_virtual_call, at ipa-prop.c:3007 } ^ 0xa39460 try_make_edge_direct_virtual_call /home/mjambor/gcc/trunk/src/gcc/ipa-prop.c:3006 0xa39460 update_indirect_edges_after_inlining /home/mjambor/gcc/trunk/src/gcc/ipa-prop.c:3062 0xa39460 propagate_info_to_inlined_callees /home/mjambor/gcc/trunk/src/gcc/ipa-prop.c:3138 0xa38e1e propagate_info_to_inlined_callees /home/mjambor/gcc/trunk/src/gcc/ipa-prop.c:3142 0x10dd48c inline_call(cgraph_edge*, bool, veccgraph_edge*, va_heap, vl_ptr*, int*, bool, bool*) /home/mjambor/gcc/trunk/src/gcc/ipa-inline-transform.c:282 0x10da041 recursive_inlining /home/mjambor/gcc/trunk/src/gcc/ipa-inline.c:1401 0x10da041 inline_small_functions /home/mjambor/gcc/trunk/src/gcc/ipa-inline.c:1773 0x10da041 ipa_inline /home/mjambor/gcc/trunk/src/gcc/ipa-inline.c:2190 0x10da041 execute /home/mjambor/gcc/trunk/src/gcc/ipa-inline.c:2552 The testcase does invoke undefined behavior but the assert triggering this should emit a builtin_unreachable instead.
[Bug bootstrap/61388] [4.8 Regression] linux/microblaze fails to build: undefined machine-specific constraint at this point: Q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61388 --- Comment #6 from Rose Garcia rose.garcia-eggl2fk at yopmail dot com --- (In reply to Nagaraju Mekala from comment #4) I have checked it with 4.9.0 and it is working fine for me. we're not talking gcc 4.9.0 here. this is about gcc 4.8.3 release. please test that version.
[Bug bootstrap/61388] [4.8 Regression] linux/microblaze fails to build: undefined machine-specific constraint at this point: Q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61388 --- Comment #7 from Rose Garcia rose.garcia-eggl2fk at yopmail dot com --- (In reply to Rose Garcia from comment #5) (In reply to Michael Eager from comment #3) What sources are you building? GCC 4.8.3 release tarball, as already mentioned. actually i didnt mention it, but i entered it on VERSION fields in the bug report, and it's also noted in KNOWN TO WORK and KNOWN TO FAIL builds, so i assumed ppl would read that.
[Bug fortran/32630] [meta-bug] ISO C binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630 Bug 32630 depends on bug 37937, which changed state. Bug 37937 Summary: Bind(C) diagnostic when using c_double for COMPLEX variables https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37937 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
