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 was minimal and resu
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, 1, 2, 3,
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() : g() {}
};
} // na
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-const
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 z
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 > struct h {
typ
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, there'll be
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 && avr-g++
-fno-exceptions -std=c++
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't find reaso
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:
* produces a data
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/subprojects/avr/liba
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 wrong?
I'm
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
Bug ID: 120955
Summary: 50 % increase in data segment size on avr-gcc for -Os
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
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-frontiers.
% tim
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 debugging, -g1 of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119407
Bug ID: 119407
Summary: Missed optimization for identical branches
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
Bug ID: 119387
Summary: Regression in performance by a factor of 6 when
building with debugging symbols
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118011
Bug ID: 118011
Summary: -fshort-enums reported as enabled by default
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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? :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111607
Bug ID: 111607
Summary: False positive -Wdangling-reference
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110127
--- Comment #2 from fiesh at zefix dot tv ---
Thank you for feedback!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110127
Bug ID: 110127
Summary: -fimplicit-constexpr leads to extremely slow and
memory intensive compilation
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity
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_loop and
othe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109785
Bug ID: 109785
Summary: ICE in begin_maybe_infinite_loop
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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
--- Comment
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. The
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
--- Commen
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212
Bug ID: 106212
Summary: Code becomes non-constexpr with _GLIBCXX_DEBUG
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105823
Bug ID: 105823
Summary: -Wrestrict / -Wstringop-overflow / -Warray-bounds
warnings for uninitialized values
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105821
Bug ID: 105821
Summary: ICE for illegal constexpr-if
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assig
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 &);
> void operator delete(void * ptr, const int &
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 to mak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100485
Bug ID: 100485
Summary: False positive in -Wmismatched-new-delete
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99713
Bug ID: 99713
Summary: Add _GLIBCXX_CHECK_PREDICATES that violates runtime
guarantees and ensures predicates are valid
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99640
Bug ID: 99640
Summary: Internal compiler error: in lookup_template_class_1,
at cp/pt.c:9895
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99356
Bug ID: 99356
Summary: Recursive std::shared_future:s with
std::launch::deferred sporadically deadlock
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949
Bug ID: 97949
Summary: Recursive calls of std::call_once together with cout
leads to deadlock under mingw64
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Sev
52 matches
Mail list logo
