[Bug c++/61372] Add warning to detect noexcept functions that might throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372 David Crocker changed: What|Removed |Added CC||dcrocker at eschertech dot com --- Comment #1 from David Crocker --- I too would find this very useful. However, it's essential that functions declared 'extern "C" ' are (or optionally can be) assumed to not throw exceptions. Otherwise, calls to C library functions and MCU vendor-supplied C header files from C++ functions declared 'noexcept' will trigger this warning. Also, the warning should be disabled when -fno-exceptions is used.
[Bug c++/61372] Add warning to detect noexcept functions that might throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372 --- Comment #3 from David Crocker --- (In reply to Jonathan Wakely from comment #2) > extern "C" functions can throw, so it would be wrong to unconditionally > assume they can't. True, you can write an extern "C" function that throws. But does it ever make sense to? I don't think so. Functions written in C and then declared extern "C" in a C++ program so that they can be called from C++ won't throw or propagate exceptions, even if they end up calling functions written in C++ that throw. The only reason to write a function in C++ and declare it extern "C" is so that it call be called from C, in which case it had better not throw.
[Bug c++/61372] Add warning to detect noexcept functions that might throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372 --- Comment #5 from David Crocker --- You seem to be assuming that C++ exceptions can propagate through functions compiled with a C compiler. On most platforms, they normally cannot, because a C compiler does not produce the information needed for the C++ unwind mechanism to unwind the call stack. If you want bsearch and qsort to propagate C++ exceptions, on most platforms the implementations of those functions would have to be compiled either using a C++ compiler, or with a C compiler using a special option that tells the compiler to include the tables and/or code needed to propagate C++ exceptions. Otherwise the exception will end up at std::unexpected. Maybe bsearch and qsort in newlib are compiled this way, I haven't checked. I don't care whether extern "C" functions are to be assumed noexcept by default or another compiler option is needed to specify that. But without this facility, the proposed warning will be useless in practice, at least for people like me writing embedded software.
[Bug c++/79189] Poor code generation when using stateless lambda instead of normal function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79189
David Crocker changed:
What|Removed |Added
CC||dcrocker at eschertech dot com
--- Comment #2 from David Crocker ---
I have found another bug involving a const pointer to a lambda function, that
goes away if I use -std=gnu++17. I am constructing a const table of structs
that has a field of function pointer type, and I need it to go into .rodata
because of limited RAM on an embedded platform. I would like to use lambda
functions in the table definition, for example:
const ObjectModelTableEntry RepRap::objectModelTable[] =
{
{ ..., [] (ObjectModel* self) { return (void
*)&(((RepRap*)self)->GetGCodes()); }, ... }
};
Using GCC 7.3.1 20180622 with std=gnu++14, the compiler doesn't put this in the
rodata segment. If I change it to:
static void* func(ObjectModel *self) { return (void
*)&(((RepRap*)self)->GetGCodes()); }
const ObjectModelTableEntry RepRap::objectModelTable[] =
{
{ ..., func, ... }
};
then it does put it in rodata.
[Bug other/99486] New: Feature request: -fstack-check option for embedded processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99486 Bug ID: 99486 Summary: Feature request: -fstack-check option for embedded processors Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dcrocker at eschertech dot com Target Milestone: --- The -fstack-check option merely adds code to probe the end of the new stack and relies on the hardware and operating system supporting memory paging to do the actual checking. This makes it useless for embedded system development using e.g. ARM Cortex processors. In particular, when developing embedded systems using RTOS on processors with limited RAM, the amount of stack provided to each task must be optimised to avoid wasting RAM; but this is difficult to do without stack checking. Some RTOS provide a mechanism to check that a stack canary at the limit of the stack hasn't been overwritten whenever a task is descheduled; but this isn't reliable because the stack may overflow without the canary being overwritten, or the program may crash before the stack check happens. The -fstack-limit option of gcc is of no use in systems using RTOS because the stack limit is different for each task. I propose an additional option for implementing -fstack-check that does not require memory paging hardware. This option would have the compiler call a stack-check function near the start of the code generated for each function. A single parameter would be passed to that function, which would be the lowest (if the stack grows downwards) stack address used in the remainder of the function. Similarly, when allocating objects of dynamic size on the stack, the stack check function would be called. The stack check function would be provided by the user or by an RTOS library. It would typically check the address passed against the stack limit for the current task, and if the stack limit would be exceeded, terminate the program or task with suitable logging of the error. In a development environment it could also record the greatest amount of stack ever used by each task.
[Bug c/47781] warnings from custom printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 David Crocker changed: What|Removed |Added CC||dcrocker at eschertech dot com --- Comment #23 from David Crocker --- I need this feature too. Instead of waiting several more years for an all-singing all-dancing solution, PLEASE can we have a simple solution that allows me to use a custom format specifier and skips a single argument for that specifier. I believe this would cover the vast majority of uses custom format specifiers. My particular use case is that my application generates a lot of JSON strings, so in my printf replacement I want to implement a specifier similar to %s that performs JSON escaping on characters in the string.
[Bug target/96882] Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882 David Crocker changed: What|Removed |Added CC||dcrocker at eschertech dot com --- Comment #9 from David Crocker --- Is there any update on this? I need to turn on LTO to keep the code size of a large application within the flash memory space of the target ARM Cortex M4F processor; but by the sound of it, doing so will be unsafe.
[Bug c++/48379] -Wdouble-promotion warns for promotion by varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48379 David Crocker changed: What|Removed |Added CC||dcrocker at eschertech dot com --- Comment #4 from David Crocker --- I too am getting fed up with having to add an explicit cast to double to suppress the warning whenever I pass a float to a varargs function. I have probably spent a few hours this year adding these casts. As has already been said, nothing can he done about the promotion in this context, so it's not worth warning about. Whereas in other situations, the warning is very useful to me because I work with embedded processors that have single-precision but not double-precision floating point hardware, so I want to avoid double precision maths as far as possible.
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523 David Crocker changed: What|Removed |Added CC||dcrocker at eschertech dot com --- Comment #16 from David Crocker --- This issue is not specific to AVR target. I get the same spurious warning from gcc 12.2 arm-none-eabi when I compile the following code for ARM Cortex M0+ and M4 targets: const char *bootloaderVersionText = *reinterpret_cast(0x20); I haven't found a workaround other than to use a pragma to disable the warning for that line of code.
[Bug target/96882] Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882 --- Comment #11 from David Crocker --- As the master branch was updated a year ago according to comment 10, does this mean that there is now a stable release of gcc that incudes the patch?
[Bug c++/61372] Add warning to detect noexcept functions that might throw [-Wnoexcept-mismatch]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372 --- Comment #11 from David Crocker --- I've been bitten by this several times. In the absence of support for this type of checking in GCC I added exception checking to our own homebrew static analysis tool. It's already detected three situations in which invalid user input would cause termination of our application instead of an error message, due to a function throwing an exception when it was called from another function that was declared noexcept. I think removing more detailed exception specifications from C++ was a big mistake. I can understand that in many applications they were not needed; however in mission critical real-time applications that use exceptions in very limited ways, such as the one we write, it's vital to know that any exception thrown will be caught and handled, not cause termination.
