https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117630
--- Comment #20 from R. Diez ---
(In reply to GCC Commits from comment #19)
Great, thanks for this optimisation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117630
--- Comment #17 from R. Diez ---
> > I haven't found any way to make the linker say why it is pulling certain
> > symbols or object files.
>
> That sounds like the GNU linker "-y" option (as in "-y symbol"). Does that
> not DTRT?
That option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117700
--- Comment #4 from R. Diez ---
I just found out some more information on this.
C++ is counterintuitive here, as template ArrayElemCount is only actually using
type information.
This article considers it a language defect:
https://www.learncpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117683
--- Comment #9 from R. Diez ---
Interesting. I think that vague warning in the documentation could be
interpreted as "mixing is risky and/or discouraged" and should be rephrased.
After all, at least some level of mixing is apparently safe.
I am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117683
--- Comment #7 from R. Diez ---
About using C++ exceptions without RTTI, I tried to build a toolchain for ARM
(arm-none-eabi) with -fno-rtti, and I got the following compilation errors
(they may be more):
File eh_arm.cc:
[...]/gcc-14.2.0/libst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117683
--- Comment #6 from R. Diez ---
I do not understand why you say that RTTI "names" merely need to be unique.
The specification for "const char* name() const;", which I quoted in my first
post, says "the returned string can be identical for sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92220
R. Diez changed:
What|Removed |Added
CC||rdiez-2006 at rd10 dot de
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117700
Bug ID: 117700
Summary: spurious error "non-constant condition" when inside a
class member
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117696
Bug ID: 117696
Summary: LTO ignores -g3 debug info level
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117683
--- Comment #4 from R. Diez ---
You are right, I'm sorry I got mixed up. Must have been memories of a distant
past.
I still see no reason to lose typeid and some dynamic_cast scenarios though.
It's only the names of the classes that are useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372
--- Comment #12 from R. Diez ---
I do not agree with the detailed exception specifications. Java tried and such
code is hard to maintain. I think all code should generally be able to cope
with any exceptions: either handle them, pass them up the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98992
--- Comment #3 from R. Diez ---
This is still broken in GCC 14.2.
The test code I am using is:
#include
struct MyClass
{
static void FreeMemory ( const void * pMem ) throw();
__attribute__ (( malloc, malloc( MyClass::FreeMemory, 1 ) ))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372
--- Comment #10 from R. Diez ---
I have been bitten by this lack of warning before, but GCC 10.5 should be able
to issue such a warning by default and has the following option in order to
disable the warning:
-Wno-terminate (C++ and Objective-C+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438
R. Diez changed:
What|Removed |Added
CC||rdiez-2006 at rd10 dot de
--- Comment #14 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117683
--- Comment #2 from R. Diez ---
> You know most places which are size constraints ban the use of RTTI.
Popular belief is often wrong. See here for details:
https://github.com/rdiez/DebugDue?tab=readme-ov-file#about-c-exceptions
I am actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117683
Bug ID: 117683
Summary: provide a way to remove all C++ class names from the
binary
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117672
--- Comment #3 from R. Diez ---
This is an example:
class test_class
{
public:
// The mere existence of this empty constructor is enough
// to make GCC generate an empty _GLOBAL__sub_I_main block
// and to keep all unused virtual methods.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117673
Bug ID: 117673
Summary: Unused static objects with non-trivial destructors not
removed
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117672
Bug ID: 117672
Summary: Remove unused virtual methods
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117630
R. Diez changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117630
--- Comment #14 from R. Diez ---
I do not understand why the compiler is generating
_GLOBAL__sub_I__ZSt20__throw_system_errori with the 2 atexit calls for
generic_category_instance and system_category_instance, or why the linker is
not optimizin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117630
--- Comment #13 from R. Diez ---
> Those two could be combined into one struct so there's only one destructor
> registration instead of two.
Thanks for your help, but reducing the number of atexit calls doesn't really
help me much. As I said
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117630
--- Comment #8 from R. Diez ---
I am not sure yet why generic_category_instance and system_category_instance
are not been discarded like they probably should.
I haven't found any way to make the linker say why it is pulling certain
symbols or o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117630
--- Comment #6 from R. Diez ---
I looked further for anything that references *_category* in my firmware, by
looking at the linker-generated cross-references table, and I noticed this in
file "gcc-14.2.0/libstdc++-v3/src/c++11/cow-stdexcept.cc":
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117630
--- Comment #5 from R. Diez ---
I am trying to figure out why generic_category_instance and
system_category_instance land in my ELF file even though nobody is apparently
using them. Other similar objects, like io_category_instance, do not.
So I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117630
--- Comment #3 from R. Diez ---
Thanks for the info. I guess one way out for me would be to skip GCC 14 and
hope that those 2 atexit calls that are pestering my now do get optimised away
by GCC 15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #30 from R. Diez ---
I just hit a similar atexit problem with GCC 14.2, this time for immortal
instances generic_category_instance and system_category_instance. See here for
more information:
https://gcc.gnu.org/bugzilla/show_bug.cg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117630
Bug ID: 117630
Summary: Useless atexit entry for generic_category_instance and
system_category_instance
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117127
Bug ID: 117127
Summary: Feature request: Warning on useless 'const' in a
function declaration
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
29 matches
Mail list logo
