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
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
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
--- 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://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
: 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
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
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
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=92442
Mark Wielaard changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment
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 |
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=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"
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 #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
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=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=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=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
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 #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=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
+++
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 #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=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=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=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=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=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=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 #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=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
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
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
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
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
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://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_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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54734
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #19
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
Reproducer:
wget https://sourceware.org/ftp/bzip2/bzip2-1.0.8.tar.gz
tar zxf bzip2-1.0.8.tar.gz
cd bzip2
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.0.1 20200430 (Red Hat 10.0.1-0.13)
This is the build of elfutils libelf with both -flto and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #43 from Mark Wielaard ---
It looks there is now some support for a symver function attribute. But it only
accepts the single and double @ forms. This makes things a little awkward when
using a symbol foo itself for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #3 from Mark Wielaard ---
(In reply to Richard Biener from comment #1)
> Err, but isn't this interpreting the dwarf from 'date'? So doesn't this
> mean that valgrind is "miscompiled" with --enable-lto rather than wrong
> debug?
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93608
--- Comment #3 from Mark Wielaard ---
(In reply to Ian Lance Taylor from comment #2)
> It looks like this would mean that libbacktrace needs an lzma decompressor.
> This is probably doable but is probably non-trivial. At least it doesn't
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93608
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517
--- Comment #6 from Mark Wielaard ---
(In reply to Christian Biesinger from comment #5)
> Using binutils from a month ago or so, this does not crash but also does not
> demangle...
Could you be slightly more specific?
Which symbol produced by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90981
--- Comment #6 from Mark Wielaard ---
Author: mark
Date: Wed Jul 3 13:08:01 2019
New Revision: 273008
URL: https://gcc.gnu.org/viewcvs?rev=273008=gcc=rev
Log:
PR debug/90981 Empty .debug_addr crashes -gdwarf-5 -gsplit-dwarf
Even if there was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90981
Mark Wielaard changed:
What|Removed |Added
Component|c++ |debug
--- Comment #5 from Mark Wielaard
at gcc dot gnu.org |mark at gcc dot gnu.org
--- Comment #4 from Mark Wielaard ---
Created attachment 46518
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46518=edit
Don't emit debug_addr attribute or addr index if there is no addr table.
Testing the following patch that makes sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90981
--- Comment #3 from Mark Wielaard ---
(In reply to Martin Liška from comment #2)
> Btw. started with r259743.
Thanks. So that is mine:
commit ac7a2c61cf2ae7fcc948724ae179ac812c12186a
Author: mark
Date: Sat Apr 28 19:54:08 2018 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #22 from Mark Wielaard ---
(In reply to Eric Gallager from comment #21)
> (In reply to Mark Wielaard from comment #20)
> > https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02055.html
>
> Did this make it in? If not, have you pinged it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #17 from Mark Wielaard ---
(In reply to Martin Sebor from comment #16)
> The warning has been relaxed for GCC 9 in r269125.
Thanks, I can confirm elfutils builds fine without warnings with GCC 9 now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #14 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #12)
> (In reply to Martin Sebor from comment #11)
> > Ah, but you mentioned elfutilts, not binutils. I've now downloaded and
> > built elfutils-0.175. It took a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #12 from Mark Wielaard ---
(In reply to Martin Sebor from comment #11)
> Ah, but you mentioned elfutilts, not binutils. I've now downloaded and
> built elfutils-0.175. It took a bit more effort because --disable-werror
> doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #9 from Mark Wielaard ---
(In reply to Martin Sebor from comment #8)
> The patch I posted for the related pr88993 also relaxes this warning for
> printf and fprintf: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00224.html
>
> Like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #7 from Mark Wielaard ---
Is this a regression that will probably be fixed for GCC 9.1 or should we be
adding workaround to the code.
Currently elfutils won't build on distros that started using the GCC 9.0
prerelease on 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #20 from Mark Wielaard ---
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02055.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #19 from Mark Wielaard ---
I think we are just talking past each other because we don't fully agree when
the warning should trigger and whether it is (trivial and/or) desirable to
avoid that specific corner case.
We do agree that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #17 from Mark Wielaard ---
(In reply to Segher Boessenkool from comment #16)
> Something as trivial as this
>
> ===
> void h(int (*)(void));
> void f(int x)
> {
> int g(void) { return x; }
> h(g);
> }
> ===
>
> will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #15 from Mark Wielaard ---
(In reply to Segher Boessenkool from comment #14)
> It is very hard to avoid the warning if you use this feature (you need to
> stop using the feature altogether!), which would disqualify it for -Wall
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #13 from Mark Wielaard ---
(In reply to Segher Boessenkool from comment #12)
> Requiring everything on the stack to always be executable, while normally it
> is
> not, is an issue, sure.
>
> Requiring the stack to be executable when
1 - 100 of 246 matches
Mail list logo
