|NEW
Last reconfirmed||2024-10-27
CC||mark at gcc dot gnu.org
--- Comment #2 from Mark Wielaard ---
The gcc-full-fedora-riscv buildbot has been red for several days now:
https://builder.sourceware.org/buildbot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945
--- Comment #13 from Mark Wielaard ---
(In reply to Eric Botcazou from comment #12)
> Unlike the C and C++ standards, the Ada standard is freely available at:
> http://www.ada-auth.org/standards/22rm/html/RM-TTL.html
> and the 'Valid attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117039
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945
--- Comment #9 from Mark Wielaard ---
Re comment #4. Sam reports that --expensive-definedness-checks=yes doesn't work
in this case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945
--- Comment #8 from Mark Wielaard ---
(In reply to Eric Botcazou from comment #7)
> > Sure. But I assume the unitialized part isn't accessed when resolving the
> > 'Valid attribute. Does checking for the 'Valid attribute depend on any
> > uninit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945
--- Comment #6 from Mark Wielaard ---
(In reply to Eric Botcazou from comment #5)
> > What code is generated for that call to 'Valid in "if
> > Indexed_Assoc.Gen_Id'Valid then". Does that conditional really depend on
> > uninitialized data?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945
--- Comment #4 from Mark Wielaard ---
Also does running valgrind memcheck with --expensive-definedness-checks=yes
help?
--expensive-definedness-checks= [default: auto]
Controls whether Memcheck should employ more precise but also more
exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945
--- Comment #3 from Mark Wielaard ---
What code is generated for that call to 'Valid in "if
Indexed_Assoc.Gen_Id'Valid then". Does that conditional really depend on
uninitialized data?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116947
--- Comment #3 from Mark Wielaard ---
Does --enable-checking=valgrind imply --enable-valgrind-annotations ?
If not I would enable --error-exitcode=99 only if --enable-valgrind-annotations
is also given (to avoid erroring out on false positives).
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rust
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org,
pierre-emmanuel.patry a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #7 from Mark Wielaard ---
You could try --expensive-definedness-checks=yes
--expensive-definedness-checks= [default: auto]
Controls whether Memcheck should employ more precise but also more
expensive (ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
Mark Wielaard changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #26 from Mark Wielaard ---
With gcc-15-2791-g2083389a18d native build of the preprocessed insn-emit-96.cc
from attachment #1 goes from 6 hours to 5 minutes.
Time variable usr sys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116152
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #12 from Mark Wielaard ---
(In reply to Andreas Schwab from comment #11)
> You can add target-specific flags like this:
>
> $(INSNEMIT_SEQ_O): ALL_COMPILERFLAGS += -fno-tree-dominator-opts
Thanks. With "$(GIMPLE_MATCH_PD_SEQ_O) $(I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #10 from Mark Wielaard ---
(In reply to Andrew Macleod from comment #7)
> Meanwhile the "workaround" might be to use '-fno-tree-dominator-opts'
That reduces the compile time from hours to just 15 minutes!
Still trying to figure out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #4 from Mark Wielaard ---
(In reply to Richard Biener from comment #3)
> There's another PR where DOM shows up via ranger also at -O1 - does -O1 help
> here?
No. With -O2 it took 6 hours for that file to compile. With -O1 it is stil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #2 from Mark Wielaard ---
Time variable usr sys wall
GGC
phase setup: 0.10 ( 0%) 0.00 ( 0%) 0.11 ( 0%)
2844k ( 0%)
phase parsing
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
Created attachment 58789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58789&action=edit
preprocessed insn-emit-96.cc
Compiling on risc-v th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116146
--- Comment #4 from Mark Wielaard ---
(In reply to Robin Dapp from comment #3)
> On riscv insn-output is the largest file right now as well.
Note that size matters, but the largest file does not always take the longest
to compile. On a risc-v s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #35 from Mark Wielaard ---
(In reply to GCC Commits from comment #28)
> The master branch has been updated by Robin Dapp :
>
> https://gcc.gnu.org/g:184378027e92f51e02d3649e0ca523f487fd2810
>
> commit r14-5034-g184378027e92f51e02d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115453
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment
||mark at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #9 from Mark Wielaard ---
10.1 is long since released
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=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=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
--partial-lo
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 #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 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473
Mark Wielaard changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #7 from Mark Wielaa
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"
||mark at gcc dot gnu.org
Last reconfirmed||2023-11-20
Status|UNCONFIRMED |NEW
--- Comment #3 from Mark Wielaard ---
Have those patches been upstreamed?
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=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:/
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 ht
: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
gcc (GCC) 13.0.1 20230117 (Red Hat 13.0.1-0)
$ echo "int main () {}" | gcc -xc -gz=none -
gcc: error: -gz=z
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=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=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 s
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=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=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=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=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 an
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 -I.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442
Mark Wielaard changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #1
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=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 | SECT
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 fo
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=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=98875
--- Comment #5 from Mark Wielaard ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565587.html
dot gnu.org |mark at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2021-02-19
Component|debug |web
--- Comment #4 from Mark Wielaard ---
(In reply to Paul Clarke from comment #3)
>
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=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" (the
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== U
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 #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 is
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 related
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.
> H
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=98755
Mark Wielaard changed:
What|Removed |Added
Build|powerpc64*-linux-gnu|
Target|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=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=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 new
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 b3test_dwz_common.
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 tha
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=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
+++ b/gas/dwarf
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
'/^_*_ZTISt13__ios_failure:/,/_ZTVN10__cxxabiv120__s
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 dwarf2out_fi
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://sourceware.org/bin
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 et
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
> muc
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=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=95188
--- Comment #10 from Mark Wielaard ---
Created attachment 49293
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49293&action=edit
supergraph
> Mark: please can you add -fdump-analyzer-supergraph to the arguments and
> attach > the bzip2.c.
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&action=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 #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
bzip2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #8 from Mark Wielaard ---
Note that VEX/priv/guest_arm64_toIR.c is fairly big (1.2M):
$ wc VEX/priv/guest_amd64_toIR.c
32655 127564 1189783 VEX/priv/guest_amd64_toIR.c
(but still less than 2^15 lines)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #7 from Mark Wielaard ---
Note that the above is in ./install/lib/valgrind/memcheck-amd64-linux
Which has .debug_line entries like:
[0x00098404] Set is_stmt to 0
[0x00098405] Advance PC by constant 17 to 0x5809993c
[0x000984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #6 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #5)
> I can no longer replicate the issue of the bad line numbers with gcc (GCC)
> 10.1.1 20200507 (Red Hat 10.1.1-1) on fedora 32. With either 3.15.0 or
> current valg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96328
--- Comment #6 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 48931 [details]
> gcc11-pr96328-alt.patch
>
> If you want, we could call the safe_previous_token also in the other spot,
> while we don't have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96328
--- Comment #4 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 48930 [details]
> gcc11-pr96328.patch
>
> I wrote this for it (the first hunk is similar).
Yours is nicer because it fixes just the specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96328
Mark Wielaard changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Mark Wielaa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611
--- Comment #7 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #6)
> Sorry, commented on the wrong bug, the above was meant for bug #93865
Groan, I seem very confused today. That comment was fine. It was me who got
confused becaus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611
--- Comment #6 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #5)
> This is also one of the issues that prevent elfutils to build with LTO.
> The workaround is to compile with -Wno-error=stack-usage= added to CFLAGS:
> https://sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
--- Comment #2 from Mark Wielaard ---
This also impacts rpm (find-debuginfo.sh) when it tries to extract the source
files from binaries compiled with LTO enabled:
https://github.com/rpm-software-management/rpm/issues/1207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47819
Mark Wielaard changed:
What|Removed |Added
Depends on||88389, 88878, 93117, 91794,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47819
--- Comment #4 from Mark Wielaard ---
The following bugs might be added to this meta-bug. But they seemed not very
urgent because they involve non-default -g/-f debug flags:
- -flto -g -gsplit-dwarf is broken
https://gcc.gnu.org/bugzilla/show_bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
Mark Wielaard changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Mark Wielaard -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78871
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #8
||mark at gcc dot gnu.org
Blocks||47819
Last reconfirmed||2020-07-16
Status|UNCONFIRMED |NEW
--- Comment #1 from Mark Wielaard ---
Replicated. With -flto added the result is a linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58528
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #10
1 - 100 of 271 matches
Mail list logo
