[Bug c/63673] New: VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63673
Bug ID: 63673
Summary: VSX intrinsic vec_vsx_ld fails to compile with double,
maps to wrong instructions with float
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Created attachment 33836
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33836action=edit
failing to compile testcase for vec_vsx_ld using doubles
These are actually two issues, but I'm filing a single bug report as it looks
like they are related.
First the build error, I've created a small failing testcase (also attached):
--
#include altivec.h
int main() {
double __attribute__((aligned(16))) d[4] = {0.0, 1.0, 2.0, 3.0 };
vector double v = vec_vsx_ld(8, d); // should load {1.0, 2.0}
}
--
This fails to compile under Debian gcc (4.9.1-19), with the following error:
$ gcc vec_vsx_ld_fail.c -c
vec_vsx_ld_fail.c: In function ‘main’:
vec_vsx_ld_fail.c:6:2: error: invalid parameter combination for AltiVec
intrinsic
vector double v = vec_vsx_ld(4, d); // should load {1.0, 2.0}
Casting d to (float *) makes it compile, but vec_vsx_ld intrinsic definitely
should handle double parameters, so I think this is a bug.
Now the second problem, a similar testcase for float (also attached):
--
#include altivec.h
int main() {
float __attribute__((aligned(16))) f[8] = {0.0, 1.0, 2.0, 3.0, 4.0,
5.0, 6.0, 7.0 };
vector float v = vec_vsx_ld(4, f); // should load {1.0, 2.0, 3.0, 4.0}
}
--
This does compile, but the asm output uses the lxvd2x asm instruction, when
according the the ISA, lxvw4x should be used -at least according to my
understanding (page 359, Power ISA 2.07). Asm output also attached.
[Bug c/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63673 --- Comment #1 from Konstantinos Margaritis markos at freevec dot org --- Created attachment 33837 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33837action=edit testcase for vec_vsx_ld using floats
[Bug c/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63673 --- Comment #2 from Konstantinos Margaritis markos at freevec dot org --- Created attachment 33838 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33838action=edit asm output for testcase for vec_vsx_ld using floats
[Bug target/63661] [4.9/5 Regression] -O2 miscompiles on OSX 10.10 Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jamborm at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r204698 , you can use -O2 -fpic -mtune=corei7 in compilers that don't grok -mtune=nehalem.
[Bug target/63661] [4.9/5 Regression] -O2 miscompiles on OSX 10.10 Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661
--- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org ---
Slightly reduced testcase:
static void
foo (double a, double q, double xx, double *ff, double *gx, int e, int ni)
{
int ii, nn;
double g1 = *gx;
ff[ni] = xx;
if (e == 0)
{
for (ii = 0; ii ni; ii++)
{
nn = 100 - ii - 1;
ff[ni - ii - 1]
= -1.0 / ((4 * (nn + 1) * (nn + 1) - a) / q + ff[ni - ii]);
}
}
else
{
for (ii = 0; ii ni; ii++)
{
nn = 100 - ii - 1;
ff[ni - ii - 1]
= -1.0 / (((2 * nn + 1) * (2 * nn + 1) - a) / q + ff[ni - ii]);
}
}
*gx = ff[0] - g1;
}
int
bar (int order, double q, double a, double c[])
{
int ni, nn, i, e;
double eps, g1, g2, x1, x2, e1, e2, de, xh, s, ratio, ff[100];
eps = 1e-10;
c[0] = 1.0;
e = 0;
if (order % 2 != 0)
e = 1;
if (q == 0.0)
{
for (i = 0; i 100; i++)
c[i] = 0.0;
c[(order - 1) / 2] = 1.0;
return 0;
}
if (order 5)
{
nn = 0;
s = 0.0;
if (e == 0)
ratio = (a - 4) / q;
else
ratio = (a - 1 - q) / q;
}
else
{
if (e == 0)
{
c[1] = (a - 4) / q;
s = 2 * c[0] + 4 * c[1];
for (i = 2; i order / 2; i++)
{
c[i] = (a - 4 * i * i) / q * c[i - 1] - c[i - 2];
s += 2 * (i + 1) * c[i];
}
}
else
{
c[1] = (a - 1) / q + 1;
s = c[0] + 3 * c[1];
for (i = 2; i order / 2 + 1; i++)
{
c[i] = (a - (2 * i - 1) * (2 * i - 1)) / q * c[i - 1] - c[i - 2];
s += (2 * (i + 1) - 1) * c[i];
}
}
nn = i - 1;
ratio = c[nn] / c[nn - 1];
}
ni = 100 - nn - 1;
if (e == 0)
x1 = -q / (4.0 * (100 + 1.0) * (100 + 1.0));
else
x1 = -q / ((2.0 * 100 + 1.0) * (2.0 * 100 + 1.0));
g1 = ratio;
foo (a, q, x1, ff, g1, e, ni);
x2 = g1;
g2 = ratio;
while (1)
{
__builtin_printf (loop %g\n, g2);
e1 = g1 - x1;
e2 = g2 - x2;
de = e1 - e2;
if (__builtin_fabs (de) eps)
break;
xh = (e1 * x2 - e2 * x1) / de;
x1 = x2;
g1 = g2;
x2 = xh;
g2 = ratio;
foo (a, q, x2, ff, g2, e, ni);
}
s += 2 * (nn + 1) * c[nn];
for (i = nn + 1; i 100; i++)
{
c[i] = ff[i - nn - 1] * c[i - 1];
s += 2 * (i + 1) * c[i];
if (__builtin_fabs (c[i]) 1e-20)
for (; i 100;)
c[i++] = 0.0;
}
for (i = 0; i 100; i++)
c[i] /= s;
return 0;
}
int
main ()
{
double c[100];
bar (1, 5.0, -5.790080598637771, c);
return 0;
}
[Bug inline-asm/62144] Frame pointer required, but reserved error with -fomit-frame-pointer but only with -m32 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144 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 --- I'd note that -fomit-frame-pointer is never a guarantee that frame pointer will be omitted, there are still tons of cases where it can't be omitted, VLAs, alloca, various specialized builtins, etc.
[Bug preprocessor/63662] __has_include is not implemented but it is defined, so #ifdef __has_include guards are ineffective in blocking usage of __has_include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Are you sure you've built your compiler properly. I've indeed reproduced this in my 4.9 tree, but only because I've only done make in the gcc subdir after updating to latest 4.9 branch and not in libcpp first. So, it sounds like you have the same case, compiler that predefines __has_include, but libcpp that doesn't handle it.
[Bug ada/62235] segmentation fault on Ada 2012 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62235 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-29 CC||ebotcazou at gcc dot gnu.org Summary|Storage_Error in the|segmentation fault on Ada |compiler|2012 code Ever confirmed|0 |1 Severity|major |normal --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Confirmed, but it's not a Storage_Error but a segfault.
[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 --- Comment #20 from torvald at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #19) * carries_dependency is about increasing optimization, not decreasing it. If it affects when barriers are added, it does so by allowing some barriers to be omitted that would otherwise be required. That's not quite true, unfortunately, AFAIU. I agree that generally, attributes are supposed to be ignorable -- but in the case of carries_dependency, C++11 explicitly requires that all declarations of a function either have the attribute or none has (see 7.6.4p2). This is because you need that to actually exploit the attribute; it's a contract between callers and callees. If a compiler does try to preserve dependencies (or not across function boundaries), then ignoring the attribute is fine. But if there should be a compiler out there that doesn't, and GCC-generated code is supposed to link to that other compiler's code, then we need to do something to make this work.
[Bug tree-optimization/63666] [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/63666] [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Oct 29 09:22:55 2014 New Revision: 216825 URL: https://gcc.gnu.org/viewcvs?rev=216825root=gccview=rev Log: 2014-10-29 Richard Biener rguent...@suse.de PR tree-optimization/63666 * tree-vect-slp.c (vect_get_mask_element): Properly handle accessing out-of-bound elements. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug rtl-optimization/63210] ira does not select the best register compared with gcc 4.8 for ARM THUMB1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63210 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Zhenqiang Chen from comment #4) (In reply to Ramana Radhakrishnan from comment #3) Fixed is it? And does it fail in GCC 4.9 ? Fixed on trunk. Same fail in GCC 4.9. It is a performance issue. Do you think it is OK for 4.9? If it is a 4.9 regression you should be marking it as so in the bug report- change the title to [4.9 regression] and fill up the Known to Fail fields. I cannot possibly comment if it is suitable for 4.9 branch or not. I'm marking this as fixed for 5.0 - if you get this backported please remember to change the target milestone to the appropriate 4.9 milestone.
[Bug ipa/63671] [5 Regression] 21% tramp3d-v4 performance hit due to -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63671 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I suppose -flto is the same as -fwhole-program then? Maybe too much speculative inlining happens? Does using FDO mitigate the -fdevirtualize hit?
[Bug inline-asm/62144] Frame pointer required, but reserved error with -fomit-frame-pointer but only with -m32 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144 --- Comment #8 from Łukasz Kucharski luk32 at o2 dot pl --- Jakub, fair enough. However, changing the optimization level should not break the compilation. The issue is, at least for me, is not that we can't omit the frame pointer, but that it depends on the optimization level. I couldn't find anything in the docs, which would allow such behaviour. Maybe I missed it. Anyway, IMO at most a warning should be issued that a potential optimization conflicts with the flag. With regards, luk32.
[Bug inline-asm/62144] Frame pointer required, but reserved error with -fomit-frame-pointer but only with -m32 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- The documentation on -fomit-frame-pointer says: Don't keep the frame pointer in a register for functions that don't need one. where whether soemthing needs a frame pointer or not is not precisely defined (exactly because the actual check in the compiler whether something needs a frame pointer or not is not really something simple, and depends on many things). Whether we can avoid frame pointer on this exact testcase is something Vlad can perhaps look at, my answer was just general.
[Bug rtl-optimization/63340] [5.0 regression] FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63340 --- Comment #5 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Wed Oct 29 10:00:18 2014 New Revision: 216828 URL: https://gcc.gnu.org/viewcvs?rev=216828root=gccview=rev Log: gcc/ PR rtl-optimization/63340 (part 1) * ira-costs.c (all_cost_classes): New variable. (complete_cost_classes): New function, split out from... (setup_cost_classes): ...here. (initiate_regno_cost_classes): Set up all_cost_classes. (restrict_cost_classes): New function. (setup_regno_cost_classes_by_aclass): Restrict the cost classes to registers that are valid for the register's mode. (setup_regno_cost_classes_by_mode): Model the mode cache as a restriction of all_cost_classes to a particular mode. (print_allocno_costs): Remove contains_reg_of_mode check. (print_pseudo_costs, find_costs_and_classes): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-costs.c
[Bug rtl-optimization/63340] [5.0 regression] FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63340 --- Comment #6 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Wed Oct 29 10:02:33 2014 New Revision: 216829 URL: https://gcc.gnu.org/viewcvs?rev=216829root=gccview=rev Log: gcc/ PR rtl-optimization/63340 (part 2) * rtl.h (invalid_mode_change_p): Delete. (valid_mode_changes_for_regno): New function. * reginfo.c (invalid_mode_change_p): Delete. (valid_mode_changes_for_regno): New function. * ira-costs.c (setup_regno_cost_classes_by_aclass): Restrict the classes to registers that are allowed by valid_mode_changes_for_regno. (setup_regno_cost_classes_by_mode): Likewise. (print_allocno_costs): Remove invalid_mode_change_p test. (print_pseudo_costs, find_costs_and_classes): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-costs.c trunk/gcc/reginfo.c trunk/gcc/rtl.h
[Bug ipa/63671] [5 Regression] 21% tramp3d-v4 performance hit due to -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63671 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) I suppose -flto is the same as -fwhole-program then? Yes. Maybe too much speculative inlining happens? Hopefully Honza finds time to tune inlining before release. Does using FDO mitigate the -fdevirtualize hit? Yes.
[Bug c/52769] Unspecified designated initializer might not set to zero in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52769 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-29 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 Severity|major |normal --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- I'm adding the test.
[Bug fortran/63674] New: procedure pointer and non/pure procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63674 Bug ID: 63674 Summary: procedure pointer and non/pure procedure Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: valeryweber at hotmail dot com Dear All the following code is compiling fine with 4.9.1, but shouldnt gcc complain about calling a nonpure procedure from a pure one? v cat gcc_pure.f90 module test interface function func_interface ( ) RESULT( reslt ) INTEGER :: reslt end function func_interface end interface type :: t procedure(func_interface), nopass, pointer :: f = NULL() end type t contains function func_1 ( ) RESULT( reslt ) integer :: reslt reslt = 1 end function func_1 pure subroutine eval( a, reslt ) type(t), intent(in) :: a integer, intent(out) :: reslt reslt = a%f() !reslt = func_1() end subroutine eval end module test program prog use test type(t) :: a integer :: reslt a%f=func_1 call eval(a,reslt) write(*,*) reslt end program prog gfortran-4.9.1 gcc_pure.f90 ./a.out 1
[Bug tree-optimization/63666] [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666 --- Comment #8 from Jiong Wang jiwang at gcc dot gnu.org --- Created attachment 33839 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33839action=edit vshuf-v16hi.i Richard, after your fix, the issue still exist on arm-none-eabi. testcase attached. cc1 built by (../gcc/configure --target=arm-none-eabi --enable-languages=c,c++) ./cc1 -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=neon vshuf-v16hi.i -Os Breakpoint 1, fancy_abort (file=0x1492484 ../../gcc/gcc/gcse.c, line=2153, function=0x1492df0 process_insert_insn) at ../../gcc/gcc/diagnostic.c:1232 1232 internal_error (in %s, at %s:%d, function, trim_filename (file), line); (gdb) bt #0 fancy_abort (file=0x1492484 ../../gcc/gcc/gcse.c, line=2153, function=0x1492df0 process_insert_insn) at ../../gcc/gcc/diagnostic.c:1232 #1 0x0096b680 in process_insert_insn (expr=0x1db2800) at ../../gcc/gcc/gcse.c:2153 #2 0x0096b6da in insert_insn_end_basic_block (expr=0x1db2800, bb=0x76e13dd0) at ../../gcc/gcc/gcse.c:2175 #3 0x0096e03f in hoist_code () at ../../gcc/gcc/gcse.c:3471 #4 0x0096ea94 in one_code_hoisting_pass () at ../../gcc/gcc/gcse.c:3701 #5 0x0096f999 in execute_rtl_hoist () at ../../gcc/gcc/gcse.c:4191 #6 0x0096fae9 in (anonymous namespace)::pass_rtl_hoist::execute (this=0x1cecca0) at ../../gcc/gcc/gcse.c:4272 #7 0x00b4f445 in execute_one_pass (pass=0x1cecca0) at ../../gcc/gcc/passes.c:2156 #8 0x00b4f684 in execute_pass_list_1 (pass=0x1cecca0) at ../../gcc/gcc/passes.c:2208 #9 0x00b4f6b5 in execute_pass_list_1 (pass=0x1cec8e0) at ../../gcc/gcc/passes.c:2209 #10 0x00b4f6f7 in execute_pass_list (fn=0x76bca1f8, pass=0x1ce97c0) at ../../gcc/gcc/passes.c:2219 #11 0x007d9aa8 in cgraph_node::expand (this=0x76bcd000) at ../../gcc/gcc/cgraphunit.c:1742 #12 0x007da0c7 in expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1878 #13 0x007dac0d in symbol_table::compile (this=0x76c74000) at ../../gcc/gcc/cgraphunit.c:2213 #14 0x007dadc4 in symbol_table::finalize_compilation_unit (this=0x76c74000) at ../../gcc/gcc/cgraphunit.c:2290 #15 0x0063572d in c_write_global_declarations () at ../../gcc/gcc/c/c-decl.c:10641 #16 0x00c489fc in compile_file () at ../../gcc/gcc/toplev.c:574 #17 0x00c4ad22 in do_compile () at ../../gcc/gcc/toplev.c:1981 #18 0x00c4af2c in toplev::main (this=0x7fffe55f, argc=6, argv=0x7fffe658) at ../../gcc/gcc/toplev.c:2078 #19 0x013a02b2 in main (argc=6, argv=0x7fffe658) at ../../gcc/gcc/main.c:38
[Bug tree-optimization/63666] [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666 --- Comment #9 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 29 Oct 2014, jiwang at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666 --- Comment #8 from Jiong Wang jiwang at gcc dot gnu.org --- Created attachment 33839 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33839action=edit vshuf-v16hi.i Richard, after your fix, the issue still exist on arm-none-eabi. testcase attached. This looks like a completely different issue than the one reported in the initial description. Please open a separate bugreport.
[Bug tree-optimization/63666] [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #2)
Also breaks gcc.dg/vect/vect-strided-a-u8-i2-gap.c
$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/vect/vect-strided-a-u8-i2-gap.c
-ftree-vectorize -fno-vect-cost-model -fno-common -O2
-fdump-tree-vect-details -lm -o ./vect-strided-a-u8-i2-gap.exe
../gcc/testsuite/gcc.dg/vect/vect-strided-a-u8-i2-gap.c: In function ‘main1’:
../gcc/testsuite/gcc.dg/vect/vect-strided-a-u8-i2-gap.c:34:16: internal
compiler error: in expand_expr_real_2, at expr.c:9156
res[i].b = ptr-a;
^
0x4059052f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:9156
0x40579c1f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9463
0x4058b71f store_expr(tree_node*, rtx_def*, int, bool)
../../gcc/expr.c:5344
0x4059701f expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5130
0x40381b7f expand_gimple_stmt_1
../../gcc/cfgexpand.c:3285
0x40381b7f expand_gimple_stmt
../../gcc/cfgexpand.c:3381
0x4038d89f expand_gimple_basic_block
../../gcc/cfgexpand.c:5216
0x403916ef execute
../../gcc/cfgexpand.c:5822
This also still happens. The vectorizer generates (and verified)
vect_perm_even_77 = VEC_PERM_EXPR vect__22.9_74, vect__22.10_76, { 0, 2, 4,
6, 8, 10, 12, 14 };
vect_perm_odd_78 = VEC_PERM_EXPR vect__22.9_74, vect__22.10_76, { 1, 3, 5,
7, 9, 11, 13, 15 };
vect_inter_high_82 = VEC_PERM_EXPR vect_perm_even_77, vect_perm_even_77, {
0, 8, 1, 9, 2, 10, 3, 11 };
vect_inter_low_83 = VEC_PERM_EXPR vect_perm_even_77, vect_perm_even_77, { 4,
12, 5, 13, 6, 14, 7, 15 };
then we unroll the loop and forwprop4 comes along changing
vect_perm_even_145 = VEC_PERM_EXPR vect__22.9_142, vect__22.10_144, { 0, 2,
4, 6, 8, 10, 12, 14 };
vect_inter_high_146 = VEC_PERM_EXPR vect_perm_even_145, vect_perm_even_145,
{ 0, 8, 1, 9, 2, 10, 3, 11 };
to
vect_perm_even_145 = VEC_PERM_EXPR vect__22.9_142, vect__22.10_144, { 0, 2,
4, 6, 8, 10, 12, 14 };
vect_inter_high_146 = VEC_PERM_EXPR vect_perm_even_145, vect_perm_even_145,
{ 0, 0, 1, 1, 2, 2, 3, 3 };
which isn't a supported permutation. It looks like
fold-const.c:fold_ternary_loc doesn't care about only generating supported
permutations and the fallback code in expand_vec_perm doesn't cover all
cases.
[Bug ada/63675] New: Non-confirming aspect doesn’t fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63675 Bug ID: 63675 Summary: Non-confirming aspect doesn’t fail Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Created attachment 33840 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33840action=edit Reproducer This arises from checking the status of PR/56196 (which is, itself, now fixed). There is an untagged base type with aspects Unchecked_Union and C_Pass_By_Copy, a primitive subprogram of the base type, and three derived types. All derived types result in warnings union.ads:15:06: warning: variant record has no direct equivalent in C union.ads:15:06: warning: use of convention for type Derived_1 is dubious union.ads:15:06: warning: variant record has no direct equivalent in C union.ads:15:06: warning: use of convention for type Derived_2 is dubious union.ads:15:06: warning: variant record has no direct equivalent in C union.ads:15:06: warning: use of convention for type Derived_3 is dubious which (a) shouldn’t be a problem, I think, and (b) are on the line at which the base type is declared, rather than on the line where the “dubious” derived type is declared. The first derived type has no aspects. The second derived type has aspect Unchecked_Union = False, which conflicts with that of the base type, and *is not rejected*. The third derived type has aspect Unchecked_Union = True, which confirms that of the base type, and *is* rejected. union.ads:29:36: representation item appears too late union.ads:29:36: primitive operations already defined for Base I think both of derived types with aspects should be rejected.
[Bug tree-optimization/63666] [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666
--- Comment #11 from Richard Biener rguenth at gcc dot gnu.org ---
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 216834)
+++ gcc/fold-const.c(working copy)
@@ -82,6 +82,7 @@ along with GCC; see the file COPYING3.
#include ipa-ref.h
#include cgraph.h
#include generic-match.h
+#include optabs.h
/* Nonzero if we are folding constants inside an initializer; zero
otherwise. */
@@ -14311,7 +14331,8 @@ fold_ternary_loc (location_t loc, enum t
if (op0 == op1 !single_arg)
changed = true;
- if (need_mask_canon arg2 == op2)
+ if (need_mask_canon arg2 == op2
+ can_vec_perm_p (TYPE_MODE (type), false, sel))
{
tree *tsel = XALLOCAVEC (tree, nelts);
tree eltype = TREE_TYPE (TREE_TYPE (arg2));
fixes the IA64 case.
[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620 Ilya Enkovich enkovich.gnu at gmail dot com changed: What|Removed |Added CC||enkovich.gnu at gmail dot com --- Comment #13 from Ilya Enkovich enkovich.gnu at gmail dot com --- Created attachment 33841 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33841action=edit Reproducer for Linux
[Bug rtl-optimization/63676] New: [5.0 regression] vshuf-v16hi.c ICE on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63676 Bug ID: 63676 Summary: [5.0 regression] vshuf-v16hi.c ICE on arm-none-eabi Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jiwang at gcc dot gnu.org Created attachment 33842 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33842action=edit vshuf-v16hi.` vshuf-v16hi.i failed on arm-none-eabi after r216728. testcase attached. cc1 built by (../gcc/configure --target=arm-none-eabi --enable-languages=c,c++) ./cc1 -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=neon vshuf-v16hi.i -Os Breakpoint 1, fancy_abort (file=0x1492484 ../../gcc/gcc/gcse.c, line=2153, function=0x1492df0 process_insert_insn) at ../../gcc/gcc/diagnostic.c:1232 1232 internal_error (in %s, at %s:%d, function, trim_filename (file), line); (gdb) bt #0 fancy_abort (file=0x1492484 ../../gcc/gcc/gcse.c, line=2153, function=0x1492df0 process_insert_insn) at ../../gcc/gcc/diagnostic.c:1232 #1 0x0096b680 in process_insert_insn (expr=0x1db2800) at ../../gcc/gcc/gcse.c:2153 #2 0x0096b6da in insert_insn_end_basic_block (expr=0x1db2800, bb=0x76e13dd0) at ../../gcc/gcc/gcse.c:2175 #3 0x0096e03f in hoist_code () at ../../gcc/gcc/gcse.c:3471 #4 0x0096ea94 in one_code_hoisting_pass () at ../../gcc/gcc/gcse.c:3701 #5 0x0096f999 in execute_rtl_hoist () at ../../gcc/gcc/gcse.c:4191 #6 0x0096fae9 in (anonymous namespace)::pass_rtl_hoist::execute (this=0x1cecca0) at ../../gcc/gcc/gcse.c:4272 #7 0x00b4f445 in execute_one_pass (pass=0x1cecca0) at ../../gcc/gcc/passes.c:2156 #8 0x00b4f684 in execute_pass_list_1 (pass=0x1cecca0) at ../../gcc/gcc/passes.c:2208 #9 0x00b4f6b5 in execute_pass_list_1 (pass=0x1cec8e0) at ../../gcc/gcc/passes.c:2209 #10 0x00b4f6f7 in execute_pass_list (fn=0x76bca1f8, pass=0x1ce97c0) at ../../gcc/gcc/passes.c:2219 #11 0x007d9aa8 in cgraph_node::expand (this=0x76bcd000) at ../../gcc/gcc/cgraphunit.c:1742 #12 0x007da0c7 in expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1878 #13 0x007dac0d in symbol_table::compile (this=0x76c74000) at ../../gcc/gcc/cgraphunit.c:2213 #14 0x007dadc4 in symbol_table::finalize_compilation_unit (this=0x76c74000) at ../../gcc/gcc/cgraphunit.c:2290 #15 0x0063572d in c_write_global_declarations () at ../../gcc/gcc/c/c-decl.c:10641 #16 0x00c489fc in compile_file () at ../../gcc/gcc/toplev.c:574 #17 0x00c4ad22 in do_compile () at ../../gcc/gcc/toplev.c:1981 #18 0x00c4af2c in toplev::main (this=0x7fffe55f, argc=6, argv=0x7fffe658) at ../../gcc/gcc/toplev.c:2078 #19 0x013a02b2 in main (argc=6, argv=0x7fffe658) at ../../gcc/gcc/main.c:38
[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 --- Comment #3 from Martin Liška marxin at gcc dot gnu.org --- Created attachment 33843 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843action=edit IPA ICF aliasing restriction Can you please try to apply following patch? It should disable alias creation for targets that do not support aliasing.
[Bug tree-optimization/63677] New: Failure to constant fold with vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63677
Bug ID: 63677
Summary: Failure to constant fold with vectorization.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
This piece of code:
int __attribute__ ((noinline))
foo ()
{
const int a[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
int i, sum;
sum = 0;
for (i = 0; i sizeof (a) / sizeof (*a); i++)
sum += a[i];
return sum;
}
when compiled with -O3 on x86_64 generates:
foo:
.LFB0:
.cfi_startproc
movdqa.LC1(%rip), %xmm0
paddd.LC0(%rip), %xmm0
movdqa%xmm0, %xmm1
psrldq$8, %xmm1
paddd%xmm1, %xmm0
movdqa%xmm0, %xmm1
psrldq$4, %xmm1
paddd%xmm1, %xmm0
movd%xmm0, %eax
ret
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.section.text.unlikely
.LCOLDE3:
.text
.LHOTE3:
.section.rodata.cst16,aM,@progbits,16
.align 16
.LC0:
.long0
.long1
.long2
.long3
.align 16
.LC1:
.long4
.long5
.long6
.long7
.identGCC: (GNU) 5.0.0 20141023 (experimental)
.section.note.GNU-stack,,@progbits
but when compiled with -O3 -mno-sse generates:
foo:
.LFB0:
.cfi_startproc
movl$28, %eax
ret
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.section.text.unlikely
.LCOLDE0:
Why isn't constant folding happening when generating code for vector unit?
$ gcc -v
Using built-in specs.
COLLECT_GCC=/work/dev/arm/bin_x86/install/bin/gcc
COLLECT_LTO_WRAPPER=/work/dev/arm/bin_x86/install/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../src/gcc/configure --prefix=/work/dev/arm/bin_x86/install
--enable-bootstrap --disable-nls --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
gcc version 5.0.0 20141023 (experimental) (GCC)
[Bug c/63678] New: __mm256_blend_epi16 only accepts 8-bit masks (should accept 16-bit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63678
Bug ID: 63678
Summary: __mm256_blend_epi16 only accepts 8-bit masks (should
accept 16-bit)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: peter.bumbulis at ianywhere dot com
Created attachment 33844
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33844action=edit
.i file for repro.
__mm256_blend_epi16 only accepts 8-bit masks as the 3rd parameter, not 16. The
Intel and Microsoft compilers handle this properly.
$ gcc -c -mavx2 -save-temps foo.c
foo.c: In function ‘blend’:
foo.c:4:46: error: the last argument must be an 8-bit immediate
return _mm256_blend_epi16(a, b, 0xabcd);
^
where foo.c is
#include immintrin.h
__m256i blend(__m256i a, __m256i b) {
return _mm256_blend_epi16(a, b, 0xabcd);
}
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-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 --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.8.2 (Ubuntu 4.8.2-19ubuntu1)
[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587 --- Comment #14 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Wed Oct 29 15:17:42 2014 New Revision: 216841 URL: https://gcc.gnu.org/viewcvs?rev=216841root=gccview=rev Log: PR ipa/63587 * g++.dg/ipa/pr63587-1.C: New test * g++.dg/ipa/pr63587-2.C: New test. * cgraphunit.c (cgraph_node::expand_thunk): Only VAR_DECLs are put to local declarations. * function.c (add_local_decl): Implementation moved from header file, assert introduced for tree type. * function.h: Likewise. Added: trunk/gcc/testsuite/g++.dg/ipa/pr63587-1.C trunk/gcc/testsuite/g++.dg/ipa/pr63587-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/function.c trunk/gcc/function.h trunk/gcc/testsuite/ChangeLog
[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #15 from Martin Liška marxin at gcc dot gnu.org --- Resolved.
[Bug target/63679] New: [4.9 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
Bug ID: 63679
Summary: [4.9 Regression][AArch64] Failure to constant fold.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
When this piece of code is compiled with -O3 -mgeneral-regs-only
int __attribute__ ((noinline))
foo ()
{
const int a[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
int i, sum;
sum = 0;
for (i = 0; i sizeof (a) / sizeof (*a); i++)
sum += a[i];
return sum;
}
4.9 gcc generates:
foo:
subsp, sp, #32
movw0, 28
addsp, sp, 32
ret
.sizefoo, .-foo
.identGCC: (unknown) 4.9.2 20140930 (prerelease)
5.0 generates:
foo:
adrpx0, .LANCHOR0
subsp, sp, #32
addx0, x0, :lo12:.LANCHOR0
ldrx7, [x0]
ldrx6, [x0, 16]
ldrx1, [x0, 8]
sbfxx5, x7, 32, 32
ldrx0, [x0, 24]
addw2, w6, w7
strx0, [sp, 24]
movx4, x1
strx1, [sp, 8]
sbfxx1, x6, 32, 32
ldrx3, [sp, 24]
addw1, w1, w5
addw1, w1, w2
strx7, [sp]
addw0, w3, w4
sbfxx4, x4, 32, 32
sbfxx3, x3, 32, 32
addw0, w0, w1
addw3, w4, w3
strx6, [sp, 16]
addw0, w3, w0
addsp, sp, 32
ret
.sizefoo, .-foo
.section.rodata
.align3
.LANCHOR0 = . + 0
.LC0:
.word0
.word1
.word2
.word3
.word4
.word5
.word6
.word7
.identGCC: (unknown) 5.0.0 20141023 (experimental)
Constant-folding seems to have got a bit messed up. I've observed this only on
aarch64-none-elf-gcc. 5.0 x86_64 seems to work fine.
foo:
.LFB0:
.cfi_startproc
movl$28, %eax
ret
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.identGCC: (GNU) 5.0.0 20141023 (experimental)
.section.note.GNU-stack,,@progbits
Looks like a aarch64-specific backend issue.
$ aarch64-none-elf-gcc -v
Target: aarch64-none-elf
Configured with: /work/dev/arm/src/gcc/configure --target=aarch64-none-elf
--prefix=/work/dev/arm/bin//install --with-gmp=/work/dev/arm/bin//host-tools
--with-mpfr=/work/dev/arm/bin//host-tools
--with-mpc=/work/dev/arm/bin//host-tools
--with-cloog=/work/dev/arm/bin//host-tools
--with-isl=/work/dev/arm/bin//host-tools --with-pkgversion=unknown
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c,c++ --with-newlib
Thread model: single
gcc version 5.0.0 20141023 (experimental) (unknown)
[Bug fortran/63640] move_alloc memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 patnel97269-gfortran at yahoo dot fr changed: What|Removed |Added Severity|major |critical
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2014-10-29 Resolution|DUPLICATE |--- Ever confirmed|0 |1 --- Comment #4 from Martin Liška marxin at gcc dot gnu.org --- PR still persists after installation of patch for PR63587.
[Bug tree-optimization/63677] Failure to constant fold with vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63677 --- Comment #1 from Tejas Belagod belagod at gcc dot gnu.org --- There is similar behaviour on aarch64. So, it doesn't look like a backend issue.
[Bug c++/63680] New: ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63680
Bug ID: 63680
Summary: ice
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marco.morandini at polimi dot it
Created attachment 33845
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33845action=edit
reduced testcase
g++ version:
marco@pao:~/Mbdyn/mbdyn.cvs g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/marco/local/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/marco/local/gcc-4.9.1
--enable-checking=release --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --enable-linux-futex --enable-lto
--with-arch=native --enable-threads=posix --with-ppl --with-cloog
--enable-languages=c,c++,fortran,lto
Thread model: posix
gcc version 4.9.1 (GCC)
--
ice message:
marco@pao:~/TTT/GccTestcaseReduction g++ -c RulesDirective.ii
RulesDirective.ii: In function ‘void processLabels()’:
RulesDirective.ii:7:6: internal compiler error: Segmentation fault
void processLabels() {
^
0x9aca5f crash_signal
../../gcc/toplev.c:337
0x8583ea get_class_context
../../gcc/ipa-devirt.c:997
0x8593fd contains_type_p
../../gcc/ipa-devirt.c:1012
0x8593fd get_polymorphic_call_info(tree_node*, tree_node*, tree_node**, long*,
ipa_polymorphic_call_context*)
../../gcc/ipa-devirt.c:1227
0x73669f cgraph_create_indirect_edge(cgraph_node*, gimple_statement_base*, int,
long, int)
../../gcc/cgraph.c:976
0x737cd3 build_cgraph_edges
../../gcc/cgraphbuild.c:343
0x737cd3 execute
../../gcc/cgraphbuild.c:409
[Bug libgcc/63681] New: bfin-rtems ICE in cfg_layout_initialize, at cfgrtl.c:4233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
Bug ID: 63681
Summary: bfin-rtems ICE in cfg_layout_initialize, at
cfgrtl.c:4233
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
git 4.9 branch with last commit 1d2b7cdfcb9376a6ee98964b11cf73fe14154e13
newlib head
Configure command (lots of newlib options)
../${GCC}/configure \
--prefix=${PREFIX} \
--bindir=${PREFIX}/bin \
--exec_prefix=${PREFIX} \
--includedir=${PREFIX}/include \
--libdir=${PREFIX}/lib \
--libexecdir=${PREFIX}/libexec \
--mandir=${PREFIX}/share/man \
--infodir=${PREFIX}/share/info \
--datadir=${PREFIX}/share \
--target=${TARGET} \
${sjlj} \
--disable-libstdcxx-pch \
--with-gnu-as --with-gnu-ld --verbose \
--with-newlib \
--with-system-zlib \
--disable-nls --without-included-gettext \
--disable-win32-registry \
--enable-version-specific-runtime-libs \
--disable-lto \
--enable-newlib-io-c99-formats \
--enable-newlib-iconv \
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,\
cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,\
iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,\
iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,\
iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,\
ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,\
utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,\
win_1253,win_1254,win_1255,win_1256,win_1257,win_1258 \
--enable-threads \
--disable-plugin \
--enable-languages=c,c++
The build fails in libgcc with this. Should be easy to reproduce:
/users/joel/test-gcc/b-bfin-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-bfin-rtems4.11-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-bfin-rtems4.11-gcc/bfin-rtems4.11/newlib/ -isystem
/users/joel/test-gcc/b-bfin-rtems4.11-gcc/bfin-rtems4.11/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/bfin-rtems4.11/bin/
-B/users/joel/test-gcc/install-head/bfin-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-head/bfin-rtems4.11/include -isystem
/users/joel/test-gcc/install-head/bfin-rtems4.11/sys-include-g -O2 -O2
-I../../../gcc/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -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
-Dinhibit_libc -I. -I. -I../.././gcc -I../../../gcc/libgcc
-I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _div_sf.o -MT
_div_sf.o -MD -MP -MF _div_sf.dep -DFINE_GRAINED_LIBRARIES -DL_div_sf -DFLOAT
-c ../../../gcc/libgcc/fp-bit.c -fvisibility=hidden -DHIDE_EXPORTS
../../../gcc/libgcc/fp-bit.c: In function '__divsf3':
../../../gcc/libgcc/fp-bit.c:1082:1: internal compiler error: in
cfg_layout_initialize, at cfgrtl.c:4233
}
^
0x4f030a cfg_layout_initialize(unsigned int)
../../gcc/gcc/cfgrtl.c:4233
0x9b9be1 reorder_loops
../../gcc/gcc/hw-doloop.c:500
0x9b9be1 reorg_loops(bool, hw_doloop_hooks*)
../../gcc/gcc/hw-doloop.c:641
0x938e85 bfin_reorg_loops
../../gcc/gcc/config/bfin/bfin.c:3888
0x938e85 bfin_reorg
../../gcc/gcc/config/bfin/bfin.c:4630
0x710bc9 rest_of_handle_machine_reorg
../../gcc/gcc/reorg.c:3936
0x710bc9 execute
../../gcc/gcc/reorg.c:3966
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[2]: *** [_div_sf.o] Error 1
make[2]: Leaving directory
`/users/joel/test-gcc/b-bfin-rtems4.11-gcc/bfin-rtems4.11/libgcc'
ma
[Bug tree-optimization/63677] Failure to constant fold with vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63677 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- I have seen this also.
[Bug libgcc/63682] New: m32c: libgcc configure checks for SJLJ model even when C++ and Java are disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63682 Bug ID: 63682 Summary: m32c: libgcc configure checks for SJLJ model even when C++ and Java are disabled Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: joel at gcc dot gnu.org On the m32c, C++ and Java are not supported. Thus we build with C only and the target doesn't have any need for SJLJ information. Unfortunately libgcc always probes for this. checking whether decimal floating point is supported... no configure: WARNING: decimal float is not supported for this target, ignored checking whether fixed-point is supported... no checking whether to use setjmp/longjmp exceptions... unknown configure: error: unable to detect exception model And if you pass in --disable-sjlj-exceptions, the build fails in libgcc with an ICE.
[Bug libgcc/63683] New: m32c-rtems ICE unable to find spill register compiling libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63683
Bug ID: 63683
Summary: m32c-rtems ICE unable to find spill register compiling
libgcc
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
gcc 4.9 branch in git at 1d2b7cdfcb9376a6ee98964b11cf73fe14154e13
newlib head
m32c fails with ICE
Configured as follows:
../${GCC}/configure \
--prefix=${PREFIX} \
--bindir=${PREFIX}/bin \
--exec_prefix=${PREFIX} \
--includedir=${PREFIX}/include \
--libdir=${PREFIX}/lib \
--libexecdir=${PREFIX}/libexec \
--mandir=${PREFIX}/share/man \
--infodir=${PREFIX}/share/info \
--datadir=${PREFIX}/share \
--target=${TARGET} \
--disable-sjlj-exceptions \
--disable-libstdcxx-pch \
--with-gnu-as --with-gnu-ld --verbose \
--with-newlib \
--with-system-zlib \
--disable-nls --without-included-gettext \
--disable-win32-registry \
--enable-version-specific-runtime-libs \
--disable-lto \
--enable-newlib-io-c99-formats \
--enable-newlib-iconv \
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,\
cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,\
iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,\
iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,\
iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,\
ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,\
utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,\
win_1253,win_1254,win_1255,win_1256,win_1257,win_1258 \
--enable-threads \
--disable-plugin \
--enable-languages=c
/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/newlib/ -isystem
/users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/m32c-rtems4.11/bin/
-B/users/joel/test-gcc/install-head/m32c-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-head/m32c-rtems4.11/include -isystem
/users/joel/test-gcc/install-head/m32c-rtems4.11/sys-include-g -O2
-mcpu=m32cm -O2 -I../../../../gcc/libgcc/../newlib/libc/sys/rtems/include -g
-O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -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 -Dinhibit_libc -I. -I. -I../../.././gcc
-I../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include
-DHAVE_CC_TLS -DUSE_EMUTLS -o _ffssi2.o -MT _ffssi2.o -MD -MP -MF _ffssi2.dep
-DL_ffssi2 -c ../../../../gcc/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
../../../../gcc/libgcc/libgcc2.c: In function '__ffssi2':
../../../../gcc/libgcc/libgcc2.c:522:1: error: unable to find a register to
spill in class 'A_REGS'
}
^
../../../../gcc/libgcc/libgcc2.c:522:1: error: this is the insn:
(insn 62 60 63 10 (set (reg:HI 0 r0 [49])
(zero_extend:HI (mem/u/j:QI (plus:PSI (subreg:PSI (reg:SI 45 [ D.2964
]) 0)
(symbol_ref:PSI (__clz_tab) [flags 0x40] var_decl
0x7f5d80ddcc78 __clz_tab)) [0 __clz_tab S1 A8])))
../../../../gcc/libgcc/libgcc2.c:520 115 {zero_extendqihi2}
(expr_list:REG_DEAD (reg:SI 45 [ D.2964 ])
(nil)))
../../../../gcc/libgcc/libgcc2.c:522: confused by earlier errors, bailing out
make[4]: *** [_ffssi2.o] Error 1
[Bug c/63678] __mm256_blend_epi16 only accepts 8-bit masks (should accept 16-bit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63678 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||kyukhin at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- What means properly? The underlying instruction (256-bit VPBLENDW) certainly accepts only 8-bit mask, and e.g. https://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-5369B2B5-B1E1-4D96-85AB-2019982667B4.htm says nothing what would the upper bits mean, it also says that the mask is 8-bit immediate. Perhaps icc just doesn't diagnose incorrect masks? Or do you see that for 16-bit masks _mm256_blend_epi16 would actually emit more than one insn (say separate blends with the low 8-bit mask, high 8-bit mask and then blend together)?
[Bug libgcc/63682] m32c: libgcc configure checks for SJLJ model even when C++ and Java are disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63682 --- Comment #1 from DJ Delorie dj at redhat dot com --- m32c-elf supports C++. What is the contents of the failing config.log? Also, there's nothing m32c-specific in the sjlj checks, it's the same for all sjlj targets.
[Bug libgcc/63684] New: Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 Bug ID: 63684 Summary: Build failure due to Let GDB reuse GCC's parser. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: sasha.levin at oracle dot com CC: pmuldoon at redhat dot com Hi, I'm seeing the following build error: n file included from ../.././libcc1/findcomp.cc:20:0: ../.././libcc1/../gcc/config.h:6:23: fatal error: auto-host.h: No such file or directory compilation terminated. In file included from ../.././libcc1/plugin.cc:27:0: ../.././libcc1/../gcc/config.h:6:23: fatal error: auto-host.h: No such file or directory compilation terminated. I've bisected it down to: commit ab103e33b2aae243b231eba689e0b99418fa1663 Author: pmuldoon pmuldoon@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Mon Oct 27 17:21:42 2014 + Let GDB reuse GCC's parser.
[Bug tree-optimization/63677] Failure to constant fold with vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63677
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-10-29
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
The problem is that the loop is first vectorized, then several passes later slp
vectorizes the initialization, so after some cleanups we have e.g. in cddce2:
MEM[(int *)a] = { 0, 1, 2, 3 };
MEM[(int *)a + 16B] = { 4, 5, 6, 7 };
vect__13.6_20 = MEM[(int *)a];
vect__13.6_17 = MEM[(int *)a + 16B];
But there is no further FRE pass that would optimize the loads into
vect__13.6_20 = { 0, 1, 2, 3 };
vect__13.6_17 = { 4, 5, 6, 7 };
(supposedly that would need to be done before forwprop4 that could in theory
refold all the stmts into constant).
Richard, how expensive would be to schedule another FRE pass if anything has
been vectorized in the current function (either vect pass, or slp)? Or are
there other passes that handle this? Looking at e.g.
typedef int V __attribute__((vector_size (4 * sizeof (int;
struct S { int a[4]; };
V __attribute__ ((noinline)) foo (struct S *p)
{
*(V *) p = (V) { 1, 2, 3, 4 };
return *(V *) p;
}
with -O2 -fno-tree-fre, it seems DOM is able to do that, but unfortunately at
dom2 time the values have not been sufficiently forward propagated for dom2 to
optimize this.
[Bug target/63678] __mm256_blend_epi16 only accepts 8-bit masks (should accept 16-bit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63678 --- Comment #2 from Peter Bumbulis peter.bumbulis at ianywhere dot com --- The referenced web page is incorrect. Look in the instruction set reference manual (https://software.intel.com/sites/default/files/managed/c6/a9/319433-020.pdf, search for VPBLENDMW) or the intrinsics guide (https://software.intel.com/sites/landingpage/IntrinsicsGuide/). These instructions blend 16 bit quantities: you can fit 16 of these in a 256 bit register. For AVX512 it's a 32-bit constant.
[Bug libgcc/63684] Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- What target? How options did you configure GCC with?
[Bug libstdc++/62318] optimization of string searches using Nigel Horspool's Boyer-Moore-Horpool algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62318 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #4) See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3905.html which proposes adding it to the C++ standard library as a separate API. The new components are part of the Library Fundamentals TS: http://cplusplus.github.io/fundamentals-ts/main.html#func That part of the TS has not yet been implemented in libstdc++. This is now implemented on trunk.
[Bug target/63678] __mm256_blend_epi16 only accepts 8-bit masks (should accept 16-bit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63678 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Peter Bumbulis from comment #2) The referenced web page is incorrect. Look in the instruction set reference manual (https://software.intel.com/sites/default/files/managed/c6/a9/319433-020.pdf, search for VPBLENDMW) or the intrinsics guide (https://software.intel.com/sites/landingpage/IntrinsicsGuide/). These instructions blend 16 bit quantities: you can fit 16 of these in a 256 bit register. For AVX512 it's a 32-bit constant. Your first reference is AVX512 documentation, _mm256_blend_epi16 is not _mm256_mask_blend_epi16. _mm256_blend_epi16 is for VPBLENDW instruction, and the https://software.intel.com/sites/landingpage/IntrinsicsGuide/ looks incorrect, because it doesn't describe what the VPBLENDW instruction does. In particular, it only has 8-bit immediate, and both 128-bit lanes are blended the same given that mask: IF (imm8[0] == 1) THEN DEST[15:0] - SRC2[15:0] ELSE DEST[15:0] - SRC1[15:0] IF (imm8[1] == 1) THEN DEST[31:16] - SRC2[31:16] ELSE DEST[31:16] - SRC1[31:16] IF (imm8[2] == 1) THEN DEST[47:32] - SRC2[47:32] ELSE DEST[47:32] - SRC1[47:32] IF (imm8[3] == 1) THEN DEST[63:48] - SRC2[63:48] ELSE DEST[63:48] - SRC1[63:48] IF (imm8[4] == 1) THEN DEST[79:64] - SRC2[79:64] ELSE DEST[79:64] - SRC1[79:64] IF (imm8[5] == 1) THEN DEST[95:80] - SRC2[95:80] ELSE DEST[95:80] - SRC1[95:80] IF (imm8[6] == 1) THEN DEST[111:96] - SRC2[111:96] ELSE DEST[111:96] - SRC1[111:96] IF (imm8[7] == 1) THEN DEST[127:112] - SRC2[127:112] ELSE DEST[127:112] - SRC1[127:112] IF (imm8[0] == 1) THEN DEST[143:128] - SRC2[143:128] ELSE DEST[143:128] - SRC1[143:128] IF (imm8[1] == 1) THEN DEST[159:144] - SRC2[159:144] ELSE DEST[159:144] - SRC1[159:144] IF (imm8[2] == 1) THEN DEST[175:160] - SRC2[175:160] ELSE DEST[175:160] - SRC1[175:160] IF (imm8[3] == 1) THEN DEST[191:176] - SRC2[191:176] ELSE DEST[191:176] - SRC1[191:176] IF (imm8[4] == 1) THEN DEST[207:192] - SRC2[207:192] ELSE DEST[207:192] - SRC1[207:192] IF (imm8[5] == 1) THEN DEST[223:208] - SRC2[223:208] ELSE DEST[223:208] - SRC1[223:208] IF (imm8[6] == 1) THEN DEST[239:224] - SRC2[239:224] ELSE DEST[239:224] - SRC1[239:224] IF (imm8[7] == 1) THEN DEST[255:240] - SRC2[255:240] ELSE DEST[255:240] - SRC1[255:240]
[Bug libgcc/63684] Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 --- Comment #2 from Sasha Levin sasha.levin at oracle dot com --- Building on x86, config options are: ./configure --prefix=/home/sasha/gcc-inst/ --with-arch=native --with-tune=native --enable-languages=c --enable-lto --enable-gold --disable-libstdcxx e --with-tune=native --enable-languages=c --enable-lto --enable-gold --disable-libstdcx
[Bug target/63678] __mm256_blend_epi16 only accepts 8-bit masks (should accept 16-bit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63678 --- Comment #4 from Peter Bumbulis peter.bumbulis at ianywhere dot com --- (In reply to Peter Bumbulis from comment #2) The referenced web page is incorrect. Look in the instruction set reference manual (https://software.intel.com/sites/default/files/managed/c6/a9/319433-020.pdf, search for VPBLENDMW) or the intrinsics guide (https://software.intel.com/sites/landingpage/IntrinsicsGuide/). These instructions blend 16 bit quantities: you can fit 16 of these in a 256 bit register. For AVX512 it's a 32-bit constant. My mistake: it looks like the generated code only uses the low 8 bytes. Sorry for any wasted bandwidth.
[Bug target/63678] __mm256_blend_epi16 only accepts 8-bit masks (should accept 16-bit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63678 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Trying icc 14.0.2.144 Build 2014012, I see that a) it indeed fails to report the bug in your source b) when using -c, it silently discards the upper 8 bits of the immediate, so you end up with: 0:c4 e3 7d 0e c1 cdvpblendw $0xcd,%ymm1,%ymm0,%ymm0 c) when using -S, it generates invalid assembly: vpblendw $43981, %ymm1, %ymm0, %ymm0 #4.16 which doesn't assemble at least with gas. So, I believe erroring out on this is significantly better than what icc does with it.
[Bug target/63678] __mm256_blend_epi16 only accepts 8-bit masks (should accept 16-bit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63678 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- .
[Bug preprocessor/63662] __has_include is not implemented but it is defined, so #ifdef __has_include guards are ineffective in blocking usage of __has_include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662 --- Comment #6 from andre.mccurdy at linaro dot org --- The issue seems to be specific to Linaro 4.9-2014.10. There's now a Linaro 4.9-2014.10-1 release which merges the missing updates to libcpp.
[Bug libgcc/63684] Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 --- Comment #3 from Phil Muldoon pmuldoon at redhat dot com --- I am trying to replicate locally. Do you recall at which stage (1, 2 .. etc) during the build process this occurred at?
[Bug libgcc/63684] Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 --- Comment #4 from Sasha Levin sasha.levin at oracle dot com --- Created attachment 33846 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33846action=edit Build log
[Bug libgcc/63684] Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 --- Comment #5 from Sasha Levin sasha.levin at oracle dot com --- It happened very early. I've attached the full build log for reference.
[Bug libgcc/63682] m32c: libgcc configure checks for SJLJ model even when C++ and Java are disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63682 --- Comment #2 from Joel Sherrill joel at gcc dot gnu.org --- Created attachment 33847 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33847action=edit config.log
[Bug libgcc/63682] m32c: libgcc configure checks for SJLJ model even when C++ and Java are disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63682 --- Comment #3 from Joel Sherrill joel at gcc dot gnu.org --- (In reply to DJ Delorie from comment #1) m32c-elf supports C++. What is the contents of the failing config.log? Hmm... then this should work. We intentionally don't deviate much from *-elf targets. I was only building C in this run. Also, there's nothing m32c-specific in the sjlj checks, it's the same for all sjlj targets. I know. But m32c and (I think) h8300 were the only failures.
[Bug libgcc/63684] Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 --- Comment #6 from Phil Muldoon pmuldoon at redhat dot com --- I am already past that point in my build. auto-host.h is an automatically generated file, so I am quite puzzled why in your case it has not found it. In my case, it is in obj/gcc/auto-host.h. I built with your parameters. Was this a new build from a new checkout? If you updated from an existing src base, did you run make distclean over the old build? Or just start with a new obj/ location?
[Bug libgcc/63684] Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 --- Comment #7 from Sasha Levin sasha.levin at oracle dot com --- The built was from a clean checkout. auto-host.h seems to be correctly created during the build. I see this after the build failure: $ stat host-x86_64-unknown-linux-gnu/gcc/auto-host.h File: `host-x86_64-unknown-linux-gnu/gcc/auto-host.h' Size: 47262 Blocks: 96 IO Block: 4096 regular file Device: fe00h/65024dInode: 15209562Links: 1 Access: (0644/-rw-r--r--) Uid: (10017/ sasha) Gid: (10017/ sasha) Access: 2014-10-29 15:59:10.713463956 -0400 Modify: 2014-10-29 15:59:09.677398847 -0400 Change: 2014-10-29 15:59:09.685399348 -0400 Birth: -
[Bug libgcc/63684] Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 --- Comment #8 from Phil Muldoon pmuldoon at redhat dot com --- I am still waiting for my build to complete the full-stages. Meanwhile does --disable-libcc1 allow you to continue with your work?
[Bug tree-optimization/63666] [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666 --- Comment #12 from Marc Glisse glisse at gcc dot gnu.org --- (I am traveling this week, so I can only post a short comment) (In reply to Richard Biener from comment #11) - if (need_mask_canon arg2 == op2) + if (need_mask_canon arg2 == op2 + can_vec_perm_p (TYPE_MODE (type), false, sel)) seems reasonable, though if we didn't have can_vec_perm_p before the transformation (which implies we are before vector lowering) we should probably still transform. Also, I believe that targets should try to support single argument permutations when they support a 2 argument version that degenerates to it when both arguments are the same. By the way, from a quick look, I don't see where we protect against TREE_SIDE_EFFECTS(op0) when doing op0=op1 or op1=op0 in this code, I don't remember if there is a reason why it isn't needed.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #51 from Dominique d'Humieres dominiq at lps dot ens.fr --- In addition r216154 breaks a lot of asan tests with -m32: see https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02834.html Could you please try following patch? diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c ... The failures are gone with the patch. Thanks.
[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 33843 [details] IPA ICF aliasing restriction Can you please try to apply following patch? It should disable alias creation for targets that do not support aliasing. With the patch bootstrap proceeds up to stage 2 where it fails with /opt/gcc/build_w/./prev-gcc/xg++ -B/opt/gcc/build_w/./prev-gcc/ -B/opt/gcc/gcc4.10w/x86_64-apple-darwin14.0.0/bin/ -nostdinc++ -B/opt/gcc/build_w/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -B/opt/gcc/build_w/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs -I/opt/gcc/build_w/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/include/x86_64-apple-darwin14.0.0 -I/opt/gcc/build_w/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/include -I/opt/gcc/work/libstdc++-v3/libsupc++ -L/opt/gcc/build_w/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -L/opt/gcc/build_w/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -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 -fno-common -DHAVE_CONFIG_H -I. -I. -I../../work/gcc -I../../work/gcc/. -I../../work/gcc/../include -I./../intl -I../../work/gcc/../libcpp/include -I/opt/mp/include -I../../work/gcc/../libdecnumber -I../../work/gcc/../libdecnumber/dpd -I../libdecnumber -I../../work/gcc/../libbacktrace -DCLOOG_INT_GMP -DCLOOG_INT_GMP -I/opt/mp/include -o tree-inline.o -MT tree-inline.o -MMD -MP -MF ./.deps/tree-inline.TPo ../../work/gcc/tree-inline.c ../../work/gcc/tree-inline.c: In function 'int estimate_num_insns_seq(gimple_seq, eni_weights*)': ../../work/gcc/tree-inline.c:5667:1: error: invalid argument to gimple call } ^ stmts # .MEM_3 = VDEF .MEM_1(D) retval.1640_4 = count_insns_seq (stmts, weights_2(D)); [tail call] ../../work/gcc/tree-inline.c:5667:1: internal compiler error: verify_gimple failed ../../work/gcc/tree-inline.c:5667:1: internal compiler error: Abort trap: 6 xg++: internal compiler error: Abort trap: 6 (program cc1plus) make[3]: *** [tree-inline.o] Abort trap: 6 make[3]: Leaving directory `/opt/gcc/build_w/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/opt/gcc/build_w' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/opt/gcc/build_w' make: *** [all] Error 2
[Bug libgcc/63684] Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 --- Comment #9 from Phil Muldoon pmuldoon at redhat dot com --- My build is not complete with the parameters specified in the PR: ../trunk/configure --prefix=/home/pmuldoon/gdb_compile_gcc/ --with-arch=native --with-tune=native --enable-languages=c --enable-lto --enable-gold --disable-libstdcxx --with-tune=native --enable-languages=c --enable-lto --enable-gold --disable-libstdcx make -j9 And it built successfully. Which is puzzling! I notice your configure was ./configure. Was it it an in-source build (IE not building to a separate object file directory?)
[Bug libgcc/63684] Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 --- Comment #10 from Phil Muldoon pmuldoon at redhat dot com --- Sorry I mean my build is now complete
[Bug libgcc/63684] Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 --- Comment #11 from Sasha Levin sasha.levin at oracle dot com --- That's correct. I'm just building in-tree and using 'git clean -df' to reset everything back to a pristine checkout state when I need to.
[Bug ada/62236] built-in: error: aggregate value used where an integer was expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62236 --- Comment #1 from Victor Porton porton at narod dot ru --- Confirmed in GNAT GPL 2014.
[Bug ada/62235] segmentation fault on Ada 2012 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62235 --- Comment #2 from Victor Porton porton at narod dot ru --- Confirmed in GNAT GPL 2014.
[Bug ada/62205] GNAT does not accept class types for Default_Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62205 --- Comment #1 from Victor Porton porton at narod dot ru --- It does not work with GNAT GPL 2014. $ gnat compile -gnatc -gnat12 test.ads gcc -c -gnatc -gnat12 test.ads test.ads:19:28: Default Iterator must be a primitive of Descriptions_List gnatmake: test.ads compilation error
[Bug ada/62042] Missing optimization of copying non-limited objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62042 --- Comment #1 from Victor Porton porton at narod dot ru --- Confirmed in GNAT GPL 2014.
[Bug ada/62236] built-in: error: aggregate value used where an integer was expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62236 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-29 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Severity|major |normal --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- GNAT GPL has nothing to do with this Bugzilla though.
[Bug libgcc/63684] Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- ./configure isn't supported in GCC, don't do that.
[Bug libgcc/63684] Build failure due to Let GDB reuse GCC's parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63684 --- Comment #13 from Sasha Levin sasha.levin at oracle dot com --- From Installing GCC: Configuration (https://gcc.gnu.org/install/configure.html): building where srcdir == objdir should still work, but doesn't get extensive testing
[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 howarth at bromo dot med.uc.edu changed: What|Removed |Added CC||howarth at bromo dot med.uc.edu --- Comment #5 from howarth at bromo dot med.uc.edu --- (In reply to Martin Liška from comment #3) Created attachment 33843 [details] IPA ICF aliasing restriction Can you please try to apply following patch? It should disable alias creation for targets that do not support aliasing. Is there a problem with this patch due to the definition of... #define ASM_WEAKEN_DECL(FILE, DECL, NAME, ALIAS)\ in gcc/config/darwin.h?
[Bug fortran/63685] New: kern.osversion bug shows up with GFORTRAN as well as GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63685 Bug ID: 63685 Summary: kern.osversion bug shows up with GFORTRAN as well as GCC Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cloverm at leidos dot com I used the fortran compiler, 4.9.0, with the new Mac OS (Yosemite, 10.10), and got the same error message others got from the gcc compiler: gfortran: warning: couldn’t understand kern.osversion ‘14.0.0 There doesn't seem to be a way to work around this, so my laptop is currently useless for compiling my code.
[Bug target/63685] kern.osversion bug shows up with GFORTRAN as well as GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63685 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|fortran |target Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Yosemite support is not there yet or at least in a released version. See bug 61407. *** This bug has been marked as a duplicate of bug 61407 ***
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||cloverm at leidos dot com --- Comment #44 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 63685 has been marked as a duplicate of this bug. ***
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #52 from Jeffrey A. Law law at redhat dot com --- Igor, can you post the patch from c#50 for official review? Thanks!
[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |vmakarov at redhat dot
com
--- Comment #14 from Jeffrey A. Law law at redhat dot com ---
Ilya, thanks for the Linux (well, non-Darwin) testcase. I think it shows very
clearly that this is an IRA/LRA problem.
If we look at the .ira dump we have:
(insn/f 43 7 2 2 (parallel [
(set (reg:SI 88)
(unspec:SI [
(const_int 0 [0])
] UNSPEC_SET_GOT))
(clobber (reg:CC 17 flags))
]) 679 {set_got}
(expr_list:REG_UNUSED (reg:SI 88)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUIV (unspec:SI [
(const_int 0 [0])
] UNSPEC_SET_GOT)
(expr_list:REG_CFA_FLUSH_QUEUE (nil)
(nil))
We assign r88 to %eax. Note the REG_UNUSED note. The validity of the
REG_UNUSED note is debatable since there aren't any uses of r88 in the RTL, but
we do have those hidden uses when we have reloads.
Later in the .ira dump we have:
(call_insn 13 12 14 2 (parallel [
(call (mem:QI (reg/v/f:SI 4 si [orig:87 f ] [87]) [0 *(__float128
(*T311) (__float128)) f_4(D) S1 A8])
(const_int 32 [0x20]))
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])))
]) j.c:11 657 {*call_pop}
(expr_list:REG_CALL_DECL (nil)
(expr_list:REG_ARGS_SIZE (const_int 28 [0x1c])
(nil)))
(nil))
[ ... ]
(insn 21 18 22 3 (set (mem:TF (pre_dec:SI (reg/f:SI 7 sp)) [1 S16 A128])
(const_double:TF 1.0e+29 [0x0.a18f07d736b90be55p+97])) j.c:13 121
{*pushtf}
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil)))
So IRA assigns r88 to %eax. Which makes sense given the raw RTL. As far as
IRA can tell, r88 is just set in the SET_GOT insn and it never gets used.
LRA turns that into:
(insn/f 43 7 2 2 (parallel [
(set (reg:SI 0 ax [88])
(unspec:SI [
(const_int 0 [0])
] UNSPEC_SET_GOT))
(clobber (reg:CC 17 flags))
]) 679 {set_got}
(expr_list:REG_EQUIV (unspec:SI [
(const_int 0 [0])
] UNSPEC_SET_GOT)
(expr_list:REG_CFA_FLUSH_QUEUE (nil)
(nil
[ ... ]
(call_insn 13 12 14 2 (parallel [
(call (mem:QI (reg/v/f:SI 4 si [orig:87 f ] [87]) [0 *(__float128
(*T311) (__float128)) f_4(D) S1 A8])
(const_int 32 [0x20]))
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])))
]) j.c:11 657 {*call_pop}
(expr_list:REG_CALL_DECL (nil)
(expr_list:REG_ARGS_SIZE (const_int 28 [0x1c])
(nil)))
(nil))
[ ... ]
(insn 46 18 47 3 (set (reg:SI 0 ax [93])
(plus:SI (reg:SI 0 ax [88])
(const:SI (unspec:SI [
(symbol_ref/u:SI (*.LC0) [flags 0x2])
] UNSPEC_GOTOFF j.c:13 213 {*leasi}
(expr_list:REG_EQUAL (symbol_ref/u:SI (*.LC0) [flags 0x2])
(nil)))
(insn 47 46 21 3 (set (reg:TF 23 xmm2 [94])
(mem/u/c:TF (reg:SI 0 ax [93]) [1 S16 A128])) j.c:13 126
{*movtf_internal}
(nil))
Which is obviously bogus because %eax is clobbered at insn 13 and thus won't
have a useful value at insn 46.
Officially assigning to Vlad...
