[Bug c++/60027] New: Problem with braced-init-lists and explicit ctors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60027
Bug ID: 60027
Summary: Problem with braced-init-lists and explicit ctors
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joaquin at tid dot es
The following code compiled with -std=c++11:
struct foo
{
foo(int){}
};
struct bar
{
explicit bar(int){}
};
void f(foo){}
void f(bar){}
int main()
{
f({0});
}
yields:
main.cpp:16:8: error: call of overloaded 'f(brace-enclosed initializer
list)' is ambiguous
f({0});
^
main.cpp:16:8: note: candidates are:
main.cpp:11:6: note: void f(foo)
void f(foo){}
^
main.cpp:12:6: note: void f(bar)
void f(bar){}
^
which seems incorrect as bar::bar(int) is explicit.
Joaquín M López Muñoz
Telefónica Digital
[Bug target/60028] New: TIC6X: B3 register (return address) is saved on stack when real call is replaced with sibling call in a leaf function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60028
Bug ID: 60028
Summary: TIC6X: B3 register (return address) is saved on stack
when real call is replaced with sibling call in a leaf
function
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wojtek.golf at interia dot pl
GCC 4.8.2, target tic6x
Input source:
int e_fun(int arg);
extern int e_int;
void g_fun(void)
{
e_fun(e_int);
}
compiled with a command: -fleading-underscore -march=c674x -O2 -g0 -S main.c
gives the following assembler code:
_g_fun:
sub .d2 B15, 8, B15
stw .d2t2 B3, *+B15(8)
b .s1 (_e_fun)
|| ldw .d2t1 *+B14(_e_int), A4
ldw .d2t2 *+B15(8), B3
|| add .s2 8, B15, B15
;; sibcall to (_e_fun) occurs
nop 4
where B3 is saved on the stack even though a branch is taken to _e_fun. Texas
Instruments CGTools compiler v7.3.2 (cl6x --gcc -mv6740 --symdebug:none -k -n
main.c) gives the following assembler code (CALLRET is an alias to B):
_g_fun:
CALLRET .S1 _e_fun; |6|
LDW .D2T1 *+DP(_e_int),A4 ; |6|
NOP 4
$C$RL0:; CALL-RETURN OCCURS {_e_fun} 0 ; |6|
where B3 is not saved.
Some investigation on my part leads to the function c6x_expand_call in the file
gcc/gcc/config/c6x/c6x.c, where we see what may cause B3 being marked as used
and hence saved on the stack prior to the branch:
if (sibcall)
{
call_insn = emit_call_insn (call_insn);
use_reg (CALL_INSN_FUNCTION_USAGE (call_insn),
gen_rtx_REG (Pmode, REG_B3));
}
commenting out use_reg invocation makes gcc to generate the expected listing:
_g_fun:
b .s1 (_e_fun)
|| ldw .d2t1 *+B14(_e_int), A4
;; sibcall to (_e_fun) occurs
nop 5
I haven't tested yet whether removal of use_reg invocation causes any
regression, but I'd like it to be investigated whether it should be removed
altogether or protected with some extra execution condition.
With best,
Wojciech
[Bug fortran/57033] [4.7/4.8/4.9 Regression] ICE on extended derived type and default initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57033 --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Sun Feb 2 11:50:28 2014 New Revision: 207396 URL: http://gcc.gnu.org/viewcvs?rev=207396root=gccview=rev Log: fortran/ PR fortran/57033 * primary.c (gfc_convert_to_structure_constructor): Avoid null pointer dereference. testsuite/ PR fortran/57033 * gfortran.dg/default_initialization_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/default_initialization_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
[Bug target/51518] ICE: in expand_call, at calls.c:3421 with -mno-accumulate-outgoing-args and __attribute__ ((ms_abi)) (after sorry)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51518 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #2 from David Binderman dcb314 at hotmail dot com --- (In reply to Marek Polacek from comment #1) Confirmed. Trunk dated 20140201 seems to also have this problem.
[Bug target/60017] [4.7/4.8/4.9 Regression] Struct not returned correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60017 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target|x86_64-*-darwin*|x86_64 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- I have a patch.
[Bug middle-end/60013] [4.9 Regression] Build of 176.gcc from CPU2000 loops in cc1 starting with r207231
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 32014 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32014action=edit A patch I am testing this patch.
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #37 from Markus Trippelsdorf trippels at gcc dot gnu.org --- I think the error is that the symbol from the explicit template instantiation in Function.ii (marked with forced_by_abi) gets merged with the symbol in the same COMDAT group from BasicBlock.ii. (This symbol isn't marked with forced_by_abi, but somehow has prevailing_def_ironly_exp) Merging nodes for _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_. Candidates: _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/9 (transferNodesFromList) @0x7f4d65008e18 Type: function definition analyzed Visibility: externally_visible prevailing_def_ironly_exp public weak comdat comdat_group:_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromLi stERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_ one_only next sharing asm name: 22 References: Referring: Read from file: /tmp/ccx3oVJ3.o First run: 0 Function flags: Called by: _ZN4llvm10BasicBlock10moveBeforeEv/1 (1.00 per call) (can throw external) _ZN4llvm10BasicBlock10moveBeforeEv/1 (1.00 per call) (can throw external) Calls: _ZN4llvm14ilist_iteratorINS_10BasicBlockEEneERS2_/16 (11.11 per call) (can throw external) _ZN4llvm14ilist_iteratorINS_10BasicBlockEEppEv/15 (10.11 per call) (can throw external) _ZN4llvm12ilist_traitsINS_10BasicBlockEE9getSymTabEPNS_8FunctionE/14 (1.00 per call) (can throw external) _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8Fu nctionEE12getListOwnerEv/13 (1.00 per call) (can throw external) _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE12getListOwnerEv/13 (1.00 per call) (can throw external) _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/22 (transferNodesFromList) @0x7f4d651888f8 Type: function definition analyzed Visibility: forced_by_abi externally_visible preempted_ir public weak comdat_group:_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS _12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_ one_only previous sharing asm name: 9 References: Referring: Read from file: /tmp/ccZVoWfZ.o First run: 0 Function flags: Called by: Calls:
[Bug target/60029] [4.9 regression] FAIL: c-c++-common/dfp/convert-bfp.c -std=c++11 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60029 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/60029] New: [4.9 regression] FAIL: c-c++-common/dfp/convert-bfp.c -std=c++11 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60029
Bug ID: 60029
Summary: [4.9 regression] FAIL: c-c++-common/dfp/convert-bfp.c
-std=c++11 execution test
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sch...@linux-m68k.org
Target: powerpc-*-*
$ gcc/xg++ -Bgcc/ ../gcc/testsuite/c-c++-common/dfp/convert-bfp.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-Ipowerpc64-linux/32/libstdc++-v3/include/powerpc64-linux
-Ipowerpc64-linux/32/libstdc++-v3/include -I../libstdc++-v3/libsupc++
-I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util
-fmessage-length=0 -std=c++11 -Lpowerpc64-linux/32/libstdc++-v3/src/.libs
-Bpowerpc64-linux/32/libstdc++-v3/src/.libs
-Lpowerpc64-linux/32/libstdc++-v3/src/.libs -lm -m32 -o ./convert-bfp.exe
$
LD_LIBRARY_PATH=.:powerpc64-linux/32/libstdc++-v3/src/.libs:powerpc64-linux/32/libstdc++-v3/src/.libs:gcc:gcc/32:.:powerpc64-linux/32/libstdc++-v3/src/.libs:powerpc64-linux/32/libstdc++-v3/src/.libs:gcc:gcc/32:powerpc64-linux/libstdc++-v3/src/.libs:powerpc64-linux/libsanitizer/.libs:powerpc64-linux/libssp/.libs:powerpc64-linux/libgomp/.libs:powerpc64-linux/libitm/.libs:powerpc64-linux/libatomic/.libs:./gcc:./prev-gcc
./convert-bfp.exe
Segmentation fault
From convert-bfp.c.214r.reload:
(insn 666 665 316 30 (set (reg:DD 8 8)
(mem/c:DD (plus:SI (reg/f:SI 31 31)
(const_int 24 [0x18])) [0 S8 A64]))
gcc/testsuite/c-c++-common/dfp/convert-bfp.c:85 445 {*movdd_hardfloat32}
(nil))
(insn 316 666 317 30 (set (mem/v/c:SD (lo_sum:SI (reg:SI 9 9 [346])
(symbol_ref:SI (d32) [flags 0x6] var_decl 0x3fff89f17be0
d32)) [0 d32+0 S4 A32])
(reg:SD 8 8)) gcc/testsuite/c-c++-common/dfp/convert-bfp.c:85 441
{movsd_hardfloat}
(nil))
With -m32 insn 666 is split into two insns that clobber both register 8 and 9.
(insn 754 665 755 (set (reg:SI 8 8)
(mem/c:SI (plus:SI (reg/f:SI 31 31)
(const_int 24 [0x18])) [0 S4 A64]))
gcc/testsuite/c-c++-common/dfp/convert-bfp.c:85 434 {*movsi_internal1}
(nil))
(insn 755 754 316 (set (reg:SI 9 9 [orig:8+4 ] [8])
(mem/c:SI (plus:SI (reg/f:SI 31 31)
(const_int 28 [0x1c])) [0 S4 A32]))
gcc/testsuite/c-c++-common/dfp/convert-bfp.c:85 434 {*movsi_internal1}
(nil))
[Bug rtl-optimization/60030] [4.9 regression] ICE in simplify_subreg, at simplify-rtx.c:5903
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60030 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug rtl-optimization/60030] New: [4.9 regression] ICE in simplify_subreg, at simplify-rtx.c:5903
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60030 Bug ID: 60030 Summary: [4.9 regression] ICE in simplify_subreg, at simplify-rtx.c:5903 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Target: powerpc-*-* $ gcc/xgcc -Bgcc/ ../gcc/testsuite/c-c++-common/ubsan/overflow-1.c -Bpowerpc64-linux/32/libsanitizer/ -Bpowerpc64-linux/32/libsanitizer/ubsan/ -Lpowerpc64-linux/32/libsanitizer/ubsan/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -fsanitize=signed-integer-overflow -lm -m32 -o ./overflow-1.exe../gcc/testsuite/c-c++-common/ubsan/overflow-1.c: In function ‘main’: ../gcc/testsuite/c-c++-common/ubsan/overflow-1.c:81:40: internal compiler error: in simplify_subreg, at simplify-rtx.c:5903 ../gcc/testsuite/c-c++-common/ubsan/overflow-1.c:12:29: note: in definition of macro ‘CHECK’ ../gcc/testsuite/c-c++-common/ubsan/overflow-1.c:81:10: note: in expansion of macro ‘FN1’ 0x1054b22b simplify_subreg(machine_mode, rtx_def*, machine_mode, unsigned int) ../../gcc/simplify-rtx.c:5902 0x1054b4df simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned int) ../../gcc/simplify-rtx.c:6123 0x102b9abf operand_subword(rtx_def*, unsigned int, int, machine_mode) ../../gcc/emit-rtl.c:1442 0x102b9cbf operand_subword_force(rtx_def*, unsigned int, machine_mode) ../../gcc/emit-rtl.c:1455 0x1048412b expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) ../../gcc/optabs.c:1813 0x102cf023 expand_shift_1 ../../gcc/expmed.c:2287 0x103a5b2f ubsan_expand_si_overflow_mul_check(gimple_statement_base*) ../../gcc/internal-fn.c:649 0x103a659b expand_internal_call(gimple_statement_base*) ../../gcc/internal-fn.c:883 0x101f2667 expand_call_stmt ../../gcc/cfgexpand.c:2188 0x101f2667 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3157 0x101f2667 expand_gimple_stmt ../../gcc/cfgexpand.c:3309 0x101f351f expand_gimple_basic_block ../../gcc/cfgexpand.c:5149 0x101f58ab gimple_expand_cfg ../../gcc/cfgexpand.c:5715 0x101f58ab execute ../../gcc/cfgexpand.c:5935
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #38 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
So maybe the following patch is enough:
diff --git a/gcc/lto/lto-symtab.c b/gcc/lto/lto-symtab.c
index f5f9d1318ee0..bdb536131707 100644
--- a/gcc/lto/lto-symtab.c
+++ b/gcc/lto/lto-symtab.c
@@ -57,7 +57,7 @@ lto_cgraph_replace_node (struct cgraph_node *node,
}
/* Merge node flags. */
- if (node-force_output)
+ if (node-force_output || node-forced_by_abi)
cgraph_mark_force_output_node (prevailing_node);
if (node-address_taken)
{
[Bug target/60017] [4.7/4.8/4.9 Regression] Struct not returned correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60017 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC|uros at gcc dot gnu.org| --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00027.html
[Bug target/60017] [4.7/4.8/4.9 Regression] Struct not returned correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60017 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Sun Feb 2 15:35:53 2014 New Revision: 207399 URL: http://gcc.gnu.org/viewcvs?rev=207399root=gccview=rev Log: PR target/60017 * config/i386/i386.c (classify_argument): Fix handling of bit_offset when calculating size of integer atomic types. testsuite/ChangeLog: PR target/60017 * gcc.c-torture/execute/pr60017.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr60017.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug testsuite/60031] dg-require-effective-target powerpc_vsx_ok is not enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60031 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug testsuite/60031] New: dg-require-effective-target powerpc_vsx_ok is not enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60031 Bug ID: 60031 Summary: dg-require-effective-target powerpc_vsx_ok is not enough Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Target: powerpc*-*-* Runtime tests cannot use dg-require-effective-target powerpc_vsx_ok alone since check_effective_target_powerpc_vsx_ok only checks whether -mvsx works, but not whether the target can execute VSX insns.
[Bug middle-end/60013] [4.9 Regression] Build of 176.gcc from CPU2000 loops in cc1 starting with r207231
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Attachment #32014|0 |1 is obsolete|| --- Comment #10 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 32015 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32015action=edit An updated patch
[Bug target/60032] New: [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032
Bug ID: 60032
Summary: [4.9 regression] ICE in reload_cse_simplify_operands,
at postreload.c:411
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sch...@linux-m68k.org
Target: powerpc-*-*
$ ./gcc/xg++ -shared-libgcc -B./gcc -nostdinc++
-Lpowerpc64-linux/32/libstdc++-v3/src
-Lpowerpc64-linux/32/libstdc++-v3/src/.libs
-Lpowerpc64-linux/32/libstdc++-v3/libsupc++/.libs -B/usr/powerpc64-linux/bin/
-B/usr/powerpc64-linux/lib/ -isystem /usr/powerpc64-linux/include -isystem
/usr/powerpc64-linux/sys-include -m32
-BBuild/powerpc64-linux/32/libstdc++-v3/src/.libs -fdiagnostics-color=never
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -O2 -g
-D_GNU_SOURCE -O2 -g -D_GNU_SOURCE -DLOCALEDIR=. -nostdinc++
-Ipowerpc64-linux/32/libstdc++-v3/include/powerpc64-linux
-Ipowerpc64-linux/32/libstdc++-v3/include -I../libstdc++-v3/libsupc++
-I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util
../libstdc++-v3/testsuite/decimal/pr54036-1.cc -include bits/stdc++.h
powerpc64-linux/libstdc++-v3/testsuite/libtestc++.a -Wl,--gc-sections -lm -m32
-o ./pr54036-1.exe
../libstdc++-v3/testsuite/decimal/pr54036-1.cc: In function ‘int main()’:
../libstdc++-v3/testsuite/decimal/pr54036-1.cc:71:1: error: insn does not
satisfy its constraints:
}
^
(insn 274 273 172 14 (set (reg:DD 31 31)
(mem/c:DD (plus:SI (reg/f:SI 1 1)
(const_int 32 [0x20])) [0 S8 A64]))
powerpc64-linux/32/libstdc++-v3/include/decimal/decimal.h:298 445
{*movdd_hardfloat32}
(nil))
../libstdc++-v3/testsuite/decimal/pr54036-1.cc:71:1: internal compiler error:
in reload_cse_simplify_operands, at postreload.c:411
0x1061c50b _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:109
0x1061c55f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.c:120
0x105c7e23 reload_cse_simplify_operands
../../gcc/postreload.c:411
0x105c9f53 reload_cse_simplify
../../gcc/postreload.c:181
0x105c9f53 reload_cse_regs_1
../../gcc/postreload.c:220
0x105ca537 reload_cse_regs
../../gcc/postreload.c:68
0x105ca537 rest_of_handle_postreload
../../gcc/postreload.c:2332
0x105ca537 execute
../../gcc/postreload.c:2368
[Bug target/60032] [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug middle-end/60013] [4.9 Regression] Build of 176.gcc from CPU2000 loops in cc1 starting with r207231
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00035.html
[Bug c++/60033] New: gcc 4.9.0 20140107: ICE in retrieve_specialization while compiling recursive generic lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60033
Bug ID: 60033
Summary: gcc 4.9.0 20140107: ICE in retrieve_specialization
while compiling recursive generic lambda
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vock at cs dot uni-bonn.de
Created attachment 32016
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32016action=edit
Preprocessed output file
I got an ICE while compiling the following minimal code example (.ii is
attached):
//#include iostream
#include utility
template typename... Funcs
struct composer;
template typename Func
struct composerFunc {
auto operator()(Func f) {
return f;
}
};
template typename Func, typename... Funcs
struct composerFunc, Funcs... {
auto operator()(Func f, Funcs... fs) {
composerFuncs... c;
return [] (auto v) {
return f(composerFuncs...()(std::forwardFuncs(fs)...)(v));
};
}
};
template typename... Funcs
auto compose(Funcs... fs) {
return composerFuncs...()(std::forwardFuncs(fs)...);
}
int main (int argc, char const* argv[]) {
float v = 3.5f;
auto func = [] (auto v) { return int(v-0.5); };
auto t = compose([] (auto v) { return v = 3; }, func)(v);
//std::cout std::boolalpha t \n;
auto f = compose([] (auto v) { return v 3; }, func)(v);
//std::cout std::boolalpha f \n;
}
Compiler output is:
g++-4.9 -std=c++1y -save-temps -Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations main.cpp
main.cpp: In instantiation of ‘composerFunc, Funcs ...::operator()(Func,
Funcs ...)::lambda(auto:2) [with auto:2 = float; Func = main(int, const
char**)::lambda(auto:3); Funcs = {main(int, const
char**)::lambda(auto:4)}]’:
main.cpp:33:88: required from here
main.cpp:19:41: internal compiler error: in retrieve_specialization, at
cp/pt.c:1042
return f(c(std::forwardFuncs(fs)...)(v));
^
0x59c47f retrieve_specialization
./src/gcc/gcc/cp/pt.c:1039
0x5a470c tsubst_pack_expansion
./src/gcc/gcc/cp/pt.c:9563
0x59f404 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
./src/gcc/gcc/cp/pt.c:14461
0x59fa18 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
./src/gcc/gcc/cp/pt.c:14443
0x59f3a0 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
./src/gcc/gcc/cp/pt.c:14456
0x5a31ce tsubst_expr
./src/gcc/gcc/cp/pt.c:13788
0x5a31a4 tsubst_expr
./src/gcc/gcc/cp/pt.c:13205
0x5a316f tsubst_expr
./src/gcc/gcc/cp/pt.c:13400
0x5a2e34 tsubst_expr
./src/gcc/gcc/cp/pt.c:13195
0x5a316f tsubst_expr
./src/gcc/gcc/cp/pt.c:13400
0x5a2038 instantiate_decl(tree_node*, int, bool)
./src/gcc/gcc/cp/pt.c:19656
0x5cfbb9 mark_used(tree_node*, int)
./src/gcc/gcc/cp/decl2.c:4701
0x57760b build_over_call
./src/gcc/gcc/cp/call.c:7127
0x57a301 build_op_call_1
./src/gcc/gcc/cp/call.c:4161
0x57a301 build_op_call(tree_node*, vectree_node*, va_gc, vl_embed**, int)
./src/gcc/gcc/cp/call.c:4184
0x636cf8 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool,
bool, int)
./src/gcc/gcc/cp/semantics.c:2298
0x5ec24b cp_parser_postfix_expression
./src/gcc/gcc/cp/parser.c:6165
0x5ee8b8 cp_parser_unary_expression
./src/gcc/gcc/cp/parser.c:7171
0x5ef48f cp_parser_binary_expression
./src/gcc/gcc/cp/parser.c:7875
0x5ef951 cp_parser_assignment_expression
./src/gcc/gcc/cp/parser.c:8113
A running version compiled using clang++ 3.5 is here:
http://coliru.stacked-crooked.com/a/acc691b9a407d6f2
System:
Arch Linux
Linux xxx 3.12.6-1-ARCH #1 SMP PREEMPT Fri Dec 20 19:39:00 CET 2013 x86_64
GNU/Linux
Build Command:
g++-4.9 -std=c++1y -save-temps -Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations main.cpp
Version:
Using built-in specs.
COLLECT_GCC=g++-4.9
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share/gcc-4.9
--with-bugurl='http://aur.archlinux.org/packages.php?ID=16045'
--enable-languages=c,c++,lto --enable-shared --enable-threads=posix
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object
--enable-linker-build-id --enable-cloog-backend=isl
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--disable-install-libiberty --disable-multilib --disable-libssp
--disable-werror --enable-checking=release --program-suffix=-4.9
--enable-version-specific-runtime-libs
[Bug c++/60033] gcc 4.9.0 20140107: ICE in retrieve_specialization while compiling recursive generic lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60033 --- Comment #1 from Richard Vock vock at cs dot uni-bonn.de --- I know I left a redundant composerFuncs... c; line in there. Just ignore that...
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 --- Comment #11 from fabien at gcc dot gnu.org --- Author: fabien Date: Sun Feb 2 19:58:06 2014 New Revision: 207407 URL: http://gcc.gnu.org/viewcvs?rev=207407root=gccview=rev Log: 2014-02-02 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * parser.c (cp_parser_nonclass_name): Call strip_using_decl and move the code handling dependent USING_DECLs... * name-lookup.c (strip_using_decl): ...Here. 2014-02-02 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * g++.dg/template/using27.C: New. * g++.dg/template/using28.C: New. * g++.dg/template/using29.C: New. Modified: trunk/gcc/cp/name-lookup.c
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 --- Comment #12 from fabien at gcc dot gnu.org --- Author: fabien Date: Sun Feb 2 20:02:37 2014 New Revision: 207408 URL: http://gcc.gnu.org/viewcvs?rev=207408root=gccview=rev Log: 2014-02-02 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * parser.c (cp_parser_nonclass_name): Call strip_using_decl and move the code handling dependent USING_DECLs... * name-lookup.c (strip_using_decl): ...Here. 2014-02-02 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * g++.dg/template/using27.C: New. * g++.dg/template/using28.C: New. * g++.dg/template/using29.C: New. Added: trunk/gcc/testsuite/g++.dg/template/using27.C trunk/gcc/testsuite/g++.dg/template/using28.C trunk/gcc/testsuite/g++.dg/template/using29.C Modified: trunk/gcc/cp/parser.c
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from fabien at gcc dot gnu.org --- Fixed in 4.9. I will backport it to 4.8 and 4.7 if everething goes well.
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 fabien at gcc dot gnu.org changed: What|Removed |Added CC||roshan.shariff at gmail dot com --- Comment #14 from fabien at gcc dot gnu.org --- *** Bug 58047 has been marked as a duplicate of this bug. ***
[Bug c++/58047] parse error with typedef introduced from base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from fabien at gcc dot gnu.org --- marked as duplicate *** This bug has been marked as a duplicate of bug 37140 ***
[Bug fortran/57019] [4.7/4.8/4.9 Regression] Compiler crashes (and make wrong assignments) at some combinations of pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57019 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #6 from Paul Thomas pault at gcc dot gnu.org --- I have spent an hour or so looking at this one. I think that I can see how to fix it. The problem is that expr.c(is_subref_array) is triggering the use of pointer arithmetic, using the hidden .span variable, when it should not. The expressions below work fine with array indices. I just have to sit down and figure out a consistent logic. Something for next weekend! Cheers Paul
[Bug target/60034] New: invalid expression as operand in aarch64 inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60034 Bug ID: 60034 Summary: invalid expression as operand in aarch64 inline asm Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kuganv at linaro dot org Created attachment 32017 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32017action=edit pre processed source This issue is originally reported in https://bugs.launchpad.net/gcc-linaro/+bug/1270789 The attached pre-processed source fails with: # aarch64-linux-gnu-gcc -std=gnu99 -fgnu89-inline -O -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wstrict-prototypes malloc.i malloc.c: In function ‘__libc_mallopt’: malloc.c:4761:16: error: invalid 'asm': invalid expression as operand Splitting this inline asm out into a smaller testcase does not seem to reproduce the issue. It's possible this is a bug in the source file, but it's not clear from gcc's output what the problem is. Seems to be an issue with alignment calculation in aarch64_classify_address. for rtl of the form (lo_sum:DI (reg/f:DI 132) (symbol_ref:DI (*.LANCHOR4) [flags 0x182])) we are currently calculating align of 8bits and due to this the following statement returns false. This causes output_addr_const (in gcc/final.c) to fail. return ((INTVAL (offs) (ref_size - 1)) == 0 ((align / BITS_PER_UNIT) (ref_size - 1)) == 0); AFIK, align of 8bits is not correct here. GCC version and config: arm-none-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=/home/kugan/work/builds/gcc-fsf-trunk/tools/bin/arm-none-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/home/kugan/work/builds/gcc-fsf-trunk/tools/libexec/gcc/arm-none-linux-gnueabi/4.9.0/lto-wrapper Target: arm-none-linux-gnueabi Configured with: /home/kugan/work/sources/gcc-fsf/trunk/configure --target=arm-none-linux-gnueabi --prefix=/home/kugan/work/builds/gcc-fsf-trunk/tools --with-sysroot=/home/kugan/work/builds/gcc-fsf-trunk/sysroot-arm-none-linux-gnueabi --disable-libssp --disable-libgomp --disable-libmudflap --enable-languages=c,c++ --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp --with-thumb Thread model: posix gcc version 4.9.0 20130922 (experimental) (GCC)
[Bug target/60034] invalid expression as operand in aarch64 inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60034 --- Comment #1 from Kugan kuganv at linaro dot org --- Created attachment 32018 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32018action=edit Proposed patch
[Bug c++/43407] Specifying visibility attribute of C++0x enum class emits warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43407 Jobst.Ziebell at mailbox dot tu-dresden.de changed: What|Removed |Added CC||Jobst.Ziebell at mailbox dot tu-dr ||esden.de --- Comment #2 from Jobst.Ziebell at mailbox dot tu-dresden.de --- This bug is still present as of 4.8.2... (on x86_64-apple-darwin13.0.0)
[Bug target/60034] invalid expression as operand in aarch64 inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60034 Kugan kuganv at linaro dot org changed: What|Removed |Added CC||kuganv at linaro dot org --- Comment #2 from Kugan kuganv at linaro dot org --- I am sorry that I entered wrong gcc -v (cut and paste error). It is an aarch64 issue and the correct gcc -v is below: aarch64-none-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/home/kugan/work/builds/gcc-fsf-trunk/tools/bin/aarch64-none-linux-gnu-gcc COLLECT_LTO_WRAPPER=/home/kugan/work/builds/gcc-fsf-trunk/tools/libexec/gcc/aarch64-none-linux-gnu/4.9.0/lto-wrapper Target: aarch64-none-linux-gnu Configured with: /home/kugan/work/sources/gcc-fsf/trunk/configure --target=aarch64-none-linux-gnu --prefix=/home/kugan/work/builds/gcc-fsf-trunk/tools --without-headers --with-newlib --disable-shared --disable-threads --disable-libssp --disable-libgomp --disable-libmudflap --disable-libatomic --without-libquadmath --disable-libquadmath --enable-languages=c Thread model: single gcc version 4.9.0 20130922 (experimental) (GCC)
[Bug libgomp/60035] New: [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035 Bug ID: 60035 Summary: [PATCH] make it possible to use OMP on both sides of a fork (without violating standard) Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: njs at pobox dot com CC: jakub at gcc dot gnu.org Created attachment 32019 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32019action=edit patch to make openmp - quiesce - fork - openmp work This is a re-open of #52303 and #58378, with more arguments, and a proposed patch that fixes the problem without violating the openmp standard. Background: Almost all scientific/numerical code delegates linear algebra operations to some optimized BLAS library. Currently, the main contenders for this library are: 1) ATLAS: free software, but uses extensive build-time configuration, which means it must be re-compiled from source by every user to achieve competitive performance. 2) MKL: proprietary, but technically excellent. 3) OpenBLAS: free software, but uses OpenMP for threading, which means that any program which does linear algebra and also expects fork() to work is screwed [1], at least when using GCC. This means that for projects like numpy, which are used in a very large range of downstream products, we are pretty much screwed too. Many of our users use fork(), for various good reasons that I can elaborate if desired, so we can't just recommend OpenBLAS in general -- ATLAS or MKL are superior for . But recompiling ATLAS is difficult, so we can't recommend that as a general solution, or provide it in pre-compiled downloads. So what we end up doing is shipping slow, unoptimized BLAS, while all the major scientific python distros ship MKL; and we also get constantly pressured by users to either ship binaries with MKL or with OpenBLAS built with icc; and we field a new bug report every week or two from people who use OpenBLAS without realizing it and are experiencing mysterious hangs. (Or sometimes other projects get caught in the crossfire, e.g. [2] which is someone trying to figure out why their web-app can't generate plot graphics when using the celery job queue manager.) Meanwhile people are waiting with bated breath for clang to get an openmp implementation so that they can shift their whole stack over there, solely because of this one bug. Basically the current situation is causing ongoing pain for a wide range of people and makes free software uncompetitive with proprietary software for scientific code using Python in general. But it doesn't have to be this way! In actual practice on real implementations -- regardless of what POSIX says -- it's perfectly safe to use arbitrary POSIX APIs after fork, so long as all threads are in a known, quiescent state when the fork occurs. The attached patch has essentially no impact on compliant OpenMP-using programs; in particular, and unlike the patch in #58378, it has no affect on the behavior of the parent process, and in the child process it does nothing that violates POSIX unless the user has violated POSIX first. But it makes it safe in practice to use OpenMP encapsulated within a serial library API, without mysterious breakage depending on far away parts of the program, and in particular should fix the OpenBLAS issue. Test case included in patch is by Olivier Grisel, from #58378. Patch is against current gcc svn trunk (r206297). [1] https://github.com/xianyi/OpenBLAS/issues/294 [2] https://github.com/celery/celery/issues/1842
[Bug target/60034] invalid expression as operand in aarch64 inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60034
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Host|x86_64-unknown-linux-gnu|
Build|x86_64-unknown-linux-gnu|
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org ---
Here is a reduced testcase:
static unsigned long global_max_fast;
int __libc_mallopt (int param_number, int value)
{
__asm__ __volatile__ (# %[_SDT_A2] :: [_SDT_A2] nor ((global_max_fast)));
global_max_fast = 1;
}
[Bug c/60036] New: Spurious signedness conversion warning with relational operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60036
Bug ID: 60036
Summary: Spurious signedness conversion warning with relational
operator
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
Gcc-trunk emits a signedness conversion warning for the statement f ^= fn1()
a;. However, as the value of fn1() a is either 1 or 0, the warning is not
true.
Moreover, Gcc-4.8 and 4.7 do not output this warning. And if I change the
statement to f = f ^ (fn1() a);, gcc-trunk does not emit this warning,
either.
$: cat conversion-for-boolean.c
extern int fn1();
unsigned fn(int a) {
unsigned f = 9;
f ^= fn1() a;
return f;
}
$: gcc-trunk -c -Wconversion -std=c11 conversion-for-boolean.c
conversion-for-boolean.c: In function ‘fn’:
conversion-for-boolean.c:4:5: warning: conversion to ‘unsigned int’ from ‘int’
may change the sign of the result [-Wsign-conversion]
f ^= fn1() a;
^
$: gcc-4.8 -c -Wconversion -std=c11 conversion-for-boolean.c
$: gcc-4.7 -c -Wconversion -std=c11 conversion-for-boolean.c
$: gcc-trunk --version
gcc-trunk (GCC) 4.9.0 20140131 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug target/58854] [4.8 regression] sub sp, fp, #40 hoisted above frame accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 Alexa alexa.gerancho at hushmail dot com changed: What|Removed |Added CC||alexa.gerancho at hushmail dot com --- Comment #13 from Alexa alexa.gerancho at hushmail dot com --- *** Bug 260998 has been marked as a duplicate of this bug. *** Seen live from the domain http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.
[Bug libstdc++/60037] New: SIGFPE in std::generate_canonicalunsigned int...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037
Bug ID: 60037
Summary: SIGFPE in std::generate_canonicalunsigned int...
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
When
libstdc++-v3/testsuite/ext/random/hypergeometric_distribution/operators/values.cc
is built with -O0, I get a crash:
Program received signal SIGFPE, Arithmetic exception.
0x00401b07 in std::generate_canonicalunsigned int, 32ul,
std::mersenne_twister_engineunsigned long, 32ul, 624ul, 397ul, 31ul,
2567483615ul, 11ul, 4294967295ul, 7ul, 2636928640ul, 15ul, 4022730752ul, 18ul,
1812433253ul (__urng=...)
at
/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3480
3480 return __sum / __tmp;
(gdb) bt
#0 0x00401b07 in std::generate_canonicalunsigned int, 32ul,
std::mersenne_twister_engineunsigned long, 32ul, 624ul, 397ul, 31ul,
2567483615ul, 11ul, 4294967295ul, 7ul, 2636928640ul, 15ul, 4022730752ul, 18ul,
1812433253ul (__urng=...)
at
/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3480
#1 0x004018d9 in
std::__detail::_Adaptorstd::mersenne_twister_engineunsigned long, 32ul,
624ul, 397ul, 31ul, 2567483615ul, 11ul, 4294967295ul, 7ul, 2636928640ul, 15ul,
4022730752ul, 18ul, 1812433253ul, unsigned int::operator()
(this=0x7fff9020)
at /build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:190
#2 0x00401785 in __gnu_cxx::hypergeometric_distributionunsigned
int::operator()std::mersenne_twister_engineunsigned long, 32ul, 624ul,
397ul, 31ul, 2567483615ul, 11ul, 4294967295ul, 7ul, 2636928640ul, 15ul,
4022730752ul, 18ul, 1812433253ul (
this=0x7fffab40, __urng=..., __param=...) at
/gcc-svn/libstdc++-v3/include/ext/random.tcc:1328
#3 0x004016fb in __gnu_cxx::hypergeometric_distributionunsigned
int::operator()std::mersenne_twister_engineunsigned long, 32ul, 624ul,
397ul, 31ul, 2567483615ul, 11ul, 4294967295ul, 7ul, 2636928640ul, 15ul,
4022730752ul, 18ul, 1812433253ul (
this=0x7fffab40, __urng=...) at
/gcc-svn/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/random:3016
#4 0x00401642 in
std::_Bind__gnu_cxx::hypergeometric_distributionunsigned int
(std::mersenne_twister_engineunsigned long, 32ul, 624ul, 397ul, 31ul,
2567483615ul, 11ul, 4294967295ul, 7ul, 2636928640ul, 15ul, 4022730752ul, 18ul,
1812433253ul)::__callunsigned int, , 0ul(std::tuple,
std::_Index_tuple0ul) (this=0x7fffab40, __args=unknown type in
/gcc-svn/build/x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/./values.exe, CU
0x0, DIE 0x445d)
at
/gcc-svn/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/functional:1264
#5 0x00401578 in
std::_Bind__gnu_cxx::hypergeometric_distributionunsigned int
(std::mersenne_twister_engineunsigned long, 32ul, 624ul, 397ul, 31ul,
2567483615ul, 11ul, 4294967295ul, 7ul, 2636928640ul, 15ul, 4022730752ul, 18ul,
1812433253ul)::operator(), unsigned int() (this=0x7fffab40) at
/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/functional:1323
#6 0x00400d4c in __gnu_test::testDiscreteDist100ul, 10ul,
std::_Bind__gnu_cxx::hypergeometric_distribution(std::mersenne_twister_enginelong
unsigned int, 32ul, 624ul, 397ul, 31ul, 2567483615ul, 11ul, 4294967295ul, 7ul,
2636928640ul, 15ul, 4022730752ul, 18ul, 1812433253ul),
test01()::lambda(int)
(std::_Bind__gnu_cxx::hypergeometric_distributionunsigned
int(std::mersenne_twister_enginelong unsigned int, 32ul, 624ul, 397ul, 31ul,
2567483615ul, 11ul, 4294967295ul, 7ul, 2636928640ul, 15ul, 4022730752ul, 18ul,
1812433253ul) , lambda(int)) (f=..., pdf=...) at
/gcc-svn/libstdc++-v3/testsuite/util/testsuite_random.h:50
#7 0x00400aa9 in test01 () at
/gcc-svn/libstdc++-v3/testsuite/ext/random/hypergeometric_distribution/operators/values.cc:42
#8 0x00400b72 in main () at
/gcc-svn/libstdc++-v3/testsuite/ext/random/hypergeometric_distribution/operators/values.cc:58
AFAICT, this is happening because:
3461 templatetypename _RealType, size_t __bits,
3462 typename _UniformRandomNumberGenerator
3463_RealType
3464generate_canonical(_UniformRandomNumberGenerator __urng)
3465{
3466 const size_t __b
3467=
std::min(static_castsize_t(std::numeric_limits_RealType::digits),
3468 __bits);
3469 const long double __r = static_castlong double(__urng.max())
3470- static_castlong double(__urng.min()) + 1.0L;
3471 const size_t __log2r = std::log(__r) / std::log(2.0L);
3472 size_t __k = std::maxsize_t(1UL, (__b + __log2r - 1UL) /
__log2r);
3473 _RealType __sum = _RealType(0);
3474 _RealType __tmp = _RealType(1);
3475 for (; __k != 0; --__k)
3476{
3477 __sum
[Bug libstdc++/60037] SIGFPE in std::generate_canonicalunsigned int...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037 --- Comment #1 from ppluzhnikov at gcc dot gnu.org --- Author: ppluzhnikov Date: Mon Feb 3 06:48:48 2014 New Revision: 207416 URL: http://gcc.gnu.org/viewcvs?rev=207416root=gccview=rev Log: xfail ext/random/hypergeometric_distribution/operators/values.cc due to PR 60037: SIGFPE when the test is built without optimization. Modified: branches/google/main/contrib/testsuite-management/x86_64-grtev4-linux-gnu.xfail
[Bug libstdc++/60020] Considering backport regexp support to 4.8+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60020 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- No.
[Bug libstdc++/57350] std::align missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Vladimir Krivopalov from comment #3) Any chance to get std::align() implementation included in the coming GCC releases? What needs to be done for that? It's too late for GCC 4.9 now.
[Bug sanitizer/60038] New: AddressSanitizer CHECK failed ... ((*tls_addr + *tls_size)) = ((*stk_addr + *stk_size)) on CentOS 5.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60038 Bug ID: 60038 Summary: AddressSanitizer CHECK failed ... ((*tls_addr + *tls_size)) = ((*stk_addr + *stk_size)) on CentOS 5.10 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak 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: x86_64-linux-gnu Many tests in address sanitizer testsuite fail on CentOS 5.10, on x86_64 64bit target: FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_PthreadExitTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadedStressStackReuseTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadNamesTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadedTest ThreadedTestSpawn() output pattern test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadStackReuseTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ManyThreadsTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadedMallocStressTest execution test FAIL: g++.dg/asan/deep-thread-stack-1.C -O0 output pattern test, is ==28946==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsaniti zer/sanitizer_common/sanitizer_linux_libcdep.cc:260 ((*tls_addr + *tls_size)) = ((*stk_addr + *stk_size)) (0x2ba95e3ff240, 0x2ba95e3ff000) FAIL: g++.dg/asan/deep-thread-stack-1.C -O1 output pattern test, is ==28972==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsaniti zer/sanitizer_common/sanitizer_linux_libcdep.cc:260 ((*tls_addr + *tls_size)) = ((*stk_addr + *stk_size)) (0x2b904ae5e240, 0x2b904ae5e000) FAIL: g++.dg/asan/deep-thread-stack-1.C -O2 output pattern test, is ==28990==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsaniti zer/sanitizer_common/sanitizer_linux_libcdep.cc:260 ((*tls_addr + *tls_size)) = ((*stk_addr + *stk_size)) (0x2b7261726240, 0x2b7261726000) FAIL: g++.dg/asan/deep-thread-stack-1.C -O3 -fomit-frame-pointer output pattern test, is ==29015==AddressSanitizer CHECK failed: ../../../../gc c-svn/trunk/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:260 ((*tls_addr + *tls_size)) = ((*stk_addr + *stk_size)) (0x2b7f30b2f240 , 0x2b7f30b2f000) FAIL: g++.dg/asan/deep-thread-stack-1.C -O3 -g output pattern test, is ==29038==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsan itizer/sanitizer_common/sanitizer_linux_libcdep.cc:260 ((*tls_addr + *tls_size)) = ((*stk_addr + *stk_size)) (0x2ae7a3e97240, 0x2ae7a3e97000) FAIL: g++.dg/asan/deep-thread-stack-1.C -Os output pattern test, is ==29078==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsaniti zer/sanitizer_common/sanitizer_linux_libcdep.cc:260 ((*tls_addr + *tls_size)) = ((*stk_addr + *stk_size)) (0x2b8e40e38240, 0x2b8e40e38000) FAIL: g++.dg/asan/deep-thread-stack-1.C -O2 -flto -flto-partition=none output pattern test, is ==29134==AddressSanitizer CHECK failed: ../../.. /../gcc-svn/trunk/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:260 ((*tls_addr + *tls_size)) = ((*stk_addr + *stk_size)) (0x2b1d04 5f7240, 0x2b1d045f7000) FAIL: g++.dg/asan/deep-thread-stack-1.C -O2 -flto output pattern test, is ==29196==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/lib sanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:260 ((*tls_addr + *tls_size)) = ((*stk_addr + *stk_size)) (0x2b99bff03240, 0x2b99bff0300 0) All these fail on the same check, in the same way. The same tests also fail on i686 32bit targets, with different addresses, e.g.: FAIL: g++.dg/asan/deep-thread-stack-1.C -O0 output pattern test, is ==2673==AddressSanitizer CHECK failed: ../../../../../gcc-svn/trunk/libsani tizer/sanitizer_common/sanitizer_linux_libcdep.cc:260 ((*tls_addr + *tls_size)) = ((*stk_addr + *stk_size)) (0xf6592020, 0xf6592000)
