[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

Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: matz at gcc dot gnu.org Target Milestone: --- This came up during fixing PR116650. Essentially it's possible for regrename choosing a new register N for a chain (having old register O) where N

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: matz at gcc dot gnu.org Target Milestone: --- This came from a discussion about a user wondering why g++ behaved different between GCC 12 and GCC 13, regarding

[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

[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

[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

|RESOLVED CC||matz at gcc dot gnu.org --- Comment #7 from Michael Matz --- Actually, it _is_ fixed. This problem report is about version 2.26, which is many years old. Current versions don't have this problem, at the very least whe

[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

[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

||matz at gcc dot gnu.org --- Comment #3 from Michael Matz --- That's simply invalid C++. A rethrow (which is what a 'throw' without value is) can only be done from within a catch. You need to throw a value: ... int __attribute__((pure,noinline)) foo () { if (x) throw 42; return y; } ...

[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

[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

[Bug target/96895] ABI of returning V1DF differs between GCC and clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895 --- Comment #7 from Michael Matz --- (In reply to Richard Biener from comment #5) > So vector types with element type T and N, a power-of-two, not otherwise > specified are passes the same as > > struct S { T a[N] }; > > ? No. structs, if the

[Bug target/96895] ABI of returning V1DF differs between GCC and clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895 --- Comment #2 from Michael Matz --- The psABI doesn't say anything about such types, no. Maybe it could in some additional info pages, but it's always a problem to codify behaviour retroactively in it, when conflicting implementations already e

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794 --- Comment #11 from Michael Matz --- (In reply to Jan Hubicka from comment #10) > > We could also punt: when enable-link-mutex we could artificially up the job > > number for make to account for the waiting link steps. I.e. when normally > > -

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794 --- Comment #9 from Michael Matz --- We could also punt: when enable-link-mutex we could artificially up the job number for make to account for the waiting link steps. I.e. when normally -jN was given, the link step could be done under -j(N + nr

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373 --- Comment #11 from Michael Matz --- (In reply to rguent...@suse.de from comment #9) > How do we represent sNaNs with -fnon-call-exceptions? That is, I think we're currently simply buggy at various stages as soon as sNaNs are involved _and_ ST

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373 --- Comment #10 from Michael Matz --- (In reply to Andreas Schwab from comment #5) > > Just note that _all_ floating point operations, not just divisions, can trap > > (without fast-math). You never know if the user enabled stops for any of > >

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373 --- Comment #3 from Michael Matz --- (In reply to Richard Biener from comment #2) > which means for non-memory gimple_could_trap_p (stmt) - sth you can > easily check I guess. Just note that _all_ floating point operations, not just divisions, c

[Bug target/96373] New: SVE miscompilation on vectorized division loop, leading to FP exception

: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: matz at gcc dot gnu.org Target Milestone: --- I believe gcc-10 miscompiles the following program when SVE and vectorization are enabled. You need glibc to show this, or a

[Bug inline-asm/94522] Enhancement request: asm goto with outputs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94522 --- Comment #3 from Michael Matz --- See the llvm link of the respective patch. They specify that the outputs are reliable only on the fallthrough (i.e. no goto taken) path (in particular the outputs might or might not have been changed on the j

[Bug testsuite/91626] [9/10 Regression] FAIL: gcc.dg/lto/pr48622 c_lto_pr48622_0.o-c_lto_pr48622_0.o link, -O -flto -finline-small-functions -fno-early-inlining

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91626 --- Comment #7 from Michael Matz --- I've added it verbatim from PR48622, which itself was an autoreduced testcase for an ICE, at the time preventing bootstrapping. I haven't verified if making the testcase conforming C (i.e. provide a definitio

[Bug c++/92662] change in gcc 8 vs 9: call of overloaded ‘basic_string()’ is ambiguous

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662 --- Comment #8 from Michael Matz --- >From the GCC perspective, yes. From the standard-is-surprising perspective, no, but that probably doesn't belong to the GCC bugzilla. So, yeah, can be closed for gcc 9 (theoretically it's still a bug in gcc

[Bug middle-end/90348] [8/9/10 Regression] Partition of char arrays is incorrect in some cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348 --- Comment #18 from Michael Matz --- (In reply to Alexander Monakov from comment #17) > I think part of the problem is trying to make "deaths" explicit via CLOBBERs > without making "births" also explicit in the IR. Yes, that's basically the cr

[Bug target/93270] [8/9/10 Regression] DSE removes store incorrectly

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

[Bug target/92821] Miscompilation when passing 8-bit enum to extern function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92821 --- Comment #5 from Michael Matz --- Yes, we (intentionally) haven't required any extensions to happen for arguments or return values smaller than 64bit (e.g. we haven't even specified that arguments <= 32bit would be zero-extended in the high bi

[Bug c++/92662] change in gcc 8 vs 9: call of overloaded ‘basic_string()’ is ambiguous

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662 --- Comment #6 from Michael Matz --- (In reply to Jonathan Wakely from comment #5) > > Before choosing which conversion operator to use, the compiler considers the > constructors of S, finding S(const S&) and S(S&&) as candidates. There is a > v

[Bug c++/92662] change in gcc 8 vs 9: call of overloaded ‘basic_string()’ is ambiguous

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662 --- Comment #4 from Michael Matz --- Even though bugzilla isn't really for educating people, I'd still like to ask why the two conversion sequences are deemed either incomparable or equal. In S b { moveme(t) }; the return value of moveme() h

[Bug c++/92662] change in gcc 8 vs 9: call of overloaded ‘basic_string()’ is ambiguous

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662 --- Comment #1 from Michael Matz --- I _think_ a reduced program would be this: - template struct remove_ref { typedef _Tp type; }; template struct remove_ref<_Tp&> { typedef _Tp type; }; template struct r

[Bug c++/92662] New: change in gcc 8 vs 9: call of overloaded ‘basic_string()’ is ambiguous

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: matz at gcc dot gnu.org Target Milestone: --- A user of ours noted a difference in behaviour between gcc8 and gcc9 regarding braced initializers. Take this

[Bug middle-end/90796] [8/9 Regression] GCC: O2 vs O3 output differs on simple test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796 --- Comment #17 from Michael Matz --- Author: matz Date: Wed Nov 20 16:51:10 2019 New Revision: 278512 URL: https://gcc.gnu.org/viewcvs?rev=278512&root=gcc&view=rev Log: Fix PR90796 PR middle-end/90796 * gimple-loop-jam.c (any_acc

[Bug middle-end/90796] [8/9 Regression] GCC: O2 vs O3 output differs on simple test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796 --- Comment #16 from Michael Matz --- (In reply to Jakub Jelinek from comment #14) > Time to backport now? Hmpf, I've actually done the regstrapping for gcc9 already but then forgot to submit. Thanks for the reminder.

[Bug middle-end/90796] [8/9 Regression] GCC: O2 vs O3 output differs on simple test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796 Michael Matz changed: What|Removed |Added Summary|[8/9/10 Regression] GCC: O2 |[8/9 Regression] GCC: O2 vs

[Bug middle-end/90796] [8/9/10 Regression] GCC: O2 vs O3 output differs on simple test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796 --- Comment #12 from Michael Matz --- Author: matz Date: Tue Oct 22 12:25:03 2019 New Revision: 277287 URL: https://gcc.gnu.org/viewcvs?rev=277287&root=gcc&view=rev Log: Fix PR middle-end/90796 PR middle-end/90796 * gimple-loop-

[Bug rtl-optimization/91898] [optimization] switch statements for state machines could be better

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91898 --- Comment #3 from Michael Matz --- For purposes of discussion, let's make a full example: % cat ex.c int get(int); int foo (int a, int *ary) { //void *labelsy[] = {&&lab1, &&lab2, &&lab3, &&lab_end}; //int ary[] = {0, 1, 2, 3}; int i = 0

[Bug rtl-optimization/91898] [optimization] switch statements for state machines could be better

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

[Bug middle-end/91358] Wrong code with dynamic allocation and optional like class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91358 --- Comment #7 from Michael Matz --- (In reply to Antony Polukhin from comment #6) > (In reply to Michael Matz from comment #3) > > I don't really see any, no good idea here :-/ > > How about moving all the optimizations based on reading uniniti

[Bug middle-end/90796] [8/9/10 Regression] GCC: O2 vs O3 output differs on simple test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796 --- Comment #11 from Michael Matz --- (In reply to rguent...@suse.de from comment #10) > >It's the only affine functions that don't progress with each iteration. > > I > >think, at least :) > > Hm. At least we analyze wrapping ones, but I guess

[Bug middle-end/90796] [8/9/10 Regression] GCC: O2 vs O3 output differs on simple test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796 --- Comment #9 from Michael Matz --- (In reply to rguent...@suse.de from comment #8) > >The fun thing is, there's a difference between these two loop nests: > > > > for (i) for (j) a[i][0] = f(a[i+1][0]); > > for (i) for (j) b[i][j] = f(a[i+1

[Bug middle-end/91358] Wrong code with dynamic allocation and optional like class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91358 --- Comment #3 from Michael Matz --- (In reply to Antony Polukhin from comment #2) > (In reply to Michael Matz from comment #1) > Valgrind complains are distracting. GDB entering the destructor is > missleading. Is there a simple way to change th

[Bug middle-end/91358] Wrong code with dynamic allocation and optional like class

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

[Bug tree-optimization/91240] [8/9/10 Regression] Wrong code with -O3 due to unroll and jam pass

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91240 --- Comment #3 from Michael Matz --- Also fixed by the patch at PR90796.

[Bug middle-end/90796] [8/9/10 Regression] GCC: O2 vs O3 output differs on simple test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796 --- Comment #7 from Michael Matz --- Created attachment 46675 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46675&action=edit potential patch Actually I was barking up the wrong tree. It's not as easy as the CFG manipulation for loop fus

[Bug tree-optimization/91240] [8/9/10 Regression] Wrong code with -O3 due to unroll and jam pass

at gcc dot gnu.org |matz at gcc dot gnu.org --- Comment #2 from Michael Matz --- Mine.

[Bug middle-end/90796] [8/9/10 Regression] GCC: O2 vs O3 output differs on simple test

at gcc dot gnu.org |matz at gcc dot gnu.org --- Comment #6 from Michael Matz --- I think I know what's going on. Mine.

[Bug middle-end/90796] [8/9/10 Regression] GCC: O2 vs O3 output differs on simple test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796 --- Comment #5 from Michael Matz --- FWIW, the reduced testcase from comment #3 is wrong. Even with -O0 or with gcc 4.3 or 6 I get: b:48 Aborted (core dumped) But I can reproduce the problem with the original testcase.

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348 --- Comment #12 from Michael Matz --- (In reply to Jakub Jelinek from comment #11) > before that region. If we can say for: > for (...) > { > unsigned char v[10]; > unsigned char *p = foo (v); > *p = 1; > unsigned c

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348 --- Comment #7 from Michael Matz --- No, this is not a problem in the stack slot sharing algorithm, but rather in the input. As presented to expand, and only showing the important parts, and reordering some BBs to make the flow more obvious: ;;

[Bug target/87561] [9 Regression] 416.gamess is slower by ~10% starting from r264866 with -Ofast

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561 --- Comment #9 from Michael Matz --- (In reply to Richard Biener from comment #8) > > I'm out of ideas suitable for GCC 9 (besides reverting the patch, reverting > to bogus state). Either that or some hack (e.g. artificially avoiding vectorizat

[Bug target/89545] ABI clarification for over-aligned type stack passing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 --- Comment #12 from Michael Matz --- (In reply to H.J. Lu from comment #11) > (In reply to Michael Matz from comment #10) > > Ah, I missed that. Yeah, I'd like to be co-owner. > > Please send me your gitlab account name. Err, right, that prob

[Bug target/89545] ABI clarification for over-aligned type stack passing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 --- Comment #10 from Michael Matz --- Ah, I missed that. Yeah, I'd like to be co-owner.

[Bug target/89545] ABI clarification for over-aligned type stack passing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 --- Comment #7 from Michael Matz --- What about this variant of the second part? diff --git a/x86-64-ABI/low-level-sys-info.tex b/x86-64-ABI/low-level-sys-info.tex index 66270b9..93b5e95 100644 --- a/x86-64-ABI/low-level-sys-info.tex +++ b/x86-6

[Bug target/89545] ABI clarification for over-aligned type stack passing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 --- Comment #2 from Michael Matz --- I think we should say something about the addresses of stack slots individual overaligned arguments as well (i.e. that the slot itself will also be aligned accordingly), not just for the overall effect.

  1   2   3   4   >