[Bug tree-optimization/66449] [6 Regression] ICE: in build2_stat, at tree.c:4376 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66449
--- Comment #1 from Dmitry G. Dyachenko dimhen at gmail dot com ---
start FAIL for me : r224020
configure as
$ ~/src/gcc_r224020/configure --prefix=/usr/local/gcc_current --enable-static
--enable-checking=release --enable-languages=c,c++,lto --enable-plugin
--disable-libstdcxx-dual-abi --disable-multilib
$ make
[build fail, fixed in r224030]
check as
$ /home/dimhen/build/gcc_r224020/./prev-gcc/xgcc
-B/home/dimhen/build/gcc_r224020/./prev-gcc/
-B/usr/local/gcc_current/x86_64-unknown-linux-gnu/bin/ -fpreprocessed -Werror
-Wall -O3 -c x.i
x.i: In function ‘fn1’:
x.i:1:7: internal compiler error: in build2_stat, at tree.c:4381
void *fn1(void *p1, void *p2, long p3) {
^
0xfb436b build2_stat(tree_code, tree_node*, tree_node*, tree_node*)
/home/dimhen/src/gcc_r224020/gcc/tree.c:4380
0x9afcef build2_stat_loc
/home/dimhen/src/gcc_r224020/gcc/tree.h:3702
0x9da548 fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/dimhen/src/gcc_r224020/gcc/fold-const.c:14286
0xe992d3 loop_exits_before_overflow
/home/dimhen/src/gcc_r224020/gcc/tree-ssa-loop-niter.c:3905
0xe99711 scev_probably_wraps_p(tree_node*, tree_node*, gimple_statement_base*,
loop*, bool)
/home/dimhen/src/gcc_r224020/gcc/tree-ssa-loop-niter.c:4036
0x14c96e1 convert_affine_scev(loop*, tree_node*, tree_node**, tree_node**,
gimple_statement_base*, bool)
/home/dimhen/src/gcc_r224020/gcc/tree-chrec.c:1279
0x14c9832 chrec_convert_1
/home/dimhen/src/gcc_r224020/gcc/tree-chrec.c:1334
0x14c9b3c chrec_convert(tree_node*, tree_node*, gimple_statement_base*, bool)
/home/dimhen/src/gcc_r224020/gcc/tree-chrec.c:1423
0xe0d3e6 interpret_rhs_expr
/home/dimhen/src/gcc_r224020/gcc/tree-scalar-evolution.c:1893
0xe0d52a interpret_gimple_assign
/home/dimhen/src/gcc_r224020/gcc/tree-scalar-evolution.c:1935
0xe0d793 analyze_scalar_evolution_1
/home/dimhen/src/gcc_r224020/gcc/tree-scalar-evolution.c:2017
0xe0d94b analyze_scalar_evolution(loop*, tree_node*)
/home/dimhen/src/gcc_r224020/gcc/tree-scalar-evolution.c:2072
0xe0da08 analyze_scalar_evolution_in_loop
/home/dimhen/src/gcc_r224020/gcc/tree-scalar-evolution.c:2168
0xe0f848 simple_iv(loop*, loop*, tree_node*, affine_iv*, bool)
/home/dimhen/src/gcc_r224020/gcc/tree-scalar-evolution.c:3276
0x14cd658 dr_analyze_innermost(data_reference*, loop*)
/home/dimhen/src/gcc_r224020/gcc/tree-data-ref.c:834
0x14ce1e7 create_data_ref(loop*, loop*, tree_node*, gimple_statement_base*,
bool)
/home/dimhen/src/gcc_r224020/gcc/tree-data-ref.c:1105
0x14d6180 find_data_references_in_stmt(loop*, gimple_statement_base*,
vecdata_reference*, va_heap, vl_ptr*)
/home/dimhen/src/gcc_r224020/gcc/tree-data-ref.c:4537
0x14d635b find_data_references_in_bb(loop*, basic_block_def*,
vecdata_reference*, va_heap, vl_ptr*)
/home/dimhen/src/gcc_r224020/gcc/tree-data-ref.c:4590
0x14d640c find_data_references_in_loop(loop*, vecdata_reference*, va_heap,
vl_ptr*)
/home/dimhen/src/gcc_r224020/gcc/tree-data-ref.c:4623
0x14d656b compute_data_dependences_for_loop(loop*, bool, vecloop*, va_heap,
vl_ptr*, vecdata_reference*, va_heap, vl_ptr*,
vecdata_dependence_relation*, va_heap, vl_ptr*)
/home/dimhen/src/gcc_r224020/gcc/tree-data-ref.c:4699
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/66451] New: Array not fully destructed if element destructor throws exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66451
Bug ID: 66451
Summary: Array not fully destructed if element destructor
throws exception
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jonathandodd at gmail dot com
Target Milestone: ---
If an array element throws during destruction, undestructed elements in that
array are not destructed. Other local variables are destructed. Clang calls
destructors on all automatic objects, regardless whether in or out of an array.
(And yes, I know throwing from destructors should be avoided, but that's hardly
the point ;p)
Relevant sections from standard
---
s15.2:
As control passes from the point where an exception is thrown to a handler,
destructors are invoked for all automatic objects constructed since the try
block was entered. ...
An object of any storage duration whose initialization or destruction is
terminated by an exception will have destructors executed for all of its fully
constructed subobjects
s1.8:
A subobject can be ... an array element.
Test case
-
#include iostream
#include exception
using namespace std;
class A {
public:
A(int new_a) : a(new_a) { }
~A() noexcept(false) {
cout a a .~A() ;
if(std::uncaught_exception())
cout Unwinding;
cout endl;
if(a==4)
throw a;
}
int a;
};
int main()
{
try {
A a1(1), a2(2);
A arr[] = {3,4,5};
} catch(...) { }
}
Output (g++ 4.9.2)
--
a5.~A()
a4.~A()
a2.~A() Unwinding
a1.~A() Unwinding
Output (clang 3.5.0)
a5.~A()
a4.~A()
a3.~A() Unwinding
a2.~A() Unwinding
a1.~A() Unwinding
[Bug sanitizer/66452] New: [6 Regression] [UBSAN] *.Lubsan_data0' defined but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66452
Bug ID: 66452
Summary: [6 Regression] [UBSAN] *.Lubsan_data0' defined but not
used
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
r224060 PASS
r224193 FAIL
$ g++ -Wall -O0 -fsanitize=undefined -c x.ii -fpreprocessed -o x.o
x.ii: In member function 'A B::m_fn1() const':
x.ii:9:12: warning: unused variable 'i' [-Wunused-variable]
for (int i;;)
^
At global scope:
cc1plus: warning: '*.Lubsan_data0' defined but not used [-Wunused-variable]
$ cat x.ii
class A {
public:
A(int);
};
class B {
A m_fn1() const;
};
A B::m_fn1() const {
for (int i;;)
;
return 0;
}
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --enable-static
--enable-checking=yes,df,fold,rtl --enable-languages=c,c++,lto --enable-plugin
--disable-libstdcxx-dual-abi --disable-multilib
Thread model: posix
gcc version 6.0.0 20150606 (experimental) [trunk revision 224193] (GCC)
$ ~/bin/gcc_224060_rls/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/dimhen/bin/gcc_224060_rls/bin/g++
COLLECT_LTO_WRAPPER=/home/dimhen/bin/gcc_224060_rls/bin/../libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_r224060/configure
--prefix=/usr/local/gcc_current --enable-static --enable-checking=release
--enable-languages=c,c++,lto --enable-plugin --disable-libstdcxx-dual-abi
--disable-multilib
Thread model: posix
gcc version 6.0.0 20150603 (experimental) [trunk revision 224060] (GCC)
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
Aldy Hernandez aldyh at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org ---
2. Once (1) is fixed, bootstrap then fails with:
/GCC/gcc-trunk/gcc/ipa-pure-const.c:1640:1: error:
‘{anonymous}::pass_ipa_pure_const::pass_ipa_pure_const(gcc::context*)’
defined but not used [-Werror=unused-function]
pass_ipa_pure_const::
A --disable-werror boostrap completes, but there are a number of
constructors and destructors that report declared but not used. AFAICT,
it's only constructors/destructors.
This is occurring at stage #2, and I thought maybe that the stage#1 compiler
could have been mis-compiled by the bootstrap; however, gcc-4.9, 5.1 and
clang (xcode 5.1.1) bootstraps all give the same result.
Jason, is pass_ipa_pure_const::pass_ipa_pure_const() really declared but not
used?
If so, can we mark it ATTRIBUTE_UNSUED or is there a more generic way of fixing
this?
[Bug tree-optimization/66442] [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66442 --- Comment #3 from vries at gcc dot gnu.org --- (In reply to vries from comment #2) Created attachment 35711 [details] tentative patch Bootstrap and reg-test on x86_64 succeeded.
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Aldy Hernandez from comment #2)
2. Once (1) is fixed, bootstrap then fails with:
/GCC/gcc-trunk/gcc/ipa-pure-const.c:1640:1: error:
‘{anonymous}::pass_ipa_pure_const::pass_ipa_pure_const(gcc::context*)’
defined but not used [-Werror=unused-function]
pass_ipa_pure_const::
A --disable-werror boostrap completes, but there are a number of
constructors and destructors that report declared but not used. AFAICT,
it's only constructors/destructors.
This is occurring at stage #2, and I thought maybe that the stage#1 compiler
could have been mis-compiled by the bootstrap; however, gcc-4.9, 5.1 and
clang (xcode 5.1.1) bootstraps all give the same result.
Jason, is pass_ipa_pure_const::pass_ipa_pure_const() really declared but not
used?
I bet a drink that it is an incharge vs outofcharge construct/deconstruct
issue. Darwin does not support aliases so the function itself is cloned.
If so, can we mark it ATTRIBUTE_UNSUED or is there a more generic way of
fixing this?
[Bug tree-optimization/66442] [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66442 --- Comment #4 from Andreas Schwab sch...@linux-m68k.org --- Fixes the test case on m68k.
[Bug tree-optimization/66449] New: [6 Regression] ICE: in build2_stat, at tree.c:4376 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66449
Bug ID: 66449
Summary: [6 Regression] ICE: in build2_stat, at tree.c:4376
with -O3
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
Target Milestone: ---
r223920 PASS
r224193 FAIL
gcc -fpreprocessed -Werror -Wall -O2 -c x.i PASS
gcc -fpreprocessed -Werror -Wall -O3 -c x.i FAIL
$ cat x.i
void *fn1(void *p1, void *p2, long p3) {
long a = (long)p1, b = (long)p2, c = p3;
while (c) {
int d = ((int *)b)[0];
c--;
((char *)a)[0] = d;
a++;
}
return 0;
}
$ /usr/local/gcc_current/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc_current/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --enable-static
--enable-checking=yes,df,fold,rtl --enable-languages=c,c++,lto --enable-plugin
--disable-libstdcxx-dual-abi --disable-multilib
Thread model: posix
gcc version 6.0.0 20150606 (experimental) [trunk revision 224193] (GCC)
$ /usr/local/gcc_current/bin/gcc -fpreprocessed -Werror -Wall -O3 -c x.i
x.i: In function ‘fn1’:
x.i:1:7: internal compiler error: in build2_stat, at tree.c:4376
void *fn1(void *p1, void *p2, long p3) {
^
0xe180cd build2_stat(tree_code, tree_node*, tree_node*, tree_node*)
/home/dimhen/src/gcc_current/gcc/tree.c:4375
0x862c78 build2_stat_loc
/home/dimhen/src/gcc_current/gcc/tree.h:3702
0x862c78 fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/dimhen/src/gcc_current/gcc/fold-const.c:14281
0xd05015 loop_exits_before_overflow
/home/dimhen/src/gcc_current/gcc/tree-ssa-loop-niter.c:3900
0xd05015 scev_probably_wraps_p(tree_node*, tree_node*, gimple_statement_base*,
loop*, bool)
/home/dimhen/src/gcc_current/gcc/tree-ssa-loop-niter.c:4031
0x13d3108 convert_affine_scev(loop*, tree_node*, tree_node**, tree_node**,
gimple_statement_base*, bool)
/home/dimhen/src/gcc_current/gcc/tree-chrec.c:1275
0x13d3510 chrec_convert_1
/home/dimhen/src/gcc_current/gcc/tree-chrec.c:1330
0xc7e6c8 interpret_rhs_expr
/home/dimhen/src/gcc_current/gcc/tree-scalar-evolution.c:1886
0xc7acca interpret_gimple_assign
/home/dimhen/src/gcc_current/gcc/tree-scalar-evolution.c:1928
0xc7acca analyze_scalar_evolution_1
/home/dimhen/src/gcc_current/gcc/tree-scalar-evolution.c:2010
0xc7b737 analyze_scalar_evolution(loop*, tree_node*)
/home/dimhen/src/gcc_current/gcc/tree-scalar-evolution.c:2065
0xc7f12a analyze_scalar_evolution_in_loop
/home/dimhen/src/gcc_current/gcc/tree-scalar-evolution.c:2161
0xc7f26f simple_iv(loop*, loop*, tree_node*, affine_iv*, bool)
/home/dimhen/src/gcc_current/gcc/tree-scalar-evolution.c:3269
0x13dc669 dr_analyze_innermost(data_reference*, loop*)
/home/dimhen/src/gcc_current/gcc/tree-data-ref.c:829
0x13e1742 create_data_ref(loop*, loop*, tree_node*, gimple_statement_base*,
bool)
/home/dimhen/src/gcc_current/gcc/tree-data-ref.c:1100
0x13e261c find_data_references_in_stmt(loop*, gimple_statement_base*,
vecdata_reference*, va_heap, vl_ptr*)
/home/dimhen/src/gcc_current/gcc/tree-data-ref.c:4532
0x13e27ea find_data_references_in_bb(loop*, basic_block_def*,
vecdata_reference*, va_heap, vl_ptr*)
/home/dimhen/src/gcc_current/gcc/tree-data-ref.c:4585
0x13e2a10 find_data_references_in_loop(loop*, vecdata_reference*, va_heap,
vl_ptr*)
/home/dimhen/src/gcc_current/gcc/tree-data-ref.c:4618
0x13e3b4a compute_data_dependences_for_loop(loop*, bool, vecloop*, va_heap,
vl_ptr*, vecdata_reference*, va_heap, vl_ptr*,
vecdata_dependence_relation*, va_heap, vl_ptr*)
/home/dimhen/src/gcc_current/gcc/tree-data-ref.c:4694
0xc65565 tree_predictive_commoning_loop
/home/dimhen/src/gcc_current/gcc/tree-predcom.c:2486
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66258 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Whomever approved the patch for the trunk can also approve the backport.
[Bug c++/66450] New: [5 Regression][C++11][constexpr] Issues when delegating implicit copy constructor in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66450
Bug ID: 66450
Summary: [5 Regression][C++11][constexpr] Issues when
delegating implicit copy constructor in constexpr
function
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mosra at centrum dot cz
Target Milestone: ---
The following code is compiled fine in both GCC 4.9.2 and Clang 3.6:
struct foo {
constexpr foo(int a);
constexpr foo(int a, int b, int c): a{a}, b{b}, c{c} {}
int a, b, c;
};
constexpr foo make_foo(int a) { return foo{a, a+1, a+2}; }
constexpr foo::foo(int a): foo{make_foo(a)} {}
int main() {
constexpr const foo f{3};
static_assert(f.a == 3, );
static_assert(f.b == 4, );
static_assert(f.c == 5, );
}
In GCC 5.1 it produces an error about non-constant condition for static
assertion. If the relevant lines are changed to runtime assert (and #include
cassert added):
assert(f.a == 3);
assert(f.b == 4);
assert(f.c == 5);
Then all three assertions fail at runtime, because the copy constructor is
somehow not called and the structure is instead just zeroed out. HOWEVER, if
you remove all occurrences of the constexpr keyword, the code compiles, no
runtime assertion is fired and everything behaves as expected.
The behavior is the same for -std=c++11 and -std=c++14.
I think the static assertion error and the zero-initialization are somehow
related, so I put these into single issue instead of creating two separate
ones.
[Bug c/66454] Common -Wmisleading-indentation false-positive triggered in the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66454 --- Comment #2 from patrick at parcs dot ath.cx --- Created attachment 35712 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35712action=edit rough patch Here is a rough patch of the aforementioned change -- to look at the column of the first non-whitespace character on the line of the guard token, instead of looking at the column of the guard token itself. The patch eliminates all of the -Wmisleading-indentation false positives from the Linux kernel build, and all of the false positives from the sqlite build.
[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66444
vries at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org
--- Comment #1 from vries at gcc dot gnu.org ---
Tentative patch:
...
diff --git a/gcc/postreload.c b/gcc/postreload.c
index 7ecca15..1cc7b14 100644
--- a/gcc/postreload.c
+++ b/gcc/postreload.c
@@ -1352,9 +1352,12 @@ reload_combine (void)
if (CALL_P (insn))
{
rtx link;
+ HARD_REG_SET used_regs;
+
+ get_call_reg_set_usage (insn, used_regs, call_used_reg_set);
for (r = 0; r FIRST_PSEUDO_REGISTER; r++)
- if (call_used_regs[r])
+ if (TEST_HARD_REG_BIT (used_regs, r))
{
reg_state[r].use_index = RELOAD_COMBINE_MAX_USES;
reg_state[r].store_ruid = reload_combine_ruid;
...
Output with patch:
...
movabsq $962072674304, %r8
salq$5, %rax
addq%rax, %r8
movq%r8, %rdi
callfn1
movq%r8, %rdi
callfn2
...
[Bug c++/66421] G++ fails compilation when assigning tuple created with variadic template to auto variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66421 Nathan Sidwell nathan at gcc dot gnu.org changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #2 from Nathan Sidwell nathan at gcc dot gnu.org --- Appears resolved in version r224163
[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66444 --- Comment #2 from vries at gcc dot gnu.org --- Looks like reload_cse_move2add could use a similar fix.
[Bug c++/52960] Missing warnings on ambiguous source : function decl vs local var decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52960 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||jan.kratochvil at redhat dot com --- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com --- Missing keyword: diagnostic Valid for: g++ (GCC) 6.0.0 20150530 (experimental) clang-3.6.0-2.fc23.x86_64
[Bug tree-optimization/66442] [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66442 --- Comment #2 from vries at gcc dot gnu.org --- Created attachment 35711 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35711action=edit tentative patch
[Bug ipa/66271] -Os generates incorrect code on ARM possibly due to IPA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66271 Jim Wilson wilson at gcc dot gnu.org changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #6 from Jim Wilson wilson at gcc dot gnu.org --- This appears to be the same problem as 65932.
[Bug c++/66443] Virtual inheritance vs. non-default constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66443 Nathan Sidwell nathan at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-08 CC||nathan at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Ever confirmed|0 |1
[Bug libitm/66453] New: In a deadlock libitm allocates all available RAM until oom is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66453
Bug ID: 66453
Summary: In a deadlock libitm allocates all available RAM until
oom is called
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libitm
Assignee: unassigned at gcc dot gnu.org
Reporter: gallir at gmail dot com
Target Milestone: ---
The following transaction block make libitm to allocate all available memory in
few seconds:
int counter[ARRAY_SIZE];
void *count(void *ptr) {
long i, max = MAX_COUNT/NUM_THREADS;
int tid = ((struct tdata *) ptr)-tid;
__transaction_atomic {
while (!counter[tid]);
counter[(tid + 1) % NUM_THREADS] = 1;
}
return;
}
Full code with 2 threads: https://gist.github.com/gallir/5df222892b1f633c8275
(tested and reproduced in a Intel i5)
The example is awfully buggy, generates an obvious -binary barrier- deadlock,
but libitm could limit the amount of allocations to prevent that this type of
mistakes brings the server down (the number of allocations is a good hint of a
deadlock, isn't it?)
[Bug c/66454] New: Common -Wmisleading-indentation false-positive triggered in the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66454
Bug ID: 66454
Summary: Common -Wmisleading-indentation false-positive
triggered in the Linux kernel
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at parcs dot ath.cx
Target Milestone: ---
The following test case is a template exhibiting the kind of code in the Linux
kernel that often triggers a -Wmisleading-indentation false-positive:
int *p;
void
foo (int n)
{
if (p) {
foo (1);
} else
if (p)
foo (2);
foo (3);
}
indentation.c: In function ‘foo’:
indentation.c:13:5: warning: statement is indented as if it were guarded by...
[-Wmisleading-indentation]
foo (3);
^
indentation.c:10:7: note: ...this ‘else’ clause, but it is not
} else
^
[Bug c/66454] Common -Wmisleading-indentation false-positive triggered in the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66454
--- Comment #1 from patrick at parcs dot ath.cx ---
We suppress the warning for
int *p;
void
foo (int n)
{
if (p)
foo (1);
else // guard token
if (p) // body token
foo (2);
foo (3); // next token
}
because we notice that the guard, body and next tokens are all on the same
column. But the closing brace in front of the else in the original test case
makes that condition no longer hold as the column of the guard token gets
shifted.
To fix this (and similar false positives), I think we should take into account
the first non-whitespace character on the guard line. If the column of that
character lines up with the columns of the body and next tokens, then we should
suppress the warning, too. In the original test case the first nonwhitespace
character on the guard line is }, and indeed the columns line up. So the
warning would be suppressed.
We also have to worry about the following false negative:
int *p;
void
foo (int n)
{
if (p) {
foo (1);
} else // guard
if (p) // body
foo (2);
foo (3); // next
}
Here the guard, body and next columns line up, thus suppressing the warning --
but of course we would like to warn about foo (3); here. So maybe we
shouldn't take into account the column of the guard character at all, but
rather always take into account the column of the first non-whitespace
character on the line of the guard token?
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Target|x86_64-apple-darwin14 |*-apple-darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-07 Host|x86_64-apple-darwin14 |*-apple-darwin* Ever confirmed|0 |1 Build|x86_64-apple-darwin14 |*-apple-darwin*
[Bug bootstrap/66448] New: [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448 Bug ID: 66448 Summary: [6 Regression] Bootstrap fails on darwin after r224161 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: aldyh at gcc dot gnu.org, iains at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin14 Target: x86_64-apple-darwin14 Build: x86_64-apple-darwin14 Bootstrap fails on darwin after r224161 ... checking for suffix of object files... configure: error: in `/opt/gcc/p_build/x86_64-apple-darwin14.3.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. ... configure:3675: /opt/gcc/p_build/./gcc/xgcc -B/opt/gcc/p_build/./gcc/ -B/opt/gcc/gcc6p-224161p4/x86_64-apple-darwin14.3.0/bin/ -B/opt/gcc/gcc6p-224161p4/x86_64-apple-darwin14.3.0/lib/ -isystem /opt/gcc/gcc6p-224161p4/x86_64-apple-darwin14.3.0/include -isystem /opt/gcc/gcc6p-224161p4/x86_64-apple-darwin14.3.0/sys-include-c -g -O2 conftest.c 5 built-in: internal compiler error: Segmentation fault: 11 built-in: internal compiler error: Abort trap: 6 xgcc: internal compiler error: Abort trap: 6 (program cc1)
[Bug c++/52869] [DR 1207] this not being allowed in noexcept clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
--- Comment #1 from htfy96 lz96 at foxmail dot com ---
#include iostream
using namespace std;
class A
{
public:
void g() noexcept(false) {}
void f() noexcept( noexcept( g() )) {};
};
A a;
int main()
{
coutnoexcept(a.f())endl;
return 0;
}
This is another testcase.
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #1 from Iain Sandoe iains at gcc dot gnu.org ---
Created attachment 35710
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35710action=edit
declare extern int __CFConstantStringClassReference lazily
There seem to be three issues triggered by 224161
1. Debug is not initialised when the built-ins are initialised, therefore any
attempt to declare a variable at that time causes the segv. (hash table is not
present).
* at present, *darwin* declares extern int
__CFConstantStringClassReference[] at the time that the CFString built-in is
initialised.
- on the basis that it's not clear *if* such early declarations are allowed,
I've made a patch that makes the declaration lazily (when the fist use of the
built-in occurs).
This works around the reported crash (one could also use DECL_SOURCE_LOCATION
!= BUILTINS_LOCATION as an additional test at passes.c:338, if built-ins *are*
supposed to be allowed to declare variables.
… however ...
2. Once (1) is fixed, bootstrap then fails with:
/GCC/gcc-trunk/gcc/ipa-pure-const.c:1640:1: error:
‘{anonymous}::pass_ipa_pure_const::pass_ipa_pure_const(gcc::context*)’ defined
but not used [-Werror=unused-function]
pass_ipa_pure_const::
A --disable-werror boostrap completes, but there are a number of constructors
and destructors that report declared but not used. AFAICT, it's only
constructors/destructors.
This is occurring at stage #2, and I thought maybe that the stage#1 compiler
could have been mis-compiled by the bootstrap; however, gcc-4.9, 5.1 and clang
(xcode 5.1.1) bootstraps all give the same result.
… additional info …
=
3. During bootstrap (and in the test suite on the --disable-werror build) there
are a large number of warnings from ld64 (of course, this might be a limitation
of ld64, but for the record):
warning: invalid DWARF generated by the compiler: DIE 0x02f7 has multiple
AT_location attributes in
'/GCC/ml/gcc-trunk-xtools/x86_64-apple-darwin12/libgcc/enable-execute-stack_s.o'.
warning: invalid DWARF generated by the compiler: DIE 0x0317 has multiple
AT_location attributes in
'/GCC/ml/gcc-trunk-xtools/x86_64-apple-darwin12/libgcc/enable-execute-stack_s.o'.
[Bug ipa/66271] -Os generates incorrect code on ARM possibly due to IPA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66271 --- Comment #7 from gccbugs at rooted dot tk --- Seems like it is indeed the same issue.
[Bug libstdc++/66455] New: is_always_equal unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66455 Bug ID: 66455 Summary: is_always_equal unimplemented Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: potswa at mac dot com Target Milestone: --- std::allocator_traits does not contain a member is_equal, as required since C++11.
[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 gccbugs at rooted dot tk changed: What|Removed |Added CC||gccbugs at rooted dot tk --- Comment #8 from gccbugs at rooted dot tk --- Can confirm this on the 5-20150519 snapshot. Here's a self-contained snippet demonstrates this problem (from vsprintf.c): https://gcc.gnu.org/bugzilla/attachment.cgi?id=35613
