[Bug c++/66533] [C++14] ICE: in dependent_type_p, at cp/pt.c:21073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66533 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 6 16:33:14 2015 New Revision: 226684 URL: https://gcc.gnu.org/viewcvs?rev=226684root=gccview=rev Log: PR c++/66533 * parser.c (cp_parser_primary_expression): Don't skip to the end of the statement if we're parsing tentatively. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-ice3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/66533] [C++14] ICE: in dependent_type_p, at cp/pt.c:21073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66533 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 6 16:36:58 2015 New Revision: 226685 URL: https://gcc.gnu.org/viewcvs?rev=226685root=gccview=rev Log: PR c++/66533 * parser.c (cp_parser_primary_expression): Don't skip to the end of the statement if we're parsing tentatively. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-ice3.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/parser.c
[Bug fortran/67140] New: undefined reference to _gfortran_mvbits_i16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67140 Bug ID: 67140 Summary: undefined reference to _gfortran_mvbits_i16 Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: eskei.one at gmail dot com Target Milestone: --- Created attachment 36143 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36143action=edit example that reproduces error in title I've been using bit manipulation of long integers in ISO_C_BINDING (IBSET, IBCLR, BTEST, IBITS) for a while now. Today I tried to do MVBITS between two C_INT128_T and got the error in the title. I am attaching an example program.
[Bug rtl-optimization/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67124 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Keywords||ra CC||vmakarov at gcc dot gnu.org Component|middle-end |rtl-optimization --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to rsand...@gcc.gnu.org from comment #6) The expand code looks OK to me. Assigning to one DImode word of a TImode isn't supposed to change the other half. I think the problem is in LRA. It tries to reload the low half of the TImode as follows: Thanks for your analysis! Reconfirmed as RA problem, adding another CC.
[Bug target/56309] conditional moves instead of compare and branch result in almost 2x slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56309 --- Comment #34 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 36138 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36138action=edit simple reproducer Use -O3 -std=c++14 options to compile and -fno-tree-loop-if-convert to get better performance
[Bug fortran/67123] ICE with source allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67123 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from vehre at gcc dot gnu.org --- I can confirm that this is a duplicate of 66927. The code in the description nevertheless needs a tweak in the allocate to read: allocate( as(0:0), ... to allocate an array of size 1, but with bounds 0..0. Using as(0) allocates an array of size 0 with bound 1..0, which then is the next bug that is not fixed by pr66927. Therefore I did not mark this bug as duplicate, but as depends on, because without the fix for 66927 the next bug does not show.
[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381 Martin Husemann martin at netbsd dot org changed: What|Removed |Added Version|4.8.1 |5.2.0 --- Comment #3 from Martin Husemann martin at netbsd dot org --- This still applies to recent versions and is an obvious fix. Please apply!
[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896 --- Comment #14 from Martin Liška marxin at gcc dot gnu.org --- (In reply to Vittorio Zecca from comment #13) I see only two NULL dereferencing in ipa-prop.c my lines 2479 and 2545 same statement dst_ctx-combine_with (ctx); Did you take care of both of them? Hi. Both cases are fixed on both trunk and gcc-5 branch in function update_jump_functions_after_inlining. Thanks, Martin
[Bug fortran/64022] [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64022 --- Comment #9 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Thu Aug 6 08:38:59 2015 New Revision: 226665 URL: https://gcc.gnu.org/viewcvs?rev=226665root=gccview=rev Log: PR fortran/64022 * gfortran.dg/ieee/large_1.f90: Adjust test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/ieee/large_1.f90
[Bug c/67134] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67134 Bug ID: 67134 Summary: internal compiler error: Segmentation fault Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: momchil.uzunov at gmail dot com Target Milestone: --- I use: mips-sde-elf-gcc (Sourcery CodeBench Lite 2013.05-35) 4.7.3 compiler. When I compile my project I receive the error: printer.c:1490:1: internal compiler error: Segmentation fault There is nothing special at printer.c:1490:1. The problem i in another file fragment: ... #define INFO_IFM_HW_VER 29 #define INFO_IFM_FW_VER 30 #define INFO_HW_CAPABILITIES31 #define INFO_DATA_FLASH_ADDRES 32 #define PARAM_SAVE_TO_FLASH 0 #define PARAM_APPLICATION_ID1 ... When I add an empty line or change the name: INFO_DATA_FLASH_ADDRES it WORK! worked example: ... #define INFO_IFM_HW_VER 29 #define INFO_IFM_FW_VER 30 #define INFO_HW_CAPABILITIES31 #define INFO_DATA_FLASH_ADDRES 32 #define PARAM_SAVE_TO_FLASH 0 #define PARAM_APPLICATION_ID1 ... I can give my source code but I thin this describe the type of the problem.
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #5) Well, it is a 5MB testcase and reducing isn't instantaneous unfortunately. No problem, I'm not in a hurry. I need to bootstrap gcc and that will take me a whole day at least.
[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66927 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org --- Comment #7 from vehre at gcc dot gnu.org --- Currently checking whether the bug can be fixed more elegantly.
[Bug target/67129] x86: erratic parsing of #pragma GCC target (...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67129
--- Comment #3 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Sorry, the expample with t2() in the code snippet above should have the pragmas
in the opposite order:
-- snip --
#pragma GCC target (no-sse)
#pragma GCC target (fpmath=sse)
void t2(void) { }
-- snip --
The attached files ar all right, though.
[Bug target/67129] x86: erratic parsing of #pragma GCC target (...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67129 --- Comment #2 from Dominik Vogt vogt at linux dot vnet.ibm.com --- Created attachment 36136 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36136action=edit warning Code that produces the warning.
[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #15 from Andreas Krebbel krebbel at gcc dot gnu.org --- Closing. Fixed in Glibc.
[Bug fortran/64022] [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64022 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Version|5.0 |6.0 Resolution|--- |FIXED --- Comment #11 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Fixed on trunk.
[Bug libgomp/67141] New: wrong libgomp mutex initialisation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67141 Bug ID: 67141 Summary: wrong libgomp mutex initialisation order Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: mattiase at acm dot org CC: jakub at gcc dot gnu.org Target Milestone: --- Libgomp may use a mutex, acc_device_lock, prior to initialising it depending on the constructor calling order: it is initialised in initialize_env and used in goacc_host_init, both declared __attribute__ ((constructor)) but in different files. This was discovered on Windows after a change to the pthread library in mingw-w64, making all-zero an invalid mutex value. Apparently the constructors were called in the wrong order, and pthread_mutex_lock called before pthread_mutex_init.
[Bug c++/66937] Do not compare constraints for unconstrained template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66937 --- Comment #3 from Roland B rbock at eudoxos dot de --- (In reply to Jason Merrill from comment #1) Author: jason Date: Thu Aug 6 17:42:25 2015 New Revision: 226687 URL: https://gcc.gnu.org/viewcvs?rev=226687root=gccview=rev Log: PR c++/66937 * pt.c (is_compatible_template_arg): A template template parameter with unconstrained parameters can match an argument with constrained parameters. Added: branches/c++-concepts/gcc/testsuite/g++.dg/concepts/template-template-parm1.C Thanks for the commit. Works fine for me! In the test file (template-template-parm1.C) I guess you should edit the comment in the last line a bit. ``` // This fails, but should not ``` Not true anymore, since it compiles just fine :-) Thanks again, Roland
[Bug c++/67138] [concepts] bogus not more constrained error for more constrained partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67138 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Fixed by r226711.
[Bug c++/66937] Do not compare constraints for unconstrained template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66937 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Applied the proposed solution for now.
[Bug c++/67139] [concepts] ICE on checking concepts with void with variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67139 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- This seems to be fixed now.
[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #22 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #21) Yes, it works. I'm uncomfortable with it because the current use of crtl-emit.x_cur_insn_uid aka cur_insn_uid is limitted to emit-rtl.c. I think that the use of that field outside of emit-rtl.c is unexpected. Also it doesn't sound good to add a new interface to access that field there. After all, your static rtx_insn is the right thing to do. OK. I will try to implement that static rtx_insn thing, after I have finished the patch attachment 36012, which makes some changes to treg_set_expr.
[Bug libfortran/67140] undefined reference to _gfortran_mvbits_i16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67140 --- Comment #2 from kargl at gcc dot gnu.org --- Created attachment 36144 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36144action=edit patch Patched built and tested with OP's code. Regression test passed.
[Bug fortran/67140] undefined reference to _gfortran_mvbits_i16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67140 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-06 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.8.5, 4.9.4, 5.2.1, 6.0 --- Comment #1 from kargl at gcc dot gnu.org --- I have a patch. Don't know if it actaully works as your test program has no output and no indication of the expected result.
[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #21 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #20) Yes, that looks OK. treg_set_expr-something recog matching is actually only required during combine. The simpler forms like (reg:SI T_REG) could also be required during expansion. Thanks. I'll commit it when the usual test is done. Hm ... actually it should work. The temporary rtx insn is not used for anything else, so that assigned insn uid will never appear anywhere. However, it's probably better to have one static rtx_insn to avoid constructing the temporary rtx over and over again. Unfortunately the gen_rtx* functions allocate rtx objects always on the GC heap. Yes, it works. I'm uncomfortable with it because the current use of crtl-emit.x_cur_insn_uid aka cur_insn_uid is limitted to emit-rtl.c. I think that the use of that field outside of emit-rtl.c is unexpected. Also it doesn't sound good to add a new interface to access that field there. After all, your static rtx_insn is the right thing to do.
[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896 --- Comment #13 from Vittorio Zecca zeccav at gmail dot com --- I see only two NULL dereferencing in ipa-prop.c my lines 2479 and 2545 same statement dst_ctx-combine_with (ctx); Did you take care of both of them?
[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||krebbel at gcc dot gnu.org Resolution|--- |FIXED --- Comment #14 from Andreas Krebbel krebbel at gcc dot gnu.org --- Fixed in Glibc per comment #12.
[Bug ipa/66363] ICE in modified test inline-39.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66363 Dominik Vogt vogt at linux dot vnet.ibm.com changed: What|Removed |Added Component|target |ipa --- Comment #2 from Dominik Vogt vogt at linux dot vnet.ibm.com --- This also happens on x86_64.
[Bug target/67129] New: x86: erratic parsing of #pragma GCC target (...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67129
Bug ID: 67129
Summary: x86: erratic parsing of #pragma GCC target (...)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
Target Milestone: ---
There's a bug in the way the GCC target pragma is translated into the
target attribute on x86, and probably also on (all?) other platforms that
base their implementation of the GCC target pragma and the target attribute
on the code in i386.c and i386-c.c:
According to the documentation, the last occurence of #pragma GCC target
(...) should always replace all previous occurences, and this is indeed what
happens. On a machine with sse support, this code compiles just fine:
-- snip --
#pragma GCC target (fpmath=sse)
#pragma GCC target (no-sse)
void t1(void) { }
-- snip --
$ gcc -S t1.c
(ok)
The no-sse option wins, fpmath=sse is not used at all.
However, *sometimes* during processing of the #pragma, the value of the old
#pragma is used for checking validity of the new #pragma:
-- snip --
#pragma GCC target (fpmath=sse)
#pragma GCC target (no-sse)
void t2(void) { }
-- snip --
$ gcc -S t2.c
/t2.c:2:9: warning: SSE instruction set disabled, using 387 arithmetics
[enabled by default]
t2.c:3:1: warning: SSE instruction set disabled, using 387 arithmetics [enabled
by default]
t2.c:3:1: warning: SSE instruction set disabled, using 387 arithmetics [enabled
by default]
Since this is only a warning, compilation continues, and eventually the old
value gets discarded without causing any harm. However, if there is a
combination of options that causes an error, gcc will fail to compile valid
code.
--
There is a bug in the implementation of i386-c.c:ix86_pragma_target_parse().
As far as I understand, when a #pragma GCC target (...) is processed:
1. Use global_options as the target options structure.
2. Add the options defined in the string.
3. Check if the resulting options are valid.
The last step fails when the secons #pragma is parsed. Then, when a function
definition begins:
4. Look up the most recent target pragma definition and the function's target
attribute and, if present, parse their strings in order.
So, for functions everything is fine, but any definitions between the last
#pragma and the next function definition is affected by the union of all
#pragmas (after the last reset).
Now, don't ask me why the warning in the example above is affected by the order
of the two pragmas. I think to fix this, the function in i386-c.c should:
1. Make a working copy of the original global_options and global_options_set
(the values that were affected only by command line options). No idea how to
get the original values at that point in the code.
2. Call ix86_valid_target_attribute_tree() with that copy.
3. If the result is calid, overwrite global_options with the modified values in
the copy.
[Bug target/67129] x86: erratic parsing of #pragma GCC target (...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67129 --- Comment #1 from Dominik Vogt vogt at linux dot vnet.ibm.com --- Created attachment 36135 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36135action=edit no warning Code that does not produce the warning.
[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303 --- Comment #13 from Dominik Vogt vogt at linux dot vnet.ibm.com --- Can this be closed? It's not a Gcc bug but a Glibc problem.
[Bug c++/67130] New: [6 Regression] ICE: tree check: expected identifier_node, have template_decl in write_unqualified_id, at cp/mangle.c:1218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67130
Bug ID: 67130
Summary: [6 Regression] ICE: tree check: expected
identifier_node, have template_decl in
write_unqualified_id, at cp/mangle.c:1218
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
trippels@gcc2-power8 test % cat type_traits.ii
namespace std {
template typename struct __success_type;
template typename void declval();
template typename class decay {
public:
typedef int type;
};
template typename... struct common_type;
struct A {
template typename, typename _Up
static __success_typetypename decaydecltype(declval_Up)::type _S_test;
};
template typename _Tp, typename _Up struct __common_type_impl : A {
typedef decltype(_S_test_Tp, _Up) type;
};
template typename _Tp, typename _Up
struct common_type_Tp, _Up : __common_type_impl_Tp, _Up {};
}
template typename struct B { struct _; };
template typename T typename BT::_ type;
template template typename... class struct C;
template template typename... class f Cf metafunction;
template typename T struct BT::_ {};
namespace detail {
template typename struct _decltype;
}
template template typename... class F struct C {
template typename... T
auto operator()(T...)
- decltype(typetypename Fdetail::_decltypeT...::type);
};
auto common_type = metafunctionstd::common_type(0, 0);
trippels@gcc2-power8 test % c++ -c type_traits.ii
type_traits.ii: In instantiation of ‘decltype (typetypename
Fdetail::_decltypeT...::type) C template-parameter-1-1 ::operator()(T
...) [with T = {int, int}; F = std::common_type; decltype (typetypename
Fdetail::_decltypeT...::type) = Bstd::__success_typeint ::_; typename
Fdetail::_decltypeT...::type = std::__success_typeint]’:
type_traits.ii:29:8: internal compiler error: tree check: expected
identifier_node, have template_decl in write_unqualified_id, at
cp/mangle.c:1218
auto operator()(T...)
^
0x10d2be23 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9499
0x103d188f tree_check
../../gcc/gcc/tree.h:2858
0x103d188f write_unqualified_id
../../gcc/gcc/cp/mangle.c:1218
0x103cb5ab write_expression
../../gcc/gcc/cp/mangle.c:2828
0x103cf47f write_type
../../gcc/gcc/cp/mangle.c:2129
0x103d1ec7 write_bare_function_type
../../gcc/gcc/cp/mangle.c:2527
0x103d4a67 mangle_decl_string
../../gcc/gcc/cp/mangle.c:3498
0x103d4c7f get_mangled_id
../../gcc/gcc/cp/mangle.c:3520
0x103d504f mangle_decl(tree_node*)
../../gcc/gcc/cp/mangle.c:3587
0x10d2d30f decl_assembler_name(tree_node*)
../../gcc/gcc/tree.c:658
0x1056c583 symbol_table::insert_to_assembler_name_hash(symtab_node*, bool)
../../gcc/gcc/symtab.c:157
0x1056d86f symbol_table::symtab_initialize_asm_name_hash()
../../gcc/gcc/symtab.c:249
0x1058a3ff analyze_functions
../../gcc/gcc/cgraphunit.c:1175
0x1058b267 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2477
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++/67135] New: [thread_local] heap-use-after-free (OS X 10.10.4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67135
Bug ID: 67135
Summary: [thread_local] heap-use-after-free (OS X 10.10.4)
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marian.tri...@haw-hamburg.de
Target Milestone: ---
Created attachment 36140
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36140action=edit
code example
#include thread
#include memory
thread_local std::unique_ptrint uptr;
int main() {
std::thread t1([]{
if (! uptr) uptr = std::unique_ptrint(new int);
});
t1.join();
}
Compiled with:
g++-5 -std=c++11 main.cpp -fsanitize=address -fno-omit-frame-pointer
It will trigger a heap-use-after-free, detected from ASAN:
=
==25568==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020dfd8
at pc 0x00010e6c5548 bp 0x000111b37e10 sp 0x000111b37e08
READ of size 8 at 0x6020dfd8 thread T1
#0 0x10e6c5547 (/Users/Hamdor/osx_thread_local/./a.out+0x12547)
#1 0x10f3f48e5 (/usr/local/lib/gcc/5/libstdc++.6.dylib+0x18e5)
#2 0x7fff86535450 (/usr/lib/system/libsystem_pthread.dylib+0x4450)
#3 0x7fff86534272 (/usr/lib/system/libsystem_pthread.dylib+0x3272)
#4 0x7fff865341e4 (/usr/lib/system/libsystem_pthread.dylib+0x31e4)
#5 0x7fff8653241c (/usr/lib/system/libsystem_pthread.dylib+0x141c)
0x6020dfd8 is located 8 bytes inside of 16-byte region
[0x6020dfd0,0x6020dfe0)
freed by thread T1 here:
#0 0x10e708419 (/usr/local/lib/gcc/5/libasan.2.dylib+0x32419)
#1 0x10f68c682 (/usr/local/lib/gcc/5/libgcc_s.1.dylib+0x11682)
previously allocated by thread T1 here:
#0 0x10e70826a (/usr/local/lib/gcc/5/libasan.2.dylib+0x3226a)
#1 0x10f68c7db (/usr/local/lib/gcc/5/libgcc_s.1.dylib+0x117db)
Thread T1 created by T0 here:
#0 0x10e6e40f0 (/usr/local/lib/gcc/5/libasan.2.dylib+0xe0f0)
#1 0x10f425d6c (/usr/local/lib/gcc/5/libstdc++.6.dylib+0x32d6c)
SUMMARY: AddressSanitizer: heap-use-after-free ??:0 ??
Shadow bytes around the buggy address:
0x1c041ba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c041bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c041bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c041bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c041be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=0x1c041bf0: fa fa fa fa fa fa 04 fa fa fa fd[fd]fa fa fd fd
0x1c041c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c041c10: fa fa fa fa fa fa 00 06 fa fa 00 00 fa fa 00 04
0x1c041c20: fa fa 00 06 fa fa 00 06 fa fa 00 fa fa fa 00 00
0x1c041c30: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
0x1c041c40: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
==25568==ABORTING
This bug was tested with:
g++-5 --version
g++-5 (Homebrew gcc5 5.2.0) 5.2.0
Older GCC versions are also affected (tested on 4.9.2)
Builds on Linux seems to be not affected, ASAN does not detect a
heap-use-after-free for the same code. OS X is 10.10.4
[Bug c++/67131] [6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67131 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-06 Ever confirmed|0 |1 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- What version of clang compiles that with no errors? Mine says, wa2.C:17:15: error: static_assert expression is not an integral constant expression static_assert(!valid_call(metafunctionno_type),); ^~ wa2.C:17:27: note: read of non-constexpr variable 'metafunctionno_type' is not allowed in a constant expression static_assert(!valid_call(metafunctionno_type),); ^ wa2.C:17:27: note: in call to 'A(metafunction)' wa2.C:6:45: note: declared here template template typename class f Af metafunction; ^
[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #20 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #19) (In reply to Kazumoto Kojima from comment #18) In the problematic situation, get_max_insn_count returns the false value after if (MAY_HAVE_DEBUG_INSNS) expand_debug_locations (); in pass_expand::execute (function *fun). expand_debug_locations calls sh_recog_treg_set_expr indirectly at this very early stage to compute rtx costs. sh_recog_treg_set_expr makes some set insns and they cause the differences of cur_insn_uid with -g. Thank you very much for tracking this down. Oleg, how about the patch below? Yes, that looks OK. treg_set_expr-something recog matching is actually only required during combine. The simpler forms like (reg:SI T_REG) could also be required during expansion. My first trial was --cur_insn_uid just after make_insn_raw there but I'm afraid that it will make another surprise. Hm ... actually it should work. The temporary rtx insn is not used for anything else, so that assigned insn uid will never appear anywhere. However, it's probably better to have one static rtx_insn to avoid constructing the temporary rtx over and over again. Unfortunately the gen_rtx* functions allocate rtx objects always on the GC heap.
[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #19 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #18) In the problematic situation, get_max_insn_count returns the false value after if (MAY_HAVE_DEBUG_INSNS) expand_debug_locations (); in pass_expand::execute (function *fun). expand_debug_locations calls sh_recog_treg_set_expr indirectly at this very early stage to compute rtx costs. sh_recog_treg_set_expr makes some set insns and they cause the differences of cur_insn_uid with -g. Oleg, how about the patch below? My first trial was --cur_insn_uid just after make_insn_raw there but I'm afraid that it will make another surprise. diff --git a/config/sh/sh.c b/config/sh/sh.c index f429193..450d634 100644 --- a/config/sh/sh.c +++ b/config/sh/sh.c @@ -14165,6 +14165,12 @@ sh_recog_treg_set_expr (rtx op, machine_mode mode) if (!can_create_pseudo_p ()) return false; + /* expand_debug_locations may call this to compute rtx costs at + very early stage. In that case, don't make new insns here to + avoid codegen differences with -g. */ + if (currently_expanding_to_rtl) +return false; + /* We are going to invoke recog in a re-entrant way and thus have to capture its current state and restore it afterwards. */ recog_data_d prev_recog_data = recog_data;
[Bug target/67129] x86: erratic parsing of #pragma GCC target (...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67129 --- Comment #5 from Dominik Vogt vogt at linux dot vnet.ibm.com --- Created attachment 36139 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36139action=edit experimental fix The attached patch fixes the problem for me (on x86), but it really needs reviewing.
[Bug sanitizer/67136] New: sanitizer reports member access within null pointer for correct C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67136
Bug ID: 67136
Summary: sanitizer reports member access within null pointer
for correct C++ code
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: konstantin.vladimirov 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: ---
Minimal reproduction:
#include cstdio
using namespace std;
class Base
{
public:
Base ():m_nl (144) {}
virtual ~Base() {}
protected:
const int m_nl;
};
class Derived : public Base
{
public:
__attribute__ ((noinline)) Derived ():Base()
{
fprintf (stderr, error = %d\n, (m_nl/2-1)%m_nl);
}
};
Base *base;
int
main ()
{
base = new Derived;
return 0;
}
Compile with G++ 5.2.0
g++-5.2.0 -fno-sanitize-recover -fsanitize=undefined -O1 -Wall test.cpp
-Wl,-rpath /tools/local/gcc-5.2.0/lib64 -lubsan
---
Yields warning:
test.cpp: In constructor ‘Derived::Derived()’:
test.cpp:20:39: warning: ‘anonymous’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
fprintf (stderr, error = %d\n, (m_nl/2-1)%m_nl);
---
I suggest, that macro UBSAN_NULL expands incorrectly on sanopt pass, yields
unitialized Gimple anonymous variable and then incorrectly compares with 0.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-06 CC||fxcoudert at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #11 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- What I do not understand is how this didn't show up before now, since the relevant libgfortran code was committed in 2012, and the mingw-w64 project has been providing gfortran builds throughout this time. Other than that, I would simply suggest we don't use umask() on mingw targets (no need to make useless system calls): Index: io/unix.c === --- io/unix.c (revision 226632) +++ io/unix.c (working copy) @@ -1083,6 +1083,14 @@ set_close_on_exec (int fd __attribute__ } +/* On mingw, we don't use umask in the function below, because it + doesn't support the user/group/other-based permissions. */ + +#ifdef __MINGW32__ +#undef HAVE_UMASK +#endif + + /* Helper function for tempfile(). Tries to open a temporary file in the directory specified by tempdir. If successful, the file name is stored in fname and the descriptor returned. Returns -1 on Can someone (Keith?) actually confirm that this restores the build on mingw32? (It should, but double-checking never hurts.)
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #13 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Steve Kargl from comment #12) Aren't there enough occurences of __MINGW32__ in io/unix.c? Why add yet another kludge? Put the #undef at line 48. Indeed, that works equally: Index: io/unix.c === --- io/unix.c (revision 226632) +++ io/unix.c (working copy) @@ -101,6 +101,12 @@ id_from_fd (const int fd) } #endif /* HAVE_WORKING_STAT */ + + +/* On mingw, we don't use umask in tempfile_open(), because it + doesn't support the user/group/other-based permissions. */ +#undef HAVE_UMASK + #endif /* __MINGW32__ */
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #34 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Thiago Macieira from comment #33) gcc 5.2.1 can no longer reproduce the testcase. Has the situation changed? GCC 5 r226650 still fails for me.
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133
--- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #9)
trippels@gcc2-power8 llvm_build % cat AnalysisConsumer.ii
It is also latent in r226635, just compile with options:
-O2 -fisolate-erroneous-paths-attribute
In this case, I cannot even debug it (i is 2):
(gdb) p gimple_call_arg (stmt, i)
/home/manuel/test3/pr67133.cc: In constructor ‘H::H()’:
/home/manuel/test3/pr67133.cc:43:1: internal compiler error: gimple check:
expected gimple_call(error_mark), have gimple_call() in gimple_call_arg, at
gimple.h:2858
H::H() { *Out a; }
^
0xa3d9c5 gimple_check_failed(gimple_statement_base const*, char const*, int,
char const*, gimple_code, tree_code)
/home/manuel/test3/src/gcc/gimple.c:1154
0x5b3abd gimple_call_arg
/home/manuel/test3/src/gcc/gimple.h:2858
But that is not the segmentation fault that is triggered when running the code
normally. It seems something wrong with the checking code.
If I print the stmt in the classic way (is there no better way to debug
gimple?):
(gdb) p *stmt
$5 = {code = GIMPLE_CALL, no_warning = 0, visited = 0, nontemporal_move = 0,
plf = 0, modified = 0, has_volatile_ops = 0, pad = 0, subcode = 0, uid = 11,
location = 2147483674, num_ops = 6, bb = 0x765bf340, next = 0x0, prev =
0x765a3b48}
Thus, it seems it should work?
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Zhendong Su from comment #0) The following code causes an ICE when compiled with the current gcc trunk at -Os and above on x86_64-linux-gnu in both 32-bit and 64-bit modes. It is a regression from 5.1.x. This was already latent in r226635, just compile with options: -Os -fisolate-erroneous-paths-dereference -fisolate-erroneous-paths-attribute The problem is that infer_nonnull_range gets: (gdb) p debug_gimple_stmt(stmt) __builtin_unreachable (); which is decorated with attributes: (gdb) p debug_tree(attrs) tree_list 0x764b3bb8 purpose identifier_node 0x7644b3c0 nonnull value tree_list 0x7645edc0 value integer_cst 0x76444060 constant 1 chain tree_list 0x764b3b90 purpose identifier_node 0x7644b2d0 format value tree_list 0x76460730 value identifier_node 0x7644b550 printf chain tree_list 0x7645ef00 value integer_cst 0x76444060 1 chain tree_list 0x7645ede8 value integer_cst 0x76444318 constant 2 That is, this __builtin_unreachable has __attribute__((nonnull(1))), which doesn't make any sense and breaks infer_nonnull_range when it tries to access its first argument. I have no idea whatsoever how __builtin_unreachable gets to have attribute nonnull, but that is a pre-existing bug. Surprising it doesn't break more stuff.
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #21 from boger at us dot ibm.com --- Created attachment 36142 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36142action=edit Configure gold with split stack based on binutils version This is an updated version of the previous patch, simplifying the test done in gcc/configure.ac. Instead of trying to link a program this just checks the binutils version number on the ld.gold --version output. The configure check in libgo will fail if the gold linker doesn't have split stack support but only on pp64le. On ppc64 the version check should be sufficient to make sure the right gold linker is there.
[Bug c++/67139] [concepts] ICE on checking concepts with void with variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67139 Eric Niebler eric.niebler at gmail dot com changed: What|Removed |Added Summary|[concepts] ICE on checking |[concepts] ICE on checking |concepts with void |concepts with void with ||variable template --- Comment #3 from Eric Niebler eric.niebler at gmail dot com --- The problem goes away when _vT is replaced with the equivalent T::type::value in concept IsTrue_, so that seems to be the smoking gun.
[Bug c++/67138] New: [concepts] bogus not more constrained error for more constrained partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67138
Bug ID: 67138
Summary: [concepts] bogus not more constrained error for more
constrained partial specialization
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
template class T
concept bool _Auto = true;
template _Auto T
struct test {};
template _Auto T
requires requires (T t) { t + t; }
struct testT {};
yields:
test.cpp:10:8: error: partial specialization ‘struct testT’ does not
specialize any template arguments and is not more constrained than
struct testT {};
^
test.cpp:6:8: note: primary template here
struct test {};
^
[Bug libfortran/66458] Loading libgfortran.so changes the FPU exception flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458 --- Comment #5 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- The comment in the front-end confirms the original intent, which is that FPU shouldn't be messed with if the user didn't explicitly request it: /* If -ffpe-trap option was provided, add a call to set_fpe so that the library will raise a FPE when needed. */ The patch below makes libgfortran behave in the same way: Index: runtime/main.c === --- runtime/main.c (revision 226632) +++ runtime/main.c (working copy) @@ -263,7 +263,11 @@ init (void) init_variables (); init_units (); - set_fpu (); + + /* If (and only if) the user asked for it, set up the FPU state. */ + if (options.fpe != 0) +set_fpu (); + init_compile_options (); #ifdef DEBUG
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #33 from Thiago Macieira thiago at kde dot org --- gcc 5.2.1 can no longer reproduce the testcase. Has the situation changed?
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133
--- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
trippels@gcc2-power8 llvm_build % cat AnalysisConsumer.ii
class A;
struct B {
typedef A type;
};
template typename struct I : B {};
class C {
public:
C(char *);
int size();
};
template typename struct D;
template typename _Tp, typename = D_Tp class F {
class G {
template typename static _Tp *__test();
typedef int _Del;
public:
typedef decltype(__test_Del()) type;
};
public:
typename I_Tp::type operator*() {
typename G::type a = 0;
return *a;
}
};
class H {
FA Out;
H();
};
void fn1(void *, void *, int) __attribute__((__nonnull__));
class A {
int OutBufEnd, OutBufCur;
public:
void operator(C p1) {
int b, c = p1.size();
if (OutBufEnd)
fn1(OutBufCur, b, c);
}
};
char* a;
H::H() { *Out a; }
trippels@gcc2-power8 llvm_build % g++ -O2 -c AnalysisConsumer.ii
AnalysisConsumer.ii: In constructor ‘H::H()’:
AnalysisConsumer.ii:43:1: internal compiler error: Segmentation fault
H::H() { *Out a; }
^
0x10a18c53 crash_signal
../../gcc/gcc/toplev.c:352
0x1072af0c infer_nonnull_range_by_attribute(gimple_statement_base*, tree_node*)
../../gcc/gcc/gimple.c:2682
0x110a881f find_explicit_erroneous_behaviour
../../gcc/gcc/gimple-ssa-isolate-paths.c:410
0x110a881f gimple_ssa_isolate_erroneous_paths
../../gcc/gcc/gimple-ssa-isolate-paths.c:526
0x110a881f execute
../../gcc/gcc/gimple-ssa-isolate-paths.c:577
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++/67139] [concepts] ICE on checking concepts with void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67139
--- Comment #2 from Eric Niebler eric.niebler at gmail dot com ---
Thanks, except that that is invalid code, and this bug is an ICE-on-valid.
Here's the equivalent valid repro case:
template class T
constexpr typename T::type::value_type _v = T::type::value;
template class T concept bool IsTrue_() { return _vT; }
template class T concept bool Unpossible() {
return IsTrue_T ();
}
template class constexpr bool unpossible() { return false; }
Unpossible{ T }
constexpr bool unpossible() { return true; }
static_assert((!unpossiblevoid()), );
[Bug c++/66533] [C++14] ICE: in dependent_type_p, at cp/pt.c:21073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66533 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |5.3 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Fixed
[Bug c++/66538] Parameter not in scope of generic lambda trailing decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66538 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed by r226684.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #12 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Thu, Aug 06, 2015 at 04:57:15PM +, fxcoudert at gcc dot gnu.org wrote: Index: io/unix.c === --- io/unix.c (revision 226632) +++ io/unix.c (working copy) @@ -1083,6 +1083,14 @@ set_close_on_exec (int fd __attribute__ } +/* On mingw, we don't use umask in the function below, because it + doesn't support the user/group/other-based permissions. */ + +#ifdef __MINGW32__ +#undef HAVE_UMASK +#endif + Aren't there enough occurences of __MINGW32__ in io/unix.c? Why add yet another kludge? Put the #undef at line 48.
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Or even with options: -O2 -fisolate-erroneous-paths-attribute (why is the latter not enabled by default?)
[Bug c++/66260] [C++14] Failure to compile variable template with recursively defined partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66260 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 6 18:45:05 2015 New Revision: 226696 URL: https://gcc.gnu.org/viewcvs?rev=226696root=gccview=rev Log: PR c++/67130 PR c++/67131 PR c++/66260 * mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable templates. * pt.c (tsubst_copy_and_build): Check for argument substitution failure. Added: branches/c++-concepts/gcc/testsuite/g++.dg/cpp1y/var-templ42.C branches/c++-concepts/gcc/testsuite/g++.dg/cpp1y/var-templ43.C Modified: branches/c++-concepts/gcc/cp/mangle.c branches/c++-concepts/gcc/cp/pt.c
[Bug c++/67131] [6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67131 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 6 18:45:05 2015 New Revision: 226696 URL: https://gcc.gnu.org/viewcvs?rev=226696root=gccview=rev Log: PR c++/67130 PR c++/67131 PR c++/66260 * mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable templates. * pt.c (tsubst_copy_and_build): Check for argument substitution failure. Added: branches/c++-concepts/gcc/testsuite/g++.dg/cpp1y/var-templ42.C branches/c++-concepts/gcc/testsuite/g++.dg/cpp1y/var-templ43.C Modified: branches/c++-concepts/gcc/cp/mangle.c branches/c++-concepts/gcc/cp/pt.c
[Bug c++/67130] [6 Regression] ICE: tree check: expected identifier_node, have template_decl in write_unqualified_id, at cp/mangle.c:1218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67130 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 6 18:45:05 2015 New Revision: 226696 URL: https://gcc.gnu.org/viewcvs?rev=226696root=gccview=rev Log: PR c++/67130 PR c++/67131 PR c++/66260 * mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable templates. * pt.c (tsubst_copy_and_build): Check for argument substitution failure. Added: branches/c++-concepts/gcc/testsuite/g++.dg/cpp1y/var-templ42.C branches/c++-concepts/gcc/testsuite/g++.dg/cpp1y/var-templ43.C Modified: branches/c++-concepts/gcc/cp/mangle.c branches/c++-concepts/gcc/cp/pt.c
[Bug c++/66937] Do not compare constraints for unconstrained template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66937 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 6 17:42:25 2015 New Revision: 226687 URL: https://gcc.gnu.org/viewcvs?rev=226687root=gccview=rev Log: PR c++/66937 * pt.c (is_compatible_template_arg): A template template parameter with unconstrained parameters can match an argument with constrained parameters. Added: branches/c++-concepts/gcc/testsuite/g++.dg/concepts/template-template-parm1.C Modified: branches/c++-concepts/ChangeLog.concepts branches/c++-concepts/gcc/cp/pt.c
[Bug c++/67139] New: [concepts] ICE on checking concepts with void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67139 Bug ID: 67139 Summary: [concepts] ICE on checking concepts with void Product: gcc Version: c++-concepts Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric.niebler at gmail dot com Target Milestone: --- Created attachment 36141 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36141action=edit preprocessed source archive Compile the attached code with -std=gnu++1z. The result is: ../cmcstl2/test/concepts/object.cpp:254:50: internal compiler error: Segmentation fault CONCEPT_ASSERT(!models::move_constructiblevoid()); ^ ../cmcstl2/test/concepts/object.cpp:254:50: internal compiler error: Aborted g++: internal compiler error: Aborted (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Cursory attempts to reduce the test case caused the error to go away.
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #35 from Thiago Macieira thiago at kde dot org --- I've only tried with SUSE's distro build, as my own GCC build is now GCC 6. However, I can reproduce it with my GCC 6 build. Let me investigate if OpenSUSE applied a patch.
[Bug c++/67139] [concepts] ICE on checking concepts with void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67139
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-08-06
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 tmp % cat o.ii
template typename T typename T::typevalue_type _v;
template class T concept bool Constructible() { return _vT; }
template class T concept bool MoveConstructible() {
return ConstructibleT ();
}
template class constexpr bool move_constructible() { return false; }
MoveConstructible { T }
constexpr bool move_constructible() { return true; }
static_assert((!move_constructiblevoid()), );
markus@x4 tmp % g++ -std=gnu++1z -c o.ii
o.ii:12:42: internal compiler error: Segmentation fault
static_assert((!move_constructiblevoid()), );
^
0xc7f85f crash_signal
../../gcc/gcc/toplev.c:352
0x7fab31e0770f ???
/var/tmp/glibc/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xef7bd0 strip_array_types(tree_node*)
../../gcc/gcc/tree.c:8194
0x71a2e8 cp_type_quals(tree_node const*)
../../gcc/gcc/cp/typeck.c:9006
0x790024 cv_unqualified(tree_node*)
../../gcc/gcc/cp/tree.c:1161
0x7fc8c4 satisfy_predicate_constraint
../../gcc/gcc/cp/constraint.cc:1705
0x7fc8c4 satisfy_constraint_1
../../gcc/gcc/cp/constraint.cc:1901
0x7fd5f6 satisfy_constraint
../../gcc/gcc/cp/constraint.cc:1952
0x7fd74c constraints_satisfied_p(tree_node*)
../../gcc/gcc/cp/constraint.cc:2059
0x5d832c add_function_candidate
../../gcc/gcc/cp/call.c:1986
0x5d8e88 add_template_candidate_real
../../gcc/gcc/cp/call.c:3109
0x5d957c add_template_candidate
../../gcc/gcc/cp/call.c:3151
0x5d957c add_candidates
../../gcc/gcc/cp/call.c:5307
0x5dbc03 perform_overload_resolution
../../gcc/gcc/cp/call.c:4003
0x5de10e build_new_function_call(tree_node*, vectree_node*, va_gc,
vl_embed**, bool, int)
../../gcc/gcc/cp/call.c:4080
0x76b998 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2391
0x6e9737 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6421
0x6ee229 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7485
0x6ee188 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7438
0x6eee57 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8222
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 middle-end/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67124
--- Comment #6 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org
---
(In reply to Uroš Bizjak from comment #5)
Wrong expansion, adding CC.
The expand code looks OK to me. Assigning to one DImode word
of a TImode isn't supposed to change the other half.
I think the problem is in LRA. It tries to reload the low half
of the TImode as follows:
Creating newreg=104, assigning class NO_REGS to secondary r104
51: r104:DI=r103:DI
Inserting the sec. move after:
52: r90:TI#0=r104:DI
then allocates it as an xmm-mem move:
Choosing alt 14 in insn 52: (0) *v (1) m {*movdi_internal}
That isn't right because the move won't preserve the high half
of the xmm register. It would need to be a strict_lowpart to do that.
[Bug c++/67130] [6 Regression] ICE: tree check: expected identifier_node, have template_decl in write_unqualified_id, at cp/mangle.c:1218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67130 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-06 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/66260] [C++14] Failure to compile variable template with recursively defined partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66260 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 6 14:28:26 2015 New Revision: 226677 URL: https://gcc.gnu.org/viewcvs?rev=226677root=gccview=rev Log: PR c++/67130 PR c++/67131 PR c++/66260 * mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable templates. * pt.c (tsubst_copy_and_build): Check for argument substitution failure. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ42.C branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ43.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/mangle.c branches/gcc-5-branch/gcc/cp/pt.c
[Bug c++/67131] [6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67131 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 6 14:28:26 2015 New Revision: 226677 URL: https://gcc.gnu.org/viewcvs?rev=226677root=gccview=rev Log: PR c++/67130 PR c++/67131 PR c++/66260 * mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable templates. * pt.c (tsubst_copy_and_build): Check for argument substitution failure. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ42.C branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ43.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/mangle.c branches/gcc-5-branch/gcc/cp/pt.c
[Bug c++/67130] [6 Regression] ICE: tree check: expected identifier_node, have template_decl in write_unqualified_id, at cp/mangle.c:1218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67130 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 6 14:28:26 2015 New Revision: 226677 URL: https://gcc.gnu.org/viewcvs?rev=226677root=gccview=rev Log: PR c++/67130 PR c++/67131 PR c++/66260 * mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable templates. * pt.c (tsubst_copy_and_build): Check for argument substitution failure. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ42.C branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ43.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/mangle.c branches/gcc-5-branch/gcc/cp/pt.c
[Bug c++/67131] [6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67131 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jason Merrill from comment #1) What version of clang compiles that with no errors? Latest trunk.
[Bug c++/66260] [C++14] Failure to compile variable template with recursively defined partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66260 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 6 14:26:18 2015 New Revision: 226676 URL: https://gcc.gnu.org/viewcvs?rev=226676root=gccview=rev Log: PR c++/67130 PR c++/67131 PR c++/66260 * mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable templates. * pt.c (tsubst_copy_and_build): Check for argument substitution failure. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ42.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ43.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/cp/pt.c
[Bug c++/67130] [6 Regression] ICE: tree check: expected identifier_node, have template_decl in write_unqualified_id, at cp/mangle.c:1218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67130 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 6 14:26:18 2015 New Revision: 226676 URL: https://gcc.gnu.org/viewcvs?rev=226676root=gccview=rev Log: PR c++/67130 PR c++/67131 PR c++/66260 * mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable templates. * pt.c (tsubst_copy_and_build): Check for argument substitution failure. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ42.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ43.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/cp/pt.c
[Bug c++/67131] [6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67131 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 6 14:26:18 2015 New Revision: 226676 URL: https://gcc.gnu.org/viewcvs?rev=226676root=gccview=rev Log: PR c++/67130 PR c++/67131 PR c++/66260 * mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable templates. * pt.c (tsubst_copy_and_build): Check for argument substitution failure. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ42.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ43.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/cp/pt.c
[Bug c/67132] New: gcc -D__WCHAR_TYPE__='unsigned int' should not complain about built-in types redefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67132 Bug ID: 67132 Summary: gcc -D__WCHAR_TYPE__='unsigned int' should not complain about built-in types redefined Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: giacomo at tesio dot it Target Milestone: --- I have a 3rd party library that `typedef Rune uint32_t`, and gcc *properly* complains about the signedness of the following assignment Rune *s = LΆρχιμήδης; because wchar_t is int32_b by default. I have found that calling gcc with -D__WCHAR_TYPE__='unsigned int' -D__WCHAR_MAX__=4294967295U -D__WCHAR_MIN__=0 fix the signedness problem completely, but gcc then warns about such built-in types redeclared at command line. It would be nice to be able to redefine such built-in types without rebuilding gcc.
[Bug middle-end/67133] New: ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133
Bug ID: 67133
Summary: ICE at -Os and above on x86_64-linux-gnu in gimple_op,
at gimple.h:2274
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following code causes an ICE when compiled with the current gcc trunk at
-Os and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 5.1.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150805 (experimental) [trunk revision 226646] (GCC)
$
$ gcc-trunk -O1 -c small.c
$ gcc-5.1 -Os -c small.c
$
$ gcc-trunk -Os -c small.c
small.c: In function ‘fn3’:
small.c:29:1: internal compiler error: in gimple_op, at gimple.h:2274
fn3 ()
^
0x86e15d gimple_op
../../gcc-trunk/gcc/gimple.h:2274
0x86e15d gimple_call_arg
../../gcc-trunk/gcc/gimple.h:2861
0x86e15d infer_nonnull_range_by_attribute(gimple_statement_base*, tree_node*)
../../gcc-trunk/gcc/gimple.c:2681
0x10c96f6 find_explicit_erroneous_behaviour
../../gcc-trunk/gcc/gimple-ssa-isolate-paths.c:410
0x10c96f6 gimple_ssa_isolate_erroneous_paths
../../gcc-trunk/gcc/gimple-ssa-isolate-paths.c:526
0x10c96f6 execute
../../gcc-trunk/gcc/gimple-ssa-isolate-paths.c:577
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.
$
---
#include assert.h
int printf (const char *, ...);
int a, *b, c;
static int
fn1 ()
{
if (a)
return (a = 0);
for (; a; )
a = 0;
return 0;
}
static int
fn2 (int p)
{
fn1 ();
c = 0;
if (p)
printf (%d, 0);
assert (b != p);
return 0;
}
void
fn3 ()
{
fn2 (0);
}
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #4) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Well, it is a 5MB testcase and reducing isn't instantaneous unfortunately.
[Bug middle-end/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67124 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC|uros at gcc dot gnu.org|rsandifo at gcc dot gnu.org, ||ubizjak at gmail dot com Component|target |middle-end --- Comment #5 from Uroš Bizjak ubizjak at gmail dot com --- Wrong expansion, adding CC.
[Bug fortran/64022] [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64022 --- Comment #10 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Thu Aug 6 09:22:30 2015 New Revision: 226670 URL: https://gcc.gnu.org/viewcvs?rev=226670root=gccview=rev Log: PR fortran/64022 * gfortran.dg/ieee/large_2.f90: New test. * gfortran.dg/ieee/large_3.F90: New test. Added: trunk/gcc/testsuite/gfortran.dg/ieee/large_2.f90 trunk/gcc/testsuite/gfortran.dg/ieee/large_3.F90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/56309] conditional moves instead of compare and branch result in almost 2x slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56309
--- Comment #33 from Yuri Rumyantsev ysrumyan at gmail dot com ---
With current compiler there is not performance difference for by-ref and by-val
test-cases, but if we turn off if-convert transformation we will get ~2X
speed-up:
on Intel(R) Xeon(R) CPU X5670 @ 2.93GHz
./t1.exe
Took 11.55 seconds total.
./t1.noifcvt.exe
Took 6.51 seconds total.
The test will be attached.
This is caused by skew conditional branch probabilities for the loop:
for (auto rhs_it = rbegin; rhs_it != rend; ++rhs_it) {
tmp = x*(*rhs_it) + data[i] + carry;
if (tmp = imax) {
carry = tmp numbits;
tmp = imax - 1;
} else {
carry = 0;
}
data[i++] = tmp;
}
Only 2.5% conditional branches are not taken since imax represents MAX_INT32
and profile estimation phase needs to be fixed to set-up unlikely probability
for integral comparison with huge constants.
To coupe with this issue we may implement Jakub approach to design Oracle for
if-conversion profitability which simply computes region (loop) costs for
if-converted and not-if-converted regions ( cost of all acyclic paths).
Using such approach we can see that for fixed profile hammock predication is
not profitable and if vectorization will not be successful loop must be
restored to orginal one.
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug target/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67124
--- Comment #4 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Richard Biener from comment #2)
Hmm, looks like a target issue. We expand from
Not this time. It looks to me that generic code is at fault, performing DImode
move from %rdx to %xmm0, instead of inserting %rdx into %xmm0.
This can be seen with -O2 -msse2 -mtune=corei7 (please note that arrow points
to an instruction *before* it is executed):
0x00400440 +0: movzbl 0x200c4b(%rip),%eax
0x00400447 +7: movdqa 0x200c41(%rip),%xmm0
0x0040044f +15:movq %xmm0,%rdx
= 0x00400454 +20:mov%rax,%rcx
0x00400457 +23:and$0xff00,%rdx
0x0040045e +30:shl$0x10,%rax
0x00400462 +34:or %rax,%rdx
0x00400465 +37:xor%eax,%eax
0x00400467 +39:movq %rdx,%xmm0
0x0040046c +44:pinsrw $0x2,%eax,%xmm0
0x00400471 +49:mov0x200be8(%rip),%rax
0x00400478 +56:movups %xmm0,(%rax)
(gdb) i r rax rdx xmm0
rax0x1
rdx0x1
xmm0 {uint128 = 0x00010001}
0x00400465 +37:xor%eax,%eax
= 0x00400467 +39:movq %rdx,%xmm0
0x0040046c +44:pinsrw $0x2,%eax,%xmm0
(gdb) i r rdx xmm0
rdx0x1
xmm0 {uint128 = 0x00010001}
0x00400465 +37:xor%eax,%eax
0x00400467 +39:movq %rdx,%xmm0
= 0x0040046c +44:pinsrw $0x2,%eax,%xmm0
(gdb) i r rdx xmm0
rdx0x1
xmm0 {uint128 = 0x0001}
The same code can be compiled with -msse4 instead of -msse2, so we will have
pinsrb insn available:
0x00400440 +0: movzbl 0x200c4b(%rip),%eax
0x00400447 +7: xor%edx,%edx
0x00400449 +9: movdqa 0x200c3f(%rip),%xmm0
= 0x00400451 +17:pinsrb $0x2,%eax,%xmm0
0x00400457 +23:pinsrw $0x2,%edx,%xmm0
0x0040045c +28:mov0x200bfd(%rip),%rdx# 0x601060
b
0x00400463 +35:movups %xmm0,(%rdx)
(gdb) i r rax xmm0
rax0x1
xmm0 {uint128 = 0x00010001}
0x00400449 +9: movdqa 0x200c3f(%rip),%xmm0
0x00400451 +17:pinsrb $0x2,%eax,%xmm0
= 0x00400457 +23:pinsrw $0x2,%edx,%xmm0
i r xmm0
xmm0 {uint128 = 0x00010001}
As shown in the first case, the value in %xmm0 is already wrong before pinsrw
is executed.
[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Martin Husemann from comment #3) This still applies to recent versions and is an obvious fix. Please apply! Points #7 and #8 in https://gcc.gnu.org/wiki/Community can help you to get your patch through.
[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Martin Husemann from comment #3) This still applies to recent versions and is an obvious fix. Please apply! I personally would prefer to factor out all that repeated code into a function pch_read_fatal_error() or to an exit label and use goto pch_read_fatal_error; In any case, patches need to be submitted to gcc-patc...@gcc.gnu.org. Reviewers rarely look for patches in bugzilla. See point #8 in https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps You should perhaps include the name of the file being patched in the subject. I'm not sure we have a maintainer for ggc anymore.
[Bug preprocessor/58397] Please add host_hooks for NetBSD to make precompiled headers work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397 Martin Husemann martin at netbsd dot org changed: What|Removed |Added Attachment #30803|0 |1 is obsolete|| --- Comment #2 from Martin Husemann martin at netbsd dot org --- Created attachment 36137 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36137action=edit Updated version of host hooks for NetBSD
[Bug preprocessor/58397] Please add host_hooks for NetBSD to make precompiled headers work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397 Martin Husemann martin at netbsd dot org changed: What|Removed |Added Version|4.8.1 |5.2.0 --- Comment #3 from Martin Husemann martin at netbsd dot org --- This still applies to current releases of gcc and makes plain FSF gcc unbuildable on many NetBSD architectures.
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-06 CC||trippels at gcc dot gnu.org Summary|ICE at -Os and above on |[6 Regression] ICE at -Os |x86_64-linux-gnu in |and above on |gimple_op, at gimple.h:2274 |x86_64-linux-gnu in ||gimple_op, at gimple.h:2274 Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Confirmed. Also happens when building LLVM.
[Bug c/67134] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67134 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- 4.7.3 is no longer supported, please report the issue to your vendor code sourcery.
[Bug c++/67131] New: [6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67131
Bug ID: 67131
Summary: [6 Regression] ICE: Segmentation fault
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
trippels@gcc2-power8 test % cat metafunction.ii
template typename T typename T::_ type;
template template typename... class struct A;
template template typename class f Af metafunction;
namespace detail {
template typename struct _decltype;
}
template template typename... class F struct A {
template typename... T
auto operator()() - decltype(typeFdetail::_decltypeT...);
};
template typename F auto valid_call(F f) - decltype(f());
constexpr auto valid_call(...) { return 0; }
template typename struct no_type;
static_assert(!valid_call(metafunctionno_type),);
trippels@gcc2-power8 test % clang++ -Wall -Wextra -c -std=c++14 metafunction.ii
trippels@gcc2-power8 test % g++ -c metafunction.ii
metafunction.ii: In substitution of ‘templateclass ... T decltype
(typeFdetail::_decltypeT... ) A template-parameter-1-1 ::operator()()
[with T = {}]’:
metafunction.ii:11:57: required by substitution of ‘templateclass F
decltype (f()) valid_call(F) [with F = Ano_type]’
metafunction.ii:14:48: required from here
metafunction.ii:9:8: internal compiler error: Segmentation fault
auto operator()() - decltype(typeFdetail::_decltypeT...);
^
0x10a19a33 crash_signal
../../gcc/gcc/toplev.c:352
0x1031435c invalid_nonstatic_memfn_p
../../gcc/gcc/cp/typeck.c:1815
0x10385f67 finish_decltype_type(tree_node*, bool, int)
../../gcc/gcc/cp/semantics.c:7172
0x1020c867 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12686
0x1021219f tsubst_function_type
../../gcc/gcc/cp/pt.c:11749
0x1020c033 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12493
0x1021911b tsubst_decl
../../gcc/gcc/cp/pt.c:10969
0x1020c3f3 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11965
0x10209c4f instantiate_template_1
../../gcc/gcc/cp/pt.c:16156
0x10209c4f instantiate_template(tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:16207
0x10236c27 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:16556
0x10188d3b add_template_candidate_real
../../gcc/gcc/cp/call.c:3022
0x1018996f add_template_candidate
../../gcc/gcc/cp/call.c:3119
0x1018996f add_candidates
../../gcc/gcc/cp/call.c:5245
0x1019012b build_op_call_1
../../gcc/gcc/cp/call.c:4232
0x1019012b build_op_call(tree_node*, vectree_node*, va_gc, vl_embed**, int)
../../gcc/gcc/cp/call.c:4319
0x1037e2e3 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**,
bool, bool, int)
../../gcc/gcc/cp/semantics.c:2408
0x10222d6b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15397
0x1020b8e3 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12666
0x10211ebb tsubst_function_type
../../gcc/gcc/cp/pt.c:11749
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++/67130] [6 Regression] ICE: tree check: expected identifier_node, have template_decl in write_unqualified_id, at cp/mangle.c:1218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67130 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed. Thanks.
[Bug bootstrap/67137] New: --enable-languages=jit and --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67137 Bug ID: 67137 Summary: --enable-languages=jit and --disable-shared Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- /git/gcc/configure --enable-host-shared --enable-threads=posix --with-arch=haswell --enable-__cxa_atexit --enable-languages=c,c++,lto,jit --disable-shared --enable-targets=all --enable-nls --with-linker-hash-style=gnu --with-system-zlib --disable-multilib make at stage2 fails with the message below, trying to build libgccjit.so.0.0.1 . As I pass --disable-shared to ./configure, either configure shall fail, when --enable-languages=jit is also requested, or it shall build libgccjit static. In any case, make may not fail because of impossible combinations of flags to ./configure, it is ./configure which must fail then. make[3]: Entering directory '/src/gcc/gcc2/gcc' /src/gcc/gcc2/./prev-gcc/xg++ -B/src/gcc/gcc2/./prev-gcc/ -B/usr/local/gcc60/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/git/gcc/libstdc++-v3/libsupc++ -L/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -no-pie -g -O2 -gtoggle -DIN_GCC -fPIC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o libgccjit.so.0.0.1 -shared \ attribs.o jit/dummy-frontend.o jit/libgccjit.o jit/jit-logging.o jit/jit-recording.o jit/jit-playback.o jit/jit-result.o jit/jit-tempdir.o jit/jit-builtins.o jit/jit-spec.o gcc.o libbackend.a libcommon-target.a libcommon.a \ ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/pic/libiberty.a ../libdecnumber/libdecnumber.a -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl -lz \ driver-i386.o \ -Wl,--version-script=/git/gcc/gcc/jit/libgccjit.map \ -Wl,-soname,libgccjit.so.0 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/bin/ld: /src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(pure.o): relocation R_X86_64_32 against `.rodata.__cxa_pure_virtual.str1.1' can not be used when making a shared object; recompile with -fPIC /src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status /git/gcc/gcc/jit/Make-lang.in:84: recipe for target 'libgccjit.so.0.0.1' failed make[3]: *** [libgccjit.so.0.0.1] Error 1 make[3]: Leaving directory '/src/gcc/gcc2/gcc' Makefile:4417: recipe for target 'all-stage2-gcc' failed make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory '/src/gcc/gcc2' Makefile:19833: recipe for target 'stage2-bubble' failed make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory '/src/gcc/gcc2' Makefile:908: recipe for target 'all' failed make: *** [all] Error 2
[Bug c++/67131] [6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67131 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- With this fix there is only one ICE left when building boost_hana: PR66533. Closing.
[Bug c++/67130] [6 Regression] ICE: tree check: expected identifier_node, have template_decl in write_unqualified_id, at cp/mangle.c:1218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67130 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- really fixed
[Bug target/67129] x86: erratic parsing of #pragma GCC target (...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67129 --- Comment #4 from Dominik Vogt vogt at linux dot vnet.ibm.com --- Also, it is a bad idea to pass global_options_set in this call ix86_valid_target_attribute_tree (args, global_options, global_options_set); because it may be modified (via ix86_handle_option()). Unlike global_options, the structure global_options_set is never saved or restored, so any target pragma or attribute may change the structure for the rest of the compilation unit. This may or may not cause weird things to happen.
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||lopezibanez at gmail dot com --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- CCing author
[Bug c++/67131] [6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67131 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Target Milestone|6.0 |--- --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Backtrace in the LLVM case is slightly different: AnalysisConsumer.ii:131658:8: internal compiler error: Segmentation fault 0x10a19a33 crash_signal ../../gcc/gcc/toplev.c:352 0x1072af6c infer_nonnull_range_by_attribute(gimple_statement_base*, tree_node*) ../../gcc/gcc/gimple.c:2682 0x110abb8f find_explicit_erroneous_behaviour ../../gcc/gcc/gimple-ssa-isolate-paths.c:410 0x110abb8f gimple_ssa_isolate_erroneous_paths ../../gcc/gcc/gimple-ssa-isolate-paths.c:526 0x110abb8f execute ../../gcc/gcc/gimple-ssa-isolate-paths.c:577 Please submit a full bug report,
