https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #24 from R. Diez ---
In case somebody else wants to patch their GCC 12.2, here is the
slightly-modified patch for convenience:
https://github.com/rdiez/DebugDue/blob/master/Toolchain/Patches/Gcc12EhGlobalsAtexit.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #23 from R. Diez ---
Many thanks for the fix.
If you backport it to GCC 12.x, I won't be able to complain so much. ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #20 from R. Diez ---
I had to modify the patch slightly. I guess that union member "unsigned char
unused;" was removed after GCC 12.2 was released.
But otherwise, the patch does work, at least in my bare-metal scenario. The
atexit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #16 from R. Diez ---
I am slowly arriving at a different conclusion.
"struct __cxa_eh_globals" has neither a constructor nor a destructor. Its
members are pointers or integers, so GCC will not have automatically generated
any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
R. Diez changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #13 from R. Diez ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
R. Diez changed:
What|Removed |Added
CC||rdiezmail-gcc at yahoo dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #9 from R. Diez ---
> [...]
> not just "turn on -Os and all the code gets removed".
I am sure that the solution is not as trivial as "turn on -Os". But, as an
outsider, it is hard to believe that it "takes non-trivial analysis of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #8 from R. Diez ---
Why does this 'eh_globals' object have to use a constexpr constructor?
How does the current code avoid the "static initialization order fiasco"? If
the user defines his/her own static C++ objects, how is it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #5 from R. Diez ---
I know very little about GCC, but it is a very smart compiler, so I am having a
hard time understanding how GCC could miss so many optimisations. After all,
even when compiling with little optimisation, GCC seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #4 from R. Diez ---
The 'constant_init' wrapper with the 'union' inside is a contrived hack, isn't
it? We may as well use a different hack then.
How about a combination of '__attribute__ constructor' and 'placement new' like
this?
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rdiezmail-gcc at yahoo dot de
Target Milestone: ---
I have this embedded firmware project of mine, which uses Newlib:
https://github.com/rdiez/DebugDue
It is the template for other similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606
--- Comment #13 from R. Diez ---
It is hard to automatically tell whether nobody else is using such a
statically-allocated emergency buffer. In my case, I am using C++ exceptions,
so the linker will probably always include the buffer.
My patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606
--- Comment #11 from R. Diez ---
> Has a solution been found for embedded systems with very limited resources?
> In this case for example, C++ exceptions can be disabled and this
> emergency pool not needed.
Contrary to popular belief, C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98992
R. Diez changed:
What|Removed |Added
CC||rdiezmail-gcc at yahoo dot de
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68605
--- Comment #4 from R. Diez ---
That is certainly a way to fix the crt0 nuisance. But it requires some specs
file black magic, so yet another thing to learn. And then you have to keep up
with GCC in case something changes around the specs files.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160
R. Diez changed:
What|Removed |Added
CC||rdiezmail-gcc at yahoo dot de
--- Comment #6
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: rdiezmail-gcc at yahoo dot de
Target Milestone: ---
I have been using the following makefile for years to build a cross-compiler
GCC toolchain with Newlib:
https://github.com/rdiez
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rdiezmail-gcc at yahoo dot de
Target Milestone: ---
File libstdc++-v3/doc/html/manual/configure.html states for
"--enable-cstdio=OPTION":
"At the moment, the only c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98324
R. Diez changed:
What|Removed |Added
CC||rdiezmail-gcc at yahoo dot de
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42579
--- Comment #12 from R. Diez ---
*** Bug 77488 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488
R. Diez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42579
R. Diez changed:
What|Removed |Added
CC||rdiezmail-gcc at yahoo dot de
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
--- Comment #5 from R. Diez ---
In a nutshell: "objdump --syms" does not show that symbol, probably because the
routine was inlined, but "readelf --debug-dump" does show it.
Thanks for your help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
--- Comment #3 from R. Diez ---
Regarding "shifting the blame", no worries, I am grateful for any help.
I suspect that there is more than 1 issue here. Could you take a look at the
following aspect mentioned in the GDB bug?
8<8<
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: rdiezmail-gcc at yahoo dot de
Target Milestone: ---
GDB has excessive CPU load and memory usage with -g3 debug info. Sometimes it
makes GDB unusable.
There are problems with debug (non LTO
Assignee: unassigned at gcc dot gnu.org
Reporter: rdiezmail-gcc at yahoo dot de
Target Milestone: ---
If you pass -flto=jobserver , and the jobserver file descriptors are not
actually available, you get no warning whatsoever from GCC.
GNU Make does try to help in this scenario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488
--- Comment #7 from R. Diez ---
(In reply to Piotr Henryk Dabrowski from comment #6)
> You can use:
>
> #line 2 "FileName.cpp"
>
> at the very top (!) of all your files
> to change the content of __FILE__.
> This also affects compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83211
--- Comment #2 from R. Diez ---
I am upgrading my embedded ARM Cortex-M4 toolchain from GCC 6.4 to GCC 7.3, and
Binutils from 2.29.1 to 2.30 (among other minor component upgrades), and I am
not seeing this warning anymore.
I do not know what
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rdiezmail-gcc at yahoo dot de
Target Milestone: ---
I recently upgraded my embedded ARM Cortex-M4 toolchain from GCC 6.3 to GCC
6.4, and Binutils from 2.28 to 2.29.1 (among other minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606
--- Comment #6 from R. Diez ---
The proposed patch looks OK. But I guess I will not be able to completely
disable the emergency pool by setting STATIC_EH_ALLOC_POOL_BYTES to 0, right?
But at least I hope that setting a very low value will have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488
--- Comment #2 from R. Diez ---
> __FILE__ expands to whatever you pass on the command line as the base file
> (and for headers whatever the directory is where they are found + the header
> filename. So, if you compile with gcc -c something.c
: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: rdiezmail-gcc at yahoo dot de
Target Milestone: ---
Hi all:
I am writing embedded software for a memory-constraint embedded target.
However, I would still like to use assert() in debug builds to help debug the
software
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606
--- Comment #2 from R. Diez ---
A setting like LIBSTDCXX_EMERGENCY_EH_POOL_SIZE sounds good. However, an
environment variable will not help me, it has to be a configuration option when
building the toolchain. I am writing embedded firmware with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68605
--- Comment #2 from R. Diez ---
Option -nostartfiles breaks other start-up things like _init and
__libc_init_array:
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rdiezmail-gcc at yahoo dot de
Target Milestone: ---
I am writing embedded firmware in C++ for small ARM Cortex-M3 microcontrollers
running on a 'bare metal' environment. One
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: rdiezmail-gcc at yahoo dot de
Target Milestone: ---
I am developing embedded software on an ARM Cortex-M3 CPU without an OS ('bare
metal') using newlib. I am not using libgloss, sometimes because the boards
need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63440
--- Comment #2 from R. Diez rdiezmail-gcc at yahoo dot de ---
Yes, I would enable -fmerge-constants with -Og.
I would do it even for -O0. Merging constants should be safe, and it saves
precious program space when generating debug builds
Assignee: unassigned at gcc dot gnu.org
Reporter: rdiezmail-gcc at yahoo dot de
The documentation for -fmerge-constants does not mention that the new
optimization level -Og does enable -fmerge-constants too. Or at least it seems
to do, judging by the generated code size in my tests.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55514
Bug #: 55514
Summary: PowerPC EABI: Warning: setting incorrect section
attributes for .sdata2
Classification: Unclassified
Product: gcc
Version: 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55515
Bug #: 55515
Summary: PowerPC EABI: Create a predefined symbol for
-mdata=xxx
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49674
Summary: Improve documentation for __attribute__ __section__
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo:
41 matches
Mail list logo
