[Bug rtl-optimization/58831] [4.7/4.8/4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58831 --- Comment #16 from Zhendong Su su at cs dot ucdavis.edu --- (In reply to Eric Botcazou from comment #15) Fixed everywhere (and twice to be really sure :-) Verified (also against the original tests). Thanks.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
--- Comment #19 from asmwarrior asmwarrior at gmail dot com ---
Hi, I see this bug happens at least in GCC 4.8.2 again. I'm using MinGW-Build
GCC 4.8.2 under Windows, and debug Codeblocks. I have a source code which have
something like:
void CompilerGCC::SetupEnvironment()
{
wxString currentPath;
}
But When I debug through lines using the step command, I see that the caret
still go back the the local variable definition of the line wxString
currentPath.
I tried the simple test code that Peter Thompson gives, but it works fine, So
it looks like this bug happens in a larger project not the simple one.
Currently I don't have much way to show you. When I see the disassembler code,
I see some call to destructor of wxString.
0x64B0CF81call 0x64b4f094 InfoWindow::Display(wxString const, wxString
const, unsigned int, unsigned int)
0x64B0CF86leaeax,[ebp-0x34]
0x64B0CF89movecx,eax
0x64B0CF8Bcall 0x64b5c090 wxString::~wxString()
0x64B0CF90leaeax,[ebp-0x38]
0x64B0CF93movecx,eax
0x64B0CF95call 0x64b5c090 wxString::~wxString()
0x64B0CF9Aleaeax,[ebp-0x30]
0x64B0CF9DmovDWORD PTR [esp],0x64b6bc70
0x64B0CFA4movecx,eax
When I run
info line *0x64B0CFDB
[debug]Line 801 of F:\cb_sf_git\trunk\src\plugins\compilergcc\compilergcc.cpp
starts at address 0x64b0cf9a CompilerGCC::SetupEnvironment()+3258 and ends at
0x64b0cfe0 CompilerGCC::SetupEnvironment()+3328.
[debug]F:\cb_sf_git\trunk\src\plugins\compilergcc\compilergcc.cpp:801:32074:beg:0x64b0cf9a
But it looks like this is not enough information I can show you, any suggest
how to see the incorrect line-code map? Thanks.
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #10 from Martin Husemann martin at netbsd dot org --- Matt Thomas suggested to go with the easy solution for now: protect the calls with MEM_P, i.e.: change the ! mode_dependent_address_p() in the bitfield patterns to (MEM_P(..) ! mode_dependent_address_p(...)) With this change, a NetBSD kernel can be compiled (but does not yet boot), and bootstrap goes way further along (will file another ticket for the next obstacle).
[Bug c++/58899] g++ seg faulted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58899 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-10-28 Ever confirmed|0 |1 Severity|major |normal --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Please, only a self-contained .ii, per the bug reporting instructions, thanks. Also please provide information about your compiler, target, etc: http://gcc.gnu.org/bugs/#report
[Bug target/58901] New: vax bootstrap fails on subreg reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901 Bug ID: 58901 Summary: vax bootstrap fails on subreg reload Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org Trying a native bootstrap on VAX fails when compiling libdecnumber with a failed assertion here: #0 0x0085637c in fancy_abort (file=0x8dae4d ../../gcc-4.8.2/gcc/emit-rtl.c, line=2019, function=0x8db1e3 change_address_1(rtx_def*, machine_mode, rtx_def*, int)::__FUNCTION__ change_address_1, 9285197, 2019, 9286115) at ../../gcc-4.8.2/gcc/diagnostic.c:1146 #1 0x00295470 in change_address_1 (memref=0x7ea2d560, mode=HImode, addr=0x7ea0fd2c, validate=1, 2124600672, 5, 2124479788, 1) at ../../gcc-4.8.2/gcc/emit-rtl.c:2019 #2 0x00295f54 in adjust_address_1 (memref=0x7ea2d560, mode=HImode, offset=0, validate=1, adjust_address=1, adjust_object=0, size=2, 2124600672, 5, 0, 1, 1, 0, 2) at ../../gcc-4.8.2/gcc/emit-rtl.c:2151 #3 0x002d1a06 in alter_subreg (xp=0x7f0e8bc8, final_p=true, 2131659720, 1) at ../../gcc-4.8.2/gcc/final.c:3072 #4 0x002d2231 in cleanup_subreg_operands (insn=0x7f2d6360, 2133680992) at ../../gcc-4.8.2/gcc/final.c:3018 #5 0x004e5810 in reload (first=0x7ea58620, global=1, 2124776992, 1) at ../../gcc-4.8.2/gcc/reload1.c:1240 #6 0x003dc5e2 in do_reload () at ../../gcc-4.8.2/gcc/ira.c:4679 #7 0x003dc7aa in rest_of_handle_reload () at ../../gcc-4.8.2/gcc/ira.c:4779 #8 0x00483bf5 in execute_one_pass (pass=0xc6fda4 pass_reload, 13041060) at ../../gcc-4.8.2/gcc/passes.c:2333 (gdb) p debug_rtx(memref) (mem/u/c:SI (plus:SI (mult:SI (reg/v:SI 0 %r0 [orig:81 count ] [81]) (const_int 4 [0x4])) (symbol_ref:SI (DECPOWERS) [flags 0x40] var_decl 0x7f22fe60 DECPOWERS)) [3 DECPOWERS S4 A32]) The invocation was: /usr/pkgobj/lang/gcc48/work/build/./prev-gcc/cc1 -quiet -v -I ../../gcc-4.8.2/libdecnumber -I . -I /usr/pkg/include -I /usr/include -I ../../gcc-4.8.2/libdecnumber -I . -I /usr/pkg/include -I /usr/include -iprefix /usr/pkgobj/lang/gcc48/work/build/prev-gcc/../lib/gcc/vax--netbsdelf/4.8.2/ -isystem /usr/pkgobj/lang/gcc48/work/build/./prev-gcc/include -isystem /usr/pkgobj/lang/gcc48/work/build/./prev-gcc/include-fixed -isystem /usr/pkg/gcc48/vax--netbsdelf/include -isystem /usr/pkg/gcc48/vax--netbsdelf/sys-include ../../gcc-4.8.2/libdecnumber/decNumber.c -fPIC -quiet -dumpbase decNumber.c -auxbase decNumber -g -gtoggle -O2 -Wextra -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wsuggest-attribute=format -Wcast-qual -Wpedantic -Wno-long-long -version -o /var/tmp//ccfituj1.s
[Bug tree-optimization/58902] New: small matrix multiplication non vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58902
Bug ID: 58902
Summary: small matrix multiplication non vectorized
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
in the following example
matmul and matmul2 do not vectorize
the manual unroll does
c++ -std=c++11 -Ofast -S m3x10.cc -march=corei7-avx -fopt-info-vec-all
gcc version 4.9.0 20131011 (experimental) [trunk revision 203426] (GCC)
cat m3x10.cc
const int nrow=3;
alignas(32) double tmp[nrow][10];
alignas(32) double param[nrow];
alignas(32) double frame[10];
void matmul() {
for (int j=0; jnrow; ++j)
for (int i=0; i10; ++i)
param[j] += tmp[j][i]*frame[i];
}
void matmul2() {
for (int j=0; jnrow; ++j) {
double s=0;
for (int i=0; i10; ++i)
s += tmp[j][i]*frame[i];
param[j] =s;
}
}
void matmul3() {
for (int i=0; i10; ++i) {
param[0] += tmp[0][i]*frame[i];
param[1] += tmp[1][i]*frame[i];
param[2] += tmp[2][i]*frame[i];
}
}
double vmul0() {
double s=0;
for (int i=0; i10; ++i)
s += tmp[0][i]*frame[i];
return s;
}
double vmul1() {
double s=0;
for (int i=0; i10; ++i)
s += tmp[1][i]*frame[i];
return s;
}
[Bug middle-end/58903] New: ICE: SIGSEGV in hash_table::find_slot_with_hash() with -O -fdevirtualize-speculatively
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58903 Bug ID: 58903 Summary: ICE: SIGSEGV in hash_table::find_slot_with_hash() with -O -fdevirtualize-speculatively Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 31099 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31099action=edit reduced testcase Compiler output: $ gcc -O -fdevirtualize-speculatively testcase.C testcase.C:12:1: internal compiler error: Segmentation fault } ^ 0xc23e6f crash_signal /mnt/svn/gcc-trunk/gcc/toplev.c:335 0xa4c221 hash_tableodr_hasher, xcallocator::find_slot_with_hash(tree_node const*, unsigned int, insert_option) /mnt/svn/gcc-trunk/gcc/hash-table.h:774 0xa49d0c get_odr_type(tree_node*, bool) /mnt/svn/gcc-trunk/gcc/ipa-devirt.c:402 0xa4b3d4 possible_polymorphic_call_targets(tree_node*, long, bool*, void**) /mnt/svn/gcc-trunk/gcc/ipa-devirt.c:798 0xa4b9c3 possible_polymorphic_call_targets /mnt/svn/gcc-trunk/gcc/ipa-utils.h:89 0xa4b9c3 ipa_devirt /mnt/svn/gcc-trunk/gcc/ipa-devirt.c:999 0xa4b9c3 execute /mnt/svn/gcc-trunk/gcc/ipa-devirt.c:1181 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r203876 - ICE
[Bug preprocessor/58887] Allow recursion in variadic macros?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887 --- Comment #6 from Max TenEyck Woodbury mtewoodbury at gmail dot com --- I have checked the code in libcpp. The __VA_ARG_COUNT__/__VA_ARGC__ implementation looks quite feasible. The heaviest impact looks to be new and revised error messages and their translation. I started to look at the possibility of doing actual recursion but ran out of steam temporarily. It might be necessary to copy hashnodes or, worse yet, add a field to the hashnode structure. Later...
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
--- Comment #20 from asmwarrior asmwarrior at gmail dot com ---
Hi, all. After the conversation on GDB IRC with GDB developer Jan Kratochvil, a
simple test code supplied by Jan in his bug report on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123#c0 can easily demonstrate
this issue in either GCC 4.8.2 or GCC 4.8.1.
class C {
public:
C() {}
~C() {}
int m() { return 0; }
};
/* 7 */ int main() {
/* 8 */ C a;
/* 9 */ C b;
/* 10 */ C c;
/* 11 */ return a.m() + b.m() + c.m();
/* 12 */ }
You will run next command back to line 10, and line 9 until go to the end of
the function main().
Note: the bug #58123 is another issue, Jan expected that the caret should go
back to line 8, but it is not.
[Bug debug/58123] [4.8/4.9 Regression] debug line not tracked for last autovariable dtor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123 asmwarrior asmwarrior at gmail dot com changed: What|Removed |Added CC||asmwarrior at gmail dot com --- Comment #3 from asmwarrior asmwarrior at gmail dot com --- @Jan Kratochvil This bug is also exists in GCC 4.8.1. BTW: Your test code can also reproduce the GCC bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951, I have add a comment there. Yuanhui Zhang
[Bug preprocessor/58887] Allow recursion in variadic macros?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887 --- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Sun, 27 Oct 2013, mtewoodbury at gmail dot com wrote: That has not always stopped you all in the past, but that is really neither We have plenty of experience dealing with the consequent problems of the old habit of adding extensions because they seemed like a good idea at the time (or because a feature was supported in some language other than C, and there used to be an idea that GNU C should support all features of GCC's internal representation that could be accessed from any language supported by GCC) without any real effort in designing them at the level of precise proposed standard text to specify the feature. Based on that experience, the bar for new extensions is much higher now. Unlike recursion, __VA_ARGC__ seems like something reasonably well-defined and in accordance with the spirit of the preprocessor and unlikely to be problematic as an extension - but as you note, there's already a separate bug for it.
[Bug preprocessor/58887] Allow recursion in variadic macros?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887 --- Comment #8 from joseph at codesourcery dot com joseph at codesourcery dot com --- (And for recursion, even specification at the level of standard text might leave something to be desired; I'd think specification at the level of X3J11/86-196, the algorithm GCC tries to follow regarding when a macro name generated in macro expansion can itself be expanded, would be desired as well. Not that I think recursion is appropriate to include in GCC's preprocessor unless it's standardized.)
[Bug c++/54485] g++ should diagnose default arguments in out-of-line definitions for template class member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54485 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01435.html
[Bug fortran/58904] New: ICE: accessing a component field of an unavailable type results in a seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58904 Bug ID: 58904 Summary: ICE: accessing a component field of an unavailable type results in a seg fault Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kimwooyoung at gmail dot com The following code causes gfortran 4.8.2 to die with a seg fault. (Ubuntu 12.10, intel64 (i.e., 64-bit x86) ) MODULE mymod CONTAINS TYPE(mytype) FUNCTION create_sort_range(b) result(r) INTEGER b r%b = b END FUNCTION create_sort_range END MODULE mymod The compiler produces the correct error message if the statement 'r%b = b' is commented out. $ gfortran -c repro.F90 f951: internal compiler error: Segmentation fault 0x869cbf crash_signal ../../gcc-4.8.2/gcc/toplev.c:332 0x555765 gfc_match_varspec(gfc_expr*, int, bool, bool) ../../gcc-4.8.2/gcc/fortran/primary.c:1944 0x555d31 match_variable ../../gcc-4.8.2/gcc/fortran/primary.c:3304 0x537eb9 gfc_match(char const*, ...) ../../gcc-4.8.2/gcc/fortran/match.c:1115 0x53925c gfc_match_assignment() ../../gcc-4.8.2/gcc/fortran/match.c:1292 0x54cb69 match_word ../../gcc-4.8.2/gcc/fortran/parse.c:65 0x54db6b match_word ../../gcc-4.8.2/gcc/fortran/parse.c:327 0x54db6b decode_statement ../../gcc-4.8.2/gcc/fortran/parse.c:327 0x54f154 next_free ../../gcc-4.8.2/gcc/fortran/parse.c:783 0x54f154 next_statement ../../gcc-4.8.2/gcc/fortran/parse.c:976 0x54f8ed parse_spec ../../gcc-4.8.2/gcc/fortran/parse.c:2760 0x551738 parse_progunit ../../gcc-4.8.2/gcc/fortran/parse.c:4124 0x551ac0 parse_contained ../../gcc-4.8.2/gcc/fortran/parse.c:4063 0x552c7f parse_module ../../gcc-4.8.2/gcc/fortran/parse.c:4322 0x552c7f gfc_parse_file() ../../gcc-4.8.2/gcc/fortran/parse.c:4593 0x58e365 gfc_be_parse_file ../../gcc-4.8.2/gcc/fortran/f95-lang.c:189 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug lto/58905] New: Undefined symbol not report when compile with -flto -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58905
Bug ID: 58905
Summary: Undefined symbol not report when compile with -flto
-O1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: npickito at gmail dot com
Test Program:
test.c
char ___undef_func___ ();
char (*f) () = ___undef_func___;
int main ()
{
return f != ___undef_func___;
}
Problem:
$ gcc-trunk test.c # link error because ___undef_func___ is undefined
/tmp/ccvwlcm2.o:test.c:function main: error: undefined reference to
'___undef_func___'
/tmp/ccvwlcm2.o:test.c:function f: error: undefined reference to
'___undef_func___'
collect2: error: ld returned 1 exit status
$ gcc-trunk test.c -flto -O1 # No linker error when -flto -O1!
$ gcc-trunk test.c -flto -O0 # But linker error with -flto -O0
/tmp/ccPm2VXa.ltrans0.ltrans.o:ccPm2VXa.ltrans0.o:function main: error:
undefined reference to '___undef_func___'
/tmp/ccPm2VXa.ltrans0.ltrans.o:ccPm2VXa.ltrans0.o:function f: error: undefined
reference to '___undef_func___'
collect2: error: ld returned 1 exit status
GCC version:
gcc trunk r204123
gcc 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC)
GCC configure:
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/kito/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/kito/gcc/configure --prefix=/home/kito
--with-arch_32=i686 --enable-languages=c,c++,go,lto --program-suffix=-trunk
--disable-bootstrap --disable-shared CFLAGS='-g0 -O3 -flto' CXXFLAGS='-g0 -O3
-flto' LDFLAGS='-flto -fuse-linker-plugin'
Thread model: posix
gcc version 4.9.0 20131028 (experimental) (GCC)
[Bug rtl-optimization/58892] [4.8 Regression] ICE in combine.c when using -Os on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58892
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-10-28
Known to work||4.9.0
Summary|ICE in combine.c when using |[4.8 Regression] ICE in
|-Os on alpha|combine.c when using -Os on
||alpha
Ever confirmed|0 |1
--- Comment #1 from Uroš Bizjak ubizjak at gmail dot com ---
Confirmed with 4.8.3 using crosscompiler from x86_64-pc-linux-gnu to
alpha-linux-gnu. 4.9 works OK (but the failure can be latent there).
Reduced testcase:
--cut here--
typedef unsigned char u8;
static inline u8 foo (const u8 * tsp)
{
if (tsp[4] 183)
return 0;
return 183 - tsp[4];
}
u8 bar (const u8 * buf)
{
u8 count;
count = foo (buf);
if (count == 0)
return -1;
return count;
}
--cut here--
gcc -O2:
t.c: In function ‘bar’:
t.c:19:1: internal compiler error: in do_SUBST, at combine.c:711
}
^
0x96532c do_SUBST
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/combine.c:710
0x97374c combine_simplify_rtx
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/combine.c:5808
0x974a22 subst
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/combine.c:5155
0x974618 subst
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/combine.c:5100
0x974618 subst
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/combine.c:5100
0x975a8d try_combine
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/combine.c:3146
0x97a5e1 combine_instructions
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/combine.c:1368
0x97a5e1 rest_of_handle_combine
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/combine.c:13809
(gdb) up
#2 0x0096532d in do_SUBST (into=into@entry=0x719b08f8,
newval=0x71984830) at
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/combine.c:710
710 gcc_assert (INTVAL (newval)
(gdb) list
705 if (GET_MODE_CLASS (GET_MODE (oldval)) == MODE_INT
706CONST_INT_P (newval))
707 {
708 /* Sanity check that we're replacing oldval with a CONST_INT
709 that is a valid sign-extension for the original mode. */
710 gcc_assert (INTVAL (newval)
711 == trunc_int_for_mode (INTVAL (newval), GET_MODE
(oldval)));
712
713 /* Replacing the operand of a SUBREG or a ZERO_EXTEND with a
714 CONST_INT is not valid, because after the replacement, the
(gdb) p debug_rtx (newval)
(const_int 183 [0xb7])
$3 = void
(gdb) p debug_rtx (oldval)
(subreg:QI (reg:DI 71 [ D.1406 ]) 0)
$4 = void
The value 183 is too big for QImode.
[Bug c++/58888] [c++11] Rejects-valid: static member with auto and initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-10-28 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug rtl-optimization/58079] internal compiler error: in do_SUBST, at combine.c:711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58079 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||mcree at orcon dot net.nz --- Comment #9 from Uroš Bizjak ubizjak at gmail dot com --- *** Bug 58892 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/58892] [4.8 Regression] ICE in combine.c when using -Os on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58892 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- Duplicate of PR58079. *** This bug has been marked as a duplicate of bug 58079 ***
[Bug rtl-optimization/58079] internal compiler error: in do_SUBST, at combine.c:711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58079 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Uroš Bizjak ubizjak at gmail dot com --- This patch has to be backported to 4.8 branch, as confirmed by duplicate failures on three different targets.
[Bug rtl-optimization/58079] [4.8 Regression] internal compiler error: in do_SUBST, at combine.c:711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58079 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target|mips64r5900el-linux-gnu |mips64r5900el-linux-gnu, ||hppa-unknown-linux-gnu, ||alpha-linux-gnu Target Milestone|--- |4.8.3 Summary|internal compiler error: in |[4.8 Regression] internal |do_SUBST, at combine.c:711 |compiler error: in ||do_SUBST, at combine.c:711 --- Comment #11 from Uroš Bizjak ubizjak at gmail dot com --- Still regression on 4.8 branch.
[Bug fortran/58906] New: SELECT TYPE with CLASS IS generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58906 Bug ID: 58906 Summary: SELECT TYPE with CLASS IS generates ICE Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kimwooyoung at gmail dot com The code fragment causes gfortan to die with a seg fault. Using 'TYPE IS' instead of 'CLASS IS' seems o.k. MODULE mymod TYPE base CONTAINS END TYPE base TYPE, EXTENDS(base) :: child CLASS(*), DIMENSION(:), POINTER :: arr CONTAINS END TYPE child CONTAINS SUBROUTINE f(r) CLASS(base), INTENT(INOUT) :: r SELECT TYPE ( r ) CLASS IS ( child ) !TYPE IS ( child ) SELECT TYPE( iarr=r%arr ) TYPE IS ( INTEGER ) CALL func( iarr ) END SELECT END SELECT END SUBROUTINE f END MODULE mymod $ gfortran -c reprod2.F90 f951: internal compiler error: Segmentation fault 0x869cbf crash_signal ../../gcc-4.8.2/gcc/toplev.c:332 0x56a244 resolve_select_type ../../gcc-4.8.2/gcc/fortran/resolve.c:8367 0x56b7cc resolve_code ../../gcc-4.8.2/gcc/fortran/resolve.c:10379 0x56d24e resolve_codes ../../gcc-4.8.2/gcc/fortran/resolve.c:15047 0x55ddb2 gfc_resolve ../../gcc-4.8.2/gcc/fortran/resolve.c:15075 0x56b940 gfc_resolve ../../gcc-4.8.2/gcc/fortran/resolve.c:15066 0x56b940 resolve_block_construct ../../gcc-4.8.2/gcc/fortran/resolve.c:9367 0x56b940 resolve_code ../../gcc-4.8.2/gcc/fortran/resolve.c:10383 0x56a0fb gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-4.8.2/gcc/fortran/resolve.c:9449 0x56adf3 resolve_code ../../gcc-4.8.2/gcc/fortran/resolve.c:10193 0x56a0fb gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-4.8.2/gcc/fortran/resolve.c:9449 0x56ab1f resolve_select_type ../../gcc-4.8.2/gcc/fortran/resolve.c:8681 0x56b7cc resolve_code ../../gcc-4.8.2/gcc/fortran/resolve.c:10379 0x56d24e resolve_codes ../../gcc-4.8.2/gcc/fortran/resolve.c:15047 0x56d157 resolve_codes ../../gcc-4.8.2/gcc/fortran/resolve.c:15033 0x55ddb2 gfc_resolve ../../gcc-4.8.2/gcc/fortran/resolve.c:15075 0x552486 gfc_parse_file() ../../gcc-4.8.2/gcc/fortran/parse.c:4614 0x58e365 gfc_be_parse_file ../../gcc-4.8.2/gcc/fortran/f95-lang.c:189 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/58907] New: [c++11] ICE in gimplify_var_or_parm_decl, at gimplify.c:NNNN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58907 Bug ID: 58907 Summary: [c++11] ICE in gimplify_var_or_parm_decl, at gimplify.c: Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ppluzhnikov at google dot com Created attachment 31100 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31100action=edit test case Google ref: b/11241398 Attached test cases causes ICE in lambda: g++ (GCC) 4.9.0 20131016 (experimental) /g++ -c -std=c++11 t.cc t.cc: In lambda function: t.cc:96:9: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2059 [] ^ 0x9657f0 gimplify_var_or_parm_decl ../../gcc/gimplify.c:2059 0x96821e gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:8113 0x973748 gimplify_modify_expr ../../gcc/gimplify.c:4786 0x967ebc gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:7693 0x96c3f6 gimplify_stmt(tree_node**, gimple_statement_d**) ../../gcc/gimplify.c:5627 0x96c5c5 gimplify_and_add ../../gcc/gimplify.c:344 0x96c5c5 gimplify_init_ctor_eval ../../gcc/gimplify.c:3818 0x971b04 gimplify_init_constructor ../../gcc/gimplify.c:4164 0x9729ae gimplify_modify_expr_rhs ../../gcc/gimplify.c:4427 0x9735d4 gimplify_modify_expr ../../gcc/gimplify.c:4745 0x967ebc gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:7693 0x97d3c0 gimplify_target_expr ../../gcc/gimplify.c:5558 0x967ed6 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:8049 0x96c3f6 gimplify_stmt(tree_node**, gimple_statement_d**) ../../gcc/gimplify.c:5627 0x968d59 gimplify_cleanup_point_expr ../../gcc/gimplify.c:5403 0x968d59 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:8045 0x96c3f6 gimplify_stmt(tree_node**, gimple_statement_d**) ../../gcc/gimplify.c:5627 0x96936b gimplify_statement_list ../../gcc/gimplify.c:1538 0x96936b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:8097 0x96c3f6 gimplify_stmt(tree_node**, gimple_statement_d**) ../../gcc/gimplify.c:5627 Please submit a full bug report, Same error in gcc-4_8 branch.
[Bug c++/58907] [c++11] ICE in gimplify_var_or_parm_decl, at gimplify.c:NNNN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58907 --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- For some reason make didn't update the version stamp. make clean make Same problem with current trunk: g++ (GCC) 4.9.0 20131028 (experimental)
[Bug fortran/58906] [OOP] SELECT TYPE with CLASS IS generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58906
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-10-28
CC||burnus at gcc dot gnu.org
Summary|SELECT TYPE with CLASS IS |[OOP] SELECT TYPE with
|generates ICE |CLASS IS generates ICE
Ever confirmed|0 |1
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org ---
Confirmed.
ICEs in resolve_select_type for:
SELECT TYPE( iarr=r%arr )
where r%arr is CLASS(*). Hence,
(gdb) p code-expr2-ts.u.derived-attr.unlimited_polymorphic
$6 = 1
(gdb) p code-expr2-ts.u.derived-ts.u.derived
$7 = (gfc_symbol *) 0x0
but the code does the following (last line derefs a NULL pointer).
7914 if (code-expr2)
7915{
7916 if (code-expr1-symtree-n.sym-attr.untyped)
7917code-expr1-symtree-n.sym-ts = code-expr2-ts;
7918 selector_type = CLASS_DATA (code-expr2)-ts.u.derived;
[Bug preprocessor/58887] Allow recursion in variadic macros?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887 --- Comment #9 from Max TenEyck Woodbury mtewoodbury at gmail dot com --- (In reply to jos...@codesourcery.com from comment #7) On Sun, 27 Oct 2013, mtewoodbury at gmail dot com wrote: That has not always stopped you all in the past, but that is really neither We have plenty of experience dealing with the consequent problems of the old habit of adding extensions because they seemed like a good idea at the time (or because a feature was supported in some language other than C, and there used to be an idea that GNU C should support all features of GCC's internal representation that could be accessed from any language supported by GCC) without any real effort in designing them at the level of precise proposed standard text to specify the feature. Based on that experience, the bar for new extensions is much higher now. Unlike recursion, __VA_ARGC__ seems like something reasonably well-defined and in accordance with the spirit of the preprocessor and unlikely to be problematic as an extension - but as you note, there's already a separate bug for it. (Stop the 'we'! Name or enumerate the group involved please.) But that bug was filed on the wrong component and has languished for YEARS as a result of that miss-filing. It looks like no one has looked at its problem seriously... (In reply to jos...@codesourcery.com from comment #8) (And for recursion, even specification at the level of standard text might leave something to be desired; I'd think specification at the level of X3J11/86-196, the algorithm GCC tries to follow regarding when a macro name generated in macro expansion can itself be expanded, would be desired as well. Not that I think recursion is appropriate to include in GCC's preprocessor unless it's standardized.) Hmm. Is X3J11/86-196 the pdf that shows up at the top of a Google search? If so, I'll need to go over it fairly carefully. A quick review left me with the impression that determining when to allow additional expansion involved a bit of hand-waving. So, the description of what should expanded has to be carefully worked out before any implementation is released. Indirect recursion would be part of the package. I am trying to look at the reasons behind the specifications in the standard. In the case of 'no recursion' it was obvious that simple recursion was a snake eating its own tail and as originally specified could not be anything else. With the addition of variadic macros, a self limiting form of recursion becomes possible. With the proper hedges in place it would have the same kind of power that variadic functions posses. As things currently stand, variadic macros have apparently arbitrary limitations that reduces their usefulness. With an intelligent design, this would be where the language aught to be going.
[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687 --- Comment #7 from Max TenEyck Woodbury mtewoodbury at gmail dot com --- I have a patch written and I am testing it now. What steps (other than posting it here when the tests are done) need to be done to get it applied?
[Bug preprocessor/58887] Allow recursion in variadic macros?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887 --- Comment #10 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Mon, 28 Oct 2013, mtewoodbury at gmail dot com wrote: (Stop the 'we'! Name or enumerate the group involved please.) Well-established consensus among the GCC maintainers about what sorts of features are appropriate to add and what sorts of features cause problems. It's not as if the preprocessor has lots of active development with disagreement among its developers about what should go in; it's rightly pretty stable in terms of features with only occasional bug fixes or new features (mainly coming from WG21) needed. But that bug was filed on the wrong component and has languished for YEARS as a result of that miss-filing. It looks like no one has looked at its problem seriously... That maintainers wouldn't necessarily object to the addition of a feature doesn't mean any maintainer has any interest in implementing it. There are lots of bugs filed suggesting some vaguely reasonable new feature that was of interest to the submitter but not of sufficient interest to anyone wanting to implement it (but not rejected either, because the feature might well be accepted if implemented). (In reply to jos...@codesourcery.com from comment #8) (And for recursion, even specification at the level of standard text might leave something to be desired; I'd think specification at the level of X3J11/86-196, the algorithm GCC tries to follow regarding when a macro name generated in macro expansion can itself be expanded, would be desired as well. Not that I think recursion is appropriate to include in GCC's preprocessor unless it's standardized.) Hmm. Is X3J11/86-196 the pdf that shows up at the top of a Google search? Yes. If so, I'll need to go over it fairly carefully. A quick review left me with the impression that determining when to allow additional expansion involved a bit of hand-waving. The point is it defines, through the pseudocode functions, exactly how hide sets (the sets of macros for which expansion is currently suppressed because it would be recursive) are determined - it's the pseudocode that you need to study more than the surrounding text. And it's this algorithm that GCC is intended to follow. So anything allowing new forms of recursion needs to explain how this algorithm is affected. possible. With the proper hedges in place it would have the same kind of power that variadic functions posses. As things currently stand, variadic macros have apparently arbitrary limitations that reduces their usefulness. With an intelligent design, this would be where the language aught to be going. I suggest that the language ought not to be going in the direction of adding much power to the preprocessor at all - that expressive power belongs in the language, not the preprocessor (and that it's fine to use programs to generate C program text if neither is convenient for what you want to do). Obviously you can experiment with adding a feature to GCC's preprocessor in preparation for submitting it to WG14 - and detailed definitions in terms of pseudocode algorithms and proposed standard text will be helpful for that as well. But for actual inclusion in mainline GCC, you need to convince the maintainers that it's desirable for such features to be present in the preprocessor at all - that they are worth the maintenance burden that any feature imposes (which includes being well-enough defined that reimplementing a bit of the compiler won't change them incompatibly, rather than doing things in ways that are accidents of the implementation and so hard to specify and keep compatible over time). Sometimes a development branch is a better place for gaining experience with an experimental feature than mainline, until the standards committees reach a conclusion on the feature and how to specify it (that was done with C++ concepts, for example).
[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687 --- Comment #8 from joseph at codesourcery dot com joseph at codesourcery dot com --- Thanks for working on this bug. http://gcc.gnu.org/contribute.html describes how to submit changes (including testcases etc.).
[Bug target/58744] Illegal Memory Access on 3-byte packed struct ARCH: x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58744 --- Comment #3 from Marco Vanotti marcovanotti15+gcc at gmail dot com --- (In reply to Richard Biener from comment #2) Confirmed. On i?86 we properly do a 16byte and a 8byte access (but we copy to stack anyway). Yes, if the value is passed on the stack, it gets copied right. (For example, if it is the seventh parameter of a function, it will be passed on the stack and will be copied right). The thing is that in the x86_64 calling convention it has to be passed on registers while the are available (rdi, rsi, rdx, rcx, r8 and r9). Reading the source code, precisely the gcc/calls.c file: http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/calls.c?revision=203967view=markup --- The params that are passed on the stack are handled in line 3027, which says: /* Now store (and compute if necessary) all non-register parms. These come before register parms, since they can require block-moves, which could clobber the registers used for register parms. Parms which have partial registers are not stored here, but we do preallocate space here if they want that. */ Assuming that the registers may not require block-moves. It uses the function store_one_arg to store the arg in the stack (it doesn't work with a non-partial register). --- After a while, the function load_register_parameters (line 1860) is called, in this function, it falls in the case: move_block_to_reg (REGNO (reg), mem, nregs, args[i].mode); where nregs == 1. So a whole register is copied. --- I don't know how this issue should be fixed, should we copy the register into pseudos before the load_register_parameters ? Or should we change the move_block_to_reg function to make the right size of move instructions, for x86_64 we don't need backup-registers, but maybe this bug is also in another arch. size 3: mov di, [rax] sal rdi, 16 mov dil, [rax] --- size 5: mov edi, [rax] sal rdi, 8 mov dil, [rax] --- size 6: mov edi, [rax] sal rdi, 16 mov di, [rax] --- size 7: mov edi, [rax] ;move 4 sal rdi, 24 mov di, [rax] ;move 3 sal rdi, 16 mov dil, [rax] - I would gladly submit a patch if I can get some advice on how this should be fixed :)
[Bug testsuite/58867] asan and ubsan tests not run for installed testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58867 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Created attachment 31101 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31101action=edit Patch which I am testing This is the patch which I am testing right now.
[Bug c++/58908] New: intern compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58908
Bug ID: 58908
Summary: intern compile error
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kulow.f at gmail dot com
// compile error with gcc 4.7 .. 4.9, clang 3.3
// Option: -std=c++11
#include vector
struct Pardef_s{};
struct LPardef_s: public Pardef_s
{
LPardef_s(const char*, const char*){}
};
class Glob_c
{
public:
const static std::vectorPardef_s Par;
};
const std::vectorPardef_s Glob_c::Par=
{
LPardef_s({
LInitState,
pInitState
})};
[Bug tree-optimization/58508] [Missed-Optimization] Redundant vector load of actual loop invariant in loop body.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58508
--- Comment #5 from Cong Hou congh at google dot com ---
I guess I should add
/* { dg-require-effective-target vect_int } */
to the test case. It is right?
[Bug libstdc++/58909] New: C++11's condition variables fail with static linkin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Bug ID: 58909
Summary: C++11's condition variables fail with static linkin
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at clambassador dot com
The program:
#include condition_variable
int main () { std::condition_variable a; }
statically compiled as either:
g++ --std=c++0x -static -pthread aa.cc -lpthread
clang++ --std=c++11 -static -pthread aa.cc -lpthread
segfaults at the destructor's implicit call to pthread_cond_destroy(). Other
uses of std::condition_variable also fail. nm shows that pthread_cond_*
functions are only 'w', while programs that use other aspects of c++ threading,
such as mutexes, will have 'W' pthread_mutex_* and corresponding T
__pthread_mutex_* available.
