[Bug c++/88521] gcc 9.0 from r266355 miscompile x265 for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521 Uroš Bizjak changed: What|Removed |Added CC||lokeshjanghel91 at gmail dot com --- Comment #1 from Uroš Bizjak --- CC author of the patch.
[Bug c++/88528] ICE with templated operator bool() in gcc 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528 Pavel Roskin changed: What|Removed |Added Summary|Regression in gcc 7.4 |ICE with templated operator ||bool() in gcc 7 --- Comment #1 from Pavel Roskin --- I turns out I was wrong about the previous version of gcc. I've just tested gcc 7.1, 7.2 and 7.3 compiled from the source. They all are affected.
[Bug c++/88528] New: Regression in gcc 7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528
Bug ID: 88528
Summary: Regression in gcc 7.4
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: proski at gnu dot org
Target Milestone: ---
gcc 7.4.0 fails to compile some code that could be compiled with earlier
version of gcc 7.x. I don't see that issue with gcc 4.9.4, 5.5.0, 6.5.0 and
8.1.0. The issue still exists with the current gcc-7-branch (git revision
c51441f7f92fe9f4a0a452c1f8d283751ad463c5, timestamp 20181217).
The code:
template
struct A
{
const bool is_valid;
operator bool() const
{
return is_valid;
}
};
template
bool check_a()
{
const A<0> a {};
const bool a_valid {a};
return a_valid;
}
The output with the current gcc from the gcc-7-branch:
$ /opt/gcc/bin/gcc -std=c++14 -c test.cpp
test.cpp: In function ‘bool check_a()’:
test.cpp:15:24: internal compiler error: unexpected expression ‘(bool)a’ of
kind implicit_conv_expr
const bool a_valid {a};
^
0x6e2a5d cxx_eval_constant_expression
/home/roskinp/src/gcc/gcc/cp/constexpr.c:4697
0x6e4454 cxx_eval_outermost_constant_expr
/home/roskinp/src/gcc/gcc/cp/constexpr.c:4755
0x6e6391 maybe_constant_init(tree_node*, tree_node*)
/home/roskinp/src/gcc/gcc/cp/constexpr.c:5082
0x603c2f store_init_value(tree_node*, tree_node*, vec**, int)
/home/roskinp/src/gcc/gcc/cp/typeck2.c:832
0x5c105d check_initializer
/home/roskinp/src/gcc/gcc/cp/decl.c:6377
0x5c5691 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/roskinp/src/gcc/gcc/cp/decl.c:6953
0x654d7f cp_parser_init_declarator
/home/roskinp/src/gcc/gcc/cp/parser.c:19468
0x6555cd cp_parser_simple_declaration
/home/roskinp/src/gcc/gcc/cp/parser.c:12844
0x656295 cp_parser_block_declaration
/home/roskinp/src/gcc/gcc/cp/parser.c:12669
0x656bb9 cp_parser_declaration_statement
/home/roskinp/src/gcc/gcc/cp/parser.c:12279
0x638247 cp_parser_statement
/home/roskinp/src/gcc/gcc/cp/parser.c:10754
0x63900d cp_parser_statement_seq_opt
/home/roskinp/src/gcc/gcc/cp/parser.c:11098
0x6390b7 cp_parser_compound_statement
/home/roskinp/src/gcc/gcc/cp/parser.c:11052
0x649f00 cp_parser_function_body
/home/roskinp/src/gcc/gcc/cp/parser.c:21521
0x649f00 cp_parser_ctor_initializer_opt_and_function_body
/home/roskinp/src/gcc/gcc/cp/parser.c:21559
0x6508f0 cp_parser_function_definition_after_declarator
/home/roskinp/src/gcc/gcc/cp/parser.c:26353
0x6551dd cp_parser_function_definition_from_specifiers_and_declarator
/home/roskinp/src/gcc/gcc/cp/parser.c:26265
0x6551dd cp_parser_init_declarator
/home/roskinp/src/gcc/gcc/cp/parser.c:19247
0x63430a cp_parser_single_declaration
/home/roskinp/src/gcc/gcc/cp/parser.c:26811
0x6501ec cp_parser_template_declaration_after_parameters
/home/roskinp/src/gcc/gcc/cp/parser.c:26415
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug web/86315] Bugzilla: add "cc count" and "duplicate count" columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86315 Eric Gallager changed: What|Removed |Added CC||gerald at pfeifer dot com See Also||https://bugzilla.mozilla.or ||g/show_bug.cgi?id=62718 --- Comment #6 from Eric Gallager --- (In reply to Martin Liška from comment #5) > Is there please any update? Is there someone else who could do this besides LpSolit? Gerald maybe? He takes care of most other web stuff, and Bugzilla is part of the website...
[Bug c++/84897] Better handling of unqualified "string"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84897 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88501 --- Comment #6 from Eric Gallager --- semi-related: bug 88501 (ok not really THAT related, but it still made me think of it)
[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394 --- Comment #8 from Eric Gallager --- (In reply to Jeffrey A. Law from comment #7) > -O0 has none of the analysis necessary and I believe you get no warnings at > all. > > A minimum of -Og is needed, but -Og is inherently going to give many false > positives. So is it worth trying to fix this then?
[Bug tree-optimization/88527] New: ICE: tree check: expected integer_cst, have error_mark in equal, at tree.c:1464; or tree check: expected integer_cst, have identifier_node in equal, at tree.c:1464
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88527 Bug ID: 88527 Summary: ICE: tree check: expected integer_cst, have error_mark in equal, at tree.c:1464; or tree check: expected integer_cst, have identifier_node in equal, at tree.c:1464 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-*-linux-gnu 1. gcc-9.0.0-alpha20181209 snapshot (r266934) ICEs when compiling gcc/testsuite/gcc.dg/graphite/id-26.c w/ -O1 -floop-interchange -fopenmp -fno-ssa-phiopt -fno-tree-loop-im -fno-tree-scev-cprop -fno-tree-vrp -g: % powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181216 -O1 -floop-interchange -fopenmp -fno-ssa-phiopt -fno-tree-loop-im -fno-tree-scev-cprop -fno-tree-vrp -g -c gcc/testsuite/gcc.dg/graphite/id-26.c during GIMPLE pass: ivopts gcc/testsuite/gcc.dg/graphite/id-26.c: In function 'find_sad_16x16': gcc/testsuite/gcc.dg/graphite/id-26.c:2:5: internal compiler error: tree check: expected integer_cst, have error_mark in equal, at tree.c:1464 2 | int find_sad_16x16(int *intra_mode) | ^~ 0x6bb2b9 tree_check_failed(tree_node const*, char const*, int, char const*, ...) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree.c:9757 0x6bc34d tree_check(tree_node const*, char const*, int, char const*, tree_code) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree.h:3413 0x6bc34d int_cst_hasher::equal(tree_node*, tree_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree.c:1464 0xff03ac hash_table::find_slot_with_hash(tree_node* const&, unsigned int, insert_option) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/hash-table.h:896 0xfdc6a1 hash_table::find_slot(tree_node* const&, insert_option) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/hash-table.h:414 0xfdc6a1 wide_int_to_tree_1 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree.c:1596 0xfde8da force_fit_type(tree_node*, poly_int<1u, generic_wide_int > > const&, int, bool) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree.c:1433 0xa07d26 fold_convert_const_int_from_int /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/fold-const.c:1999 0xa07d26 fold_convert_const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/fold-const.c:2277 0xa1817b fold_convert_loc(unsigned int, tree_node*, tree_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/fold-const.c:2414 0xa2533e extract_muldiv_1 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/fold-const.c:6300 0xa26570 extract_muldiv /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/fold-const.c:6215 0xa100d9 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/fold-const.c:10072 0xa1466a fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/fold-const.c:12343 0x9ccd3e get_inner_reference(tree_node*, poly_int_pod<1u, long>*, poly_int_pod<1u, long>*, tree_node**, machine_mode*, int*, int*, int*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/expr.c:7249 0x8886b8 get_object_alignment_2 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/builtins.c:254 0x888c5b get_object_alignment(tree_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/builtins.c:404 0xe76a4b rewrite_use_address /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree-ssa-loop-ivopts.c:7140 0xe76a4b rewrite_groups /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree-ssa-loop-ivopts.c:7237 0xe76a4b tree_ssa_iv_optimize_loop /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/g
[Bug fortran/85314] gcc/fortran/resolve.c:9222: unreachable code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85314 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Dec 17 02:19:58 2018 New Revision: 267196 URL: https://gcc.gnu.org/viewcvs?rev=267196=gcc=rev Log: 2018-12-16 Steven G. Kargl PR fortran/85314 * resolve.c (resolve_transfer): Remove dead code. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c
[Bug fortran/85314] gcc/fortran/resolve.c:9222: unreachable code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85314 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|8.3 |9.0 --- Comment #5 from kargl at gcc dot gnu.org --- Fixed. Disappointed. Closing.
[Bug target/88524] PLT32 relocation is off by 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88524 --- Comment #5 from Ruslan Nikolaev --- (In reply to Andrew Pinski from comment #4) > Still is a binutils (assembler rather than the linker issue): > .file "t.c" > .text > #APP > a: .long func@plt - 4 > #NO_APP > .globl geta > .type geta, @function > geta: > .LFB0: > .cfi_startproc > pushq %rbp > .cfi_def_cfa_offset 16 > .cfi_offset 6, -16 > movq%rsp, %rbp > .cfi_def_cfa_register 6 > movqa@GOTPCREL(%rip), %rax > movl(%rax), %eax > popq%rbp > .cfi_def_cfa 7, 8 > ret > .cfi_endproc > .LFE0: > .size geta, .-geta > .ident "GCC: (Octeon TX GCC 7 - (Build 116)) 7.3.0" > .section.note.GNU-stack,"",@progbits > > > What GCC outputs does not have the -4 in there. Ok, thanks!
[Bug c/88526] New: gcc accepts ill-formed program with sizeof (int [*])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88526
Bug ID: 88526
Summary: gcc accepts ill-formed program with sizeof (int [*])
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following C11 program (prog.c):
void f(int a[sizeof(int [*])]);
int main()
{
}
Compiling it with
gcc prog.c -std=c11 -pedantic-errors
gives no errors. The expected behaviour is that it should compile with at least
one error. This becuase the flag -pedantic-errors was used and because the
program is incorrect according to the C11 standard (taking sizeof int [*]
should not be possible since it is not a complete type).
[Bug target/88524] PLT32 relocation is off by 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88524 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #4 from Andrew Pinski --- Still is a binutils (assembler rather than the linker issue): .file "t.c" .text #APP a: .long func@plt - 4 #NO_APP .globl geta .type geta, @function geta: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp .cfi_def_cfa_register 6 movqa@GOTPCREL(%rip), %rax movl(%rax), %eax popq%rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size geta, .-geta .ident "GCC: (Octeon TX GCC 7 - (Build 116)) 7.3.0" .section.note.GNU-stack,"",@progbits What GCC outputs does not have the -4 in there.
[Bug target/88524] PLT32 relocation is off by 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88524 Ruslan Nikolaev changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|MOVED |--- --- Comment #3 from Ruslan Nikolaev --- (In reply to Andreas Schwab from comment #2) > If anything, this is a problem in the linker, please report to the binutils > project. Why is it binutils? The problem already appears with when running with '-c' flag (incorrect PLT32 relocation), i.e. not linking a shared library yet. I have just gave that example to further demonstrate the problem.
[Bug c/88525] New: gcc thinks that C11 program does not declare anything but it does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88525
Bug ID: 88525
Summary: gcc thinks that C11 program does not declare anything
but it does.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following C11 program (prog.c):
int main()
{
struct { enum { a } b; };
}
This program does NOT violate rule 6.7.2 in the C11 standard since the
declaration declares a member of an enum (a).
I tried to compile it with the following command line:
gcc prog.c -std=c11 -pedantic-errors
I get the following unexpected error message:
error: unnamed struct/union that defines no instances
This is wrong. The declaration does declare the enum member a and according
to the C11 standard it does not need to declare anything else.
[Bug c/88477] Variable with type completed in initializer not allowed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477 --- Comment #4 from Anders Granlund --- In general the standard seems to be a bit inprecise when it talks about types beeing complete. The same type may be incomplete at one point in the program, but complete at another point. The standard should always specify at what point in the program a type needs to be complete when it requires it to be complete. I will file a defect report about that instead.
[Bug d/88462] All D execution tests FAIL on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462 --- Comment #12 from Iain Buclaw --- (In reply to Johannes Pfau from comment #10) > I guess the proper fix to the alignment problem is using > 'https://dlang.org/phobos/std_traits.html#classInstanceAlignment' (or rather > the druntime equivalent) instead of Mutex.alignof + the rounding / slice > assignment fixes? > > Regarding the ModuleInfo problem: Although ModuleInfo does have a variable > size, _flags ist the first field in the struct. So the whole struct instance > has to be misaligned for some reason? Is the minfo section aligned properly? ModuleInfo is forced an alignment of 1. It should be instead aligned to `max(uint.sizeof, size_t.sizeof)` so that both named and variable data parts can be read without alignment problems.
[Bug target/88524] PLT32 relocation is off by 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88524 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #2 from Andreas Schwab --- If anything, this is a problem in the linker, please report to the binutils project.
[Bug target/88524] PLT32 relocation is off by 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88524 --- Comment #1 from Ruslan Nikolaev --- btw, I have just compared the output with clang/llvm 7.0; the generated code seems to be correct in both cases there.
[Bug c/88523] Allow slick and sick variably modified function return type constructed on each instance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88523 --- Comment #3 from sasho648 at gmail dot com --- The included phrase in the standard would read something like: If an incomplete structure type is the composite type of a function - it's allowed to be completed inside its prototype in which case a X function is created which type will be evaluated on each instance after its argument values are evaluated.
[Bug target/88524] New: PLT32 relocation is off by 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88524
Bug ID: 88524
Summary: PLT32 relocation is off by 4
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nruslan_devel at yahoo dot com
Target Milestone: ---
Consider the following example for some -fpic -mcmodel=small compiled code.
There is an external function func() for which we store a relative reference
to the corresponding @plt stub in a 32-bit variable.
The following seems to generate correct offsets (@plt is already relative, so
we can probably specify it directly):
void func(void);
asm("a: .long func@plt");
extern int a;
int geta()
{
return a;
}
gcc -Wall -O2 -c -fpic test.c
yields
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
R_X86_64_PLT32func
0013 R_X86_64_REX_GOTPCRELX a-0x0004
However, if we change asm("a: .long func@plt") to asm("a: .long func@plt - .")
the generated code is very weird and is off by 4:
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
R_X86_64_PLT32func-0x0004
0013 R_X86_64_REX_GOTPCRELX a-0x0004
Specifically, if we generate a shared library, the generated offset to func@plt
is off by 4 in the second case.
gcc -Wall -O2 -shared -fpic test.c
the first case is correct:
04c0 :
...
05c0 :
5c0: 00 ff
5c2: ff
5c3: ff
[5c0 + ff00] = 4C0
whereas the second case is off by 4:
04c0 :
...
05c0 :
5c0: fc
5c1: fe
5c2: ff
5c3: ff
[5c0 + fefc] = 4BC
It is quite possible that I am missing something here (and the generated code
is correct) but just want to check if there is any potential bug in the
compiler.
[Bug c/88523] Allow slick and sick variably modified function return type constructed on each instance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88523 --- Comment #2 from sasho648 at gmail dot com --- I'm referring to the function without linkage main. The one with linkage that is declared at file scope has no relation at all with my proposal - I'm just using the opportunity to introduce as few identifiers as possible.
[Bug c/88523] Allow slick and sick variably modified function return type constructed on each instance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88523 sasho648 at gmail dot com changed: What|Removed |Added Summary|Allow slick and sick|Allow slick and sick |variably modified function |variably modified function |return type created on |return type constructed on |instance. |each instance. --- Comment #1 from sasho648 at gmail dot com --- Allow this behavior only on functions without linkage like the one above.
[Bug c/88523] New: Allow slick and sick incomplete variably modified function return type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88523
Bug ID: 88523
Summary: Allow slick and sick incomplete variably modified
function return type.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sasho648 at gmail dot com
Target Milestone: ---
Consider the following code:
main()
{
auto a(char a, struct t { char t[a] } t)
{
}
}
It currently ICEs and has no actual purpose but what if we use this opportunity
to introduce:
main()
{
auto struct t main(char a, struct t { char t[a] } t)
{
return t;
}
}
The above code will complete the composite type of main on each instance after
its arguments were evaluated.
[Bug target/88522] New: Error: operand size mismatch for `vpgatherqq'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522
Bug ID: 88522
Summary: Error: operand size mismatch for `vpgatherqq'
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
Target Milestone: ---
Target: i386,x86-64
With binutils 2.32, I got
[hjl@gnu-skx-1 gcc]$
/export/users/hjl/build/gnu/tools-build/gcc-32bit/build-i686-linux/gcc/xgcc
-B/export/users/hjl/build/gnu/tools-build/gcc-32bit/build-i686-linux/gcc/
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -Ofast -mavx512vl -masm=intel -c -o
avx512vl-pr79299-2.o
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/avx512vl-pr79299-2.c
-m32
/tmp/ccptGe0Q.s: Assembler messages:
/tmp/ccptGe0Q.s:18: Error: operand size mismatch for `vgatherdps'
/tmp/ccptGe0Q.s:43: Error: operand size mismatch for `vgatherdps'
/tmp/ccptGe0Q.s:67: Error: operand size mismatch for `vgatherdpd'
/tmp/ccptGe0Q.s:92: Error: operand size mismatch for `vgatherdpd'
/tmp/ccptGe0Q.s:116: Error: operand size mismatch for `vgatherqps'
/tmp/ccptGe0Q.s:141: Error: operand size mismatch for `vgatherqps'
/tmp/ccptGe0Q.s:165: Error: operand size mismatch for `vgatherqpd'
/tmp/ccptGe0Q.s:190: Error: operand size mismatch for `vgatherqpd'
/tmp/ccptGe0Q.s:213: Error: operand size mismatch for `vpgatherdd'
/tmp/ccptGe0Q.s:238: Error: operand size mismatch for `vpgatherdd'
/tmp/ccptGe0Q.s:262: Error: operand size mismatch for `vpgatherdq'
/tmp/ccptGe0Q.s:287: Error: operand size mismatch for `vpgatherdq'
/tmp/ccptGe0Q.s:311: Error: operand size mismatch for `vpgatherqd'
/tmp/ccptGe0Q.s:336: Error: operand size mismatch for `vpgatherqd'
/tmp/ccptGe0Q.s:360: Error: operand size mismatch for `vpgatherqq'
/tmp/ccptGe0Q.s:385: Error: operand size mismatch for `vpgatherqq'
/tmp/ccptGe0Q.s:410: Error: operand size mismatch for `vgatherdps'
/tmp/ccptGe0Q.s:429: Error: operand size mismatch for `vgatherdps'
/tmp/ccptGe0Q.s:451: Error: operand size mismatch for `vgatherdpd'
/tmp/ccptGe0Q.s:470: Error: operand size mismatch for `vgatherdpd'
/tmp/ccptGe0Q.s:492: Error: operand size mismatch for `vgatherqps'
/tmp/ccptGe0Q.s:512: Error: operand size mismatch for `vgatherqps'
/tmp/ccptGe0Q.s:534: Error: operand size mismatch for `vgatherqpd'
/tmp/ccptGe0Q.s:553: Error: operand size mismatch for `vgatherqpd'
/tmp/ccptGe0Q.s:575: Error: operand size mismatch for `vpgatherdd'
/tmp/ccptGe0Q.s:594: Error: operand size mismatch for `vpgatherdd'
/tmp/ccptGe0Q.s:616: Error: operand size mismatch for `vpgatherdq'
/tmp/ccptGe0Q.s:635: Error: operand size mismatch for `vpgatherdq'
/tmp/ccptGe0Q.s:657: Error: operand size mismatch for `vpgatherqd'
/tmp/ccptGe0Q.s:677: Error: operand size mismatch for `vpgatherqd'
/tmp/ccptGe0Q.s:699: Error: operand size mismatch for `vpgatherqq'
/tmp/ccptGe0Q.s:718: Error: operand size mismatch for `vpgatherqq'
/tmp/ccptGe0Q.s:739: Error: operand size mismatch for `vgatherdps'
/tmp/ccptGe0Q.s:756: Error: operand size mismatch for `vgatherdps'
/tmp/ccptGe0Q.s:776: Error: operand size mismatch for `vgatherdpd'
/tmp/ccptGe0Q.s:793: Error: operand size mismatch for `vgatherdpd'
/tmp/ccptGe0Q.s:813: Error: operand size mismatch for `vgatherqps'
/tmp/ccptGe0Q.s:831: Error: operand size mismatch for `vgatherqps'
/tmp/ccptGe0Q.s:851: Error: operand size mismatch for `vgatherqpd'
/tmp/ccptGe0Q.s:868: Error: operand size mismatch for `vgatherqpd'
/tmp/ccptGe0Q.s:888: Error: operand size mismatch for `vpgatherdd'
/tmp/ccptGe0Q.s:905: Error: operand size mismatch for `vpgatherdd'
/tmp/ccptGe0Q.s:925: Error: operand size mismatch for `vpgatherdq'
/tmp/ccptGe0Q.s:942: Error: operand size mismatch for `vpgatherdq'
/tmp/ccptGe0Q.s:962: Error: operand size mismatch for `vpgatherqd'
/tmp/ccptGe0Q.s:980: Error: operand size mismatch for `vpgatherqd'
/tmp/ccptGe0Q.s:1000: Error: operand size mismatch for `vpgatherqq'
/tmp/ccptGe0Q.s:1017: Error: operand size mismatch for `vpgatherqq'
[hjl@gnu-skx-1 gcc]$
We have
[hjl@gnu-skx-1 gcc]$ cat x.s
.intel_syntax noprefix
vpgatherdd xmm0{k1}, XMMWORD PTR [eax+xmm1*1]
vpgatherdd ymm0{k1}, YMMWORD PTR [eax+ymm1*1]
vpgatherdd zmm1{k1}, ZMMWORD PTR [eax+zmm0*1]
vpgatherdq xmm0{k1}, XMMWORD PTR [eax+xmm1*1]
vpgatherdq ymm0{k1}, YMMWORD PTR [eax+xmm1*1]
vpgatherdq zmm1{k1}, ZMMWORD PTR [eax+ymm0*1]
vpgatherqd xmm0{k1}, QWORD PTR [eax+xmm1*1]
vpgatherqd xmm0{k1}, XMMWORD PTR [eax+ymm1*1]
vpgatherqd ymm1{k1}, YMMWORD PTR [eax+zmm0*1]
vpgatherqd ymm2{k1}, YMMWORD PTR [edx+zmm1*1]
vpgatherqq xmm0{k1}, XMMWORD PTR [eax+xmm1*1]
vpgatherqq ymm0{k1}, YMMWORD PTR [eax+ymm1*1]
[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 zed.three at gmail dot com changed: What|Removed |Added CC||zed.three at gmail dot com --- Comment #26 from zed.three at gmail dot com --- Thank you for looking at the finalisation stuff, Paul, it's really appreciated! It wasn't clear to me from the patch notes if you expect the following to be fixed: subroutine assign_a_type(lhs, rhs) class(a_type_t), intent(inout) :: lhs class(a_type_t), intent(in):: rhs lhs%x = rhs%x end subroutine assign_a_type or class(a_type_t), allocatable :: c c = add_a_type(a, b) These still generate memory leaks (detected using -fsanitize=address) I'm using trunk (r267184, git bf96f3) I've been trying to dig into the code myself, mostly as a learning exercise. Am I right in thinking that gfc_conv_procedure_call handles the whole statement? i.e. that finalisation both of the lhs and function result are (or should be) done here?
[Bug fortran/85544] [7/8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544 --- Comment #7 from Thomas Koenig --- The problem with the patch in comment #6 is that it pessimizes code like b = (-1)**a So, some more thinking required...
[Bug fortran/88467] Silently accepts wrong array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88467 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.3 --- Comment #8 from kargl at gcc dot gnu.org --- Fixed on trunk and branch-8. pr88116*f90 testcases fail when patch applied to branch-7. Closing.
[Bug fortran/88116] [8/9 Regression] ICE in gfc_convert_constant(): Unexpected type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88116 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from kargl at gcc dot gnu.org --- Fixed on trunk and branch-8. pr88116*f90 testcases fail when patch applied to branch-7. Closing.
[Bug c++/88521] New: gcc 9.0 from r266355 miscompile x265 for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521 Bug ID: 88521 Summary: gcc 9.0 from r266355 miscompile x265 for mingw-w64 target Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mateuszb at poczta dot onet.pl Target Milestone: --- Target: mingw-w64 x265 compiled by gcc 9.0 r266355 (or newer) for mingw-w64 makes wrong encoding (awful quality). Comparison of encoding by x265 compiled by gcc 9.0 r266354 vs. r266355 (see bitrate and Avg QP): f:\speed\2.9+15>x265r354 --crf 20 --no-asm ../Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m w1.hevc && x265r355 --crf 20 --no-asm ../Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m w2.hevc y4m [info]: 1920x1080 fps 30/1 i420p8 frames 0 - 599 of 600 raw [info]: output file: w1.hevc x265 [info]: HEVC encoder version 2.9+16-c829b5b75a9f x265 [info]: build info [Windows][GCC 9.0.0][64 bit] 10bit x265 [info]: using cpu capabilities: none! x265 [info]: Main 10 profile, Level-4 (Main tier) x265 [info]: Thread pool created using 12 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 3 / wpp(17 rows) x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2 x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00 x265 [info]: Lookahead / bframes / badapt: 20 / 4 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0 x265 [info]: References / ref-limit cu / depth : 3 / on / on x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1 x265 [info]: Rate Control / qCompress: CRF-20.0 / 0.60 x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing x265 [info]: tools: lslices=6 deblock sao x265 [info]: frame I: 3, Avg QP:19.68 kb/s: 32315.52 x265 [info]: frame P:148, Avg QP:21.03 kb/s: 12782.31 x265 [info]: frame B:449, Avg QP:26.54 kb/s: 1167.18 x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0% x265 [info]: consecutive B-frames: 0.7% 0.7% 0.7% 96.7% 1.3% encoded 600 frames in 113.81s (5.27 fps), 4187.99 kb/s, Avg QP:25.15 y4m [info]: 1920x1080 fps 30/1 i420p8 frames 0 - 599 of 600 raw [info]: output file: w2.hevc x265 [info]: HEVC encoder version 2.9+16-c829b5b75a9f x265 [info]: build info [Windows][GCC 9.0.0][64 bit] 10bit x265 [info]: using cpu capabilities: none! x265 [info]: Main 10 profile, Level-4 (Main tier) x265 [info]: Thread pool created using 12 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 3 / wpp(17 rows) x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2 x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00 x265 [info]: Lookahead / bframes / badapt: 20 / 4 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0 x265 [info]: References / ref-limit cu / depth : 3 / on / on x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1 x265 [info]: Rate Control / qCompress: CRF-20.0 / 0.60 x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing x265 [info]: tools: lslices=6 deblock sao x265 [info]: frame I: 3, Avg QP:39.68 kb/s: 13494.72 x265 [info]: frame P:148, Avg QP:19.37 kb/s: 18426.52 x265 [info]: frame B:449, Avg QP:51.00 kb/s: 77.51 x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0% x265 [info]: consecutive B-frames: 0.7% 0.7% 0.7% 96.7% 1.3% encoded 600 frames in 103.13s (5.82 fps), 4670.69 kb/s, Avg QP:43.14
[Bug fortran/88467] Silently accepts wrong array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88467 --- Comment #7 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 16 17:00:33 2018 New Revision: 267190 URL: https://gcc.gnu.org/viewcvs?rev=267190=gcc=rev Log: 2018-12-16 Steven G. Kargl PR fortran/88116 PR fortran/88467 * array.c (gfc_match_array_constructor): Check return value of gfc_convert_type(). Skip constructor elements with BT_UNKNOWN, which need to go through resolution. * intrinsic.c (gfc_convert_type_warn): Return early if the types martch (i.e., no conversion is required). * simplify.c (gfc_convert_constant): Remove a gfc_internal_error, and return gfc_bad_expr. 2018-12-16 Steven G. Kargl PR fortran/88116 * gfortran.dg/pr88116_1.f90: New test. * gfortran.dg/pr88116_2.f90: Ditto. PR fortran/88467 * gfortran.dg/pr88467.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88116_1.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88116_2.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88467.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/array.c branches/gcc-8-branch/gcc/fortran/intrinsic.c branches/gcc-8-branch/gcc/fortran/simplify.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/88116] [8/9 Regression] ICE in gfc_convert_constant(): Unexpected type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88116 --- Comment #9 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 16 17:00:33 2018 New Revision: 267190 URL: https://gcc.gnu.org/viewcvs?rev=267190=gcc=rev Log: 2018-12-16 Steven G. Kargl PR fortran/88116 PR fortran/88467 * array.c (gfc_match_array_constructor): Check return value of gfc_convert_type(). Skip constructor elements with BT_UNKNOWN, which need to go through resolution. * intrinsic.c (gfc_convert_type_warn): Return early if the types martch (i.e., no conversion is required). * simplify.c (gfc_convert_constant): Remove a gfc_internal_error, and return gfc_bad_expr. 2018-12-16 Steven G. Kargl PR fortran/88116 * gfortran.dg/pr88116_1.f90: New test. * gfortran.dg/pr88116_2.f90: Ditto. PR fortran/88467 * gfortran.dg/pr88467.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88116_1.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88116_2.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88467.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/array.c branches/gcc-8-branch/gcc/fortran/intrinsic.c branches/gcc-8-branch/gcc/fortran/simplify.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/88116] [8/9 Regression] ICE in gfc_convert_constant(): Unexpected type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88116 --- Comment #8 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 16 16:29:43 2018 New Revision: 267189 URL: https://gcc.gnu.org/viewcvs?rev=267189=gcc=rev Log: 2018-12-16 Steven G. Kargl PR fortran/88116 PR fortran/88467 * array.c (gfc_match_array_constructor): Check return value of gfc_convert_type(). Skip constructor elements with BT_UNKNOWN, which need to go through resolution. * intrinsic.c (gfc_convert_type_warn): Return early if the types martch (i.e., no conversion is required). * simplify.c (gfc_convert_constant): Remove a gfc_internal_error, and return gfc_bad_expr. 2018-12-16 Steven G. Kargl PR fortran/88116 * gfortran.dg/pr88116_1.f90: New test. * gfortran.dg/pr88116_2.f90: Ditto. PR fortran/88467 * gfortran.dg/pr88467.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88116_1.f90 trunk/gcc/testsuite/gfortran.dg/pr88116_2.f90 trunk/gcc/testsuite/gfortran.dg/pr88467.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88467] Silently accepts wrong array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88467 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 16 16:29:43 2018 New Revision: 267189 URL: https://gcc.gnu.org/viewcvs?rev=267189=gcc=rev Log: 2018-12-16 Steven G. Kargl PR fortran/88116 PR fortran/88467 * array.c (gfc_match_array_constructor): Check return value of gfc_convert_type(). Skip constructor elements with BT_UNKNOWN, which need to go through resolution. * intrinsic.c (gfc_convert_type_warn): Return early if the types martch (i.e., no conversion is required). * simplify.c (gfc_convert_constant): Remove a gfc_internal_error, and return gfc_bad_expr. 2018-12-16 Steven G. Kargl PR fortran/88116 * gfortran.dg/pr88116_1.f90: New test. * gfortran.dg/pr88116_2.f90: Ditto. PR fortran/88467 * gfortran.dg/pr88467.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88116_1.f90 trunk/gcc/testsuite/gfortran.dg/pr88116_2.f90 trunk/gcc/testsuite/gfortran.dg/pr88467.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog
[Bug target/88513] [9 Regression] FAIL: gcc.target/i386/pr59591-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88513 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Likely dup of PR88514.
[Bug rtl-optimization/88519] internal compiler error: in expand_widen_pattern_expr, at optabs.c:278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88519 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Likely dup of PR88514.
[Bug c++/88520] New: improve warning when `struct` is required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88520
Bug ID: 88520
Summary: improve warning when `struct` is required
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Consider this source:
int Foo;
struct Foo
{
int a;
};
extern int f(Foo x);
gcc (I'm using 8.2.1 from Fedora 28) says:
q.cc:8:14: warning: ‘f’ initialized and declared ‘extern’
extern int f(Foo x);
^~~
q.cc:8:17: error: expected ‘)’ before ‘x’
extern int f(Foo x);
~ ^~
)
clang is somewhat nicer here, showing where the definition appeared.
This is handy info for figuring out what went wrong:
q.cc:8:14: error: must use 'struct' tag to refer to type 'Foo' in this scope
extern int f(Foo x);
^
struct
q.cc:1:5: note: struct 'Foo' is hidden by a non-type declaration of 'Foo' here
int Foo;
^
This came up on the gdb list, where a user couldn't figure out why
gcc was erroring.
[Bug target/88514] [9 Regression] FAIL: gcc.target/i386/avx512vl-pr79299-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88514 --- Comment #3 from Jakub Jelinek --- Created attachment 45245 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45245=edit gcc9-pr88514-wip.patch Untested WIP patch. With this I can vectorize the above testcase fine, but the testcase in #c0 still ICEs, just with a different ICE.
[Bug sanitizer/84863] false-positive -Warray-bounds warning with -fsanitize-coverage=object-size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84863 --- Comment #3 from Arnd Bergmann --- The problem in the kernel then is that we then have to turn off the sanitizers for the 'allmodconfig' build, since the recommended minimum regression testing for kernel changes involves building a kernel with all options (including UBSAN) enabled and checking that there are no compiler warnings. This means we would fail to catch any build regressions in the kernel part of UBSAN, as well as any legitimate warnings that are only seen when the sanitizers are active.
[Bug rtl-optimization/88519] New: internal compiler error: in expand_widen_pattern_expr, at optabs.c:278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88519 Bug ID: 88519 Summary: internal compiler error: in expand_widen_pattern_expr, at optabs.c:278 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: toon at moene dot org Target Milestone: --- Created attachment 45244 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45244=edit Source code that provokes the ICE. The attached source provokes the following ICE: during RTL pass: expand hlcfint2.f90:159:0: 159 |zpsi2 = ppsi(i,k) + (ppsi(i,k)-ppsi(i,k-1))*zxx/(pph(i,k)-pph(i,k-1)) | internal compiler error: in expand_widen_pattern_expr, at optabs.c:278 0x6bcac1 expand_widen_pattern_expr(separate_ops*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, int) /home/toon/compilers/trunk/gcc/optabs.c:278 0xabe134 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /home/toon/compilers/trunk/gcc/expr.c:9465 0xaaeb2f expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /home/toon/compilers/trunk/gcc/expr.c:9882 0xaac1b5 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /home/toon/compilers/trunk/gcc/expr.c:11037 0xab8843 store_expr(tree_node*, rtx_def*, int, bool, bool) /home/toon/compilers/trunk/gcc/expr.c:5633 0xab9f79 expand_assignment(tree_node*, tree_node*, bool) /home/toon/compilers/trunk/gcc/expr.c:5416 0xab9f79 expand_assignment(tree_node*, tree_node*, bool) /home/toon/compilers/trunk/gcc/expr.c:4977 0x9a064f expand_gimple_stmt_1 /home/toon/compilers/trunk/gcc/cfgexpand.c:3746 0x9a064f expand_gimple_stmt /home/toon/compilers/trunk/gcc/cfgexpand.c:3844 0x9a2b01 expand_gimple_basic_block /home/toon/compilers/trunk/gcc/cfgexpand.c:5880 0x9a7687 execute /home/toon/compilers/trunk/gcc/cfgexpand.c:6502 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. when compiled in the following way: ~toon/compilers/install/bin/gfortran -Ofast -march=skylake-avx512 -c hlcfint2.f90 Version of the compiler: ~toon/compilers/install/bin/gfortran -v Using built-in specs. COLLECT_GCC=/home/toon/compilers/install/bin/gfortran COLLECT_LTO_WRAPPER=/home/toon/compilers/install/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/toon/compilers/trunk/configure --prefix=/home/toon/compilers/install --with-gnu-as --with-gnu-ld --enable-languages=all,go,ada --disable-multilib --disable-nls Thread model: posix gcc version 9.0.0 20181216 (experimental) (GCC)
[Bug debug/79342] [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79342 H.J. Lu changed: What|Removed |Added Status|REOPENED|NEW --- Comment #13 from H.J. Lu --- index_string -> find_string_form -> set_indirect_string makes string indexes out of order.
[Bug debug/79342] [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79342
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #12 from H.J. Lu ---
On x86, r267186 fails:
[hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -march=skylake -mrtm -mabm -m32 -gsplit-dwarf
-g3 -O2 -S /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/pr79342.c
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/pr79342.c:18:1:
internal compiler error: in output_index_string, at dwarf2out.c:28777
18 | }
| ^
0xb751c7 output_index_string(indirect_string_node**, unsigned int*)
/export/gnu/import/git/sources/gcc/gcc/dwarf2out.c:28777
0xb75450 output_indirect_strings
/export/gnu/import/git/sources/gcc/gcc/dwarf2out.c:28865
0xb7aeac dwarf2out_finish
/export/gnu/import/git/sources/gcc/gcc/dwarf2out.c:31563
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[hjl@gnu-cfl-2 gcc]$
The problem is
Breakpoint 10, index_string (h=0x7fffea9910b0, index=0x7fffd6d4)
at /export/gnu/import/git/sources/gcc/gcc/dwarf2out.c:28734
28734 find_string_form (node);
Missing separate debuginfos, use: dnf debuginfo-install
gmp-6.1.2-8.0.fc29.x86_64 isl-0.16.1-7.0.fc29.x86_64
libmpc-1.1.0-2.0.fc29.x86_64 mpfr-3.1.6-2.fc29.x86_64
(gdb) p *node
$26 = {
str = 0x7fffea9554e0 "GNU C17 9.0.0 20181216 (experimental) -march=skylake
-mrtm -mabm -m32 -gsplit-dwarf -g3 -O2", refcount = 2, form = 0, label = 0x0,
index = 0}
(gdb)
Its form isn't DW_FORM_GNU_str_index.
(gdb) p *node
$27 = {
str = 0x7fffea9554e0 "GNU C17 9.0.0 20181216 (experimental) -march=skylake
-mrtm -mabm -m32 -gsplit-dwarf -g3 -O2", refcount = 2,
form = DW_FORM_GNU_str_index, label = 0x30adc00 "*.LASF375",
index = 4294967294}
(gdb)
Now it is.
[Bug middle-end/88518] Function call defeats -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88518
--- Comment #2 from Matthew Wilcox ---
Thanks! What I actually want to do is annotate g() to the effect that it reads
the pointed-to variable before it writes it. IOW, I want to write something
like:
void g(unsigned long __attribute__((read_before_write)) *p);
void h(void);
void f(void)
{
unsigned long i;
h();
g();
}
and have gcc emit a warning that i is used uninitialised. I tried adding i = i
prior to the call of g() through macro trickery, but was surprised that it
didn't trigger, and simplified down to this test-case.
Any chance I could get that attribute or something like it?
[Bug middle-end/41453] use INTENT(out) for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453 --- Comment #7 from Thomas Koenig --- Also still to do: Do some more precise clobbering for the case of PR88364, i.e. for call foo(a) clobber a%x, which is currently not done.
[Bug fortran/88364] [9 Regression] Wrong-code due to CLOBBER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88364 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Thomas Koenig --- Fixed by rr267187.
[Bug c/88363] [9 Regression] alloc_align attribute doesn't accept enumerated arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88363 --- Comment #5 from Thomas Koenig --- Author: tkoenig Date: Sun Dec 16 14:32:46 2018 New Revision: 267187 URL: https://gcc.gnu.org/viewcvs?rev=267187=gcc=rev Log: 2018-12-16 Thomas Koenig PF fortran/88364 * trans-expr.c (gfc_conv_expr_reference): Do not add clobber if the expression contains a reference. 2018-12-16 Thomas Koenig PR fortran/88363 * intent_out_13.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/intent_out_13.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/88512] Too much STL in error output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512 --- Comment #5 from Jonny Grant --- ICC 19.0.1 output (7): error: no instance of overloaded function "std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::erase [with _CharT=char, _Traits=std::char_traits, _Alloc=std::allocator]" matches the argument list argument types are: (std::size_t, __gnu_cxx::__normal_iterator, std::allocator>>) object type is: std::__cxx11::string str.erase(s, str.end()); ^ /opt/compiler-explorer/gcc-8.2.0/bin/../include/c++/8.2.0/bits/basic_string.h(1827): note: this candidate was rejected because arguments do not match erase(__const_iterator __first, __const_iterator __last) ^ /opt/compiler-explorer/gcc-8.2.0/bin/../include/c++/8.2.0/bits/basic_string.h(1808): note: this candidate was rejected because mismatch in count of arguments erase(__const_iterator __position) ^ /opt/compiler-explorer/gcc-8.2.0/bin/../include/c++/8.2.0/bits/basic_string.h(1789): note: this candidate was rejected because arguments do not match erase(size_type __pos = 0, size_type __n = npos) ^ compilation aborted for (code 2) Compiler returned: 2
[Bug target/88483] Unnecessary stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88483 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2018-12-16 Resolution|FIXED |--- Target Milestone|9.0 |10.0 Ever confirmed|0 |1 --- Comment #4 from H.J. Lu --- Revisit it in GCC 10.
[Bug target/88483] Unnecessary stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88483 --- Comment #3 from hjl at gcc dot gnu.org --- Author: hjl Date: Sun Dec 16 13:55:18 2018 New Revision: 267186 URL: https://gcc.gnu.org/viewcvs?rev=267186=gcc=rev Log: x86: Revert reversion 267133 Revert commit: commit 76c21b271247ccbd681bdb4530426d2fe35dbfa5 Author: hjl Date: Fri Dec 14 12:38:04 2018 + x86: Don't use get_frame_size when finalizing stack frame gcc/ PR target/88483 * config/i386/i386.c (ix86_finalize_stack_frame_flags): Revert reversion 267133. gcc/testsuite/ PR target/88483 * gcc.target/i386/stackalign/pr88483.c: Removed. Revert reversion 267133. Removed: trunk/gcc/testsuite/gcc.target/i386/stackalign/pr88483.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug lto/88422] collect2.exe: fatal error: lto-wrapper returned 1 exit status: file not recognized: file truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422 --- Comment #5 from Nidal Faour --- i've used the RV gcc official toolchain and reverted the patch as Jim did. and it passed in the test case, but when i moved to a bigger code, i failed again to build. and it turned out that it passed only if i drop the -g option from the compiling command. when using the -g option it will get the "file not recognized: file format not recognized" again. i've downloaded the RV toolchain from: https://github.com/riscv/riscv-gnu-toolchain configuration for linux building: ./configure --with-arch=rv64imafdc --with-abi=lp64d --enable-multilib --prefix= configuration for windows building: ./configure --with-arch=rv64imafdc --with-abi=lp64d --enable-multilib --without-system-zlib --with-cmodel=medany --with-host=x86_64-w64-mingw32 --prefix= test case can be found at: https://github.com/westerndigitalcorporation/riscv32-Code-density-test-bench/tree/master/lto_test_case
[Bug c/26732] different argument type not rejected for K style function definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #8 from Harald van Dijk --- (In reply to Eric Gallager from comment #7) > (In reply to Andrew Pinski from comment #6) > > Now we don't even error out at -O3. > > Why would the -O3 matter? -O3 enables inlining, which up until GCC 4.2 triggered an error on the parameter/argument type mismatch. But GCC is correct to not report an error for that. This is only undefined at runtime, so the compiler is required to allow this unless it can prove the execution will reach that point of the code. What's missing as of GCC 4.0 is GCC 3.4's default-enabled warning "warning: structure defined inside parms".
