https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-03-17
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
Martin Liška changed:
What|Removed |Added
Summary|[8/9/10/11 REGRESSION] |[8/9/10/11 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99620
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #5 from William Bader ---
`gcc -S -m32 -O2 bfinal-format.c` with Fedora 32 gcc 10.2.1 gives a section
similar to one in my first comment. In particular, it calls fucomi "floating
unordered compare of st(0) and st(i)" and then fstp "fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99620
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #6 from Jakub Jelinek ---
fucomi sets %eflags in addition to some effects on c[0-3] in FPU flags, fstp
has some effects on c[0-3] in FPU flags. Nothing in the program really cares
about the FPU flags.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #7 from William Bader ---
>Are you sure this just isn't an excess precision problem in all the floating
>point calculations?
I am pretty sure that it isn't a precision problem because the original program
is parsing numbers from po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #8 from William Bader ---
Created attachment 50404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50404&action=edit
example program before creduce
This is the example that I cut from a much larger module. The problematic area
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #9 from Martin Liška ---
(In reply to William Bader from comment #8)
> Created attachment 50404 [details]
> example program before creduce
I modified the file to:
find_ad_image_breaks("123", "4329652-1.eps", 0, 0, &breaks_blob,
bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #10 from William Bader ---
The program before creduce has debug code. Setting the variable to print the
debug code makes the program work. Usually for something like this, I would put
in debug code and see where the good and bad versi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #11 from Martin Liška ---
(In reply to William Bader from comment #10)
> The program before creduce has debug code. Setting the variable to print the
> debug code makes the program work.
Can you please attach a version that works wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #12 from William Bader ---
>I modified the file to:
Sorry about that. I hadn't originally intended to post that file, and I forgot
to clean it up.
>len 9, unknown bad
That means that the data file isn't valid. I posted a binary fil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
Martin Liška changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #13 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93964
--- Comment #5 from CVS Commits ---
The releases/gcc-9 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:bb0ec9cffb1d0a3326d8c4ed197717fc08eeec37
commit r9-9287-gbb0ec9cffb1d0a3326d8c4ed197717fc08eeec37
Author: Richard Biener
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98117
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:4db478784807708c031a77ae11850529fa5ecff1
commit r9-9288-g4db478784807708c031a77ae11850529fa5ecff1
Author: Richard Biener
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #14 from William Bader ---
>It seems you attached a different file then:
Sorry. I was testing how the 9 result came out, and I put in a small file. I've
been up all night. It is 9:30am my time.
This is the real file. It looks like i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98282
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:9bb84bd30dcfcdc12f69b148d4dcf8f2e3fe8046
commit r9-9289-g9bb84bd30dcfcdc12f69b148d4dcf8f2e3fe8046
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98758
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:396cc56368a68d25456ea5a29c24069e46ae5f46
commit r9-9290-g396cc56368a68d25456ea5a29c24069e46ae5f46
Author: Richard Biener
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98891
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98758
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #15 from Martin Liška ---
> This is the real file. It looks like it matches your file.
Good. But then my comment 9 is still and I cannot reproduce your problem..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98891
--- Comment #2 from Jakub Jelinek ---
E.g. x86_64 (both -m32 and -m64) keeps the double-word logicals in the IL, then
has its machine dependent stv pass that promotes some sets of operations into
SIMD ones and finally (admittedly, clearly too lat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #16 from William Bader ---
Is your pr99621-2.c somewhere that I can look at it?
I tried downloading all of the attachments, and it all works for me, on my
Fedora 32 laptop and on a CentOS 6 test server.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #17 from Martin Liška ---
(In reply to William Bader from comment #16)
> Is your pr99621-2.c somewhere that I can look at it?
Sure, it's here:
https://gist.githubusercontent.com/marxin/21562b2795430152de5a18ee89fc4e89/raw/5ffbcfb5d7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #18 from William Bader ---
Created attachment 50405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50405&action=edit
the example program with the binary string constant replaced
Thanks for posting it. Your copy of the example C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #19 from Martin Liška --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99296
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #20 from Jakub Jelinek ---
I'd say before reducing, it would be nice to see what is and is not inlined and
see which function is problematic (e.g. by trying different optimize
attributes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #21 from Martin Liška ---
All right, I think it's a well-known problem called X87 FP unit.
The test-case is fixed with:
$ gcc pr99621-3.c -O2 -m32 && ./a.out
len 5167, expected bad
$ gcc pr99621-3.c -O2 -m32 -ffloat-store && ./a.out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99296
--- Comment #4 from Jakub Jelinek ---
Or perhaps better use as the condition whether type_range.upper_bound () is
zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #23 from Jakub Jelinek ---
Which is why I was talking about excess precision, depending on the
optimizations if something needs to be spilled from the FPU stack where it is
computed in 80-bit precision to stack where the spilling then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94479
--- Comment #13 from CVS Commits ---
The releases/gcc-8 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:27b298a840e5046ac8a8e045b580128a88d25c44
commit r8-10799-g27b298a840e5046ac8a8e045b580128a88d25c44
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98282
--- Comment #13 from CVS Commits ---
The releases/gcc-8 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:55bac5c2824dcb4bdae5b309b2b2a26703f273f0
commit r8-10800-g55bac5c2824dcb4bdae5b309b2b2a26703f273f0
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97081
--- Comment #13 from CVS Commits ---
The releases/gcc-8 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:16e2f38167eb90a4dc977b806dcc0dc9011cc456
commit r8-10801-g16e2f38167eb90a4dc977b806dcc0dc9011cc456
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97081
--- Comment #14 from CVS Commits ---
The releases/gcc-8 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:e407585a3ae48a25f031450565cf2b657d431cee
commit r8-10802-ge407585a3ae48a25f031450565cf2b657d431cee
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97081
Richard Biener changed:
What|Removed |Added
Known to work||8.4.1
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94479
Richard Biener changed:
What|Removed |Added
Known to work||8.4.1
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98282
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #24 from William Bader ---
Jakub was right. I didn't understand what he meant at first. Sorry about that.
I can confirm `gcc -m32 -O9 -fexcess-precision=standard gcc-bug1-init.c` on the
original example works correctly for me.
If I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98078
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:25fc4cb3ff7bb86d31ac886e04bbe5dd69db832e
commit r9-9291-g25fc4cb3ff7bb86d31ac886e04bbe5dd69db832e
Author: Martin Jambor
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98078
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #39 from Jakub Jelinek ---
Ok, so what do we want to do on the gcc side?
Nothing, just tell users they need latest binutils?
Or try to add a configure check to detect broken binutils that doesn't handle
the DWARF5 new sections and if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96369
--- Comment #8 from CVS Commits ---
The releases/gcc-8 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:371ae12cf3b22795246a5707017f07257b5cbc97
commit r8-10803-g371ae12cf3b22795246a5707017f07257b5cbc97
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96370
--- Comment #10 from CVS Commits ---
The releases/gcc-8 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:0307275acc789491bcc33dc67948009ec7d9c51d
commit r8-10804-g0307275acc789491bcc33dc67948009ec7d9c51d
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96579
--- Comment #9 from CVS Commits ---
The releases/gcc-8 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:19b7dd1caf953f8b79b16c6fc0439dba2a598b1f
commit r8-10805-g19b7dd1caf953f8b79b16c6fc0439dba2a598b1f
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97255
--- Comment #7 from CVS Commits ---
The releases/gcc-8 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:87da0caaec663bd427147c04e5784d7843ede96a
commit r8-10806-g87da0caaec663bd427147c04e5784d7843ede96a
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99542
--- Comment #7 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:39916ceab4940315e84bcd966da2c1d4a8e1734b
commit r11-7700-g39916ceab4940315e84bcd966da2c1d4a8e1734b
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96369
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96370
Richard Biener changed:
What|Removed |Added
Known to fail||8.4.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96579
Richard Biener changed:
What|Removed |Added
Known to work||8.4.1
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96579
Bug 96579 depends on bug 96370, which changed state.
Bug 96370 Summary: [8 Regression] ICE with -ffast-math since
r7-950-g8a85cee26eabf5cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96370
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97255
Richard Biener changed:
What|Removed |Added
Known to fail||8.4.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #8 from Jakub Jelinek ---
Rather than a target hook, isn't it a property of a particular constraint?
This constraint implies "m", this one doesn't?
Make the implies "m" behavior the default one and add some syntax in the *.md
files to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99446
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #40 from jyong at gcc dot gnu.org ---
Personally I'm fine with gcc configure warning of a potentially broken binutils
dwarf5 handing when targeting mingw/cygwin with binutils 2.35.1 or earlier.
How do you even parse binutils versions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93964
--- Comment #6 from CVS Commits ---
The releases/gcc-8 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:5fb76d406e75acc7223df06b66b95e70705e1185
commit r8-10807-g5fb76d406e75acc7223df06b66b95e70705e1185
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93964
Richard Biener changed:
What|Removed |Added
Known to work||8.4.1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859
Bug 59859 depends on bug 93964, which changed state.
Bug 93964 Summary: [8 Regression] [graphite] ICE in
assign_parameter_index_in_region, at graphite-scop-detection.c:1104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93964
What|R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
Bug ID: 99623
Summary: Code behaves differently at -O2 optimization
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #1 from Sebastiano Vigna ---
Created attachment 50407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50407&action=edit
Output of gcc with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #2 from Sebastiano Vigna ---
Created attachment 50408
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50408&action=edit
Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
Bug ID: 99624
Summary: Address sanitizer detects heap-buffer-overflow in
namet.adb
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #7 from Richard Biener ---
(In reply to Matthias Klose from comment #5)
> I'm able to reduce the amount of object files involved in this ICE. But then
> trying to rebuild the package with -save-temps makes the ICE disappear.
I guess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #8 from Richard Biener ---
(In reply to Richard Biener from comment #6)
> More specifically, likely caused by
> g:ae99b315ba5b9e1ccc221b3c45de323cbc574400 which did
>
> diff --git a/gcc/cfg.c b/gcc/cfg.c
> index 529b6ed2105..e8bd1456
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #9 from Richard Biener ---
For the ICE in this bug it might be enough to, in cgraph_node::release_body,
walk callees and zap ->call_stmt on the cgraph edges. But the more general
issue remains - GC will still try to collect the now u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #10 from Richard Biener ---
So like this.
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 80140757d16..447d9a920f7 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -1854,6 +1854,9 @@ cgraph_node::release_body (bool keep_arguments)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #41 from Jakub Jelinek ---
gcc/configure has e.g. $ld_vers_major and $ld_vers_minor and $ld_vers_patch.
But as the fix was March 1st, I think it is neither in 2.35.2 nor in 2.36.
I think a feature test would be better, try to assemble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98891
--- Comment #3 from Wilco ---
Older GCCs only ever did this for vorn, not for other operations like
add/sub/and/orr/eor, so current behaviour is now fully consistent, and I don't
consider it a bug.
One could argue these intrinsics should always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #5 from Sebastiano Vigna ---
Created attachment 50409
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50409&action=edit
Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #6 from Sebastiano Vigna ---
Created attachment 50410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50410&action=edit
Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #42 from Jakub Jelinek ---
As a start, perhaps compiling
void
foo (void)
{
int a = 1;
asm ("nop");
a = 2;
asm ("nop");
a = 3;
}
with -gdwarf-5 -O2 -dA to get the assembly. But bet it can be reduced manually
somewhat, it wou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98891
--- Comment #4 from Wilco ---
(In reply to Jakub Jelinek from comment #1)
> Reduced testcase:
> extern unsigned long long a, b, c;
>
> void
> foo (void)
> {
> a = b | ~c;
> }
>
> Seems this is the usual dilemma between split double-word opera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
Martin Liška changed:
What|Removed |Added
Blocks||86656
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
Sebastiano Vigna changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #11 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
>
> --- Comment #10 from Richard Biener ---
> So like this.
>
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index 80140757d16..447d9a920f7 100644
> --- a/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
H.J. Lu changed:
What|Removed |Added
Resolution|MOVED |---
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99604
Richard Biener changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #8 from Sebastiano Vigna ---
I'm sorry, I did the test on the wrong file. No, you cannot eliminate the &,
even if the type is correct, and h can be NULL at that point. I'll ask the
libavl maintainers their opinion. We can compile with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #4 from Richard Biener ---
(In reply to H.J. Lu from comment #3)
> This is what GCC generates:
>
> hjl@gnu-cfl-2 pr27590]$ cat bad.s
> .section.gnu.debuglto_.debug_macro,"e",@progbits
> .Ldebug_macro0:
> .long .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99625
Bug ID: 99625
Summary: GCC does not detect narrowing in aggregate
initialization
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #5 from Richard Biener ---
Maybe it's an assembler bug that it fails to set 'E' on the GROUP section?
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99604
--- Comment #4 from Nathan Sidwell ---
I wonder if this was an instance of 99423?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #6 from Jakub Jelinek ---
For normal non-LTO debug macro we emit:
.section.debug_macro,"",@progbits
.Ldebug_macro0:
.value 0x5 # DWARF macro version number
.byte 0x2 # Flags: 32-bit, lineptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99604
--- Comment #5 from Richard Biener ---
(In reply to Nathan Sidwell from comment #4)
> I wonder if this was an instance of 99423?
It doesn't use any modules, so unlikely. I thought of PR99447 instead but
since it doesn't reproduce...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #7 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #6)
> For normal non-LTO debug macro we emit:
> .section.debug_macro,"",@progbits
> .Ldebug_macro0:
> .value 0x5 # DWARF macro version number
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #8 from H.J. Lu ---
(In reply to Richard Biener from comment #5)
> Maybe it's an assembler bug that it fails to set 'E' on the GROUP section?
>
SHF_EXLCUDE doesn't apply to "ld -r".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #15 from Jürgen Reuter ---
(In reply to anlauf from comment #14)
> (In reply to Jürgen Reuter from comment #13)
> > Cool, thanks for the quick reaction, Paul. Maybe Harald can have a look at
> > it as well :D
>
> LGTM. It's by Paul.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #9 from Sebastiano Vigna ---
Finally solved: the problematic statement
if (h == NULL) h = (struct prb_node *)&tree->prb_root;
should just be
if (h == NULL) h = tree->prb_root->prb_link[0];
The position in memory of the two pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #9 from H.J. Lu ---
(In reply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #10 from Richard Biener ---
(In reply to H.J. Lu from comment #9)
> (In reply to Jakub Jelinek from comment #6)
> > I don't see how that is any different from the above. The intent is (and it
> > has been working fine for years) that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99604
--- Comment #6 from Nathan Sidwell ---
Myth Plausible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #11 from Jakub Jelinek ---
It has never been global. All it needs is the start of the comdat section.
And GCC is doing it that way for 9.5 years already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #12 from Richard Biener ---
Btw, gold happily links w/o a problem. lld (from llvm9) reports
> ld.lld -r bad.o bad.o
ld.lld: warning: relocation refers to a discarded section:
.gnu.debuglto_.debug_macro
>>> referenced by bad.o:(.rela
1 - 100 of 181 matches
Mail list logo
