[Bug c++/96543] null check on template pointer parameter fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96543 --- Comment #2 from Vlad Petric --- Got it, should I refile/change this bug?
[Bug c++/96543] New: null check on template pointer parameter fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96543
Bug ID: 96543
Summary: null check on template pointer parameter fails
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vlad at petric dot cc
Target Milestone: ---
static unsigned c = 0;
template
struct A {
static void test() {
if constexpr (c) ++ *c;
}
};
int main() {
A<>::test();
A::test();
}
The error is:
bug.cc: In instantiation of ‘static void A::test() [with unsigned int* c =
(& c)]’:
bug.cc:11:10: required from here
bug.cc:11:5: error: the address of ‘c’ will never be NULL [-Werror=address]
11 | A<>::test();
The only fix is to remove the if constexpr (nothing else helps).
[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551 --- Comment #10 from Vlad Petric --- Could someone boost its priority? Given that gcc segfaults with valid code (see newest example/attachment), I believe it's worth a P1.
[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551 --- Comment #9 from Vlad Petric --- Created attachment 40235 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40235=edit Compliant code that segfaults the compiler
[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551
--- Comment #8 from Vlad Petric ---
(In reply to Vlad Petric from comment #7)
> Ok, so the example that I started this bug with is not standard compliant
> because it initialized different elements in a union with the constexpr
> constructor.
>
> The following does just one. I believe that the following is
> standard-compliant code (though obviously I could be wrong)
>
> And it generates a segfault.
>
> struct A {
> union {
> long s;
> char d[4];
> };
> constexpr A (char x) : d("") { d[0] = x; }
> };
>
> A a{'a'};
clang 3.8/4.0 have no problem with the above code.
Personally I think that we should change the main attachment and the tag - to
segfault on valid code (worse than ICE ...).
[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551
--- Comment #7 from Vlad Petric ---
Ok, so the example that I started this bug with is not standard compliant
because it initialized different elements in a union with the constexpr
constructor.
The following does just one. I believe that the following is standard-compliant
code (though obviously I could be wrong)
And it generates a segfault.
struct A {
union {
long s;
char d[4];
};
constexpr A (char x) : d("") { d[0] = x; }
};
A a{'a'};
[Bug c++/78551] Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551 --- Comment #2 from Vlad Petric --- Created attachment 40167 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40167=edit Code with constexpr that fails
[Bug c++/78551] Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551 --- Comment #1 from Vlad Petric --- Created attachment 40166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40166=edit code that fails as attachment
[Bug c++/77771] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #3 from Vlad Petric --- Sorry - accidentally added test case attachment to this bug. The bug I reported is likely related https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551
[Bug c++/77771] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #2 from Vlad Petric --- Created attachment 40165 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40165=edit code that fails
[Bug c++/78551] New: Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551
Bug ID: 78551
Summary: Internal compiler error with constexpr initialization
of union
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vlad at petric dot cc
Target Milestone: ---
The following code ICEs:
#include
#include
struct A {
union {
uint64_t s;
char buff[8];
};
constexpr A(const char* str) : s(0) {
if (str == nullptr) return;
size_t i = 0;
for (; i < 8 && str[i] != '\0'; ++i) {
buff[i] = str[i];
}
if (str[i] != '\0') throw std::out_of_range("");
}
};
constexpr std::array<A, 2> array({"long", "longer"});
It doesn't ICE if I do any of the following:
1. Switch the constructor to char[N] (where N is from template)
2. Get rid of constexpr
3. Get rid of the union - just initialize buff
[Bug c++/66921] New: failure to determine size of static constexpr array that is nested within a templated class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66921
Bug ID: 66921
Summary: failure to determine size of static constexpr array
that is nested within a templated class
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vlad at petric dot cc
Target Milestone: ---
Created attachment 36010
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36010action=edit
straightforward file (include-less) that fails to compile
templatetypename T
struct Holder {
constexpr static const int array[] = { 1, 2, 3 };
enum {F = array[0]};
};
class HI: public Holderint {};
gcc 4.9.3/Centos linux.
$ g++ -std=c++11 ./x.cc -o x.o -c
./x.cc: In instantiation of ‘constexpr const int Holderint::array []’:
./x.cc:4:18: required from ‘struct Holderint’
./x.cc:7:18: required from here
./x.cc:3:30: error: initializer fails to determine size of ‘Holderint::array’
constexpr static const int array[] = { 1, 2, 3 };
^
./x.cc:3:30: error: array must be initialized with a brace-enclosed initializer
./x.cc: In instantiation of ‘struct Holderint’:
./x.cc:7:18: required from here
./x.cc:4:8: error: enumerator value for ‘F’ is not an integer constant
enum {F = array[0]};
* with gcc 4.8.3, it compiles just fine.
* if I remove the template, it also compiles just fine:
struct Holder {
constexpr static const int array[] = { 1, 2, 3 };
enum {F = array[0]};
};
class HI: public Holder {};
[Bug c/31792] New: ivopts generates slightly worse code for tight loop from zlib
cmp0x6(%ecx),%al 50: 75 1c jne6e inner_longest_match+0x6e 52: 83 c2 01add$0x1,%edx 55: 0f b6 02movzbl (%edx),%eax 58: 3a 41 07cmp0x7(%ecx),%al 5b: 75 11 jne6e inner_longest_match+0x6e 5d: 83 c2 01add$0x1,%edx 60: 83 c1 08add$0x8,%ecx 63: 0f b6 02movzbl (%edx),%eax 66: 3a 01 cmp(%ecx),%al 68: 75 04 jne6e inner_longest_match+0x6e 6a: 39 da cmp%ebx,%edx 6c: 72 a2 jb 10 inner_longest_match+0x10 The sixth element: 3c: 83 c2 01add$0x1,%edx 3f: 0f b6 02movzbl (%edx),%eax 42: 3a 41 05cmp0x5(%ecx),%al 45: 75 27 jne6e inner_longest_match+0x6e The scan variable is no longer folded (it is instead incremented by one in each element), and consequently this loop no longer requires the ebx register for the temporary. The match variable is still folded. The issue here is that folding scan, while reducing the overall dataflow height, also requires an additional register. For register-starved architectures ( i.e., x86-32), this can turn into additional spills. This isolated example doesn't generate more spills. However, in real life this loop is part of the longest_match function within zlib's deflate.c, where it does create more spills (compiling deflate.c with -fno-ivopts speeds up the compression of high-redundancy content by ~1-2%). Finally, note that gcc 4.1.1 behaves similarly. -- Summary: ivopts generates slightly worse code for tight loop from zlib Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vlad at petric dot cc GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31792
[Bug c/31792] ivopts generates slightly worse code for tight loop from zlib
--- Comment #1 from vlad at petric dot cc 2007-05-02 19:36 --- Created an attachment (id=13498) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13498action=view) Isolated code which illustrates the ivopts issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31792
[Bug c/19685] New: ICE, in verify_local_live_at_start, at flow.c:574
[EMAIL PROTECTED]:~/cis/research/ripower$ gcc -O3 sim-ri.i sim-ri.c: In function `ruu_commit': sim-ri.c:4591: internal compiler error: in verify_local_live_at_start, at flow.c:574 -- Summary: ICE, in verify_local_live_at_start, at flow.c:574 Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vlad at petric dot cc CC: gcc-bugs at gcc dot gnu dot org,vlad at petric dot cc GCC build triplet: i486-linux-gcc GCC host triplet: i486-linux-gcc GCC target triplet: i486-linux-gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19685
[Bug c/19685] ICE, in verify_local_live_at_start, at flow.c:574
--- Additional Comments From vlad at petric dot cc 2005-01-29 06:34 --- Created an attachment (id=8097) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8097action=view) preprocessed sourcecode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19685
