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
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,
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
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
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
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
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
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
>
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
>
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
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
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
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
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
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
>
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
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
>
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
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
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
>
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)
>
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
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:
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
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.
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
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) {
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
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?
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99188
Michael Matz changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
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
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))
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|
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
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
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
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
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
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
41 matches
Mail list logo
