++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following code triggers a `-Wdangling-reference` warning:
t.cpp: In function ‘consteval auto f(const V&)’:
t.cpp:19:22: warning: possibly dangling reference to a temporary
[-Wdang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110127
--- Comment #2 from fiesh at zefix dot tv ---
Thank you for feedback!
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Created attachment 55262
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55262=edit
Testcase for slow -fimpli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109785
--- Comment #2 from fiesh at zefix dot tv ---
(In reply to Martin Liška from comment #1)
> Dup.
>
> *** This bug has been marked as a duplicate of bug 109666 ***
Ah thanks, and sorry for the dup. Searched for bagin_maybe_infi
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
This code:
struct Trans_NS___cxx11_basic_string {
constexpr Trans_NS___cxx11_basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88804
fiesh at zefix dot tv changed:
What|Removed |Added
CC||fiesh at zefix dot tv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
--- Comment #13 from fiesh at zefix dot tv ---
User99627, a few points:
* My test case does require lto to be present. There's nothing to be gained
from your statement that the bug doesn't require lto, there are test cases for
either case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
--- Comment #9 from fiesh at zefix dot tv ---
I forgot to mention that my test case requires -flto to be present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
fiesh at zefix dot tv changed:
What|Removed |Added
CC||fiesh at zefix dot tv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212
--- Comment #1 from fiesh at zefix dot tv ---
Oh and this appears to be a regression introduced in GCC 12.
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Consider the following C++20 code:
#include
struct P {
constexpr P(int i) : e{i} {}
auto operator<=>(P const &) const = default;
std::array e;
};
constexpr aut
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Some of our code when compiled with enough optimization resulted in weird
-Wrestrict warnings that I think were somehow
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following code leads to resource exhaustion:
namespace a {};
template int r() {
if constexpr (a) {
return r();
} else {
return r<(g + h) / 2, h>();
}
}
template int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100485
--- Comment #7 from fiesh at zefix dot tv ---
Thanks for the outline! We'll turn off -Wmismatched-new-delete with GCC 11 and
try to switch to the selective opt-out with pragmas in 12. That's a good
workaround for now.
On a random related note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100485
--- Comment #5 from fiesh at zefix dot tv ---
> extern "C" void free (void *);
>
> class Base
> {
> public:
> Base();
>
> void * operator new(unsigned long, const int &);
> v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100485
--- Comment #3 from fiesh at zefix dot tv ---
* marking operator delete noinline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100485
--- Comment #2 from fiesh at zefix dot tv ---
But this isn't really a solution since I can't inline new without moving a lot
of code into the header, and marking `operator new` noinline isn't what I want
either. I read both articles prior
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following code triggers -Wmismatched-new-delete:
extern "C" void free(void *);
class Base
{
public:
Base();
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
This is an extension of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519
A very nasty kind of bugs
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following reduced code results in the internal compiler error mentioned in
the subject line:
---
class
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Trying to sail around 97949, we switched to using std::shared_future combined
with std::launch::deferred instead
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-w64-mingw32.static
The following code locks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
fiesh at zefix dot tv changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92583
fiesh at zefix dot tv changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78022
fiesh at zefix dot tv changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88242
fiesh at zefix dot tv changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95832
--- Comment #7 from fiesh at zefix dot tv ---
> Not possible to backport to gcc-10, because the front end support
isn't there. That unfortunately means std::variant construction works
differently in each of gcc-9, gcc-10 and master.
Does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95832
--- Comment #3 from fiesh at zefix dot tv ---
I did the former, you do the latter :P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95832
--- Comment #1 from fiesh at zefix dot tv ---
https://en.cppreference.com/w/cpp/utility/variant/variant says that
"If T_i is (possibly cv-qualified) bool, F(T_i) is only considered if
std::decay_t (until C++20)std::remove_cvref_t (since
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following code returned 1 when compiled with gcc-9 but returns 0 with
gcc-10. Since clang exhibits
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Being guilty of abusing -isystem a lot to silence warnings in third-party
libraries, it would be great if there were a spin off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #9 from fiesh at zefix dot tv ---
(In reply to Martin Liška from comment #8)
> Ok, GCC newly received a support for __has_builtin, so one needs to
> '#define a 0' always.
> The ICE started with r259043, before that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #7 from fiesh at zefix dot tv ---
And creduce just finished: (I left the ifdef unchanged so it can still be
compiled under clang.)
#ifdef __has_builtin
#define a 1
#endif
template struct d {
typedef b e;
constexpr operator e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
--- Comment #8 from fiesh at zefix dot tv ---
Ok, thanks for the feedback!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
--- Comment #6 from fiesh at zefix dot tv ---
My suggestion would be to uniformly include the information about whether a bug
has been closed, irrespective of its nature. So yes, un-optimal code
generation might also be listed, and I think
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The former, while logically sounder, seems difficult to implement without
adding every single open ticket on GCC's Bugzilla and returning `true` for
every non-existent one.
So probably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #5 from fiesh at zefix dot tv ---
Thank you for your offer. The original translation unit is a whopping 20MB and
took about 3 days to reduce ;-)
I changed the file and the interestingness test to make sure clang compiles it.
It's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #3 from fiesh at zefix dot tv ---
(Or is there some other trick to make it valid apart from extending the
interestingness test of creduce to include a clang compilation step?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #2 from fiesh at zefix dot tv ---
It's been made invalid by creduce, but the original code was valid.
If necessary, we can try to produce valid code that leads to the same issue.
But I'd only do so if necessary since it's somewhat
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following code results in an internal compiler error in 8, 9, and trunk:
namespace a {
template
struct c {};
template
using d = int;
template
struct e {};
template
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following code leads to an internal compiler error with gcc 8, 9, and
trunk:
template struct a {};
template using b = int;
template struct e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88242
--- Comment #2 from fiesh at zefix dot tv ---
So from the discussion
https://bugs.llvm.org/show_bug.cgi?id=41785
I think this also is actually ill-formed code.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
(Filed this as C++ but don't think that's the right component.)
The following code compiles to a program that behaves as follows:
* Compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91351
--- Comment #4 from fiesh at zefix dot tv ---
Yeah, it seems the "bad commit" just somehow triggered this behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91351
--- Comment #1 from fiesh at zefix dot tv ---
commit 37db4f8d72cfc87716a729b38aa2f42097cdbf1f
Author: glisse
Date: Tue Oct 2 14:55:39 2018 +
No a*x+b*x factorization for signed vectors
2018-10-02 Marc Glisse
PR
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following code results in different runtime behavior depending on whether
it is compiled with -fstrict-enums or not:
#include
enum E { e0, e1, e2, e3, e4, e5, e6, e7, e8, e9, e10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371
fiesh at zefix dot tv changed:
What|Removed |Added
CC||fiesh at zefix dot tv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88242
--- Comment #1 from fiesh at zefix dot tv ---
Ran through creduce:
template struct b { static constexpr int c = a; };
template struct d {};
template struct j;
template struct j> : b {};
template constexpr long h = j::c;
template struc
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following code leads to g++ (and also clang++) running indefinitely. It
needs to be compiled with -std=c++17.
#include
template
void p(T const & v)
{
}
template
void f(T &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78022
--- Comment #5 from fiesh at zefix dot tv ---
The code still does not compile with gcc-8.2 but does compile on trunk now!
Conversely, clang consistently refuses to compile it since clang-5.
So I guess this can be closed, unless clang
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following code compiles iff -DFIX is supplied. Clang compiles it both with
and without -DFIX. Please let me know what else I can do to help debug this
problem, I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #12 from fiesh at zefix dot tv ---
X(double) : X(X(42)) {} // clang doesn't like this
is also enough to show the difference, no need for an operator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #6 from fiesh at zefix dot tv ---
Again, fixes the issue for me with clang!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #4 from fiesh at zefix dot tv ---
Heh ok, you tricked me ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #2 from fiesh at zefix dot tv ---
This fixes the problem. Thank you so much for your effort!
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
For a type T that is non-trivially copy constructible, std::optional is not
copy constructible. However, only clang catches
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following code compiles with gcc <= 7.3 and clang. It also compiles with
gcc >= 8 when FIX is defined. It does not compile with gcc >=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842
fiesh at zefix dot tv changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842
--- Comment #4 from fiesh at zefix dot tv ---
> So I'm strongly opposed to that part of the suggestion. Either you get all
> the ABI-preserving debug checks, or none.
Checking all (possible) preconditions without any limit on the intr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842
--- Comment #2 from fiesh at zefix dot tv ---
> Not everything. Some Expects preconditions cannot be tested (e.g. that
> pointer points to an array of at least N objects).
True. I suppose it's sufficient to have that memory accessed (s
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Right now, the debug mode changes the ABI. Thus everything that is linked,
including libraries, needs to be compiled using debug mode, making
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Preface: A rather hard-to-find set of bugs is that introduced by violating
run-time preconditions imposed by certain functions. For example, failing to
satisfy the Compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85373
--- Comment #1 from fiesh at zefix dot tv ---
The problem is that d_count_templates_scopes calls itself infinitely.
: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following leads to cxxfilt running with 100% CPU indefinitely:
/tmp/binutils-gdb/binutils (master✗) % echo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281
--- Comment #7 from fiesh at zefix dot tv ---
Oh, I just realize I misunderstood what ice-on-invalid means. Sorry about
that!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281
--- Comment #5 from fiesh at zefix dot tv ---
The test case was reduced from an actual translation unit that stalled our
build server. Since the translation unit itself was invalid C++, the test case
is too. I think it shouldn't be part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281
--- Comment #2 from fiesh at zefix dot tv ---
I guess that depends on the definition of "meaningful". It reproduces the
problem, so I'd say yes. ;)
: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Created attachment 43362
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43362=edit
Reduced test case for indefinite heap growth
Attached you find a creduced file that triggers the follow
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Created attachment 43335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43335=edit
Reduced file leading to segfault with "g++ -c -std=c++17 -g"
Attached you find the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
fiesh at zefix dot tv changed:
What|Removed |Added
CC||fiesh at zefix dot tv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78022
--- Comment #3 from fiesh at zefix dot tv ---
Interestingly, clang-5 no longer compiles this code:
:28:15: error: constexpr variable 'b1' must be initialized by a
constant expression
constexpr B b1{0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83482
--- Comment #2 from fiesh at zefix dot tv ---
Maybe it provides a good test case though since it is triggered by -O2 but not
by -Os, like the original bug report?
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Created attachment 42914
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42914=edit
Preprocessed code triggering segmentation fault
The attached file leads to a segmentat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78022
--- Comment #1 from fiesh at zefix dot tv ---
The same happens with 6.2.1.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following piece of code does not compile. Since clang 3.8.1 compiles it,
and furthermore changes that would appear inconsequential make it compile, I
suspect it might be an issue of GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68383
--- Comment #14 from fiesh at zefix dot tv ---
It appears to be correct, as far as one can safely judge this by eye
examination.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68383
--- Comment #8 from fiesh at zefix dot tv ---
Would it be helpful it I tried to create a test case for 5.2.0? Or anything
else I can provide?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68159
fiesh at zefix dot tv changed:
What|Removed |Added
CC||fiesh at zefix dot tv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68159
--- Comment #5 from fiesh at zefix dot tv ---
Ah I see, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68383
--- Comment #2 from fiesh at zefix dot tv ---
g++ 4.9.3, I do have the source code and will try to provide a minimal test
case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68383
--- Comment #3 from fiesh at zefix dot tv ---
Created attachment 36739
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36739=edit
Preprocessed c++ file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68383
--- Comment #4 from fiesh at zefix dot tv ---
I added a preprocessed file that triggers the bug. It was created using
g++ -I. -std=c++14 -E -o write.ii write.cpp
and can be compiled and linked using
g++ -std=c++14 -o write write.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66769
--- Comment #3 from fiesh at zefix dot tv ---
Better, self contained problem case:
class A
{
void f(int a);
int g();
};
void A::f(int a) {}
int A::g()
{
auto r = [] (auto x) { f(*x); };
int * p;
r(p);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66769
--- Comment #2 from fiesh at zefix dot tv ---
A friend checked for me, 5.1.0 also appears affected.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Created attachment 35914
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35914action=edit
Preprocessed test case
The following simple C++14 program leads to a segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66769
--- Comment #1 from fiesh at zefix dot tv ---
Sorry, the above output was for 4.9.2 on a different host, mixed up when I ran
several tests. For 4.9.3:
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/g++
Target: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
--- Comment #15 from fiesh at zefix dot tv ---
Boost 1.58.0 has a workaround by making one function explicit.
(https://github.com/boostorg/polygon/commit/634aa3de29d63dcf02a478ca2b5045c5e9ccb7e0)
Since this means the bug becomes irrelevant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
--- Comment #14 from fiesh at zefix dot tv ---
Bounty: EUR 150
I'd like to try something new and place a bounty on this issue. In order to
collect it, you have to provide a patch that is accepted into 4.9 and 5. You
also need to be able
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
--- Comment #13 from fiesh at zefix dot tv ---
Are there any news on this bug? At least for us, this keeps production code
from being able to work with any boost 1.55, which is becoming an increasingly
bigger issue.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
I originally filed this as a boost bug:
https://svn.boost.org/trac/boost/ticket/10531
However, given that clang 3.4.2 has no problems compiling it, I suspect it
might be a gcc issue.
In short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
--- Comment #3 from fiesh at zefix dot tv ---
I wanted to, but the problem is that the ii file is 2.7MB, more than the
maximum allowed file size of 1000KB. Should I upload it to a different site?
Also I just realized that the problem only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
--- Comment #9 from fiesh at zefix dot tv ---
Ever so little simplified:
struct A {};
template typename _B1
struct B : _B1 {};
template typename _Tp
_Tp declval();
template typename _From, typename _To
struct C {
template typename _From1
92 matches
Mail list logo
