[Bug c++/80247] New: 'nullptr' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80247
Bug ID: 80247
Summary: 'nullptr' was not declared in this scope
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbansal at ciena dot com
Target Milestone: ---
I am migrating my code from 3.4.5 to 4.8.1 and enabled c++11 using -std=C++11
but I am getting below error :
In file included from
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc-current/include/grpc++/impl/codegen/security/auth_context.h:41:0,
from
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc-current/include/grpc++/impl/codegen/create_auth_context.h:43,
from
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc-current/include/grpc++/impl/codegen/server_context.h:45,
from
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc-current/include/grpc++/server_context.h:37,
from
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc_ciena/server/request_mgr.h:35,
from
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc_ciena/secu_framework/session_mgmt.cc:13:
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc-current/include/grpc++/impl/codegen/string_ref.h:
In constructor 'grpc::string_ref::string_ref()':
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc-current/include/grpc++/impl/codegen/string_ref.h:70:24:
error: 'nullptr' was not declared in this scope
string_ref() : data_(nullptr), length_(0) {}
What Can I do to fix that?
Thanks.
[Bug rtl-optimization/80233] [7 Regression] ICE in combine_instructions w/ -O2 (and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-29 CC||jakub at gcc dot gnu.org, ||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- This fixes it for me: --- combine.c.jj1 2017-03-21 15:49:11.0 +0100 +++ combine.c 2017-03-29 07:59:56.627951253 +0200 @@ -1254,6 +1254,7 @@ combine_instructions (rtx_insn *f, unsig last_combined_insn = PREV_INSN (last_combined_insn); if (last_combined_insn == NULL_RTX || BARRIER_P (last_combined_insn) + || NOTE_P (last_combined_insn) || BLOCK_FOR_INSN (last_combined_insn) != this_basic_block || DF_INSN_LUID (last_combined_insn) <= DF_INSN_LUID (insn)) last_combined_insn = insn; but I'll study the combine dumps in more detail.
[Bug libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66689 --- Comment #3 from Ed Smith-Rowland <3dw4rd at verizon dot net> --- Well, for whatever reason, TR29124 and C++17 chose the - in front of \nu. As long as we document and warn I think this isn't a defect. I'll dig through the docs and get back.
[Bug target/80204] macosx-version-min wrong for macOS Sierra 10.12.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80204 --- Comment #1 from simon at pushface dot org --- macOS 10.12.4 includes kernel version 16.5.0. The command line tools have been updated: clang cc1 is now version 8.1.0 (clang-802.0.38). It still specifies -macosx_version_min 10.12.0 at link time.
[Bug c++/80241] [5/6/7 Regression] Broken error message + ICE with invalid attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80241 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-29 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |5.5 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r222902 aka PR59012. Before that we get: pr80241.C:3:30: error: expected ‘]’ before ‘...’ token [[gnu::aligned (alignof(A))...]] char c; ^
[Bug c++/80243] c++ doesn't allow function to return a struct (or object?) - same thing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80243 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Martin Sebor --- This report doesn't look valid to me. The snippet from comment #0 compiles successfully and with no warnings with the top of both the 6 branch and trunk. If you get an error from GCC, please reopen this report and post the full compiler output here. (Please review https://gcc.gnu.org/bugs to see what information we're looking for -- see What we need, especially "the compiler output (error messages, warnings, etc.)".)
[Bug target/80246] Builtin's for POWER's dxex[q] and diex[q] use the wrong types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80246 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2017-03-28 00:00:00 |2017-03-29 Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/80246] Builtin's for POWER's dxex[q] and diex[q] use the wrong types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80246 Peter Bergner changed: What|Removed |Added Last reconfirmed||2017-3-28 --- Comment #2 from Peter Bergner --- I'm testing a patch.
[Bug target/80246] Builtin's for POWER's dxex[q] and diex[q] use the wrong types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80246
--- Comment #1 from Peter Bergner ---
bergner@pike:~/gcc/BUGS/LTC137326$ cat dxex.i
long
dxex (_Decimal64 arg)
{
return __builtin_dxex (arg);
}
bergner@pike:~/gcc/BUGS/LTC137326$ gcc -O2 -mcpu=power8 -S dxex.i
bergner@pike:~/gcc/BUGS/LTC137326$ cat dxex.s
[snip]
dxex:
dxex 1,1
drintn. 0,1,1,1
dctfix 1,1
mfvsrd 3,1
blr
Notice the incorrect FP -> integer cast that destroys the return value.
Expected code is:
dxex:
dxex 0,1
mfvsrd 3,0
blr
[Bug target/80246] New: Builtin's for POWER's dxex[q] and diex[q] use the wrong types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80246 Bug ID: 80246 Summary: Builtin's for POWER's dxex[q] and diex[q] use the wrong types Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bergner at gcc dot gnu.org Target Milestone: --- The DFP builtins for extract exponent (dxex and dxexq) return a decimal float type when the actual value returned by the hardware instructions is a 64-bit signed binary integer (albeit in a FP register). The return type of the builtins should match the type of the value returned and not register type it is returned in, since moving the return value when it's in a FP variable to an integer variable produces bad and/or incorrect code. A similar issue affects the DFP insert exponent builtins (diex, diexq), but this time it is related to using the wrong type for the input argument that represents the exponent.
[Bug tree-optimization/79534] [7 Regression] tree-ifcombine aarch64 performance regression with trunk@245151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534 --- Comment #4 from Brian Rzycki --- Hi James, thank you for taking the time to test this. Unfortunately I can't post the original code because of its license. The problem is with the weighting changing enough that at least one pair of if conditionals is no longer converted into a boolean logical if. If it helps I can talk to Sebastian to see if we have time to refine the reduced test case. Alternatively I may be able to post the diff of the previous and current passes on the real code showing the branch no longer selected for conversion.
[Bug rtl-optimization/80193] [7 Regression] ICE on valid (but hairy) C code at -O3 on x86_64-linux-gnu: in check_allocation, at ira.c:2563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80193 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #7 from Jeffrey A. Law --- Fixed by Vlad's patch on the trunk.
[Bug testsuite/43496] gcc.target/powerpc/gcse-1.c fails on powerpc-unknown-linux-gnu with -fpic/-fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43496 --- Comment #3 from Segher Boessenkool --- Author: segher Date: Tue Mar 28 22:26:17 2017 New Revision: 246555 URL: https://gcc.gnu.org/viewcvs?rev=246555&root=gcc&view=rev Log: rs6000: Fix gcc.target/powerpc/gcse-1.c for PIC (PR43496) With PIC a @ha relocation isn't generated, so skip that test then. PR testsuite/43496 * gcc.target/powerpc/gcse-1.c: Skip scan-assembler-times "@ha" if generating PIC code. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/gcse-1.c
[Bug debug/80234] [7 Regression] ICE in splice_child_die at dwarfout.c:5265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80234 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I'll have a look.
[Bug c++/80240] cannot dynamic_cast variable to intmax_t from variable of type intmax_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80240 Volker Reichelt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||reichelt at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Volker Reichelt --- The C++ standard says in [expr.dynamic.cast]: 1 The result of the expression dynamic_cast(v) is the result of converting the expression v to type T. T shall be a pointer or reference to a complete class type, or "pointer to cv void." intmax_t is neither a pointer or reference and that's what the error message says. The compiler is correct, your code is broken.
[Bug c++/80244] New: [6/7 Regression] ICE with attribute in template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80244
Bug ID: 80244
Summary: [6/7 Regression] ICE with attribute in template alias
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following code snippet triggers an ICE since GCC 6.1.0:
==
template struct A {};
template using B = A<__underlying_type(T) [[gnu::aligned(4)]]>;
==
bug.cc:3:67: internal compiler error: in layout_type, at stor-layout.c:2386
template using B = A<__underlying_type(T) [[gnu::aligned(4)]]>;
^
0xd5a9bf layout_type(tree_node*)
../../gcc/gcc/stor-layout.c:2386
0x1027845 type_hash_canon(unsigned int, tree_node*)
../../gcc/gcc/tree.c:7131
0x1027d2d build_type_attribute_qual_variant(tree_node*, tree_node*, int)
../../gcc/gcc/tree.c:4875
0x7ce47d cp_build_type_attribute_variant(tree_node*, tree_node*)
../../gcc/gcc/cp/tree.c:4156
0x7dd9f2 strip_typedefs(tree_node*, bool*)
../../gcc/gcc/cp/tree.c:1580
0x6478ac canonicalize_type_argument
../../gcc/gcc/cp/pt.c:7331
0x68db53 coerce_template_parms
../../gcc/gcc/cp/pt.c:8128
0x6947ea lookup_template_class_1
../../gcc/gcc/cp/pt.c:8664
0x6947ea lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:9009
0x7a7a8d finish_template_type(tree_node*, tree_node*, int)
../../gcc/gcc/cp/semantics.c:3151
0x7308f4 cp_parser_template_id
../../gcc/gcc/cp/parser.c:15491
0x730b0f cp_parser_class_name
../../gcc/gcc/cp/parser.c:21949
0x72d572 cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:6285
0x72d572 cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:5971
0x732b23 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:16822
0x7208ad cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16495
0x72f1e2 cp_parser_type_specifier_seq
../../gcc/gcc/cp/parser.c:20777
0x724e61 cp_parser_type_id_1
../../gcc/gcc/cp/parser.c:20623
0x72c4f0 cp_parser_type_id
../../gcc/gcc/cp/parser.c:20693
0x72c4f0 cp_parser_alias_declaration
../../gcc/gcc/cp/parser.c:18589
Please submit a full bug report, [etc.]
In GCC 5 and before the code was accepted.
[Bug c++/80243] c++ doesn't allow function to return a struct (or object?) - same thing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80243
--- Comment #1 from Jim Michaels ---
#include
#include
typedef struct {std::string s;int i;} Structsb;
Structsb fn(std::string s1, int i1) {
return {s1,i1};
}
int main() {}
Structsb structsb=fn("string",1);
return strustsb.i;
}
[Bug rtl-optimization/80193] [7 Regression] ICE on valid (but hairy) C code at -O3 on x86_64-linux-gnu: in check_allocation, at ira.c:2563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80193 --- Comment #6 from Vladimir Makarov --- Author: vmakarov Date: Tue Mar 28 20:55:38 2017 New Revision: 246554 URL: https://gcc.gnu.org/viewcvs?rev=246554&root=gcc&view=rev Log: 2017-03-28 Vladimir Makarov PR rtl-optimization/80193 * ira.c (ira): Do not check allocation for LRA. 2017-03-28 Vladimir Makarov PR rtl-optimization/80193 * gcc.target/i386/pr80193.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr80193.c Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/80193] [7 Regression] ICE on valid (but hairy) C code at -O3 on x86_64-linux-gnu: in check_allocation, at ira.c:2563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80193 --- Comment #5 from Vladimir Makarov --- The allocation is correct. Simply there is no rebuilding conflicts after generations moves on region edges (there are a lot of them, about 100) for LRA as LRA does not need the conflict info from IRA. The patch will be committed soon.
[Bug c++/80243] New: c++ doesn't allow function to return a struct (or object?) - same thing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80243
Bug ID: 80243
Summary: c++ doesn't allow function to return a struct (or
object?) - same thing
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jmichae3 at yahoo dot com
Target Milestone: ---
c++ doesn't allow function to return a struct. and notice a class is a struct
with a constructur function and destructor function but has auto-start.
#include
#include
typedef struct {std::string s;int i;} Structsb;
Structsb fn(std::string s1, int i1) {
return {s1,i1};
}
I should be able to do this with objects which are instantiations of a class
too.
[Bug c++/80241] New: [5/6/7 Regression] Broken error message + ICE with invalid attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80241
Bug ID: 80241
Summary: [5/6/7 Regression] Broken error message + ICE with
invalid attribute
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: diagnostic, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid code snippet triggers a broken error message
followed by an ICE since GCC 5.2.0:
=
template struct A
{
[[gnu::aligned (alignof(A))...]] char c;
};
A a;
=
bug.cc:3:30: error: expansion pattern '#'tree_list' not supported by
dump_expr#' contains no argument packs
[[gnu::aligned (alignof(A))...]] char c;
^~~
bug.cc:3:41: internal compiler error: tree check: expected tree_list, have
error_mark in is_late_template_attribute, at cp/decl2.c:1119
[[gnu::aligned (alignof(A))...]] char c;
^
0x100872c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9817
0x6e946d tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3064
0x6e946d is_late_template_attribute
../../gcc/gcc/cp/decl2.c:1119
0x6e946d splice_template_attributes
../../gcc/gcc/cp/decl2.c:1179
0x6e946d save_template_attributes
../../gcc/gcc/cp/decl2.c:1205
0x6e946d cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/gcc/cp/decl2.c:1420
0x6f036d grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/gcc/cp/decl2.c:951
0x71da83 cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:23392
0x71e63a cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:22941
0x71e63a cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:22094
0x720bf1 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:22346
0x720bf1 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16419
0x721ada cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13326
0x71d275 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:26621
0x73f19c cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:26315
0x73ee2c cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:26550
0x73ee2c cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:26569
0x746fa9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12445
0x748abb cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12372
0x748d9a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4366
Please submit a full bug report, [etc.]
[Bug c++/80240] New: cannot dynamic_cast variable to intmax_t from variable of type intmax_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80240
Bug ID: 80240
Summary: cannot dynamic_cast variable to intmax_t from variable
of type intmax_t
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jmichae3 at yahoo dot com
Target Milestone: ---
error: cannot dynamic_cast 'index' (of type 'intmax_t {aka long long int}') to
type 'intmax_t {aka long long int}' (target is not pointer or reference)
result=multiplier*dynamic_cast(base)+dynamic_cast(index);
index is of type intmax_t. I should not be getting this error. to you this
might look stupid, but there's a compiler bug and it needs to be paid attention
to, compiler should not be throwing errors on this line.
[Bug go/80226] ICE gimple-expr.c:474 on Go function returning multiple empty struct/array values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80226 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ian Lance Taylor --- Fixed. Thanks.
[Bug go/80226] ICE gimple-expr.c:474 on Go function returning multiple empty struct/array values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80226 --- Comment #2 from ian at gcc dot gnu.org --- Author: ian Date: Tue Mar 28 20:08:31 2017 New Revision: 246553 URL: https://gcc.gnu.org/viewcvs?rev=246553&root=gcc&view=rev Log: PR go/80226 * go-gcc.cc (Gcc_backend::return_statement): Check for void_type_node when checking result size. Modified: trunk/gcc/go/ChangeLog trunk/gcc/go/go-gcc.cc
[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #30 from Jerry DeLisle --- Agree, closing. PR78670 will have some followup for READ related issues. Fixed on trunk.
[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670 Bug 78670 depends on bug 78661, which changed state. Bug 78661 Summary: [OOP] Namelist output missing object designator under DTIO https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #20 from Jerry DeLisle --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #19) > >> [...] >> >> Here's the output I get: >> >> 63 >> >> 65 >> >> Rainer > > So its internal units, aka a string. and its not detecting the EOR. I will > have to think on this a bit and get back a little later. If you are OK , I > will > go off list with you to spare everyone the back and forth on here. Sure, fine with me. Thanks. Rainer
[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #20 from Jerry DeLisle --- (In reply to r...@cebitec.uni-bielefeld.de from comment #19) > [...] > > Here's the output I get: > > 63 > > 65 > > Rainer So its internal units, aka a string. and its not detecting the EOR. I will have to think on this a bit and get back a little later. If you are OK , I will go off list with you to spare everyone the back and forth on here.
[Bug target/80239] [7 regression] 9% regression on dhrystone when targetting Cortex-M7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80239 --- Comment #3 from Thomas Preud'homme --- (In reply to Richard Earnshaw from comment #2) > is the diff you show backwards? Otherwise the new code looks distinctly > better. Yes it is, sorry. Diff good bad is: - add r5, sp, #16 + add r0, sp, #24 str r1, [lr, #4]@ unaligned str r2, [lr, #8]@ unaligned + mov r5, r0 + str r0, [sp, #4]
[Bug target/80239] [7 regression] 9% regression on dhrystone when targetting Cortex-M7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80239 --- Comment #2 from Richard Earnshaw --- is the diff you show backwards? Otherwise the new code looks distinctly better.
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #84 from Bernd Edlinger ---
I think the patch should also handle
arrays of unions like:
union BB {
unsigned char x[10];
};
struct B {
BB x[16];
};
struct A {
B b;
};
A a1, a2;
void test()
{
a1.b = a2.b;
}
compiles to:
; Function void test() (_Z4testv, funcdef_no=0, decl_uid=2384, cgraph_uid=0,
symbol_order=2)
void test() ()
{
[0.00%]:
a1.b = a2.b;
return;
}
while in this example
struct B {
unsigned char x[16];
};
struct A {
B b;
};
A a1, a2;
void test()
{
a1.b = a2.b;
}
compiles to:
;; Function void test() (_Z4testv, funcdef_no=0, decl_uid=2348, cgraph_uid=0,
symbol_order=2)
void test() ()
{
[0.00%]:
MEM[(void *)&a1] = MEM[(void *)&a2];
return;
}
which is probably unnecessary, because all valid examples
used a union with an array of unsigned char. Right?
[Bug rtl-optimization/80193] [7 Regression] ICE on valid (but hairy) C code at -O3 on x86_64-linux-gnu: in check_allocation, at ira.c:2563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80193 --- Comment #4 from Vladimir Makarov --- I've reproduced it and started to investigate. It is a very complicated example. I can not even say right now what is wrong, the check or the allocation result. I guess it will take some time only to investigate it. In the best scenario, it will be fixed on this week.
[Bug target/24012] [5/6/7 regression] #define _POSIX_C_SOURCE breaks #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012 --- Comment #24 from Jonathan Wakely --- The new tests fail on AIX 7.2: FAIL: 21_strings/headers/cwchar/24012.cc (test for excess errors) Excess errors: /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:224: error: '::wcstold' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:233: error: '::wcstoll' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:234: error: '::wcstoull' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:242: error: '__gnu_cxx::wcstold' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:243: error: '__gnu_cxx::wcstoll' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:244: error: '__gnu_cxx::wcstoull' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:268: error: '::wcstof' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:279: error: '::vfwscanf' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:290: error: '::vswscanf' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:300: error: '::vwscanf' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:310: error: '__gnu_cxx::wcstof' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:313: error: '__gnu_cxx::vfwscanf' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:316: error: '__gnu_cxx::vswscanf' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:319: error: '__gnu_cxx::vwscanf' has not been declared This isn't caused by the patch though, it always failed, for the same reason as FreeBSD. It doesn't pass with the patch because (unlike the BSDs) there's no dynamic check in config/os/aix/os_defines.h It looks like _ISOC99_SOURCE is the relevant macro for AIX. If that's not defined we don't get the C99 functions from
[Bug fortran/80046] Explicit interface required: pointer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80046 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Known to work|4.8.5 | Summary|[5/6/7 Regression] Explicit |Explicit interface |interface required for at |required: pointer argument |(1): pointer argument | --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) > The only 'bug' is that gfortran does not reject the first one as well. ( ... therefore it's not a regression.) Here is a slightly reduced test for that case, based on the original example: program p implicit none type :: Node_t procedure(), nopass, pointer :: cloneProc end type interface subroutine NodeCloner( tgt, src ) import Node_t type(Node_t), pointer, intent(out) :: tgt type(Node_t), intent(in) :: src end subroutine end interface type(Node_t) :: node procedure(NodeCloner), pointer :: cloneNode cloneNode => node%cloneProc end
[Bug fortran/80046] [5/6/7 Regression] Explicit interface required for at (1): pointer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80046 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Joachim Herb from comment #0) > Is this an intended behavior? Well, at least the error on the second procptr assignment is intended behavior. See PR 56261 for discussion. The only 'bug' is that gfortran does not reject the first one as well. > If so, what would be the correct way to handle such pointers? The correct way would be the one pointed out by Dominique in comment #1, namely giving 'cloneProc' an explicit interface.
[Bug libstdc++/62045] [5 Regression] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 Jonathan Wakely changed: What|Removed |Added Summary|[5/6 Regression]|[5 Regression] |__gnu_pbds::priority_queue< |__gnu_pbds::priority_queue< |int, less, |int, less, |binary_heap_tag> is too |binary_heap_tag> is too |slow|slow --- Comment #13 from Jonathan Wakely --- Also fixed for 6.4 now.
[Bug libstdc++/80137] [6/7 Regression] std::generate_canonical calls its generator a non-constant number of times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80137 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jonathan Wakely --- And also for 6.4
[Bug c++/80238] genmatch.c:(.text.startup+0x66c6): undefined reference to `operator delete(void*, unsigned long)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80238 --- Comment #1 from Jonathan Wakely --- That's the sized-deallocation function which was new in GCC 5. How did you configure gcc? What is your existing compiler that you're using to build it?
[Bug libstdc++/80137] [6/7 Regression] std::generate_canonical calls its generator a non-constant number of times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80137 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Tue Mar 28 17:18:42 2017 New Revision: 246549 URL: https://gcc.gnu.org/viewcvs?rev=246549&root=gcc&view=rev Log: PR libstdc++/80137 use std::nextafter instead of looping PR libstdc++/80137 * include/bits/random.tcc (generate_canonical): Use std::nextafter or numeric_limits::epsilon() to reduce out-of-range values. * testsuite/26_numerics/random/uniform_real_distribution/operators/ 64351.cc: Verify complexity requirement is met. Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/bits/random.tcc branches/gcc-6-branch/libstdc++-v3/testsuite/26_numerics/random/uniform_real_distribution/operators/64351.cc
[Bug libstdc++/62045] [5/6 Regression] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #12 from Jonathan Wakely --- Author: redi Date: Tue Mar 28 17:18:37 2017 New Revision: 246548 URL: https://gcc.gnu.org/viewcvs?rev=246548&root=gcc&view=rev Log: PR libstdc++/62045 fix O(N) insertion in pd_ds binary heap Backport from mainline 2017-03-15 Xi Ruoyao PR libstdc++/62045 * include/ext/pb_ds/qdetail/binary_heap_/binary_heap_.hpp (is_heap): Remove. (push_heap): Remove the wrong checking using is_heap. (make_heap): Remove the assertion using is_heap. * include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp (modify): Ditto. (resize_for_insert_if_needed): Add PB_DS_ASSERT_VALID after calling make_heap. Backport from mainline 2017-03-15 Jonathan Wakely PR libstdc++/62045 * testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc: New test. * testsuite/ext/pb_ds/regression/priority_queues.cc: Fix copy&paste error in comment. Added: branches/gcc-6-branch/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp branches/gcc-6-branch/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp branches/gcc-6-branch/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queues.cc
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 Jonathan Wakely changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #9 from Jonathan Wakely --- (In reply to Dominik Schmidt from comment #8) > Do you still need a regular gdb backtrace without asan? Looks the same to > me, but I can provide it anyway. This is OK. > `ldd /tmp/crashTest ` prints: > linux-vdso.so.1 (0x7efa3000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x76e1) > libm.so.6 => /lib/libm.so.6 (0x76d8f000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x76d63000) > libc.so.6 => /lib/libc.so.6 (0x76c27000) > /lib/ld-linux-armhf.so.3 (0x76f51000) > > Yes, I'm pretty sure this is the correct libstdc++. That was confirmed on IRC: lrwxrwxrwx1 root root 19 Feb 28 18:29 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.22 I don't see anything obviously wrong in the libstdc++ code, and can't reproduce this on x86_64, so it might be a misoptimization.
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #10 from Jonathan Wakely --- Oh, but it only happens at -O0, so maybe target specific.
[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 --- Comment #29 from janus at gcc dot gnu.org --- AFAICS r246546 should fully fix this PR, so I think it can be closed. Do you agree, Jerry?
[Bug rtl-optimization/80197] pgo dramatically pessimizes scimark2 MonteCarlo benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80197 --- Comment #5 from Alexander Monakov --- On trunk, manually fixing up inlining is not enough: trunk additionally needs -fno-tracer, otherwise crucial if-conversion of 'if (k < 0) k += m1;' is prevented.
[Bug target/80225] ICE when using =@cc output operand incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80225
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |7.0
--- Comment #2 from Uroš Bizjak ---
This is fixed in gcc-7:
pr80225.c: In function ‘int main()’:
pr80225.c:5:61: error: invalid 'asm': invalid use of asm flag output
asm("lar %0, %1;" : "=@ccz"(z), "=r"(ar) : "rm"(0x1234));
As this is ICE-on-invalid bug, there is no plan for a backport.
[Bug target/57796] AVX2 gather vectorization: code bloat and reduction of performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796 --- Comment #10 from vincenzo Innocente --- added a self contained "benchmark" on my machine [innocent@vinavx3 ctest]$ c++ -Ofast -Wall SparseOnly.c -march=native ; time ./a.out 0.496u 0.000s 0:00.49 100.0%0+0k 0+0io 0pf+0w [innocent@vinavx3 ctest]$ c++ -O2 -Wall SparseOnly.c -march=native ; time ./a.out 0.411u 0.000s 0:00.41 100.0%0+0k 0+0io 0pf+0w [innocent@vinavx3 ctest]$ c++ -O3 -Wall SparseOnly.c -march=native ; time ./a.out 0.413u 0.000s 0:00.41 100.0%0+0k 0+0io 0pf+0w
[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 --- Comment #28 from janus at gcc dot gnu.org --- Author: janus Date: Tue Mar 28 17:01:05 2017 New Revision: 246546 URL: https://gcc.gnu.org/viewcvs?rev=246546&root=gcc&view=rev Log: 2017-03-28 Janus Weil PR fortran/78661 * trans-io.c (transfer_namelist_element): Perform a polymorphic call to a DTIO procedure if necessary. 2017-03-28 Janus Weil PR fortran/78661 * gfortran.dg/dtio_25.f90: Modified test case. * gfortran.dg/dtio_27.f90: New test case. 2017-03-28 Janus Weil PR fortran/78661 * io/write.c (nml_write_obj): Build a class container only if necessary. Added: trunk/gcc/testsuite/gfortran.dg/dtio_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dtio_25.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/write.c
[Bug target/57796] AVX2 gather vectorization: code bloat and reduction of performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796 --- Comment #9 from vincenzo Innocente --- Created attachment 41070 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41070&action=edit self contained benchmark of scimark2 SparseMat must content is not randomized param must be modified by hand in the main
[Bug c++/80178] Class with deleted copy and move constructors uses wrong argument passing ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80178 Jonathan Wakely changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #2 from Jonathan Wakely --- This example came from a Clang discussion, and they might also be changing how they handle this. We might want to bring it up on the cxxabi list if there's any doubt what the right behaviour is. CCing Richard, as I discussed it with him last week.
[Bug target/80239] [7 regression] 9% regression on dhrystone when targetting Cortex-M7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80239 Thomas Preud'homme changed: What|Removed |Added Keywords||ra Component|rtl-optimization|target Target Milestone|--- |7.0
[Bug rtl-optimization/80239] [7 regression] 9% regression on dhrystone when targetting Cortex-M7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80239
Thomas Preud'homme changed:
What|Removed |Added
Keywords|ra |
Component|target |rtl-optimization
Target Milestone|7.0 |---
--- Comment #1 from Thomas Preud'homme ---
Below is my analysis of the issue. I have a patch for that as well but
unfortunately it only works when applied at r235184 and same goes for reverting
r235184.
After changing:
(insn 608 40 41 2 (set (reg/f:SI 223)
(reg/f:SI 419)) dhry_1.c:101 794 {*thumb2_movsi_insn}
(expr_list:REG_EQUAL (plus:SI (reg/f:SI 102 sfp)
(const_int -64 [0xffc0]))
(nil)))
into:
(insn 608 40 41 2 (set (reg/f:SI 223)
(plus:SI (reg/f:SI 102 sfp)
(const_int 16 [0x10]))) dhry_1.c:101 794 {*thumb2_movsi_insn}
(expr_list:REG_EQUAL (plus:SI (reg/f:SI 102 sfp)
(const_int -64 [0xffc0]))
(nil)))
in curr_insn_transform (), process_alt_operands () choose the alternative with
the memory constraint (alternative 5) which leads the second operand to be of
class NO_REGS. It later reloads with:
(insn 638 0 0 (set (reg:SI 431)
(plus:SI (reg/f:SI 102 sfp)
(const_int 16 [0x10]))) 4 {*arm_addsi3}
(nil))
(insn 608 40 41 2 (set (reg/f:SI 223)
(plus:SI (reg/f:SI 102 sfp)
(const_int 16 [0x10]))) dhry_1.c:101 794 {*thumb2_movsi_insn}
(expr_list:REG_EQUAL (plus:SI (reg/f:SI 102 sfp)
(const_int -64 [0xffc0]))
(nil)))
Then when analyzing insn 638, process_alt_operands decides that reg 431 needs
to be reloaded because its class (NO_REGS, inherited from the analysis of insn
638) does not intersect with ALL_REGS according to in_class_p ().
I believe the problem is that the equivalence stays with NO_REGS as register
class instead of being given that of a register (since it's going to be
reloaded into a register). My patch follows that path and as said above works
just after r235184 but the performance remains worse on recent trunk.
When looking at code generated by recent trunk, the issue mentionned in the
original post is not there which suggest that something else is at play.
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 --- Comment #26 from uros at gcc dot gnu.org --- Author: uros Date: Tue Mar 28 16:51:00 2017 New Revision: 246543 URL: https://gcc.gnu.org/viewcvs?rev=246543&root=gcc&view=rev Log: PR target/53383 * config/i386/i386.c (ix86_option_override_internal): Always allow -mincoming-stack-boundary=3 for 64-bit targets. testsuite/ChangeLog: PR target/53383 * gcc.target/i386/pr53383-1.c (dg-options): Remove -mno-sse. * gcc.target/i386/pr53383-2.c (dg-options): Ditto. * gcc.target/i386/pr53383-3.c (dg-options): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr53383-1.c trunk/gcc/testsuite/gcc.target/i386/pr53383-2.c trunk/gcc/testsuite/gcc.target/i386/pr53383-3.c
[Bug target/80239] [7 regression] 9% regression on dhrystone when targetting Cortex-M7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80239 Andrew Pinski changed: What|Removed |Added Keywords||ra Component|rtl-optimization|target Target Milestone|--- |7.0
[Bug rtl-optimization/80239] New: [7 regression] 9% regression on dhrystone when targetting Cortex-M7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80239 Bug ID: 80239 Summary: [7 regression] 9% regression on dhrystone when targetting Cortex-M7 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org Target Milestone: --- Target: arm-none-eabi Hi, Performance for dhrystone has regressed by 9% after commit r235184 when targeting Cortex-M7 with -O3 -fno-inline. I've tracked this to a couple of changes likes the following: - add r0, sp, #24 + add r5, sp, #16 str r1, [lr, #4]@ unaligned str r2, [lr, #8]@ unaligned - mov r5, r0 - str r0, [sp, #4] Where [sp, #4] appears to never be loaded again. The mov itself is problematic as well as removing all the extra str still made the code slower.
[Bug c++/80178] Class with deleted copy and move constructors uses wrong argument passing ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80178 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Jason Merrill --- Hmm, I don't see anything in the ABI about deleted constructors, and a deleted function isn't non-trivial (nor trivial). That said, I agree that it makes sense for a class with only deleted copy/move ctors to be passed by invisible reference in the case of copy-list-initialization.
[Bug tree-optimization/79534] [7 Regression] tree-ifcombine aarch64 performance regression with trunk@245151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534 James Greenhalgh changed: What|Removed |Added CC||jgreenhalgh at gcc dot gnu.org --- Comment #3 from James Greenhalgh --- I'm unable to reproduce the performance difference on the systems I have access to, comparing r245150 against r245151.
[Bug c++/80238] New: genmatch.c:(.text.startup+0x66c6): undefined reference to `operator delete(void*, unsigned long)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80238 Bug ID: 80238 Summary: genmatch.c:(.text.startup+0x66c6): undefined reference to `operator delete(void*, unsigned long)' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: programmist.linuks at mail dot ru Target Milestone: --- Created attachment 41069 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41069&action=edit log file I compile gcc version 6.3.0. After an hour of compilation, I had an error, I attach a detailed log. (I could not translate it, do not pay any attention to Russian symbols)
[Bug libstdc++/80137] [6/7 Regression] std::generate_canonical calls its generator a non-constant number of times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80137 Jonathan Wakely changed: What|Removed |Added Version|unknown |6.3.1 Target Milestone|--- |6.4 --- Comment #6 from Jonathan Wakely --- Fixed on trunk so far.
[Bug target/80103] ICE in output_1144, at config/rs6000/vsx.md:2298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80103 kelvin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from kelvin at gcc dot gnu.org --- The committed patch resolves the error.
[Bug bootstrap/80200] decNumber.c : error : #include_next is a GCC extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80200 --- Comment #4 from Roman --- Sorry, here is the output of gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/roman/gcc-source/configure Thread model: posix gcc version 7.0.1 20170304 (experimental) (GCC) Best regards, Roman
[Bug libstdc++/80137] [6/7 Regression] std::generate_canonical calls its generator a non-constant number of times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80137 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Tue Mar 28 16:09:49 2017 New Revision: 246542 URL: https://gcc.gnu.org/viewcvs?rev=246542&root=gcc&view=rev Log: PR libstdc++/80137 use std::nextafter instead of looping PR libstdc++/80137 * include/bits/random.tcc (generate_canonical): Use std::nextafter or numeric_limits::epsilon() to reduce out-of-range values. * testsuite/26_numerics/random/uniform_real_distribution/operators/ 64351.cc: Verify complexity requirement is met. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.tcc trunk/libstdc++-v3/testsuite/26_numerics/random/uniform_real_distribution/operators/64351.cc
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #8 from Dominik Schmidt --- -fsanitize=address -g: ==539==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ebcac10 at pc 0x00013d20 bp 0x7ebca90c sp 0x7ebca904 READ of size 16 at 0x7ebcac10 thread T0 #0 0x13d1f in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair const&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/ext/new_allocator.h:120 #1 0x13b0f in void std::allocator_traits > > >::construct, std::pair const&>(std::allocator > >&, std::pair*, std::pair const&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/alloc_traits.h:455 #2 0x13a27 in void std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_construct_node const&>(std::_Rb_tree_node >*, std::pair const&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:543 #3 0x1381b in std::_Rb_tree_node >* std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_create_node const&>(std::pair const&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:560 #4 0x1352f in std::_Rb_tree_node >* std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node::operator() const&>(std::pair const&) const /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:473 #5 0x12b23 in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_ const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node>(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::pair const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:1535 #6 0x11953 in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique_ const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node>(std::_Rb_tree_const_iterator >, std::pair const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:2004 #7 0x11337 in void std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique const*>(std::pair const*, std::pair const*) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:2250 #8 0x110a7 in std::map, std::allocator > >::map(std::initializer_list >, std::less const&, std::allocator > const&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_map.h:215 #9 0x13e87 in main ../main.cpp:15 #10 0x7670783f in __libc_start_main (/lib/libc.so.6+0x1683f) Address 0x7ebcac10 is located in stack of thread T0 at offset 112 in frame #0 0x13d8f in main ../main.cpp:11 This frame has 2 object(s): [32, 56) 'j1' [96, 120) 'j3' <== Memory access at offset 112 partially overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/ext/new_allocator.h:120 in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair const&) Shadow bytes around the buggy address: 0x2fd79530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd79540: f1 f1 f1 f1 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 0x2fd79550: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 0x2fd79560: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd79570: 00 00 00 00 f1 f1 f1 f1 00 00 00 f4 f2 f2 f2 f2 =>0x2fd79580: 00 00[00]f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 0x2fd79590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd795a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd795b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd795c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd795d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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 Contain
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 --- Comment #83 from Jason Merrill --- (In reply to Jonathan Wakely from comment #81) > Boost 1.63 has an array of char. Seems they should change that to unsigned char (or std::byte).
[Bug target/80211] ICE in curr_insn_transform, at lra-constraints.c:3816
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80211 --- Comment #1 from Vladimir Makarov --- I can not reproduce it. With the mentioned options I have warning: implicit declaration of function '__builtin_dfp_dtstsfi_ov'; did you mean '__builtin_fpclassify`? The option set has no sense for me too. -mpower9-dform-vector implements new load insns for power9 but -mcpu=401 sets up an ancient ppc architecture. They are exclusive options. Even if the bug is reproducable, the PR should be marked as P4, IMHO.
[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #18 from Jerry DeLisle --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #17) >> >> ro@colima 27 > >> LD_LIBRARY_PATH=../../../sparc-sun-solaris2.12/sparcv9/libgfortran/.libs >> ./dtio_26.exe >> >> >> >> Program aborted. Backtrace: >> Abort > > I am sorry, I was not being clear. There are four similar lines that need to > replace abort with the print. We are invoking the Fortran ABORT procedure when > ever a test condition is not met. So I need to see what the condition is saved > in the iomsg variable and which line without aborting. Ah, I see. > So something like this in place of the lines starting at line 57: [...] Here's the output I get: 63 65 Rainer
[Bug libstdc++/80137] [6/7 Regression] std::generate_canonical calls its generator a non-constant number of times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80137 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #4 from Jonathan Wakely --- Ah, I tried that but not halving the epsilon, and so got a different result that I wasn't happy with. I sugested _RealType(0) because if the analysis at http://stackoverflow.com/a/25669510 is correct then the current code is biased against 0, so using it when we round up to 1.0 would offset that, to a greater or lesser extent. I don't know which :-) I'll go with your suggestion, thanks.
[Bug c/80237] New: float to double conversion is not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80237
Bug ID: 80237
Summary: float to double conversion is not optimized away
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
i get suboptimal code for
__attribute__((noinline))
static float f(float x)
{
return x*x;
}
static double g(float x)
{
return x>0 ? f(x) : x+1.0;
}
float foo(float x)
{
return g(x);
}
i expected a tail call because for float x, (float)(double)x conversion is a
nop, but with -O3 i get
f:
mulss %xmm0, %xmm0
ret
foo:
ucomiss .LC0(%rip), %xmm0
jbe .L8
callf / why not tail call?
cvtss2sd%xmm0, %xmm0
cvtsd2ss%xmm0, %xmm0
ret
.L8:
cvtss2sd%xmm0, %xmm0
addsd .LC1(%rip), %xmm0
cvtsd2ss%xmm0, %xmm0
ret
.LC0:
.long 0
.LC1:
.long 0
.long 1072693248
[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #18 from Jerry DeLisle --- (In reply to r...@cebitec.uni-bielefeld.de from comment #17) > > ro@colima 27 > > LD_LIBRARY_PATH=../../../sparc-sun-solaris2.12/sparcv9/libgfortran/.libs > ./dtio_26.exe > > > > Program aborted. Backtrace: > Abort I am sorry, I was not being clear. There are four similar lines that need to replace abort with the print. We are invoking the Fortran ABORT procedure when ever a test condition is not met. So I need to see what the condition is saved in the iomsg variable and which line without aborting. So something like this in place of the lines starting at line 57: read(unit=10, fmt='(dt)', iostat=istat, iomsg=imsg) foo if (imsg.ne."End of record") print *, 57, imsg rewind(10) read(unit=10, fmt=*, iostat=istat, iomsg=imsg) foo if (imsg.ne."End of record") print *, 60, imsg s = "hello" read( unit=s, fmt='(dt)', iostat=istat, iomsg=imsg) foo if (imsg.ne."End of record") print *, 63, imsg read( unit=s, fmt=*, iostat=istat, iomsg=imsg) foo if (imsg.ne."End of record") print *, 65 end program p
[Bug target/24012] [5/6/7 regression] #define _POSIX_C_SOURCE breaks #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012 --- Comment #23 from Jonathan Wakely --- Created attachment 41068 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41068&action=edit Use dynamic checks for C99 functions This fixes it and passes the testsuite on GNU/Linux and FreeBSD 11.0-RELEASE. Even though this bug is a regression, this is too late in the gcc-7 process to make a change like this. I'll commit it early for gcc-8 and backport it if it doesn't cause any problems.
[Bug target/24012] [5/6/7 regression] #define _POSIX_C_SOURCE breaks #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012
--- Comment #22 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #20)
> Also, I assume this is only a problem for -std=c++98 or -std=gnu++98,
> because if the system headers don't declare those functions for C++11 and
> later dialects then that's a bug in those system headers.
That's not true, because we (rather bizarrely) do this:
#if _GLIBCXX_HAVE_WCSTOF
#undef wcstof
#endif
namespace std {
#if _GLIBCXX_HAVE_WCSTOF
using ::wcstof
#endif
}
#if __cplusplus >= 201103L
namespace std {
#if _GLIBCXX_HAVE_WCSTOF
using std::wcstof
#endif
}
#endif
This means we unconditionally try to declare them in namespace std, then for
C++11 redeclare std::wcstof as std:wcstof (???).
[Bug tree-optimization/80218] [6/7 Regression] tree-call-cdce does not update block frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80218 --- Comment #3 from Jeffrey A. Law --- Author: law Date: Tue Mar 28 15:14:36 2017 New Revision: 246538 URL: https://gcc.gnu.org/viewcvs?rev=246538&root=gcc&view=rev Log: gcc/ PR tree-optimization/80218 * tree-call-cdce.c (shrink_wrap_one_built_in_call_with_conds): Update block frequencies and counts. gcc/testsuite/ PR tree-optimization/80218 * gcc.dg/pr80218.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr80218.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-call-cdce.c
[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80221
--- Comment #11 from Martin Sebor ---
That would work too. Yet another possibility is to surround all the dg-message
directives that apply to the same line in a pair of new directives (analogously
to dg-{begin,end}-multiline-output):
foobar;
/* { dg-begin-same-line-output .-1 }
...
{ dg-warning "warning for foobar" }
...
{ dg-message "note for foobar" }
...
{ dg-error "error for foobar" }
...
{ dg-end-same-line-output } */
[Bug c++/70387] -fnon-call-exceptions has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70387 --- Comment #5 from jwjagersma at gmail dot com --- Bumping this, I hope it will be resolved someday. I found a reference to the same issue, with another test case using posix signal handlers: https://cygwin.com/ml/cygwin/2010-07/msg00195.html This claims it used to work on 3.3.4, and failed from 4.3.4 on.
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #7 from Jonathan Wakely --- Also please build with -g so the backtraces and stack info are more useful.
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #6 from Jonathan Wakely --- Are you using the right libstdc++.so that matches the gcc 6.3.0 compiler? What does "ldd /tmp/crashTest" show?
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #5 from Dominik Schmidt --- -fsanitize=undefined does not make any difference.
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #4 from Dominik Schmidt --- AddressSanitizer output: = ==597==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7e842bd0 at pc 0x00013d20 bp 0x7e8428dc sp 0x7e8428d4 READ of size 16 at 0x7e842bd0 thread T0 #0 0x13d1f in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair const&) (/tmp/crashTest+0x13d1f) #1 0x13b0f in void std::allocator_traits > > >::construct, std::pair const&>(std::allocator > >&, std::pair*, std::pair const&) (/tmp/crashTest+0x13b0f) #2 0x13a27 in void std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_construct_node const&>(std::_Rb_tree_node >*, std::pair const&) (/tmp/crashTest+0x13a27) #3 0x1381b in std::_Rb_tree_node >* std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_create_node const&>(std::pair const&) (/tmp/crashTest+0x1381b) #4 0x1352f in std::_Rb_tree_node >* std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node::operator() const&>(std::pair const&) const (/tmp/crashTest+0x1352f) #5 0x12b23 in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_ const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node>(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::pair const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node&) (/tmp/crashTest+0x12b23) #6 0x11953 in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique_ const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node>(std::_Rb_tree_const_iterator >, std::pair const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node&) (/tmp/crashTest+0x11953) #7 0x11337 in void std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique const*>(std::pair const*, std::pair const*) (/tmp/crashTest+0x11337) #8 0x110a7 in std::map, std::allocator > >::map(std::initializer_list >, std::less const&, std::allocator > const&) (/tmp/crashTest+0x110a7) #9 0x13e87 in main (/tmp/crashTest+0x13e87) #10 0x766cb83f in __libc_start_main (/test/crosscan-test/lib/libc.so.6+0x1683f) Address 0x7e842bd0 is located in stack of thread T0 at offset 112 in frame #0 0x13d8f in main (/tmp/crashTest+0x13d8f) This frame has 2 object(s): [32, 56) 'j1' [96, 120) 'j3' <== Memory access at offset 112 partially overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow (/tmp/crashTest+0x13d1f) in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair const&) Shadow bytes around the buggy address: 0x2fd08520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd08530: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x2fd08540: 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 0x2fd08550: 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f3 f3 f3 f3 0x2fd08560: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 =>0x2fd08570: 00 00 00 f4 f2 f2 f2 f2 00 00[00]f4 f3 f3 f3 f3 0x2fd08580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd08590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd085a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd085b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd085c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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 Left alloca redzone: ca Right alloca redzone:cb ==597==ABORTING
[Bug target/80225] ICE when using =@cc output operand incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80225 jwjagersma at gmail dot com changed: What|Removed |Added Target|x86_64-w64-mingw32 |x86_64-w64-mingw32, ||i686-w64-mingw32, ||i586-pc-msdosdjgpp --- Comment #1 from jwjagersma at gmail dot com --- I should mention I also reproduced this issue on i686-w64-mingw32 and i586-pc-msdosdjgpp (where I first encountered it). Since the error occurs in a function called "print_reg", I imagine this would be reproducible on any x86/amd64 target, as the flags register doesn't have a printable name.
[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80117 --- Comment #17 from Andreas Schwab --- Author: schwab Date: Tue Mar 28 14:22:29 2017 New Revision: 246536 URL: https://gcc.gnu.org/viewcvs?rev=246536&root=gcc&view=rev Log: Backport "Support for Ada on aarch64 with -mabi=ilp32" from trunk PR ada/80117 * system-linux-aarch64-ilp32.ads: New file. * gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS_COMMON): Rename from LIBGNAT_TARGET_PAIRS. (LIBGNAT_TARGET_PAIRS_32, LIBGNAT_TARGET_PAIRS_64): Define. (LIBGNAT_TARGET_PAIRS): Use LIBGNAT_TARGET_PAIRS_COMMON, and LIBGNAT_TARGET_PAIRS_64 or LIBGNAT_TARGET_PAIRS_32 for -mabi=lp64 or -mabi=ilp32, resp. Added: branches/gcc-6-branch/gcc/ada/system-linux-aarch64-ilp32.ads Modified: branches/gcc-6-branch/gcc/ada/ChangeLog branches/gcc-6-branch/gcc/ada/gcc-interface/Makefile.in
[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed.
[Bug tree-optimization/78542] [6 Regression] wrong code at -Og results in endless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78542 Bug 78542 depends on bug 78644, which changed state. Bug 78644 Summary: [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644 --- Comment #9 from Richard Biener --- Author: rguenth Date: Tue Mar 28 13:57:43 2017 New Revision: 246534 URL: https://gcc.gnu.org/viewcvs?rev=246534&root=gcc&view=rev Log: 2017-03-28 Richard Biener PR tree-optimization/78644 * tree-ssa-ccp.c (evaluate_stmt): When we may not use the value of a simplification result we may not use it at all. * gcc.dg/pr78644-1.c: New testcase. * gcc.dg/pr78644-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr78644-1.c trunk/gcc/testsuite/gcc.dg/pr78644-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 --- Comment #20 from Richard Biener --- (In reply to Thomas Preud'homme from comment #19) > (In reply to Richard Biener from comment #18) > > (In reply to Thomas Preud'homme from comment #17) > > > (In reply to rguent...@suse.de from comment #16) > > > > On Thu, 23 Mar 2017, thopre01 at gcc dot gnu.org wrote: > > > > > > > > > > Funnily this led back to the Cortex-M0+ reduced testcase. With the > > > > > patch in > > > > > comment #13 applied we can still see a difference in the push (one > > > > > register > > > > > pushed Vs 0). > > > > > > > > I can't reproduce zero pushes here I get three with/without > > > > -fno-code-hoisting. code hoisting hoists the two loads inside > > > > the switch before it so we have > > > > > > Ooops my apologize, it needs more flags indeed. -O2 -funroll-all-loops > > > shows > > > 2 registers pushed Vs 1 when -fno-code-hoisting is added. > > > > Still can't reproduce. I've configured with > > > > /space/rguenther/src/svn/gcc-7-branch/configure > > --target=arm-suse-linux-gnueabi --disable-libstdcxx-pch > > --enable-languages=c,c++ > > > > and am using > > > > ./cc1 -quiet cortex-m0plus_reproducer.c -O2 -mcpu=cortex-m0plus -mthumb -I > > include -fdump-tree-pre-details -fdump-tree-crited -fdump-tree-all > > -funroll-all-loops -fno-code-hoisting > > Oh my bad, I was still not clear enough. I meant using the Cortex-M0+ > testcase but build it for Cortex-M7. Hopefully with -mcpu=cortex-m7 you > should see a difference between with and without code hoisting. I do. Two pushes with code hoisting and three without. Changed -mcpu above to -mcpu=cortex-m7.
[Bug debug/80234] [7 Regression] ICE in splice_child_die at dwarfout.c:5265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80234 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Component|c++ |debug
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 --- Comment #19 from Thomas Preud'homme --- (In reply to Richard Biener from comment #18) > (In reply to Thomas Preud'homme from comment #17) > > (In reply to rguent...@suse.de from comment #16) > > > On Thu, 23 Mar 2017, thopre01 at gcc dot gnu.org wrote: > > > > > > > > Funnily this led back to the Cortex-M0+ reduced testcase. With the > > > > patch in > > > > comment #13 applied we can still see a difference in the push (one > > > > register > > > > pushed Vs 0). > > > > > > I can't reproduce zero pushes here I get three with/without > > > -fno-code-hoisting. code hoisting hoists the two loads inside > > > the switch before it so we have > > > > Ooops my apologize, it needs more flags indeed. -O2 -funroll-all-loops shows > > 2 registers pushed Vs 1 when -fno-code-hoisting is added. > > Still can't reproduce. I've configured with > > /space/rguenther/src/svn/gcc-7-branch/configure > --target=arm-suse-linux-gnueabi --disable-libstdcxx-pch > --enable-languages=c,c++ > > and am using > > ./cc1 -quiet cortex-m0plus_reproducer.c -O2 -mcpu=cortex-m0plus -mthumb -I > include -fdump-tree-pre-details -fdump-tree-crited -fdump-tree-all > -funroll-all-loops -fno-code-hoisting Oh my bad, I was still not clear enough. I meant using the Cortex-M0+ testcase but build it for Cortex-M7. Hopefully with -mcpu=cortex-m7 you should see a difference between with and without code hoisting.
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-03-28 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Usually this happens when you return a reference to an automatic variable thus invalidly extend an objects lifetime after destruction. Did you try -fsanitize=address or -fsanitize=undefined?
[Bug c++/80095] [5/6/7 Regression] ICE with this pointer in NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80095 Marek Polacek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Marek Polacek --- In store_init_value, we have decl: a type: const struct A & value: D.2291.p = (void *) &;, (const struct A &) &D.2291; but because type isn't CLASS_TYPE_P, we're not calling replace_placeholders. We cannot just call replace_placeholders, that would crash, because obj has type "const struct A &" whereas *t is "".
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
--- Comment #18 from Richard Biener ---
(In reply to Thomas Preud'homme from comment #17)
> (In reply to rguent...@suse.de from comment #16)
> > On Thu, 23 Mar 2017, thopre01 at gcc dot gnu.org wrote:
> > >
> > > Funnily this led back to the Cortex-M0+ reduced testcase. With the patch
> > > in
> > > comment #13 applied we can still see a difference in the push (one
> > > register
> > > pushed Vs 0).
> >
> > I can't reproduce zero pushes here I get three with/without
> > -fno-code-hoisting. code hoisting hoists the two loads inside
> > the switch before it so we have
>
> Ooops my apologize, it needs more flags indeed. -O2 -funroll-all-loops shows
> 2 registers pushed Vs 1 when -fno-code-hoisting is added.
Still can't reproduce. I've configured with
/space/rguenther/src/svn/gcc-7-branch/configure --target=arm-suse-linux-gnueabi
--disable-libstdcxx-pch --enable-languages=c,c++
and am using
./cc1 -quiet cortex-m0plus_reproducer.c -O2 -mcpu=cortex-m0plus -mthumb -I
include -fdump-tree-pre-details -fdump-tree-crited -fdump-tree-all
-funroll-all-loops -fno-code-hoisting
seeing 3 pushes:
fn1:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
movsr3, #0
push{r4, r5, lr}
I see softfp being used, not sure how I could change that (if that's what I'm
missing). Btw, -funroll-all-loops disqualifies this testcase ;)
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #2 from Dominik Schmidt --- Created attachment 41067 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41067&action=edit g++ --version --verbose
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #1 from Dominik Schmidt --- Created attachment 41066 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41066&action=edit part 2 of minimal example: bar.cpp
[Bug c++/80236] New: ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 Bug ID: 80236 Summary: ARM NEON: Crash in std::map Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: d...@dominik-schmidt.de Target Milestone: --- Created attachment 41065 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41065&action=edit part 1 of minimal example Hey, we are facing a crash when compiling the attached cpp files with: `arm-oe-linux-gnueabi-g++ -march=armv7ve -marm -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/home/build/openembedded_sdk/tmp/sysroots/raspberrypi3 -O0 ../bar.cpp ../main.cpp -o crashTest` The crash only happens with optimizations disabled, it already doesn't happen anymore with `-O1`. Also we could not trigger the faulty behavior in a single file, so this example is really the bare minimum we could find. gcc is installed from openembedded standard repository in version 6.3.0. Full `--version --verbose` output is provided via attachments. We could also reproduce this for another ARM target with GCC 5.4. I'm currently lacking more information on that myself, but I will try to provide it later on. The bt for 6.3 looks like this: (gdb) run Starting program: /tmp/crashTest Program received signal SIGSEGV, Segmentation fault. 0x000121bc in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair const&) () (gdb) bt #0 0x000121bc in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair const&) () #1 0x000120e0 in void std::allocator_traits > > >::construct, std::pair const&>(std::allocator > >&, std::pair*, std::pair const&) () #2 0x00011ffc in void std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_construct_node const&>(std::_Rb_tree_node >*, std::pair const&) () #3 0x00011df0 in std::_Rb_tree_node >* std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_create_node const&>(std::pair const&) () #4 0x00011c0c in std::_Rb_tree_node >* std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node::operator() const&>(std::pair const&) const () #5 0x00011728 in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_ const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node>(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::pair const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node&) () #6 0x00010f7c in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique_ const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node>(std::_Rb_tree_const_iterator >, std::pair const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node&) () #7 0x00010c8c in void std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique const*>(std::pair const*, std::pair const*) () #8 0x00010a90 in std::map, std::allocator > >::map(std::initializer_list >, std::less const&, std::allocator > const&) () #9 0x0001227c in main ()
[Bug fortran/80235] ICE: coarrays, submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80235 --- Comment #2 from Anton Shterenlikht --- Can be triggered also with gfortran7 directly: $ gfortran7 -c -fcoarray=lib m.f90 $ gfortran7 -c -fcoarray=lib sm.f90 sm.f90:22:0: maxfe = size( cgca_pfem_centroid_tmp%r, dim=2 ) internal compiler error: Segmentation fault
[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79390 Richard Biener changed: What|Removed |Added Known to work||6.3.1 Target Milestone|--- |7.0 Summary|10% performance drop in |[7 Regression] 10% |SciMark2 LU after r242550 |performance drop in ||SciMark2 LU after r242550 --- Comment #12 from Richard Biener --- On more recent trunk -fno-split-paths makes only a tiny difference (4882 vs. 4779 Mflops) while -ftree-loop-if-convert still results in 5432 Mflops. GCC 6 scores 5523 Mflops for me (-O3 -march=native on a Broadwell CPU). Marking as regression.
[Bug fortran/80235] ICE: coarrays, submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80235 --- Comment #1 from Anton Shterenlikht --- Created attachment 41064 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41064&action=edit submodule file
[Bug fortran/80235] New: ICE: coarrays, submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80235 Bug ID: 80235 Summary: ICE: coarrays, submodule Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mexas at bristol dot ac.uk Target Milestone: --- Created attachment 41063 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41063&action=edit module file $ caf -c m.f90 $ caf -c sm.f90 sm.f90:22:0: maxfe = size( cgca_pfem_centroid_tmp%r, dim=2 ) internal compiler error: Segmentation fault m.f90 - module, sm.f90 - submodule, both attached.
[Bug c++/80234] [7 Regression] ICE in splice_child_die at dwarfout.c:5265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80234 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-28 CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Target Milestone|--- |7.0 Summary|ICE in splice_child_die at |[7 Regression] ICE in |dwarfout.c:5265 |splice_child_die at ||dwarfout.c:5265 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r241753.
[Bug c++/80234] New: ICE in splice_child_die at dwarfout.c:5265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80234
Bug ID: 80234
Summary: ICE in splice_child_die at dwarfout.c:5265
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tim at array dot ca
Target Milestone: ---
Created attachment 41062
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41062&action=edit
preprocessed source
In the fedora rawhide GCC 7.0.1-0.12 build (x86_64), I'm getting an ICE in the
following code when generating debug info:
class foo
{
public:
static constexpr const char name_str[] = "foo";
virtual ~foo();
};
constexpr const char foo::name_str[];
foo::~foo()
{
}
% /usr/bin/c++ -g -std=gnu++17 -Wall -Wextra -o /home/tim/tmp/foo.o -c
/home/tim/Projects/ugp/src/ugp/UGF/Core/src/component/foo.cc
/home/tim/Projects/ugp/src/ugp/UGF/Core/src/component/foo.cc:18:1: internal
compiler error: in splice_child_die, at dwarf2out.c:5265
The code snippet is about as minimal as I can get it and still reproduce the
error. If I make the destructor non-virtual or get rid of the definition of
foo::name_str, the error disappears.
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
--- Comment #25 from Uroš Bizjak ---
(In reply to Katsunori Kumatani from comment #24)
> I think this bug should be reopened because the current behavior is
> restricting.
[...]
I agree. Let's remove this artificial dependency on -msse.
Patch in testing:
--cut here--
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 246531)
+++ config/i386/i386.c (working copy)
@@ -5927,9 +5927,8 @@ ix86_option_override_internal (bool main_args_p,
ix86_preferred_stack_boundary = PREFERRED_STACK_BOUNDARY_DEFAULT;
if (opts_set->x_ix86_preferred_stack_boundary_arg)
{
- int min = (TARGET_64BIT_P (opts->x_ix86_isa_flags)
-? (TARGET_SSE_P (opts->x_ix86_isa_flags) ? 4 : 3) : 2);
- int max = (TARGET_SEH ? 4 : 12);
+ int min = TARGET_64BIT_P (opts->x_ix86_isa_flags)? 3 : 2;
+ int max = TARGET_SEH ? 4 : 12;
if (opts->x_ix86_preferred_stack_boundary_arg < min
|| opts->x_ix86_preferred_stack_boundary_arg > max)
--cut here--
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #82 from Richard Biener ---
Btw, for the attached patch it would fail to handle the case of passing the
aggregate by value and the inliner introducing the aggregate copy:
inline void* operator new(__SIZE_TYPE__, void* __p) { return __p; }
struct X { union { int i; char s[4]; } u; };
static float foo (X y)
{
return reinterpret_cast (y.u.s);
}
int main ()
{
X x;
new (&x.u.s) float (1.0);
if (foo (x) != 1.0)
__builtin_abort ();
}
generates at -O2 after inlining:
int main() ()
{
void * D.2385;
float D.2383;
struct X y;
struct X x;
float _7;
bool retval.0_8;
[100.00%]:
MEM[(float *)&x] = 1.0e+0;
y = x;
_7 = MEM[(float &)&y];
...
[Bug target/24012] [5/6/7 regression] #define _POSIX_C_SOURCE breaks #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
