[Bug libgcc/65306] make error with clang on OSX 10.9.5 -- movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65306 --- Comment #10 from Uroš Bizjak --- Assembler support for interunit movq (e.g. "movq %rax, %xmm0") is detected with configure, and HAVE_AS_IX86_INTERUNIT_MOVQ flag is set accordingly. It looks that configure checks different assembler than the one used to compile the library.
[Bug c++/62274] [C++11] Variadic templates expansion into non-variadic class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62274 --- Comment #4 from Ville Voutilainen --- (In reply to juchem from comment #3) > Clang does accept this code: http://goo.gl/YKBt2l Clang 3.3 and 3.4 do, yes. 3.5, 3.6 and their trunk don't.
[Bug ipa/65318] [5 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65318 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-05 CC||mpolacek at gcc dot gnu.org Component|tree-optimization |ipa Target Milestone|--- |5.0 Summary|wrong code at -Os and above |[5 Regression] wrong code |on x86_64-linux-gnu |at -Os and above on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed, and ICF issue. Started with r221099.
[Bug c++/65292] Template function not emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292 John Marino changed: What|Removed |Added CC||gnugcc at marino dot st --- Comment #4 from John Marino --- Khem, I've also just discovered gcc-5 won't build webkit anymore. If you have already come up with a patch for libJavaScriptCore, could you share it here?
[Bug c++/62274] [C++11] Variadic templates expansion into non-variadic class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62274 --- Comment #3 from juchem at gmail dot com --- Clang does accept this code: http://goo.gl/YKBt2l
[Bug rtl-optimization/65067] regression on accessing volatile bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067 --- Comment #10 from Bernd Edlinger --- (In reply to Tony Liu from comment #9) > (In reply to Bernd Edlinger from comment #8) > > Created attachment 34955 [details] > > Proposed Fix > > > > Well, I noticed that the first version of this patch caused > > a small but measurable decrease of code quality on x86_64, > > so I moved the patch to the if (strict_volatile_bitfield_p block, > > and used some code transformations to simplify the resulting code > > a bit. > > > > I will post this new version for review, after a full boot-strap > > and successful regression-test on my ARM target. > > I've tested for target Cortex-M3, no regression. Oh, thanks. This was really speedy! Then I am clear to post the patch in a moment.
[Bug target/65321] New: ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321
Bug ID: 65321
Summary: ICE on valid code at -O2 and -O3 with -g enabled in
decompose, at rtl.h:2007
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O2 and -O3 with -g enabled on x86_64-linux-gnu in both 32-bit and 64-bit
modes.
This is a regression from 4.9.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 20150304 (experimental) [trunk revision 221192] (GCC)
$
$ gcc-trunk -O2 -c small.c
$ gcc-4.9.2 -O2 -g -c small.c
$
$ gcc-trunk -O2 -g -c small.c
small.c: In function ‘fn1’:
small.c:27:1: internal compiler error: in decompose, at rtl.h:2007
}
^
0xae1a87 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
../../gcc-trunk/gcc/rtl.h:2005
0xae1a87 wide_int_ref_storage::wide_int_ref_storage >(std::pair const&, unsigned int)
../../gcc-trunk/gcc/wide-int.h:957
0xae1a87 generic_wide_int
>::generic_wide_int >(std::pair const&, unsigned int)
../../gcc-trunk/gcc/wide-int.h:733
0xae1a87 wi::binary_traits,
std::pair, wi::int_traits >::precision_type, wi::int_traits >::precision_type>::result_type wi::sub, std::pair >(std::pair const&, std::pair const&)
../../gcc-trunk/gcc/wide-int.h:2357
0xae1a87 simplify_const_binary_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
../../gcc-trunk/gcc/simplify-rtx.c:3934
0xaded4f simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
../../gcc-trunk/gcc/simplify-rtx.c:1987
0x7791f3 cselib_expand_value_rtx_1
../../gcc-trunk/gcc/cselib.c:1843
0x77a38e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-trunk/gcc/cselib.c:1551
0xd88005 vt_expand_var_loc_chain
../../gcc-trunk/gcc/var-tracking.c:8310
0xd88005 vt_expand_loc_callback
../../gcc-trunk/gcc/var-tracking.c:8472
0x779102 cselib_expand_value_rtx_1
../../gcc-trunk/gcc/cselib.c:1704
0x77a38e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-trunk/gcc/cselib.c:1551
0xd88bb1 vt_expand_var_loc_chain
../../gcc-trunk/gcc/var-tracking.c:8310
0xd88bb1 vt_expand_1pvar
../../gcc-trunk/gcc/var-tracking.c:8585
0xd88bb1 emit_note_insn_var_location(variable_def**, emit_note_data_def*)
../../gcc-trunk/gcc/var-tracking.c:8640
0xd92403 void hash_table::traverse_noresize(emit_note_data_def*)
../../gcc-trunk/gcc/hash-table.h:1057
0xd92403 void hash_table::traverse(emit_note_data_def*)
../../gcc-trunk/gcc/hash-table.h:1079
0xd92403 emit_notes_for_changes
../../gcc-trunk/gcc/var-tracking.c:9000
0xd94140 emit_notes_in_bb
../../gcc-trunk/gcc/var-tracking.c:9432
0xd94140 vt_emit_notes
../../gcc-trunk/gcc/var-tracking.c:9495
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.
$
-
int a, b, c, d, e;
int
fn1 ()
{
int h;
char i;
for (; c > 0;)
{
for (d = 0; d < 2; d++)
{
i = 1 << d;
if (i - a)
{
e = b = 0;
for (; c; c--)
d = 127;
}
}
h = ~d;
if (h > c)
for (;;)
;
return 0;
}
return 0;
}
[Bug rtl-optimization/65067] regression on accessing volatile bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067 --- Comment #9 from Tony Liu --- (In reply to Bernd Edlinger from comment #8) > Created attachment 34955 [details] > Proposed Fix > > Well, I noticed that the first version of this patch caused > a small but measurable decrease of code quality on x86_64, > so I moved the patch to the if (strict_volatile_bitfield_p block, > and used some code transformations to simplify the resulting code > a bit. > > I will post this new version for review, after a full boot-strap > and successful regression-test on my ARM target. I've tested for target Cortex-M3, no regression.
[Bug libgcc/65306] make error with clang on OSX 10.9.5 -- movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65306 --- Comment #9 from Matthew Niemerg --- @Max. See the attached files. @Howarth. I am compiling gcc-4.9.2 with gmp, mpfr, and mpc source directories in the gcc-4.9.2 source tree. There is nothing disconcerting about not passing --with-* to the configure script, as per the directions found on https://gcc.gnu.org/install/configure.html . Kind regards, Matt
[Bug libgcc/65306] make error with clang on OSX 10.9.5 -- movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65306 --- Comment #8 from Matthew Niemerg --- Created attachment 34961 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34961&action=edit extenddftf2.s
[Bug libgcc/65306] make error with clang on OSX 10.9.5 -- movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65306 --- Comment #7 from Matthew Niemerg --- Created attachment 34960 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34960&action=edit extenddftf2.i
[Bug c++/65284] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65284
--- Comment #6 from Aldy Hernandez ---
For the construction of the lambda in the simplified testcase I have just
uploaded:
MaybeInt().xmap([abc](int childId)
{
return ParsedSchema(bark, childId + 666);
});
We initially generate the following tree:
ParsedSchema::findNested():: (const struct __lambda0 * const
__closure, int childId)
{
const int abc [value-expr: __closure->__abc];
<
NON_LVALUE_EXPR
*NON_LVALUE_EXPR = bark;, <<< Unknown tree: empty_class_expr >>>;
childId + 666 >;
}
Whose AGGR_INIT_EXPR will be gimplified into:
ParsedSchema::findNested():: (const struct __lambda0 * const
__closure, int childId)
{
const int abc [value-expr: __closure->__abc];
<, *NON_LVALUE_EXPR = bark;, <<< Unknown tree: empty_class_expr
>>>;, childId + 666)>>;
}
Notice the non-existent return value from ParsedSchema::ParsedSchema is being
read from, and constructors do not return anything. I suppose D.2331 should be
set from NON_LVALUE_EXPR, although even the assignment into
*NON_LVALUE_EXPR looks odd. Isn't a NON_LVALUE_EXPR by definition not
assignable?
Before the patch that broke this, we had:
< = TARGET_EXPR ;, <<< Unknown tree: empty_class_expr >>>;
childId + 666 ;, D.2133>>;
Notice the TARGET_EXPR, which then does the right thing when gimplified.
[Bug tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307 --- Comment #12 from madars+gccbug at gmail dot com --- By the way, in g++ the bug can be triggered even with -O1 and without marking any functions inline (implicitly or explicitly): http://web.mit.edu/madars/Public/gcc-basic-arithmetic-bug-O1.cpp
[Bug libgomp/65320] New: FAIL: libgomp.fortran/examples-4/e.51.2.f90 -O3 -g execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65320 Bug ID: 65320 Summary: FAIL: libgomp.fortran/examples-4/e.51.2.f90 -O3 -g execution test Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: jakub at gcc dot gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu spawn /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/ /home/ dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/examples-4/e.51.2.f90 -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/ -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/.libs -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp -I/home/dave/gnu/gcc/gcc/libgomp/testsuite/../../include -I/home/dave/gnu/gcc/gcc/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp -O3 -g -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/../libgfortran/.libs -fintrinsic-modules-path=/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/../libgfortran/.libs -lgfortran -lm -o ./e.51.2.exePASS: libgomp.fortran/examples-4/e.51.2.f90 -O3 -g (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/.libs:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/../libgfortran/.libs:.:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/.libs:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/../libgfortran/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc spawn [open ...]./e.51.2.exe: error while loading shared libraries: internal error: symidx out o f range of fptr table FAIL: libgomp.fortran/examples-4/e.51.2.f90 -O3 -g execution test Similar fail: FAIL: libgomp.fortran/examples-4/e.51.3.f90 -Os execution test
[Bug testsuite/64850] FAIL: gfortran.dg/goacc/acc_on_device-1.f95 -O scan-rtl-dump-times expand "\\(call [^\\n]*\\"acc_on_device" 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64850 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from John David Anglin --- Fixed.
[Bug libstdc++/64797] 22_locale/conversions/string/2.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64797 --- Comment #11 from howarth at bromo dot med.uc.edu --- Confirmed that the libstdc++ test suite now shows no regressions on x86_64-apple-darwin14.
[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
--- Comment #19 from Jan Hubicka ---
I tried to construct a testcase for __restrict__ case:
int var;
const int *varptr=&var;
const int *__restrict__ varptr2=&var;
int *__restrict__ varptr3 = &var;
int *__restrict__ varptr4 = &var;
int *
return_valptr(int i)
{
return varptr[i];
}
int * __restrict__
return_valptr2(int i)
{
return varptr2[i];
}
int
testrestrict ()
{
int *ptr = return_valptr (0);
*ptr = 0;
*varptr3 = 1;
return *ptr;
}
int
testrestrict2 ()
{
int *ptr = return_valptr2 (0);
*ptr = 0;
*varptr3 = 1;
return *ptr;
}
int
testrestrict4 ()
{
*varptr4 = 0;
*varptr3 = 1;
return *varptr4;
}
Here I would like restrict2 to return uncondtional 0, because ptr is taken from
a restrict pointer in a global var. For whatever reason this optimization is
not happening (it happens in testrestrict4). So perhaps we are safe to
completely ignore restircts on vars, because we never get the flag in through
folding.
[Bug ada/65319] FAIL: g++.dg/other/dump-ada-spec-3.C -std=gnu++98 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65319 --- Comment #1 from John David Anglin --- spawn /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ -B/home/dave/gnu/gc c/objdir/gcc/testsuite/g++/../../ /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/ot her/dump-ada-spec-3.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nos tdinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-lin ux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include -I/home/d ave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/inc lude/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -fdump-ada-spec -S -o dump-ada-spec-3.s /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/other/dump-ada-spec-3.C:25:1: intern al compiler error: Segmentation fault 0x6baee3 crash_signal ../../gcc/gcc/toplev.c:383Please submit a full bug report, Failure is not fully consistent and I was unable to get test to ICE running in under gdb on linux. Test also ICE's on hpux.
[Bug ada/65319] New: FAIL: g++.dg/other/dump-ada-spec-3.C -std=gnu++98 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65319 Bug ID: 65319 Summary: FAIL: g++.dg/other/dump-ada-spec-3.C -std=gnu++98 (internal compiler error) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa*-*-* Target: hppa*-*-* Build: hppa*-*-*
[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270 --- Comment #18 from Jan Hubicka --- Here is summary of my current understanding of remaining issues from my last weekend's audit. ICF specific: - ipa-icf-gimple.c needs to match dependence analysis Richard has propsed a patch for it, so I hope he will commit it tomorrow. - restrict flag may need to be matched when considering two references to variables being equal. Here I am waiting for Richards comment. I would propose matching restricts in compare_cgraph_references same way as we now compare vtables. non-ICF specific wrong codes - tree-vectorizer is picking up wrong alignment - fold-const.c's operands_equal_p probably needs same treatment for comparing mem-ref as ipa-icf-gimple has. I think in all cases one can construct testcase where tree-tail-merge would produce same incorrect merging as ipa-icf does. stuff that can wait for next stage1 - ipa-pure-const is probably wrong to check TYPE_NEEDS_CONSTRUCTION flag (something to fix for next stage1) - expand_builtin_classify_type can probably be dropped, because fold_classify_type prevails.
[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270 --- Comment #17 from Jan Hubicka --- Author: hubicka Date: Thu Mar 5 00:10:29 2015 New Revision: 221199 URL: https://gcc.gnu.org/viewcvs?rev=221199&root=gcc&view=rev Log: PR ipa/65270 * ipa-icf.c (sem_item::compare_cgraph_references): Compare vtable references for their containing type. (sem_function::equals_wpa): Compare TYPE_RESTRICT and type attributes. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c
[Bug lto/65316] [5 Regression] LTO: Uninitialized memory / ICE with -g -fno-lto-odr-type-merging: in types_same_for_odr, at ipa-devirt.c:465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65316 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka --- Mine, obviously.
[Bug lto/65302] [5 Regression] LTO: ICE internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65302 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #4 from Jan Hubicka --- *free_cfg_annotations is bogus name for pass_fixup_cfg, but it is precisely what the pass should do - clear EH edges if they are no longer needed. I will take a look.
[Bug target/65248] Copy relocation against protected symbol doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248 --- Comment #3 from H.J. Lu --- BInutils, glibc and GCC patches are posted at https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00257.html
[Bug c++/65284] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65284 --- Comment #5 from Aldy Hernandez --- Created attachment 34959 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34959&action=edit reduced testcase
[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64342 --- Comment #14 from Jeffrey A. Law --- Created attachment 34958 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34958&action=edit testcase
[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64342
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Assignee|unassigned at gcc dot gnu.org |vmakarov at redhat dot
com
--- Comment #13 from Jeffrey A. Law ---
AFACIT only one issue is left, namely avx512f-kandnw-1.c when compiled with
-mavx512f -m32 does not generate a kandnw instruction.
This appears to be some kind of register allocation issue.
In the IRA dump we have:
ssigning 69 to a1r105
Assigning 70 to a5r103
Assigning 69 to a6r101
Disposition:
10:r87 l0 03:r91 l0224:r92 l0232:r93 l021
9:r100 l0216:r101 l0698:r102 l0 05:r103 l070
7:r104 l0 11:r105 l0690:r110 l021
Which is basically what we want for insn 17 to generate the proper insn:
(insn 17 11 19 2 (parallel [
(set (reg:HI 105)
(and:HI (not:HI (reg:HI 101 [ k1 ]))
(reg:HI 103 [ k2 ])))
(clobber (reg:CC 17 flags))
]) ./include/avx512fintrin.h:9995 388 {kandnhi}
(expr_list:REG_DEAD (reg:HI 103 [ k2 ])
(expr_list:REG_DEAD (reg:HI 101 [ k1 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
LRA comes along and mucks things up. It seems to initially do the right thing:
Choosing alt 2 in insn 17: (0) !k (1) k (2) k {kandnhi}
Then later:
** Assignment #1: **
Spill r101 after risky transformations
Assigning to 117 (cl=MASK_EVEX_REGS, orig=105, freq=2000, tfirst=117,
tfreq=2000)...
Assign 71 to reload r117 (freq=2000)
Reassigning non-reload pseudos
Assign 0 to r101 (freq=2000)
Note the Assign 0 to r101, at this point we're going to lose badly.
Choosing alt 1 in insn 17: (0) &r (1) 0 (2) r {kandnhi}
Creating newreg=118 from oldreg=105, assigning class GENERAL_REGS to r118
Creating newreg=119 from oldreg=103, assigning class GENERAL_REGS to r119
With insn 17 looking like:
(insn 17 40 39 2 (parallel [
(set (reg:HI 0 ax [105])
(and:HI (not:HI (reg:HI 0 ax [105]))
(reg:HI 2 cx [orig:103 k2 ] [103])))
(clobber (reg:CC 17 flags))
]) ./include/avx512fintrin.h:9995 388 {kandnhi}
(nil))
with input & output reloads to get things into the k registers and of course no
kandnw instruction since we end up doing the logical operation in the general
purpose registers.
[Bug target/65313] Compilation error in lto profiledbootstrap on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65313 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- I don't see the reported error with today's trunk (r221193) but rather a different one. After configuring like so: $ /src/gcc-trunk-git/configure --disable-multilib --enable-checking=release --with-build-config=bootstrap-lto --enable-languages=c and making profiledboostrap: $ nice make -j16 profiledbootstrap the build fails with: profiling:/build/gcc-65313/libcpp/lex.gcda:Merge mismatch for function 0 get_d.c: In function '__gmpn_get_d': get_d.c:490:1: error: the control flow of function '__gmpn_get_d' does not match its profile data (counter 'arcs') [-Werror=coverage-mismatch] } ^ get_d.c:490:1: error: the control flow of function '__gmpn_get_d' does not match its profile data (counter 'time_profiler') [-Werror=coverage-mismatch] cc1: some warnings being treated as errors profiling:/build/gcc-65313/libcpp/lex.gcda:Merge mismatch for function 0 profiling:/build/gcc-65313/libcpp/lex.gcda:Merge mismatch for function 0 make[5]: *** [get_d.lo] Error 1 make[5]: Leaving directory `/build/gcc-65313/gmp/mpn' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/build/gcc-65313/gmp' make[3]: *** [all] Error 2 make[3]: Leaving directory `/build/gcc-65313/gmp' make[2]: *** [all-stagefeedback-gmp] Error 2 make[2]: Leaving directory `/build/gcc-65313' make[1]: *** [stagefeedback-bubble] Error 2 make[1]: Leaving directory `/build/gcc-65313' make: *** [profiledbootstrap] Error 2
[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65242 --- Comment #7 from David Edelsohn --- I'll defer to Mike for deeper analysis, but changing ?m to !m seems very reasonable.
[Bug target/65138] testsuite ICEs on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65138 --- Comment #17 from Michael Meissner --- Just an additional comment. Jakub asked whether the PowerPC needed the additional target attribute support that the x86 added as part of PR61925. I looked at those patches, and at present those are not needed. Those patches are needed on the x86 because the x86 saves memory by not creating all of the built-in functions at compiler start time. Instead it only builds the built-ins for the current switches. If the user uses the target attribute/pragma support to add new options, these built-in functions would be created. At the present time, the PowerPC does not create the built-in functions on the fly, so it doesn't have to change the attributes when creating said functions. If we ever mirror the x86 behavior and not create all 1,167 built-in functions, we would need similar patches.
[Bug tree-optimization/65318] New: wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65318
Bug ID: 65318
Summary: wrong code at -Os and above 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 miscompiles the following code on x86_64-linux at -Os and
above in both 32-bit and 64-bit modes.
This is a regression from 4.9.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 20150304 (experimental) [trunk revision 221192] (GCC)
$
$ gcc-trunk -O1 small.c; ./a.out
$ gcc-4.9.2 -Os small.c; ./a.out
$
$ gcc-trunk -Os small.c
$ ./a.out
0
$
-
int printf(const char *, ...);
static short a = 0;
short b = -1;
static unsigned short c = 0;
int
main ()
{
if (a <= b)
printf ("%d\n", c);
return 0;
}
[Bug target/65138] testsuite ICEs on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65138 --- Comment #16 from Michael Meissner --- Created attachment 34957 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34957&action=edit Backport of patches to gcc 4.8 Here is the backport of the patches to gcc 4.8.
[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65242
--- Comment #6 from Jeffrey A. Law ---
So I think two things are coming into play with reproducing these issues.
First an inaccurate trunk version #. r221042 is not a trunk commit. I was
able to reproduce with r221041 which is a trunk commit. Odds are Matthias
typo'd.
Second, these issues are highly dependent upon reloads actions which are known
to be notoriously difficult to predict and are easily perturbed.
So using r221041 or d21bee29dffb3724605183d17983dfc9f0ee6f21 for the GIT folks,
I was able to reproduce with the original testcase without problems.
There's a few key insns in play here. The most important (from the IRA dump)
is:
(insn 32 33 128 3 (set (mem/f:DI (plus:DI (reg/f:DI 203 [ this ])
(const_int 9 [0x9])) [6 this_1(D)->MissFile+0 S8 A8])
(reg/f:DI 264)) j.C:84 467 {*movdi_internal64}
(nil))
r203 will get a suitable hard register (r25). r264 will not. r264 is set via:
(insn 26 18 17 2 (set (reg/f:DI 264)
(plus:DI (reg/f:DI 113 sfp)
(const_int 51 [0x33]))) j.C:83 81 {*adddi3}
(expr_list:REG_EQUIV (plus:DI (reg/f:DI 113 sfp)
(const_int 51 [0x33]))
(nil)))
I'm guessing sfp is a soft frame pointer or some-such eliminable register.
Anyway, the REG_EQUIV note for r264 gets shoved into insn 32 resulting in:
(insn 32 33 128 3 (set (mem/f:DI (plus:DI (reg/f:DI 25 25 [orig:203 this ]
[203])
(const_int 9 [0x9])) [6 this_1(D)->MissFile+0 S8 A8])
(plus:DI (reg/f:DI 1 1)
(const_int 51 [0x33]))) j.C:84 467 {*movdi_internal64}
(nil))
We record the following reloads:
Reload 0: BASE_REGS, RELOAD_FOR_OPADDR_ADDR (opnum = 0), optional, can't
combine, secondary_reload_p
Reload 1: GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), optional, can't
combine, secondary_reload_p
secondary_out_reload = 0
secondary_out_icode = reload_di_store
Reload 2: reload_out (DI) = (mem/f:DI (plus:DI (reg/f:DI 25 25 [orig:203 this ]
[203])
(const_int 9 [0x9])) [6
this_1(D)->MissFile+0 S8 A8])
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (mem/f:DI (plus:DI (reg/f:DI 25 25 [orig:203 this ]
[203])
(const_int 9 [0x9])) [6
this_1(D)->MissFile+0 S8 A8])
secondary_out_reload = 1
Reload 3: reload_in (DI) = (plus:DI (reg/f:DI 1 1)
(mem/u/c:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC4") [flags 0x2])
(reg:DI 2 2)
] UNSPEC_TOCREL)
[13 S8 A64]))
FLOAT_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
reload_in_reg: (plus:DI (reg/f:DI 1 1)
(const_int 51 [0x33]))
Ugh. So many bad things happening here I want to cry. But I'll focus on
reload #3, note FLOAT_REGS.
In gen_add2_insn we have:
(gdb) p debug_rtx (x)
(reg:DI 32 0)
$107 = void
(gdb) p debug_rtx (y)
(mem/u/c:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC4") [flags 0x2])
(reg:DI 2 2)
] UNSPEC_TOCREL) [13 S8 A64])
$108 = void
Note the register used for X. This is a direct result of FLOAT_REGS as the
class for reload #3.
So going to the appropriate insn in the MD file we have:
(define_insn "*movdi_internal64"
[(set (match_operand:DI 0 "nonimmediate_operand"
"=Y,r,r,r,r,r,?m,?*d,?*d,r,*h,*h,r,?*wg,r,?*wj,?*wi")
(match_operand:DI 1 "input_operand"
"r,Y,r,I,L,nF,d,m,d,*h,r,0,*wg,r,*wj,r,O"))]
Note carefully the constraints for alternative #7. op0 is "?m" and op1 is
"d".
The odd offset in the address computation for operand0 causes mem_operand_opr
not to match and thus we ultimately target alternative #7. And "d" happens to
be FP regs for double values, presumably FLOAT_REGS. And ultimately this
causes the ICE when we try to realize the recorded reloads.
That seems a particularly bad alternative to select. One could easily argue
the constraint for operand 0, alterantive 7 should be "!m". In fact, if I do
that, the test passes and a peek at the reloads we generate for the
problematical insn look much better.
I'm far from a expert in the PPC backend and not confident enough to propose
this patch and find other instances that might need similar updates. But
perhaps this saves someone else some analysis time.
[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65240 Michael Meissner changed: What|Removed |Added Attachment #34952|0 |1 is obsolete|| --- Comment #13 from Michael Meissner --- Created attachment 34956 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34956&action=edit Proposed patch to fix the problem This patch appears to fix the problem (first patch was a bandaid). I'm going to test it before submitting it.
[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65240 Michael Meissner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org
[Bug target/65317] New: [SH] Shifts used instead of and with const_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65317
Bug ID: 65317
Summary: [SH] Shifts used instead of and with const_int
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
int
test_01 (int a, int b)
{
int r = a < 0;
return r << 31;
}
compiled with -O2 -m4:
shllr4
movtr0
and #1,r0
rts
rotrr0
could be:
mov.l .Lconst,r0
rts
and r4,r0
.Lconst:
.long 0x8000
combine says:
Failed to match this instruction:
(set (reg:SI 168 [ D.1470 ])
(and:SI (reg:SI 4 r4 [ a ])
(const_int -2147483648 [0x8000])))
Notice that this
int
test_02 (int a)
{
return a & 0x8000;
}
compiles as expected:
mov.l .L18,r0
rts
and r4,r0
.L19:
.align 2
.L18:
.long -2147483648
If code size is important, or constant loads should be avoided (because it's
not shared etc), a shorter (in code size) version would be:
shll r4
movt r0
rts
rotr r0
Another case:
int foo3(int *x)
{
int i,y;
int a[40];
int b[40] __attribute__ ((aligned(32)));
int c[40] __attribute__ ((aligned(128)));
for (i = 0; i < 40; i++)
a[i] = *x++;
for (i = 0; i < 40; i++)
b[i] = *x++;
for (i = 0; i < 40; i++)
c[i] = *x++;
y = -99;
for (i = 0; i < 40; i++)
y = y + a[i] + b[i] + c[i];
return y;
}
compiles to:
mov.l r14,@-r15
mov #-5,r3
add #-80,r15
mov.w .L11,r2
add #-80,r15
add r15,r2
mov r15,r14
mov r2,r15
mov r15,r7
add #31,r7
mov #5,r1
shldr3,r7
shldr1,r7
mov #0,r0
mov #40,r1
.align 2
.L2:
mov.l @(r0,r4),r2
The shifts used to mask out lower bits can be replaced with a much simpler and
with a constant.
Combine says:
Failed to match this instruction:
(set (reg/f:SI 217)
(and:SI (reg/f:SI 214)
(const_int -32 [0xffe0])))
It seems that it's better to allow any constant for the *andsi_compact pattern
and split out the constant load if it doesn't fit into K08. An and with
constant 0x8000 could be treated as a special case to emit the shorter
sequence:
shll r4
movt r0
rts
rotr r0
If constant calculation optimization is done (PR 65069), it would automatically
be converted to:
mov #1,r0
rotrr0
rts
and r4,r0
which is equivalent and maybe even better because the input is not mutated.
[Bug lto/65302] [5 Regression] LTO: ICE internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65302 --- Comment #3 from Aldy Hernandez --- Started with r218767: commit 9e7bd3ae5774b5b9d383588f42d8edab0003a9bf Author: hubicka Date: Mon Dec 15 22:35:20 2014 + PR lto/64043 * gcc.dg/lto/20110201-1_0.c: New testcase. * tree-streamer.c (preload_common_nodes): Skip preloading of main_identifier_node, pid_type and optimization/option nodes. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@218767 138bc75d-0d04-0410-96 1f-82ee72b054a4
[Bug fortran/65144] Problems printing, reading and accessing substrings of ISO_10646 character variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65144 --- Comment #9 from Zaak --- I'm sorry for the duplicate commet and typo... it should be PR 65141 NOT 151
[Bug fortran/65144] Problems printing, reading and accessing substrings of ISO_10646 character variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65144
--- Comment #8 from Zaak ---
(In reply to Dominique d'Humieres from comment #1)
> AFAICT the substring problem occurs for PARAMETER only:
>
> program test3
> INTEGER,PARAMETER :: ucs4 = selected_char_kind("ISO_10646")
> CHARACTER(3,UCS4),PARAMETER ::
> unip=CHAR(INT(Z'5e74'),UCS4)//CHAR(INT(Z'6708'),ucs4)//CHAR(INT(Z'65e5'),
> ucs4)
> character(3,UCS4) :: uni
> uni = unip
> open(6, encoding="utf-8")
> print *, uni
> print *, uni(2:2)
> print *, unip
> print *, "'",unip(1:1),"'"
> end program test3
>
> gives at run time
>
> 年月日
> 月
> 年月日
> 't'
As Dominique noted a problem does exist with ISO 10646 characters with the
parameter attribute. Pleas see PR 65151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65141 for more details
[Bug fortran/65144] Problems printing, reading and accessing substrings of ISO_10646 character variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65144
--- Comment #7 from Zaak ---
(In reply to Dominique d'Humieres from comment #1)
> AFAICT the substring problem occurs for PARAMETER only:
>
> program test3
> INTEGER,PARAMETER :: ucs4 = selected_char_kind("ISO_10646")
> CHARACTER(3,UCS4),PARAMETER ::
> unip=CHAR(INT(Z'5e74'),UCS4)//CHAR(INT(Z'6708'),ucs4)//CHAR(INT(Z'65e5'),
> ucs4)
> character(3,UCS4) :: uni
> uni = unip
> open(6, encoding="utf-8")
> print *, uni
> print *, uni(2:2)
> print *, unip
> print *, "'",unip(1:1),"'"
> end program test3
>
> gives at run time
>
> 年月日
> 月
> 年月日
> 't'
As Dominique noted a problem does exist with ISO 10646 characters with the
parameter attribute. Pleas see PR 65151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65141 for more details
[Bug rtl-optimization/65067] regression on accessing volatile bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067 --- Comment #8 from Bernd Edlinger --- Created attachment 34955 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34955&action=edit Proposed Fix Well, I noticed that the first version of this patch caused a small but measurable decrease of code quality on x86_64, so I moved the patch to the if (strict_volatile_bitfield_p block, and used some code transformations to simplify the resulting code a bit. I will post this new version for review, after a full boot-strap and successful regression-test on my ARM target.
[Bug lto/65302] [5 Regression] LTO: ICE internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65302 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-04 CC||aldyh at gcc dot gnu.org, ||richard.guenther at gmail dot com Ever confirmed|0 |1 --- Comment #2 from Aldy Hernandez --- Confirmed. Happens during ltrans stage: (gdb) bt #0 internal_error (gmsgid=0x161bb98 "verify_flow_info failed") at /source/gcc/gcc/diagnostic.c:1221 #1 0x00729a78 in verify_flow_info () at /source/gcc/gcc/cfghooks.c:280 #2 0x00b3e1b5 in execute_function_todo (fn=0x7fffeff972a0, data=0x40) at /source/gcc/gcc/passes.c:1969 #3 0x00b3d25e in do_per_function (callback= 0xb3dfa3 , data=0x40) at /source/gcc/gcc/passes.c:1649 #4 0x00b3e32f in execute_todo (flags=64) at /source/gcc/gcc/passes.c:2014 #5 0x00b3ed09 in execute_one_pass (pass= ) at /source/gcc/gcc/passes.c:2341 #6 0x00b3eeb1 in execute_pass_list_1 ( pass=) at /source/gcc/gcc/passes.c:2380 #7 0x00b3ef1f in execute_pass_list (fn=0x7fffeff972a0, pass=) at /source/gcc/gcc/passes.c:2391 #8 0x00763888 in cgraph_node::expand ( this=) at /source/gcc/gcc/cgraphunit.c:1878 #9 0x007642f6 in output_in_order (no_reorder=false) at /source/gcc/gcc/cgraphunit.c:2116 #10 0x007649c3 in symbol_table::compile (this=0x7018f000) at /source/gcc/gcc/cgraphunit.c:2361 #11 0x006a5c0a in lto_main () at /source/gcc/gcc/lto/lto.c:3476 #12 0x00c3750a in compile_file () at /source/gcc/gcc/toplev.c:594 #13 0x00c399d3 in do_compile () at /source/gcc/gcc/toplev.c:2066 #14 0x00c39c01 in toplev::main (this=0x7fffdbb0, argc=25, argv=0x1fe0320) at /source/gcc/gcc/toplev.c:2164 #15 0x01576ac7 in main (argc=25, argv=0x7fffdcb8) at /source/gcc/gcc/main.c:39
[Bug c++/65284] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65284
Aldy Hernandez changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4 from Aldy Hernandez ---
This was caused by r210292:
commit f1ec53b67367cb5d4aba65b5648e5faa5f29bdf0
Author: jason
Date: Fri May 9 20:07:45 2014 +
PR c++/60463
PR c++/60755
* lambda.c (lambda_expr_this_capture): Add new parameter
add_capture_p controlling whether the functions will try to
capture 'this' via the default capture.
(maybe_resolve_dummy): Likewise.
* cp-tree.h: Adjust prototypes.
* call.c, semantics.c: Change callers of these functions.
* call.c (build_new_method_call_1): Use the actual 'this' that
would be potentially captured for the overload resolution, instead
of the dummy object.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210292
138bc75d-0d04-0410-961f-82ee72b054a4
Jason, just so I know what I'm looking at here, is the testcase even valid?
Because mainline on x86-64 has a totally different symptom than ppc with
--enable-checking and a totally different symptom than ppc with
--enable-checking=release.
On mainline on x86-64 (with either default checking or
--enable-checking=release), we get:
reynosa:/build/t/gcc$ ./cc1plus ~/a.ii -quiet -std=c++11 -O2 -I./
/home/aldyh/a.ii: In lambda function:
/home/aldyh/a.ii:50:7: error: using result of function returning ‘void’
});
On a cross PPC with default checking we get:
reynosa:/build/arm-linux-gnueabihf-checking/gcc$ ./cc1plus ~/a.ii -quiet
-std=c++11 -O2 -I./
/home/aldyh/a.ii: In lambda function:
/home/aldyh/a.ii:48:35: error: non-trivial conversion at assignment
.map([this](uint64_t childId) {
^
struct ParsedSchema
struct ParsedSchema *
= D.4925;
/home/aldyh/a.ii:48:35: internal compiler error: verify_gimple failed
0xf4da3b verify_gimple_in_seq(gimple_statement_base*)
/source/gcc/gcc/tree-cfg.c:4736
0xc7fe6d gimplify_body(tree_node*, bool)
/source/gcc/gcc/gimplify.c:9117
0xc802a7 gimplify_function_tree(tree_node*)
/source/gcc/gcc/gimplify.c:9202
0xa2f3e0 cgraph_node::analyze()
/source/gcc/gcc/cgraphunit.c:633
0xa306ba analyze_functions
/source/gcc/gcc/cgraphunit.c:1023
0xa34a5f symbol_table::finalize_compilation_unit()
/source/gcc/gcc/cgraphunit.c:2435
0x799173 cp_write_global_declarations()
/source/gcc/gcc/cp/decl2.c:4754
Please submit a full bug report,
Finally, on a cross PPC with --enable-checking=release we get:
reynosa:/build/arm-linux-gnueabihf/gcc$ ./cc1plus ~/a.ii -quiet -std=c++11 -O2
-I./
/home/aldyh/a.ii: In member function ‘Maybe
ParsedSchema::findNested() const’:
/home/aldyh/a.ii:45:21: internal compiler error: Segmentation fault
Maybe ParsedSchema::findNested() const {
^
0xd1b9a4 crash_signal
/source/gcc/gcc/toplev.c:383
0xa40122 maybe_canonicalize_mem_ref_addr
/source/gcc/gcc/gimple-fold.c:3504
0xa402c3 fold_stmt_1
/source/gcc/gcc/gimple-fold.c:3556
0xa40e07 fold_stmt(gimple_stmt_iterator*, tree_node* (*)(tree_node*))
/source/gcc/gcc/gimple-fold.c:3810
0xe438c7 execute
/source/gcc/gcc/tree-ssa-forwprop.c:2347
Please submit a full bug report,
Odd indeed. A little guidance would be appreciated, as I don't even know which
one of the three is the correct path.
[Bug middle-end/65315] incorrect alignment of local variable with aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65315 --- Comment #2 from Steve Ellcey --- I submitted a proposed fix. https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00244.html
[Bug lto/65316] [5 Regression] LTO: Uninitialized memory / ICE with -g -fno-lto-odr-type-merging: in types_same_for_odr, at ipa-devirt.c:465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65316 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-04 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- In member function ‘_ZNKSt5ctypeIcE5widenEc.part.2.constprop’: lto1: internal compiler error: in types_same_for_odr, at ipa-devirt.c:465 0x86041e types_same_for_odr(tree_node const*, tree_node const*) ../../gcc/gcc/ipa-devirt.c:465 0x86c099 odr_hasher::equal(odr_type_d const*, tree_node const*) ../../gcc/gcc/ipa-devirt.c:513 0x86c099 hash_table::find_slot_with_hash(tree_node const*, unsigned int, insert_option) ../../gcc/gcc/hash-table.h:981 0x862cb7 get_odr_type(tree_node*, bool) ../../gcc/gcc/ipa-devirt.c:1590 0x8680fd possible_polymorphic_call_targets(tree_node*, long, ipa_polymorphic_call_context, bool*, void**, bool) ../../gcc/gcc/ipa-devirt.c:2497 0x7cda0c possible_polymorphic_call_targets(tree_node*, gimple_statement_base*, bool*, void**) ../../gcc/gcc/ipa-utils.h:126 0x7cba49 gimple_fold_call ../../gcc/gcc/gimple-fold.c:3094 0x7cba49 fold_stmt_1 ../../gcc/gcc/gimple-fold.c:3676 0xa8a992 fold_marked_statements ../../gcc/gcc/tree-inline.c:4864 0xa979b4 tree_function_versioning(tree_node*, tree_node*, vec*, bool, bitmap_head*, bool, bitmap_head*, basic_block_def*) ../../gcc/gcc/tree-inline.c:5810 0x6919c3 cgraph_materialize_clone ../../gcc/gcc/cgraphclones.c:1056 0x6919c3 symbol_table::materialize_all_clones() ../../gcc/gcc/cgraphclones.c:1153 0x68c739 symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2326 0x603076 lto_main() ../../gcc/gcc/lto/lto.c:3476 Please submit a full bug report,
[Bug ipa/65298] [5 Regression] lto1: ICE: in operator[], at vec.h:736 during LTO/PGO Firefox build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65298 --- Comment #9 from Markus Trippelsdorf --- (In reply to Martin Jambor from comment #8) > Created attachment 34951 [details] > Patch testing pass-through jump function indices > > Here is the same patch as an attachment. Thanks. But I cannot reproduce the issue with todays gcc and your patch applied. Unfortunately I have deleted the old Firefox build directory...
[Bug middle-end/65315] incorrect alignment of local variable with aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65315 --- Comment #1 from Steve Ellcey --- It might be easier to see this bug if you apply this patch: diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c index 7dfe1f6..7beb00e 100644 --- a/gcc/cfgexpand.c +++ b/gcc/cfgexpand.c @@ -973,6 +973,8 @@ expand_stack_vars (bool (*pred) (size_t), struct sta ck_vars_data *data) i = stack_vars_sorted[si]; alignb = stack_vars[i].alignb; + gcc_assert (alignb*BITS_PER_UNIT <= large_align); + /* Stop when we get to the first decl with "small" alignment. */ if (alignb * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT) break; This way you get an ICE instead of just incorrectly aligned vectors.
[Bug lto/65316] New: [5 Regression] LTO: Uninitialized memory / ICE with -g -fno-lto-odr-type-merging: in types_same_for_odr, at ipa-devirt.c:465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65316 Bug ID: 65316 Summary: [5 Regression] LTO: Uninitialized memory / ICE with -g -fno-lto-odr-type-merging: in types_same_for_odr, at ipa-devirt.c:465 Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Created attachment 34954 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34954&action=edit one.ii Follow up to PR65276 and PR65302. It turned out that is issue is due to uninitialized memory. Thus, if the last command succeeds, simply try again a couple of times (in delta, I called it up to 25 times) - or run it under valgrind or similar. It fails with the ICE: lto1: internal compiler error: in types_same_for_odr, at ipa-devirt.c:465 touch two.ii g++ -c -std=c++11 -g2 -fno-lto-odr-type-merging -flto -O2 two.ii one.ii gcc -r -nostdlib -O2 -fno-lto-odr-type-merging -flto one.o two.o
[Bug middle-end/65315] New: incorrect alignment of local variable with aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65315 Bug ID: 65315 Summary: incorrect alignment of local variable with aligned attribute Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Created attachment 34953 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34953&action=edit Test case When GCC has multiple local variables with different aligned attributes on them, it creates an aligned block of space aligned to the least aligned variable instead of the most aligned variable. In the attached program, when run on MIPS, GCC is creating a 32 byte aligned block of memory for foo1, foo3, and foo4 and a 128 byte aligned memory block for foo2. foo3 and foo4 should have 128 byte aligned memory. I thought the problem was in stack_var_cmp where it checks the alignment of two variables and returns '(int) largeb - (int) largea' to sort the variables based on their alignment but when I swapped the two arguments I got an ICE in expand_stack_vars [gcc_assert (large_base != NULL);]. It also tried changing: large_align = stack_vars[stack_vars_sorted[0]].alignb * BITS_PER_UNIT; to large_align = stack_vars[stack_vars_sorted[n-1]].alignb * BITS_PER_UNIT; but that caused the same ICE. It may be that we need a loop to check the alignment of each variable.
[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
--- Comment #16 from Jan Hubicka ---
Richard,
thanks, I also think alias trick makes gloal vars safe for merging across
RESTRICT flags.
One however needs to consider merging of items referring restricted vars.
const restrict int *a=&var;
const int *b = &var;
const int **ptrs1={&a};
const int **ptrs2=[&b};
with -fmerge-all-constants we may merge ptrs1 and ptrs2 and, in the late
compilation, in turn fold expression "ptrs2[0]" into a restricted pointer to
var?
If this case is legit, the correct place to match RESTRICT flags is
compare_cgraph_references. We can also go with your patch that will make A and
B considered to be different and thus prevent merging PTRS1&PTRS2.
[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65240 --- Comment #12 from Michael Meissner --- Created attachment 34952 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34952&action=edit Initial patch to paper over the problem This patch papers over the problem. As I mentioned before this is an interaction between -ffast-math and -mupper-regs-df. I was able to replicate it for both power7 and power8 targets, and turning off either -ffast-math or -mupper-regs-df allowed the problem to compile. I suspect that the logic in easy_fp_constant to keep the CONST_DOUBLE around to reload time is no longer needed, and that reciprocal approximation does not need the constant in the RTL, but uses the register notes.
[Bug c++/65309] [4.9 Regression] Executes wrong function inside an anonymous namespace on runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65309 --- Comment #13 from Jason Merrill --- Author: jason Date: Wed Mar 4 18:13:44 2015 New Revision: 221192 URL: https://gcc.gnu.org/viewcvs?rev=221192&root=gcc&view=rev Log: PR c++/65209 PR c++/65309 * decl2.c (constrain_visibility_for_template): Handle reference arguments. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/abi/anon4.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/decl2.c
[Bug c++/65209] [5 Regression] Broken code with global static variables, invalid pointer when freeing global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65209 --- Comment #7 from Jason Merrill --- Author: jason Date: Wed Mar 4 18:13:44 2015 New Revision: 221192 URL: https://gcc.gnu.org/viewcvs?rev=221192&root=gcc&view=rev Log: PR c++/65209 PR c++/65309 * decl2.c (constrain_visibility_for_template): Handle reference arguments. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/abi/anon4.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/decl2.c
[Bug c++/65309] [4.9 Regression] Executes wrong function inside an anonymous namespace on runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65309 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jason Merrill --- Fixed for 4.9.3.
[Bug c++/65309] [4.9 Regression] Executes wrong function inside an anonymous namespace on runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65309 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug ipa/65298] [5 Regression] lto1: ICE: in operator[], at vec.h:736 during LTO/PGO Firefox build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65298 --- Comment #8 from Martin Jambor --- Created attachment 34951 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34951&action=edit Patch testing pass-through jump function indices Here is the same patch as an attachment.
[Bug c++/64085] ICE on C++14 lambda by-reference capture with an initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64085
Paolo Carlini changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle
dot com
--- Comment #4 from Paolo Carlini ---
This is a reduced testcase:
template
struct reference_wrapper
{
T& get() const noexcept;
};
template
auto make_monad(reference_wrapper arg) {
return [&captive = arg.get()](auto&&) { return 1; };
}
int main()
{
make_monad(reference_wrapper());
}
[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317 Jeffrey A. Law changed: What|Removed |Added Priority|P1 |P2 --- Comment #20 from Jeffrey A. Law --- Still poking, but downgrading to P2.
[Bug target/65261] [5 Regression] bootstrap-ubsan ppc64le: gcc/libcpp/lex.c:552:30: runtime error: load of misaligned address 0x01002172dfc6 for type 'const uchar', which requires 16 byte alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65261 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Markus Trippelsdorf --- fixed.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 65261, which changed state. Bug 65261 Summary: [5 Regression] bootstrap-ubsan ppc64le: gcc/libcpp/lex.c:552:30: runtime error: load of misaligned address 0x01002172dfc6 for type 'const uchar', which requires 16 byte alignment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65261 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/65261] [5 Regression] bootstrap-ubsan ppc64le: gcc/libcpp/lex.c:552:30: runtime error: load of misaligned address 0x01002172dfc6 for type 'const uchar', which requires 16 byte alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65261 --- Comment #3 from Markus Trippelsdorf --- Author: trippels Date: Wed Mar 4 17:28:56 2015 New Revision: 221190 URL: https://gcc.gnu.org/viewcvs?rev=221190&root=gcc&view=rev Log: Fix PR65261 Running bootstrap-ubsan on ppc64le shows many instances of: libcpp/lex.c:552:30: runtime error: load of misaligned address 0x01001f31d37a for type 'const uchar', which requires 16 byte alignment But the unaligned vector loads are intended in this case, because they are preferable to forced-alignment on POWER8. So just silence the ubsan errors. 2015-03-02 Markus Trippelsdorf include/ PR target/65261 * ansidecl.h (ATTRIBUTE_NO_SANITIZE_UNDEFINED): New macro. libcpp/ PR target/65261 * lex.c (search_line_fast): Silence ubsan errors. Modified: trunk/include/ChangeLog trunk/include/ansidecl.h trunk/libcpp/ChangeLog trunk/libcpp/lex.c
[Bug libstdc++/64797] 22_locale/conversions/string/2.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64797 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jonathan Wakely --- This should be fixed now, please re-open if it still fails on Solaris or OS X.
[Bug libstdc++/64797] 22_locale/conversions/string/2.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64797 --- Comment #9 from Jonathan Wakely --- Author: redi Date: Wed Mar 4 17:19:55 2015 New Revision: 221189 URL: https://gcc.gnu.org/viewcvs?rev=221189&root=gcc&view=rev Log: PR libstdc++/64797 * include/bits/locale_conv.h (wstring_convert::_M_conv): Handle incomplete multibyte sequences correctly. * include/std/codecvt (codecvt_utf8, codecvt_utf16, codecvt_utf8_utf16): Limit _Maxcode to maximum Unicode code point. * src/c++11/codecvt.cc (invalid_mb_sequence, incomplete_mb_character): Define constants. (is_high_surrogate, is_low_surrogate, surrogate_pair_to_code_point): Define convenience functions. (read_utf8_code_point): Return relevant constant to distinguish incomplete characters from invalid sequences. (read_utf16_code_point): Likewise. Check for invalid sequences. (ucs4_in, utf16_in): Use incomplete_mb_character constant. (utf16_out): Check for invalid sequences. (utf16_span): Fix condition. (ucs2_out): Use is_high_surrogate. (ucs2_in): Use incomplete_mb_character constant and fix condition. * testsuite/22_locale/codecvt/char16_t.cc: Fix whitespace. * testsuite/22_locale/conversions/buffer/1.cc: New. * testsuite/22_locale/conversions/string/2.cc: Use char16_t and char32_t instead of wchar_t. * testsuite/22_locale/conversions/string/3.cc: New. Added: trunk/libstdc++-v3/testsuite/22_locale/conversions/buffer/1.cc - copied, changed from r221188, trunk/libstdc++-v3/testsuite/22_locale/conversions/string/2.cc trunk/libstdc++-v3/testsuite/22_locale/conversions/string/3.cc - copied, changed from r221188, trunk/libstdc++-v3/testsuite/22_locale/conversions/string/2.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/locale_conv.h trunk/libstdc++-v3/include/std/codecvt trunk/libstdc++-v3/src/c++11/codecvt.cc trunk/libstdc++-v3/testsuite/22_locale/codecvt/char16_t.cc trunk/libstdc++-v3/testsuite/22_locale/conversions/string/2.cc
[Bug c++/65314] New: invalid type for array subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65314
Bug ID: 65314
Summary: invalid type for array subscript
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: polina.borisova at kcl dot ac.uk
Hi,
I dont seem to be able to fix this bug
Relevant code:
.
.
.
.
double on[N_k];
double a1[N], a2[N];
double x_0[N];
double y_0[N];
double x_1[N];
double y_1[N];
.
.
.
.
.
void Fourier(void)
{
int n, j;
for(j=0; j
[Bug ipa/65298] [5 Regression] lto1: ICE: in operator[], at vec.h:736 during LTO/PGO Firefox build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65298 --- Comment #7 from Markus Trippelsdorf --- Could you attach the patch, please. It doesn't apply when I copy&paste.
[Bug ipa/65298] [5 Regression] lto1: ICE: in operator[], at vec.h:736 during LTO/PGO Firefox build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65298
--- Comment #6 from Martin Jambor ---
(In reply to Markus Trippelsdorf from comment #3)
> ix=1 and m_vecpfx.m_num=1 in this case.
> Let me know what other debugging info may be useful to you.
Well, it might be difficult debugging this without reproducing it,
but...
It would be nice to know, at ipa-cp.c:937, what is the
IPA_NODE_REF(parms_info->ipcp_orig_node), especially the lengths of
the descriptors and lattices vectors. IPA_NODE_REF currently
translates to ipa_node_params_sum->get(parms_info->ipcp_orig_node) so
it should be easily printable in gdb.
Also, at ipa-inline-analysis.c:950, it is important to know where
parms_info came from, i.e. whether it was obtained as IPA_NODE_REF
(e->caller->global.inlined_to) or only IPA_NODE_REF (e->caller).
You might also try running with the following patch which should
hopefully find out where we create the first wrong jump function
(assuming that is the problem):
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index cfd9c16..7116c0f 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -2570,6 +2570,12 @@ update_jump_functions_after_inlining (struct cgraph_edge
*cs,
enum tree_code operation;
operation = ipa_get_jf_pass_through_operation (src);
+ struct ipa_node_params *new_root_info;
+ new_root_info = IPA_NODE_REF (cs->caller->global.inlined_to
+ ?
cs->caller->global.inlined_to
+ : cs->caller);
+ gcc_assert (formal_id < ipa_get_param_count
(new_root_info));
+
if (operation == NOP_EXPR)
{
bool agg_p;
@@ -4570,6 +4576,8 @@ ipa_read_jump_function (struct lto_input_block *ib,
if (operation == NOP_EXPR)
{
int formal_id = streamer_read_uhwi (ib);
+ gcc_assert (formal_id
+ < ipa_get_param_count (IPA_NODE_REF (cs->caller)));
struct bitpack_d bp = streamer_read_bitpack (ib);
bool agg_preserved = bp_unpack_value (&bp, 1);
ipa_set_jf_simple_pass_through (jump_func, formal_id, agg_preserved);
@@ -4578,6 +4586,8 @@ ipa_read_jump_function (struct lto_input_block *ib,
{
tree operand = stream_read_tree (ib, data_in);
int formal_id = streamer_read_uhwi (ib);
+ gcc_assert (formal_id
+ < ipa_get_param_count (IPA_NODE_REF (cs->caller)));
ipa_set_jf_arith_pass_through (jump_func, formal_id, operand,
operation);
}
[Bug c/65275] Disappearing -Wsequence-point warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65275 --- Comment #2 from joseph at codesourcery dot com --- The warning here appears to be bogus; the code looks well-defined to me.
[Bug libgcc/65306] make error with clang on OSX 10.9.5 -- movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65306 howarth at bromo dot med.uc.edu changed: What|Removed |Added CC||howarth at bromo dot med.uc.edu --- Comment #6 from howarth at bromo dot med.uc.edu --- I don't see this problem with the same Xcode 6.1.1 and associated command line tools package installed on 10.9.4 as current gcc-4_9_branch... % ../gcc-4.9.3-20150227/configure --prefix=/Users/howarth/dist --enable-languages=c,c++ --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-threads --enable-static bootstraps fine here. The fact that you aren't aren't using -with-gmp or --with-mpc is rather disconcerting as it suggests you have been installing into the system directories instead of /usr/local or /opt. If so, I would suggest reinstalling the OS to purge out anything you've installed in the system directories.
[Bug c++/65284] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65284
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2015-03-03 00:00:00 |2015-03-04
CC||aldyh at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Aldy Hernandez ---
Confirmed with --enable-checking=release and a cross build:
$ ./cc1plus a.ii -quiet -std=c++11 -I./ -O2
a.ii: In member function ‘Maybe ParsedSchema::findNested()
const’:
a.ii:45:21: internal compiler error: Segmentation fault
Maybe ParsedSchema::findNested() const {
I'll take a look.
[Bug tree-optimization/65307] [4.9/5 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307
--- Comment #11 from Richard Biener ---
Fixed 4.9 assert:
gcc_assert ((valv & ~val.mask
& ~nonzero_bits & mask).is_zero ());
fixed trunk assert:
@@ -1901,9 +1922,14 @@ evaluate_stmt (gimple stmt)
}
else
{
- if (wi::bit_and_not (val.value, nonzero_bits) != 0)
- val.value = wide_int_to_tree (TREE_TYPE (lhs),
- nonzero_bits & val.value);
+ widest_int tem = wi::bit_and_not (wi::to_widest (val.value),
+ extend_mask (nonzero_bits));
+ if (tem != 0)
+ {
+ gcc_assert (tem.and_not (val.mask) == 0);
+ val.value = wide_int_to_tree (TREE_TYPE (lhs),
+ nonzero_bits & val.value);
+ }
if (nonzero_bits == 0)
val.mask = 0;
else
That is, when CCP computes a constant it verifies that nonzero bits info
is consistent with that.
Such assert might not be ready for prime-time as for example in unreachable
code-regions any inconsistency can happen, like in
if ((i & 1) == 0) { if (i == 3) { } }
[Bug lto/65302] [5 Regression] LTO: ICE internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65302 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug tree-optimization/65307] [4.9/5 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307
Richard Biener changed:
What|Removed |Added
Known to work|5.0 |
Summary|[4.9 Regression] Incorrect |[4.9/5 Regression]
|optimization breaks basic |Incorrect optimization
|arithmetic |breaks basic arithmetic
Known to fail||5.0
--- Comment #10 from Richard Biener ---
The simpler testcase reproduces on trunk for me. Trunk assert:
Index: gcc/tree-ssa-ccp.c
===
--- gcc/tree-ssa-ccp.c (revision 221174)
+++ gcc/tree-ssa-ccp.c (working copy)
@@ -1901,9 +1922,13 @@ evaluate_stmt (gimple stmt)
}
else
{
- if (wi::bit_and_not (val.value, nonzero_bits) != 0)
- val.value = wide_int_to_tree (TREE_TYPE (lhs),
- nonzero_bits & val.value);
+ wide_int tem = wi::bit_and_not (val.value, nonzero_bits);
+ if (tem != 0)
+ {
+ gcc_assert (extend_mask (tem).and_not (val.mask) == 0);
+ val.value = wide_int_to_tree (TREE_TYPE (lhs),
+ nonzero_bits & val.value);
+ }
if (nonzero_bits == 0)
val.mask = 0;
else
[Bug tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307
Richard Biener changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #9 from Richard Biener ---
Visiting statement:
# RANGE [0, 4294967295] NONZERO 0x0fffe
_5 = 15;
which is likely CONSTANT
Lattice value changed to CONSTANT 14. Adding SSA edges to worklist.
is of course overly optimistic ;) (but yes, nonzero bits info is bogus)
I'd say we should eventually assert instead of miscompiling things.
That is,
static prop_value_t
evaluate_stmt (gimple stmt)
{
...
if (flag_tree_bit_ccp
&& ((is_constant && TREE_CODE (val.value) == INTEGER_CST)
|| (!is_constant && likelyvalue != UNDEFINED))
&& gimple_get_lhs (stmt)
&& TREE_CODE (gimple_get_lhs (stmt)) == SSA_NAME)
{
if (!is_constant)
{
...
}
else
{
double_int valv = tree_to_double_int (val.value);
here assert
gcc_assert ((valv & ~val.mask & ~nonzero_bits).is_zero ());
that is, known bits in valv should be consistent with nonzero_bits info.
if (!(valv & ~nonzero_bits & mask).is_zero ())
val.value = double_int_to_tree (TREE_TYPE (lhs),
valv & nonzero_bits);
if (nonzero_bits.is_zero ())
val.mask = double_int_zero;
else
val.mask = val.mask & (nonzero_bits | ~mask);
}
[Bug target/65248] Copy relocation in PIE against protected symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248 H.J. Lu changed: What|Removed |Added Summary|[5 Regression] Copy |Copy relocation in PIE |relocation in PIE against |against protected symbol |protected symbol| --- Comment #2 from H.J. Lu --- It never worked with normal executable. I proposed a solution: https://groups.google.com/forum/#!topic/x86-64-abi/Nbfw6bX0DpI
[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175 --- Comment #33 from rguenther at suse dot de --- On Wed, 4 Mar 2015, dje at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175 > > --- Comment #32 from David Edelsohn --- > "So currently on a tie we don't vectorize basic-blocks (same with GCC 4.8). > That's kind of arbitrary, but given instruction encoding size on x86 for > example > it makes sense." That was just a random comment and not the design decision for that code. If costs are near tie then it becomes quite arbitrary given the very very simple cost modeling of the scalar code. That we choose to keep the scalar code in case the cost model says its equally expensive than the vectorized code is an arbitrary choice. I wonder if in this particular case the vectorized or the scalar version is faster (on ppc)?
[Bug tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #8 from Mikhail Maltsev ---
A simpler testcase:
static inline unsigned cp(unsigned x)
{
return x;
}
unsigned f(unsigned x)
{
return cp(x * 2) * 2 + cp(cp(x * 2) * 3) * 5;
}
$ cat ./test1.c.085t.phiopt2
;; Function f (f, funcdef_no=1, decl_uid=1393, symbol_order=1)
f (unsigned int x)
{
unsigned int _2;
unsigned int _3;
unsigned int _4;
unsigned int _5;
unsigned int _6;
:
_2 = x_1(D) * 2;
_5 = 15;
_3 = _5 + 2;
_4 = _2 * _3;
_6 = _4;
return _6;
}
$ cat ./test1.c.087t.ccp3
;; Function f (f, funcdef_no=1, decl_uid=1393, symbol_order=1)
Pass statistics:
Immediate_uses:
x_1(D) : --> single use.
_2 = x_1(D) * 2;
_2 : --> single use.
_4 = _2 * _3;
_3 : --> single use.
_4 = _2 * _3;
_4 : --> single use.
_6 = _4;
_5 : --> single use.
_3 = _5 + 2;
_6 : --> single use.
return _6;
.MEM_7(D) : --> single use.
# VUSE <.MEM_7(D)>
return _6;
Adding Destination of edge (0 -> 2) to worklist
Simulating block 2
Visiting statement:
# RANGE [0, 4294967295] NONZERO 0x0fffe
_2 = x_1(D) * 2;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x0 (0x0fffe).
Adding SSA edges to worklist.
Visiting statement:
# RANGE [0, 4294967295] NONZERO 0x0fffe
_5 = 15;
which is likely CONSTANT
Lattice value changed to CONSTANT 14. Adding SSA edges to worklist.
Visiting statement:
_3 = _5 + 2;
which is likely CONSTANT
Lattice value changed to CONSTANT 16. Adding SSA edges to worklist.
Visiting statement:
_4 = _2 * _3;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x0 (0x0ffe0).
Adding SSA edges to worklist.
Visiting statement:
# RANGE [0, 4294967295] NONZERO 0x0fffe
_6 = _4;
Lattice value changed to CONSTANT 0x0 (0x0ffe0).
Adding SSA edges to worklist.
Visiting statement:
# VUSE <.MEM_7(D)>
return _6;
No interesting values produced. Marked VARYING.
Substituting values and folding statements
Folding statement: return _6;
Not folded
Folding statement: _6 = _4;
Not folded
Folding statement: _4 = _2 * _3;
Folded into: _4 = _2 * 16;
Removing dead stmt _3 = 16;
Removing dead stmt _5 = 14;
Folding statement: _2 = x_1(D) * 2;
Not folded
Pass statistics:
Constants propagated: 1
Statements deleted: 2
f (unsigned intD.4 xD.1392)
{
unsigned intD.4 _2;
unsigned intD.4 _4;
unsigned intD.4 _6;
;; basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
# RANGE [0, 4294967295] NONZERO 0x0fffe
_2 = x_1(D) * 2;
# RANGE [0, 4294967295] NONZERO 0x0ffe0
_4 = _2 * 16;
# RANGE [0, 4294967295] NONZERO 0x0ffe0
_6 = _4;
# VUSE <.MEM_7(D)>
return _6;
;;succ: EXIT [100.0%]
}
[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175 --- Comment #32 from David Edelsohn --- "So currently on a tie we don't vectorize basic-blocks (same with GCC 4.8). That's kind of arbitrary, but given instruction encoding size on x86 for example it makes sense."
[Bug c++/65309] [4.9 Regression] Executes wrong function inside an anonymous namespace on runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65309 Markus Trippelsdorf changed: What|Removed |Added Known to work||5.0 Summary|[4.9/5 Regression] Executes |[4.9 Regression] Executes |wrong function inside an|wrong function inside an |anonymous namespace on |anonymous namespace on |runtime |runtime Known to fail|5.0 | --- Comment #11 from Markus Trippelsdorf --- The issue was fixed on trunk by r220991.
[Bug tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 Known to work||4.8.3, 5.0 Known to fail||4.9.2
[Bug middle-end/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65233 --- Comment #23 from Richard Biener --- Created attachment 34950 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34950&action=edit CFG debugging Just FYI - this is a local CFG debugging patch I use. Just do (gdb) p debug_dot_cfg (cfun) from anywhere you like and get 'dot -Tx11' of the CFG spawned in the background (you can continue debugging).
[Bug middle-end/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65233
--- Comment #22 from Richard Biener ---
The error is to do anything that possibly relies on an up-to-date SSA web when
need_ssa_update () is true.
In fact the polymorphic call code walks to the PHI which is already dead
(it's block is gone). So while we don't ICE we certainly look at released
stuff still. I remember we had name_registered_for_update_p guards in
tree-cfgcleaup.c code, like on the 4.5 branch in cleanup_control_expr_graph:
case GIMPLE_COND:
{
tree lhs = gimple_cond_lhs (stmt);
tree rhs = gimple_cond_rhs (stmt);
/* For conditions try harder and lookup single-argument
PHI nodes. Only do so from the same basic-block though
as other basic-blocks may be dead already. */
if (TREE_CODE (lhs) == SSA_NAME
&& !name_registered_for_update_p (lhs))
{
gimple def_stmt = SSA_NAME_DEF_STMT (lhs);
the issue with needing cfg-cleanup before update-ssa is unreachable blocks
don't play well with computing dominators which update-ssa needs. But
we also obviously cannot fix SSA form in this case without removing unreachable
blocks first. And if we do that, and then fixup SSA form that will still fail
because threading _did_ fail to update the PHI node in BB 13 - where's the
definition of SR33_23 supposed to be? I see that it is later updated to
be SR.33_45.
It's also odd that it chose to duplicate bb 30 at all (to bb 48). I see
no good reason to do that.
I think a better workaround for the bug is
Index: ipa-polymorphic-call.c
===
--- ipa-polymorphic-call.c (revision 221149)
+++ ipa-polymorphic-call.c (working copy)
@@ -81,6 +81,8 @@ along with GCC; see the file COPYING3.
#include "data-streamer.h"
#include "lto-streamer.h"
#include "streamer-hooks.h"
+#include "tree-ssa-operands.h"
+#include "tree-into-ssa.h"
/* Return true when TYPE contains an polymorphic type and thus is interesting
for devirtualization machinery. */
@@ -804,7 +806,7 @@ walk_ssa_copies (tree op, hash_set
STRIP_NOPS (op);
while (TREE_CODE (op) == SSA_NAME
&& !SSA_NAME_IS_DEFAULT_DEF (op)
-&& SSA_NAME_DEF_STMT (op)
+&& !name_registered_for_update_p (op)
&& (gimple_assign_single_p (SSA_NAME_DEF_STMT (op))
|| gimple_code (SSA_NAME_DEF_STMT (op)) == GIMPLE_PHI))
{
@@ -835,10 +837,7 @@ walk_ssa_copies (tree op, hash_set
{
gimple phi = SSA_NAME_DEF_STMT (op);
- if (gimple_phi_num_args (phi) > 2
- /* We can be called while cleaning up the CFG and can
-have empty PHIs about to be removed. */
- || gimple_phi_num_args (phi) == 0)
+ if (gimple_phi_num_args (phi) > 2)
goto done;
if (gimple_phi_num_args (phi) == 1)
op = gimple_phi_arg_def (phi, 0);
I'm going to bootstrap & test this.
Still the block duplication during threading that happens looks odd to me.
[Bug target/65313] New: Compilation error in lto profiledbootstrap on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65313 Bug ID: 65313 Summary: Compilation error in lto profiledbootstrap on powerpc64le-unknown-linux-gnu Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target: powerpc64le-unknown-linux-gnu $ ../configure --prefix=/home/marxin/bin/gcc --disable-multilib --enable-checking=release --with-build-^Cnfig=bootstrap-lto $ make profiledboostrap error: /home/marxin/gcc/objdir/./prev-gcc/xg++ -B/home/marxin/gcc/objdir/./prev-gcc/ -B/home/marxin/bin/gcc/powerpc64le-unknown-linux-gnu/bin/ -nostdinc++ -B/home/marxin/gcc/objdir/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/marxin/gcc/objdir/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/marxin/gcc/objdir/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/marxin/gcc/objdir/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/marxin/gcc/libstdc++-v3/libsupc++ -L/home/marxin/gcc/objdir/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/marxin/gcc/objdir/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace -o insn-automata.o -MT insn-automata.o -MMD -MP -MF ./.deps/insn-automata.TPo insn-automata.c ../../libcpp/lex.c: In function ‘_cpp_clean_line’: ../../libcpp/lex.c:555:53: error: Builtin function __builtin_altivec_vcmpequb requires the -maltivec option m_nl = (vc) __builtin_vec_cmpeq(data, repl_nl); ^ ../../libcpp/lex.c:556:53: error: Builtin function __builtin_altivec_vcmpequb requires the -maltivec option m_cr = (vc) __builtin_vec_cmpeq(data, repl_cr); ^ ../../libcpp/lex.c:557:53: error: Builtin function __builtin_altivec_vcmpequb requires the -maltivec option m_bs = (vc) __builtin_vec_cmpeq(data, repl_bs); ^ ../../libcpp/lex.c:558:53: error: Builtin function __builtin_altivec_vcmpequb requires the -maltivec option m_qm = (vc) __builtin_vec_cmpeq(data, repl_qm); ^ ../../libcpp/lex.c:565:33: error: Builtin function __builtin_altivec_vcmpequb_p requires the -maltivec option while (!__builtin_vec_vcmpeq_p(/*__CR6_LT_REV*/3, t, zero)); ^ ../../libcpp/lex.c:555:53: error: Builtin function __builtin_altivec_vcmpequb requires the -maltivec option m_nl = (vc) __builtin_vec_cmpeq(data, repl_nl); ^ ../../libcpp/lex.c:556:53: error: Builtin function __builtin_altivec_vcmpequb requires the -maltivec option m_cr = (vc) __builtin_vec_cmpeq(data, repl_cr); ^ ../../libcpp/lex.c:557:53: error: Builtin function __builtin_altivec_vcmpequb requires the -maltivec option m_bs = (vc) __builtin_vec_cmpeq(data, repl_bs); ^ ../../libcpp/lex.c:558:53: error: Builtin function __builtin_altivec_vcmpequb requires the -maltivec option m_qm = (vc) __builtin_vec_cmpeq(data, repl_qm); ^ ../../libcpp/lex.c:565:33: error: Builtin function __builtin_altivec_vcmpequb_p requires the -maltivec option while (!__builtin_vec_vcmpeq_p(/*__CR6_LT_REV*/3, t, zero)); ^ ../../libcpp/lex.c:555:53: error: Builtin function __builtin_altivec_vcmpequb requires the -maltivec option m_nl = (vc) __builtin_vec_cmpeq(data, repl_nl); ^ ../../libcpp/lex.c:556:53: error: Builtin function __builtin_altivec_vcmpequb requires the -maltivec option m_cr = (vc) __builtin_vec_cmpeq(data, repl_cr); ^ ../../libcpp/lex.c:557:53: error: Builtin function __builtin_altivec_vcmpequb requires the -maltivec option m_bs = (vc) __builtin_vec_cmpeq(data, repl_bs); ^ ../../libcpp/lex.c:558:53: error: Builtin function __builtin_altivec_vcmpequb requires the -maltivec option m_qm = (vc) __bu
[Bug tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307
--- Comment #7 from Kai Tietz ---
Well, it looked like the same issue by inspection dumps, as folding issue
happens in reassoc-pass. Of course it might be that forward-prop patch is the
actual issue.
I noticed for -O3 on 4.9.x that valid computation (dse1):
...
g (const unsigned int from_f)
{
const unsigned int thirty_four;
unsigned int _3;
unsigned int _4;
unsigned int global.0_8;
unsigned int _9;
unsigned int _10;
:
global.0_8 = global;
_9 = global.0_8 * 2;
_3 = _9 * 2;
_10 = _9 * 3;
_4 = _10 * 5;
thirty_four_5 = _3 + _4;
...
Shows after reassoc1 pass:
...
g (const unsigned int from_f)
{
const unsigned int thirty_four;
unsigned int _3;
unsigned int _4;
unsigned int global.0_8;
unsigned int _9;
unsigned int _10;
:
global.0_8 = global;
_9 = global.0_8 * 2;
_4 = 15;
_3 = _4 + 2;
_10 = _9 * _3;
thirty_four_5 = _10;
...
so it seems to be the forward-propagate patch.
Sorry for the noise
[Bug c++/65312] Implicitly-declared default constructor must be defined as deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65312
--- Comment #3 from Jonathan Wakely ---
The {} means value-initialization as opposed to default-initialization.
I think value-init requires the compiler to zero out all the members first,
even though they will be given another value anyway.
I haven't checked the generated code, but that would be my guess (and I would
hope the dead stores can be optimized away).
[Bug tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307 Manuel López-Ibáñez changed: What|Removed |Added Status|RESOLVED|REOPENED CC||manu at gcc dot gnu.org Resolution|DUPLICATE |--- --- Comment #6 from Manuel López-Ibáñez --- (In reply to Kai Tietz from comment #4) > This is a duplicate of PR/65216. Underlying issue is in reassoc1-pass. > This issue is fixed for 5.0 > > *** This bug has been marked as a duplicate of bug 65216 *** Is it fixed in 4.9.x? Because that PR 65216 is marked as fixed and does not mention 4.9.x, only 5.0.
[Bug tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307 --- Comment #5 from Marek Polacek --- Why do you think it is a duplicate? PR65216 was a 5 Regression, something that worked in 4.9; this one is an issue with 4.9 and not 5. PR65216 was also about -O3 only, this one fails even with -O2. PR65216 started after this one got fixed.
[Bug tree-optimization/65216] [5 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65216 Kai Tietz changed: What|Removed |Added CC||madars+gccbug at gmail dot com --- Comment #8 from Kai Tietz --- *** Bug 65307 has been marked as a duplicate of this bug. ***
[Bug c++/65312] Implicitly-declared default constructor must be defined as deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65312
--- Comment #2 from radventure at yandex dot ru ---
(In reply to Jonathan Wakely from comment #1)
> I believe this is a GCC extension, G++ implements the proposed resolution of
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#253 and since
> all sub-objects of List are correctly initialized, no initializer is
> required for the member of that type.
Ok. Other question on a little bit another code. Why generated output so
dramatically changed when I removed initializer of 'data' member of Array
struct (//Here commented)
#include
#include
constexpr uint64_t Fib(uint32_t i)
{
return (i < 2)? i: (Fib(i - 1) + Fib(i - 2));
}
template struct List
{
const uint64_t val = Fib(Z - N);
const List next{};
};
template struct List
{
const uint64_t value = Fib(Z - 0);
};
template struct Array
{
const List data{}; //Here
const uint64_t *table = reinterpret_cast(&data);
constexpr uint32_t size() const { return Z; }
};
Array<20u> array;
int main()
{
for (uint32_t i(0); i < array.size(); ++i)
std::cout << array.table[i] << " ";
}
[Bug tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Kai Tietz --- This is a duplicate of PR/65216. Underlying issue is in reassoc1-pass. This issue is fixed for 5.0 *** This bug has been marked as a duplicate of bug 65216 ***
[Bug libgcc/65306] make error with clang on OSX 10.9.5 -- movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65306 --- Comment #5 from Maxim Kuvyrkov --- No need to rebuild the whole GCC with -save-temps. Just go to directory where compilation of extenddftf2_s.o takes place and copy-paste the compilation command for that one file with addition of -save-temps. I'm not familiar with "Apple Inc version cctools-862, GNU assembler version 1.38", so it may be that assembler is broken or too old; you may have to build recent binutils for your GCC to use.
[Bug c++/65309] [4.9/5 Regression] Executes wrong function inside an anonymous namespace on runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65309 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Known to work||4.8.4, 4.9.2 Summary|[4.9 Regression] Executes |[4.9/5 Regression] Executes |wrong function inside an|wrong function inside an |anonymous namespace on |anonymous namespace on |runtime |runtime Known to fail||4.9.3, 5.0 --- Comment #10 from Richard Biener --- Confirmed also on trunk. P1 because of a regression on the branch that wasn't released yet.
[Bug c++/65312] Implicitly-declared default constructor must be defined as deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65312 --- Comment #1 from Jonathan Wakely --- I believe this is a GCC extension, G++ implements the proposed resolution of http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#253 and since all sub-objects of List are correctly initialized, no initializer is required for the member of that type.
[Bug c++/65311] Segmentation fault when doing unaligned assignment in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65311 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Biener --- Well, you get the loop vectorized and using aligned accesses which makes your CPU trip over this.
[Bug c++/65312] New: Implicitly-declared default constructor must be defined as deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65312
Bug ID: 65312
Summary: Implicitly-declared default constructor must be
defined as deleted
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: radventure at yandex dot ru
I think the next code should not be successfully compiled because of
implicitly-declared default constructor of Array struct should be deleted
#include
#include
constexpr uint64_t Fib(uint32_t i)
{
return (i < 2)? i: (Fib(i - 1) + Fib(i - 2));
}
template struct List
{
const uint64_t val = Fib(Z - N);
List next;
};
template struct List
{
const uint64_t value = Fib(Z - 0);
};
template struct Array
{
const List data;
const uint64_t *table = reinterpret_cast(&data);
constexpr uint32_t size() const { return Z; }
};
Array<20u> array;
int main()
{
for (uint32_t i(0); i < array.size(); ++i)
std::cout << array.table[i] << " ";
}
[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270 --- Comment #15 from Richard Biener --- Ok, as variable merging always creates aliases accesses and their types remain the same. So we don't need any extra checks for merging globals here.
[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270 --- Comment #14 from Richard Biener --- Created attachment 34949 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34949&action=edit function parameter and variable part I am testing that in addition.
[Bug c++/65311] New: Segmentation fault when doing unaligned assignment in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65311 Bug ID: 65311 Summary: Segmentation fault when doing unaligned assignment in a loop Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: emil.styrke at gmail dot com Created attachment 34948 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34948&action=edit Demonstration of bug (no includes) The attached code segfaults when compiled with -O3. I realize the code is dodgy (and breaks strict aliasing rules according to my understanding), but even with -fno-strict-aliasing it breaks. It works fine on -O2. $ g++-4.9 -o test test.cpp -Wall -Wextra -O3 -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations $ ./test Segmenteringsfel (minnesutskrift skapad) $ g++-4.9 -v Using built-in specs. COLLECT_GCC=g++-4.9 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.1-16ubuntu6' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6)
[Bug c++/65309] [4.9 Regression] Executes wrong function inside an anonymous namespace on runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65309 Markus Trippelsdorf changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|[Regression] Executes wrong |[4.9 Regression] Executes |function inside an |wrong function inside an |anonymous namespace on |anonymous namespace on |runtime |runtime --- Comment #9 from Markus Trippelsdorf --- Started with r219305.
[Bug c/65120] [5 Regression] Wlogical-not-parentheses should not warn about double exclamation !!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120 --- Comment #9 from Richard Biener --- Btw, just saw > [ 2808s] ../drivers/xen/sfc_netfront/falcon_event.c:113:43: error: logical > not is only applied to the left hand side of comparison > [-Werror=logical-not-parentheses] > [ 2808s] BUG_ON(!QWORD_GET_U(RX_EV_BYTE_CNT, *ev) == 0); > [ 2808s]^ which I think we should preserve - so make sure that the !! special-casing doesn't cover this case from macro expansion.
[Bug c++/65308] [C++14] auto-returning function template used inside function template doesn't allow template members to be called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65308 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid --- Comment #2 from Jonathan Wakely --- Actually no, the 'template' keyword is not required there, but maybe G++ is confused into thinking that the expression is dependent because of the deduced return type for make_thing()
