[Bug c++/90825] New: g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90825
Bug ID: 90825
Summary: g++: internal compiler error: Segmentation fault
signal terminated program cc1plus
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hyc at symas dot com
Target Milestone: ---
$ PATH=/home/user/gcc_9_1_0_install/bin/:$PATH
LD_LIBRARY_PATH=/home/user/gcc_9_1_0_install/lib64:$LD_LIBRARY_PATH g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/user/gcc_9_1_0_install/libexec/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/user/gcc_9_1_0_install
--disable-multilib --enable-languages=c,c++,lto
Thread model: posix
gcc version 9.1.0 (GCC)
$ cat gcc91c.cc
class address
{
char host_[63];
public:
static constexpr unsigned buffer_size() noexcept { return
sizeof(host_); }
};
template
void load()
{
char host[address::buffer_size()];
}
$ PATH=/home/user/gcc_9_1_0_install/bin/:$PATH
LD_LIBRARY_PATH=/home/user/gcc_9_1_0_install/lib64:$LD_LIBRARY_PATH g++
gcc91c.cc -c
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
ii:
# 1 "gcc91c.cc"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "gcc91c.cc"
class address
{
char host_[63];
public:
static constexpr unsigned buffer_size() noexcept { return
sizeof(host_); }
};
template
void load()
{
char host[address::buffer_size()];
}
[Bug c++/90825] [9 Regression] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90825 --- Comment #7 from hyc at symas dot com --- Thanks for the quick resolution, much appreciated.
[Bug inline-asm/77607] New: Aarch64 LDP operand rejected incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77607
Bug ID: 77607
Summary: Aarch64 LDP operand rejected incorrectly
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: hyc at symas dot com
Target Milestone: ---
This sequence:
{uint8x16_t _a, _b, _c, _d;
__asm__("ldp %0, %1, %4\n\t"
"ldp %2, %3, %4, #32\n\t" : "=w"(_a), "=w"(_b), "=w"(_c), "=w"(_d) :
"Ump"(state.k) :);
Generates this code:
ldp v1, v4, [x0]
ldp v0, v2, [x0], #32
And gets this error:
/tmp/ccQYB8nY.s:172: Error: operand 1 should be a floating-point register --
`ldp v1,v4,[x0]'
/tmp/ccQYB8nY.s:173: Error: operand 1 should be a floating-point register --
`ldp v0,v2,[x0],#32'
According to the docs, "w" is the correct constraint character to use for FP or
SIMD register. So either gas is rejecting this incorrectly, or gcc is
generating the wrong register name for this constraint.
[Bug inline-asm/77607] Aarch64 LDP operand rejected incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77607
hyc at symas dot com changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #2 from hyc at symas dot com ---
(In reply to Andrew Pinski from comment #1)
> You want %qN.
> Some something like:
> {uint8x16_t _a, _b, _c, _d;
> __asm__("ldp %q0, %q1, %4\n\t"
> "ldp %q2, %q3, %4, #32\n\t" : "=w"(_a), "=w"(_b), "=w"(_c), "=w"(_d)
> : "Ump"(state.k) :);
>
> Oh by the way you really not need this. GCC should be able to use ldp in
> these cases if wanted by the target; though ldp for q registers is not yet
> implemented as most processors don't want them right now.
Thanks.
>
> Also your inline-asm is incorrect as you modify state.k.
Oh? That's not my intention at this point. Just want to load from it.
> So really it should be something like:
> {uint8x16_t _a, _b, _c, _d;
> __asm__("ldp %q0, %q1, %4\n\t"
> "ldp %q2, %q3, %4, #32\n\t" : "=w"(_a), "=w"(_b), "=w"(_c), "=w"(_d)
> , "+Ump"(state.k) :);
[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885 hyc at symas dot com changed: What|Removed |Added CC||hyc at symas dot com --- Comment #14 from hyc at symas dot com --- (In reply to Markus Trippelsdorf from comment #8) > See Initializers 8.6.12: > > When storage for an object with automatic or dynamic storage duration is > obtained, the object has an indeterminate value, and if no initialization is > performed for the object, that object retains an indeterminate value until > that value is replaced (5.17). "If no initialization is performed" - this is the constructor, whose job is to create and initialize the object, and you're preventing that initialization from happening. How is that logical?
[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885 --- Comment #15 from hyc at symas dot com --- (In reply to Markus Trippelsdorf from comment #3) > See https://gcc.gnu.org/gcc-6/porting_to.html (More aggressive optimization > of -flifetime-dse). > > You're invoking undefined behavior; -flifetime-dse=1 is a workaround. "More aggressive optimization of -flifetime-dse The C++ compiler (with enabled -flifetime-dse) is more aggressive in dead-store elimination in situations where a memory store to a location precedes a constructor to the memory location." This bug report is talking about a store that occurs *during* the constructor. This does not *precede* the constructor.
[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885 --- Comment #19 from hyc at symas dot com --- (In reply to Manuel López-Ibáñez from comment #18) > (In reply to Kern Sibbald from comment #17) > > The g++ developers could have realized that in especially in "undefined" > > territory where they knew they would break code the conservative way to do > > it without creating chaos is to add new strict warning message for a period > > of time (one to two years) prior to making their changes default. > > If someone developed the warning, it could stay forever. The problem is that > someone needs to develop the warning. People working on GCC right now > (including myself) are either not paid to do this or not personally > interested in such a warning enough to dedicate their free time. That's all well and good. But, somebody had to go out of their way to develop the code to identify this case of new as being a dead store. Why was this worth anyone's time to do so? What performance benefit does this "optimization" bring, and is it really worth all of the obviously known breakage that it causes? We all have important things to be doing. It doesn't appear that the time invested in this "feature" was time well spent.
[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885 --- Comment #24 from hyc at symas dot com --- (In reply to Manuel López-Ibáñez from comment #21) > (In reply to hyc from comment #19) > > That's all well and good. But, somebody had to go out of their way to > > develop the code to identify this case of new as being a dead store. Why was > > this worth anyone's time to do so? What performance benefit does this > > "optimization" bring, and is it really worth all of the obviously known > > breakage that it causes? > > I don't know the answers to those questions, but somebody did do the effort > to implement it and test it: > https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00782.html I see a patch, I don't see justification / motivation / profiling / benchmark results quantifying the impact of this patch. > and then add various options to control it: > https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01651.html > > so they probably have their own motivation to do this instead of something > else. Nobody raised any objections at the time. > > > We all have important things to be doing. It doesn't appear that the time > > invested in this "feature" was time well spent. > > For better or worse, we don't get to decide on what other people spent their > own time unless we pay them. No, but you get to decide whether to accept the work or not based on whether it actually solved a problem that programmers care about. Or whether the added complexity was worth any added maintenance cost or compile time. This feature is enabled at -O1, which is usually reserved for non-aggressive, benign optimizations. In what way is this feature an optimization? How does it qualify as benign? Where was *any* critical review of this thing? When I was a gcc maintainer (1988-1996) a patch like this wouldn't have proceeded without answers to these questions.
