https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
--- Comment #12 from Mark Wielaard ---
(In reply to David Malcolm from comment #11)
> (In reply to Mark Wielaard from comment #10)
> > Created attachment 49293 [details]
> > supergraph
>
> Thanks. Compared to my testing, I'm seeing what appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355
--- Comment #11 from Mark Wielaard ---
I don't understand why the .debug sections are compared in this case.
But if they are then the diff comes from this gas issue:
https://sourceware.org/bugzilla/show_bug.cgi?id=26740
Even though unused gas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355
--- Comment #15 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #14)
> In any case, the change to use -gdwarf-* by default even when not compiling
> just assembly was based on the assumption that gas would in that case pretty
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
--- Comment #4 from Mark Wielaard ---
Note that I can replicate it with the instructions in the description and gcc
git: gcc (GCC) 11.0.0 20200916 (experimental)
$ /opt/local/install/gcc/bin/gcc -g -O2 -fanalyzer -c bzip2.c 2>&1 | head -25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
--- Comment #6 from Mark Wielaard ---
Created attachment 49291
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49291=edit
Output for gcc -Wanalyzer-too-complex -g -O2 -fanalyzer -c bzip2.c
(In reply to David Malcolm from comment #5)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
--- Comment #10 from Mark Wielaard ---
Created attachment 49293
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49293=edit
supergraph
> Mark: please can you add -fdump-analyzer-supergraph to the arguments and
> attach > the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97541
--- Comment #5 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #4)
> # 82 "s-atocou.adb" 1
> isn't a .file assignment though.
> As I said earlier, if we don't want to revert the r11-3693 change and be
> able to specify -gdwarf-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728
Mark Wielaard changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728
--- Comment #2 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #1)
> Maybe this bug should be split in two (or three) for each specific FAIL?
>
> (In reply to Rainer Orth from comment #0)
> > With the switch to DWARF-5, two debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98755
Mark Wielaard changed:
What|Removed |Added
Build|powerpc64*-linux-gnu|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728
Mark Wielaard changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98708
--- Comment #8 from Mark Wielaard ---
I am not sure where the -g -O2 -g0 comes from. I must have missed this in my
testing.
The issue is the .file 0 directive, which is special to gas (only valid with
-gdwarf-5).
It is generated by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98708
--- Comment #11 from Mark Wielaard ---
Aha, now I see in libstdc++-v3/src/c++11/Makefile.am:
if ENABLE_DUAL_ABI
# Rewrite the type info for __ios_failure.
rewrite_ios_failure_typeinfo = sed -e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98708
--- Comment #12 from Mark Wielaard ---
On the binutils gas side it could be as simple as turning the error into a
warning:
diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
index a428370ecca..a216bfd6b28 100644
--- a/gas/dwarf2dbg.c
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716
--- Comment #7 from Mark Wielaard ---
(In reply to Ian Lance Taylor from comment #5)
> I'm not seeing any failures in the Go testsuite with GNU binutils 2.35.1.
> Anybody know what changed in newer version of the binutils?
The difference is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716
--- Comment #8 from Mark Wielaard ---
(In reply to Ian Lance Taylor from comment #6)
> On the other hand the libbacktrace testsuite now fails when using dwz
> 0.13+20201015-2. But I guess that is not a GCC problem.
>
> dwz -m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716
--- Comment #9 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #7)
> (In reply to Ian Lance Taylor from comment #5)
> > I'm not seeing any failures in the Go testsuite with GNU binutils 2.35.1.
> > Anybody know what changed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #45 from Mark Wielaard ---
Note that the hack in comment 43 doesn't really work with elfutils since the
.symver attribute doesn't work exactly like the assembly construct with @@@.
The @@@ symver variant see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #13 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #12)
> For valgrind, the quick workaround would be -march=z13 when compiling the
> s390x tests that have register long double variables.
Yes, this works, if fpext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #11 from Mark Wielaard ---
BTW. Disabling that test in valgrind produces another crash in another test
that looks similar:
gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -I../../../include
-I../../../coregrind -I../../../include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #10 from Mark Wielaard ---
(In reply to Will Schmidt from comment #9)
> (In reply to Segher Boessenkool from comment #5)
> > Have you tried a new valgrind?
> >
> > Either this is (or was) a known problem in valgrind, or it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #12 from Mark Wielaard ---
OK, so according to memcheck the load uses a pointer value that isn't
initialized properly. And it thinks that value originated from a stack value in
the isVariable call. Unfortunately my powerpc assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #13 from Mark Wielaard ---
I could replicate this with gcc 9.1.1 with the following source:
#define variables (const char* []){ "PK", "KEK", "db"}
int ret, len;
void isVariable(char *var)
{
for (int v = 0; v < 2; v++)
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #17 from Mark Wielaard ---
Thanks for the step-by-step explanation of the assembly instructions and
calling conventions.
(In reply to Segher Boessenkool from comment #16)
> (In reply to Mark Wielaard from comment #13)
> > ==25741==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #18 from Mark Wielaard ---
The current thinking (Julian did the thinking, I am just repeating) is that
this is caused by the way the _savegpr and/or restgpr functions return using
blr.
PPC has two special "lets zap the red zone"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811
--- Comment #3 from Mark Wielaard ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> If the DWARF-5 support depends on specific binutils versions/patches to
> work, this should both be documented and detected at configure time.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811
--- Comment #1 from Mark Wielaard ---
(In reply to Rainer Orth from comment #0)
> However, when I switched to
> the freshly released GNU as 2.36 today, the error vanished everywhere.
Which GNU as were you using before? There were some bug fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490
--- Comment #5 from Mark Wielaard ---
I don't believe it is a requirement to generate a separate .debug_rnglists.dwo
section, the spec says the same data can be provided in the .debug_rnglists
section and gdb and elfutils handle that just fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488
--- Comment #3 from Mark Wielaard ---
So gcc/dwarf2out.c creates it as:
#define DEBUG_STR_SECTION_FLAGS \
(HAVE_GAS_SHF_MERGE && flag_merge_debug_strings \
? SECTION_DEBUG | SECTION_MERGE |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488
--- Comment #8 from Mark Wielaard ---
On Mon, 2021-03-15 at 12:21 +, jakub at gcc dot gnu.org wrote:
> --- Comment #7 from Jakub Jelinek ---
> [43] .debug_line_str MIPS_DWARF ecf07bf 0066e6 01
> MS
> 0 0 1
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442
Mark Wielaard changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875
Mark Wielaard changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875
Mark Wielaard changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875
--- Comment #5 from Mark Wielaard ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565587.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178
--- Comment #3 from Mark Wielaard ---
So if the compiler would emit the .debug_name index would that make any
link/post-processing steps easier or more efficient?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19753
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44415
Bug 44415 depends on bug 39747, which changed state.
Bug 39747 Summary: Installation documentation should suggest building libgmp as
PIC for building with libjava
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104463
Mark Wielaard changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088
--- Comment #11 from Mark Wielaard ---
I believe the intention of the DWARF5 spec as that dir entry zero would be
equal to the comp_dir attribute of the CU and file entry zero would be equal to
the name attribute of the CU.
Also, although the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #4 from Mark Wielaard ---
The content of attachment 53775 has been deleted for the following reason:
https://sourceware.org/pipermail/overseers/2022q4/019048.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
--- Comment #7 from Mark Wielaard ---
The content of attachment 53773 has been deleted for the following reason:
https://sourceware.org/pipermail/overseers/2022q4/019048.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #25 from Mark Wielaard ---
Note that elfutils-0.187 builds fine for me on fedora x86_64 with either:
gcc (GCC) 12.2.1 20220819 (Red Hat 12.2.1-2)
So this might have been fixed since 12.2.0?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108572
Bug ID: 108572
Summary: -gz=none produces gcc: error: -gz=zstd is not
supported in this configuration
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #6 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #5)
> So, I wonder if we just shouldn't ask for a DWARF 6 extension here, have
> some way for the compiler to specify DW_AT_location for the return value.
There is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110147
Mark Wielaard changed:
What|Removed |Added
Last reconfirmed||2023-06-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #24 from Mark Wielaard ---
(In reply to Eric Gallager from comment #23)
> (In reply to Mark Wielaard from comment #22)
> > (In reply to Eric Gallager from comment #21)
> > > (In reply to Mark Wielaard from comment #20)
> > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #19 from Mark Wielaard ---
(In reply to David Binderman from comment #18)
> (In reply to Mark Wielaard from comment #17)
> > I am surprised valgrind memcheck doesn't produce more output, normally it
> > would tell you why & where it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #25 from Mark Wielaard ---
Note comment #16 which explains that valgrind seems to translate this large
read into smaller chunks. Which most likely causes memcheck to flag the (last)
8 bytes read as fully invalid. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #17 from Mark Wielaard ---
I am surprised valgrind memcheck doesn't produce more output, normally it would
tell you why & where it found the address invalid. I assume somehow valgrind
memcheck believes it is reading past the end of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473
--- Comment #6 from Mark Wielaard ---
Also looking at f944c5b2a894f866fc50e06ba90fb5dbd902ba36 "Bug 1167919: See
Also: support debbugs.gnu.org tracker"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473
Mark Wielaard changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #7 from Mark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473
Mark Wielaard changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114223
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78100
Mark Wielaard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507
Mark Wielaard changed:
What|Removed |Added
CC||gccbugs at dima dot
secretsauce.ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
60 matches
Mail list logo
