https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508
--- Comment #18 from Mark Wielaard ---
That said, I suddenly see a fedora-ppc64le builder fail:
https://builder.sourceware.org/buildbot/#/builders/19/builds/2183
# of unexpected successes 6
Bunsen links:
https://builder.sourceware.org/tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508
--- Comment #17 from Mark Wielaard ---
(In reply to Owen A. from comment #16)
> *linked builders
What exactly are you asking for? The builder runs are linked aren't they?
They have stdout logs and through the bunsen link you can find full .sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508
--- Comment #14 from Mark Wielaard ---
https://builder.sourceware.org/buildbot/#/builders?tags=gccrust
Little endian gccrust-debian-i386 gccrust-fedora-arm64 gccrust-fedora-ppc64le
gccrust-fedora-x86_64 seems green
Big endian gccrust-debian-pp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508
Mark Wielaard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508
Mark Wielaard changed:
What|Removed |Added
Last reconfirmed||2025-04-04
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119227
--- Comment #15 from Mark Wielaard ---
(In reply to James K. Lowden from comment #14)
> (In reply to Mark Wielaard from comment #13)
> > But it isn't clear from the logs if or where the cobol docs are generated
> > now.
>
> I'm not sure how to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119227
--- Comment #13 from Mark Wielaard ---
(In reply to James K. Lowden from comment #12)
> The inability to create a PDF from groff suggests an old version is
> installed. The PDF driver was introduced with version 1.22
> (https://lists.gnu.org/ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119227
--- Comment #11 from Mark Wielaard ---
The online docs seem to be build again now, but I don't know if the new cobol
docs actually get generated (or where they end up).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119227
--- Comment #10 from Mark Wielaard ---
And fche install groff-perl which should contain the tmac.pdf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119227
--- Comment #8 from Mark Wielaard ---
Installed groff from codeready-builder-for-rhel-8-x86_64-rpms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119227
--- Comment #7 from Mark Wielaard ---
(In reply to David Malcolm from comment #6)
> Sorry if this comes across as blunt, but pushing changes and waiting for a
> cronjob to run (in production) seems very 1990s.
>
> Is there some automated way to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119227
Mark Wielaard changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119227
--- Comment #4 from Mark Wielaard ---
mandoc-1.14.5-13.el8.x86_64 is now installed
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
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org, law at gcc dot gnu.org,
palmer at gcc dot gnu.org, sjames at gcc dot gnu.org,
vmakarov at gcc dot gnu.org
Target
|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
1 - 100 of 303 matches
Mail list logo
