[Bug driver/86003] New: [8 Regression] GCC fails to build when configured --with-cpu=xscale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86003
Bug ID: 86003
Summary: [8 Regression] GCC fails to build when configured
--with-cpu=xscale
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: stilor at att dot net
Target Milestone: ---
Created attachment 44215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44215&action=edit
Script to reproduce the issue
I am seeing the following failure when building a crosstool-NG configuration
which configures GCC for XScale CPU. The warning is:
cc1: warning: switch -mcpu=xscale conflicts with -march=armv5te switch
But during the build of libatomic, -Werror is thrown in, so the warning becomes
an error. The failing command is:
libtool: compile:
/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/build/build-cc-gcc-final/./gcc/xgcc
-B/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/build/build-cc-gcc-final/./gcc/
-B/home/avn/x-tools/armeb-unknown-linux-uclibcgnueabi/armeb-unknown-linux-uclibcgnueabi/bin/
-B/home/avn/x-tools/armeb-unknown-linux-uclibcgnueabi/armeb-unknown-linux-uclibcgnueabi/lib/
-isystem
/home/avn/x-tools/armeb-unknown-linux-uclibcgnueabi/armeb-unknown-linux-uclibcgnueabi/include
-isystem
/home/avn/x-tools/armeb-unknown-linux-uclibcgnueabi/armeb-unknown-linux-uclibcgnueabi/sys-include
-DHAVE_CONFIG_H
-I/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/src/gcc/libatomic/config/arm
-I/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/src/gcc/libatomic/config/linux/arm
-I/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/src/gcc/libatomic/config/posix
-I/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/src/gcc/libatomic
-I. -Wall -Werror -pthread -g -O2 -g -Os -MT init.lo -MD -MP -MF .deps/init.Tpo
-c
/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/src/gcc/libatomic/config/linux/arm/init.c
-fPIC -DPIC -o .libs/init.o
A reproduction script (including the configuration for GCC and all the
prerequisites) is attached; for the sake of reducing the build time, it just
builds the GCC and runs the compiler on an empty source file.
The problem, as far as I can see, is that the driver executes cc1 with the
flags defined in
#define OPTION_DEFAULT_SPECS \
{"arch", "%{!march=*:%{!mcpu=*:-march=%(VALUE)}}" }, \
{"cpu", "%{!march=*:%{!mcpu=*:-mcpu=%(VALUE)}}" }, \
{"tune", "%{!mcpu=*:%{!mtune=*:-mtune=%(VALUE)}}" }, \
{"float", "%{!mfloat-abi=*:-mfloat-abi=%(VALUE)}" }, \
{"fpu", "%{!mfpu=*:-mfpu=%(VALUE)}"}, \
{"abi", "%{!mabi=*:-mabi=%(VALUE)}"}, \
{"mode", "%{!marm:%{!mthumb:-m%(VALUE)}}"}, \
{"tls", "%{!mtls-dialect=*:-mtls-dialect=%(VALUE)}"},
Which evaluates to:
-mcpu=xscale -mfloat-abi=soft -mtls-dialect=gnu -marm -march=armv5te
added to the arguments from the command line (there were no -march= or -mcpu=
specified explicitly in the failing command).
Then, cc1 discovers that -mcpu=xscale and -march=armv5te are not exactly
compatible:
(gdb) p arm_selected_cpu->common.isa_bits
$17 = {isa_bit_armv3m, isa_bit_mode32, isa_bit_notm, isa_bit_xscale,
isa_bit_armv4, isa_bit_armv5e, isa_bit_armv5, isa_bit_thumb, isa_nobit }
(gdb) p arm_selected_arch->common.isa_bits
$18 = {isa_bit_armv3m, isa_bit_mode32, isa_bit_notm, isa_bit_armv4,
isa_bit_armv5e, isa_bit_armv5, isa_bit_thumb, isa_nobit }
Because they differ in the presence of isa_bit_xscale (and that bit is not
listed as a quirk that's ignored during comparison), cc1 complains.
Received the following response on the mailing list [1]:
> OK, got it. Xscale isn't really an architecture in its own right, so
> having an architectural bit for is is somewhat of an anomaly. Given
> that this is only used to cause some pre-defines to occur, perhaps the
> simplest thing to do is to convert the architecture bit into a tuning
> flag. That will then avoid the conflicting state.
>
> Could you raise a bugzilla ticket please and mark it as a regression.
[1] https://gcc.gnu.org/ml/gcc-help/2018-05/msg00172.html
[Bug c/65673] Compound literal with initializer for zero-sized array drops other initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65673 --- Comment #4 from Alexey Neyman --- Any chance of this patch getting applied?
[Bug target/70718] multilib_defaults on nios2 refers to -EL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70718 --- Comment #1 from Alexey Neyman --- Ping? [trivial patch]
[Bug target/70718] New: multilib_defaults on nios2 refers to -EL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70718 Bug ID: 70718 Summary: multilib_defaults on nios2 refers to -EL Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: stilor at att dot net Target Milestone: --- Created attachment 38304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38304&action=edit Proposed fix On nios2, multilib_defaults spec refers to the -EL/-EB options, but the driver does not recognize them on nios2. Instead, the driver uses -mel/-meb (see the asm/link specs, right next to the modified multilib spec, in the attached patch).
[Bug target/80848] /crtend.o(.eh_frame); no .eh_frame_hdr table will be created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80848
Alexey Neyman changed:
What|Removed |Added
CC||stilor at att dot net
--- Comment #1 from Alexey Neyman ---
I have looked at this issue when the problem was reported in crosstool-NG
tracker [1]. The issue started with the commit 66035fd [2]; the link at [3]
explains in more detail the problem that commit tried to solve.
After that change, BFD trips over this check [4]:
724 if (hdr_length == 0)
725 {
726 /* A zero-length CIE should only be found at the end of
727 the section. */
728 REQUIRE ((bfd_size_type) (buf - ehbuf) == sec->size);
729 ENSURE_NO_RELOCS (buf);
730 sec_info->count++;
731 break;
732 }
The crtend.o generated by the build has the following in .eh_frame:
alphaev4-unknown-linux-gnu-readelf -wf
.build/alphaev4-unknown-linux-gnu/buildtools/lib/gcc/alphaev4-unknown-linux-gnu/4.8.4/crtend.o
Contents of the .eh_frame section:
ZERO terminator
0004 0010 CIE
Version: 1
Augmentation: "zR"
Code alignment factor: 4
Data alignment factor: -8
Return address column: 26
Augmentation data: 1b
DW_CFA_def_cfa_register: r30
DW_CFA_nop
0018 0024 0018 FDE cie=0004
pc=..0070
DW_CFA_advance_loc: 20 to 0014
DW_CFA_def_cfa_offset: 32
DW_CFA_advance_loc: 12 to 0020
DW_CFA_offset: r9 at cfa-24
DW_CFA_advance_loc: 8 to 0028
DW_CFA_offset: r10 at cfa-16
DW_CFA_advance_loc: 8 to 0030
DW_CFA_offset: r26 at cfa-32
DW_CFA_advance_loc: 60 to 006c
DW_CFA_restore: r10
DW_CFA_restore: r9
DW_CFA_restore: r26
DW_CFA_def_cfa_offset: 0
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
I.e., the zero terminator is indeed not the last record. GCC produces the
following assembly when compiling crtstuff.c into crtend.o (skipping irrelevant
parts):
.section.eh_frame,"a",@progbits
.align 2
.type __FRAME_END__, @object
__FRAME_END__:
.zero 4
...
__do_global_ctors_aux:
$LFB9:
.cfi_startproc
ldah $29,0($27) !gpdisp!1
lda $29,0($29) !gpdisp!1
That is, GCC generates both the explicit zero terminator as well as the CFI
instructions that make the assembler generate additional CIE/FDE records.
Adding -fno-asynchronous-unwind-tables and/or -fno-exceptions has no effect.
Adding -fno-dwarf2-cfi-insns makes GCC emit a second .eh_section fragment with
explicitly generated DWARF2 bytecode. In both cases, the result is an invalid
.eh_frame section with zero terminator record not being the last. In other
words, there is no way to prevent GCC from emitting any additional content into
the .eh_frame section, aside from the terminator.
- So, the question is, how should this be fixed?
- Was [2] a correct change to begin with?
- Should alpha (in addition to [2], or instead of [2]) implement a custom
"alpha_except_unwind_info" that will return UI_NONE if exceptions are disabled
(and then use that while compiling crtend.o)?
- Or if CFI is desired for __do_global_ctors_aux, perhaps compile this routine
separately into, say, crtend1.o; then compile the data-only section terminators
into crtend2.o; and then do a `ld -r` of both crtend[12].o into crtend.o?
[1] https://github.com/crosstool-ng/crosstool-ng/issues/719
[2]
https://github.com/gcc-mirror/gcc/commit/66035fd81f6fb8dff84e0c64d52ed041450fdebc
[3] https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01680.html
[4]
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf-eh-frame.c;h=52ba9c62138bb7d2c8901d961ba322dbfe23e220;hb=HEAD#l724
[Bug target/80848] /crtend.o(.eh_frame); no .eh_frame_hdr table will be created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80848 --- Comment #2 from Alexey Neyman --- It seems to be a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80037 that has a proposed patch.
[Bug libgcc/80037] Bad .eh_frame data in crtend.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80037 Alexey Neyman changed: What|Removed |Added CC||stilor at att dot net --- Comment #2 from Alexey Neyman --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80848 is a duplicate of this bug. I have confirmed that this patch solves that issue.
[Bug libgcc/80037] Bad .eh_frame data in crtend.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80037 --- Comment #7 from Alexey Neyman --- Can you close 80848 as a duplicate of this one?
[Bug target/79242] ICE in simplify_subreg, at simplify-rtx.c:6029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79242
Alexey Neyman changed:
What|Removed |Added
CC||stilor at att dot net
--- Comment #4 from Alexey Neyman ---
Seeing this issue with a test case as simple as:
int
reallocarray(unsigned __int20 a, unsigned __int20 b)
{
return 0xfUL / a < b;
}
This is a regression in GCC7/GCC8, GCC6 compiles it successfully. Started with
the following commit:
Author: amonakov
Date: Mon May 30 14:37:02 2016 +
match.pd: optimize unsigned mul overflow check
gcc/
2016-05-28 Alexander Monakov
Marc Glisse
PR tree-optimization/71289
* match.pd (-1 / B < A, A > -1 / B): New transformations.
gcc/testsuite/
2016-05-28 Alexander Monakov
PR tree-optimization/71289
* gcc.dg/pr71289.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@236882
138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c/65673] New: Compound literal with initializer for zero-sized array drops other initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65673
Bug ID: 65673
Summary: Compound literal with initializer for zero-sized array
drops other initializers
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stilor at att dot net
I am seeing a strange behavior when a compound initializer is used in a
structure initialization. A test case:
[[[
struct s {
int y;
unsigned long *x;
};
struct s foo = {
.y = 25,
.x = (unsigned long [SZ]){},
};
]]]
If SZ is defined to non-zero, the expected output is produced:
[[[
/tmp$ gcc -S -o- 1.c -Wall -DSZ=1
.file"1.c"
.local__compound_literal.0
.comm__compound_literal.0,8,8
.globlfoo
.data
.align 16
.typefoo, @object
.sizefoo, 16
foo:
.long25
.zero4
.quad__compound_literal.0
.ident"GCC: (Ubuntu 4.9.1-16ubuntu6) 4.9.1"
.section.note.GNU-stack,"",@progbits
]]]
If SZ is zero, the initializer for .y (".y = 25") member is dropped as well:
[[[
/tmp$ gcc -S -o- 1.c -Wall -DSZ=0
.file"1.c"
.globlfoo
.bss
.align 16
.typefoo, @object
.sizefoo, 16
foo:
.zero16
.ident"GCC: (Ubuntu 4.9.1-16ubuntu6) 4.9.1"
.section.note.GNU-stack,"",@progbits
]]]
Tested with GCC 4.6.3 and 4.9.1, both exhibit the same behavior.
With -Wextra, the code rightfully complains that the initializer for .x is
missing - but why the .y initializer is dropped even if there is no initializer
for .x?
In the mailing list, this was some discussion of this issue:
[[[
But in this case, the code attempts to create an unnanmed temporary array of
zero elements which, IMO, makes no sense. At the same time, I wouldn't expect
gcc to simply omit the initialization for foo.x. I suggest to open a gcc bug
for it.
]]]
I'd add that this was a reduced test case from a bigger aggregate type - which
was an array of such structures. When one of the elements became unused and the
size of the bitmap (which was the purpose of the compound literal initializer)
was set to zero, the whole array lost its initializers - i.e., even other
'struct s' members of the array, not just the member with a zero-sized array
compound literal.
[Bug debug/93751] New: -g1 does not do behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751 Bug ID: 93751 Summary: -g1 does not do behave per manual Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: stilor at att dot net Target Milestone: --- Reported here, https://gcc.gnu.org/ml/gcc-help/2020-02/msg00062.html; I was advised to file a bug in Bugzilla. The `-g1` option is described in the GCC manual as: Level 1 produces minimal information, enough for making backtraces in parts of the program that you don’t plan to debug. This includes descriptions of functions and external variables, and line number tables, but no information about local variables." However, GCC's behavior differs when DWARF debug format is used: `-g1` does not produce the DIEs for external variables, only for function descriptions. As I was told in the email thread above, this is also inconsistent with other debug formats (which do follow the description of the `-g1` in the manual). Easily demonstratable by compiling a simple file and feeding the object to `readelf -wi`: ``` int foo; static int bar; ``` With `-g2` or `-g`, the object file contains DIEs for both `foo` and `bar`. With `-g1`, it contains neither even though it is supposed to still have `foo`.
[Bug debug/93751] -g1 does not behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751 --- Comment #1 from Alexey Neyman --- Created attachment 47845 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47845&action=edit Patch
[Bug debug/93751] -g1 does not behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751 --- Comment #3 from Alexey Neyman --- Well, why not fix it then? :) It should be a fairly low risk change, since it does not remove any DIEs - I think it is quite unlikely that any user depends on the *absence* of DIEs. And it aligns DWARF with stabs and other formats, and with the manual. Do you see any problem with the proposed patch?
[Bug debug/93751] -g1 does not behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751
--- Comment #5 from Alexey Neyman ---
Well, that's exactly how I encountered this bug. We have some built-in
introspection in our binary and we noticed that GCC generates a lot of debug
info for local variables; the difference between -g and -g1 was ~75% decrease
in the size of the debugging information.
But it turned out that we cannot go to -g1, exactly because we need the ability
to find the addresses/locations of all exported objects - both functions and
data.
First, I am not sure that fixing a manual is a good idea: that would require
removing generation of such debug info for older formats to align with current
DWARF behavior ("-g1 makes GCC generate debug info only for functions"), which
is much likelier to break existing users which depend on it.
Also I think most typical executables have fewer exported data objects than
they do have functions (note that for functions, DIEs are generated even for
static ones, so the increase in size of the debugging info should be fairly
negligible. Users concerned about even such minor increases typically strip the
debug information from the binaries altogether.
But if the size is a concern, maybe have a finer-grained knobs for enabling
debug info? E.g.
`-gpublic-functions`
`-gpublic-data`
`-gall-functions`
`-gall-data`
`-gmacros`
and have `-gX` implemented as aliases to sets of these options? `-g1` would be
then translated to `-gall-functions -gpublic-data` (if implemented per manual)
or just `-gall-functions` (if current behavior is kept).
[Bug debug/93751] -g1 does not behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751 --- Comment #8 from Alexey Neyman --- (In reply to Eric Botcazou from comment #6) > > But it turned out that we cannot go to -g1, exactly because we need the > > ability to find the addresses/locations of all exported objects - both > > functions and data. > > Do you really need debug information for this? This is a bare-metal application that's objcopy-ed into a plain binary. So, there is no ELF symbol table available (and obviously, no libdl's interfaces either). The application also consists of several modules so the symbols in a different module are not directly accessible to this self-debugger directly (each module is linked separately with only a defined set of symbols kept visible to other modules, by running through `objcopy --keep-global-symbols). Besides, as the module in question is a minimal self-debugger, it uses the DWARF information for other purposes such as stack traces - so it is only natural to use it to locate the data structures as well. >> Also I think most typical executables have fewer exported data objects than >> they do have functions (note that for functions, DIEs are generated even for >> static ones, so the increase in size of the debugging info should be fairly >> negligible. Users concerned about even such minor increases typically strip >> the debug information from the binaries altogether. > > People use -g1 precisely because they cannot strip all the debug > information, otherwise they would just use -g0. And they don't use -g2 > because it's bloated so we must be careful not to do the same for -g1. To > sum up, I think that we would need some figures before changing a behavior > that has been there for 25 years. What I tried to say in the previous comment was that 90% of the -g2 bloat comes not from the *external* variables (which is what we discuss here) but from the *local* variables. But I concede that it is an increase, after all, even if not a big one. Hence I think we both agree that space-conscious applications are the primary consumers of -g1. It is just that in our case, we are also faced with the extreme bloat of -g2 but we need -g1 to do what it is currently described in the manual - just the function descriptions are not sufficient for us. So I propose to introduce a new option, e.g. `-gdwarf-external-variables` that will make GCC generate the DIEs for external variables. In other words: * `-g1` will keep the current behavior * `-g1 -gdwarf-external-variables` will do what the manual currently describes, which is also what we need Would that be acceptable?
[Bug debug/93751] -g1 does not behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751 Alexey Neyman changed: What|Removed |Added Attachment #47845|0 |1 is obsolete|| --- Comment #10 from Alexey Neyman --- Created attachment 47866 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47866&action=edit Patch, v2
[Bug debug/93751] -g1 does not behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751 --- Comment #11 from Alexey Neyman --- I decided to name the option `-gexternal-variables` - it seems more in-line with the existing options (which omit "dwarf" from the option name even if the option is only relevant to DWARF debugging info). Also, I decided against having a negatable option (`-gno-external-variables`) as it would lead to funny results with `-g2` or `-g3` (where we'd generate DIEs for local and static variables, but not for external ones).
[Bug debug/93751] -g1 does not behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751 --- Comment #12 from Alexey Neyman --- Patch ping.
[Bug debug/93751] -g1 does not behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751 --- Comment #14 from Alexey Neyman --- Created attachment 47930 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47930&action=edit Patch, v3 In gcc-patches, there have been three votes for generating external variables' DIEs without an additional option. Updated the patch to do that. I'd be happy to see either of v2 or v3 of the patch picked up.
[Bug debug/93751] -g1 does not behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751 Alexey Neyman changed: What|Removed |Added Attachment #47930|0 |1 is obsolete|| --- Comment #15 from Alexey Neyman --- Created attachment 47931 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47931&action=edit Patch, v3
[Bug debug/94273] [10 Regression] ICE in splice_child_die, at dwarf2out.c:5657 since r10-7235-g52b3aa8be1893848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94273
--- Comment #4 from Alexey Neyman ---
Or add a similar "return if debug level is terse" at the beginning of
`gen_type_die` - I didn't notice that in C++ it could also get called not
through the `add_type_attribute`:
```
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 89e52a41508..b0f6680bd61 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -25709,6 +25709,9 @@ gen_type_die_with_usage (tree type, dw_die_ref
context_die,
static void
gen_type_die (tree type, dw_die_ref context_die)
{
+ if (debug_info_level <= DINFO_LEVEL_TERSE)
+return;
+
if (type != error_mark_node)
{
gen_type_die_with_usage (type, context_die, DINFO_USAGE_DIR_USE);
```
I verified that it makes the attached test case compile successfully.
[Bug debug/94273] [10 Regression] ICE in splice_child_die, at dwarf2out.c:5657 since r10-7235-g52b3aa8be1893848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94273
--- Comment #7 from Alexey Neyman ---
(In reply to Richard Biener from comment #6)
> (In reply to Alexey Neyman from comment #4)
> > Or add a similar "return if debug level is terse" at the beginning of
> > `gen_type_die` - I didn't notice that in C++ it could also get called not
> > through the `add_type_attribute`:
> >
> > ```
> > diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> > index 89e52a41508..b0f6680bd61 100644
> > --- a/gcc/dwarf2out.c
> > +++ b/gcc/dwarf2out.c
> > @@ -25709,6 +25709,9 @@ gen_type_die_with_usage (tree type, dw_die_ref
> > context_die,
> > static void
> > gen_type_die (tree type, dw_die_ref context_die)
> > {
> > + if (debug_info_level <= DINFO_LEVEL_TERSE)
> > +return;
> > +
> >if (type != error_mark_node)
> > {
> >gen_type_die_with_usage (type, context_die, DINFO_USAGE_DIR_USE);
> > ```
> >
> > I verified that it makes the attached test case compile successfully.
>
> But then the static var is improperly scoped in the debug info? IMHO
> it's better left out.
First, which static variable? The test case for this PR does not have any
static vars:
```
class a {
virtual void c() {}
} extern b;
a b;
```
As to DECL_FILE_SCOPE_P check, do you mean something like this?
```
@@ -26360,7 +26365,8 @@ gen_decl_die (tree decl, tree origin, struct
vlr_context *ctx,
variable declarations or definitions unless it is external. */
if (debug_info_level < DINFO_LEVEL_TERSE
|| (debug_info_level == DINFO_LEVEL_TERSE
- && !TREE_PUBLIC (decl_or_origin)))
+ && (!TREE_PUBLIC (decl_or_origin)
+ || !DECL_FILE_SCOPE_P(decl_or_origin
break;
if (debug_info_level > DINFO_LEVEL_TERSE) {
@@ -26841,7 +26847,8 @@ dwarf2out_decl (tree decl)
variable declarations or definitions unless it is external. */
if (debug_info_level < DINFO_LEVEL_TERSE
|| (debug_info_level == DINFO_LEVEL_TERSE
- && !TREE_PUBLIC (decl)))
+ && (!TREE_PUBLIC (decl)
+ || !DECL_FILE_SCOPE_P(decl
return;
break;
```
This change doesn't resolve the ICE with that test.
I am going to attach a patch with what I suggested. Whether it is accepted, or
something different needs to be done - I don't have commit access, so somebody
else will have to commit it.
[Bug debug/94273] [10 Regression] ICE in splice_child_die, at dwarf2out.c:5657 since r10-7235-g52b3aa8be1893848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94273 --- Comment #8 from Alexey Neyman --- Created attachment 48129 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48129&action=edit Patch
[Bug middle-end/111696] New: [11/12/13/14 Regression] Spurious -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111696 Bug ID: 111696 Summary: [11/12/13/14 Regression] Spurious -Wstringop-overflow Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: stilor at att dot net Target Milestone: --- Created attachment 56052 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56052&action=edit test case The attached testcase started producing a warning beginning with commit 8d57bdadd2d9c2e5c95515ca7a583d7b407b55c4 when compiled with `-O3` (or `-O2 -ftree-slp-vectorize`). Starting with commit 2b8453c401b699ed93c085d0413ab4b5030bcdb8, vectorization is also enabled at `-O2` and the testcase starting failing at `-O2` as well. The warning can be reproduced at current HEAD (96557ee6a0a234821af865800d22621efa6e7390) as well. Failure message: $ /usr/gcc-test/bin/gcc -c -O3 -Wall -Werror stringop-overflow-bug-gcc.c stringop-overflow-bug-gcc.c: In function ‘update’: stringop-overflow-bug-gcc.c:25:3: error: writing 24 bytes into a region of size 16 [-Werror=stringop-overflow=] 25 | memcpy(&last->s, &cur.s, sizeof(struct nested)); | ^~~ stringop-overflow-bug-gcc.c:10:17: note: destination object ‘a’ of size 16 10 | unsigned long a[2]; | ^ cc1: all warnings being treated as errors $ /usr/gcc-test/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/gcc-test/bin/gcc COLLECT_LTO_WRAPPER=/usr/gcc-test/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --enable-languages=c --prefix=/usr/gcc-test --disable-bootstrap Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.1 20210303 (experimental) (GCC) The message is bogus: - the "note" points to a member inside a structure and references that member's size while memcpy has the whole structure as a destination. - commenting out any of the first two statements in the update() function removes the warning even though it has no effect on the addresses passed to memcpy().
