[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-02 Status|UNCONFIRMED |WAITING Target||x86_64-linux
[Bug fortran/99326] [9/10/11 Regression] ICE in gfc_build_dummy_array_decl, at fortran/trans-decl.c:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99326 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |9.4
[Bug c/99325] [11 Regression] ICE in maybe_print_line_1, at c-family/c-ppoutput.c:454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99325 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-02 Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c/99324] ICE in mark_addressable, at gimple-expr.c:918
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99324
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-03-02
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed.
914 /* Also mark the artificial SSA_NAME that points to the partition of
X. */
915 if (TREE_CODE (x) == VAR_DECL
916 && !DECL_EXTERNAL (x)
917 && !TREE_STATIC (x)
918 && cfun->gimple_df != NULL
919 && cfun->gimple_df->decls_to_pointers != NULL)
920 {
(gdb) p cfun
$1 = (function *) 0x0
I suppose this could be made more robust by checking for cfun being non-NULL
or checking currently_expanding_to_rtl.
[Bug c/99323] [9/10/11 Regression] ICE in add_hint, at diagnostic-show-locus.c:2234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99323 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4 CC||dmalcolm at gcc dot gnu.org
[Bug c++/99318] [10/11 Regression] -Wdeprecated-declarations where non-should be?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99318 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3 Keywords||diagnostic, rejects-valid
[Bug c++/99336] New: [modules] ICE combining unordered_map, memory, module partitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99336 Bug ID: 99336 Summary: [modules] ICE combining unordered_map, memory, module partitions Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: practicaldesignbook at gmail dot com Target Milestone: --- Created attachment 50282 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50282=edit Input files A.cpp and Test.cpp with preprocessed source to trigger bug. version: gcc version 11.0.1 20210301 (experimental) target: x86_64-pc-linux-gnu build options: -disable-multilib --enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion g++ produces an internal compiler error when combining an unordered_map with a module partition, but only if the header is also included. My original code used a std::unique_ptr, but in reducing the bug to the minimal amount of code, I discovered that usage of std::unique_ptr is not required to trigger the bug. The bug is triggered by the inclusion of the header. Note, the code compiles correctly if the memory header is not included. g++ -fmodules-ts -std=c++20 -c A.cpp Test.cpp Test.cpp:1:8: internal compiler error: in tree_node, at cp/module.cc:9157 1 | export module Test; |^~ 0x69cde0 trees_out::tree_node(tree_node*) ../.././gcc/cp/module.cc:9157 0xa178c9 trees_out::core_vals(tree_node*) ../.././gcc/cp/module.cc:6027 0xa1aca4 trees_out::tree_node_vals(tree_node*) ../.././gcc/cp/module.cc:7168 0xa1aca4 trees_out::tree_value(tree_node*) ../.././gcc/cp/module.cc:8988 0xa16d64 trees_out::tree_node(tree_node*) ../.././gcc/cp/module.cc:9186 0xa178c9 trees_out::core_vals(tree_node*) ../.././gcc/cp/module.cc:6027 0xa1aca4 trees_out::tree_node_vals(tree_node*) ../.././gcc/cp/module.cc:7168 0xa1aca4 trees_out::tree_value(tree_node*) ../.././gcc/cp/module.cc:8988 0xa16d64 trees_out::tree_node(tree_node*) ../.././gcc/cp/module.cc:9186 0xa178c9 trees_out::core_vals(tree_node*) ../.././gcc/cp/module.cc:6027 0xa1aca4 trees_out::tree_node_vals(tree_node*) ../.././gcc/cp/module.cc:7168 0xa1aca4 trees_out::tree_value(tree_node*) ../.././gcc/cp/module.cc:8988 0xa16d64 trees_out::tree_node(tree_node*) ../.././gcc/cp/module.cc:9186 0xa178c9 trees_out::core_vals(tree_node*) ../.././gcc/cp/module.cc:6027 0xa1aca4 trees_out::tree_node_vals(tree_node*) ../.././gcc/cp/module.cc:7168 0xa1aca4 trees_out::tree_value(tree_node*) ../.././gcc/cp/module.cc:8988 0xa16d64 trees_out::tree_node(tree_node*) ../.././gcc/cp/module.cc:9186 0xa178c9 trees_out::core_vals(tree_node*) ../.././gcc/cp/module.cc:6027 0xa1aca4 trees_out::tree_node_vals(tree_node*) ../.././gcc/cp/module.cc:7168 0xa1aca4 trees_out::tree_value(tree_node*) ../.././gcc/cp/module.cc:8988 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.
[Bug c/99317] Missed warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99317 --- Comment #3 from Andrew Pinski --- Right. basically what I am saying is: x ? void* : char* implies an implict conversion of the second operand to void*. Without the cast, there is no implict conversion in standard C, that is what the warning is about. With -pendatic-errors, the warning turns into an error.
[Bug target/99038] aarch64_rtx_costs is missing tests for vector immediate forms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99038 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed||2021-03-02 Keywords||missed-optimization CC||pinskia at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c/99317] Missed warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99317 --- Comment #2 from Piotr --- @(In reply to Andrew Pinski from comment #1) > I dont think this is exactly a bug. The warning is a pedantic warning and > with void*, things are implicitly converted by standard c rules. With not `void *` it is exactly the same. https://godbolt.org/z/zM8Eqs No -pedantic option too.
[Bug ada/99095] [10/11 regression] couple of issues with unconstrained array of limited record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99095 Eric Botcazou changed: What|Removed |Added Target Milestone|--- |10.3 Last reconfirmed||2021-03-02 Status|UNCONFIRMED |NEW Summary|Unconstrained array of |[10/11 regression] couple |limited records results in |of issues with |a bounds bug. |unconstrained array of ||limited record CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- I can reproduce.
[Bug ada/99020] ICE in record containing discriminated accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Eric Botcazou --- This should compile now.
[Bug ada/99020] ICE in record containing discriminated accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020 --- Comment #3 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:3104dbdcf4a2b7766b5570a0fa2d30157082f04e commit r11-7444-g3104dbdcf4a2b7766b5570a0fa2d30157082f04e Author: Eric Botcazou Date: Tue Mar 2 01:04:10 2021 +0100 Do not call Set_Cloned_Subtype on private type Build_Discriminated_Subtype may be invoked on a E_Record_Type_With_Private, in which case it builds a E_Record_Subtype_With_Private which does not have the Cloned_Subtype field. gcc/ada/ PR ada/99020 * sem_ch3.adb (Build_Discriminated_Subtype): Set the Cloned_Subtype only if the type is not private.
[Bug ada/99020] ICE in record containing discriminated accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | --- Comment #2 from Eric Botcazou --- Fixing.
[Bug c/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- GCC 6.2 is not supported anymore (nor 7.x). I can't reproduce the code you posted with any of 5.5, 6.4.1, 7.4.1 nor current trunk. If you can't reproduce with a supported compiler, there is nothing to do, if you can, you'll need to specify version and how exactly it has been configured e.g. if you have some non-standard default --with-tune=, --with-arch= etc.
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 --- Comment #28 from anlauf at gcc dot gnu.org --- Patch for accepts-invalid / ice-on-invalid-code (parameter + data) part: https://gcc.gnu.org/pipermail/fortran/2021-March/055768.html
[Bug c++/99335] New: Comma Operator Evaluation Order - C++ 11 and newer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99335
Bug ID: 99335
Summary: Comma Operator Evaluation Order - C++ 11 and newer
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aatsnps at gmail dot com
Target Milestone: ---
Filing a bug for tracking this issue:
Test Case:
#include
struct CBI;
struct EC;
struct CET;
struct CBI {
CBI& operator,(const CBI& rhs)
{ return *const_cast(); }
};
struct EC : CBI {
explicit EC(CET* cet) : cet_(cet)
{}
CET* cet_;
};
struct CET {
CBI& operator,(const CBI& rhs) const
{ return *const_cast(); }
operator EC&() const
{ return *new EC(const_cast(this)); }
};
static const CET&
hello() {
std::cout << "Hello " << std::endl;
return *new CET();
}
static const CET&
world() {
std::cout << "World " << std::endl;
return *new CET();
}
static void
test_comma_operator(CBI&) {
}
int main()
{
test_comma_operator ((
hello(),
world()
));
}
As per rule 16 from https://en.cppreference.com/w/cpp/language/eval_order , the
eval order of the above listed test case doesn't look right.
16) Every overloaded operator obeys the sequencing rules of the built-in
operator it overloads when called using operator notation.
CLANG appears to do it right, however, g++ appears to do it wrong.
us01odcvde08782> clang++ -g test.cpp
us01odcvde08782> ./a.out
Hello
World
us01odcvde08782> g++ -g test.cpp
us01odcvde08782> ./a.out
World
Hello
us01odcvde08782>
I was using CentOS6.8 with gcc 6.2. However, trying other versions of GCC
didn't make any difference.
My understanding, based on the rule 16 and the discussions below, is that it is
a GCC bug, so filing a bug.
More details/discussions below:
On Thu, Feb 4, 2021 at 1:33 PM David Brown wrote:
On 04/02/2021 22:21, Andreas Schwab wrote:
> On Feb 04 2021, David Brown wrote:
>
>> For the built-in comma operator, you get guaranteed order of evaluation
>> (or more precisely, guaranteed order of visible side-effects). But for
>> a user-defined comma operator, you do not - until C++17, which has
>> guaranteed evaluation ordering in some circumstances.
>
> But not the evaluation order of function arguments. See
> Sequenced-before
> rules, rule 15.
Correct.
>
>> Try your test again with "-std=c++17" or "-std=g++17" - if the order is
>> still reversed, it's a gcc bug (AFAICS).
>
> I don't think so.
>
Unless I am missing something, in the OP's program it is a user-defined
comma operator that is called. There is only one argument to the
"test_comma_operator" function, the result of that user-defined comma
operator. So rule 15 above does not apply - rule 16 applies.
At least that is /my/ reading of the cppreference page and the OP's program.
David
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #38 from Mikael Pettersson --- After updating binutils to ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0, including the fix for BZ 27268, I was able to do a full bootstrap of current gcc head on Cygwin64. https://sourceware.org/bugzilla/show_bug.cgi?id=27268 has more detail.
[Bug c/99334] New: Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334 Bug ID: 99334 Summary: Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: aatsnps at gmail dot com Target Milestone: --- Created attachment 50281 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50281=edit Function gp_fs_solve_top_cons in the attached gp_fs_solve_gcc.i file will have this issue in the generated DWARF Filing a bug for tracking this: Compile Time Switches Used: gcc -Werror -Wall -Wpointer-arith -Wnested-externs -Wmissing-prototypes -Wextra -Wmissing-braces -Wformat=2 -Wno-format-nonliteral -Wno-format-nonliteral -Wno-unused-parameter -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -fdiagnostics-show-option -Wno-missing-field-initializers -fno-dollars-in-identifiers -Wno-unused-local-typedefs -Xassembler -mrelax-relocations=no -m64 -msse2 -fPIC -D__NO_STRING_INLINES -mstackrealign -DLINUX -m64 -rdynamic -DMM_MODE=0 -DLINUX_X86_64 -fPIC -DLINUX_X86_64 -DLONG_PTR_64 -DVM_LITTLE_ENDIAN -DMM_MODE=0 -rdynamic -O3 -fPIC -fomit-frame-pointer -fPIC -O3 -msse2 -fno-strict-aliasing -fPIC -fomit-frame-pointer -c gp_fs_solve_gcc.i On Tue, Oct 13, 2020 at 5:10 AM AJ D via Gcc wrote: > > Hi, > > > > I have a function for which GCC is generating the following code (just > showing the relevant snippet here). > > > > 5a70 : > > 5a70: 4c 8d 54 24 08 lea0x8(%rsp),%r10 > > 5a75: 48 83 e4 f0 and$0xfff0,%rsp > > 5a79: 41 ff 72 f8 pushq -0x8(%r10) > > 5a7d: 55 push %rbp > > 5a7e: 48 89 e5mov%rsp,%rbp > > 5a81: 41 57 push %r15 > > 5a83: 41 56 push %r14 > > 5a85: 41 55 push %r13 > > 5a87: 41 54 push %r12 > > : > > 5b08: 5b pop%rbx > > 5b09: 41 5a pop%r10 > > 5b0b: 41 5c pop%r12 > > 5b0d: 41 5d pop%r13 > > 5b0f: 41 5e pop%r14 > > 5b11: 41 5f pop%r15 > > 5b13: 5d pop%rbp > > *=>5b14: 49 8d 62 f8 lea-0x8(%r10),%rsp* > > 5b18: c3 retq > > > > I am using a SIGPROF based CPU profiler (Google CPU Profiler) to profile my > code. The SIGPROF handler (of the Google CPU Profiler) tries to unwind the > stack (using libunwind) every time it gets a SIGPROF. And libunwind (used > for unwinding the stack) uses DWARF unwind table (dumped by gcc -O3 > -mstackrealign -fomit-frame-pointer). > > > And I noticed that I get a crash every time my code gets interrupted by > SIGPROF while my program is in the middle of setting / resetting frame > pointer and the frame pointer %rbp happens to point to the parent/previous > frame at that point, for example, in instruction *5b14* (shown above with > => and red). > > > > *=>5b14: 49 8d 62 f8 lea-0x8(%r10),%rsp* > > > DWARF dumped by GCC for the snippet shown above is the following: > > > > 02f4 0044 02f8 FDE cie= > pc=5a70..5d7c > > DW_CFA_advance_loc: 5 to 5a75 > > DW_CFA_def_cfa: r10 (r10) ofs 0 > > DW_CFA_advance_loc: 9 to 5a7e > > DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) > > DW_CFA_advance_loc: 11 to 5a89 > > DW_CFA_expression: r15 (r15) (DW_OP_breg6 (rbp): -8) > > DW_CFA_expression: r14 (r14) (DW_OP_breg6 (rbp): -16) > > DW_CFA_expression: r13 (r13) (DW_OP_breg6 (rbp): -24) > > DW_CFA_expression: r12 (r12) (DW_OP_breg6 (rbp): -32) > > DW_CFA_advance_loc: 5 to 5a8e > > DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref) > > DW_CFA_advance_loc: 4 to 5a92 > > *>> DW_CFA_expression: r3 (rbx) (DW_OP_breg6 (rbp): -48)* > > DW_CFA_advance_loc1: 121 to 5b0b > > DW_CFA_remember_state > > *>> DW_CFA_def_cfa: r10 (r10) ofs 0* > > DW_CFA_advance_loc: 13 to 5b18 > > DW_CFA_def_cfa: r7 (rsp) ofs 8 > > DW_CFA_advance_loc: 8 to 5b20 > > DW_CFA_restore_state > > > > 02f4 0044 02f8 FDE cie= > pc=5a70..5d7c > >LOC CFA rbx rbp r12 r13 r14 r15 ra > > 5a70 rsp+8u u u u u u c-8 > > 5a75 r10+0u u u u u u c-8 > > 5a7e r10+0u exp u u u u c-8 > > 5a89 r10+0u exp exp exp exp exp c-8 >
[Bug libstdc++/99333] New: std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333
Bug ID: 99333
Summary: std::filesystem::path().is_absolute() thinks UNC paths
aren't absolute
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: moritz at bunkus dot org
Target Milestone: ---
Created attachment 50280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50280=edit
test case
Compiling with gcc 10.2.0 from the mxe cross compilation environment for
Windows.
The attached sample program says it all. It shows that
std::filesystem::("\\server\share\file.txt").is_absolute() is false and turns
std::filesystem::absolute("\\server\share\file.txt") into something like
"C:\server\share\file.txt".
boost::filesystem::path(…).is_aboslute(), on the other hand, considers UNC
paths absolute & leaves them unmodified via boost::filesystem::absolute(…)
The test program outputs the following:
std::filesystem:
original \\disky\mosu\existing_file.txt
is_absolute 0
absolute "C:\\disky\\mosu\\existing_file.txt"
boost::filesystem:
original \\disky\mosu\existing_file.txt
is_absolute 1
absolute "\\disky\mosu\existing_file.txt"
Compile with something like:
x86_64-w64-mingw32.static-g++ -std=c++17 \
-I/home/mosu/prog/video/mingw/cross/usr/x86_64-w64-mingw32.static/include \
-L/home/mosu/prog/video/mingw/cross/usr/x86_64-w64-mingw32.static/lib \
-o std_filesystem_unc_paths_vs_absolute.exe \
std_filesystem_unc_paths_vs_absolute.cpp \
-lboost_filesystem-mt-s-x64 -lboost_system-mt-s-x64
[Bug c++/98432] [coroutine] leaked frame created using await_transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432 --- Comment #6 from Iain Sandoe --- (In reply to Tomáš Hering from comment #5) > Created attachment 50278 [details] > unprocessed original source > > Oops, seems I uploaded a slightly different code. I apologize. It's strange > you can't reproduce the issue, though. Please see the demo with the original > code on godbolt (https://godbolt.org/z/Gao919) which is in accordance with > my local output. Please note that the behavior now seems correct when > setting the trunk version of gcc there. Perhaps it has been fixed in some > recent commit. >From my tests, it is fixed on 10.x and master - (In reply to Tomáš Hering from comment #5) > Created attachment 50278 [details] > unprocessed original source > > Oops, seems I uploaded a slightly different code. I apologize. It's strange > you can't reproduce the issue, though. Please see the demo with the original > code on godbolt (https://godbolt.org/z/Gao919) which is in accordance with > my local output. Please note that the behavior now seems correct when > setting the trunk version of gcc there. Perhaps it has been fixed in some > recent commit. So, even with the original code copied from Compiler Explorer, from my tests, this is fixed on 10.x and master, therefore I think we can close it here (unless you want to make a build of the 10.x branch on your platform to double-check).
[Bug c/99276] grammar in diagnostics for overflowing the destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99276 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c/99276] grammar in diagnostics for overflowing the destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99276 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-01 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed.
[Bug rtl-optimization/99332] New: ICE:inreset_sched_cycles_in_current_ebb, at sel-sched.c:7147 with -fprofile-generate -O3 -fselective-scheduling -fselective-scheduling2 -fsel-sched-pipelining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99332
Bug ID: 99332
Summary: ICE:inreset_sched_cycles_in_current_ebb, at
sel-sched.c:7147 with -fprofile-generate -O3
-fselective-scheduling -fselective-scheduling2
-fsel-sched-pipelining
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
This testing case is reduced from CPU2017 511.povray, it appears on aarch64
with both gcc11 and gcc10:
$ cat t.C
class OStream {
public:
void printf(...);
};
typedef double VECTOR[3];
enum { X, Y, Z };
typedef struct ot_block_struct OT_BLOCK;
typedef int OT_NODE;
struct ot_block_struct {
OT_BLOCK *next;
VECTOR Point, S_Normal;
VECTOR To_Nearest_Surface;
short Bounce_Depth;
};
bool ot_write_block(OT_BLOCK *, void *);
bool ot_traverse(OT_NODE *, bool function(OT_BLOCK *, void *), void *handle) {
bool oksofar;
OT_BLOCK *this_block;
while (this_block) {
function(this_block, handle);
this_block = this_block->next;
}
return oksofar;
}
bool ot_save_tree() {
int *fd, *root;
ot_traverse(root, ot_write_block, fd);
}
bool ot_write_block(OT_BLOCK *bl, void *fd) {
((OStream *)fd)->printf(
bl[Z], bl->S_Normal[X] * int(bl->S_Normal[Z] * .5 * 254. + .49),
bl[Z], int(bl->To_Nearest_Surface[X]),
int((bl->To_Nearest_Surface[Y] + 1.) * .5 * 254. + .49),
int((bl->To_Nearest_Surface[Z] + 1.) * .5 * 254. + .49));
return true;
}
[qzlocal@ca-dev-arm06 bug_2]$ sh t
/data1/qing/Install/latest/bin/g++ -fprofile-generate -O3
-fselective-scheduling -fselective-scheduling2 -fsel-sched-pipelining -c -o t.o
t.C
t.C: In function 'bool ot_save_tree()':
t.C:29:1: warning: no return statement in function returning non-void
[-Wreturn-type]
29 | }
| ^
during RTL pass: sched2
t.C:29:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at
sel-sched.c:7147
0x1063387 reset_sched_cycles_in_current_ebb
../../latest_gcc/gcc/sel-sched.c:7147
0x1063387 sel_region_target_finish
../../latest_gcc/gcc/sel-sched.c:7220
0x1063387 sel_region_finish
../../latest_gcc/gcc/sel-sched.c:7276
0x1063387 sel_sched_region(int)
../../latest_gcc/gcc/sel-sched.c:7645
0x1063593 run_selective_scheduling()
../../latest_gcc/gcc/sel-sched.c:7720
0x103e70b rest_of_handle_sched2
../../latest_gcc/gcc/sched-rgn.c:3738
0x103e70b execute
../../latest_gcc/gcc/sched-rgn.c:3882
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/48097] gcc sometimes generates code that uses the buggy libgcc_s unwinder on darwin (originally exposed by Throw_2 failures in libjava testsuite under Xcode 4.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #18 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:491d5b3cf8216f9285a67aa213b9a66b0035137b commit r11-7443-g491d5b3cf8216f9285a67aa213b9a66b0035137b Author: Iain Sandoe Date: Mon Jan 18 20:09:10 2021 + dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097]. This address one of the more long-standing and serious regressions for Darwin. GCC emits unwind code by default on the assumption that the unwinder will be (of have the same capability) as the one in the current libgcc_s. For Darwin platforms, this is not the case - some of them are based on the libgcc_s from GCC-4.2.1 and some are using the unwinder provided by libunwind (part of the LLVM project). The latter implementation has gradually adopted a section that deals with GNU unwind. The most serious problem for some of the platform versions is in handling DW_CFA_remember/restore_state pairs. The DWARF description talks about these in terms of saving/restoring register rows; this is what GCC originally did (and is what the unwinders do for the Darwin versions based on libgcc_s). However, in r118068, this was changed so that not only the registers but also the current frame address expression were saved. The unwind code assumes that the unwinder will do this; some of Darwin's unwinders do not, leading to lockups etc. To date, the only solution has been to replace the system libgcc_s with a newer one which is not a viable solution for many end-users (since that means overwritting the one provided with the system installation). The fix here provides a target hook that allows the target to specify that the CFA should be reinstated after a DW_CFA_restore. This fixes the issue (and also the closed WONTFIX of 44107). (As a matter of record, it also fixes reported Java issues if backported to GCC-5). gcc/ChangeLog: PR target/44107 PR target/48097 * config/darwin-protos.h (darwin_should_restore_cfa_state): New. * config/darwin.c (darwin_should_restore_cfa_state): New. * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New. * doc/tm.texi: Regenerated. * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE. * dwarf2cfi.c (connect_traces): If the target requests, restore the CFA expression after a DW_CFA_restore. * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook.
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #34 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:491d5b3cf8216f9285a67aa213b9a66b0035137b commit r11-7443-g491d5b3cf8216f9285a67aa213b9a66b0035137b Author: Iain Sandoe Date: Mon Jan 18 20:09:10 2021 + dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097]. This address one of the more long-standing and serious regressions for Darwin. GCC emits unwind code by default on the assumption that the unwinder will be (of have the same capability) as the one in the current libgcc_s. For Darwin platforms, this is not the case - some of them are based on the libgcc_s from GCC-4.2.1 and some are using the unwinder provided by libunwind (part of the LLVM project). The latter implementation has gradually adopted a section that deals with GNU unwind. The most serious problem for some of the platform versions is in handling DW_CFA_remember/restore_state pairs. The DWARF description talks about these in terms of saving/restoring register rows; this is what GCC originally did (and is what the unwinders do for the Darwin versions based on libgcc_s). However, in r118068, this was changed so that not only the registers but also the current frame address expression were saved. The unwind code assumes that the unwinder will do this; some of Darwin's unwinders do not, leading to lockups etc. To date, the only solution has been to replace the system libgcc_s with a newer one which is not a viable solution for many end-users (since that means overwritting the one provided with the system installation). The fix here provides a target hook that allows the target to specify that the CFA should be reinstated after a DW_CFA_restore. This fixes the issue (and also the closed WONTFIX of 44107). (As a matter of record, it also fixes reported Java issues if backported to GCC-5). gcc/ChangeLog: PR target/44107 PR target/48097 * config/darwin-protos.h (darwin_should_restore_cfa_state): New. * config/darwin.c (darwin_should_restore_cfa_state): New. * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New. * doc/tm.texi: Regenerated. * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE. * dwarf2cfi.c (connect_traces): If the target requests, restore the CFA expression after a DW_CFA_restore. * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook.
[Bug c/99322] [11 Regression] ICE in change_scope, at final.c:1480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99322 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||openmp
[Bug target/99321] [11 Regression] ICE: in extract_constrain_insn, at recog.c:2670: insn does not satisfy its constraints: {*uminv16qi3} since r11-7121-g37876976b0511ec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
--- Comment #2 from Jakub Jelinek ---
I'm afraid we have multiple problems with -mavx512vl -mno-avx512bw (are there
any CPUs with that combination of ISA sets though?).
In r7-618-g9bdf001b7a2232753e4a92582218bb4f24c8d809 I've fixed the 16-byte
vp{min,max}ub to not allow v constraints when not AVX512BW.
But clearly many other patterns need something like that and don't have that.
E.g. vp{add,sub,{min,max},{u,s}}{b,w}, both 16-byte and 32-byte.
The result of that aren't ICEs, but code silently using AVX512BW features when
AVX512VL is enabled but AVX512BW is not.
Similarly, vpmullq needs AVX512DQ.
And, another thing is that the:
(define_peephole2
[(set (match_operand 0 "sse_reg_operand")
(match_operand 1 "sse_reg_operand"))
(set (match_dup 0)
(match_operator 3 "commutative_operator"
[(match_dup 0)
(match_operand 2 "memory_operand")]))]
"REGNO (operands[0]) != REGNO (operands[1])"
[(set (match_dup 0) (match_dup 2))
(set (match_dup 0)
(match_op_dup 3 [(match_dup 0) (match_dup 1)]))])
peephole2 doesn't work and results in ICEs if the patterns are correct (as is
the case of *uminv16qi3) if one is unlucky and operands[1] is [xy]mm16 or
higher register and operands[0] is not.
[Bug c++/99331] [8/9/10/11 Regression] -Wconversion false-positive in immediate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331
--- Comment #3 from Nikita Kniazev ---
This one most likely has the same root problem:
template struct X {};
template
struct foo { using t = X; };
:3:26: error: conversion from 'long unsigned int' to 'int' may change
value [-Werror=conversion]
3 | struct foo { using t = X; };
| ^
[Bug c++/99331] [8/9/10/11 Regression] -Wconversion false-positive in immediate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with commit 16b61424dd309f61326f577a6deb8487c6c1f291 Author: Jason Merrill Date: Fri Oct 21 15:45:45 2016 -0400 re PR c++/77656 (64-bit integral template parameter gets incorrectly sized as 32-bits) PR c++/77656 * pt.c (convert_template_argument): Call convert_nontype_argument on value-dependent but not type-dependent arguments. (convert_nontype_argument): Handle value-dependent arguments. (canonicalize_expr_argument): New. (deducible_expression, unify): Skip CONVERT_EXPR. * error.c (dump_template_argument): Likewise. * mangle.c (write_expression): Likewise. From-SVN: r241425 think I'll have a look at this myself, though.
[Bug middle-end/99299] Need a recoverable version of __builtin_trap()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #9 from Segher Boessenkool ---
The i386 port has
===
(define_insn "trap"
[(trap_if (const_int 1) (const_int 6))]
""
{
#ifdef HAVE_AS_IX86_UD2
return "ud2";
#else
return ASM_SHORT "0x0b0f";
#endif
}
[(set_attr "length" "2")])
===
which implements __builtin_trap, and can implement __builtin_trap_no_abort
just fine as well, if your OS kernel (or similar) can return after a ud2.
If clang uses terribly confusing names (or semantics, or syntax, etc.) we
should not copy that from them. *Especially* when that already conflicts
with names they copied from us.
[Bug c++/99331] [8/9/10/11 Regression] -Wconversion false-positive in immediate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Summary|-Wconversion false-positive |[8/9/10/11 Regression] |in immidiate context|-Wconversion false-positive ||in immediate context Target Milestone|--- |8.5 Priority|P3 |P2 Last reconfirmed||2021-03-01 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed. Started in GCC 7.
[Bug c++/99331] New: -Wconversion false-positive in immidiate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331
Bug ID: 99331
Summary: -Wconversion false-positive in immidiate context
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
template struct X {};
template X foo();
g++ -Wconversion -Werror src.cpp
:2:22: error: conversion from 'long unsigned int' to 'int' may change
value [-Werror=conversion]
2 | template X foo();
| ^
https://godbolt.org/z/d16WhG
[Bug middle-end/95757] [11 regression] missing warning in gcc.dg/Wstringop-overflow-25.c since r11-1517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757 --- Comment #9 from Jakub Jelinek --- Created attachment 50279 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50279=edit gcc11-pr95757.patch Untested fix.
[Bug fortran/87127] External function not recognised from within an associate block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127 --- Comment #9 from Vladimir Fuka --- I see now, it was fixed on the 8 branch, but not on the trunk! It ought to be applied at least to the 12.
[Bug middle-end/99299] Need a recoverable version of __builtin_trap()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299 --- Comment #8 from Franz Sirl --- (In reply to Segher Boessenkool from comment #7) > (In reply to Franz Sirl from comment #5) > > For the naming I suggest __builtin_debugtrap() to align with clang. Maybe > > with an aliased __debugbreak() on Windows platforms. > > Those are terrible names. This would *not* be used more often than > __builtin_trap, for debugging. > > In general, builtins should say what they *do*, nott what you imagine they > will be used for. Let me re-phrase it. If the result of this discussion will result in a builtin that will be eqivalent to an "int 3" (or was it ud2? on x86) without "noreturn" as it is with clang, I would really prefer it to be called __builtin_debugtrap() even if the name is not great. Having different naming between GCC and clang seems worse to me.
[Bug c/99295] [9/10/11 Regression] documentation on __attribute__((malloc)) is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99295 Martin Sebor changed: What|Removed |Added Known to fail||10.2.1, 9.3.0 Summary|[11 Regression] |[9/10/11 Regression] |documentation on|documentation on |__attribute__((malloc)) is |__attribute__((malloc)) is |wrong |wrong Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Known to work|10.2.1 |8.3.0 Keywords||patch Status|NEW |ASSIGNED --- Comment #3 from Martin Sebor --- I agree the insertion of the sentence: Compiler predicts that a function with the attribute returns non-null in most cases. make the following sentence at least ambiguous if not incorrect. The sentence was added in r263355, in response to pr83023. I have posted the following change to avoid the unintended reading: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566030.html
[Bug target/99271] [10 regression] Wrong code for Arm-v8-m.main CMSE calling __gnu_cmse_nonsecure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Earnshaw --- Fixed on all affected branches.
[Bug c++/98432] [coroutine] leaked frame created using await_transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432 Tomáš Hering changed: What|Removed |Added Attachment #50276|0 |1 is obsolete|| --- Comment #5 from Tomáš Hering --- Created attachment 50278 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50278=edit unprocessed original source Oops, seems I uploaded a slightly different code. I apologize. It's strange you can't reproduce the issue, though. Please see the demo with the original code on godbolt (https://godbolt.org/z/Gao919) which is in accordance with my local output. Please note that the behavior now seems correct when setting the trunk version of gcc there. Perhaps it has been fixed in some recent commit.
[Bug target/99271] [10 regression] Wrong code for Arm-v8-m.main CMSE calling __gnu_cmse_nonsecure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:1b3bb23a576e6a864f540e3bea5097f47fea507c commit r10-9398-g1b3bb23a576e6a864f540e3bea5097f47fea507c Author: Richard Earnshaw Date: Mon Feb 22 15:00:53 2021 + arm: force use of r4 for __gnu_cmse_nonsecure_call when !FPCXT [PR99271] Commit r10-6017 relaxed the constraint on thumb2 calls to __gnu_cmse_nonsecure_call to allow any register for the call address. Although the initial code expansion continues to use r4 with the FPCXT extension is not enabled, the change was unsafe because subsequent optimizations could use the additional freedom to change which register was being used. To fix this we need to split the output patterns in the machine description to use distinct recognizers: one with the additional freedom when FPCXT is enabled an another that retains the original restrictions when the extension is not available. gcc: PR target/99271 * config/arm/thumb2.md (nonsecure_call_reg_thumb2_fpcxt): New pattern. (nonsecure_call_value_reg_thumb2_fpcxt): Likewise. (nonsecure_call_reg_thumb2): Restrict to using r4 for the callee address and disable when the FPCXT is not available. (nonsecure_call_value_reg_thumb2): Likewise. gcc/testsuite: * gcc.target/arm/cmse/cmse-18.c: New test.
[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 Jonathan Wakely changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-03-01 Target||*-pc-msdosdjgpp
[Bug c++/99330] New: module ICE with -std=c++2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99330
Bug ID: 99330
Summary: module ICE with -std=c++2b
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
module;
export module hello;
export inline void greeter()
{
}
cqwrteur@DESKTOP-DFHPDC1:/mnt/d/Desktop/hello$ g++ -c hello.cc -Ofast
-std=c++20 -s -flto -march=native -std=c++2b -fmodules-ts
hello.cc:2:8: internal compiler error: in get_cxx_dialect_name, at
cp/name-lookup.c:7027
2 | export module hello;
|^~
emit..
-std=c++2b triggers fmodules-ts to ICE
[Bug c/99329] New: [OpenMP] device_type(nohost) & host code diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99329
Bug ID: 99329
Summary: [OpenMP] device_type(nohost) & host code diagnostic
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid, openmp
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Based on https://github.com/SOLLVE/sollve_vv/pull/304#issuecomment-788114379
not yet looked into it.
#pragma omp declare target
int a[N], b[N], c[N];
int i = 0;
#pragma omp end declare target
void update() {
for (i = 0; i < N; i++) {
a[i] += 1;
b[i] += 2;
c[i] += 3;
}
}
#pragma omp declare target to(update) device_type(nohost)
int test_declare_target_device_type_nohost() {
#pragma omp target update to(a,b,c)
#pragma omp target
{
// if (!omp_is_initial_device()) // < no change with this.
update();
}
...
CLANG gives for this:
nohost.c:42:6: error: function with 'device_type(nohost)' is not available on
host
update();
^
nohost.c:34:31: note: marked as 'device_type(nohost)' here
#pragma omp declare target to(update) device_type(nohost)
[Bug c/99317] Missed warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99317 --- Comment #1 from Andrew Pinski --- I dont think this is exactly a bug. The warning is a pedantic warning and with void*, things are implicitly converted by standard c rules.
[Bug rtl-optimization/99328] New: ICE: in verify_target_availability, at sel-sched.c:1557 with -fselective-scheduling2 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99328
Bug ID: 99328
Summary: ICE: in verify_target_availability, at
sel-sched.c:1557 with -fselective-scheduling2 on
aarch64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
gcc11 has the following ICE:
$ cat t.c
long a;
double b, c;
double fn1(double);
void fn2(long *);
void fn3(int p1) {
fn2();
if (fn1(0) >= p1)
b = c;
}
$ sh t
/data1/qing/Install/latest/bin/gcc -fprofile-generate -Ofast
-fselective-scheduling -fselective-scheduling2 -c -o t.o t.c
during RTL pass: sched2
t.c: In function 'fn3':
t.c:9:1: internal compiler error: in verify_target_availability, at
sel-sched.c:1557
9 | }
| ^
0xd86fbb verify_target_availability
../../latest_gcc/gcc/sel-sched.c:1553
0xd86fbb find_best_reg_for_expr
../../latest_gcc/gcc/sel-sched.c:1667
0xd89f33 fill_vec_av_set
../../latest_gcc/gcc/sel-sched.c:3784
0xd89f33 fill_ready_list
../../latest_gcc/gcc/sel-sched.c:4014
0xd89f33 find_best_expr
../../latest_gcc/gcc/sel-sched.c:4374
0xd89f33 fill_insns
../../latest_gcc/gcc/sel-sched.c:5535
0xd8ba17 schedule_on_fences
../../latest_gcc/gcc/sel-sched.c:7353
0xd8ba17 sel_sched_region_2
../../latest_gcc/gcc/sel-sched.c:7491
0xd8c517 sel_sched_region_1
../../latest_gcc/gcc/sel-sched.c:7533
0xd8e573 sel_sched_region(int)
../../latest_gcc/gcc/sel-sched.c:7634
0xd8f1b7 run_selective_scheduling()
../../latest_gcc/gcc/sel-sched.c:7720
0xd6a32f rest_of_handle_sched2
../../latest_gcc/gcc/sched-rgn.c:3738
0xd6a32f execute
../../latest_gcc/gcc/sched-rgn.c:3882
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 --- Comment #1 from cqwrteur --- Created attachment 50277 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50277=edit DJGPP's original errno This is djgpp crt's original errno.
[Bug c++/99327] New: ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 Bug ID: 99327 Summary: ENOTSUP macro does not exist on djgpp crt Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- libstdc++'s filesystem uses std::errc::not_supported but that does not exist on djgpp. Bootstrap failure What I did was just #define ENOTSUP 42 in errno.h and bootstrap succeed However, strerror will not work for this anymore. There is another solution for this. Replace all std::errc::not_supported to std::errc::invalid_argument since EINVAL should exist on all platforms.
[Bug fortran/99326] New: [9/10/11 Regression] ICE in gfc_build_dummy_array_decl, at fortran/trans-decl.c:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99326 Bug ID: 99326 Summary: [9/10/11 Regression] ICE in gfc_build_dummy_array_decl, at fortran/trans-decl.c:1299 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r9, changed between 20181014 and 20181021 : $ cat z1.f90 program p type t0 end type type t class(t0), allocatable :: a(:) end type contains subroutine s(x) class(t0) :: x(:) type(t) :: z associate (y => x) z%a = y end associate end end $ gfortran-9-20181014 -c z1.f90 z1.f90:11:23: 11 | associate (y => x) | 1 Error: Assumed shape array at (1) must be a dummy argument $ gfortran-11-20210228 -c z1.f90 z1.f90:1:9: 1 | program p | 1 internal compiler error: in gfc_build_dummy_array_decl, at fortran/trans-decl.c:1299 0x754a97 gfc_build_dummy_array_decl ../../gcc/fortran/trans-decl.c:1299 0x759043 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1697 0x75c05f generate_local_decl ../../gcc/fortran/trans-decl.c:5950 0x71af42 do_traverse_symtree ../../gcc/fortran/symbol.c:4170 0x75d004 generate_local_vars ../../gcc/fortran/trans-decl.c:6156 0x75d004 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6815 0x75cfe4 gfc_generate_contained_functions ../../gcc/fortran/trans-decl.c:5874 0x75cfe4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6812 0x6e3a46 translate_all_program_units ../../gcc/fortran/parse.c:6351 0x6e3a46 gfc_parse_file() ../../gcc/fortran/parse.c:6620 0x72fd7f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug c/99325] New: [11 Regression] ICE in maybe_print_line_1, at c-family/c-ppoutput.c:454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99325 Bug ID: 99325 Summary: [11 Regression] ICE in maybe_print_line_1, at c-family/c-ppoutput.c:454 Product: gcc Version: 11.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 20201115 and 20201122 : $ cat z1.c #line 9223372036854775807 #pragma message "abc" $ gcc-11-20210228 -c z1.c -no-integrated-cpp z1.c:1:7: warning: line number out of range 1 | #line 9223372036854775807 | ^~~ z1.c:-1: internal compiler error: Segmentation fault 0xb5eeff crash_signal ../../gcc/toplev.c:327 0x6edd15 maybe_print_line_1 ../../gcc/c-family/c-ppoutput.c:454 0x6edd15 maybe_print_line ../../gcc/c-family/c-ppoutput.c:479 0x6ee7fe token_streamer::stream(cpp_reader*, cpp_token const*, unsigned int) ../../gcc/c-family/c-ppoutput.c:270 0x6eea03 scan_translation_unit ../../gcc/c-family/c-ppoutput.c:322 0x6eea03 preprocess_file(cpp_reader*) ../../gcc/c-family/c-ppoutput.c:102 0x6ecf90 c_common_init() ../../gcc/c-family/c-opts.c:1195 0x62f8bd lang_dependent_init ../../gcc/toplev.c:1889 0x62f8bd do_compile ../../gcc/toplev.c:2186
[Bug fortran/87127] External function not recognised from within an associate block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127 Vladimir Fuka changed: What|Removed |Added CC||vladimir.fuka at gmail dot com --- Comment #8 from Vladimir Fuka --- I see a comment but at the same time the status is NEW. What is the actual status? In any case, the issue still exists in GCC 11. https://stackoverflow.com/questions/66424857/dlantr-at-1-is-not-a-function/66425244?noredirect=1#comment117432549_66425244
[Bug target/99143] Bad section alignment on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #8 from Richard Earnshaw --- There is nothing in C (or other languages for that matter) that will guarantee that independent objects will be packed without space around them. So the premise of this bug report is simply invalid.
[Bug c/99324] New: ICE in mark_addressable, at gimple-expr.c:918
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99324
Bug ID: 99324
Summary: ICE in mark_addressable, at gimple-expr.c:918
Product: gcc
Version: 11.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 r6, with missing ";" at /// :
$ cat z1.c
#include
void f (int x, ...)
{
va_list a;
va_arg (a, int);
int b () ///;
int c[va_arg (a, int)];
va_end (a);
return;
}
$ gcc-11-20210228 -c z1.c
z1.c: In function 'b':
z1.c:7:3: internal compiler error: Segmentation fault
7 | int c[va_arg (a, int)];
| ^~~
0xb5eeff crash_signal
../../gcc/toplev.c:327
0x8c6733 mark_addressable(tree_node*)
../../gcc/gimple-expr.c:918
0x6ce03c build_va_arg(unsigned int, tree_node*, tree_node*)
../../gcc/c-family/c-common.c:4630
0x6751b6 c_parser_postfix_expression
../../gcc/c/c-parser.c:9141
0x67e012 c_parser_unary_expression
../../gcc/c/c-parser.c:8224
0x67f03f c_parser_cast_expression
../../gcc/c/c-parser.c:8066
0x67f2f9 c_parser_binary_expression
../../gcc/c/c-parser.c:7869
0x680305 c_parser_conditional_expression
../../gcc/c/c-parser.c:7592
0x680861 c_parser_expr_no_commas
../../gcc/c/c-parser.c:7507
0x67d1f6 c_parser_direct_declarator_inner
../../gcc/c/c-parser.c:4095
0x694483 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2148
0x695709 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2498
0x693bb9 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5700
0x693ff3 c_parser_compound_statement
../../gcc/c/c-parser.c:5597
0x6958a8 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2539
0x69c717 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x69d239 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x69d239 c_parse_file()
../../gcc/c/c-parser.c:21984
0x6ed0a2 c_common_parse_file()
../../gcc/c-family/c-opts.c:1218
[Bug target/99321] [11 Regression] ICE: in extract_constrain_insn, at recog.c:2670: insn does not satisfy its constraints: {*uminv16qi3} since r11-7121-g37876976b0511ec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug target/99321] [11 Regression] ICE: in extract_constrain_insn, at recog.c:2670: insn does not satisfy its constraints: {*uminv16qi3} since r11-7121-g37876976b0511ec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |11.0
Last reconfirmed||2021-03-01
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Summary|[11 Regression] ICE: in |[11 Regression] ICE: in
|extract_constrain_insn, at |extract_constrain_insn, at
|recog.c:2670: insn does not |recog.c:2670: insn does not
|satisfy its constraints:|satisfy its constraints:
|{*uminv16qi3} |{*uminv16qi3} since
||r11-7121-g37876976b0511ec9
CC||jakub at gcc dot gnu.org,
||marxin at gcc dot gnu.org
--- Comment #1 from Martin Liška ---
Confirmed, started with r11-7121-g37876976b0511ec9.
[Bug c/99323] New: [9/10/11 Regression] ICE in add_hint, at diagnostic-show-locus.c:2234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99323
Bug ID: 99323
Summary: [9/10/11 Regression] ICE in add_hint, at
diagnostic-show-locus.c:2234
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
With testfile gcc.c-torture/compile/limits-externdecl.c
and options -Wall -no-integrated-cpp, started with r8 :
$ gcc-11-20210228 -c limits-externdecl.c -no-integrated-cpp
$
$ gcc-11-20210228 -c limits-externdecl.c -Wall -no-integrated-cpp
limits-externdecl.c:55:26: warning: missing braces around initializer
[-Wmissing-braces]
55 | REFERENCE references[] = {
| ^
56 | LIM5 (X)
limits-externdecl.c:58:1: internal compiler error: in add_hint, at
diagnostic-show-locus.c:2234
58 | };
| ^
0x15769cf add_hint
../../gcc/diagnostic-show-locus.c:2233
0x15769cf print_trailing_fixits
../../gcc/diagnostic-show-locus.c:2316
0x15769cf print_line
../../gcc/diagnostic-show-locus.c:2555
0x15769cf diagnostic_show_locus(diagnostic_context*, rich_location*,
diagnostic_t)
../../gcc/diagnostic-show-locus.c:2637
0x6e9ef5 c_diagnostic_finalizer
../../gcc/c-family/c-opts.c:175
0x157029b diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:1251
0x157091e diagnostic_impl
../../gcc/diagnostic.c:1406
0x1572272 warning_at(rich_location*, int, char const*, ...)
../../gcc/diagnostic.c:1558
0x662913 pop_init_level(unsigned int, int, obstack*, unsigned int)
../../gcc/c/c-typeck.c:8839
0x684a0a c_parser_braced_init
../../gcc/c/c-parser.c:5280
0x686d1e c_parser_initializer
../../gcc/c/c-parser.c:5201
0x694e3a c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2276
0x69c717 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x69d239 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x69d239 c_parse_file()
../../gcc/c/c-parser.c:21984
0x6ed0a2 c_common_parse_file()
../../gcc/c-family/c-opts.c:1218
[Bug c/99322] New: [11 Regression] ICE in change_scope, at final.c:1480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99322
Bug ID: 99322
Summary: [11 Regression] ICE in change_scope, at final.c:1480
Product: gcc
Version: 11.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 20201018 and 20201108 :
$ cat z1.c
void g ();
void f ()
{
#pragma omp parallel
for (;;)
for (int i = 0; i < 8; ++i)
g ();
{ L1: }
&
}
$ gcc-11-20210228 -c z1.c -fopenmp -O2 -g
$ gcc-11-20210228 -c z1.c -fopenmp -O3
$
$ gcc-11-20210228 -c z1.c -fopenmp -O3 -g
during RTL pass: final
z1.c: In function 'f._omp_fn.0':
z1.c:4:11: internal compiler error: Segmentation fault
4 | #pragma omp parallel
| ^~~
0xb5eeff crash_signal
../../gcc/toplev.c:327
0x87295d change_scope
../../gcc/final.c:1480
0x8792c1 reemit_insn_block_notes
../../gcc/final.c:1581
0x8792c1 final_start_function_1
../../gcc/final.c:1785
0x879549 rest_of_handle_final
../../gcc/final.c:4675
0x879549 execute
../../gcc/final.c:4754
---
z1.c: In function 'f._omp_fn.0':
z1.c:10:1: error: location references block not in block tree
10 | }
| ^
L1:
during IPA pass: *free_lang_data
z1.c:10:1: internal compiler error: verify_gimple failed
0xd94884 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5477
0xc45d3e execute_function_todo
../../gcc/passes.c:2042
0xc46b7d do_per_function
../../gcc/passes.c:1694
0xc46be2 execute_todo
../../gcc/passes.c:2096
[Bug c++/98432] [coroutine] leaked frame created using await_transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432 --- Comment #4 from Iain Sandoe --- (In reply to Tomáš Hering from comment #3) > Created attachment 50276 [details] > unprocessed source thanks! but ... (on x86_64-linux-gnu and x86_64-darwin16): $ gcc-10-2/bin/g++ -std=c++20 -fcoroutines pr98432.C -o t -O3 -Wall -Wextra $ ./t allocated frames 1 allocated frames 2 allocated frames 3 allocated frames: 2 allocated frames: 1 hello coro-world allocated frames: 0 === same on 10.x and master. [ I will try on some older platforms, and on a 32b host too, later ]. So I'm still a bit stuck - given that coroutines is pretty much a Front End code base, it seems odd that there would be some platform dependence here (I guess there could be a an allocation/deallocation bug). Maybe we could try to find some difference in the initial gimple [-fdump-tree-gimple].
[Bug middle-end/99299] Need a recoverable version of __builtin_trap()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299 --- Comment #7 from Segher Boessenkool --- (In reply to Franz Sirl from comment #5) > For the naming I suggest __builtin_debugtrap() to align with clang. Maybe > with an aliased __debugbreak() on Windows platforms. Those are terrible names. This would *not* be used more often than __builtin_trap, for debugging. In general, builtins should say what they *do*, nott what you imagine they will be used for.
[Bug middle-end/99299] Need a recoverable version of __builtin_trap()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299 --- Comment #6 from Segher Boessenkool --- (In reply to Richard Biener from comment #4) > I'm not sure what your proposed not noreturn trap() would do in terms of > IL semantics compared to a not specially annotated general call? Nothing I think? But __builtin_trap *is* very different: it ends BBs. > "recoverable" likely means resuming after the trap, not on an exception > path (so it'll not be a throw())? "recoverable" is super unclear. For example, on Power the hardware has a concept "recoverable interrupt", which set MSR[RI]=1, and traps never do. This is a very different concept as what is wanted here, which has nothing to do with recoverability, and is simply about not being an abort() (which __builtin_trap *is*!) > The only thing that might be useful to the middle-end would be marking > the function as not altering the memory state. But I suppose it should > still serve as a barrier for code motion of both loads and stores, even > of those loads/stores are known to not trap. The only magic we'd have > for this would be __attribute__((const,returns_twice)). Which likely > will be more detrimental to general optimization. > > So - what's the "sub-optimal code generation" you refer to from the > (presumably) volatile asm() you use for the trap? > > [yeah, asm() on GIMPLE is less optimized than a call] The rs6000 backend can optimise the used instructions: we have trap_if instructions, both with registers and with immediates. A single instruction can do a comparison and a conditional trap. This works great with __builtin_trap, *if* the kernel's trap handler has abort() semantics. __builtin_trap_no_abort() maybe?
[Bug libstdc++/99306] cross compiler bootstrap failure on msdosdjgpp: error: alignment of 'm' is greater than maximum object file alignment 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99306 --- Comment #3 from Jonathan Wakely --- It's intended to be the cacheline size, so would use std::hardware_destructive_interference_size, but that's not implemented yet for the reasons given in PR 88466. And also because it's just a very verbose way to say 64 :-P
[Bug c++/98432] [coroutine] leaked frame created using await_transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432 Tomáš Hering changed: What|Removed |Added Attachment #49839|0 |1 is obsolete|| --- Comment #3 from Tomáš Hering --- Created attachment 50276 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50276=edit unprocessed source
[Bug rtl-optimization/99320] constexpr defined arrays within constexpr functions would benefit from lookup-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320 --- Comment #3 from Jakub Jelinek --- constexpr doesn't imply anything like that. constexpr variables can still be odr-used, their address taken, compared etc.
[Bug rtl-optimization/99320] constexpr defined arrays within constexpr functions would benefit from lookup-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320 --- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de --- You are right, it seems to be the same issue except that my function is constexpr, and I can't use `static constexpr ...` within the function, but Barry mentioned that use case already. You mentioned something that gcc needs to prove that this is safe, but I think my use case is "safe" since it is constexpr :)
[Bug target/99321] New: [11 Regression] ICE: in extract_constrain_insn, at recog.c:2670: insn does not satisfy its constraints: {*uminv16qi3}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
Bug ID: 99321
Summary: [11 Regression] ICE: in extract_constrain_insn, at
recog.c:2670: insn does not satisfy its constraints:
{*uminv16qi3}
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 50275
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50275=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -mtune=btver2 -fno-tree-dce -mavx512vl testcase.c
testcase.c: In function 'foo0':
testcase.c:68:1: error: insn does not satisfy its constraints:
68 | }
| ^
(insn 2646 2645 2188 2 (set (reg/v:V16QI 27 xmm7 [orig:428 v128u8_0 ] [428])
(umin:V16QI (reg/v:V16QI 27 xmm7 [orig:428 v128u8_0 ] [428])
(reg/v:V16QI 53 xmm17 [orig:428 v128u8_0 ] [428])))
"testcase.c":28:50 3810 {*uminv16qi3}
(nil))
during RTL pass: cprop_hardreg
testcase.c:68:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0x703506 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0x703593 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:118
0x6f1f3f extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2670
0xfae7cc copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.c:831
0xfaf9fe execute
/repo/gcc-trunk/gcc/regcprop.c:1396
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.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-7439-20210301075850-g074226d5aa8-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-7439-20210301075850-g074226d5aa8-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.1 20210301 (experimental) (GCC)
[Bug rtl-optimization/99320] constexpr defined arrays within constexpr functions would benefit from lookup-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Looks like a dup of PR99091 to me.
[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-03-01 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 50274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50274=edit gcc11-pr99319.patch Ugh, this is a mess. Seems r0-120109-g99ea153e45c86a1b0318e3f5e983624c3336445e that introduced the DWARF 4 -gsplit-dwarf extension came after I've introduced .debug_macro also as DWARF 4 extension, but not too long after it so it hasn't thought out interactions very well. So, I'm afraid for version 4 .debug_macro.dwo consumers should expect 2 leb128 arguments instead of one + offse. And for DWARF 5 we have the standardized DW_MACRO_*_strx which make those explicit, so this patch changes GCC to emit that.
[Bug rtl-optimization/99320] New: constexpr defined arrays within constexpr functions would benefit from lookup-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320
Bug ID: 99320
Summary: constexpr defined arrays within constexpr functions
would benefit from lookup-tables
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hi gcc-team,
first of all, sorry if this is the wrong component, but I guess that this is a
"missed-optimization" issue rather than a regular C++ issue, so I wasn't sure
which component fit the most.
I have the following code (which can be further reduced, but I kept it as
original as possible to reflect my use case):
```c++
#include
struct foo
{
static constexpr char bar(unsigned idx)
{
constexpr std::array lookup_table
{
[] () constexpr
{
std::array ret{};
// reverse mapping for characters and their lowercase
for (unsigned rnk = 0u; rnk < 15; ++rnk)
{
ret[rnk + 'A'] = rnk;
}
// set U equal to T
ret['U'] = ret['T']; ret['u'] = ret['t'];
// iupac characters get special treatment, because there is no N
ret['R'] = ret['A']; ret['r'] = ret['A']; // A or G
ret['Y'] = ret['C']; ret['y'] = ret['C']; // C or T
ret['S'] = ret['C']; ret['s'] = ret['C']; // C or G
ret['W'] = ret['A']; ret['w'] = ret['A']; // A or T
ret['K'] = ret['G']; ret['k'] = ret['G']; // G or T
ret['M'] = ret['A']; ret['m'] = ret['A']; // A or T
ret['B'] = ret['C']; ret['b'] = ret['C']; // C or G or T
ret['D'] = ret['A']; ret['d'] = ret['A']; // A or G or T
ret['H'] = ret['A']; ret['h'] = ret['A']; // A or C or T
ret['V'] = ret['A']; ret['v'] = ret['A']; // A or C or G
return ret;
}()
};
return lookup_table[idx];
}
};
int main(int argc, char const ** argv)
{
return foo::bar(argc);
}
```
I wanted to switch from defining that lookup-table within the class (e.g.
`static constexpr ... lookup_table = ...`) to define the lookup-table within
the function directly, and I noticed that I had some performance regression in
my benchmarks. Some micro benchmarks went from ~80ns to ~3000ns, but I also saw
an impact on more "realistic" macro benchmarks.
After looking at the assembly https://godbolt.org/z/n9bo7W, I noticed that the
table is "constructed" on each function call rather than a single
lookup-instruction.
So I compared it to what clang does, and it seems that they are actually
generating a static lookup table.
I know that this use case is quite niche, but it would be cool to have it
nevertheless :)
Thank you!
[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 --- Comment #2 from Tom de Vries --- (In reply to Tom de Vries from comment #0) > The second operand is now also a .uleb128. AFAIU, this goes against the > spec. Also, gdb doesn't get it: ... $ gdb -q -batch -readnow a.out DW_FORM_strp pointing outside of .debug_str section [in module /home/vries/hello/a.out] ... Debugging shows that the error is due to a large str_offset: ... (gdb) p /x str_offset $14 = 0x8c0502cd ... which matches this: ... .byte 0x5 # Define macro strp .uleb128 0x8b # At line number 139 .uleb128 0x14d # The macro: "stdin stdin" .byte 0x5 # Define macro strp .uleb128 0x8c # At line number 140 .uleb128 0x24 # The macro: "stdout stdout" ... Note that the uleb128 representation of 0x14d is "cd02".
[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 --- Comment #1 from Tom de Vries --- Related readelf PR: https://sourceware.org/bugzilla/show_bug.cgi?id=27387
[Bug debug/99319] New: DW_MACRO_define_strp uses uleb128 for second operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 Bug ID: 99319 Summary: DW_MACRO_define_strp uses uleb128 for second operand Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Consider compiling hello world, with macro info: ... $ gcc-11 -ggdb3 -g hello.c -dA -save-temps ... In a-hello.s, we have: ... .section.debug_macro,"",@progbits .Ldebug_macro0: .value 0x5 # DWARF macro version number .byte 0x2 # Flags: 32-bit, lineptr present .long .Ldebug_line0 .byte 0x3 # Start new file .uleb128 0 # Included from line number 0 .uleb128 0x1# file hello.c .byte 0x5 # Define macro strp .uleb128 0 # At line number 0 .long .LASF2 # The macro: "__STDC__ 1" ... So, the DW_MACRO_define_strp entry (starting with .byte 0x5) has two operands, a uleb128 and a .long. AFAIU, this is in accordance with the spec: ... A DW_MACRO_define_strp or DW_MACRO_undef_strp entry has two operands. The first operand encodes the source line number of the #define or #undef macro directive. The second operand consists of an offset into a string table contained in the .debug_str section of the object file. The size of the operand is given in the header offset_size_flag field. ... Now add -gsplit-dwarf: ... $ gcc-11 -ggdb3 -g hello.c -dA -save-temps -gsplit-dwarf ... Now we have instead: ... .section.debug_macro.dwo,"e",@progbits .Ldebug_macro0: .value 0x5 # DWARF macro version number .byte 0x2 # Flags: 32-bit, lineptr present .long .Lskeleton_debug_line0 .byte 0x3 # Start new file .uleb128 0 # Included from line number 0 .uleb128 0x1# file hello.c .byte 0x5 # Define macro strp .uleb128 0 # At line number 0 .uleb128 0x191 # The macro: "__STDC__ 1" ... The second operand is now also a .uleb128. AFAIU, this goes against the spec.
[Bug c++/99318] New: [10/11 Regression] -Wdeprecated-declarations where non-should be?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99318
Bug ID: 99318
Summary: [10/11 Regression] -Wdeprecated-declarations where
non-should be?
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hello gcc-team,
since gcc 10 the following code throws a deprecation warning, even though it
doesn't use any deprecated code.
```c++
template
class alphabet_base
{
[[deprecated("message")]] unsigned char_to_rank_table(char const chr)
{
using index_t = unsigned;
return derived_type::char_to_rank[static_cast(chr)];
}
};
```
gives the following warning:
```
: In member function 'unsigned int
alphabet_base::char_to_rank_table(char)':
:7:55: warning: 'unsigned int
alphabet_base::char_to_rank_table(char)' is deprecated: message
[-Wdeprecated-declarations]
7 | return derived_type::char_to_rank[static_cast(chr)];
| ^~~
:4:40: note: declared here
4 | [[deprecated("message")]] unsigned char_to_rank_table(char const
chr)
|^~
Compiler returned: 0
```
See https://godbolt.org/z/4cWzMr
Thank you!
[Bug middle-end/95757] [11 regression] missing warning in gcc.dg/Wstringop-overflow-25.c since r11-1517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
We get only 3 warnings on the last function with
-O2 -Wall -Wno-array-bounds --param=logical-op-non-short-circuit=0
-ftrack-macro-expansion=0
while we get 4 with
-O2 -Wall -Wno-array-bounds --param=logical-op-non-short-circuit=1
-ftrack-macro-expansion=0
I think the important differences are that while we have in *.optimized pretty
much the same IL - I only see differences between SSA_NAME versions, in the
--param=logical-op-non-short-circuit=1 case we have more accurate
SSA_NAME_RANGE_INFO on 3 SSA_NAMEs
[local count: 1073741824]:
- _51 ={v} unsigned_value_source;
- if (_51 > 1)
+ _57 ={v} unsigned_value_source;
+ if (_57 > 1)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
# RANGE [1, 2] NONZERO 3
- _55 = _51 + 1;
+ _55 = _57 + 1;
[local count: 1073741824]:
# RANGE [1, 2] NONZERO 3
- # prephitmp_54 = PHI <_55(3), 1(2)>
- _49 ={v} unsigned_value_source;
- _48 = _49 + 18446744073709551615;
- if (_48 > 1)
+ # prephitmp_50 = PHI <1(2), _55(3)>
+ _52 ={v} unsigned_value_source;
+ _59 = _52 + 18446744073709551615;
+ if (_59 > 1)
goto ; [50.00%]
else
goto ; [50.00%]
- [local count: 268435457]:
- _53 = _49 + 1;
+ [local count: 536870913]:
+ # RANGE [2, 3] NONZERO 3
+ _53 = _52 + 1;
[local count: 1073741824]:
- # prephitmp_57 = PHI <2(4), _53(5)>
+ # RANGE [2, 3] NONZERO 3
+ # prephitmp_54 = PHI <2(4), _53(5)>
_47 ={v} unsigned_value_source;
- _52 = _47 + 18446744073709551614;
- if (_52 > 1)
+ _61 = _47 + 18446744073709551614;
+ if (_61 > 1)
goto ; [50.00%]
else
goto ; [50.00%]
- [local count: 268435457]:
- _59 = _47 + 1;
+ [local count: 536870913]:
+ # RANGE [3, 4] NONZERO 7
+ _48 = _47 + 1;
[local count: 1073741824]:
...
I mean the _53, prephitmp_54 and _48 ranges above in the + lines (i.e. =1).
Early during optimizations we have the usual short-circuit vs.
non-short-circuit differences like:
- # iftmp.0_52 = PHI <_51(3), 0(2)>
- _49 ={v} unsigned_value_source;
- if (_49 == 0)
-goto ; [50.00%]
+ # iftmp.0_58 = PHI <0(2), _57(3)>
+ _52 ={v} unsigned_value_source;
+ _53 = _52 == 0;
+ _54 = _52 > 2;
+ _55 = _53 | _54;
+ if (_55 != 0)
+goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
- if (_49 > 2)
-goto ; [50.00%]
- else
-goto ; [50.00%]
-
- [local count: 268435456]:
- [local count: 1073741824]:
- # iftmp.0_50 = PHI <1(4), 1(5), _49(6)>
+ [local count: 1073741824]:
+ # iftmp.0_56 = PHI <1(4), _52(5)>
but they gradually disappear.
Right before *.dom3 the IL is already pretty much the same when ignoring
SSA_NAME version differences,
except:
- # prephitmp_54 = PHI <_55(3), 1(2)>
- _49 ={v} unsigned_value_source;
- _48 = _49 + 18446744073709551615;
- _1 = _48 > 1;
- if (_1 != 0)
+ # prephitmp_50 = PHI <1(2), _55(3)>
+ _52 ={v} unsigned_value_source;
+ _59 = _52 + 18446744073709551615;
+ if (_59 > 1)
and
_47 ={v} unsigned_value_source;
- _52 = _47 + 18446744073709551614;
- _50 = _52 > 1;
- if (_50 != 0)
+ _61 = _47 + 18446744073709551614;
+ if (_61 > 1)
i.e. the - version (=0) doesn't have the comparisons folded into GIMPLE_CONDs
while the + version (=1) does.
And I believe that is the trigger on why during dom3 adds the more precise
ranges in the --param=logical-op-non-short-circuit=1 case and not in the
--param=logical-op-non-short-circuit=0 case.
[Bug target/99314] [Patch] [RISC-V] g++.dg/opt/memcpy1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314 --- Comment #1 from Kito Cheng --- I didn't see this testcase failed before, and I can't reproduce that on my work environment, do you mind share your build environment, e.g. the version of gcc or the distribution version?
[Bug target/99313] ICE while changing global target options via pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Martin Liška --- Fixed on master.
[Bug target/99313] ICE while changing global target options via pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:4ed0a92f6cfc647e2ad8ceaa1e5709545c915465 commit r11-7442-g4ed0a92f6cfc647e2ad8ceaa1e5709545c915465 Author: Martin Liska Date: Mon Mar 1 15:41:14 2021 +0100 s390: add exceptions for param modified by target pragma gcc/ChangeLog: PR target/99313 * optc-save-gen.awk: Add 4 more exceptions. gcc/testsuite/ChangeLog: PR target/99313 * gcc.target/s390/target-attribute/pr99313.c: New test.
[Bug ada/99020] ICE in record containing discriminated accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-01 CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- I can reproduce.
[Bug c/99317] New: Missed warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99317
Bug ID: 99317
Summary: Missed warning
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pj at hugeone dot co.uk
Target Milestone: ---
The code:
int *foo(void *v, void *w, int x) {
float * f = v;
int * i = w;
return (x ? f : i);
}
int *foo1(void *v, void *w, int x) {
float * f = v;
int * i = w;
return (1 ? f : (void *)i);
}
int *bar(void *v, void *w, int x) {
float * f = v;
int * i = w;
return (x ? f : (void *)i);
}
Function foo correctly emits the warning:
source>: In function 'foo':
:7:19: warning: pointer type mismatch in conditional expression
7 | return (x ? f : i);
| ^
Casting removes that warming even in the trivial foo1 example.
https://godbolt.org/z/ozsPPY
[Bug preprocessor/99313] ICE while changing global target options via pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313 --- Comment #4 from Martin Liška --- (In reply to Richard Biener from comment #3) > But this results in unexpected behavior when there's functions with arch=z13 > vs. arch=z9 and depending on "luck" we then inherit the wrong params where > we should not? Yes. > > That said, when unifying target/optimize options these should be handled > and stored once, right? Exactly, that's the original motivation for merging of them.
[Bug preprocessor/99313] ICE while changing global target options via pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313 --- Comment #3 from Richard Biener --- But this results in unexpected behavior when there's functions with arch=z13 vs. arch=z9 and depending on "luck" we then inherit the wrong params where we should not? That said, when unifying target/optimize options these should be handled and stored once, right?
[Bug c++/99294] [modules] tdef-inst-1 fails with -fno-module-lazy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99294 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- 2e0bb9eec2d 2021-03-01 | c++: Completeness of typedef structs [PR 99294]
[Bug c++/99294] [modules] tdef-inst-1 fails with -fno-module-lazy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99294 --- Comment #1 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:2e0bb9eec2d455840bc4773391b3313a320b3c23 commit r11-7441-g2e0bb9eec2d455840bc4773391b3313a320b3c23 Author: Nathan Sidwell Date: Mon Mar 1 05:41:10 2021 -0800 c++: Completeness of typedef structs [PR 99294] When we read in a class definition, we use fixup_type_variants to propagate the now-completed fields of the class's TYPE to other variants. Unfortunately that doesn't propagate all of them, and in this case we had a typedef to an (incomplete) instantiation. That typedef ended up with a VOIDmode, which blew up gimple expansion as the type itself isn't VOID. Without modules, that information is propagated in finalize_type_size when laying out the class. But that doesn't happen with stream-in -- we already know the layout. There is already some overlap between the two functions, now there's a bit more. In fixup_type_variants, I pay attention to the TYPE_NAME to decide whether to override a user's TYPE_ALIGN -- variants of the main-variant typedef just copy the main-variant. Other variants recalculate. Overaligning is still permitted. I also added a TYPE_ALIGN_RAW accessor, and fixed a bug in the alignment streaming I noticed. I did not refactor TYPE_ALIGN beyond using the new accessor. (It could be written as ((1 << align_raw) >> 1), rather than use the conditional.) PR c++/99294 gcc/ * tree.h (TYPE_ALIGN_RAW): New accessor. (TYPE_ALIGN): Use it. gcc/cp/ * class.c (fixup_type_variants): Propagate mode, precision, alignment & emptiness. * module.cc (trees_out::type_node): Use TYPE_ALIGN_RAW. (trees_in::tree_node): Rematerialize alignment here. gcc/testsuite/ * g++.dg/modules/pr99294.h: New. * g++.dg/modules/pr99294_a.C: New. * g++.dg/modules/pr99294_b.C: New.
[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338 Jan Hubicka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #25 from Jan Hubicka --- Fixed. Sorry for the delay - next time I should not commit into a private branch :(
[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338 --- Comment #24 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:150bde36c119eff4b8a74667c9d728d6a8a5e8a1 commit r11-7440-g150bde36c119eff4b8a74667c9d728d6a8a5e8a1 Author: Jan Hubicka Date: Mon Mar 1 14:36:11 2021 +0100 Fix ICE in compute_fn_summary PR ipa/98338 * ipa-fnsummary.c (compute_fn_summary): Fix sanity check.
[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- We certainly don't claim it is the exact same thing as using the noreturn attribute, it is not. We could in profile.c ignore edges that lead to basic blocks that start with __builtin_unreachable () call as the first non-debug stmt after labels if it was really important, but I'm not convinced it is.
[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151 --- Comment #8 from Sebastian Huber --- (In reply to Eric Botcazou from comment #7) > > I still think that the profiling counter increment in the > > __builtin_unreachable() path is a bug. > > How so? I only see a missed optimization, but with -fprofile-arcs > -ftest-coverage you're splitting hairs IMO. The __builtin_unreachable() explicitly mentions the use case with a function which doesn't return in the documentation: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html I would expect from the compiler that it generates then similar code. Having a profiling counter increment in one case and not in the other is not really a nice behaviour.
[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151 --- Comment #7 from Eric Botcazou --- > This nop behaviour could be a bit inconsistent across architectures. For > example, arm and powerpc don't generate a nop here. Well, it's low-level trickery so architecture-dependent by definition. > I still think that the profiling counter increment in the > __builtin_unreachable() path is a bug. How so? I only see a missed optimization, but with -fprofile-arcs -ftest-coverage you're splitting hairs IMO.
[Bug debug/99230] [11 Regression] gcc.dg/pr83527.c excess errors: '-fcompare-debug' failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99230
--- Comment #4 from Jakub Jelinek ---
I can actually reproduce e.g. on x86_64-linux with:
extern void fn2(void);
extern void fn3(int);
int a, b;
void fn1() {
int c;
short d;
switch (a) {
case 22000:
fn2();
case 22300:
b = 0;
case 22600:
case 22601:
case 22900:
fn3(1);
case 20100:
fn3(2);
case 20200:
fn3(3);
case 20300:
fn3(4);
case 20400:
fn3(5);
case 20310:
fn3(4);
case 20410:
fn3(5);
}
if (d || c) {
do
;
while (0);
}
}
and -O2 --param logical-op-non-short-circuit=0 -fcompare-debug
--param=jump-table-max-growth-ratio-for-speed=5000
And the difference is the same:
--- pr99230-4.c.gkd 2021-03-01 13:44:32.625879468 +0100
+++ pr99230-4.gk.c.gkd 2021-03-01 13:44:32.731878292 +0100
@@ -9,7 +9,7 @@ Declarations used by fn1, sorted by DECL
5: void ;
4: void ;
6: void ;
-1: void ;
+1: void ;
;; Function fn1 (fn1, funcdef_no=0, cgraph_uid=1, symbol_order=2)
[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #6 from Sebastian Huber ---
(In reply to Eric Botcazou from comment #5)
> static void
> sparc_asm_function_epilogue (FILE *file)
> {
> /* If the last two instructions of a function are "call foo; dslot;"
> the return address might point to the first instruction in the next
> function and we have to output a dummy nop for the sake of sane
> backtraces in such cases. This is pointless for sibling calls since
> the return address is explicitly adjusted. */
This nop behaviour could be a bit inconsistent across architectures. For
example, arm and powerpc don't generate a nop here.
I still think that the profiling counter increment in the
__builtin_unreachable() path is a bug.
[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338 --- Comment #23 from Jakub Jelinek --- The make check results also looked ok on all 3 arches.
[Bug c/99291] maybe_warn_pass_by_reference uses outdated format string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99291 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #5 from Martin Liška --- The '%<%s%>' is currently supported, but not triggered for some reason. Martin?
[Bug debug/99230] [11 Regression] gcc.dg/pr83527.c excess errors: '-fcompare-debug' failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99230
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-03-01
Ever confirmed|0 |1
--- Comment #3 from Jakub Jelinek ---
This can be seen also on
int a, b;
void fn1(int c, short d) {
if (d || c) {
do
;
while (0);
}
}
with -O2 --param logical-op-non-short-circuit=0 -fcompare-debug - differences
in *.gimple dump:
--- pr99230-2.c.006t.gimple 2021-03-01 12:46:25.715634310 +0100
+++ pr99230-2.gk.c.006t.gimple 2021-03-01 12:46:25.740634033 +0100
@@ -1,11 +1,13 @@
void fn1 (int c, short int d)
{
- if (d != 0) goto ; else goto ;
- :
- if (c != 0) goto ; else goto ;
+ # DEBUG BEGIN_STMT
+ if (d != 0) goto ; else goto ;
:
- :
+ if (c != 0) goto ; else goto ;
:
+ # DEBUG BEGIN_STMT
+ # DEBUG BEGIN_STMT
+ :
}
I'm afraid it is the same issue as PR93786.
The difference is that when shortcut_cond_expr is run, in one case
then_se is false, because then_ is
>
constant
arg:0 constant 0>
pr99230-2.c:11:7 start: pr99230-2.c:11:7 finish: pr99230-2.c:11:7>
but in another case is
>
side-effects head 0x7fffea189168 tail 0x7fffea1891c8 stmts 0x7fffea189150
0x7fffea186240
stmt
pr99230-2.c:10:5 start: pr99230-2.c:10:5 finish: pr99230-2.c:10:6>
stmt
head 0x7fffea189240 tail 0x7fffea189240 stmts 0x7fffea189228
stmt
pr99230-2.c:11:7 start: pr99230-2.c:11:7 finish:
pr99230-2.c:11:7>>>
and only the latter has TREE_SIDE_EFFECTS set.
In PR93786 I've tried several possibilities and had to gave up.
Alex, any thoughts?
Unless we want to remove the statement frontiers support, I'm not sure what
else we can do, we'd need some new trees to hold just the debug statements that
would preserve what exactly would be the behavior without -g.
Not sure if this needs to be P1 though, the statement frontiers issues are old,
and cris is not a primary or secondary target, so if we have a testcase that in
the end only fails there...
[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #23 from Vadim Zeitlin --- (In reply to Eric Botcazou from comment #22) > Thanks for reporting the problem. Thanks a lot for fixing it so quickly! And I've also appreciated the explanation in the commit message, it's nice to understand what the problem really was, even if it's fixed now.
[Bug fortran/99308] [OOP] passing array of object as class(TYPE) to procedure leads to incorrect length of array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99308
Tobias Burnus changed:
What|Removed |Added
Keywords||missed-optimization
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus ---
I think there are two errors:
(a) The value can be simplified at compile time as the size (8 or 2) is known
at compile time, but isn't.
I wonder whether this only a problem for 'size' or also for 'ubound','lbound'
or when doing
var(:)%idx = 0 – for the bounds of the generated do loop.
(b) The run-time version is wrong.
In my dump, (and output '2 2') I see for either variable
parm.10.span = spcs->_vptr->_size;
parm.10.dtype = {.elem_len=4, .rank=1, .type=5};
D.3995 = stride.5;
parm.10.dim[0].lbound = 1;
parm.10.dim[0].ubound = 2;
parm.10.dim[0].stride = NON_LVALUE_EXPR ;
parm.10.data = 0B;
parm.10.offset = -NON_LVALUE_EXPR ;
D.3996 =
D.3997 = (integer(kind=4)) MAX_EXPR <(D.3996->dim[0].ubound -
D.3996->dim[0].lbound) + 1, 0>;
Obviously, 'ubound = 2' is only valid for 'fuel' and not for 'spcs'.
[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #5 from Eric Botcazou ---
static void
sparc_asm_function_epilogue (FILE *file)
{
/* If the last two instructions of a function are "call foo; dslot;"
the return address might point to the first instruction in the next
function and we have to output a dummy nop for the sake of sane
backtraces in such cases. This is pointless for sibling calls since
the return address is explicitly adjusted. */
[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- (In reply to Dominique d'Humieres from comment #1) > Reduced test While -fsanitize=address,undefined does not find anything on x86_64-gnu-linux, I do see with valgrind: ==98347== Invalid write of size 8 ==98347==at 0x40397E: test_t1_ (ijd.f90:43) ==98347==by 0x403A4E: MAIN__ (ijd.f90:60) ==98347==by 0x403A85: main (ijd.f90:61) ==98347== Address 0x4f55c98 is 8 bytes inside a block of size 12 alloc'd ==98347==at 0x483DFAF: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==98347==by 0x402A6D: test_t1_ (ijd.f90:40) ==98347==by 0x403A4E: MAIN__ (ijd.f90:60) ==98347==by 0x403A85: main (ijd.f90:61) That's: x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)] y = x x = realloc_t1 (y) ! <<< line 40, 8 bytes alloc'd inside block of size 12 x = realloc_t1 (x) x = x(3:1:-1) + y x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)] ! <<< line 43, invalid write of size 8 Looking at the Fortran code, x and y have the dynamic type T2 until 'realloc_t1', which turns this into the dynamic type T1. In the last line (line 43), the dynamic type changes again to T2. In terms of memory usage: 3*8bytes before the first realloc_t1 call, then 3*4bytes and for the last line again 3*8bytes. * * * It seems as if the reallocation does not work properly if the dynamic type changes – at least not if the required size increased in the assignment. (The valgrind message implies that shrinking did work in line 40.)
[Bug target/96357] [10/11 Regression] could not split insn UNSPEC_COND_FSUB with AArch64 SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96357 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||andrew.goodbody at linaro dot org --- Comment #5 from ktkachov at gcc dot gnu.org --- *** Bug 99316 has been marked as a duplicate of this bug. ***
[Bug c/99316] ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99316 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from ktkachov at gcc dot gnu.org --- Dup. Fixed for GCC 10.3 *** This bug has been marked as a duplicate of bug 96357 ***
[Bug c/99316] ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99316 --- Comment #1 from andrew.goodbody at linaro dot org --- Command line used was this /usr/local/bin/gcc-U_FORTIFY_SOURCE -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections -fdata-sections '-std=c++0x'-MD -MF bazel-out/aarch64-opt/bin/tensorflow/core/kernels/_objs/histogram_op/histogram_op.pic.d '-frandom-seed=bazel-out/aarch64-opt/bin/tensorflow/core/kernels/_objs/histogram_op/histogram_op.pic.o' -fPIC -D__CLANG_SUPPORT_DYN_ANNOTATION__ -DEIGEN_MPL2_ONLY '-DEIGEN_MAX_ALIGN_BYTES=64' '-DEIGEN_HAS_TYPE_TRAITS=0' -DEIGEN_USE_BLAS -DEIGEN_USE_LAPACK -iquote . -iquote bazel-out/aarch64-opt/bin -iquote external/com_google_absl -iquote bazel-out/aarch64-opt/bin/external/com_google_absl-iquote external/eigen_archive -iquote bazel-out/aarch64-opt/bin/external/eigen_archive -iquote external/local_config_sycl -iquote bazel-out/aarch64-opt/bin/external/local_config_sycl -iquote external/nsync -iquote bazel-out/aarch64-opt/bin/external/nsync -iquote external/com_googlesource_code_re2 -iquote bazel-out/aarch64-opt/bin/external/com_googlesource_code_re2 -iquote external/gif -iquote bazel-out/aarch64-opt/bin/external/gif -iquote external/libjpeg_turbo -iquote bazel-out/aarch64-opt/bin/external/libjpeg_turbo -iquote external/com_google_protobuf -iquote bazel-out/aarch64-opt/bin/external/com_google_protobuf -iquote external/farmhash_archive -iquote bazel-out/aarch64-opt/bin/external/farmhash_archive -iquote external/fft2d -iquote bazel-out/aarch64-opt/bin/external/fft2d -iquote external/highwayhash -iquote bazel-out/aarch64-opt/bin/external/highwayhash -iquote external/zlib_archive -iquote bazel-out/aarch64-opt/bin/external/zlib_archive -isystem third_party/eigen3/mkl_include -isystem bazel-out/aarch64-opt/bin/third_party/eigen3/mkl_include -isystem external/eigen_archive-isystem bazel-out/aarch64-opt/bin/external/eigen_archive -isystem external/nsync/public -isystem bazel-out/aarch64-opt/bin/external/nsync/public -isystem external/gif -isystem bazel-out/aarch64-opt/bin/external/gif -isystem external/com_google_protobuf/src -isystem bazel-out/aarch64-opt/bin/external/com_google_protobuf/src -isystem external/farmhash_archive/src -isystem bazel-out/aarch64-opt/bin/external/farmhash_archive/src -isystem external/zlib_archive -isystem bazel-out/aarch64-opt/bin/external/zlib_archive '-march=armv8.2-a+sve' -O3 '-std=c++14' '-march=armv8.2-a+sve' -O3 '-D_GLIBCXX_USE_CXX11_ABI=0' -DEIGEN_AVOID_STL_ARRAY -Iexternal/gemmlowp -Wno-sign-compare '-ftemplate-depth=900' -fno-exceptions '-DINTEL_MKL=1' -DEIGEN_USE_VML -DINTEL_MKL_DNN_ONLY -DENABLE_MKL -pthread '-DINTEL_MKL=1' -DINTEL_MKL_DNN_ONLY -DENABLE_MKL -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c tensorflow/core/kernels/histogram_op.cc -o bazel-out/aarch64-opt/bin/tensorflow/core/kernels/_objs/histogram_op/histogram_op.pic.o
[Bug c/99316] New: ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99316
Bug ID: 99316
Summary: ICE: in final_scan_insn_1, at final.c:3073 (error:
could not split insn)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew.goodbody at linaro dot org
Target Milestone: ---
Created attachment 50273
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50273=edit
Preprocessed source
gcc 10.2.0 built from tarball
In file included from
external/eigen_archive/unsupported/Eigen/CXX11/Tensor:144,
from ./third_party/eigen3/unsupported/Eigen/CXX11/Tensor:1,
from ./tensorflow/core/framework/numeric_types.h:20,
from ./tensorflow/core/framework/allocator.h:26,
from ./tensorflow/core/framework/op_kernel.h:25,
from ./tensorflow/core/kernels/histogram_op.h:19,
from tensorflow/core/kernels/histogram_op.cc:20:
external/eigen_archive/unsupported/Eigen/CXX11/src/Tensor/TensorExecutor.h: In
static member function 'static void Eigen::internal::EvalRange::run(Evaluator*, StorageIndex, StorageIndex) [with
Evaluator = Eigen::TensorEvaluator, 16,
Eigen::MakePointer>, const Eigen::TensorConversionOp,
const
Eigen::TensorCwiseUnaryOp >, const Eigen::TensorConversionOp, const
Eigen::TensorCwiseBinaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer>, const
Eigen::TensorCwiseNullaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer> > >, const
Eigen::TensorCwiseNullaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer> > > > >, const
Eigen::TensorCwiseNullaryOp, const
Eigen::TensorCwiseUnaryOp >, const Eigen::TensorConversionOp, const
Eigen::TensorCwiseBinaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer>, const
Eigen::TensorCwiseNullaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer> > >, const
Eigen::TensorCwiseNullaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer> > > > > > > > >, Eigen::ThreadPoolDevice>;
StorageIndex = long int]':
external/eigen_archive/unsupported/Eigen/CXX11/src/Tensor/TensorExecutor.h:349:3:
error: could not split insn
349 | }
| ^
(insn 1615 2102 1433 (set (reg:VNx4SF 34 v2 [orig:554 _1597 ] [554])
(unspec:VNx4SF [
(reg:VNx4BI 72 p4 [orig:376 vec_mask_and_1413 ] [376])
(unspec:VNx4SF [
(reg:VNx4BI 78 p10 [orig:376 vec_mask_and_1413 ] [376])
(const_int 1 [0x1])
(reg:VNx4SF 49 v17 [2017])
(reg:VNx4SF 32 v0 [2049])
] UNSPEC_COND_FADD)
(reg:VNx4SF 39 v7 [orig:392 vect__ifc__887.8029 ] [392])
] UNSPEC_SEL)) 5628 {*cond_addvnx4sf_any}
(expr_list:REG_DEAD (reg:VNx4BI 78 p10 [orig:376 vec_mask_and_1413 ]
[376])
(expr_list:REG_DEAD (reg:VNx4BI 72 p4 [orig:376 vec_mask_and_1413 ]
[376])
(expr_list:REG_DEAD (reg:VNx4SF 39 v7 [orig:392 vect__ifc__887.8029
] [392])
(expr_list:REG_EQUAL (unspec:VNx4SF [
(reg:VNx4BI 78 p10 [orig:376 vec_mask_and_1413 ]
[376])
(unspec:VNx4SF [
(reg:VNx4BI 78 p10 [orig:376
vec_mask_and_1413 ] [376])
(const_int 1 [0x1])
(reg:VNx4SF 49 v17 [2017])
(const_vector:VNx4SF [
(const_double:SF -6.103515625e-5
[-0x0.8p-13])
])
] UNSPEC_COND_FADD)
(subreg:VNx4SF (reg:VNx4SI 39 v7 [orig:392
vect__ifc__887.8029 ] [392]) 0)
] UNSPEC_SEL)
(nil))
during RTL pass: final
external/eigen_archive/unsupported/Eigen/CXX11/src/Tensor/TensorExecutor.h:349:3:
internal compiler error: in final_scan_insn_1, at final.c:3073
0x69255f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/rtl-error.c:108
0x9debcf final_scan_insn_1
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:3073
0x9dede3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:3152
0x9df0a7 final_1
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:2020
0x9df823 rest_of_handle_final
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:4658
0x9df823 execute
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug preprocessor/99313] ICE while changing global target options via pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2021-03-01
--- Comment #2 from Martin Liška ---
The diff comes from here:
(gdb) p ptr1->x_param_max_completely_peel_times
$3 = 16
(gdb) p ptr2->x_param_max_completely_peel_times
$4 = 64
Which comes from here:
if (opts->x_s390_tune >= PROCESSOR_2097_Z10)
{
SET_OPTION_IF_UNSET (opts, opts_set, param_max_unrolled_insns,
100);
SET_OPTION_IF_UNSET (opts, opts_set, param_max_unroll_times, 32);
SET_OPTION_IF_UNSET (opts, opts_set, param_max_completely_peeled_insns,
2000);
SET_OPTION_IF_UNSET (opts, opts_set, param_max_completely_peel_times,
64);
}
So this is an obvious situation where a target option modified optimization
options that is global.
I'm going to add exceptions for it.
