[Bug c++/90664] New: noexcept confuses template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90664
Bug ID: 90664
Summary: noexcept confuses template argument deduction
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ofv at wanadoo dot es
Target Milestone: ---
consider this code:
<<
template struct OpM;
template
struct OpM
{};
class Class {
public:
int address() noexcept { return 0; }
void address(int) noexcept {}
};
struct Sk {
template Sk(R (C::*p)()) {
typedef OpM OP;
}
};
Sk sk(static_cast(::address));
$ g++.exe -std=c++17 -fsyntax-only -c kk.cpp
kk.cpp: In instantiation of 'Sk::Sk(R (C::*)()) [with C = Class; R = int]':
kk.cpp:19:53: required from here
kk.cpp:15:64: error: 'int (Class::*)(){((int (Class::*)())Class::address), 0}'
is not a valid template argument for type 'int (Class::*)()'
15 | typedef OpM OP;
|^~
kk.cpp:15:64: note: it must be a pointer-to-member of the form '::Y'
The error message is obviously wrong.
Also, I suppose that noexcept is leaking. The static_cast has no problem
deducing the correct overload without mentioning noexcept but then the
instantiation of Sk in the typedef fails because noexcept is missing
(unconmment the noexcept and the compilation succeeds).
The problem was first noticed with gcc 8.x and boost 1.70.
[Bug tree-optimization/90663] New: [7/8/9 Regression] strcmp ([i], a + i) not folded for arrays and constant index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90663
Bug ID: 90663
Summary: [7/8/9 Regression] strcmp ([i], a + i) not folded
for arrays and constant index
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The two functions below are more or less equivalent and should result in
optimal code (a no-op) but starting with GCC 4.7 g() does not. Prior to GCC
4.7 both were optimized into a return statement. Clang also emits optimally
efficient code here.
$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
extern char a[];
void f (const char *s)
{
if (__builtin_strcmp ([2], s + 2)) // folded
__builtin_abort ();
}
void g (void)
{
if (__builtin_strcmp ([2], a + 2)) // not folded
__builtin_abort ();
}
;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=0)
f (const char * s)
{
[local count: 1073741824]:
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1910, cgraph_uid=2, symbol_order=1)
g ()
{
int _1;
[local count: 1073741824]:
_1 = __builtin_strcmp ([2], [(void *) + 2B]);
if (_1 != 0)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return;
}
[Bug tree-optimization/90662] strlen of a string in a vla plus offset not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90662
--- Comment #1 from Martin Sebor ---
The inequality in g() should be != 3, not != 5:
void g (int n)
{
char a[n];
__builtin_strcpy (a, "12345");
if (__builtin_strlen ([2]) != 3) // not folded
__builtin_abort ();
}
The expression '&*a.1_9[2]' in the GIMPLE can be traced to the original IL
(below). I wonder how many other transformations make the same assumption as
strlen that such ADDR_EXPRs are simplified into POINTER_PLUS_EXPRs.
;; Function g (null)
;; enabled by -tree-original
{
char a[0:(sizetype) ((long int) SAVE_EXPR + -1)];
(void) SAVE_EXPR ;
char a[0:(sizetype) ((long int) SAVE_EXPR + -1)];
__builtin_strcpy ((char *) , (const char *) "12345");
if (__builtin_strlen ((const char *) [2]) != 3)
{
__builtin_abort ();
}
}
;; Function h (null)
;; enabled by -tree-original
{
char * a = (char *) __builtin_malloc (6);
char * a = (char *) __builtin_malloc (6);
__builtin_strcpy (a, (const char *) "12345");
if (__builtin_strlen ((const char *) (a + 2)) != 3)
{
__builtin_abort ();
}
}
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 Thomas Koenig changed: What|Removed |Added Attachment #46427|0 |1 is obsolete|| --- Comment #42 from Thomas Koenig --- Created attachment 46428 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46428=edit Patch which should finally work So, this does not regress, apparently. Martin, could you give this one a shot?
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 --- Comment #41 from Thomas Koenig --- Just noticed that this causes a regression in gfortran.fortran-torture/execute/arrayarg.f90 , but only at certain optimization levels. Oh well... need to look some more.
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 Thomas Koenig changed: What|Removed |Added Attachment #46420|0 |1 is obsolete|| --- Comment #40 from Thomas Koenig --- Created attachment 46427 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46427=edit Updated patch OK, so this patch fixes the shortened test case and netcdf. It is basically the earlier one with two lines interchanged. The idea of the patch is simple: Do the same as the library version and don't repack if the array in question is already contiguous Martin, can you check if that this fixes the SPEC problem, too? If so, we can commit and then worry about fine-tuning of when to use this and when to use the library version. I could imagine that, for a procedure with very many arguments, using a library function could be a win because the inlined version would use more icache.
[Bug tree-optimization/90662] New: strlen of a string in a vla plus offset not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90662
Bug ID: 90662
Summary: strlen of a string in a vla plus offset not folded
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In the test case below, GCC can compute the string length in f() and h() but
not in g().
The root cause is that the get_stridx() function in tree-ssa-strlen.c that
retrieves the length record for a non-constant string only handles
POINTER_PLUS_EXPR but the [2] in in g() is represented as '&*a.1_9[2]' or
ADDR_EXPR.
$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
void f (int n)
{
char a[6];
__builtin_strcpy (a, "12345");
if (__builtin_strlen ([2]) != 3) // folded to false
__builtin_abort ();
}
void g (int n)
{
char a[n];
__builtin_strcpy (a, "12345");
if (__builtin_strlen ([2]) != 5) // not folded
__builtin_abort ();
}
void h (int n)
{
char *a = __builtin_malloc (6);
__builtin_strcpy (a, "12345");
if (__builtin_strlen ([2]) != 3) // folded to false
__builtin_abort ();
}
;; Function f (f, funcdef_no=0, decl_uid=1906, cgraph_uid=1, symbol_order=0)
f (int n)
{
[local count: 1073741824]:
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1910, cgraph_uid=2, symbol_order=1)
g (int n)
{
char[0:D.1921] * a.1;
sizetype _1;
char * _6;
long unsigned int _7;
[local count: 1073741824]:
_1 = (sizetype) n_2(D);
a.1_9 = __builtin_alloca_with_align (_1, 8);
__builtin_memcpy (a.1_9, "12345", 6);
_6 = &*a.1_9[2];
_7 = __builtin_strlen (_6);
if (_7 != 5)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return;
}
;; Function h (h, funcdef_no=2, decl_uid=1914, cgraph_uid=3, symbol_order=2)
h (int n)
{
[local count: 1073741824]:
return;
}
[Bug c++/90659] [9/10 Regression] ICE in tree_to_uhwi, at tree.h:4352/7291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90659 --- Comment #3 from Marek Polacek --- Looks like missing verify_constant after the get_array_or_vector_nelts call.
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #13 from Jonathan Wakely --- Author: redi Date: Tue May 28 20:48:31 2019 New Revision: 271719 URL: https://gcc.gnu.org/viewcvs?rev=271719=gcc=rev Log: PR libstdc++/90634 reduce allocations in filesystem::path construction Backport from mainline 2019-05-28 Jonathan Wakely PR libstdc++/90634 * include/experimental/bits/fs_path.h (path::path(path&&)): Only call _M_split_cmpts() for a path with multiple components. (path::_S_is_dir_sep()): Add missing 'static' keyword to function. * src/filesystem/path.cc (path::_M_split_cmpts()): Count number of components and reserve space in vector. Return early when there is only one component. * testsuite/27_io/filesystem/path/construct/90634.cc: New test. * testsuite/experimental/filesystem/path/construct/90634.cc: New test. Added: branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/path/construct/90634.cc branches/gcc-9-branch/libstdc++-v3/testsuite/experimental/filesystem/path/construct/90634.cc Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/include/experimental/bits/fs_path.h branches/gcc-9-branch/libstdc++-v3/src/filesystem/path.cc
[Bug c/90658] [7/8/9 Regression] ICE in default_conversion, at c/c-typeck.c:2159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90658 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |7.5 --- Comment #3 from Marek Polacek --- Mine then.
[Bug c/90658] [7/8/9 Regression] ICE in default_conversion, at c/c-typeck.c:2159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90658 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-28 CC||mpolacek at gcc dot gnu.org, ||msebor at gcc dot gnu.org Known to work||4.9.4 Summary|ICE in default_conversion, |[7/8/9 Regression] ICE in |at c/c-typeck.c:2159|default_conversion, at ||c/c-typeck.c:2159 Ever confirmed|0 |1 Known to fail||10.0, 5.1.0, 6.4.0, 7.3.0, ||8.2.0, 9.1.0 --- Comment #2 from Martin Sebor --- Confirmed. Bisection points to r210262: PR c/50459 c-family/ * c-common.c (check_user_alignment): Return -1 if alignment is error node. (handle_aligned_attribute): Don't call default_conversion on FUNCTION_DECLs. (handle_vector_size_attribute): Likewise. (handle_tm_wrap_attribute): Handle case when wrap_decl is error node. (handle_sentinel_attribute): Call default_conversion and allow even integral types as an argument. c/ * c-parser.c (c_parser_attributes): Parse the arguments as an expression-list if the attribute takes identifier. testsuite/ * c-c++-common/attributes-1.c: Move test line to a new test. * c-c++-common/attributes-2.c: New test. * c-c++-common/pr50459.c: New test. * c-c++-common/pr59280.c: Add "undeclared" to dg-error. * gcc.dg/nonnull-2.c: Likewise. * gcc.dg/pr55570.c: Modify dg-error. * gcc.dg/tm/wrap-2.c: Likewise. Prior to that GCC rejected the test case with: error: constructor priorities must be integers from 0 to 65535 inclusive void g () __attribute__ ((constructor(f))); ^
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #12 from Jonathan Wakely --- Author: redi Date: Tue May 28 19:39:48 2019 New Revision: 271717 URL: https://gcc.gnu.org/viewcvs?rev=271717=gcc=rev Log: PR libstdc++/90634 reduce allocations in filesystem::path construction PR libstdc++/90634 * include/experimental/bits/fs_path.h (path::path(path&&)): Only call _M_split_cmpts() for a path with multiple components. (path::_S_is_dir_sep()): Add missing 'static' keyword to function. * src/filesystem/path.cc (path::_M_split_cmpts()): Count number of components and reserve space in vector. Return early when there is only one component. * testsuite/27_io/filesystem/path/construct/90634.cc: New test. * testsuite/experimental/filesystem/path/construct/90634.cc: New test. Added: trunk/libstdc++-v3/testsuite/27_io/filesystem/path/construct/90634.cc trunk/libstdc++-v3/testsuite/experimental/filesystem/path/construct/90634.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/experimental/bits/fs_path.h trunk/libstdc++-v3/src/filesystem/path.cc
[Bug d/90651] ICE in FuncDeclaration::semantic3, at d/dmd/func.c:1524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90651
--- Comment #2 from Iain Buclaw ---
The second function is not necessary.
struct object {}
void f (...) {}
[Bug c++/90659] [9/10 Regression] ICE in tree_to_uhwi, at tree.h:4352/7291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90659 --- Comment #2 from Marek Polacek --- The crash is here: 3126 unsigned HOST_WIDE_INT max = tree_to_uhwi (nelts); (gdb) p nelts $1 = (gdb) pge (sizetype) (SAVE_EXPR <(ssizetype) n + -1>) + 1
[Bug c++/90659] [9/10 Regression] ICE in tree_to_uhwi, at tree.h:4352/7291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90659 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-28 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug d/90661] New: ICE in AlignDeclaration::syntaxCopy, at d/dmd/attrib.c:670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90661
Bug ID: 90661
Summary: ICE in AlignDeclaration::syntaxCopy, at
d/dmd/attrib.c:670
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: gs...@t-online.de
Target Milestone: ---
$ cat z1.d
class a (b) { align.c d; }
mixin a!(string);
$ cat z2.d
class a (b) { align.c d; }
alias a!(int) e;
$ gdc-10-20190526 -c z1.d
d21: internal compiler error: Segmentation fault
0xcbd25f crash_signal
../../gcc/toplev.c:326
0x63e226 AlignDeclaration::syntaxCopy(Dsymbol*)
../../gcc/d/dmd/attrib.c:670
0x69df82 Dsymbol::arraySyntaxCopy(Array*)
../../gcc/d/dmd/dsymbol.c:883
0x69dff9 ScopeDsymbol::syntaxCopy(Dsymbol*)
../../gcc/d/dmd/dsymbol.c:980
0x69df82 Dsymbol::arraySyntaxCopy(Array*)
../../gcc/d/dmd/dsymbol.c:883
0x6ae8c1 TemplateMixin::semantic(Scope*)
../../gcc/d/dmd/dtemplate.c:8397
0x68f4f8 Module::semantic(Scope*)
../../gcc/d/dmd/dmodule.c:747
0x791e75 d_parse_file()
../../gcc/d/d-lang.cc:1153
[Bug d/90660] New: ICE in TypeQualified::resolveHelper, at d/dmd/mtype.c:6738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90660
Bug ID: 90660
Summary: ICE in TypeQualified::resolveHelper, at
d/dmd/mtype.c:6738
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: gs...@t-online.de
Target Milestone: ---
$ cat z1.d
struct S
{
mixin a.b;
enum {a}
}
$ gdc-10-20190526 -c z1.d
d21: internal compiler error: Segmentation fault
0xb7057f crash_signal
../../gcc/toplev.c:326
0x6faaf3 TypeQualified::resolveHelper(Loc, Scope*, Dsymbol*, Dsymbol*,
Expression**, Type**, Dsymbol**, bool)
../../gcc/d/dmd/mtype.c:6738
0x6fb3aa TypeIdentifier::resolve(Loc, Scope*, Expression**, Type**, Dsymbol**,
bool)
../../gcc/d/dmd/mtype.c:6962
0x688486 TemplateMixin::findTempDecl(Scope*)
../../gcc/d/dmd/dtemplate.c:8203
0x68a894 TemplateMixin::semantic(Scope*)
../../gcc/d/dmd/dtemplate.c:8295
0x67735f StructDeclaration::semantic(Scope*)
../../gcc/d/dmd/dstruct.c:1118
0x66b708 Module::semantic(Scope*)
../../gcc/d/dmd/dmodule.c:747
0x7665f5 d_parse_file()
../../gcc/d/d-lang.cc:1153
[Bug c++/90659] New: [9/10 Regression] ICE in tree_to_uhwi, at tree.h:4352/7291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90659
Bug ID: 90659
Summary: [9/10 Regression] ICE in tree_to_uhwi, at
tree.h:4352/7291
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20190224 and 20190303 :
$ cat z1.cc
template
void foo (int n)
{
T a[n];
[=]{a;};
}
void bar ()
{
foo ;
}
$ g++-10-20190526 -c z1.cc
z1.cc: In instantiation of 'void foo(int) [with T = double]':
z1.cc:9:15: required from here
z1.cc:5:3: internal compiler error: in tree_to_uhwi, at tree.h:4352
5 | [=]{a;};
| ^~~
0x617f9c tree_to_uhwi(tree_node const*)
../../gcc/tree.h:4352
0x617f9c cxx_eval_vec_init_1
../../gcc/cp/constexpr.c:3126
0x610857 cxx_eval_vec_init
../../gcc/cp/constexpr.c:3221
0x610857 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4946
0x61392e cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:5328
0x61617c maybe_constant_init_1
../../gcc/cp/constexpr.c:5705
0x73f396 massage_init_elt
../../gcc/cp/typeck2.c:1348
0x73e666 process_init_constructor_record
../../gcc/cp/typeck2.c:1567
0x73e666 process_init_constructor
../../gcc/cp/typeck2.c:1841
0x73e666 digest_init_r
../../gcc/cp/typeck2.c:1239
0x708501 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
../../gcc/cp/semantics.c:2874
0x6695c4 build_lambda_object(tree_node*)
../../gcc/cp/lambda.c:117
0x6de512 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19547
0x6e64c9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18247
0x6e64c9 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17923
0x6e5467 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17050
0x6e55f1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17036
0x6e6151 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17330
0x6e4624 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:24760
0x6f987b instantiate_pending_templates(int)
../../gcc/cp/pt.c:24876
[Bug c/90658] New: ICE in default_conversion, at c/c-typeck.c:2159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90658 Bug ID: 90658 Summary: ICE in default_conversion, at c/c-typeck.c:2159 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to gcc-5 : $ cat z1.c void f (); void g () __attribute__ ((constructor(f))); $ cat z2.c void f (); void g () __attribute__ ((destructor(f))); $ gcc-10-20190526 -c z1.c z1.c:2:1: internal compiler error: in default_conversion, at c/c-typeck.c:2159 2 | void g () __attribute__ ((constructor(f))); | ^~~~ 0x5e641b default_conversion(tree_node*) ../../gcc/c/c-typeck.c:2159 0x68182d get_priority ../../gcc/c-family/c-attribs.c:1545 0x6833cf handle_constructor_attribute ../../gcc/c-family/c-attribs.c:1596 0x5c9e67 decl_attributes(tree_node**, tree_node*, int, tree_node*) ../../gcc/attribs.c:719 0x5e00f5 start_decl(c_declarator*, c_declspecs*, bool, tree_node*) ../../gcc/c/c-decl.c:4977 0x6225c3 c_parser_declaration_or_fndef ../../gcc/c/c-parser.c:2154 0x628733 c_parser_external_declaration ../../gcc/c/c-parser.c:1653 0x6291f9 c_parser_translation_unit ../../gcc/c/c-parser.c:1534 0x6291f9 c_parse_file() ../../gcc/c/c-parser.c:19884 0x670c60 c_common_parse_file() ../../gcc/c-family/c-opts.c:1156
[Bug c/90658] ICE in default_conversion, at c/c-typeck.c:2159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90658
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Target||x86_64-pc-linux-gnu
--- Comment #1 from G. Steinmetz ---
Additional variants :
$ cat z3.c
void f ()
{
__attribute__ ((constructor (f)))
void g () {}
}
$ cat z4.c
void f ()
{
__attribute__ ((destructor (f)))
void g () {}
}
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #39 from kargl at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #38)
> So, I finally have a self-contained test case:
>
> module t2
> implicit none
> contains
> subroutine foo(a)
> real, dimension(*) :: a
> end subroutine foo
> end module t2
> module t1
> use t2
> implicit none
> contains
> subroutine bar(a)
> real, dimension(:) :: a
> call foo(a)
> end subroutine bar
> end module t1
>
> program main
> use t1
> call bar([1.0, 2.0])
> end program main
This looks an optimizer bug. Compiling with -fdump-tree-original
-fdump-tree-optimize -O gives
(in a.f90.004t.original)
MAIN__ ()
{
{
static real(kind=4) A.5[2] = {1.0e+0, 2.0e+0};
struct array01_real(kind=4) parm.6;
parm.6.span = 4;
parm.6.dtype = {.elem_len=4, .rank=1, .type=3};
parm.6.dim[0].lbound = 0;
parm.6.dim[0].ubound = 1;
parm.6.dim[0].stride = 1;
parm.6.data = (void *) [0];
parm.6.offset = 0;
bar ();
}
}
(in a.f90.231t.optimized)
main (integer(kind=4) argc, character(kind=1) * * argv)
{
struct array01_real(kind=4) parm.9;
static integer(kind=4) options.10[7] = {2116, 4095, 0, 0, 1, 0, 31};
[local count: 1073741824]:
_gfortran_set_args (argc_2(D), argv_3(D));
_gfortran_set_options (7, [0]);
# DEBUG INLINE_ENTRY MAIN__
parm.9.span = 4;
MEM[(struct dtype_type *) + 24B] = {};
parm.9.dtype.elem_len = 4;
parm.9.dtype.rank = 1;
parm.9.dtype.type = 3;
parm.9.dim[0].lbound = 0;
parm.9.dim[0].ubound = 1;
parm.9.dim[0].stride = 1;
parm.9.data = [0];
parm.9.offset = 0;
bar ();
parm.9 ={v} {CLOBBER};
return 0;
}
Note 'static real(kind=4) A.5[2] = {1.0e+0, 2.0e+0};' in *original
appears to be A.8 in *.optimized, but the static declaration is
gone. Perhaps, the Fortran FE needs to mark that actual arguments
as "used" by gfc_mark_ss_chain_used() or TREE_USED().
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #11 from Jonathan Wakely --- Author: redi Date: Tue May 28 16:08:51 2019 New Revision: 271712 URL: https://gcc.gnu.org/viewcvs?rev=271712=gcc=rev Log: Fix check for root-directory path and add tests PR libstdc++/90634 * src/filesystem/path.cc (path::_M_split_cmpts()): Fix check for "/". * testsuite/27_io/filesystem/path/construct/90634.cc: New test. * testsuite/experimental/filesystem/path/construct/90634.cc: New test. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/path/construct/90634.cc branches/gcc-8-branch/libstdc++-v3/testsuite/experimental/filesystem/path/construct/90634.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/src/filesystem/path.cc
[Bug target/88656] [7/8/9/10 Regression] lr clobbered by thumb prologue before __builtin_return_address(0) reads from it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656 --- Comment #6 from gerd at egidy dot de --- (In reply to Richard Earnshaw from comment #5) > then please update the known-to-work field accordingly. It seems I'm missing the rights to do so, could someone with the rights please do that.
[Bug middle-end/85598] [7/8 Regression] Incorrect -Wformat-truncation in a loop only at -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #26 from Jeffrey A. Law --- I concur with Richi. The patch is backportable/safe, the gcc-8 branch is active and this is a regression. So it's really just a matter if if you (or someone) wants to do the backport.
[Bug testsuite/90657] New test case gcc.dg/ipa/pr90555.c in r271695 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90657 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-28 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Mine.
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #10 from Jonathan Wakely --- Author: redi Date: Tue May 28 14:57:35 2019 New Revision: 271710 URL: https://gcc.gnu.org/viewcvs?rev=271710=gcc=rev Log: PR libstdc++/90634 reduce allocations in filesystem::path construction PR libstdc++/90634 * include/bits/fs_path.h (path::path(path&&)): Only call _M_split_cmpts() for a path with multiple components. (path::_S_is_dir_sep()): Add missing 'static' keyword to function. * include/experimental/bits/fs_path.h: Likewise. * src/filesystem/path.cc (path::_M_split_cmpts()): Count number of components and reserve space in vector. Return early when there is only one component. * src/filesystem/std-path.cc (path::_M_split_cmpts()): Likewise. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/bits/fs_path.h branches/gcc-8-branch/libstdc++-v3/include/experimental/bits/fs_path.h branches/gcc-8-branch/libstdc++-v3/src/filesystem/path.cc branches/gcc-8-branch/libstdc++-v3/src/filesystem/std-path.cc
[Bug testsuite/90657] New: New test case gcc.dg/ipa/pr90555.c in r271695 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90657 Bug ID: 90657 Summary: New test case gcc.dg/ipa/pr90555.c in r271695 fails Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/pr90555.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fopenmp-simd -O2 -mavx512f -fdump-ipa-icf -S -o pr90555.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/pr90555.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fopenmp-simd -O2 -mavx512f -fdump-ipa-icf -S -o pr90555.s xgcc: error: unrecognized command line option '-mavx512f' compiler exited with status 1 FAIL: gcc.dg/ipa/pr90555.c (test for excess errors) Excess errors: xgcc: error: unrecognized command line option '-mavx512f' gcc.dg/ipa/pr90555.c: dump file does not exist UNRESOLVED: gcc.dg/ipa/pr90555.c scan-ipa-dump icf "Semantic equality hit:test_simduid1->test_simduid2" gcc.dg/ipa/pr90555.c: dump file does not exist UNRESOLVED: gcc.dg/ipa/pr90555.c scan-ipa-dump icf "Equal symbols: 1" testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/ipa.exp completed in 1 seconds === gcc Summary === # of unexpected failures1 # of unresolved testcases 2
[Bug c++/90548] [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:18877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90548 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed.
[Bug c++/90548] [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:18877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90548 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Tue May 28 14:16:38 2019 New Revision: 271708 URL: https://gcc.gnu.org/viewcvs?rev=271708=gcc=rev Log: PR c++/90548 - ICE with generic lambda and empty pack. * pt.c (tsubst_copy_and_build): Handle pack expansion properly. * g++.dg/cpp1y/lambda-generic-90548.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-90548.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/pt.c
[Bug c++/63149] wrong auto deduction from braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63149 Az changed: What|Removed |Added CC||azalepiej at o2 dot pl --- Comment #4 from Az --- Fails on gcc (Debian 8.3.0-6) 8.3.0
[Bug c++/87699] Implement CWG 1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug target/88656] [7/8/9/10 Regression] lr clobbered by thumb prologue before __builtin_return_address(0) reads from it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656 --- Comment #5 from Richard Earnshaw --- (In reply to gerd from comment #4) > (In reply to Richard Earnshaw from comment #3) > > A regression is not a bug that applies in all previous releases. A > > regression is where something worked in some previous releases but does not > > work now. > > using __builtin_return_address(0) as described in the bug report worked in > gcc 5.4.0 and before. To be more specific, it worked before the fix for bug > 77933 was incorporated. So to me this is a regression. then please update the known-to-work field accordingly.
[Bug c++/90548] [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:18877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90548 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Tue May 28 14:00:29 2019 New Revision: 271705 URL: https://gcc.gnu.org/viewcvs?rev=271705=gcc=rev Log: PR c++/90548 - ICE with generic lambda and empty pack. * pt.c (tsubst_copy_and_build): Handle pack expansion properly. * g++.dg/cpp1y/lambda-generic-90548.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-90548.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/90656] New: Illegal operand from Fortran program WRF with mcpu=niagara3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90656 Bug ID: 90656 Summary: Illegal operand from Fortran program WRF with mcpu=niagara3 Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mailboxnotfound at yahoo dot com Target Milestone: --- Created attachment 46426 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46426=edit tarball, md5sum is 3cba3d5be4b05751298c6dbcb824f06d Introduction Compiling 521.wrf_r from SPEC CPU 2017 with gcc 9.1 on SPARC Linux fails with message module_cu_nsas.fppized.s: Assembler messages: module_cu_nsas.fppized.s:8432: Error: Illegal operands and indeed the operand is illegal - %f25 is only a single precision register: $ head -8432 module_cu_nsas.fppized.s | tail -1 std %f25, [%fp+1799] $ Also fails with WRF You do not need SPEC CPU 2017 to reproduce this problem. The reproducer script for this bug starts from https://raw.githubusercontent.com/NCAR/WRFV3/master/phys/module_cu_nsas.F New with 9.1 The error does not occur with gcc 8.3. I built my copy of GCC 9.1 on a SPARC T8 running Oracle Linux 6.9 with these add-ins to the source directory: binutils-2.32 gmp-6.1.2 isl-0.19 mpc-1.1.0 mpfr-3.1.6 and this configure command: /export/GCC/build/gcc-9.1.0/configure --enable-languages=c,c++,fortran --enable-lto --enable-bootstrap --with-cpu=ultrasparc --with-pkgversion=johnh-16-May-2019 --prefix=/export/GCC/gcc-9.1.0 --with-local-prefix=/export/GCC Optimization Original: -Ofast -mcpu=niagara4 In the reproducer, I got it down to: -O3 -fstack-arrays -ffinite-math-only -mcpu=niagara3 Furthermore, it still fails even if many of the components of O3 are turned off: -fno-inline-functions -fno-predictive-commoning -fno-gcse-after-reload -fno-tree-loop-distribution -fno-tree-loop-distribute-patterns -fno-loop-interchange -fno-loop-unroll-and-jam -fno-split-paths -fno-tree-slp-vectorize -fno-vect-cost-model -fno-tree-partial-pre -fno-peel-loops -fno-ipa-cp-clone -fno-split-loops The reproducer adds all the above to the command and still generates the failure. The problem is rare No other SPEC CPU 2017 benchmarks failed for me on SPARC Linux with GCC 9.1. Within the failing benchmark, 479 modules were built, and they had 29,623 std instructions: $ ls *.s | wc -l 479 $ cat *s | expand |grep -c "std" 29623 $ and only one with a bad floating point double register: $ cat *s | expand |grep "std" | tr -s ' ' | cut -f1 -d, | sort | uniq std %f0 std %f10 std %f12 std %f14 std %f16 std %f18 std %f2 std %f20 std %f22 std %f24 std %f25 <- std %f26 std %f28 std %f30 std %f32 std %f34 std %f36 std %f38 std %f4 std %f40 std %f42 std %f44 std %f46 std %f48 std %f50 std %f52 std %f54 std %f56 std %f58 std %f6 std %f60 std %f62 std %f8 $ $ grep std *s | grep f25 module_cu_nsas.fppized.s: std %f25, [%fp+1799] $ To reproduce: $ ls illegal_operand.tar.xz $ xz -dc illegal_operand.tar.xz | tar -xvf - illegal_operand/ illegal_operand/readme.txt illegal_operand/module_cu_nsas.F illegal_operand/doit.sh $ cd illegal_operand $ Edit 'doit.sh' for your paths, and then: $ ./doit.sh This command using -O3 is expected to fail with gcc 9.1: /export/GCC/gcc-9.1.0/bin/gfortran -ffree-form -nocpp -O3 -m64 -c -o module_cu_nsas.o -v -save-temps -g -fstack-arrays -ffinite-math-only -mcpu=niagara3 module_cu_nsas.F press enter to continue GNU assembler version 2.32 (sparc64-unknown-linux-gnu) using BFD version (johnh-16-May-2019) 2.32 module_cu_nsas.s: Assembler messages: module_cu_nsas.s:9061: Error: Illegal operands press enter to continue This command still uses -O3, but turns off many of its components. It is expected to still fail with gcc 9.1 /export/GCC/gcc-9.1.0/bin/gfortran -ffree-form -fno-inline-functions -fno-predictive-commoning -fno-gcse-after-reload -fno-tree-loop-distribution -fno-tree-loop-distribute-patterns -fno-loop-interchange -fno-loop-unroll-and-jam -fno-split-paths -fno-tree-slp-vectorize -fno-vect-cost-model -fno-tree-partial-pre -fno-peel-loops -fno-ipa-cp-clone -fno-split-loops -nocpp -O3 -m64 -c -o module_cu_nsas.o -v -save-temps -g -fstack-arrays -ffinite-math-only -mcpu=niagara3 module_cu_nsas.F press enter to continue GNU assembler version 2.32 (sparc64-unknown-linux-gnu) using BFD version (johnh-16-May-2019) 2.32 module_cu_nsas.s: Assembler
[Bug target/88656] [7/8/9/10 Regression] lr clobbered by thumb prologue before __builtin_return_address(0) reads from it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656 --- Comment #4 from gerd at egidy dot de --- (In reply to Richard Earnshaw from comment #3) > A regression is not a bug that applies in all previous releases. A > regression is where something worked in some previous releases but does not > work now. using __builtin_return_address(0) as described in the bug report worked in gcc 5.4.0 and before. To be more specific, it worked before the fix for bug 77933 was incorporated. So to me this is a regression.
[Bug target/88656] [7/8/9/10 Regression] lr clobbered by thumb prologue before __builtin_return_address(0) reads from it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656
--- Comment #3 from Richard Earnshaw ---
(In reply to gerd from comment #2)
> Could it be that this is a duplicate of bug 88167?
>
> I compiled a gcc 7.4.0 patched with the fix for 88167 and now get this
> result:
>
> push{r4, lr}
> mov r3, r8
> mov r4, r9
> push{r3, r4}
> mov r0, lr
>
> The patch for bug 88167 seems to be just in trunk for now. As the problem is
> a regression in all releases till gcc 7 I'd prefer if it could be backported
> into the corresponding branches.
A regression is not a bug that applies in all previous releases. A regression
is where something worked in some previous releases but does not work now.
[Bug libstdc++/90646] std::filesystem::absolute( "yourpathhere" ) segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90646 --- Comment #7 from Jonathan Wakely --- It could also be Bug 90557 (which is fixed in the gcc-9-branch but present in the gcc 9.1.0 release) but the symptoms don't look similar.
[Bug libstdc++/90646] std::filesystem::absolute( "yourpathhere" ) segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90646 --- Comment #6 from myLC at gmx dot net --- I'm afraid that wasn't it. I rebuilt the Nana (GUI) library with the same compiler (gcc/c++-9.1.0) and I'm still facing the same problem. Valgrind croaked with 'Process finished with exit code 9', which makes sense. The output shows the 'Invalid read of size 8' ( if (__ptr != nullptr) ) in unique_ptr.h: std::unique_ptr::~unique_ptr() std::filesystem::path::_List::~_List() std::filesystem::path::~path() std::filesystem::current_path(std::error_code&) std::filesystem::current_path() std::filesystem::absolute(std::filesystem::path const&) Config::read(std::filesystem::path const&, std::string const&) main Address 0xb is not stack'd, malloc'd or (recently) free'd I'm in for a lot of fun, it seems...
[Bug middle-end/90648] [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90648 --- Comment #7 from Jakub Jelinek --- Some checking is needed even if the C FE is improved, in particular, one can do stuff like: return ((int (*) (int)) memcpy) (5); etc.
[Bug middle-end/90648] [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90648 --- Comment #6 from Marc Glisse --- (In reply to Jakub Jelinek from comment #5) > So perhaps the way forward is just do a better job on the C FE side too, if > the user provided decl is too different, make sure not to overwrite the old > anticipated builtin and don't mark the new decl as builtin. Yes, that sounds like what I was hoping for without understanding how it is implemented ;-) (but only if it isn't too much more work)
[Bug other/90315] [10 regression] help text (or test for help text) problem after r270788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90315 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška --- Fixed.
[Bug other/90315] [10 regression] help text (or test for help text) problem after r270788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90315 --- Comment #5 from Martin Liška --- Author: marxin Date: Tue May 28 12:05:50 2019 New Revision: 271700 URL: https://gcc.gnu.org/viewcvs?rev=271700=gcc=rev Log: Support again multiple --help options (PR other/90315). 2019-05-28 Martin Liska PR other/90315 * opts-global.c (decode_options): Print help for all help_option_arguments. * opts.c (print_help): Add new argument. (common_handle_option): Remember all values into help_option_arguments. * opts.h (print_help): Add new argument. Modified: trunk/gcc/ChangeLog trunk/gcc/opts-global.c trunk/gcc/opts.c trunk/gcc/opts.h
[Bug testsuite/89441] FAIL: g++.dg/ipa/pr89009.C -std=gnu++98 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89441 --- Comment #4 from Martin Liška --- Author: marxin Date: Tue May 28 11:54:45 2019 New Revision: 271698 URL: https://gcc.gnu.org/viewcvs?rev=271698=gcc=rev Log: Backport r269278 2019-05-28 Martin Liska Backport from mainline 2019-02-28 John David Anglin PR testsuite/89441 * g++.dg/ipa/pr89009.C: Update symbol visibility. Modified: branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/g++.dg/ipa/pr89009.C
[Bug ipa/89009] Miscompilation (missing function call) with -fvisibility=hidden -fpic -O2 -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89009 --- Comment #20 from Martin Liška --- Author: marxin Date: Tue May 28 11:54:33 2019 New Revision: 271697 URL: https://gcc.gnu.org/viewcvs?rev=271697=gcc=rev Log: Backport r268762 (test-suite) 2019-05-28 Martin Liska Backport from mainline 2019-02-11 Martin Liska PR ipa/89009 * g++.dg/ipa/pr89009.C: New test. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/ipa/pr89009.C Modified: branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug middle-end/90649] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_EQ_EXPR, at generic-match.c:42857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90649 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug middle-end/90649] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_EQ_EXPR, at generic-match.c:42857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90649 --- Comment #3 from Martin Liška --- (In reply to Jakub Jelinek from comment #2) > This is essentially a dup of PR90648, what I said there applies here too, I > think genmatch should verify number of call arguments before reading them. Are you Jakub planning to come up with a patch as mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90648#c5?
[Bug ipa/90555] IPA ICF should compare selected struct cfgloop members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90555 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Liška --- Implemented.
[Bug ipa/90555] IPA ICF should compare selected struct cfgloop members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90555 --- Comment #1 from Martin Liška --- Author: marxin Date: Tue May 28 11:42:46 2019 New Revision: 271695 URL: https://gcc.gnu.org/viewcvs?rev=271695=gcc=rev Log: Handle loop fields in IPA ICF (PR ipa/90555). 2019-05-28 Martin Liska PR ipa/90555 * ipa-icf-gimple.c (func_checker::compare_loops): New function. * ipa-icf-gimple.h (func_checker::compare_loops): Likewise. (func_checker::compare_bb): Call compare_loops. 2019-05-28 Martin Liska PR ipa/90555 * gcc.dg/ipa/pr90555.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr90555.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf-gimple.c trunk/gcc/ipa-icf-gimple.h trunk/gcc/testsuite/ChangeLog
[Bug middle-end/90648] [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90648 --- Comment #5 from Jakub Jelinek --- Another thing is that gimple_builtin_call_types_compatible_p compares the argument types to the TYPE_ARG_TYPES of the fndecl, but that could very well be the user provided prototype rather than what GCC relies on. So perhaps the way forward is just do a better job on the C FE side too, if the user provided decl is too different, make sure not to overwrite the old anticipated builtin and don't mark the new decl as builtin.
[Bug c++/70196] inconsistent constness of inequality of weak symbol addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70196
--- Comment #4 from Nathan Sidwell ---
ordering comparison of pointers is only well-defined when the two pointers
point into the same object (including one-past-the-end). [expr.ref]/4
No object can have a NULL address.
The third bullet permits a compiler to /always/ return true (or false) for any
stricly ordered relational pointer comparison involving a null pointer
constant. (AFAICT even '(void *)0 < 0' is included in that). The -or-equal
operators coult be expanded to '(strict-order) | (equality-cmp)', and then
simplified based on what constant we chose the strict-order to always return.
Now, that said, I think the problematic statement in the example is:
constexpr int *q =
That should probably be rejected, as it assigns the set {NULL, obj-addr} to q.
[Bug middle-end/90648] [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90648 --- Comment #4 from Jakub Jelinek --- The fact that it is a call to builtin is determined just by the call calling a fndecl which has builtin class different from none. At GIMPLE perhaps we could cache whether it is a valid builtin call in some GF_CALL_* bit, just would to trigger recomputation of that if we make some significant changes (change types of arguments or similar). As the usual case is correct prototypes and correct arguments to builtins, I think caching this call to builtin is ok is all we need. But for GENERIC we don't even have a routine similar to gimple_builtin_call_types_compatible_p that would check a CALL_EXPR, at least I'm not aware of it.
[Bug middle-end/90648] [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90648 --- Comment #3 from Marc Glisse --- Is there a way we could check the arguments early in a single place, and if they don't match, create a regular function call instead of a bogus call to a builtin? This is so we don't have to check the arguments all over the place in the compiler. But it may be harder than it sounds.
[Bug middle-end/90649] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_EQ_EXPR, at generic-match.c:42857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90649 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- This is essentially a dup of PR90648, what I said there applies here too, I think genmatch should verify number of call arguments before reading them.
[Bug other/90655] New: make install fails with empty DESTDIR on cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90655
Bug ID: 90655
Summary: make install fails with empty DESTDIR on cygwin
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: helmut.grohne at intenta dot de
Target Milestone: ---
Host: x86_64-w64-mingw32
Build: x86_64-pc-cygwinng
Created attachment 46425
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46425=edit
patch for trunk
When running make install with an empty DESTDIR, a small number of install
invocations will attempt to install to $(DESTDIR)/$(something) where something
typically is one of libdir, includedir or plugin_resourcesdir. All of these
typically start with ${prefix} which starts with a slash. When DESTDIR is
empty, the whole path starts with two forward slashes. Cygwin has a special
handling for paths that start with two forward slashes and interprets them as
network shares (see https://unix.stackexchange.com/a/12291/259352). The
relevant install invocations fail. This affects a small number of install
invocations in c, cp, jit and lto. The majority of install invocations use
$(DESTDIR)$(something), which works fine on cygwin.
[Bug d/90651] ICE in FuncDeclaration::semantic3, at d/dmd/func.c:1524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90651 --- Comment #1 from Iain Buclaw --- Confirmed that segfault happens in upstream as well. By the way, it would be interesting to see if any more problems can be found just by prefixing all these generated tests with 'module object;' as the first line - this makes it so there are no implicit runtime dependencies being imported into the compilation.
[Bug d/90650] ICE in fold_convert_loc, at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90650 --- Comment #2 from Iain Buclaw --- Related upstream bug, with fix (makes code an error). https://issues.dlang.org/show_bug.cgi?id=15407
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #9 from baltic <1000hz.radiowave at gmail dot com> --- (In reply to Jonathan Wakely from comment #8) > The libc++ implementation also fails this test: As i've shown before, neither of those are failures. By the current C++ standard at least. So, long story short: "I am not going to fix the x10 overhead, because I believe the standard is wrong." Ok. But damn! how good clang looks on the same test: about to quit. total allocated 0 bytes
[Bug c++/90654] GCC doesn't value-initialize base class with trivial default constructor, resulting in uninitialized data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90654 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78620 Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- This looks like a dup of Bug 65816, specifically Bug 65816 comment 1. *** This bug has been marked as a duplicate of bug 65816 ***
[Bug c++/65816] Constructor delegation does not perform zero-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816 Jonathan Wakely changed: What|Removed |Added CC||adrianbibbywalther at gmail dot co ||m --- Comment #5 from Jonathan Wakely --- *** Bug 90654 has been marked as a duplicate of this bug. ***
[Bug middle-end/90649] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_EQ_EXPR, at generic-match.c:42857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90649 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-28 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, it's very old, at least GCC 4.8. I'll fix it.
[Bug go/90645] sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90645 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #4 from Eric Botcazou --- Your system is way too old to support Go.
[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088 --- Comment #23 from Eric Gallager --- (In reply to Mark Wielaard from comment #22) > (In reply to Eric Gallager from comment #21) > > (In reply to Mark Wielaard from comment #20) > > > https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02055.html > > > > Did this make it in? If not, have you pinged it lately? > > No, there was some review, I think we are generally good, but I am waiting > for stage1 to open. Stage1 has opened.
