[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386 --- Comment #57 from Michael Matz --- (In reply to Alexander Monakov from comment #56) > I think you mean -fno-plt, not -mno-plt (here and your previous comment)? Yes.

[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386 --- Comment #55 from Michael Matz --- Yes, %r11 may be clobbered by the lazy stub, nothing else will be changed by the PLT. Even that shouldn't matter, though, in this case. Of course, the very fact that the PLT was never used in the past year

[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386 --- Comment #52 from Michael Matz --- I'm not a backend maintainer, so I have no real say here. But FWIW I don't see an issue with going via PLT either (if not under -mno-plt effect). I agree that a dependency on -m[no-]direct-extern-access wou

[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386 --- Comment #17 from Michael Matz --- (In reply to Ard Biesheuvel from comment #16) > OK, so in summary, the fallthrough for CM_SMALL_PIC/CM_MEDIUM_PIC should be > removed, and instead, a 'call mcount@PLT' should be emitted. That crucially depe

[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386 --- Comment #14 from Michael Matz --- (In reply to H.J. Lu from comment #13) > (In reply to Michael Matz from comment #11) > > > access to the respective GOT slot). Upstream binutils now silently do emit > > a > > route via PLT, our binutils

[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386 --- Comment #12 from Michael Matz --- (clicked send too soon) ... Either way, I think GCC should emit a PIC sequence under -fPIC, also for the function profiler, either by direct GOT access, or by using the @plt decoration, depending on if the

[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386 --- Comment #11 from Michael Matz --- The binutils in our (SUSEs) enterprise codestreams revert certain behaviour changes from upstream in relation to rewriting PC32 to PLT32 relocs (as some old tooling doesn't cope with that). So, our binutils

[Bug tree-optimization/105771] [12/13/14/15 regression] matrix partial transposition with -O3 since r8-5159-g1cc521f1a824b591

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105771 Michael Matz changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |matz at gcc dot gnu.org

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980 --- Comment #21 from Michael Matz --- I've posted a version of Kewens patch that moves the wanted functionality under a new target option: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668608.html (in the hope that that's getting a

[Bug rtl-optimization/117064] New: target hook HARD_REGNO_RENAME_OK is too limiting

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117064 Bug ID: 117064 Summary: target hook HARD_REGNO_RENAME_OK is too limiting Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Compo

[Bug tree-optimization/116850] [12/13/14/15 Regression] ICE at -O{s,2,3} on x86_64-linux-gnu: in verify_dominators, at dominance.cc:1194

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116850 --- Comment #4 from Michael Matz --- > Instead of using post-dominance from entry we could approximate that by > dominance from exit which requires adding fake exit edges. Hmm? post-dominance _is_ dominance from exit. (IOW: it's dominance on

[Bug target/115860] [15 regression] Register pairs and regrename since r15-1579-g792f97b44ffc5e

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115860 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #1 f

[Bug rtl-optimization/116650] Regrename creates conflict with register pair

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116650 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #2 f

[Bug target/116413] [LRA] [M68K] ICE: unrecognized insn in lra_set_insn_recog_data, at lra.cc:1036

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413 --- Comment #18 from Michael Matz --- This last problem is a pre-existing one in the backend. It accepts bare label_ref plus operands, but it does so also in flag_pic mode. There it isn't correct (because it implies another memory reference).

[Bug target/116429] [LRA] [M86k] Wrong spill offset

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116429 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #1 f

[Bug target/116413] [LRA] [M68K] ICE: unrecognized insn in lra_set_insn_recog_data, at lra.cc:1036

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #8 f

[Bug target/116374] [LRA] [M68K] Wrong %argptr elimination

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116374 --- Comment #5 from Michael Matz --- Little by little... So, there's a special case in eliminate_regs_in_insn for a simple regset from a reg+cst source. That special case isn't doing quite the same as the generic elimination code in lra_elimin

[Bug target/116236] [LRA] [M68K] ICE insn does not satisfy its constraints

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236 --- Comment #21 from Michael Matz --- (In reply to Richard Sandiford from comment #17) > > But if LRA needs to be extended for correctness, then, ... meh. > But this is how it's always worked. The corresponding reload code is in > find_reloads_

[Bug target/116374] [LRA] [M68K] Wrong %argptr elimination

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116374 --- Comment #3 from Michael Matz --- Ah yes, that assert checks that a previously unused elimination entry is still pristine. It might be that the entries in 'self_elim_table' need similar treatment, but that would need further testcases to be

[Bug target/116374] [LRA] [M68K] Wrong %argptr elimination

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116374 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #1 f

[Bug target/116236] [LRA] [M68K] ICE insn does not satisfy its constraints

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236 --- Comment #16 from Michael Matz --- (In reply to Richard Sandiford from comment #15) > > Yes, I considered adding this handling of (zero_extend Rx) to LRA. I'm > > confident > > it would fix this instance of the problem, if done correctly (it

[Bug target/116236] [LRA] [M68K] ICE insn does not satisfy its constraints

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236 --- Comment #14 from Michael Matz --- (In reply to Richard Sandiford from comment #13) > (In reply to Michael Matz from comment #12) > > That's why I struggle a bit, I lack the bigger picture, how LRA is > > envisioned to deal with these situati

[Bug target/116236] [LRA] [M68K] ICE insn does not satisfy its constraints

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236 --- Comment #12 from Michael Matz --- But please note that Georg-Johanns question and its ensuing subthread is not related to this specific m68k problem. It rather deals with the situation of what to do in the non-strict variant. _Here_ we hav

[Bug target/116236] [LRA] [M68K] ICE insn does not satisfy its constraints

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236 --- Comment #6 from Michael Matz --- This works for me for the full testcase. a) accept pseudos during lra_in_progress only when they're allocated to the right hardreg b) but _only_ do (a) if the pseudo is not one of those generated _during_

[Bug target/116236] [LRA] [M68K] ICE insn does not satisfy its constraints

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #5 f

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980 --- Comment #16 from Michael Matz --- (In reply to Kewen Lin from comment #15) > I agree, thanks for the comments! btw, I'm not fighting for the current > implementation, just want to know more details why users are unable to make > use of the c

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980 --- Comment #14 from Michael Matz --- (In reply to Kewen Lin from comment #13) > (In reply to Giuliano Belinassi from comment #12) > > With your patch we have: > > > > > .LPFE0: > > > ... > > Which seems what is expected. > > Hi Giuliano, than

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #31 from Michael Matz --- (In reply to H.J. Lu from comment #30) > (In reply to Michael Matz from comment #29) > > It not only can call malloc. As the backtrace of H.J. shows, it quite > > clearly _does_ so :-) > > ld.so can only c

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #29 from Michael Matz --- It not only can call malloc. As the backtrace of H.J. shows, it quite clearly _does_ so :-) That's why there is talk earlier in this report about potentially not using malloc as one-time allocator for thre

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980 --- Comment #3 from Michael Matz --- (In reply to Kewen Lin from comment #1) > > As Segher's review comments in [2], to support "before NOPs" before global > entry and "after NOPs" after global entry, Just to be perfectly clear here: the "afte

[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #15 f

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372 --- Comment #16 from Michael Matz --- A general remark: in principle I don't see problems with undoing a little CSE, as proposed. I.e. for each SSA name use, see if it (trivially, or conservatively or optimistically) refers to an address of a t

[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345 --- Comment #21 from Michael Matz --- (In reply to Jan Hubicka from comment #20) > > > > Live patching (user-space) doesn't depend on any particular alignment of > > functions, on x86-64 at least. (The plan for other architectures wouldn't > >

[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345 --- Comment #19 from Michael Matz --- (In reply to Jan Hubicka from comment #18) > Reading all the discussion again, I am leaning towards -falign-all-functions > + documentation update explaining that -falign-functions/-falign-loops are > optimiz

[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #28

[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #16 f

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899 --- Comment #11 from Michael Matz --- (In reply to Florian Weimer from comment #10) > (In reply to Michael Matz from comment #9) > > > > I don't see how that helps. Imagine a preserve_all function foo that > > > > calls > > > > printf. How do

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899 --- Comment #9 from Michael Matz --- (In reply to Florian Weimer from comment #8) > (In reply to Michael Matz from comment #7) > > > > Does the clang implementation take into account the various problematic > > > > cases that arise when calling

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899 --- Comment #7 from Michael Matz --- (In reply to Florian Weimer from comment #5) > > It also makes argument registers be callee-saved, which is very > > unconventional. > > Isn't this done for the this pointer in some C++ ABIs? There are some

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899 --- Comment #4 from Michael Matz --- (In reply to Florian Weimer from comment #2) > I tried to write up something for the x86-64 psABI: > > Document the ABI for __preserve_most__ function calls >

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899 --- Comment #3 from Michael Matz --- Huh, since when does clang implement this? See also https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624004.html where I asked for comments about a similar, but not same, mechanism. I came from the an

[Bug middle-end/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110728 --- Comment #11 from Michael Matz --- (In reply to Michael Matz from comment #9) > Just for completeness: I agree with Andrew that the initial code example in > comment #0 doesn't show any problem. The edge from asmgoto to l0 doesn't > cross >

[Bug middle-end/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110728 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #9 f

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742 --- Comment #10 from Michael Matz --- (In reply to Jakub Jelinek from comment #9) > (In reply to Michael Matz from comment #7) > > (In reply to Jakub Jelinek from comment #5) > > > https://eel.is/c++draft/cfloat.syn points to the C standard for

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742 --- Comment #8 from Michael Matz --- (In reply to Michael Matz from comment #7) > So, my interpretation is that unsuffixed "4.2" has to be the double constant > 4.2 (in IEEE double aka 0x1.0cccdp+2), which is then, because of > FLT_EVAL_

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742 --- Comment #7 from Michael Matz --- (In reply to Jakub Jelinek from comment #5) > https://eel.is/c++draft/cfloat.syn points to the C standard for > FLT_EVAL_METHOD > (plus https://eel.is/c++draft/expr#pre-6 talks about excess precision too) > a

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742 --- Comment #3 from Michael Matz --- (In reply to Jakub Jelinek from comment #2) > Note, internally in standard excess precision, 4.2 seen by the lexer is > actually > EXCESS_PRECISION , Then _that_ is the problem. The literal "4.2" simply is

[Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742 Bug ID: 108742 Summary: Incorrect constant folding with (or exposed by) -fexcess-precision=standard Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity:

[Bug c/106571] Implement -Wsection diag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106571 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #4 f

[Bug fortran/106353] [suboptimal] Why is a 3D array initialized, use case 2 two-layer loop?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106353 --- Comment #2 from Michael Matz --- True, but in this case it could also be emitted in a better way by the fortran frontend.

[Bug tree-optimization/106192] [11/12/13 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.cc:3522

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106192 --- Comment #3 from Michael Matz --- (In reply to Michael Matz from comment #2) > see why it should be. If GIMP_SIMD_LANE has properties that make this > transformation invalid I would argue that those properties are correctly "are _not_" I me

[Bug tree-optimization/106192] [11/12/13 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.cc:3522

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106192 --- Comment #2 from Michael Matz --- Unroll-and-jam simply unrolls the outer loop and merged all resulting inner-loop bodies. In this situation we have (before unroll-and-jam): outerloop(i_1) { _12 = i_1 <= 59 innerloop(i_1, j by 1) {

[Bug c++/105169] Compiling C++ code with -fpatchable-function-entry=16,14 results in references to discarded sections

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105169 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #8 f

[Bug middle-end/104721] currently_expanding_gimple_stmt isn't cleared properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104721 --- Comment #2 from Michael Matz --- Is there a testcase where you noticed this, or was it just reading code?

[Bug tree-optimization/104543] [9/10/11 Regression] wrong code at -O3 on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104543 --- Comment #11 from Michael Matz --- (In reply to Richard Biener from comment #5) > in particular the comment in bb_prevents_fusion_p saying > > /* BB is duplicated by outer unrolling and then all N-1 first copies > move into the body o

[Bug demangler/99188] cxxfilt may exist a uaf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99188 Michael Matz changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #8 f

[Bug target/102024] [12 Regression] zero width bitfields and ABIs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #8 from Michael Matz --- The only thing the x86-64 psABI says about this case is "'Unnamed bit-fields' types do not affect the alignment of a structure or union." . (zero-width bit-fields are _always_ unnamed) But the x86-64 psABI

[Bug middle-end/100394] wrong-code with EH and pure/const functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394 --- Comment #4 from Michael Matz --- That then still shows problems with the pure function and -O2, but with standard C++ this then works: struct S { int foo(int i) const { if (i) throw 42; return 0; } }; int __attribute__((noinline)) bar2

[Bug middle-end/100394] wrong-code with EH and pure/const functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394 Michael Matz changed: What|Removed |Added Known to fail|3.4.6, 4.3.5| CC|

[Bug target/100077] x86: by-value floating point array in struct - xmm regs spilling to stack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100077 --- Comment #2 from Michael Matz --- Yeah, to solve this fully requires representing the parameter passing in a better way, one that can be (a) used on the gimple side (where the code is already generated assuming the vec3a params go into memory

[Bug driver/99896] g++ drops -lc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #7 fr

[Bug tree-optimization/99101] optimization bug with -ffinite-loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101 --- Comment #22 from Michael Matz --- Over the last days I came to a similar conclusion. Control dependence as defined with postdoms doesn't capture the number of invocations of an instruction, just wether it's invoked at all. I.e. paths with a

[Bug tree-optimization/99101] optimization bug with -ffinite-loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101 --- Comment #19 from Michael Matz --- (In reply to Michael Matz from comment #18) > But there are other blocks control dependend on bb4, namely bb5 and bb9. > To see this observe that bb9 doesn't pdom bb4, but there's a path from bb4 to > bb9 (e.

[Bug tree-optimization/99101] optimization bug with -ffinite-loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101 --- Comment #18 from Michael Matz --- (In reply to Richard Biener from comment #11) > (In reply to Richard Biener from comment #10) > > Created attachment 50248 [details] > > dot of the CFG as CD-DCE sees it > > (gdb) p debug_dominance_info (CDI

[Bug tree-optimization/99101] optimization bug with -ffinite-loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101 --- Comment #17 from Michael Matz --- (In reply to Richard Biener from comment #16) > Of course since -ffinite-loops and the C++ standard require forward progress > here and all testcases expect the loop to not terminate we're in the realm > of u