[Bug inline-asm/63541] gcc compilation error: The register specified for 'variable' is not general enough to be used as a register variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63541 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- pc is not general enough in all of armv7. If you want to read the PC do this instead or something like this: asm(mov pc, %0:=rarm_pc);
[Bug go/63539] libgo does not use the newly built objcopy when doing a combined build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63539 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||ian at airs dot com Assignee|ian at airs dot com|pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- .
[Bug go/63539] libgo does not use the newly built objcopy when doing a combined build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63539 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- Created attachment 33718 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33718action=edit Patch which I need to submit I already tested this patch but I need to submit it still. ChangeLog: * Makefile.def (flags_to_pass): Pass OBJCOPY_FOR_TARGET also. * Makefile.tpl (HOST_EXPORTS): Add OBJCOPY_FOR_TARGET. (BASE_TARGET_EXPORTS): Add OBJCOPY. (OBJCOPY_FOR_TARGET): New variable. (EXTRA_TARGET_FLAGS): Add OBJCOPY. * Makefile.in: Regenerate. * configure.ac: Check for already installed target objcopy. Also GCC_TARGET_TOOL on objcopy. * configure: Regenerate.
[Bug target/63542] New: My build log is full of non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63542 Bug ID: 63542 Summary: My build log is full of non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org /home/pinskia/src/local/gcc/libgcc/config/libbid/bid128_compare.c: In function ‘__bid128_quiet_not_equal’: /home/pinskia/src/local/gcc/libgcc/config/libbid/bid_conf.h:315:32: note: non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location #define bid128_quiet_not_equal __bid128_quiet_not_equal ^ /home/pinskia/src/local/gcc/libgcc/config/libbid/bid_conf.h:1056:6: note: in definition of macro ‘BID128_FUNCTION_ARG2_NORND_CUSTOMRESTYPE’ fn_name (UINT128 bid_##arg_name1, \ ^ /home/pinskia/src/local/gcc/libgcc/config/libbid/bid128_compare.c:1675:48: note: in expansion of macro ‘bid128_quiet_not_equal’ BID128_FUNCTION_ARG2_NORND_CUSTOMRESTYPE (int, bid128_quiet_not_equal, ^ /home/pinskia/src/local/gcc/libgcc/config/libbid/bid_conf.h:315:32: note: non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location #define bid128_quiet_not_equal __bid128_quiet_not_equal ^ /home/pinskia/src/local/gcc/libgcc/config/libbid/bid_conf.h:1056:6: note: in definition of macro ‘BID128_FUNCTION_ARG2_NORND_CUSTOMRESTYPE’ fn_name (UINT128 bid_##arg_name1, \ ^ /home/pinskia/src/local/gcc/libgcc/config/libbid/bid128_compare.c:1675:48: note: in expansion of macro ‘bid128_quiet_not_equal’ BID128_FUNCTION_ARG2_NORND_CUSTOMRESTYPE (int, bid128_quiet_not_equal, etc.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #47 from Jakub Jelinek jakub at gcc dot gnu.org --- .
[Bug c++/63419] verify_gimple failed: vector CONSTRUCTOR element is not a GIMPLE value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63419
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
The testcase should have // { dg-options -Wno-psabi }
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- For -pg, at least for 32-bit -fpic, one way to handle this would be for !targetm.profile_before_prologue () crtl-profile in ix86_init_pic_reg instead of emitting set_got into the pic_offset_table_rtx emit set_got into %ebx hard reg and then copy %ebx to the pic_offset_table_rtx (to strongly hint RA that it better should allocate the pic register at the start of the function to %ebx). And then, when emitting prologue, see if the function doesn't start with set_got insn (after optional notes) loading into %ebx, and if it does, move the set_got insn right before the NOTE_INSN_PROLOGUE_END (on which final.c emits the _mcount call). That way, there will be just a single set_got, not two. If you don't find it for some reason (e.g. function that doesn't use PIC register otherwise, or something unexpected happened), make sure you treat %ebx as clobbered in the prologue and emit the set_got into %ebx directly right before NOTE_INSN_PROLOGUE_END. For -m64 -fpic -mcmodel=large -pg this will be harder, as init_pic_reg emits multiple instructions.
[Bug tree-optimization/62031] [4.8/4.9 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Oct 15 07:37:20 2014 New Revision: 216236 URL: https://gcc.gnu.org/viewcvs?rev=216236root=gccview=rev Log: 2014-10-15 Richard Biener rguent...@suse.de Backport from mainline 2014-08-15 Richard Biener rguent...@suse.de PR tree-optimization/62031 * tree-data-ref.c (dr_analyze_indices): Do not set DR_UNCONSTRAINED_BASE. (dr_may_alias_p): All indirect accesses have to go the formerly DR_UNCONSTRAINED_BASE path. * tree-data-ref.h (struct indices): Remove unconstrained_base member. (DR_UNCONSTRAINED_BASE): Remove. * gcc.dg/torture/pr62031.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr62031.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-data-ref.c branches/gcc-4_9-branch/gcc/tree-data-ref.h
[Bug target/63542] My build log is full of non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63542 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-15 CC||evstupac at gmail dot com, ||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Not just UNSPEC_GOT (0), but also UNSPEC_GOTOFF (1): grep UNSPEC_ LOG | sed 's/^.*: note:/note:/' | sort | uniq -c 9140 note: non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location 4179 note: non-delegitimized UNSPEC UNSPEC_GOTOFF (1) found in variable location in i686-linux bootstrap. This has been discussed, and I think I've suggested what to do in those cases: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02513.html - if you don't have a known PIC register to subtract, subtract _GLOBAL_OFFSET_TABLE_ symbol instead. Relocations in .debug_* sections are resolved at link time, thus even if on some i?86/x86_64 target _GLOBAL_OFFSET_TABLE_ doesn't have hidden visibility, it would still resolve to the local copy.
[Bug target/63542] My build log is full of non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63542 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Version|4.9.0 |5.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- You are reporting this against trunk, right?
[Bug inline-asm/63541] gcc compilation error: The register specified for 'variable' is not general enough to be used as a register variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63541 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Invalid.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr ---
r216154 broke bootstrap on x86_64-apple-darwin13 too while building
libstdc++-v3:
libtool: compile: /opt/gcc/p_build/./gcc/xgcc -shared-libgcc
-B/opt/gcc/p_build/./gcc -nostdinc++
-L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/src
-L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/src/.libs
-L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/bin/
-B/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/lib/ -isystem
/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/include -isystem
/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/sys-include -m32
-I/opt/gcc/p_work/libstdc++-v3/../libgcc
-I/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/include/x86_64-apple-darwin13.4.0
-I/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/include
-I/opt/gcc/p_work/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -fvisibility-inlines-hidden
-ffunction-sections -fdata-sections -frandom-seed=atexit_thread.lo -g -O2 -m32
-std=gnu++11 -c ../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc
-fno-common -DPIC -D_GLIBCXX_SHARED -o atexit_thread.o
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc: In function
'void {anonymous}::key_init()':
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc:111:3: internal
compiler error: in cselib_invalidate_regno, at cselib.c:2146
}
^
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc:111:3: internal
compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1plus)
[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-10-15 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- AFAICT the ICE with REAL :: ptee1(10) has been fixed for gfortran 4.9.1 and above (also for 4.8.4). I also think the error for REAL :: ptee1(*) is right. If you agree with the above, could you please close this PR as FIXED?
[Bug tree-optimization/63537] [4.9/5 Regression] Missed optimization: Loop unrolling adds extra copy when returning aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63537
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-10-15
Known to work||4.7.3
Target Milestone|--- |4.9.2
Summary|Missed optimization: Loop |[4.9/5 Regression] Missed
|unrolling adds extra copy |optimization: Loop
|when returning aggregate|unrolling adds extra copy
||when returning aggregate
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
This is because the outer loop is unrolled only after SRA gets a chance to
scalarize away the local aggregate. With GCC 4.7 we unroll the loop during
early unrolling even at -O2.
With 4.9 we conclude:
Estimating sizes for loop 1
BB: 4, after_exit: 0
size: 2 if (i_1 = 2)
Exit condition will be eliminated in peeled copies.
BB: 3, after_exit: 1
size: 1 _4 = lhs.n[i_1];
size: 1 _6 = _4 * rhs_5(D);
size: 1 ret.n[i_1] = _6;
size: 1 i_8 = i_1 + 1;
Induction variable computation will be folded away.
size: 6-3, last_iteration: 2-0
Loop size: 6
Estimated size after unrolling: 7
Not unrolling loop 1: size would grow.
while 4.7 had:
Estimating sizes for loop 1
BB: 4, after_exit: 0
size: 2 if (i_1 = 2)
Exit condition will be eliminated.
BB: 3, after_exit: 1
size: 1 D.1593_3 = lhs.n[i_1];
size: 1 D.1594_5 = D.1593_3 * rhs_4(D);
size: 1 ret.n[i_1] = D.1594_5;
size: 1 i_6 = i_1 + 1;
Induction variable computation will be folded away.
size: 6-3, last_iteration: 2-2
Loop size: 6
Estimated size after unrolling: 6
so the difference is in last_iteration handling.
Honza?
Otherwise this is a optimization pass ordering issue.
Eventually a simple pass could handle
retval = ret;
ret ={v} {CLOBBER};
return retval;
and back-propagate retval into all stores/loads of ret.
[Bug fortran/63535] SELECT TYPE shouldn't pass ALLOCATABLE/POINTER attribute through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63535 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-15 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.8.3 up to trunk (5.0).
[Bug tree-optimization/63537] [4.8/4.9/5 Regression] Missed optimization: Loop unrolling adds extra copy when returning aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63537 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.9.2 |4.8.4 Summary|[4.9/5 Regression] Missed |[4.8/4.9/5 Regression] |optimization: Loop |Missed optimization: Loop |unrolling adds extra copy |unrolling adds extra copy |when returning aggregate|when returning aggregate Known to fail||4.8.3, 4.9.1, 5.0
[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #26 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #25) (In reply to Oleg Endo from comment #23) Kaz, could you please have an early look at it? The idea looks OK to me. Build fails on sh4-linux with the patch, though. Maybe a wrong version? There is a typo divdf3 expand. s/gen_divdf3 /gen_divdf3_i / - expand_df_binop (gen_divdf3_i, operands); + emit_insn (gen_divdf3 (operands[0], operands[1], operands[2])); With fixing it, yet segfaults during compiling libgcc2.c __powidf2 at No, that was the correct version unfortunately. And that was my infinite-memory problem. Thanks for spotting it. #0 0x089706b4 in sh_adjust_cost (insn=0xb7f767e0, link=0xb7f79380, dep_insn=0xb7f762d0, cost=25) at trunk/gcc/config/sh/sh.c:10908 10908 SET_SRC (use_pat))) (gdb) l 10903cycle earlier. */ 10904 else if (reload_completed 10905 get_attr_dfp_comp (dep_insn) == DFP_COMP_YES 10906 (use_pat = single_set (insn)) 10907 ! regno_use_in (REGNO (SET_DEST (single_set (dep_insn))), 10908 SET_SRC (use_pat))) It looks - (use (match_operand:PSI 3 fpscr_operand c))] + (set (reg:SI FPSCR_STAT_REG) (const_int 0)) + (use (reg:SI FPSCR_MODES_REG))] breaks the assumption of sh_adjust_cost which divdf3_i has only one set insn. Yep, single_set now returns null for basically all fp insns and it's not checked there. The default implementation of single_set is also the reason why delay slot stuffing is not working on fp insns anymore.
[Bug fortran/63494] internal compiler error: Bus error, and out of memory allocating ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63494 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-10-15 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- On x86_64-apple-darwin13 without preprocessor I get the following ICE f951: internal compiler error: Segmentation fault: 11 The backtrace is * frame #0: 0x000141f93520 libgmp.10.dylib`__gmpz_init_set + 16 frame #1: 0x000100031a02 f951`gfc_copy_shape(__mpz_struct (*) [1], int) + 82 frame #2: 0x000100031ae2 f951`gfc_copy_expr(gfc_expr*) + 194 frame #3: 0x00010008fa9b f951`gfc_resolve_substring_charlen(gfc_expr*) + 171 frame #4: 0x00010008d316 f951`gfc_resolve_expr(gfc_expr*) + 1526 frame #5: 0x00010009457e f951`gfc_resolve_code(gfc_code*, gfc_namespace*) + 782 frame #6: 0x000100097300 f951`resolve_codes(gfc_namespace*) + 304 frame #7: 0x000100097208 f951`resolve_codes(gfc_namespace*) + 56 frame #8: 0x0001000973ed f951`gfc_resolve(gfc_namespace*) (.part.48) + 61 frame #9: 0x00010008191b f951`gfc_parse_file() + 779 frame #10: 0x0001000c5266 f951`gfc_be_parse_file() + 38 frame #11: 0x000100998cce f951`compile_file() + 46 frame #12: 0x00010099b3bf f951`toplev_main(int, char**) + 2991
[Bug c++/53000] Conditional operator does not behave as standardized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #28 from Paolo Carlini paolo.carlini at oracle dot com --- Something is going wrong here: the bug is closed as fixed, but if I try to enable in 20_util/common_type/requirements/sfinae_friendly_1.cc the lines which require the bug to be fixed to pass, I'm still seeing a failure, for the line: static_assert(is_typestd::common_typeconst Ukn, volatile Ukn, Ukn(), ); Maybe Daniel or Jason can clarify??
[Bug c++/63540] Erroneous 'Derived' declares a move constructor or move assignment operator in error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63540 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-15 Ever confirmed|0 |1
[Bug c/63543] New: incomplete type error should suppress duplicates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63543
Bug ID: 63543
Summary: incomplete type error should suppress duplicates
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
For a test case like this
struct undefined;
int f(struct undefined *f)
{
int x = f-a;
return x + f-a + f-b;
}
tmissing-type.c: In function 'f':
tmissing-type.c:5:11: error: dereferencing pointer to incomplete type
int x = f-a;
^
tmissing-type.c:6:14: error: dereferencing pointer to incomplete type
return x + f-a + f-b;
^
tmissing-type.c:6:21: error: dereferencing pointer to incomplete type
return x + f-a + f-b;
gcc outputs three different errors for each reference of the undefined type.
It would be better if it remembered that it already gave an error for
referencing that type and suppress the later errors (similar to undefined
symbols). This would avoid cascading errors.
[Bug c/63543] incomplete type error should suppress duplicates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63543 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-15 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Yeah.
[Bug c/63543] incomplete type error should suppress duplicates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63543 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- It would also be nice to mention the type. test.c:6:12: error: incomplete definition of type 'struct undefined' int x = f-a; ~^ test.c:2:8: note: forward declaration of 'struct undefined' struct undefined; ^
[Bug c/63543] incomplete type error should suppress duplicates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63543 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- The C++ FE prints: test.c:6:12: error: invalid use of incomplete type ‘struct undefined’ int x = f-a; ^ test.c:2:8: note: forward declaration of ‘struct undefined’ struct undefined; ^ but it also prints it three times.
[Bug go/59432] [4.9/5 regression] sync/atomic FAILs on 32bit x86 systems without .cfi directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ian at airs dot com|ubizjak at gmail dot com --- Comment #12 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 33719 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33719action=edit Patch to enable unconditional use of %ebx in atomic_compare_and_swapdwi_doubleword pattern Patch in testing. Now that %ebx is not fixed anymore, we can always use it and avoid all PIC related complications in atomic_compare_and_swapdwi_doubleword pattern. Attached patch fixes sync/atomic on CentOS 5 and doesn't regress in Fedora 20. The patch in effect reverts Ian's patch at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2013-11/msg00309.html
[Bug go/59432] [4.9/5 regression] sync/atomic FAILs on 32bit x86 systems without .cfi directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Attachment #33719|0 |1 is obsolete|| --- Comment #13 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 33720 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33720action=edit Updated patch. The correct version of the patch.
[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Attachment #33717|0 |1 is obsolete|| --- Comment #27 from Oleg Endo olegendo at gcc dot gnu.org --- Created attachment 33721 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33721action=edit Using virtual FPSCR registers to model insn dependencies Updated patch that avoids the single_set problems by using (clobber (reg:SI FPSCR_STAT_REG)) instead of a set. This also eliminates the fsca pattern changes in the previous patch. Since the 'fpu_switch' insn is still a multiple set insn, it won't be used for delay slot stuffing, but this is a minor issue that can be addressed later. I'm testing the patch now on sh-sim. At least 'make all' works.
[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 33722 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33722action=edit gcc49-pr63302.patch IMHO better fix, we already have the right predicate, it doesn't make sense to add another one.
[Bug ada/61027] gnatcmd gets SIGABRT during exception handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61027 --- Comment #2 from simon at pushface dot org --- I just built 4.9.1 on Mac OS X 10.9.5 (Darwin 13.4.0), Xcode 6.0.1. This problem goes away if GCC is configured with --with-host-libstdcxx=-lstdc++. For reference, the configuration flags, as reported by gcc, were Target: x86_64-apple-darwin13 Configured with: ../gcc-4.9.1/configure \ --prefix=/opt/gcc-4.9.1 \ --disable-multilib \ --disable-nls \ --enable-languages=c,c++,ada,fortran,objc,obj-c++ \ --host=x86_64-apple-darwin13 \ --target=x86_64-apple-darwin13 \ --build=x86_64-apple-darwin13 \ --with-host-libstdcxx=-lstdc++ Thread model: posix gcc version 4.9.1 (GCC)
[Bug c++/63531] gcc segfaults on some sourcefiles when using '-Weffc++' and '-fsanitize=undefined' together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63531 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Actually, I can't reproduce it with 4.9 nor with 5. I'd say your version doesn't have r215459 yet, which I believe is the fix. Can you try newer GCC?
[Bug c++/63522] [4.8/4.9/5] ICE: unexpected expression 'ElementIndices' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63522 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-15 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.4 Summary|[4.8/4.9/5.0] ICE: |[4.8/4.9/5] ICE: unexpected |unexpected expression |expression 'ElementIndices' |'ElementIndices' of kind|of kind template_parm_index |template_parm_index | Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug middle-end/62289] [5 Regression] ICE (segfault) for gfortran.dg/graphite/pr42393.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62289 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #3) Namely: This is a bug in ISL. Theyâll fix it in a new version of ISL. https://groups.google.com/forum/#!topic/isl-development/SeNZf5IA-Lk Seems to be fixed by the commit(s): http://repo.or.cz/w/isl.git/history/HEAD:/test_inputs/codegen/roman.c thus (untested by me) a post ISL 0.13 should work.
[Bug target/63442] [AArch64] ICE with ubsan/overflow-int128.c test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442 --- Comment #4 from Jiong Wang jiwang at gcc dot gnu.org --- the root cause should be one minor bug in prepare_cmp_insn. the last mode parameter pmode of prepare_cmp_insn should match the mode of the first parameter x, while during the recursive call of prepare_cmp_insn, x is with mode of targetm.libgcc_cmp_return_mode (), pmode is assign to word_mode. there comes the problem, aarch64 implemented libgcc_cmp_return_mode to always return SImode, so there is a unmatch. we should assign pmode with targetm.libgcc_cmp_return_mode () also. this problem is hidding because nearly all other targets use the default hook which return word_mode.
[Bug bootstrap/63536] [5 Regression] bootstrap failed when configured with --with-cpu=slm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63536 Stupachenko Evgeny evstupac at gmail dot com changed: What|Removed |Added CC||tromey at redhat dot com --- Comment #1 from Stupachenko Evgeny evstupac at gmail dot com --- That is most likely not ebx enabling issue, but java issue.
[Bug bootstrap/63536] [5 Regression] bootstrap failed when configured with --with-cpu=slm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63536
--- Comment #2 from Stupachenko Evgeny evstupac at gmail dot com ---
ebx enabling changes triggered a warning for
_Jv_global_static_constructor().
The function has NULL location and CONTEXT.
The ICE caused by passing NULL to
lang_printable_name:
if (current_function_decl != NULL
DECL_CONTEXT (current_function_decl) != last_error_function_context)
{
if (file)
fprintf (stderr, %s: , file);
last_error_function_context = DECL_CONTEXT (current_function_decl);
fprintf (stderr, In class '%s':\n,
lang_printable_name (last_error_function_context, 0));
}
an additional check
if (current_function_decl != NULL
DECL_CONTEXT (current_function_decl) != NULL
DECL_CONTEXT (current_function_decl) != last_error_function_context)
should resolve the problem.
Checking bootstrap now.
[Bug tree-optimization/63379] [4.8 Regression] Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63379 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to clyon from comment #8) After this commit, I've noticed that this new test appears as FAIL on target aarch64_be-none-linux-gnu. My gcc.log shows: PASS: gcc.dg/vect/pr63379.c (test for excess errors) *** EXIT code 4242 emu: host signal 6 FAIL: gcc.dg/vect/pr63379.c execution test I'm using qemu as execution engine. Maybe you run into known reduction endianess dependence issues here (as you are on big-endian). Who knows...
[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401 --- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org --- Created attachment 33723 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33723action=edit Make GBR call preserved by default (In reply to Oleg Endo from comment #10) (In reply to Kazumoto Kojima from comment #9) (In reply to Oleg Endo from comment #8) change the value for gbr in sh.h CALL_USED_REGISTERS from '1' to '0' and confirm that everything is still OK? The comment and document about CALL_USED_REGISTERS say that it must be a superset of FIXED_REGISTERS. CALL_REALLY_USED_REGISTERS might be a macro for that purpose. Right. In this case it's probably better to do it in sh_conditional_register_usage. It would be nice if '-fcall-saved-gbr' and '-fcall-used-gbr' still remained functional afterwards ... I'll give it a try. sh_conditional_register_usage is invoked after the -fcall-*-* options are processed. Defining the CALL_REALLY_USED_REGISTERS macro with the default values works as expected, i.e. -fcall-used-gbr still works. Kaz, could you please add the attached patch to your test run?
[Bug bootstrap/63536] [5 Regression] bootstrap failed when configured with --with-cpu=slm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63536
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Stupachenko Evgeny from comment #2)
ebx enabling changes triggered a warning for
_Jv_global_static_constructor().
The function has NULL location and CONTEXT.
The ICE caused by passing NULL to
lang_printable_name:
if (current_function_decl != NULL
DECL_CONTEXT (current_function_decl) != last_error_function_context)
{
if (file)
fprintf (stderr, %s: , file);
last_error_function_context = DECL_CONTEXT (current_function_decl);
fprintf (stderr, In class '%s':\n,
lang_printable_name (last_error_function_context, 0));
}
an additional check
if (current_function_decl != NULL
DECL_CONTEXT (current_function_decl) != NULL
DECL_CONTEXT (current_function_decl) != last_error_function_context)
should resolve the problem.
Checking bootstrap now.
Will it solve
../../../../../src-trunk/libjava/classpath/tools/external/asm/org/objectweb/asm/xml/ASMContentHandler.java:1018:0:
note: non-delegitimized UNSPEC UNSPEC_GOTOFF (1) found in variable location
H.J.
[Bug bootstrap/63536] [5 Regression] bootstrap failed when configured with --with-cpu=slm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63536 --- Comment #4 from Stupachenko Evgeny evstupac at gmail dot com --- No. The changes has no influence on the note. Anyway bootstrap have passed.
[Bug c++/63455] [4.8/4.9/5 Regression] decltype of statement expression internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:25062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63455 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Oct 15 14:12:24 2014 New Revision: 216260 URL: https://gcc.gnu.org/viewcvs?rev=216260root=gccview=rev Log: PR c++/63455 c-family/ * c-common.h (CPP_PREPARSED_EXPR): New. (N_CP_TTYPES): Adjust. cp/ * parser.c (struct saved_token_sentinel): New. (cp_parser_statement): Use it. (cp_parser_start_tentative_firewall): New. (cp_parser_end_tentative_firewall): New. (cp_parser_lambda_expression): Use them. (cp_parser_statement_expr): New. (cp_parser_primary_expression): Use it. Added: trunk/gcc/testsuite/g++.dg/ext/stmtexpr16.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.h trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-sfinae1.C
[Bug c++/63455] [4.8/4.9/5 Regression] decltype of statement expression internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:25062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63455 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Oct 15 14:18:54 2014 New Revision: 216261 URL: https://gcc.gnu.org/viewcvs?rev=216261root=gccview=rev Log: PR c++/63455 Revert: * parser.c (cp_parser_abort_tentative_parse): Make sure we haven't committed to this tentative parse. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ext/stmtexpr16.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/parser.c
[Bug tree-optimization/63464] compare one character to many: faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 33724 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33724action=edit gcc5-pr63464.patch Untested patch.
[Bug middle-end/63544] New: [5 Regression] hash_map ends in an infinite loop if overwritten mark_empty uses a different value than 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63544
Bug ID: 63544
Summary: [5 Regression] hash_map ends in an infinite loop if
overwritten mark_empty uses a different value than 0
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mliska at suse dot cz
CC: tbsaunde at gcc dot gnu.org
Hello.
With following patch applied:
diff --git a/gcc/value-prof.c b/gcc/value-prof.c
index 37710ca..43900c1 100644
--- a/gcc/value-prof.c
+++ b/gcc/value-prof.c
@@ -1240,9 +1240,9 @@ struct profile_id_traits : default_hashmap_traits
return e.m_key == UINT_MAX;
}
- templatetypename T static bool is_empty (T e) { return e.m_key == 0; }
+ templatetypename T static bool is_empty (T e) { return e.m_key ==
UINT_MAX - 1; }
templatetypename T static void mark_deleted (T e) { e.m_key = UINT_MAX; }
- templatetypename T static void mark_empty (T e) { e.m_key = 0; }
+ templatetypename T static void mark_empty (T e) { e.m_key = UINT_MAX - 1;
}
};
static hash_mapunsigned int, cgraph_node *, profile_id_traits *
I configured GCC: ../configure --enable-languages=c,c++ --disable-libsanitizer
--disable-multilib
and run: make profiledbootstrap
After stage1 compiler is built, I loop in:
#0 hash_mapunsigned int, cgraph_node*,
profile_id_traits::hash_entry::is_deleted (e=...) at ../../gcc/hash-map.h:132
#1 0x00f4bb14 in is_deleted_helperhash_mapunsigned int,
cgraph_node*, profile_id_traits::hash_entry, hash_mapunsigned int,
cgraph_node*, profile_id_traits::hash_entry, false::call (v=...) at
../../gcc/hash-table.h:392
#2 0x00f4b375 in hash_tablehash_mapunsigned int, cgraph_node*,
profile_id_traits::hash_entry, xcallocator, true::is_deleted (v=...) at
../../gcc/hash-table.h:1170
#3 0x00f4b0cc in hash_tablehash_mapunsigned int, cgraph_node*,
profile_id_traits::hash_entry, xcallocator, true::find_with_hash
(this=0x29c7e00, comparable=@0x7f3fd57042e0: 108032747, hash=108032747) at
../../gcc/hash-table.h:1435
#4 0x00f4a662 in hash_mapunsigned int, cgraph_node*,
profile_id_traits::get (this=0x29c7e00, k=@0x7f3fd57042e0: 108032747)
at ../../gcc/hash-map.h:220
#5 0x00f4810c in init_node_map (local=true) at
../../gcc/value-prof.c:1280
#6 0x00d3b298 in tree_profiling () at ../../gcc/tree-profile.c:584
#7 0x00d3b75d in (anonymous namespace)::pass_ipa_tree_profile::execute
(this=0x29d5e90) at ../../gcc/tree-profile.c:709
#8 0x00b643cb in execute_one_pass (pass=0x29d5e90) at
../../gcc/passes.c:2151
#9 0x00b6517b in execute_ipa_pass_list (pass=0x29d5e90) at
../../gcc/passes.c:2541
#10 0x00804083 in ipa_passes () at ../../gcc/cgraphunit.c:2012
#11 0x00804422 in symbol_table::compile (this=0x7f3fd56f5000) at
../../gcc/cgraphunit.c:2131
#12 0x0080475c in symbol_table::finalize_compilation_unit
(this=0x7f3fd56f5000) at ../../gcc/cgraphunit.c:2284
#13 0x00663d4a in c_write_global_declarations () at
../../gcc/c/c-decl.c:10633
#14 0x00c5b98a in compile_file () at ../../gcc/toplev.c:565
#15 0x00c5dc88 in do_compile () at ../../gcc/toplev.c:1973
#16 0x00c5ddf3 in toplev_main (argc=26, argv=0x7fff49285938) at
../../gcc/toplev.c:2049
#17 0x01523bb0 in main (argc=26, argv=0x7fff49285938) at
../../gcc/main.c:36
Thank you for help,
Martin
[Bug c/63543] incomplete type error should suppress duplicates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63543 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Testing a fix.
[Bug lto/61048] compiling with -fsanitize=address crashes GCC if pointers are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61048 Ilya Palachev i.palachev at samsung dot com changed: What|Removed |Added Attachment #33714|0 |1 is obsolete|| --- Comment #5 from Ilya Palachev i.palachev at samsung dot com --- Created attachment 33725 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33725action=edit Patch that fixes the ICE (2nd version) The 2nd version of patch was posted at https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01364.html
[Bug tree-optimization/63168] loop header copying fails - not vectorized: latch block not empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63168
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
It looks like do_while_loop_p is fooled by the CFG structure and hits
static bool
do_while_loop_p (struct loop *loop)
{
gimple stmt = last_stmt (loop-latch);
/* If the latch of the loop is not empty, it is not a do-while loop. */
if (stmt
gimple_code (stmt) != GIMPLE_LABEL)
return false;
the loop at CH time looks like
|
v
/- bb 5
| exit test ---
| |
| bb 3
| ...
| |
\ bb 4
-- (empty but with a PHI)
phiopt introduces this singleton PHI:
bb 3:
max_8 = *it_6;
- if (max_8 max_2)
-goto bb 5;
- else
-goto bb 4;
+ max_10 = MAX_EXPR max_2, max_8;
bb 4:
+ # max_9 = PHI max_10(3)
bb 5:
- # max_9 = PHI max_2(4), max_8(3)
-
- bb 6:
- # it_1 = PHI it_6(5), it_4(D)(2)
- # max_2 = PHI max_9(5), max_5(2)
+ # it_1 = PHI it_6(4), it_4(D)(2)
+ # max_2 = PHI max_9(4), max_5(2)
it looks like the CH predicate relies on copy-propagated form
(a latch block with an SSA name copy should also be considered empty IMHO).
I think that cfgcleanup should merge
bb A
| single-succ/pred
bb B
# var = PHI arg
and rewrite the PHIs to copies. Its comment even says so:
/* Merging the blocks may create new opportunities for folding
conditional branches (due to the elimination of single-valued PHI
nodes). */
if (single_succ_p (bb)
can_merge_blocks_p (bb, single_succ (bb)))
{
merge_blocks (bb, single_succ (bb));
return true;
}
Ah, but
/* Checks whether we can merge block B into block A. */
static bool
gimple_can_merge_blocks_p (basic_block a, basic_block b)
{
...
/* Protect the loop latches. */
if (current_loops b-loop_father-latch == b)
return false;
triggers here (merge_blocks doesn't handle merging with a latch).
Mine.
[Bug tree-optimization/62031] [4.8 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 clyon at gcc dot gnu.org changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #8 from clyon at gcc dot gnu.org --- The added testcase (gcc/testsuite/gcc.dg/torture/pr62031.c) FAILs at execution on all the arm* targets I validate. They PASS on aarch64 targets though. The logs only show: PASS: gcc.dg/torture/pr62031.c -O0 (test for excess errors) FAIL: gcc.dg/torture/pr62031.c -O0 execution test etc
[Bug tree-optimization/62031] [4.8 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 --- Comment #9 from clyon at gcc dot gnu.org --- Forgot to mention that my observation is true on trunk and 4.9 branch. I didn't notice it earlier because I run validations for every commit on the 4.9 branch, and not as often on trunk.
[Bug rtl-optimization/63448] [4.9/5 Regression] ICE when compiling atlas 3.10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448 --- Comment #8 from Vladimir Makarov vmakarov at gcc dot gnu.org --- I already saw such problem. It is chain of spills and reassignment of non-reload pseudos. Each pass considers only 1-2 pseudos and very few insns. We just need 2 more passes to finish RA for the test. The current code of LRA looping prevention is too conservative for the case. Finally I have an idea how to solve this kind of problems. The patch is on the way.
[Bug tree-optimization/63537] [4.8/4.9/5 Regression] Missed optimization: Loop unrolling adds extra copy when returning aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63537 --- Comment #2 from Tavian Barnes tavianator at gmail dot com --- Is it possible to make SRA work even if the loop isn't unrolled? If the array size is increased to 4 then -O2 doesn't unroll the loop at all, resulting in: movq%rdi, %rax xorl%edx, %edx .L3: movsd8(%rsp,%rdx), %xmm1 mulsd%xmm0, %xmm1 movsd%xmm1, -40(%rsp,%rdx) addq$8, %rdx cmpq$32, %rdx jne.L3 movq-40(%rsp), %rdx movq%rdx, (%rax) movq-32(%rsp), %rdx movq%rdx, 8(%rax) movq-24(%rsp), %rdx movq%rdx, 16(%rax) movq-16(%rsp), %rdx movq%rdx, 24(%rax) ret which would be a lot prettier as something like: movq%rdi, %rax xorl%edx, %edx .L3: movsd8(%rsp,%rdx), %xmm1 mulsd%xmm0, %xmm1 movsd%xmm1, (%rax,%rdx) addl$8, %edx cmpl$32, %edx jne.L3 ret
[Bug bootstrap/63545] New: ICE building GCC hash_tablecselib_hasher,xcallocator::find_slot_with_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63545 Bug ID: 63545 Summary: ICE building GCC hash_tablecselib_hasher,xcallocator::find_slot_with_ hash Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: bill.klees at teamquest dot com Target: ia64-hp-hpux11.23 Created attachment 33726 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33726action=edit config log from ia64-hp-hpux11.23\hpux64\libgcc System -- HP-UX clhpux1i B.11.23 U ia64 Configure Line -- /shares/scratch/users/b/gcc/clhpux1i_32/gcc-4.9.1/./configure --prefix=/shares/source/itlinks/opt/hpux_ia64/11.2/32/gcc-4.9.1 --with-gmp=/opt/32/gmp-6.0.0 --with-mpfr=/opt/32/mpfr-3.1.2 --with-mpc=/opt/32/mpc-1.0.2 --enable-languages=c,c++ CC=/opt/32/gcc-4.7.4/bin/gcc CXX=/opt/32/gcc-4.7.4/bin/g++ --disable-bootstrap --with-gnu-as --with-as=/opt/binutils-2.24/bin/as --without-gnu-ld Error during build -- gmake[4]: Entering directory `/shares/scratch/users/b/gcc/clhpux1i_32/gcc491_debug/ia64-hp-hpux11.23/hpux64/libgcc' # If this is the top-level multilib, build all the other # multilibs. /u/scratch/users/b/gcc/clhpux1i_32/gcc491_debug/./gcc/xgcc -B/u/scratch/users/b/gcc/clhpux1i_32/gcc491_debug/./gcc/ -B/shares/source/itlinks/opt/hpux_ia64/11.2/32/gcc-4.9.1/ia64-hp-hpux11.23/bin/ -B/shares/source/itlinks/opt/hpux_ia64/11.2/32/gcc-4.9.1/ia64-hp-hpux11.23/lib/ -isystem /shares/source/itlinks/opt/hpux_ia64/11.2/32/gcc-4.9.1/ia64-hp-hpux11.23/include -isystem /shares/source/itlinks/opt/hpux_ia64/11.2/32/gcc-4.9.1/ia64-hp-hpux11.23/sys-include -g -O2 -mlp64 -O2 -g -O2 -DIN_GCC-DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../../.././gcc -I/shares/scratch/users/b/gcc/clhpux1i_32/gcc-4.9.1/./libgcc -I/shares/scratch/users/b/gcc/clhpux1i_32/gcc-4.9.1/./libgcc/. -I/shares/scratch/users/b/gcc/clhpux1i_32/gcc-4.9.1/./libgcc/../gcc -I/shares/scratch/users/b/gcc/clhpux1i_32/gcc-4.9.1/./libgcc/../include-o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /shares/scratch/users/b/gcc/clhpux1i_32/gcc-4.9.1/./libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /shares/scratch/users/b/gcc/clhpux1i_32/gcc-4.9.1/./libgcc/libgcc2.c: In function '__multi3': /shares/scratch/users/b/gcc/clhpux1i_32/gcc-4.9.1/./libgcc/libgcc2.c:557:1: internal compiler error: Segmentation fault } ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gmake[4]: *** [_muldi3.o] Error 1 gmake[4]: Leaving directory `/shares/scratch/users/b/gcc/clhpux1i_32/gcc491_debug/ia64-hp-hpux11.23/hpux64/libgcc' gmake[3]: *** [multi-do] Error 1 gmake[3]: Leaving directory `/shares/scratch/users/b/gcc/clhpux1i_32/gcc491_debug/ia64-hp-hpux11.23/libgcc' gmake[2]: *** [all-multi] Error 2 gmake[2]: Leaving directory `/shares/scratch/users/b/gcc/clhpux1i_32/gcc491_debug/ia64-hp-hpux11.23/libgcc' gmake[1]: *** [all-target-libgcc] Error 2 gmake[1]: Leaving directory `/shares/scratch/users/b/gcc/clhpux1i_32/gcc491_debug' gmake: *** [all] Error 2 Traceback from failure -- (gdb) bt #0 0x5830880 in unknown_procedure () warning: Attempting to unwind past bad PC 0x5830880 #1 0x555c170 in hash_tablecselib_hasher,xcallocator::find_slot_with_hash ( this=Unhandled dwarf expression opcode ) #2 0x4501220:0 in _ZL16cselib_find_slotP7rtx_defj13insert_option12machine_mode (x=Unhandled dwarf expression opcode ) #3 0x45013a0:0 in cselib_lookup (x=Unhandled dwarf expression opcode ) #4 0x4506460:0 in _ZL18cselib_record_setsP7rtx_def (insn=0x76d98a78) #5 0x450a3d0:0 in cselib_process_insn (insn=Unhandled dwarf expression opcode ) #6 0x52b6ab0:0 in _ZL18rest_of_handle_dsev () #7 0x49fe960:0 in execute_one_pass (pass=Unhandled dwarf expression opcode ) #8 0x49ff4a0:0 in execute_pass_list (pass=0x4027b710) #9 0x49ff500:0 in execute_pass_list (pass=0x4027aed0) #10 0x44de270:0 in _ZL15expand_functionP11cgraph_node (node=Unhandled dwarf expression opcode ) #11 0x44e3800:0 in compile () #12 0x44e4060:0 in finalize_compilation_unit () #13 0x4265f90:0 in c_write_global_declarations () #14 0x4bb8680:0 in _ZL12compile_filev () #15 0x4bbdb30:0 in toplev_main (argc=75, argv=0x7178) #16 0x5431a70:0 in main (argc=75, argv=0x7178) at /shares/scratch/users/b/gcc/clhpux1i_32/gcc-4.9.1/./gcc/main.c:37 Notes - The failed compilation step is: /u/scratch/users/b/gcc/clhpux1i_32/gcc491_debug/./gcc/xgcc -B/u/scratch/users/b/gcc/clhpux1i_32/gcc491_debug/./gcc/
[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432 --- Comment #30 from tejohnson at gcc dot gnu.org --- Author: tejohnson Date: Wed Oct 15 15:45:59 2014 New Revision: 216269 URL: https://gcc.gnu.org/viewcvs?rev=216269root=gccview=rev Log: 2014-10-15 Teresa Johnson tejohn...@google.com PR bootstrap/63432 * tree-ssa-threadupdate.c (recompute_probabilities): Better overflow checking. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
[Bug rtl-optimization/63448] [4.9/5 Regression] ICE when compiling atlas 3.10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448 --- Comment #9 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Wed Oct 15 15:48:33 2014 New Revision: 216270 URL: https://gcc.gnu.org/viewcvs?rev=216270root=gccview=rev Log: 2014-10-15 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/63448 * lra-int.h (LRA_MAX_CONSTRAINT_ITERATION_NUMBER): Remove. (LRA_MAX_ASSIGNMENT_ITERATION_NUMBER): New. (LRA_MAX_INHERITANCE_PASSES): Use it. (lra_constraint_iter_after_spill): Remove. (lra_assignment_iter): New. (lra_assignment_iter_after_spill): New. * lra-assigns.c (lra_assignment_iter): New. (lra_assignment_iter_after_spill): New. (former_reload_pseudo_spill_p): New. (spill_for): Set up former_reload_pseudo_spill_p. (setup_live_pseudos_and_spill_after_risky): Ditto. (assign_by_spills): Ditto. (lra_assign): Increment lra_assignment_iter. Print the iteration number. Reset former_reload_pseudo_spill_p. Check lra_assignment_iter_after_spill. * lra.c (lra): Remove lra_constraint_iter_after_spill. Initialize lra_assignment_iter and lra_assignment_iter_after_spill. * lra-constraints.c (lra_constraint_iter_after_spill): Remove. (lra_constraints): Remove code with lra_assignment_iter_after_spill. 2014-10-15 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/63448 * gcc.target/i386/pr63448.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr63448.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-assigns.c trunk/gcc/lra-constraints.c trunk/gcc/lra-int.h trunk/gcc/lra.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/63448] [4.9/5 Regression] ICE when compiling atlas 3.10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448 --- Comment #10 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Wed Oct 15 15:51:07 2014 New Revision: 216271 URL: https://gcc.gnu.org/viewcvs?rev=216271root=gccview=rev Log: 2014-10-15 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/63448 * lra-int.h (LRA_MAX_CONSTRAINT_ITERATION_NUMBER): Remove. (LRA_MAX_ASSIGNMENT_ITERATION_NUMBER): New. (LRA_MAX_INHERITANCE_PASSES): Use it. (lra_constraint_iter_after_spill): Remove. (lra_assignment_iter): New. (lra_assignment_iter_after_spill): New. * lra-assigns.c (lra_assignment_iter): New. (lra_assignment_iter_after_spill): New. (former_reload_pseudo_spill_p): New. (spill_for): Set up former_reload_pseudo_spill_p. (setup_live_pseudos_and_spill_after_risky): Ditto. (assign_by_spills): Ditto. (lra_assign): Increment lra_assignment_iter. Print the iteration number. Reset former_reload_pseudo_spill_p. Check lra_assignment_iter_after_spill. * lra.c (lra): Remove lra_constraint_iter_after_spill. Initialize lra_assignment_iter and lra_assignment_iter_after_spill. * lra-constraints.c (lra_constraint_iter_after_spill): Remove. (lra_constraints): Remove code with lra_assignment_iter_after_spill. 2014-10-15 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/63448 * gcc.target/i386/pr63448.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr63448.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/lra-assigns.c branches/gcc-4_9-branch/gcc/lra-constraints.c branches/gcc-4_9-branch/gcc/lra-int.h branches/gcc-4_9-branch/gcc/lra.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #10 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to Jakub Jelinek from comment #8) For -pg, at least for 32-bit -fpic, one way to handle this would be for !targetm.profile_before_prologue () crtl-profile in ix86_init_pic_reg instead of emitting set_got into the pic_offset_table_rtx emit set_got into %ebx hard reg and then copy %ebx to the pic_offset_table_rtx (to strongly hint RA that it better should allocate the pic register at the start of the function to %ebx). And then, when emitting prologue, see if the function doesn't start with set_got insn (after optional notes) loading into %ebx, and if it does, move the set_got insn right before the NOTE_INSN_PROLOGUE_END (on which final.c emits the _mcount call). That way, there will be just a single set_got, not two. If you don't find it for some reason (e.g. function that doesn't use PIC register otherwise, or something unexpected happened), make sure you treat %ebx as clobbered in the prologue and emit the set_got into %ebx directly right before NOTE_INSN_PROLOGUE_END. For -m64 -fpic -mcmodel=large -pg this will be harder, as init_pic_reg emits multiple instructions. Sounds reasonable. I also don't like 2 set_got one-by-one. However, we should ask Vladimir on how we can force RA allocate pseudo GOT on %ebx. I expect there should be an easier way to do this. And we should refer %ebx for pseudo GOT register in all 32bit cases. Right now we can emit second set_got and file a bug on potential performance improvement in RA. I've measured spec2000 o2 -fporfile-generate execution on train data on Corei7. Even with additional set_got there is: CINT +0,2 CFP +1,4 compared to a compiler before enabling ebx.
[Bug target/63542] My build log is full of non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63542 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) You are reporting this against trunk, right? Yes sorry about that I did not notice the version was set to 4.9 rather than 5.0
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #11 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Stupachenko Evgeny from comment #10) Sounds reasonable. I also don't like 2 set_got one-by-one. However, we should ask Vladimir on how we can force RA allocate pseudo GOT on %ebx. I expect there should be an easier way to do this. And we should refer %ebx for pseudo GOT register in all 32bit cases. Right now we can emit second set_got and file a bug on potential performance improvement in RA. The modification to IRA to get ebx for GOT pseudo could be not difficult. However it will not work. When I worked on modification RA for this project, I saw that RA gets info that ebx is clobbered by calls. I already wrote about this to Ilya. So this problem should be solved first. When the problem is solved, GOT pseudo will get the best hard reg (most probably ebx) and we will not need to do modification to RA to assign specifically ebx to GOT pseudo. I've measured spec2000 o2 -fporfile-generate execution on train data on Corei7. Even with additional set_got there is: CINT +0,2 CFP +1,4 compared to a compiler before enabling ebx.
[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302 --- Comment #21 from Jeffrey A. Law law at redhat dot com --- John, I know those PA boxes are slow, but if you could try Jakub's patch, it'd be appreciated. BTW, are you using strictly PA 2.0 (PA8000+) hardware? I was pondering doing a reimplementation of pa_combine_instructions using Bin's infrastructure for insn fusion as part of the review process for that code and having a box where I could do performance testing would be helpful. I can certainly test on PA8000+ hardware (assuming mine doesn't overheat), but fmpyadd/fmpysub tend to degrade performance on the more modern hardware. I guess I could look for a performance degradation and call that a victory since that would indicate we're doing a better job at fusing the independent FP mult and add/sub instructions.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #12 from Stupachenko Evgeny evstupac at gmail dot com ---
(In reply to Dominique d'Humieres from comment #9)
r216154 broke bootstrap on x86_64-apple-darwin13 too while building
libstdc++-v3:
libtool: compile: /opt/gcc/p_build/./gcc/xgcc -shared-libgcc
-B/opt/gcc/p_build/./gcc -nostdinc++
-L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/src
-L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/src/.libs
-L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/libsupc++/.
libs -B/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/bin/
-B/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/lib/ -isystem
/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/include -isystem
/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/sys-include -m32
-I/opt/gcc/p_work/libstdc++-v3/../libgcc
-I/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/include/
x86_64-apple-darwin13.4.0
-I/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/include
-I/opt/gcc/p_work/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -fvisibility-inlines-hidden
-ffunction-sections -fdata-sections -frandom-seed=atexit_thread.lo -g -O2
-m32 -std=gnu++11 -c
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc -fno-common
-DPIC -D_GLIBCXX_SHARED -o atexit_thread.o
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc: In function
'void {anonymous}::key_init()':
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc:111:3:
internal compiler error: in cselib_invalidate_regno, at cselib.c:2146
}
^
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc:111:3:
internal compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1plus)
We are trying to reproduce the issue. Can you please send me/attach rtl dumps
on the fail?
[Bug middle-end/58624] gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58624 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Oct 15 16:46:11 2014 New Revision: 216273 URL: https://gcc.gnu.org/viewcvs?rev=216273root=gccview=rev Log: PR c++/58624 * pt.c (tsubst_copy_and_build) [VAR_DECL]: Use TLS wrapper. * semantics.c (finish_id_expression): Don't call TLS wrapper in a template. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/tls/thread_local10.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/pt.c branches/gcc-4_8-branch/gcc/cp/semantics.c
[Bug c++/63455] [4.8/4.9/5 Regression] decltype of statement expression internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:25062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63455 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Oct 15 16:46:35 2014 New Revision: 216277 URL: https://gcc.gnu.org/viewcvs?rev=216277root=gccview=rev Log: PR c++/63455 Revert: * parser.c (cp_parser_abort_tentative_parse): Make sure we haven't committed to this tentative parse. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/ext/stmtexpr16.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/parser.c
[Bug c++/56710] Using reserved double underscore variable name in a lambda causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56710 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Oct 15 16:46:23 2014 New Revision: 216275 URL: https://gcc.gnu.org/viewcvs?rev=216275root=gccview=rev Log: PR c++/56710 * semantics.c (finish_member_declaration): Don't push closure members. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-names1.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/semantics.c
[Bug c++/63415] [4.9/5 Regression] internal compiler error: unexpected expression ‘static_castint(std::is_sameT, A1{})’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63415 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Oct 15 16:46:29 2014 New Revision: 216276 URL: https://gcc.gnu.org/viewcvs?rev=216276root=gccview=rev Log: PR c++/63415 * pt.c (value_dependent_expression_p) [CONSTRUCTOR]: Check the type. (iterative_hash_template_arg): Likewise. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-initlist8.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/pt.c
[Bug c++/63415] [4.9/5 Regression] internal compiler error: unexpected expression ‘static_castint(std::is_sameT, A1{})’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63415 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.9.2 |4.8.4 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org --- Fixing the error in 4.8 as well.
[Bug c++/63455] [4.8/4.9/5 Regression] decltype of statement expression internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:25062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63455 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Fixed properly for GCC 5, just removed the assert for 4.8/4.9.
[Bug lto/62026] [5 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026
--- Comment #17 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Here's a new testcase that fails on ppc64 even with the patch from comment 15
applied to trunk.
trippels@gcc1-power7 genrb % cat timezone.ii
class UnicodeString
{
public:
void m_fn1 ();
} a;
void
fn1 ()
{
static int b = 0;
a.m_fn1 ();
}
trippels@gcc1-power7 genrb % /home/trippels/gcc_test/usr/local/bin/c++ -flto=32
-ffunction-sections -fdata-sections -std=gnu++0x -g -O2 -r -nostdlib
timezone.ii
lto1: internal compiler error: Segmentation fault
0x1063d46b crash_signal
../../gcc/gcc/toplev.c:340
0x104ed8c4 lto_get_decl_name_mapping(lto_file_decl_data*, char const*)
../../gcc/gcc/lto-section-in.c:340
0x1098f447 varpool_node::get_constructor()
../../gcc/gcc/varpool.c:280
0x1098f447 varpool_node::get_constructor()
../../gcc/gcc/varpool.c:264
0x10981c4f get_variable_section(tree_node*, bool)
../../gcc/gcc/varasm.c:1121
0x10983ae3 get_block_for_decl
../../gcc/gcc/varasm.c:1194
0x1098663b make_decl_rtl(tree_node*)
../../gcc/gcc/varasm.c:1419
0x10989f43 make_decl_rtl_for_debug(tree_node*)
../../gcc/gcc/varasm.c:1467
0x102523f7 rtl_for_decl_location
../../gcc/gcc/dwarf2out.c:15760
0x102871e7 loc_list_from_tree
../../gcc/gcc/dwarf2out.c:14391
0x1028dc13 add_location_or_const_value_attribute
../../gcc/gcc/dwarf2out.c:15892
0x1028dc13 add_location_or_const_value_attribute
../../gcc/gcc/dwarf2out.c:15836
0x10297707 dwarf2out_finish
../../gcc/gcc/dwarf2out.c:24243
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.
make: *** [/home/trippels/tmp/ccC9suVr.ltrans0.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/home/trippels/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug lto/62026] [5 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026 --- Comment #18 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Wed Oct 15 17:01:08 2014 New Revision: 216278 URL: https://gcc.gnu.org/viewcvs?rev=216278root=gccview=rev Log: PR lto/62026 * lto/pr62026.C: New testcase. * cgraphclones.c (duplicate_thunk_for_node): Get body to have args to duplicate. * lto-streamer-out.c (lto_output): Handle correctly thunks that was born at WPA time. Added: trunk/gcc/testsuite/g++.dg/lto/pr62026.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphclones.c trunk/gcc/lto-streamer-out.c trunk/gcc/testsuite/ChangeLog
[Bug lto/62026] [5 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026 --- Comment #19 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Program received signal SIGSEGV, Segmentation fault. lto_get_decl_name_mapping (decl_data=0x0, name=0x3fffaf6d4580 _ZZ3fn1vE1b) at ../../gcc/gcc/lto-section-in.c:340 340 ../../gcc/gcc/lto-section-in.c: No such file or directory. (gdb) bt #0 lto_get_decl_name_mapping (decl_data=0x0, name=0x3fffaf6d4580 _ZZ3fn1vE1b) at ../../gcc/gcc/lto-section-in.c:340 #1 0x1098f448 in get_constructor (this=0x3fffaf890080) at ../../gcc/gcc/varpool.c:280 #2 varpool_node::get_constructor (this=0x3fffaf890080) at ../../gcc/gcc/varpool.c:264 #3 0x10981c50 in get_variable_section (decl=0x3fffaf7003f0, prefer_noswitch_p=optimized out) at ../../gcc/gcc/varasm.c:1121 #4 0x10983ae4 in get_block_for_decl (decl=decl@entry=0x3fffaf7003f0) at ../../gcc/gcc/varasm.c:1194 #5 0x1098663c in make_decl_rtl (decl=0x3fffaf7003f0) at ../../gcc/gcc/varasm.c:1419 #6 0x10989f44 in make_decl_rtl_for_debug (decl=0x3fffaf7003f0) at ../../gcc/gcc/varasm.c:1467 #7 0x102523f8 in rtl_for_decl_location (decl=decl@entry=0x3fffaf7003f0) at ../../gcc/gcc/dwarf2out.c:15760 #8 0x102871e8 in loc_list_from_tree (loc=loc@entry=0x3fffaf7003f0, want_address=optimized out) at ../../gcc/gcc/dwarf2out.c:14391 #9 0x1028dc14 in add_location_or_const_value_attribute (attr=DW_AT_location, cache_p=optimized out, decl=0x3fffaf7003f0, die=0x3fffaf880230) at ../../gcc/gcc/dwarf2out.c:15892 #10 add_location_or_const_value_attribute (die=0x3fffaf880230, decl=0x3fffaf7003f0, cache_p=cache_p@entry=false, attr=DW_AT_location) at ../../gcc/gcc/dwarf2out.c:15836 #11 0x10297708 in dwarf2out_finish (filename=0x112f2440 /home/trippels/tmp/ccZV1IhN.ltrans0.o) at ../../gcc/gcc/dwarf2out.c:24243 #12 0x1063dd80 in compile_file () at ../../gcc/gcc/toplev.c:602 #13 0x10640844 in do_compile () at ../../gcc/gcc/toplev.c:1973 #14 toplev_main (argc=22, argv=0x112f2860) at ../../gcc/gcc/toplev.c:2049 #15 0x10101730 in main (argc=optimized out, argv=optimized out) at ../../gcc/gcc/main.c:36 (gdb) up #1 0x1098f448 in get_constructor (this=0x3fffaf890080) at ../../gcc/gcc/varpool.c:280 280 ../../gcc/gcc/varpool.c: No such file or directory. (gdb) up #2 varpool_node::get_constructor (this=0x3fffaf890080) at ../../gcc/gcc/varpool.c:264 264 in ../../gcc/gcc/varpool.c (gdb) up #3 0x10981c50 in get_variable_section (decl=0x3fffaf7003f0, prefer_noswitch_p=optimized out) at ../../gcc/gcc/varasm.c:1121 1121../../gcc/gcc/varasm.c: No such file or directory. (gdb) p debug_tree(decl) var_decl 0x3fffaf7003f0 b type integer_type 0x3fffaf6b07e0 int asm_written public SI size integer_cst 0x3fffaf681380 constant 32 unit size integer_cst 0x3fffaf681398 constant 4 align 32 symtab 16383 alias set -1 canonical type 0x3fffaf6b07e0 precision 32 min integer_cst 0x3fffaf681338 -2147483648 max integer_cst 0x3fffaf681350 2147483647 pointer_to_this pointer_type 0x3fffaf6b1848 static SI file timezone.ii line 9 col 14 size integer_cst 0x3fffaf681380 32 unit size integer_cst 0x3fffaf681398 4 align 32 context function_decl 0x3fffaf843018 fn1 initial error_mark 0x3fffaf681128 $1 = void
[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529 --- Comment #7 from russelldub at gmail dot com --- (In reply to Dominique d'Humieres from comment #6) AFAICT the ICE with REAL :: ptee1(10) has been fixed for gfortran 4.9.1 and above (also for 4.8.4). I can't easily test with either of those, but the ICE doesn't happen for me with a trunk build, so I guess that's OK. I also think the error for REAL :: ptee1(*) is right. Whether or not the assumed size array is allowed is one question. I don't know the answer but I can say that both ifort and pgf95 think it's fine. I can't find a definitive answer in the standards, but as cray-pointers aren't part of the standard, it's probably not the right way to handle that question. The second question is whether the emitted error is sufficient to allow one to fix the problem. It's true that omitting -fcray-pointer from the arguments does give a more informative error, but I would have tried a lot of other things before getting to that as I am trying to compile code that depends on cray pointers. It would be much better if the informative error showing the actual location of the issue was emitted when using -fcray-pointer.
[Bug c++/63528] A variadic variable template cannot use the ::value of a variadic trait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63528 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Oct 15 17:42:07 2014 New Revision: 216279 URL: https://gcc.gnu.org/viewcvs?rev=216279root=gccview=rev Log: PR c++/63528 * pt.c (lookup_template_variable): Call coerce_template_parms. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug bootstrap/63536] [5 Regression] bootstrap failed when configured with --with-cpu=slm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63536 --- Comment #5 from iverbin at gcc dot gnu.org --- Author: iverbin Date: Wed Oct 15 17:49:27 2014 New Revision: 216280 URL: https://gcc.gnu.org/viewcvs?rev=216280root=gccview=rev Log: PR target/63536 gcc/java/ * lang.c (java_print_error_function): Add check on NULL function context. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/lang.c
[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Attachment #33721|0 |1 is obsolete|| --- Comment #28 from Oleg Endo olegendo at gcc dot gnu.org --- Created attachment 33727 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33727action=edit Using virtual FPSCR registers to model insn dependencies (In reply to Oleg Endo from comment #27) Created attachment 33721 [details] Using virtual FPSCR registers to model insn dependencies Updated patch that avoids the single_set problems by using (clobber (reg:SI FPSCR_STAT_REG)) instead of a set. This also eliminates the fsca pattern changes in the previous patch. Since the 'fpu_switch' insn is still a multiple set insn, it won't be used for delay slot stuffing, but this is a minor issue that can be addressed later. I'm testing the patch now on sh-sim. At least 'make all' works. Testing for '-m4 -ml' and '-m4 -mb' shows one new failure (ignoring the ISR failures): FAIL: gcc.c-torture/execute/pr28982a.c -O1 (internal compiler error) FAIL: gcc.c-torture/execute/pr28982a.c -O1 (test for excess errors) The problem is the define_split and the peephole2 patterns below the fpu_switch insn. I don't know how/if that was working before. I've removed the peephole2 pattern and rewrote the split pattern, which fixes the failure above. I'll re-test the whole thing again.
[Bug go/59432] [4.9/5 regression] sync/atomic FAILs on 32bit x86 systems without .cfi directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432 --- Comment #14 from uros at gcc dot gnu.org --- Author: uros Date: Wed Oct 15 17:57:17 2014 New Revision: 216281 URL: https://gcc.gnu.org/viewcvs?rev=216281root=gccview=rev Log: PR go/59432 * config/i386/sync.md (atomic_compare_and_swapdwi_doubleword): Remove the second alternative. (regprefix): Remove mode attribute. (atomic_compare_and_swapmode): Do not fixup operand 2. * config/i386/predicates.md (cmpxchg8b_pic_memory_operand): Remove. Revert: 2013-11-05 Ian Lance Taylor i...@google.com * config/i386/sync.md (atomic_compare_and_swapdwi_doubleword): If possible, add .cfi directives to record change to bx. * config/i386/i386.c (ix86_emit_cfi): New function. * config/i386/i386-protos.h (ix86_emit_cfi): Declare. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/predicates.md trunk/gcc/config/i386/sync.md
[Bug lto/63546] New: ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546
Bug ID: 63546
Summary: ICE: Segmentation fault in lto_get_decl_name_mapping
on ppc64
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
trippels@gcc1-power7 ~ % cat timezone.ii
class UnicodeString
{
public:
void m_fn1 ();
} a;
void
fn1 ()
{
static int b = 0;
a.m_fn1 ();
}
trippels@gcc1-power7 ~ % /home/trippels/gcc_test/usr/local/bin/c++ -flto
-fdata-sections -g -O2 -r -nostdlib timezone.ii
lto1: internal compiler error: Segmentation fault
0x1063d46b crash_signal
../../gcc/gcc/toplev.c:340
0x104ed8c4 lto_get_decl_name_mapping(lto_file_decl_data*, char const*)
../../gcc/gcc/lto-section-in.c:340
0x1098f447 varpool_node::get_constructor()
../../gcc/gcc/varpool.c:280
0x1098f447 varpool_node::get_constructor()
../../gcc/gcc/varpool.c:264
0x10981c4f get_variable_section(tree_node*, bool)
../../gcc/gcc/varasm.c:1121
0x10983ae3 get_block_for_decl
../../gcc/gcc/varasm.c:1194
0x1098663b make_decl_rtl(tree_node*)
../../gcc/gcc/varasm.c:1419
0x10989f43 make_decl_rtl_for_debug(tree_node*)
../../gcc/gcc/varasm.c:1467
0x102523f7 rtl_for_decl_location
../../gcc/gcc/dwarf2out.c:15760
0x102871e7 loc_list_from_tree
../../gcc/gcc/dwarf2out.c:14391
0x1028dc13 add_location_or_const_value_attribute
../../gcc/gcc/dwarf2out.c:15892
0x1028dc13 add_location_or_const_value_attribute
../../gcc/gcc/dwarf2out.c:15836
0x10297707 dwarf2out_finish
../../gcc/gcc/dwarf2out.c:24243
Please submit a full bug report,
with preprocessed source if appropriate.
(gdb) up
#3 0x10981c50 in get_variable_section (decl=0x3fffaf7003f0,
prefer_noswitch_p=optimized out) at ../../gcc/gcc/varasm.c:1121
1121../../gcc/gcc/varasm.c: No such file or directory.
(gdb) p debug_tree(decl)
var_decl 0x3fffaf7003f0 b
type integer_type 0x3fffaf6b07e0 int asm_written public SI
size integer_cst 0x3fffaf681380 constant 32
unit size integer_cst 0x3fffaf681398 constant 4
align 32 symtab 16383 alias set -1 canonical type 0x3fffaf6b07e0
precision 32 min integer_cst 0x3fffaf681338 -2147483648 max integer_cst
0x3fffaf681350 2147483647
pointer_to_this pointer_type 0x3fffaf6b1848
static SI file timezone.ii line 9 col 14 size integer_cst 0x3fffaf681380
32 unit size integer_cst 0x3fffaf681398 4
align 32 context function_decl 0x3fffaf843018 fn1 initial error_mark
0x3fffaf681128
$1 = void
[Bug lto/62026] [5 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed. I've opened PR63546 for the new issue on ppc64.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 33728 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33728action=edit Compressed tar of the files produced with -fdump-rtl-all
[Bug lto/63547] New: --disable-lto with configure creates and installs lto-wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63547 Bug ID: 63547 Summary: --disable-lto with configure creates and installs lto-wrapper Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: jb999 at gmx dot de It seems pointless to have lto-wrapper compiled and installed when configuring --disable-lto.
[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302 --- Comment #22 from dave.anglin at bell dot net --- On 10/15/2014 12:19 PM, law at redhat dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302 --- Comment #21 from Jeffrey A. Law law at redhat dot com --- John, I know those PA boxes are slow, but if you could try Jakub's patch, it'd be appreciated. I started a build and check on hppa2.0w-hp-hpux11.11. Will take a day or so for full build and check. Jakub's patch appears to fix ldil.c testcase. BTW, are you using strictly PA 2.0 (PA8000+) hardware? I was pondering doing a reimplementation of pa_combine_instructions using Bin's infrastructure for insn fusion as part of the review process for that code and having a box where I could do performance testing would be helpful. Almost all my testing is on PA 2.0 hardware. I have a c8000, rp3440 and c3750 at home. Mostly use the rp3440. Probably, the best machine to use for development is sibaris (4-way 1 GHz c8000 linux). It's our primary buildd machine but others have used it for development testing. I'll check with Helge Deller who manages the machine and get back. I can certainly test on PA8000+ hardware (assuming mine doesn't overheat), but fmpyadd/fmpysub tend to degrade performance on the more modern hardware. I guess I could look for a performance degradation and call that a victory since that would indicate we're doing a better job at fusing the independent FP mult and add/sub instructions. Dave
[Bug target/58945] Improve atomic_compare_and_swap*_doubleword pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58945 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Attachment #33470|0 |1 is obsolete|| --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 33729 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33729action=edit Updated patch to simplify atomic_compare_and_swapdwi_doubleword pattern Patched mainline gcc at revision 216266 still fails to compile the testcase. Updated patch attached.
[Bug go/59432] [4.9/5 regression] sync/atomic FAILs on 32bit x86 systems without .cfi directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.9.2 |5.0 --- Comment #15 from Uroš Bizjak ubizjak at gmail dot com --- Fixed for 5.0.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #14 from Igor Zamyatin izamyatin at gmail dot com --- Thanks! That's define_insn_and_split nonlocal_goto_receiver where the issue comes from. Seems now we need to handle this split somewhat similar to the second approach in solving of the profiling issue
[Bug c++/53000] Conditional operator does not behave as standardized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000 --- Comment #29 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Paolo Carlini from comment #28) Something is going wrong here: the bug is closed as fixed, but if I try to enable in 20_util/common_type/requirements/sfinae_friendly_1.cc the lines which require the bug to be fixed to pass, I'm still seeing a failure, for the line: static_assert(is_typestd::common_typeconst Ukn, volatile Ukn, Ukn(), ); Maybe Daniel or Jason can clarify?? Comparing this test with the current wording in 5.16 the assertion looks incorrect and should be doomed to fail - sorry! I'll check the remaining ones and will suggest a patch for it.
[Bug tree-optimization/63537] [4.8/4.9/5 Regression] Missed optimization: Loop unrolling adds extra copy when returning aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63537
--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
Eventually a simple pass could handle
retval = ret;
ret ={v} {CLOBBER};
return retval;
and back-propagate retval into all stores/loads of ret.
Shouldn't tree-nrv.c already handle this, except that it currently bails out if
TREE_ADDRESSABLE (found)? (strangely enough it has (dead) code to handle the
addressable case further in the same function)
[Bug libstdc++/63500] [4.9/5 Regression] bug in debug version of std::make_move_iterator?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63500 --- Comment #7 from François Dumont fdumont at gcc dot gnu.org --- Author: fdumont Date: Wed Oct 15 20:40:31 2014 New Revision: 216286 URL: https://gcc.gnu.org/viewcvs?rev=216286root=gccview=rev Log: 2014-10-15 François Dumont fdum...@gcc.gnu.org Jonathan Wakely jwak...@redhat.com PR libstdc++/63500 * include/debug/functions.h (__foreign_iterator_aux2): Do not check for foreign iterators if input iterators returns rvalue reference. * testsuite/23_containers/vector/63500.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/vector/63500.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/debug/functions.h
[Bug libstdc++/63500] [4.9/5 Regression] bug in debug version of std::make_move_iterator?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63500 François Dumont fdumont at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #8 from François Dumont fdumont at gcc dot gnu.org --- For now we just skip the check when input iterator do not expose lvalue reference. Thanks for the report.
[Bug c++/53000] Conditional operator does not behave as standardized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000 --- Comment #30 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Oct 15 21:08:59 2014 New Revision: 216287 URL: https://gcc.gnu.org/viewcvs?rev=216287root=gccview=rev Log: 2014-10-15 Daniel Krugler daniel.krueg...@gmail.com * testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc: Enable tests predicated on PR c++/53000. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc
[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #29 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Oleg Endo from comment #28) Created attachment 33727 [details] Using virtual FPSCR registers to model insn dependencies The problem is the define_split and the peephole2 patterns below the fpu_switch insn. I don't know how/if that was working before. I've removed the peephole2 pattern and rewrote the split pattern, which fixes the failure above. I'll re-test the whole thing again. With this patch there are no new failures for -m4 -ml and -m4 -mb here, except the ISR failures. I'll also test it for the other combinations later. I'd like to get the current sh4 working version first. Then fix other niche problems with ISRs or SH2E. Kaz, what do you think?
[Bug rtl-optimization/63548] New: redundent reload in loop after removing regmove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63548 Bug ID: 63548 Summary: redundent reload in loop after removing regmove Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wmi at google dot com Created attachment 33730 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33730action=edit testcase 1.c For program with many insns like a = b + c, where operands b and c are both dead immediately after the add insn, the hardreg preference heuristic seems not perfect. Here is a testcase 1.c, For gcc after r204212, they generates two redundent reload insns caused by imperfect hardreg preference heuristic in IRA. ~/workarea/gcc-r214579/build/install/bin/gcc -O2 -S 1.c .L5: movl%ebx, %edi callgoo leal2(%rbx), %edi movl%eax, %r13d callgoo leal4(%rbx), %edi movl%eax, %r12d callgoo leal6(%rbx), %edi movl%eax, %ebp addl$1, %ebx callgoo movl%eax, %edx // redundent mov movl%r13d, %eax// redundent mov imull %r12d, %eax imull %ebp, %eax imull %edx, %eax addl%eax, total(%rip) cmpl%ebx, M(%rip) jg .L5 For old gcc with regmove, it happens to be better than hardreg preference heuristic and generates one redundent reload. ~/workarea/gcc-r199418/build/install/bin/gcc -O2 -S 1.c .L3: movl%ebx, %edi callgoo leal2(%rbx), %edi movl%eax, %r13d callgoo leal4(%rbx), %edi movl%eax, %r12d callgoo leal6(%rbx), %edi movl%eax, %ebp addl$1, %ebx callgoo movl%r13d, %edx// redundent mov imull %r12d, %edx imull %ebp, %edx imull %eax, %edx addl%edx, total(%rip) cmpl%ebx, M(%rip) jg .L3 llvm generates no redundent move insn. clang-r217862 -O2 -S 1.c .LBB0_2: movl%ebx, %edi callq goo movl%eax, %r14d leal2(%rbx), %edi callq goo movl%eax, %ebp leal4(%rbx), %edi callq goo movl%eax, %r15d leal6(%rbx), %edi callq goo imull %r14d, %ebp imull %r15d, %ebp imull %eax, %ebp addl%ebp, total(%rip) incl%ebx cmplM(%rip), %ebx jl .LBB0_2
[Bug tree-optimization/63530] GCC generates incorrect aligned store on ARM after the loop is unrolled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63530
--- Comment #2 from Cong Hou congh at google dot com ---
This issue can also be reproduced on x86_64. Compile the following code with
options (assume the file name is t.c): -O2 -ftree-vectorize t.c
-fdump-tree-all-alias
#include stdlib.h
typedef struct {
unsigned char map[256];
int i;
} A, *AP;
AP foo(int n)
{
AP b = malloc(sizeof(A));
int i;
for (i = n; i 256; i++)
b-map[i] = i;
return b;
}
The from t.c.116t.vect we can find such a statement:
# ALIGN = 8, MISALIGN = 0
vectp_b.15_47 = b_5 + _48;
Here b_5 is obtained from malloc which can be 8 bytes aligned, but _48 is from
input parameter n, and the alignment of vectp_b.15_47 should be unknown instead
of 8 here. I suspect the ptr_info_def object of vectp_b.15_47 is just copied
from that of b_5, which is incorrect.
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 Andre Netzeband andre at netzeband dot eu changed: What|Removed |Added CC||andre at netzeband dot eu --- Comment #9 from Andre Netzeband andre at netzeband dot eu --- Hello I'm using MingW64 with GCC 4.9.1 (x86_64-4.9.1-posix-seh-rt_v3-rev1) and tried to precompile some Boost Headers to speed up compiling. Unfortunately I get the same error described here: It crashed and windows just show the following information: Problemereignisname:APPCRASH Anwendungsname:cc1plus.exe Anwendungsversion:0.0.0.0 Anwendungszeitstempel: Fehlermodulname:cc1plus.exe Fehlermodulversion:0.0.0.0 Fehlermodulzeitstempel: Ausnahmecode:c005 Ausnahmeoffset:00923688 Betriebsystemversion:6.1.7601.2.1.0.256.48 Gebietsschema-ID:1031 Zusatzinformation 1:50fa Zusatzinformation 2:50fa4f6a0bed1a7f9bb7018c9ff4ca3f Zusatzinformation 3:7510 Zusatzinformation 4:751099e505bceb2fa8cbac2f21c93fb2 This issue was reported over one year ago. Was there any progress?
[Bug c/63549] New: ICE in build_array_ref with invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63549 Bug ID: 63549 Summary: ICE in build_array_ref with invalid code Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org While reducing a testcase for a different bug I ran into this ICE. Testcase: enum processor_type ix86_cpu; const processor_alias_table[] = align_functions = 1 i; align_loops = processor_target_table[ix86_cpu].align_loop; Reduced from SPEC 2006's gcc. This produces the following output: pinskia@server:~$ ~/local-gcc/bin/gcc t.i t.i:3:6: error: ‘align_functions’ undeclared here (not in a function) align_functions = 1 i; ^ t.i:3:29: error: ‘i’ undeclared here (not in a function) align_functions = 1 i; ^ t.i:4:7: warning: data definition has no type or storage class align_loops = processor_target_table[ix86_cpu].align_loop; ^ t.i:4:21: error: ‘processor_target_table’ undeclared here (not in a function) align_loops = processor_target_table[ix86_cpu].align_loop; ^ t.i:4:7: error: ‘ix86_cpu’ has an incomplete type align_loops = processor_target_table[ix86_cpu].align_loop; ^ t.i:4:7: internal compiler error: in build_array_ref, at c/c-typeck.c:2482 0x5a87c8 build_array_ref(unsigned int, tree_node*, tree_node*) /home/pinskia/src/local/gcc/gcc/c/c-typeck.c:2482 0x5c8964 c_parser_postfix_expression_after_primary /home/pinskia/src/local/gcc/gcc/c/c-parser.c:7742 0x5bc686 c_parser_postfix_expression /home/pinskia/src/local/gcc/gcc/c/c-parser.c:7607 0x5beb6a c_parser_unary_expression /home/pinskia/src/local/gcc/gcc/c/c-parser.c:6534 0x5c47ff c_parser_cast_expression /home/pinskia/src/local/gcc/gcc/c/c-parser.c:6372 0x5c49e4 c_parser_binary_expression /home/pinskia/src/local/gcc/gcc/c/c-parser.c:6187 0x5c5545 c_parser_conditional_expression /home/pinskia/src/local/gcc/gcc/c/c-parser.c:5963 0x5c5b10 c_parser_expr_no_commas /home/pinskia/src/local/gcc/gcc/c/c-parser.c:5881 0x5ce7f9 c_parser_initializer /home/pinskia/src/local/gcc/gcc/c/c-parser.c:4141 0x5d19bf c_parser_declaration_or_fndef /home/pinskia/src/local/gcc/gcc/c/c-parser.c:1799 0x5db2d7 c_parser_external_declaration /home/pinskia/src/local/gcc/gcc/c/c-parser.c:1427 0x5dbb99 c_parser_translation_unit /home/pinskia/src/local/gcc/gcc/c/c-parser.c:1314 0x5dbb99 c_parse_file() /home/pinskia/src/local/gcc/gcc/c/c-parser.c:14348 0x62f8d2 c_common_parse_file() /home/pinskia/src/local/gcc/gcc/c-family/c-opts.c:1043 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401 --- Comment #12 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #11) Kaz, could you please add the attached patch to your test run? No new failures for the top level make -k check on sh4-unknown-linux-gnu.
[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #30 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #29) With this patch there are no new failures for -m4 -ml and -m4 -mb here, except the ISR failures. I'll also test it for the other combinations later. I'd like to get the current sh4 working version first. Then fix other niche problems with ISRs or SH2E. Kaz, what do you think? Sounds reasonable. Please go ahead.
[Bug c++/63550] New: Multiple definition errors occur only with -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63550
Bug ID: 63550
Summary: Multiple definition errors occur only with -fgnu-tm
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: spear at cse dot lehigh.edu
Templates instantiated within transactions from multiple files result in
multiple-definition errors at link time. Errors do not occur when compiling
without TM, or when all source files are concatenated. Should these symbols be
emitted as weak?
The smallest testcase entails two files, each of which instantiates
std::vectorint and uses the initializer list constructor. #define is used to
show behavior with and without instantiation from within a transaction.
f1.cc:
#include vector
#ifdef USE_TM
#define TX __transaction_atomic
#else
#define TX
#endif
std::vectorint* v1;
void test1() {
TX {
// make a vector with some elements in it
v1 = new std::vectorint({1, 2, 3, 4, 5});
}
}
int main(int argc, char** argv) { }
f2.cc:
#include vector
#ifdef USE_TM
#define TX __transaction_atomic
#else
#define TX
#endif
std::vectorint* v2;
void test2() {
TX {
v2 = new std::vectorint({11, 13, 15, 17});
}
}
The following script builds the two files four ways: with and without
instantation of std::vectorint({...}) within a transaction; and with and
without multiple .cc files.
build.sh:
echo Building from 2 files, no TM
g++ f1.cc f2.cc -std=c++11 -fgnu-tm -o no_tm_2_file.exe
echo Building from 2 files, TM
g++ -DUSE_TM f1.cc f2.cc -std=c++11 -fgnu-tm -o yes_tm_2_file.exe
echo Building from 1 file, no TM
cat f1.cc f2.cc f.cc; g++ f.cc -std=c++11 -fgnu-tm -o no_tm_1_file.exe; rm
f.cc
echo Building from 1 file, TM
cat f1.cc f2.cc f.cc; g++ -DUSE_TM f.cc -std=c++11 -fgnu-tm -o
yes_tm_1_file.exe; rm f.cc
Link errors occur only in one case. Other three cases produce executables:
Output:
sh build.sh
Building from 2 files, no TM
Building from 2 files, TM
/tmp/cchUc9zn.o: In function `transaction clone for std::vectorint,
std::allocatorint ::vector(std::initializer_listint, std::allocatorint
const)':
f2.cc:(.text+0x1b4): multiple definition of `transaction clone for
std::vectorint, std::allocatorint ::vector(std::initializer_listint,
std::allocatorint const)'
/tmp/ccvjPFgv.o:f1.cc:(.text+0x1c6): first defined here
/tmp/cchUc9zn.o: In function `transaction clone for
std::allocatorint::allocator() [clone .localalias.31]':
f2.cc:(.text+0x180): multiple definition of `transaction clone for
std::allocatorint::allocator()'
/tmp/ccvjPFgv.o:f1.cc:(.text+0x192): first defined here
/tmp/cchUc9zn.o: In function `transaction clone for
std::allocatorint::~allocator() [clone .localalias.30]':
f2.cc:(.text+0x19a): multiple definition of `transaction clone for
std::allocatorint::~allocator()'
/tmp/ccvjPFgv.o:f1.cc:(.text+0x1ac): first defined here
/tmp/cchUc9zn.o: In function `transaction clone for
__gnu_cxx::new_allocatorint::new_allocator() [clone .localalias.29]':
f2.cc:(.text+0x24a): multiple definition of `transaction clone for
__gnu_cxx::new_allocatorint::new_allocator()'
/tmp/ccvjPFgv.o:f1.cc:(.text+0x25c): first defined here
/tmp/cchUc9zn.o: In function `transaction clone for
__gnu_cxx::new_allocatorint::~new_allocator() [clone .localalias.28]':
f2.cc:(.text+0x254): multiple definition of `transaction clone for
__gnu_cxx::new_allocatorint::~new_allocator()'
/tmp/ccvjPFgv.o:f1.cc:(.text+0x266): first defined here
/tmp/cchUc9zn.o: In function `transaction clone for std::_Vector_baseint,
std::allocatorint ::_Vector_base(std::allocatorint const) [clone
.localalias.27]':
f2.cc:(.text+0x25e): multiple definition of `transaction clone for
std::_Vector_baseint, std::allocatorint ::_Vector_base(std::allocatorint
const)'
/tmp/ccvjPFgv.o:f1.cc:(.text+0x270): first defined here
/tmp/cchUc9zn.o: In function `transaction clone for std::_Vector_baseint,
std::allocatorint ::~_Vector_base() [clone .localalias.23]':
f2.cc:(.text+0x3a4): multiple definition of `transaction clone for
std::_Vector_baseint, std::allocatorint ::~_Vector_base()'
/tmp/ccvjPFgv.o:f1.cc:(.text+0x3b6): first defined here
/tmp/cchUc9zn.o: In function `transaction clone for std::_Vector_baseint,
std::allocatorint ::_Vector_impl::_Vector_impl(std::allocatorint const)
[clone .localalias.22]':
f2.cc:(.text+0x412): multiple definition of `transaction clone for
std::_Vector_baseint, std::allocatorint
::_Vector_impl::_Vector_impl(std::allocatorint const)'
/tmp/ccvjPFgv.o:f1.cc:(.text+0x424): first defined here
/tmp/cchUc9zn.o: In function `transaction clone for std::_Vector_baseint,
std::allocatorint ::_Vector_impl::~_Vector_impl() [clone .localalias.15]':
f2.cc:(.text+0x58c): multiple definition of `transaction clone for
std::_Vector_baseint, std::allocatorint ::_Vector_impl::~_Vector_impl()'
/tmp/ccvjPFgv.o:f1.cc:(.text+0x59e): first
[Bug tree-optimization/63551] New: wrong code (segfaults) at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63551
Bug ID: 63551
Summary: wrong code (segfaults) at -Os on x86_64-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk (as well as 4.9.x) miscompiles the following code on
x86_64-linux at -Os in both 32-bit and 64-bit modes.
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20141014 (experimental) [trunk revision 216217] (GCC)
$
$ gcc-trunk -O1 small.c; a.out
$
$ gcc-trunk -Os small.c
$ ./a.out
Segmentation fault (core dumped)
$
---
union U
{
unsigned int f0;
int f1;
};
int a, d;
void
fn1 (union U p)
{
if (p.f1 = 0)
if (a)
d = 0;
}
void
fn2 ()
{
d = 0;
union U b = { 4294967286 };
fn1 (b);
}
int
main ()
{
fn2 ();
return 0;
}
[Bug middle-end/61848] [5 Regression] a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|amodra at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug fortran/63552] New: [OOP] Type-bound procedures rejected as actual argument to dummy procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552 Bug ID: 63552 Summary: [OOP] Type-bound procedures rejected as actual argument to dummy procedure Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org The following code compiles with, e.g., Cray's ftn but fails with gfortran 5 with: call co_reduce(a,x%tbp) 1 Error: Expected argument list at (1) module m type t procedure(f), pointer, nopass :: ppc contains procedure, nopass :: tbp = f end type t contains pure function f(a,b) real :: a,b value :: a intent(in) :: b f = 0 end function f end module m use m !intrinsic co_reduce integer :: a type(t) :: x !call co_reduce(a,x%ppc) call co_reduce(a,x%tbp) end
[Bug fortran/63553] New: [OOP] Wrong code when assigning a CLASS to a TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553 Bug ID: 63553 Summary: [OOP] Wrong code when assigning a CLASS to a TYPE Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org From https://gcc.gnu.org/ml/fortran/2014-10/msg00072.html Gives with Cray's ftn: tm = cm 2*1 but with gfortran 5 the wrong: tm = cm19967872 1 program toto implicit none type mother integer :: i end type mother type,extends(mother) :: child end type child type(mother) :: tm type(child) :: tc class(mother),allocatable :: cm,cm2 class(child),allocatable :: cc allocate(cm,cc) tc%i=0 cc%i=2 tm%i=2 cm%i=1 tm=cm print *,'tm = cm',tm%i,cm%i end program
