https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #28 from fiesh at zefix dot tv ---
I guess if the optimization goal of -Os is just to reduce the *total* size,
then this is not a regression but an improvement. It's just that this is the
wrong goal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #26 from fiesh at zefix dot tv ---
(Also note that I'll gladly provide the source code for the entire project if
that helps somebody.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #25 from fiesh at zefix dot tv ---
> But this looks like a trade off of text size vs data size.
>
> I still don't see the huge difference which you were originally seeing.
I specifically created a test case that w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #22 from fiesh at zefix dot tv ---
And reduced somewhat more by hand, no idea why cvise couldn't figure this out:
-8<-
struct h {
int g;
constexpr h() : g() {}
};
struct n {
h m{};
};
struct H {
int p[6]{0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #21 from fiesh at zefix dot tv ---
Ok, reduction finally done:
-8<-
template struct b {
typedef int c[a];
};
template struct f {
b::c d;
};
namespace e::detail {
struct h {
int g;
constexpr h()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #20 from fiesh at zefix dot tv ---
Actually, this is not a good reduction since the original unreduced test case
does not rely on `-fimplicit-constexpr`. (One needs to modify the source
trivially by removing the call to the non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
fiesh at zefix dot tv changed:
What|Removed |Added
Keywords|needs-source|
--- Comment #19 from fiesh at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #18 from fiesh at zefix dot tv ---
Ok, finally here's a reduced testcase:
-8<-
typedef int c __attribute__((__mode__(__SI__)));
typedef int d __attribute__((__mode__(__SI__)));
template < typename f, int g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #17 from fiesh at zefix dot tv ---
Actually, my interestingness test is broken since cvise expects it to take its
argument in the current working directory...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #16 from fiesh at zefix dot tv ---
Ah also I just realized it's cvise's CommentsPass that breaks the TU right away
and keeps it from being reduced further. Disabling this pass now makes cvise
do something. So hopefully, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #15 from fiesh at zefix dot tv ---
To reproduce my sizes:
~ % podman run -it -v /tmp:/tmp alpine:3.21 sh -c 'sed -i -e s/https/http/
/etc/apk/repositories && apk -q add gcc-avr && avr-g++ --version && a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949
--- Comment #11 from fiesh at zefix dot tv ---
(In reply to Sam James from comment #10)
> (In reply to fiesh from comment #9)
>
> https://gcc.gnu.org/bugzilla/userprefs.cgi "After changing a bug"
Ah thank you. What a bizarre default behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #13 from fiesh at zefix dot tv ---
I should mention that it's key to use `avr-size -G` to get meaningful data
sizes for objects. The default Berkeley style gives very small data sizes for
objects. No clue why, and I can&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #12 from fiesh at zefix dot tv ---
Created attachment 61893
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61893&action=edit
unreduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949
--- Comment #9 from fiesh at zefix dot tv ---
This test case was meant to be added to 120955
This is a very weird UI bug in Bugzilla. I tried uploading the attachment, it
complained it was too big, I pressed back or ok or something, added it in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949
--- Comment #8 from fiesh at zefix dot tv ---
Created attachment 61892
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61892&action=edit
unreduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #11 from fiesh at zefix dot tv ---
So at last I have *something*. I'm not sure if it's at the core of the problem
though, but it does look fishy to my untrained eye.
Attached you find a translation unit a.ii that:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #10 from fiesh at zefix dot tv ---
Naturally, but it doesn't go away:
avr-size on all individual object files:
textdata bss dec hex filename
88 0 0 88 58
/b_os_nolto/subproject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #8 from fiesh at zefix dot tv ---
No, I deactivated lto completely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #6 from fiesh at zefix dot tv ---
Alas, running `avr-size` on the individual modules doesn't produce anything of
significant data size. They also don't add up even remotely to the final
linked file. Am I doing something w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #5 from fiesh at zefix dot tv ---
Ah of course, sizing individual object files might make it much easier. Thank
you, I think I'll be able to create a proper testcase this way. I'll get back
to here when I've reduced it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #3 from fiesh at zefix dot tv ---
Thank you for the feedback. I tried to generate a test case, but it proved
really hard for me. Is there some other output, like nm or objdump, that could
help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #1 from fiesh at zefix dot tv ---
12de1942a0a is r15-6052-g12de1942a0a673
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
For our software that controls various machinery in our factory, we have the
following sizes:
Commit 0c83096f19b:
textdata bss dec hex filename
212830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
--- Comment #13 from fiesh at zefix dot tv ---
(In reply to Jakub Jelinek from comment #12)
> Or if it is var tracking or statement frontiers, you can try -O2 -g
> -fno-variable-tracking-assignments and/or -O2 -g -gno-statement-fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
--- Comment #11 from fiesh at zefix dot tv ---
(In reply to Alexander Monakov from comment #10)
> Just a quick note for reporter's information: if you need just the symbols
> for stack traces, not full debug info for interactive deb
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Consider this (somewhat nonsensical) code snippet
-8<-
#include
std::vector f(int const i) {
if (i == 42) {
return {};
}
std::vector v;
retur
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Created attachment 60831
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60831&action=edit
Increase in compile
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
% gcc -Q --help=optimizers | grep short-enums
-fshort-enums [enabled]
However, it is not enabled by default, see https://godbolt.org/z/68d9sba31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949
--- Comment #5 from fiesh at zefix dot tv ---
But will it be fixed for 13^W14^W15? :-)
++
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&action=edit
Testcase for slow -fi
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_infinite
++
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
e
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 re
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 ar
++
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 of
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.
Doe
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 the
: 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 of
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, befor
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 the
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 probabl
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&#
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&
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:
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 is
: 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'
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
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 access
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 o
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&action=edit
Reduced test case for indefinite heap growth
Attached you find a creduced file that triggers the fo
++
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&action=edit
Reduced file leading to segfault with "g++ -c -std=c++17 -g"
Attached you
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
1 - 100 of 122 matches
Mail list logo
