[Bug libstdc++/65118] Android target build is broken with "guard.cc:36:22: fatal error: syscall.h: No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65118 --- Comment #3 from Alexander Ivchenko --- I'm afraid I don't have an ability to reproduce it anymore. As nobody complained over the years, I think it makes sense to close it
[Bug target/85595] New: __atomic_is_lock_free(sizeof(unsigned long long), &v) returns true on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85595
Bug ID: 85595
Summary: __atomic_is_lock_free(sizeof(unsigned long long), &v)
returns true on i686
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: aivchenk at gmail dot com
Target Milestone: ---
in gcc __atomic_is_lock_free(sizeof(unsigned long long), &v) returns true (in
clang it is left as a call)
int main()
{
unsigned long long v;
if (__atomic_is_lock_free(sizeof(unsigned long long), &v))
return 0;
else
return 1;
}
> g++ -O2 -m32 -std=gnu++11 -fno-exceptions -fno-rtti
main:
.LFB0:
xorl%eax, %eax
ret
> clang++ -O2 -m32 -std=gnu++11 -fno-exceptions -fno-rtti
main: # @main
.Lfunc_begin0:
# %bb.0:
subl$12, %esp
.Ltmp0:
subl$8, %esp
leal8(%esp), %eax
pushl %eax
pushl $8
calll __atomic_is_lock_free
addl$16, %esp
xorl%ecx, %ecx
testl %eax, %eax
sete%cl
.Ltmp1:
movl%ecx, %eax
addl$12, %esp
retl
__atomic_is_lock_free always should return false for misaligned pointers (long
long is only 4-byte aligned on i686)
More details can be found at the bug filed against llvm
https://bugs.llvm.org/show_bug.cgi?id=36860
[Bug target/79634] ICE in expand_builtin_with_bounds, at builtins.c:7490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79634 --- Comment #5 from Alexander Ivchenko --- (In reply to Ilya Enkovich from comment #4) > We hit function pointer propagation issues before and chkp_redirect_edge > with corresponding code in redirect_call_stmt_to_callee appeared to handle > them. Why doesn't it work in this case? cgraph_edge::redirect_call_stmt_to_callee is not called at all here. I'll try to figure out why tomorrow
[Bug target/79634] ICE in expand_builtin_with_bounds, at builtins.c:7490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79634
--- Comment #3 from Alexander Ivchenko ---
The problem here is that when CHKP is instrumenting call statement "i();" it
doesn't know that it's a builtin call. When optimizations come into play,
namely ccp pass, it becomes known that the call is to memmove and it is
actually is replaced as memmove. But we instrumented the call statement, so we
expand it like that:
if (CALL_WITH_BOUNDS_P (exp))
return expand_builtin_with_bounds (exp, target, subtarget,
tmode, ignore);
and then this assert fails:
gcc_assert (fcode > BEGIN_CHKP_BUILTINS
&& fcode < END_CHKP_BUILTINS);
Here is untested fix to check whether we substitute builtin and, if the builtin
is of the instrumentable type, make the call to instrumented builtin:
diff --git a/gcc/tree-ssa-propagate.c b/gcc/tree-ssa-propagate.c
index 0693802..9e9c4a3 100644
--- a/gcc/tree-ssa-propagate.c
+++ b/gcc/tree-ssa-propagate.c
@@ -38,6 +38,8 @@
#include "cfgloop.h"
#include "tree-cfgcleanup.h"
#include "cfganal.h"
+#include "cgraph.h"
+#include "ipa-chkp.h"
/* This file implements a generic value propagation engine based on
the same propagation used by the SSA-CCP algorithm [1].
@@ -1072,6 +1074,13 @@ substitute_and_fold_dom_walker::before_dom_children
(basic_block bb)
fold_stmt (&i, follow_single_use_edges);
stmt = gsi_stmt (i);
gimple_set_modified (stmt, true);
+ if (flag_check_pointer_bounds &&
+ gimple_code (stmt) == GIMPLE_CALL)
+ {
+ tree fndecl = gimple_call_fndecl (stmt);
+ fndecl = chkp_maybe_clone_builtin_fndecl (fndecl);
+ gimple_call_set_fndecl (stmt, fndecl);
+ }
}
/* Some statements may be simplified using propagator
[Bug ipa/79787] ICE in remove_unreachable_nodes, at ipa.c:469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79787
Alexander Ivchenko changed:
What|Removed |Added
CC||aivchenk at gmail dot com
--- Comment #2 from Alexander Ivchenko ---
Reduced testcase:
inline __attribute__((__always_inline__)) __attribute__ ((target("bmi"))) int
fn1() {}
__attribute__((__always_inline__)) __attribute__ ((target("bmi"))) int fn2() {
fn1(); }
int fn3() { return fn1(); }
Initial call graph:
fn3 -(not inlinable because of attribute mismatch)-> fn1
fn2 -> fn1
Call graph before chkp_ecleanup
fn3 -> fn3.chkp -(not inlinable because of attribute mismatch)-> fn1.chkp
fn2.chkp -> fn1.chkp
fn2 (fn1 is inlined here)
When compiler inlines fn1 to fn2 in expand_call_inline, it removes fn1 cnode,
as it is no longer needed.
There it execute this code (in cgraph_node::remove):
if (instrumented_version)
{
instrumented_version->instrumented_version = NULL;
instrumented_version = NULL;
}
Hence, now fn1.chkp.instrumened_version==NULL and fn1 is removed.
And later on in chkp_cleanup in reachability analysis in
symbol_table::remove_unreachable_nodes
we fail on this assert, where cnode==fn1.chkp
/* For instrumentation clones we always need original
function node for proper LTO privatization. */
if (cnode->instrumentation_clone
&& cnode->definition)
{
=>gcc_assert (cnode->instrumented_version || in_lto_p);
(since fn1 is removed, we don't consider it in chkp_produce_thunks
(early=false))
[Bug fortran/79929] [7/8 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929 Alexander Ivchenko changed: What|Removed |Added CC||aivchenk at gmail dot com --- Comment #20 from Alexander Ivchenko --- Not sure whether it is connected, but when I bootstrap with: >../gcc_ref/configure --with-system-zlib --with-demangler-in-ld >--with-arch=corei7 --with-cpu=corei7 --with-fpmath=sse >--enable-shared --enable-host-shared --enable-clocale=gnu >--enable-cloog-backend=isl --enable-languages=c --enable-libmpx=yes >--with-build-config=bootstrap-lto >make In function ‘rtvec_alloc’, inlined from ‘copy_rtx_for_iterators’ at ../../gcc_ref/gcc/read-rtl.c:448:32: ../../gcc_ref/gcc/rtl.c:155:10: error: ‘memset’: specified size 18446744073709551608 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] memset (&rt->elem[0], 0, n * sizeof (rtx));
[Bug ipa/79765] [CHKP] ICE in create_target_clone in multiple_target.c:211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79765
Alexander Ivchenko changed:
What|Removed |Added
CC||aivchenk at gmail dot com
--- Comment #1 from Alexander Ivchenko ---
Multi-versioning pass tries to make versions out of mpx chunks, which have no
bodies and hence it fails. I think there is no reason to keep target_clones
attribute for chunks. The following patch helps:
diff --git a/gcc/ipa-chkp.c b/gcc/ipa-chkp.c
index c7fc3a0..5de11b3 100644
--- a/gcc/ipa-chkp.c
+++ b/gcc/ipa-chkp.c
@@ -718,6 +718,9 @@ chkp_produce_thunks (bool early)
0, CGRAPH_FREQ_BASE);
node->create_reference (node->instrumented_version,
IPA_REF_CHKP, NULL);
+ DECL_ATTRIBUTES (node->decl)
+ = remove_attribute ("target_clones",
+ DECL_ATTRIBUTES (node->decl));
/* Thunk shouldn't be a cdtor. */
DECL_STATIC_CONSTRUCTOR (node->decl) = 0;
DECL_STATIC_DESTRUCTOR (node->decl) = 0;
.. And at "O0" it works. However it fails later on at O1 and above.
gcc/gcc/testsuite/gcc.target/i386/mvc1.c:18:1: error: virtual definition of
statement not up-to-date
main ()
^~~~
_3 = foo.chkp.ifunc ();
gcc/gcc/testsuite/gcc.target/i386/mvc1.c:18:1: internal compiler error:
verify_ssa failed
r0x113ccab verify_ssa(bool, bool)
../../gcc/gcc/tree-ssa.c:1184
0xd65f4b execute_function_todo
../../gcc/gcc/passes.c:1973
0xd64fab do_per_function
../../gcc/gcc/passes.c:1650
0xd660d6 execute_todo
../../gcc/gcc/passes.c:2016
[Bug middle-end/80270] ICE in extract_bit_field_1 at gcc/expmed.c:1798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80270
--- Comment #2 from Alexander Ivchenko ---
Another test that fails similarly, but already at "-O0":
typedef int v8 __attribute__ ((vector_size (8)));
struct S2
{
v8 s2f2;
int* f3;
};
int foo (int i)
{
register struct S2 b asm ("xmm0");
int k = 5;
b.f3 = &k;
b.f3 = b.f3 + i;
return *b.f3;
}
[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79788 Alexander Ivchenko changed: What|Removed |Added CC||aivchenk at gmail dot com --- Comment #4 from Alexander Ivchenko --- This is not a CHKP issue as we ICE without it as well: >gcc-7 /export/users/aivchenk/gnu_ws/gcc/gcc/testsuite/gcc.dg/pr38934.c -m32 >-ftrapv /export/users/aivchenk/gnu_ws/gcc/gcc/testsuite/gcc.dg/pr38934.c:14:35: internal compiler error: in expand_expr_real_2, at expr.c:9569 if (p >= -9223372036854775808LL - (signed char) g) ~~~^ 0xa5e6a3 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../gcc/gcc/expr.c:9569 0x8fa8c6 expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3677 0x8fab10 expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:3737 0x901bf4 expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:5744 0x903656 execute gcc-4.8.3 works though. So it's a regression
[Bug tree-optimization/80270] New: ICE in extract_bit_field_1 at gcc/expmed.c:1798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80270
Bug ID: 80270
Summary: ICE in extract_bit_field_1 at gcc/expmed.c:1798
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aivchenk at gmail dot com
Target Milestone: ---
> cat struct_hard_reg.c
#include
typedef int v8 __attribute__((vector_size(8)));
struct S1 {
v8 s1f;
};
struct S2 {
struct S1 s2f1;
v8 s2f2;
};
void fn1() {
int __trans_tmp_2, i = 3;
register struct S2 b asm("xmm0");
__trans_tmp_2 = b.s2f1.s1f[i];
printf("%d", __trans_tmp_2);
}
> gcc ./struct_hard_reg.c -O1
./new_bug.c: In function ‘fn1’:
./new_bug.c:17:3: internal compiler error: Segmentation fault
printf("%d", __trans_tmp_2);
^~~
0xe92cda crash_signal
../../gcc/gcc/toplev.c:337
0xa3284a extract_bit_field_1
../../gcc/gcc/expmed.c:1798
0xa32e01 extract_bit_field(rtx_def*, unsigned long, unsigned long, int,
rtx_def*, machine_mode, machine_mode, bool)
../../gcc/gcc/expmed.c:1932
0xa63501 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10702
0xa5821f expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/gcc/expr.c:8072
0xa5f27e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:9775
0xa5821f expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/gcc/expr.c:8072
0x8d448f expand_normal
../../gcc/gcc/expr.h:282
0x8d647d precompute_register_parameters
../../gcc/gcc/calls.c:956
[Bug rtl-optimization/80173] New: ICE in store_bit_field_1, at expmed.c:787
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80173
Bug ID: 80173
Summary: ICE in store_bit_field_1, at expmed.c:787
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aivchenk at gmail dot com
Target Milestone: ---
> cat ../struct_asm.c
/* { dg-do compile } */
typedef int v8 __attribute__ ((vector_size(8)));
struct U {
v8 a;
v8 b;
};
int
foo (int i)
{
register struct U u asm ("xmm0") = {{-1, 0}, {-1, 0}};
return u.b[i];
}
> gcc ../struct_asm.c
>
../struct_asm.c: In function ‘foo’:
../struct_asm.c:13:21: internal compiler error: in store_bit_field_1, at
expmed.c:787
register struct U u asm ("xmm0") = {{-1, 0}, {-1, 0}};
[Bug middle-end/79990] [CHKP] ICE in expand_expr_addr_expr_1, at expr.c:7790
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79990 --- Comment #2 from Alexander Ivchenko --- I proposed a fix for this: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01222.html
[Bug middle-end/79990] [CHKP] ICE in expand_expr_addr_expr_1, at expr.c:7790
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79990 --- Comment #1 from Alexander Ivchenko --- The problem here is that chkp creates bounds for register variable: vsdump.c.025t.chkp: Building bounds for address of decl u Made bounds: __bound_tmp.0_4 = __builtin_ia32_bndmk (&u, 16); And when we expanding &u we face expand_expr_addr_expr_1: /* If the DECL isn't in memory, then the DECL wasn't properly marked TREE_ADDRESSABLE, which will be either a front-end or a tree optimizer bug. */ gcc_assert (MEM_P (result)); where "result" is: (reg/v:V4SI 21 xmm0 [ u ]) We need to disable the instrumentation of register variables and the subscriptions of those variables. I couldn't find the correct place for that disabling so far though.
[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78631 Alexander Ivchenko changed: What|Removed |Added CC||aivchenk at gmail dot com --- Comment #12 from Alexander Ivchenko --- Fixed with r243942
[Bug target/65705] ICE: SIGSEGV in contains_struct_check with -fsanitize=null -fcheck-pointer-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65705 Alexander Ivchenko changed: What|Removed |Added CC||aivchenk at gmail dot com --- Comment #3 from Alexander Ivchenko --- The same problem as: whttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=69804
[Bug middle-end/68270] [MPX] Common pattern for variable sized data clashes with MPX bound checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68270 Alexander Ivchenko changed: What|Removed |Added CC||aivchenk at gmail dot com --- Comment #3 from Alexander Ivchenko --- Addressed in r243936 | aivchenk | 2016-12-27 16:31:43 +0300 (Tue, 27 Dec 2016) | 18 lines 2016-12-27 Alexander Ivchenko * c-family/c.opt (flag_chkp_flexible_struct_trailing_arrays): Add new option. (fchkp-narrow-to-innermost-array): Fix typo. * doc/cpp.texi (flag_chkp_flexible_struct_trailing_arrays): Ditto. * tree-chkp.c (chkp_may_narrow_to_field ): Forbid narrowing when flag_chkp_flexible_struct_trailing_arrays is used and the field is the last array field in the structure. 2016-12-27 Alexander Ivchenko * gcc.target/i386/mpx/vla-trailing-1-lbv.c: New test. * gcc.target/i386/mpx/vla-trailing-1-nov.c: Ditto. * gcc.target/i386/mpx/vla-trailing-1-ubv.c: Ditto. The new option -fchkp-flexible-struct-trailing-arrays will allow to treat all trailing arrays in structures as possibly flexible. The bug can be closed
[Bug other/67520] libmpx should abort() instead of exit(255) on bound violation detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67520 Alexander Ivchenko changed: What|Removed |Added CC||aivchenk at gmail dot com --- Comment #2 from Alexander Ivchenko --- (In reply to Richard Biener from comment #1) > IMHO libraries should have a way to specify a custom handler (and default > that to abort maybe). Indeed exit (255) isn't very canonical. Addressed in: r243928 | aivchenk | 2016-12-26 18:14:06 +0300 (Mon, 26 Dec 2016) | 14 lines 2016-12-26 Alexander Ivchenko * mpxrt/libtool-version: New version. * mpxrt/mpxrt-utils.c (set_mpx_rt_stop_handler): New function. (print_help): Add help for CHKP_RT_STOP_HANDLER environment variable. (__mpxrt_init_env_vars): Add initialization of stop_handler. (__mpxrt_stop_handler): New function. (__mpxrt_stop): Ditto. * mpxrt/mpxrt-utils.h (mpx_rt_stop_mode_handler_t): New enum. * mpxrt/mpxrt.c (handler): Replace exit(255) with __mpxrt_stop function call. Now libmpx will call abort on bounds violations by default (User can restore previous behavior with CHKP_RT_STOP_HANDLER env variable)
[Bug middle-end/63994] Ada bootstrap fails with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63994 Alexander Ivchenko changed: What|Removed |Added CC||aivchenk at gmail dot com --- Comment #8 from Alexander Ivchenko --- I couldn't reproduce the issue as of Dec 26 trunk. I suppose it can be closed
[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77267 Alexander Ivchenko changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Alexander Ivchenko --- Fixed with r240057
[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65530 Bug 65530 depends on bug 77267, which changed state. Bug 77267 Summary: MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77267 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/77383] -fcheck-pointer-bounds -mmpx ICE with VLA struct return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77383 --- Comment #2 from Alexander Ivchenko --- I debugged it and I suspect that the problem is in tree_function_versioning (which is used for making instrumented clones of all functions in MPX). Deep inside the logic of tree_function_versioning we do a copy of that statement: *D.1824 = retframe_block (); [return slot optimization] : (gdb) pgg orig_stmt *D.1824 = retframe_block (); [return slot optimization] (gdb) pct TYPE_SIZE(TREE_TYPE(gimple_call_lhs(orig_stmt))) D.1820 (gdb) pct TYPE_SIZE(TREE_TYPE(gimple_call_fntype(orig_stmt))) D.1820 And here is the copy of that gimple statement after remap_gimple_stmt (gdb) pgg stmt MEM[(struct block *)D.1842] = retframe_block (); [return slot optimization] (gdb) pct TYPE_SIZE(TREE_TYPE(gimple_call_lhs(stmt))) D.1837 (gdb) pct TYPE_SIZE(TREE_TYPE(gimple_call_fntype(stmt))) D.1820 where D.1820 is a local identifier from original "main" function (gdb) pct get_containing_scope(TYPE_SIZE(TREE_TYPE(gimple_call_fntype(stmt main (gdb) pct get_containing_scope(TYPE_SIZE(TREE_TYPE(gimple_call_lhs(stmt main.chkp After later on MPX deletes bodies of original functions, expand crashes when trying to make an rtl for D.1820 var_decl
[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77267 --- Comment #10 from Alexander Ivchenko --- Matthias, could you apply the fix for that bug (https://gcc.gnu.org/viewcvs?rev=240057&root=gcc&view=rev) to the Ubuntu version of gcc?
[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77267 --- Comment #9 from Alexander Ivchenko --- Looks like exactly the same discussion happened when '-z bndplt' option was discussed. Here is the reference: https://patchwork.ozlabs.org/patch/456557/ . It's a long one, but seems that the consensus was formulated by Jeff Law: "I guess the one thing I don't like here is that whether or not to pass -z bndplt is made at the time we configure GCC. Yet, it's trivial for someone to change the system linker later, either to gold or from an old BFD linker that doesn't support -z bndplt to one that does support -z bndplt. [ Note we have the same issue with certain assembler feature tests. ] I'm not aware of any real infrastructure in GCC to query the behavior of the linker at link time and then customize the options passed. So if it's going to be configurable, then that's the only time to do the test." ... "So, in an ideal world, we'd query the linker at link time and pass the flag anytime we have a linker that supports the capability and perhaps warn if the linker doesn't support that capability. Given we're not in that ideal world, I think Ilya's patch is reasonable and should be installed."
[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77267 --- Comment #8 from Alexander Ivchenko --- Thanks, Matthias, that's a valid point about changing linker on a runtime. In my defense, I see that right now MPX does not work with '-fuse-ld=bfd' anyways: >gcc test.c -fcheck-pointer-bounds -mmpx -fuse-ld=gold /usr/bin/ld.gold: bndplt: unknown -z option /usr/bin/ld.gold: use the --help option for usage information That's not a surprise, because the check for '--push-state' is done exactly like the check for '-z bndplt'. Would it be possible to probe the 'other' linker (the one that is not the default one) during a configure time? If so we may end up with something like HAVE_BFD_PUSHPOPSTATE_SUPPORT/HAVE_GOLD_PUSHPOPSTATE_SUPPORT
[Bug target/77267] New: MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77267 Bug ID: 77267 Summary: MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default) Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: aivchenk at gmail dot com Target Milestone: --- When compiling with -Wl,-as-needed libmpx.so and libmpxwrappers.so are not linked: >gcc -fcheck-pointer-bounds -mmpx any_mpx_test.c -Wl,-as-needed > ldd a.out linux-vdso.so.1 (0x7ffc687a) libc.so.6 => /lib64/libc.so.6 (0x0035c8c0) /lib64/ld-linux-x86-64.so.2 (0x55e88586f000) And hence, MPX does not work. (In a working scenario it should be like that: > ldd a.out linux-vdso.so.1 (0x7fff53fe7000) libmpx.so.0 => /lib64/libmpx.so.0 (0x7f135ac34000) libmpxwrappers.so.0 => /lib64/libmpxwrappers.so.0 (0x7f135aa31000) libc.so.6 => /lib64/libc.so.6 (0x0035c8c0) libpthread.so.0 => /lib64/libpthread.so.0 (0x0035c940) /lib64/ld-linux-x86-64.so.2 (0x55861968) ) This case is important because on Debian/Ubuntu -no-as-needed option is always implicitly added while linking.
[Bug libstdc++/65118] New: Android target build is broken with "guard.cc:36:22: fatal error: syscall.h: No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65118 Bug ID: 65118 Summary: Android target build is broken with "guard.cc:36:22: fatal error: syscall.h: No such file or directory" Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: aivchenk at gmail dot com configured with: /users/aivchenk/toolchain_3/gcc/gcc-5.0/libstdc++-v3/configure - --enable-multilib --with-cross-host=x86_64-linux-gnu --disable-bootstrap --with-sysroot=/users/aivchenk/ndk/android-ndk-r10d/platforms/android-21/arch-x86_64/ --disable-shared --disable-libitm --disable-libsanitazer --enable-languages=c,c++,lto --program-transform-name=s&^&x86_64-linux-android-& --disable-option-checking --with-target-subdir=x86_64-linux-android --build=x86_64-linux-gnu --host=x86_64-linux-android --target=x86_64-linux-android /users/aivchenk/toolchain_3//gcc/gcc-4.10/libstdc++-v3/libsupc++/guard.cc:36:22: fatal error: syscall.h: No such file or directory Should we guard that with __ANDROID__?
[Bug tree-optimization/64277] [4.9/5.0 Regression] Incorrect warning "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277 --- Comment #3 from Alexander Ivchenko --- You need to specify "-mssse3" (not "-msse3"). Warning about array bounds is not correct, because gcc does not know how this function is being called.
[Bug tree-optimization/64277] New: [4.9/5.0 Regression] Incorrect warning "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
Bug ID: 64277
Summary: [4.9/5.0 Regression] Incorrect warning "array
subscript is above array bounds"
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aivchenk at gmail dot com
>cat test.c
void foo(short a[], short m)
{
int i, j;
int f1[10];
short nc;
nc = m + 1;
if (nc > 3)
{
for (i = 0; i <= nc; i++)
{
f1[i] = f1[i] + 1;
}
}
for (i = 0, j = m; i < nc; i++, j--)
{
a[i] = f1[i];
a[j] = i;
}
return;
}
>gcc -O3 -mssse3 -Wall
/export/users/aivchenk/src/gcc_obj/test.c:21:16: warning: array subscript is
above array bounds [-Warray-bounds]
a[i] = f1[i];
^
If compile with "-msse3" there is no warning.
[Bug tree-optimization/63915] New: gomp/pr60823-2.c:31:1: error: dead STMT in EH table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63915 Bug ID: 63915 Summary: gomp/pr60823-2.c:31:1: error: dead STMT in EH table Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: aivchenk at gmail dot com >g++ gcc/testsuite/c-c++-common/gomp/pr60823-2.c -O1 -fopenmp-simd -fPIC -m32 gcc/testsuite/c-c++-common/gomp/pr60823-2.c: In function ‘int main()’: gcc/testsuite/c-c++-common/gomp/pr60823-2.c:31:1: error: dead STMT in EH table main () ^ # .MEM_15 = VDEF <.MEM_42> _16 = foo (_14, _13); gcc/testsuite/c-c++-common/gomp/pr60823-2.c:31:1: internal compiler error: verify_gimple failed 0xcf687d verify_gimple_in_cfg(function*, bool) /export/users/aivchenk/src/gcc_mainline/gcc/tree-cfg.c:5027 0xbfd25f execute_function_todo /export/users/aivchenk/src/gcc_mainline/gcc/passes.c:1868 0xbfdbc3 execute_todo /export/users/aivchenk/src/gcc_mainline/gcc/passes.c:1925 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug tree-optimization/62053] [5 Regression] ICE: in remap_type_1, at tree-inline.c:540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62053 --- Comment #7 from Alexander Ivchenko --- The patch fixed the issue for me, thanks!
[Bug tree-optimization/62053] [5 Regression] ICE: in remap_type_1, at tree-inline.c:540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62053 --- Comment #5 from Alexander Ivchenko --- Ping.. any updates? We cannot build Android since the beginning of Jul, and, hence, cannot evaluate 5.0 candidate for it. I find it very unfortunate
[Bug tree-optimization/62053] [5 Regression] ICE: in remap_type_1, at tree-inline.c:540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62053 --- Comment #3 from Alexander Ivchenko --- Jan, by any chance, do you have any progress on that? May be we should revert the patch until the proper fix?
[Bug tree-optimization/62053] [4.10 Regression] ICE: in remap_type_1, at tree-inline.c:540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62053 Alexander Ivchenko changed: What|Removed |Added CC||aivchenk at gmail dot com --- Comment #2 from Alexander Ivchenko --- Stuck on the same error when building Android.
[Bug bootstrap/60644] [4.9/4.10 Regression] Build of i686-pc-linux-android is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 --- Comment #9 from Alexander Ivchenko --- Confirm fixing
[Bug bootstrap/60644] [4.9 Regression] Build of i686-pc-linux-android is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 --- Comment #7 from Alexander Ivchenko --- The fix in gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01428.html
[Bug bootstrap/60644] [4.9 Regression] Build of i686-pc-linux-android is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 --- Comment #4 from Alexander Ivchenko --- That (In reply to Andrew Pinski from comment #2) > Well pthread_yield should be replaced with the POSIX version: sched_yield() > instead. Right.. the attached patch cured the build
[Bug bootstrap/60644] [4.9 Regression] Build of i686-pc-linux-android is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 --- Comment #3 from Alexander Ivchenko --- Created attachment 32443 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32443&action=edit Renaming ANDROID to __ANDROID__
[Bug bootstrap/60644] New: [4.9 Regression] Build of i686-pc-linux-android is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 Bug ID: 60644 Summary: [4.9 Regression] Build of i686-pc-linux-android is broken Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: aivchenk at gmail dot com > ../gcc_mainline/configure --target=i686-linux-android --disable-bootstrap > --enable-languages=c,c++ > --with-sysroot=[..]ndk/android-ndk-r9d/platforms/android-19/arch-x86 > --disable-shared --disable-libitm --disable-libsanitizer > make [..] ../../../gcc_mainline/libcilkrts/runtime/os-unix.c: In function ‘linux_gettid’: ../../../gcc_mainline/libcilkrts/runtime/os-unix.c:293:20: error: ‘SYS_gettid’ undeclared (first use in this function) return syscall(SYS_gettid); ^ ../../../gcc_mainline/libcilkrts/runtime/os-unix.c:293:20: note: each undeclared identifier is reported only once for each function it appears in ../../../gcc_mainline/libcilkrts/runtime/os-unix.c: In function ‘__cilkrts_yield’: ../../../gcc_mainline/libcilkrts/runtime/os-unix.c:419:5: warning: implicit declaration of function ‘pthread_yield’ [-Wimplicit-function-declaration] pthread_yield(); ^ make[2]: *** [os-unix.lo] Error 1 make[2]: *** Waiting for unfinished jobs mv -f .deps/spin_mutex.Tpo .deps/spin_mutex.Plo mv -f .deps/worker_mutex.Tpo .deps/worker_mutex.Plo mv -f .deps/stats.Tpo .deps/stats.Plo mv -f .deps/signal_node.Tpo .deps/signal_node.Plo mv -f .deps/symbol_test.Tpo .deps/symbol_test.Plo mv -f .deps/sysdep-unix.Tpo .deps/sysdep-unix.Plo make[2]: Leaving directory `/export/users/aivchenk/src/android_gcc_obj/i686-linux-android/libcilkrts' make[1]: *** [all-target-libcilkrts] Error 2 make[1]: Leaving directory `/export/users/aivchenk/src/android_gcc_obj' make: *** [all] Error 2
[Bug bootstrap/60634] [4.9] Build x86_64-unknown-linux-gnu with --disable-libstdc__-v3 is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60634 --- Comment #2 from Alexander Ivchenko --- (In reply to Jakub Jelinek from comment #1) > What is it useful for to configure gcc that way? The stdc++ library is built and shipped separately from the compiler. > And, both libsanitizer and libcilkrts really require libstdc++, so IMNSHO if > you disable that, you should disable those too. Do we have any mechanism to check that on configure time?
[Bug bootstrap/60634] New: [4.9] Build x86_64-unknown-linux-gnu with --disable-libstdc__-v3 is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60634 Bug ID: 60634 Summary: [4.9] Build x86_64-unknown-linux-gnu with --disable-libstdc__-v3 is broken Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: aivchenk at gmail dot com Build of x86_64-unknown-linux-gnu with --disable-libstdc__-v3 is broken now: $ ../gcc_mainline/configure --disable-bootstrap --disable-libstdc__-v3 libtool: link: cannot find the library `../../libstdc++-v3/src/libstdc++.la' or unhandled argument `../../libstdc++-v3/src/libstdc++.la' make[4]: *** [liblsan.la] Error 1 make[4]: Leaving directory `/users/aivchenk/gcc_build/x86_64-unknown-linux-gnu/libsanitizer/lsan' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/users/aivchenk/gcc_build/x86_64-unknown-linux-gnu/libsanitizer' make[2]: *** [all] Error 2 make[2]: Leaving directory `/users/aivchenk/gcc_build/x86_64-unknown-linux-gnu/libsanitizer' make[1]: *** [all-target-libsanitizer] Error 2 make[1]: Leaving directory `/users/aivchenk/gcc_build' make: *** [all] Error 2 And then if we switch off sanitizer (--disable-libsanitizer): xg++: error: unrecognized command line option ‘-funconfigured-libstdc++-v3’ make[2]: *** [bug.lo] Error 1 make[2]: Leaving directory `/users/aivchenk/gcc_build/x86_64-unknown-linux-gnu/libcilkrts' make[1]: *** [all-target-libcilkrts] Error 2 make[1]: Leaving directory `/users/aivchenk/gcc_build make: *** [all] Error 2 I'm not sure that we allow that type of build officially, but that's how it is done when e.g. building android ndk. Actually libmudflap also couldn't be built with that, but it was turned off for android so I didn't notice.
[Bug tree-optimization/59789] [4.9 Regression] ICE in in convert_move, at expr.c:333
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59789 --- Comment #7 from Alexander Ivchenko --- (In reply to H.J. Lu from comment #3) > (In reply to Alexander Ivchenko from comment #2) > > lets just say that my code is valid and I forgot to add "-msse2" :). > > > > Does GCC ICE with -msse2? No, you were right when you said that the code is incorrect. Seems that I accidentally found this bug when compiling the initial code without "-msse2".
[Bug target/59789] [4.9 Regression] ICE in in convert_move, at expr.c:333
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59789 --- Comment #2 from Alexander Ivchenko --- lets just say that my code is valid and I forgot to add "-msse2" :). (In reply to H.J. Lu from comment #1) > The code is invalid since -march=i686 doesn't support SSE. > The older GCC issues: > > In file included from /tmp/pr59789.c:2:0: > /usr/lib/gcc/x86_64-redhat-linux/4.8.2/include/emmintrin.h:31:3: error: > #error "SSE2 instruction set not enabled" > # error "SSE2 instruction set not enabled" >^ > /tmp/pr59789.c: In function ‘f1’: > /tmp/pr59789.c:9:5: error: unknown type name ‘__m128i’ > __m128i bar = _mm_set1_epi32(0);
[Bug target/59789] New: [4.9 Regression] ICE in in convert_move, at expr.c:333
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59789
Bug ID: 59789
Summary: [4.9 Regression] ICE in in convert_move, at expr.c:333
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: aivchenk at gmail dot com
Android build is currently broken due to this bug:
>gcc expr_ice.c -c -O2 -fPIC -m32 -march=i686
expr_ice.c:9:13: internal compiler error: in convert_move, at expr.c:333
__m128i bar = _mm_set1_epi32(0);
^
0x73a66e convert_move(rtx_def*, rtx_def*, int)
/export/users/aivchenk/src/gcc/gcc/expr.c:333
0x73dae5 store_expr(tree_node*, rtx_def*, int, bool)
/export/users/aivchenk/src/gcc/gcc/expr.c:5389
0x73fbb9 expand_assignment(tree_node*, tree_node*, bool)
/export/users/aivchenk/src/gcc/gcc/expr.c:5114
0x65f28d expand_gimple_stmt_1
/export/users/aivchenk/src/gcc/gcc/cfgexpand.c:3213
0x65f28d expand_gimple_stmt
/export/users/aivchenk/src/gcc/gcc/cfgexpand.c:3309
0x660f17 expand_gimple_basic_block
/export/users/aivchenk/src/gcc/gcc/cfgexpand.c:5149
0x6637c9 gimple_expand_cfg
/export/users/aivchenk/src/gcc/gcc/cfgexpand.c:5715
0x6637c9 execute
/export/users/aivchenk/src/gcc/gcc/cfgexpand.c:5935
Please submit a full bug report,
>cat expr_ice.c
#include
#include
typedef void (*func_type)();
extern func_type f;
static void f1()
{
__m128i bar = _mm_set1_epi32(0);
_mm_storel_epi64(&bar, bar);
}
void foo(void)
{
f = f1;
}
[Bug c++/58525] __cxa_throw_bad_array_new_length is generated with -fno-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58525 --- Comment #6 from Alexander Ivchenko --- (In reply to Volker Reichelt from comment #5) > Alexander, Jason, can this bug be closed as fixed? Yes, it is fixed now in trunk.
[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226 --- Comment #12 from Alexander Ivchenko --- (In reply to Markus Trippelsdorf from comment #11) > (In reply to Alexander Ivchenko from comment #10) > > Patch from comment #7 didn't cure Android build as well.. > > Can you try the patch from PR58252 comment 7? > I've build Chromium (browser) successfully with it. Yep, the patch from PR58252 comment 7 has cured my build of Android
[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226 --- Comment #10 from Alexander Ivchenko --- Patch from comment #7 didn't cure Android build as well..
[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226 Alexander Ivchenko changed: What|Removed |Added CC||aivchenk at gmail dot com --- Comment #4 from Alexander Ivchenko --- This broke Android image build with trunk compiler (in addition to pr58585)..
[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086 --- Comment #7 from Alexander Ivchenko --- Do we have any documentation that states how many registers can be used in inline assembler for a particular arch and optset? "almost all" is not good enough for that. If the user code that worked in 4.8 correctly is now broken for 4.9, we better need to respect the user and document it properly.
[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086 --- Comment #5 from Alexander Ivchenko --- I understand the technical reasons of the complexity of the correct and efficient register allocation here, but what I don't understand is this: $> gcc_4.7 test.c -c -fPIC -mstackrealign -march=core-avx2 -m32 $> gcc_4.8 test.c -c -fPIC -mstackrealign -march=core-avx2 -m32 $> gcc_4.9 test.c -c -fPIC -mstackrealign -march=core-avx2 -m32 test.c: In function 'testFunc': test.c:7:3: error: 'asm' operand has impossible constraints __asm__( ^ How can we allow to break the user code with the release version of the compiler here..?
[Bug regression/59086] New: error: ‘asm’ operand has impossible constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086
Bug ID: 59086
Summary: error: ‘asm’ operand has impossible constraints
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: aivchenk at gmail dot com
Android image build with trunk gcc failed after the following commit:
Author: hubicka
Date: Thu Oct 3 17:25:42 2013 +
* i386.c (ix86_option_override_internal): Do not enable
accumulate-outgoing-args when producing unwind info.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@203171
138bc75d-0d04-0410-961f-82ee72b054a4
==
The reduced testcase looks something like this
(previous r203169 is able to compile it):
#include
void testFunc(int count) {
int x;
__m128i tmp1;
__asm__(
"1:\n"
:"+d"(x)
:[count] "m" (count), [tmp1] "m" (tmp1)
:"ecx","esi","edi","eax"
);
}
The compiling options:
gcc test.c -c -fPIC -mstackrealign -march=core-avx2 -m32
[Bug c++/58525] __cxa_throw_bad_array_new_length is generated with -fno-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58525 --- Comment #3 from Alexander Ivchenko --- thanks. I have sent it to gcc-paches: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00402.html
[Bug c++/58525] __cxa_throw_bad_array_new_length is generated with -fno-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58525 --- Comment #1 from Alexander Ivchenko --- Created attachment 30891 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30891&action=edit Proposed untested fix Proposed untested fix is attached
[Bug c++/58525] New: __cxa_throw_bad_array_new_length is generated with -fno-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58525
Bug ID: 58525
Summary: __cxa_throw_bad_array_new_length is generated with
-fno-exceptions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aivchenk at gmail dot com
When I compile the following code (modified version of
g++.dg/cpp0x/bad_array_new1.C without try/catch):
// { dg-options -std=c++11 }
// { dg-do run }
#include
void * f(int i)
{
return new int[i];
}
int main()
{
f(-1);
}
with -fno-exceptions option, I still get the call to
__cxa_throw_bad_array_new_length:
> nm ./bad_array_new1.o | grep cxa
U __cxa_throw_bad_array_new_length
The same goes for __cxa_throw_bad_array_length
[Bug bootstrap/58242] [4.9 regression] linux-android.c:40:7: error: 'OPTION_BIONIC' was not declared in this scope breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58242 --- Comment #3 from Alexander Ivchenko --- Should be fixed now by r202274
[Bug c++/58201] New: [g++] Undefined reference to `B::B(void const**)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201
Bug ID: 58201
Summary: [g++] Undefined reference to `B::B(void const**)'
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aivchenk at gmail dot com
Testcase:
ABC.h-
class A
{
protected:
A();
virtual ~A();
};
class B : virtual public A
{
public:
B();
virtual ~B();
};
class C
{
private:
class C2 : public B
{
public:
C2();
virtual ~C2();
};
};
AB.cpp-
#include "ABC.h"
A::A() { }
A::~A() { }
B::B() { }
B::~B() { }
C.cpp--
#include "ABC.h"
C::C2::C2(){ }
C::C2::~C2() { }
int main ()
{
return 0;
}
---
Compiling the usual way:
g++ AB.cpp -c
g++ C.cpp -c
g++ AB.o C.o
C.o: In function `C::C2::C2()':
C.cpp:(.text+0x23): undefined reference to `B::B(void const**)'
C.o: In function `C::C2::C2()':
C.cpp:(.text+0x8d): undefined reference to `B::B(void const**)'
C.o: In function `C::C2::~C2()':
C.cpp:(.text+0x129): undefined reference to `B::~B(void const**)'
C.o: In function `C::C2::~C2()':
C.cpp:(.text+0x1c3): undefined reference to `B::~B(void const**)'
collect2: error: ld returned 1 exit status
We cannot right now build the Android Open Source Tree with the trunk because
of that bug. It was introduced with this commit:
Author: hubicka
Date: Thu Jul 25 17:10:21 2013 +
* cgraph.c (release_function_body): Break out from ...
(cgraph_release_function_body): ... this one; also release DECL_RESULT
and DECL_ARGUMENTS.
* ipa-cp.c (get_replacement_map): Add parm_num argument; do not set
old_tree in the map.
(create_specialized_node): Update.
* lto-cgraph.c (output_node_opt_summary): Do not translate old_tree
into index.
* cgraphclones.c (cgraph_create_virtual_clone): Do not copy
DECL_ARGUMENTS,
DECL_INITIAL and DECL_RESULT.
* ipa-prop.c (ipa_populate_param_decls): Look for origin of clones.
* tree-inline.c (initialize_cfun): Initialize DECL_ARGUMENTS and
DECL_RESULT.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@201251
138bc75d-0d04-0410-961f-82ee72b054a4
[Bug regression/58165] [4.8/4.9 regression] internal compiler error: verify_flow_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58165 --- Comment #7 from Alexander Ivchenko --- > Well, that wouldn't be sufficient, you'd need to also remove the EH edges > from the other bb. But not splitting the block means you don't have to > bother with that. Well, that's true. We could do that and not give up on cdce, but I guess there is no much profit in that.. Your fix works for me and the initial issue with bullet lib is also cured (and reduced testcase shows the problem as well). Thanks =)
[Bug regression/58165] [4.8/4.9 regression] internal compiler error: verify_flow_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58165 --- Comment #4 from Alexander Ivchenko --- I firstly did something like that: diff --git a/gcc/tree-call-cdce.c b/gcc/tree-call-cdce.c index 9b6186e..5862ebf 100644 --- a/gcc/tree-call-cdce.c +++ b/gcc/tree-call-cdce.c @@ -771,6 +771,9 @@ shrink_wrap_one_built_in_call (gimple bi_call) join_tgt_in_edge_fall_thru = make_edge (guard_bb0, join_tgt_bb, EDGE_FALSE_VALUE); + if (!gimple_call_nothrow_p (bi_call)) +make_eh_edges (bi_call); + bi_call_in_edge0->probability = REG_BR_PROB_BASE * ERR_PROB; bi_call_in_edge0->count = apply_probability (guard_bb0->count, which also helped.. but now I see that we shouldn't split the block
[Bug regression/58165] New: [4.8/4.9 regression] internal compiler error: verify_flow_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58165
Bug ID: 58165
Summary: [4.8/4.9 regression] internal compiler error:
verify_flow_info
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: aivchenk at gmail dot com
extern "C" {
float sqrtf(float);
}
class V
{
public:
double length2 () const {}
double length () const
{
return sqrtf(length2());
}
V& normalize()
{
length();
return *this;
}
};
class B1
{
public:
virtual ~B1 ();
};
class B2: public B1
{
public:
B2(const V& p0,const V& p1,const V& p2) : B1() {}
};
class A1
{
public:
virtual ~A1 ();
};
struct A2: public A1
{
V m_v;
virtual void foo (V v)
{
V v1 (v);
B2 tA (m_v, m_v, m_v);
V v2 = v1.normalize();
}
};
void bar ()
{
A2 a;
}
Compile: g++ -c -O3 test.C
test.C: In member function ‘virtual void A2::foo(V)’:
test.C:43:16: error: BB 6 is missing an EH edge
virtual void foo (V v)
^
test.C:43:16: internal compiler error: verify_flow_info failed
0x8b31ce verify_flow_info()
src/gcc/gcc/cfghooks.c:260
0xbceee7 execute_function_todo
src/gcc/gcc/passes.c:1633
0xbce1b3 do_per_function
src/gcc/gcc/passes.c:1358
0xbcefd7 execute_todo
src/gcc/gcc/passes.c:1660
_
The case came from android ndk r9: it's 4.8 is unable to compile bullet lib.
After some investigation I found that it's the same as in usual 4.8-release
with just android sysroot (The reason is that 'sqrtf' is defined in Bionic
without throw, if you add throw() to it, as it is in glibc, the ICE will
disappear again).
The guilty revision is:
Author: eraman
Date: Fri Jun 15 17:35:11 2012 +
2012-06-15 Easwaran Raman
* passes.c (init_optimization_passes): Remove pass_call_cdce
from its current position and insert after pass_dce.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@188675
138bc75d-0d04-0410-961f-82ee72b054a4
[Bug tree-optimization/57385] [tree-ssa] Possible segfault in fully_constant_vn_reference_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57385 --- Comment #6 from Alexander Ivchenko --- On Fri, May 24, 2013 at 1:15 PM, Kirill Yukhin wrote: >> >> Ok for trunk and 4.8 after 4.8.1 is out. >> > > Checked in to trunk: > http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00803.html (+ > http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00804.html for missed test). > And 4.8 branch: http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00805.html > > Thanks, K I think we can close it now.
[Bug tree-optimization/57385] [tree-ssa] Possible segfault in fully_constant_vn_reference_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57385 --- Comment #5 from Alexander Ivchenko --- btw it indeed gives a segfault for 4.7 on linux_64 if we change the index from "-1" to some "-1". g++ .../src/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr57385.c -O1 -S -o pr57385.s ...src/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr57385.c: In function ‘void foo(int)’: ...src/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr57385.c:10:1: internal compiler error: Segmentation fault g++ --version g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
[Bug tree-optimization/57385] [tree-ssa] Possible segfault in fully_constant_vn_reference_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57385 --- Comment #4 from Alexander Ivchenko --- Bootstrapped and tested on x86_64 linux, sent to gcc-patches. http://patchwork.ozlabs.org/patch/246036/
[Bug tree-optimization/57385] [tree-ssa] Possible segfault in fully_constant_vn_reference_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57385 --- Comment #3 from Alexander Ivchenko --- Testing is in progress, will send to gcc-patches rigth after that.
[Bug tree-optimization/57385] [tree-ssa] Possible segfault in fully_constant_vn_reference_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57385 --- Comment #1 from Alexander Ivchenko --- Following fix could solve the problem: diff --git a/gcc-4.6/gcc/tree-ssa-sccvn.c b/gcc-4.6/gcc/tree-ssa-sccvn.c index eb88969..704a86c 100644 --- a/gcc-4.6/gcc/tree-ssa-sccvn.c +++ b/gcc-4.6/gcc/tree-ssa-sccvn.c @@ -1115,6 +1115,7 @@ fully_constant_vn_reference_p (vn_reference_t ref) == TYPE_MODE (TREE_TYPE (TREE_TYPE (arg0->op0 && GET_MODE_CLASS (TYPE_MODE (op->type)) == MODE_INT && GET_MODE_SIZE (TYPE_MODE (op->type)) == 1 + && tree_int_cst_sgn (op->op0) >= 0 && compare_tree_int (op->op0, TREE_STRING_LENGTH (arg0->op0)) < 0) return build_int_cst_type (op->type, (TREE_STRING_POINTER (arg0->op0)
[Bug tree-optimization/57385] New: [tree-ssa] Possible segfault in fully_constant_vn_reference_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57385
Bug ID: 57385
Summary: [tree-ssa] Possible segfault in
fully_constant_vn_reference_p
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aivchenk at gmail dot com
CC: aivchenk at gmail dot com
The following code crashes android ndk gcc-4.6 on 64 bit windows with segfault
on at least -O1:
int c;
void foo(int f)
{
int wbi=-1;
c = (f ? "012346":"01345:6008")[wbi];
}
However, potentially it can appear on trunk as well: the reason for this is
that in fully_constant_vn_reference_p we have a bound violation:
1303| if (arg0->opcode == STRING_CST
1304| && (TYPE_MODE (op->type)
1305| == TYPE_MODE (TREE_TYPE (TREE_TYPE (arg0->op0
1306| && GET_MODE_CLASS (TYPE_MODE (op->type)) == MODE_INT
1307| && GET_MODE_SIZE (TYPE_MODE (op->type)) == 1
1308| && compare_tree_int (op->op0, TREE_STRING_LENGTH (arg0->op0)) <
0)
1309| return build_int_cst_type (op->type,
1310+> (TREE_STRING_POINTER (arg0->op0)
1311| [TREE_INT_CST_LOW (op->op0)]));
here the TREE_INT_CST_LOW (op->op0) is 0x ("wbi" from the code snippet
above and int_cst.low is unsigned). but here:
1308| && compare_tree_int (op->op0, TREE_STRING_LENGTH (arg0->op0)) <
0)
compare_tree_int thinks that op->op0 equals to "-1" and so the check for bound
violation passes.
I think we need to add another check that op->op0 is not less than zero here.
[Bug target/55816] New: Options from command line are added to target arch attribute eventhough they are in contradiction with that target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55816
Bug #: 55816
Summary: Options from command line are added to target arch
attribute eventhough they are in contradiction with
that target
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aivch...@gmail.com
CC: aivch...@gmail.com, hjl.to...@gmail.com,
ubiz...@gmail.com
Target: i?86-*-* x86_64-*-*
On x86 android gcc we have -msse3 turned on by default, that leads
gcc/testsuite/gcc.target/i386/funcspec-10.c to fail:
extern int foo (int) __attribute__((__target__("arch=i386")));
int
foo (int x)
{
if (x < 0)
x = 1;
return x;
}
because compiler produces CMOV, eventhough foo has been declared as arch=i386.
The problem is that isa option from command line (-msse3) is added to arch=i386
within this function.
I believe that there could be other cases when that would be more critical.
Should we turn off enabled from command line isa's inside the function with
"target arch" attribute, if those isa's are in contradiction with that arch?
[Bug treelang/55412] pr47276.c fails with -fpic option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55412 --- Comment #3 from Alexander Ivchenko 2012-11-21 07:48:23 UTC --- I tried to narrow down the problem and changed the test a little bit. (The relative order of declarations remains the same; Just grouped the coupled declarations) This changed test passes with -fno-pic and fails with -fpic. BUT if we comment out the first group of definition/declarations the test will fail with -fno-pic with the same problem, eventhough those two groups are completely independent of each other test case is attached in the previous comment
[Bug treelang/55412] pr47276.c fails with -fpic option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55412 --- Comment #2 from Alexander Ivchenko 2012-11-21 07:46:20 UTC --- Created attachment 28751 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28751 Simple reproducer
[Bug treelang/55412] New: pr47276.c fails with -fpic option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55412
Bug #: 55412
Summary: pr47276.c fails with -fpic option.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: treelang
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aivch...@gmail.com
When trying to compile pr47276.c with additional -fpic option I've got the
following error:
pr47276.c:36:1: warning: asm declaration ignored due to conflict with previous
rename [-Wpragmas]
extern __typeof (__vsyslog_chk) __vsyslog_chk __asm__ ("" ASMNAME
("__GI___vsyslog_chk")) __attribute__ ((visibility ("hidden")));
^
../../../../gcc/gcc/testsuite/gcc.dg/pr47276.c:25:123: error:
‘__EI___vsyslog_chk’ aliased to undefined symbol ‘__GI___vsyslog_chk’
extern __typeof (__vsyslog_chk) __EI___vsyslog_chk __asm__("" ASMNAME
("__vsyslog_chk")); extern __typeof (__vsyslog_chk) __EI___vsyslog_chk
__attribute__((alias ("" "__GI___vsyslog_chk")));
[Bug target/53435] (ix86_expand_vec_perm) and (ix86_expand_vec_perm) do not pass arguments to avx2_permvar8s[f,i] correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53435 --- Comment #1 from Alexander Ivchenko 2012-05-21 11:46:35 UTC --- Created attachment 27460 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27460 proposed patch for fixing
[Bug target/53435] New: (ix86_expand_vec_perm) and (ix86_expand_vec_perm) do not pass arguments to avx2_permvar8s[f,i] correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53435 Bug #: 53435 Summary: (ix86_expand_vec_perm) and (ix86_expand_vec_perm) do not pass arguments to avx2_permvar8s[f,i] correctly Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: aivch...@gmail.com CC: areg.melikadam...@gmail.com, hjl.to...@gmail.com, kirill.yuk...@intel.com, ubiz...@gmail.com Target: i?86-*-* x86_64-*-* Seems that after: commit 8da8a06b586ddd9511b5c5c83e2c28ca8d7613a8 Author: uros Date: Thu Apr 12 18:37:42 2012 + PR target/52932 * config/i386/avx2intrin.h (_mm256_permutevar8x32_ps): Change second argument type to __m256i. Update call to __builtin_ia32_permvarsf256. ... (avx2_permvarv8sf, avx2_permvarv8si): Switch operands 1 and 2. ... (ix86_expand_vec_perm): Update calls to gen_avx2_permvarv8si and gen_avx2_permvarv8sf. (expand_vec_perm_pshufb): Ditto. gcc.c-torture/execute/vshuf-v* and gcc.dg/torture/pr45720.c fail. The problem is that not everything that had to be changed was changed to use the second argument as __m256i. Please take a look at the attached patch that should fix those problems
