https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118353
--- Comment #5 from Mark Wielaard ---
One difference might be how many cores are used for the builds.
The more cores how more sensitive they are for parallelism bottlenecks.
And riscv (was) kind of special in that there were just a handful of f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
Bug 84402 depends on bug 118032, which changed state.
Bug 118032 Summary: [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
Mark Wielaard changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
Bug 111600 depends on bug 116166, which changed state.
Bug 116166 Summary: [13 Regression] risc-v (last) insn-emit-nn.c build takes
hours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
Mark Wielaard changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #35 from Mark Wielaard ---
Shall we close this bug or keep it open for implementing greedy switch
clustering for jump tables as suggested in comment #29 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #34 from Mark Wielaard ---
After r15-6598-g668cad04b16fc044142474232ac072fcc5f94433
("tree-switch-conversion: don't apply switch size limit on jump tables") the
build speeds up considerably:
https://builder.sourceware.org/buildbot/#/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #32 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #31)
> (In reply to Filip Kastl from comment #30)
> > (In reply to Mark Wielaard from comment #28)
> > > I haven't tried yet, but do you mean something like the follo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #31 from Mark Wielaard ---
(In reply to Filip Kastl from comment #30)
> (In reply to Mark Wielaard from comment #28)
> > I haven't tried yet, but do you mean something like the following?
> > - /* Note: l + 1 is the number of cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #28 from Mark Wielaard ---
(In reply to Filip Kastl from comment #24)
> One way to fix this would be to not apply the switch size limit on jump
> tables. Since finding jump tables is at least O(n^2), this could
> theoretically cause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #26 from Mark Wielaard ---
(In reply to Andreas Schwab from comment #25)
> 20241220: 2d 06:58:23
That seems like a nice speedup. Do you know what caused that?
Is the because r15-6223-g6dcfe8743134936db17ffdfd0a5102a87338f494 ("genre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #23 from Mark Wielaard ---
Created attachment 59930
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59930&action=edit
preprocessed -E output of generated insn-attrtab.cc
Note that the generated insn-attrtab.cc file is 10M.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #21 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #14)
> After about 20~25 minutes only insn-attrtab.cc is left (all other files
> mentioned in comment #13 have compiled successfully).
>
> /home/builder/worker/gcc-f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #15 from Robin Dapp ---
> Based on earlier builds this file will take 2.5 to 3 hours to build (while
> all other cores are idle).
insn-attrtab.c doesn't consist of many functions so a split won't help. Given
that we have a number o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #14 from Mark Wielaard ---
After about 20~25 minutes only insn-attrtab.cc is left (all other files
mentioned in comment #13 have compiled successfully).
/home/builder/worker/gcc-full-fedora-riscv/gcc-build/./prev-gcc/cc1plus -quiet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #13 from Mark Wielaard ---
Just looking at a current build there are a couple of files that take 10+
minutes to build while nothing else is building:
gimple-match-10.cc
gimple-match-91.cc
insn-opinit.cc
lto-lang.cc
insn-attrtab.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #33 from Mark Wielaard ---
(In reply to Robin Dapp from comment #32)
> With insn-recog split, is this still relevant or can we close it?
I think it is not relevant anymore, but I haven't been able to verify yet.
The current compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #4 from Mark Wielaard ---
The slowdown is on the pioneer box, which has 64 cores and 128GB ram.
https://builder.sourceware.org/buildbot/#/builders/gcc-full-fedora-riscv
See the build times tab on that page.
It used to do builds in 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
Bug ID: 118032
Summary: Bootstrap slowdown for risc-v
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117316
Mark Wielaard changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116561
Bug ID: 116561
Summary: gcc/testsuite/rust/execute/torture/iter1.rs:350:5:
internal compiler error: 'verify_gimple' failed
Product: gcc
Version: unknown
Status: UNCONFIR
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
Bug ID: 116166
Summary: risc-v (last) insn-emit-nn.c build takes hours
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
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 #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
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"
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=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
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=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
Stat
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 f
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875
Mark Wielaard changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc d
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 f
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)
1 - 100 of 101 matches
Mail list logo
