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>
|
|
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.
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
|
|
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
This is the fortran part of the patch, including tests, which
are essentially unchanged from Siddhesh's original 2012 submission:
https://sourceware.org/ml/gdb-patches/2012-08/msg00562.html
There is, however, one large departure. In the above thread,
Jan pointed out problems with GCC debuginfo for -m32 builds
(filed usptream as gcc/54934). After investigating the issue,
I am dropping the hand-tweaked assembler source file to workaround
this case.
While I would normally do something to accommodate this, in
this case, given the ubiquity of 64-bit systems today (where
the tests pass) and the apparent lack of urgency on the compiler
side (by users), I don't think the additional complexity and
maintenance costs are worth it. It will be very routinely tested
on 64-bit systems. [For example, at Red Hat, we always
test -m64 and -m32 configurations for all GDB releases.]
gdb/ChangeLog:
From Siddhesh Poyarekar:
* f-lang.h (f77_get_upperbound): Return LONGEST.
(f77_get_lowerbound): Likewise.
* f-typeprint.c (f_type_print_varspec_suffix): Expand
UPPER_BOUND and LOWER_BOUND to LONGEST. Use plongest to format
print them.
(f_type_print_base): Expand UPPER_BOUND to LONGEST. Use
plongest to format print it.
* f-valprint.c (f77_get_lowerbound): Return LONGEST.
(f77_get_upperbound): Likewise.
(f77_get_dynamic_length_of_aggregate): Expand UPPER_BOUND,
LOWER_BOUND to LONGEST.
(f77_create_arrayprint_offset_tbl): Likewise.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-bounds.exp: New file.
* gdb.fortran/array-bounds.f90: New file.
|