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
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
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 i
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/dwarf2ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751
Alexey Neyman changed:
What|Removed |Added
Attachment #47930|0 |1
is obsolete|
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 addit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751
--- Comment #12 from Alexey Neyman ---
Patch ping.
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).
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751
Alexey Neyman changed:
What|Removed |Added
Attachment #47845|0 |1
is obsolete|
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
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
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 s
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
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
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 issu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65673
--- Comment #4 from Alexey Neyman ---
Any chance of this patch getting applied?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79242
Alexey Neyman changed:
What|Removed |Added
CC||stilor at att dot net
--- Comment #4
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80037
Alexey Neyman changed:
What|Removed |Added
CC||stilor at att dot net
--- Comment #2
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80848
Alexey Neyman changed:
What|Removed |Added
CC||stilor at att dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70718
--- Comment #1 from Alexey Neyman ---
Ping? [trivial patch]
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,
: 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
24 matches
Mail list logo
