| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
gnat-llvm seems to be a bit more aggressive about eliminating unused
variables. This patch improves the test results a tiny bit by
arranging for some variables to appear to be used.
Note the copyright dates on the new files are done that way because I
simply copied existing files.
|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
Sometimes it is convenient to be able to specify the exact bits of a
floating-point literal. For example, you may want to set a
floating-point register to a denormalized value, or to a particular
NaN.
In C, you can do this by combining the "{}" cast with an array
literal, like:
(gdb) p {double}{0x576488BDD2AE9FFE}
$1 = 9.8765449999999996e+112
This patch adds a somewhat similar idea to Ada. It extends the lexer
to allow "l" and "f" suffixes in a based literal. The "f" indicates a
floating-point literal, and the "l"s control the size of the
floating-point type.
Note that this differs from Ada's based real literals. I believe
those can also be used to control the bits of a floating-point value,
but they are a bit more cumbersome to use (simplest is binary but
that's also very lengthy). Also, these aren't implemented in GDB.
I chose not to allow this extension to work with based integer
literals with exponents. That didn't seem very useful.
|
