[Bug debug/53927] wrong value for DW_AT_static_link

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 --- Comment #21 from Pierre-Marie de Rodat derodat at adacore dot com --- (In reply to Eric Botcazou from comment #18) I think this is worth investigating though because it's conceptually much simpler than adding yet another indirection

[Bug debug/53927] wrong value for DW_AT_static_link

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 --- Comment #22 from Pierre-Marie de Rodat derodat at adacore dot com --- (In reply to Tom Tromey from comment #20) Yeah. There wasn't much point submitting it when it wouldn't work anyhow :} Also see the README.archer file. It explains some

[Bug debug/53927] wrong value for DW_AT_static_link

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 --- Comment #15 from Pierre-Marie de Rodat derodat at adacore dot com --- (In reply to Pierre-Marie de Rodat from comment #13) [1] This patch teaches GDB how to use DW_AT_static_link in order to find the frame corresponding to the lexically

[Bug debug/53927] wrong value for DW_AT_static_link

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 --- Comment #17 from Pierre-Marie de Rodat derodat at adacore dot com --- (In reply to Tom Tromey from comment #16) I'm curious if you tried it on the test case in this PR. I did not, but it looks like it now works as expected. Here

[Bug debug/53927] wrong value for DW_AT_static_link

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 --- Comment #14 from Pierre-Marie de Rodat derodat at adacore dot com --- Created attachment 34868 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34868action=edit patch to generate DWARF-compliant DW_AT_static_link attributes gcc

[Bug debug/53927] wrong value for DW_AT_static_link

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 Pierre-Marie de Rodat derodat at adacore dot com changed: What|Removed |Added CC

[Bug debug/66503] New: missing DW_AT_abstract_origin for cross-unit call sites

Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: derodat at adacore dot com Target Milestone: --- Created attachment 35754 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35754action=edit C reproducer With the recent work for PR debug

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #1 from Pierre-Marie de Rodat derodat at adacore dot com --- Created attachment 35923 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35923action=edit Part of the reproducer

[Bug rtl-optimization/66790] New: Invalid uninitialized register handling in REE

-optimization Assignee: unassigned at gcc dot gnu.org Reporter: derodat at adacore dot com Target Milestone: --- The reproducer I'm about to attach[1] seems to trigger a code generation issue at least on x86_64-linux: $ gnatmake -q p -O3 -gnatn $ ./p raised

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #2 from Pierre-Marie de Rodat derodat at adacore dot com --- Created attachment 35924 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35924action=edit Part of the reproducer

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #3 from Pierre-Marie de Rodat derodat at adacore dot com --- Created attachment 35925 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35925action=edit Part of the reproducer

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #8 from Pierre-Marie de Rodat derodat at adacore dot com --- (In reply to Richard Biener from comment #7) It would be certainly good to see why we have this UNDEF in the first place. Sure: here is a C translation of what happens

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #9 from Pierre-Marie de Rodat derodat at adacore dot com --- Created attachment 36098 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36098action=edit Updated candidate patch

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #6 from Pierre-Marie de Rodat derodat at adacore dot com --- Thanks for your answer, Richard! (In reply to Richard Biener from comment #5) So what is the issue with replacing zero-extending an uninitialized %ebp with a random other

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #4 from Pierre-Marie de Rodat derodat at adacore dot com --- (In reply to Pierre-Marie de Rodat from comment #0) Given the somelabel code path, I would rather expect DF_REF_CHAIN to hold a NULL reference to materialize the lack

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #43 from Pierre-Marie de Rodat --- (In reply to Bernd Schmidt from comment #42) > I don't think that would actually help. Even if something is an actual > incoming argument register, it may still be uninitialized by the caller. Sure,

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #13 from Pierre-Marie de Rodat --- (In reply to Eric Botcazou from comment #12) > Thanks. I misremembered, the testcase has a single variable with two > fields, one uninitialized and one initialized, instead of two variables, but >

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #11 from Pierre-Marie de Rodat --- Created attachment 36320 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36320=edit Reproducer with an uninitialized variable (no OUT parameter)

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #41 from Pierre-Marie de Rodat --- Thank you again for spotting this! Yes, these artificial defs break the consevativeness for the MIR analysis. I guess your proposal would work: considering as uninintialized registers than aren’t is

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #32 from Pierre-Marie de Rodat --- (In reply to Bernd Schmidt from comment #28) > It is sufficient for OUT(3) to be all-zeros. And I don't think the > LAST_CHANGE_AGE mechanism does anything to prevent it. Please try it > out. I

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 Pierre-Marie de Rodat changed: What|Removed |Added Attachment #36098|0 |1 is obsolete|

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #34 from Pierre-Marie de Rodat --- Created attachment 36378 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36378=edit Fix for DF_LIVE local BB information

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #38 from Pierre-Marie de Rodat --- (In reply to Paolo Bonzini from comment #35) > Is this comment obsolete? The IN bitmap is all set at first. Yes, indeed: I removed the part you quoted. (In reply to Paolo Bonzini from comment #35)

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 Pierre-Marie de Rodat changed: What|Removed |Added Attachment #36377|0 |1 is obsolete|

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #27 from Pierre-Marie de Rodat --- Firstly, thanks everyone for your help! I'll try to address points that still are unresolved. (In reply to Bernd Schmidt from comment #14) > As you say, the df-live problem claims to compute a

[Bug ada/79542] [7 regression] GNAT bug box

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542 Pierre-Marie de Rodat changed: What|Removed |Added CC||derodat at adacore dot com

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78112 Pierre-Marie de Rodat changed: What|Removed |Added CC||derodat at adacore dot com

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

||derodat at adacore dot com Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |derodat at adacore dot com --- Comment #13 from Pierre-Marie de Rodat --- I just pushed the suggested fix on trunk, so the regression

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78112 Pierre-Marie de Rodat changed: What|Removed |Added CC||thopre01 at gcc dot gnu.org ---

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78112 --- Comment #10 from Pierre-Marie de Rodat --- Created attachment 39932 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39932=edit pyelftools-based Python3 script to check duplicate attributes in ELF/DWARF info

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78112 --- Comment #9 from Pierre-Marie de Rodat --- Back to business. ;-) Thank you very much, Jakub! During investigation, I managed to reduce this even further: void run (int *int_p, void(*func)(int *)) { func (int_p); } namespace foo {

[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 Pierre-Marie de Rodat changed: What|Removed |Added CC||derodat at adacore dot com

[Bug ada/79542] [7/8 regression] ICE in add_gnat_descriptive_type_attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542 --- Comment #7 from Pierre-Marie de Rodat --- (In reply to John Marino from comment #6) > It looks like the release of 7.2 is upcoming. It would be really great if > this ICE/Regression is addressed for that release. Is there any way to >

[Bug ada/35880] GNAT does not generate debugging information on imported entities

||derodat at adacore dot com Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |derodat at adacore dot com Target Milestone|--- |8.0 --- Comment #11 from Pierre-Marie de Rodat

[Bug testsuite/78318] FAIL: g++.dg/pr78112.C scan-assembler-times DW_AT_object_pointer 37

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78318 --- Comment #3 from Pierre-Marie de Rodat --- (In reply to Ramana Radhakrishnan from comment #1) > Is this still an issue ? Surely isn't the fix just changing > scan-assembler-times to 38 ? I could not just change the count, as I got different

[Bug testsuite/78318] FAIL: g++.dg/pr78112.C scan-assembler-times DW_AT_object_pointer 37

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78318 --- Comment #4 from Pierre-Marie de Rodat --- (In reply to Thomas Preud'homme from comment #2) > I assume the result is 37 for some platform. Anyway, I apologize since the > scan has been removed from the testcase so this is now fixed as of

[Bug debug/82155] [7/8 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:21655

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82155 Pierre-Marie de Rodat changed: What|Removed |Added CC||derodat at adacore dot com

[Bug debug/82155] [7/8 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:21655

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82155 --- Comment #4 from Pierre-Marie de Rodat --- I have a candidate fix, which I submitted on gcc-patches@:

[Bug ada/82384] [8 Regression] s-taprop.adb failed to compile for x32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82384 Pierre-Marie de Rodat changed: What|Removed |Added CC||derodat at adacore dot com

[Bug ada/82384] [8 Regression] s-taprop.adb failed to compile for x32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82384 --- Comment #7 from Pierre-Marie de Rodat --- I think your second test will also fail for the same reason. I suggest you also add the following patchlet: diff --git a/gcc/ada/libgnarl/s-osinte__x32.adb b/gcc/ada/libgnarl/s-osinte__x32.adb index

[Bug ada/82384] [8 Regression] s-taprop.adb failed to compile for x32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82384 --- Comment #13 from Pierre-Marie de Rodat --- Yes, and thank you Eric for checking the fix in. :-)

[Bug ada/79542] [7 regression] ICE in add_gnat_descriptive_type_attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542 Pierre-Marie de Rodat changed: What|Removed |Added Status|NEW |RESOLVED Known to work|

[Bug debug/82155] [7 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:21655

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82155 Pierre-Marie de Rodat changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug driver/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83016 --- Comment #1 from Pierre-Marie de Rodat --- I can’t reproduce with “--enable-languages=c,c++,ada --disable-multilib --disable-libsanitizer” on trunk r254797. Do you use specific options?

[Bug ada/82844] [8 Regression] Many ada tests time out on x32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82844 --- Comment #9 from Pierre-Marie de Rodat --- I’ve setup an Ubuntu VM, installed libx32 runtime libraries and built with “--with-multilib-list=m32,m64,mx32” + ran the testsuite (“make -C gcc -j8 -k check-ada”), without reproducing the issues you

[Bug ada/82844] [8 Regression] Many ada tests time out on x32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82844 --- Comment #8 from Pierre-Marie de Rodat --- (In reply to H.J. Lu from comment #7) > That is r253366. X32 failed to build between r253136 and r253365. Ok, thanks! We still have patches in the pipeline in this area (s-taprop* files), so I’ll

[Bug debug/83935] DWARF for a variant part is incorrect

||2018-01-22 CC||derodat at adacore dot com Component|ada |debug Assignee|unassigned at gcc dot gnu.org |derodat at adacore dot com Ever confirmed|0

[Bug debug/83935] DWARF for a variant part is incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #2 from Pierre-Marie de Rodat --- Thinking more about it, the rule that the discriminant entry must be a child of the variant part entry sounds suspicious to me. In the case of two variant parts, which are nested and depend on the

[Bug debug/83935] DWARF for a variant part is incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #4 from Pierre-Marie de Rodat --- (In reply to Tom Tromey from comment #3) > TBH this did not make sense to me, either, which is partly why I originally > wrote my patch the "more natural" way -- then this got caught in review, > see

[Bug debug/83765] LTO bootstrap with Ada fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83765 --- Comment #6 from Pierre-Marie de Rodat --- (In reply to Eric Botcazou from comment #4) > We have been crossing fingers about that for some time. ;-) CCing the > expert. Calling me “expert” is a bit far fetched: I never worked with LTO, and

[Bug debug/83935] DWARF for a variant part is incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #6 from Pierre-Marie de Rodat --- Just got a notification that it got assigned issue #180123.1: http://dwarfstd.org/ShowIssue.php?issue=180123.1

[Bug lto/84213] [8 Regression] 521.wrf_r from SPEC 2017 fails to build (link) with LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84213 --- Comment #18 from Pierre-Marie de Rodat --- Excellent, thank you for the feedback!

[Bug lto/84213] [8 Regression] 521.wrf_r from SPEC 2017 fails to build (link) with LTO

|--- |FIXED Assignee|rguenth at gcc dot gnu.org |derodat at adacore dot com --- Comment #16 from Pierre-Marie de Rodat --- Martin, the issue should now be fixed on trunk. Thank you for reporting it! Can you confirm everything is fine on your side?

[Bug lto/84213] [8 Regression] 521.wrf_r from SPEC 2017 fails to build (link) with LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84213 --- Comment #14 from Pierre-Marie de Rodat --- (In reply to Pierre-Marie de Rodat from comment #13) > IIRC, DECL_VALUE_EXPR is something like MEM_REF (-1). Yes, I’ll give it a > try… I submitted a candidate patch:

[Bug lto/84213] [8 Regression] 521.wrf_r from SPEC 2017 fails to build (link) with LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84213 --- Comment #10 from Pierre-Marie de Rodat --- (In reply to Richard Biener from comment #8) > Yeah, setting DECL_PRESERVE_P would make it possible to add the > location late since we'd not remove the decl. Currently it's simply > gone and the

[Bug lto/84213] [8 Regression] 521.wrf_r from SPEC 2017 fails to build (link) with LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84213 Pierre-Marie de Rodat changed: What|Removed |Added CC||derodat at adacore dot com

[Bug lto/84213] [8 Regression] 521.wrf_r from SPEC 2017 fails to build (link) with LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84213 --- Comment #13 from Pierre-Marie de Rodat --- (In reply to rguent...@suse.de from comment #11) > This means you should be able to arrange for this > to be emitted by tree_add_const_value_attribute_for_decl as well, no? I don’t know… I have to

[Bug debug/83935] DWARF for a variant part is incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #8 from Pierre-Marie de Rodat --- Understood, thank you for the notice! As we have to tweak the spec one way or another for Ada, I suggest indeed we keep the way things are implemented in GCC today, waiting for the DWARF committee to

[Bug debug/83935] DWARF for a variant part is incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #5 from Pierre-Marie de Rodat --- I just submitted an Issue/Comment on dwarfstd.org, but unfortunately it is not yet publicly visible (http://dwarfstd.org/Issues.php). Waiting for feedback from there…