Age | Commit message (Collapse) | Author | Files | Lines |
|
This patch is the result of running check-include-guards.py on the
current tree. Running it a second time causes no changes.
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
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.
|
|
When building gdb with -flto -O2, I run into:
...
opcodes/mep-desc.h:250:14: warning: type 'cgen_operand_type' violates the \
C++ One Definition Rule [-Wodr]
typedef enum cgen_operand_type {
^
opcodes/or1k-desc.h:624:14: note: an enum with different value name is \
defined in another translation unit
typedef enum cgen_operand_type {
^
opcodes/mep-desc.h:212:14: warning: type 'cgen_hw_type' violates the C++ One \
Definition Rule [-Wodr]
typedef enum cgen_hw_type {
^
opcodes/or1k-desc.h:433:14: note: an enum with different value name is \
defined in another translation unit
typedef enum cgen_hw_type {
^
...
Fix this by making the conflicting type names unique, adding a target-specific
prefix using a define before the include:
...
#define cgen_operand_type <target-name>_cgen_operand_type
#define cgen_hw_type <target-name>_cgen_hw_type
#include "opcodes/<target-name>-desc.h"
...
and move those defines into a new file cgen-remap.h, similar to how that's
done for yacc in yy-remap.h.
Likewise for targets frv and lm32, the two other targets that include
opcodes/<target-name>-desc.h.
Likewise for more cgen symbols that I got the same warning for when using
-flto-partition=one.
A PR has been filed to take care of this in the opcodes dir instead (PR30758).
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/30757
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30757
|