rom LEB128. i.e. it is _super regular_. but we won't know how
it will do on density until we have the 32-bit opcodes.
Michael
isters (they could still be
memory-mapped, and be in fact offsets from a special base register that's
not exposed to GCC - perhaps that gives you the features you seek for your
mostly memory-safe guarantees?).
Ciao,
Michael.
ologically. netgull broke sooner as it
has no releases after gcc-10.1.0. I have not checked any non-US mirrors.
The release is present on ftp.gnu.org, but I know that you prefer to
encourage people to use other mirrors to keep traffic down.
Cheers,
—
Michael Leuchtenburg
Staff Software Engineer
m. 41
> On 17 Dec 2024, at 5:44 AM, Alexander Monakov wrote:
>
>
>> On Mon, 16 Dec 2024, Florian Weimer via Gcc wrote:
>>
>> I would like to provide a facility to create wrapper functions without
>> lots of argument shuffling. To achieve that, the wrapping function and
>> the wrapped function sho
Hello,
On Tue, 12 Nov 2024, Thomas Koenig via Gcc wrote:
> Am 12.11.24 um 17:25 schrieb Michael Matz via Gcc:
>
> > If you think of float as
> > approximated reals, then yes, division by zero is undefined (not
> > somewhat undefined!).
>
> Depends on how you look
o exempt 0.0 from being warned about, then we
would need to exempt all other constants C in 'x == C' as well, after all
x could (the compiler doesn't know in general) be used in '1 / (x - C)'.
Ciao,
Michael.
I like the sound of resolved path identity from search, including the
constructed full path and the index within include paths. if I was writing a
compiler from scratch, i'd problem do something like this:
SHA2(include-path-search-offset-integer-of-found-header-to-support-include-next)
+
SHA2
- Resolve 15+ bug reports
DDD's maintainers are Stefan Eickler and Michael Eager. Please
send questions or comments to mailto:d...@gnu.org.
Information about DDD, including how to download and build DDD sources,
can be found on the DDD project page: https://www.gnu.org/software/ddd/
--
Michael Eager
On 8/23/24 15:57, Michael Clark wrote:
On 8/23/24 15:46, Michael Clark wrote:
one more thing. it doesn't require PT_GNU_STACK or writable stacks
like GCC nested functions. 🙂 so I think it is safer but it does have
safety issues, mostly related to stack overflows but its going to need
On 8/23/24 15:46, Michael Clark wrote:
one more thing. it doesn't require PT_GNU_STACK or writable stacks like
GCC nested functions. 🙂 so I think it is safer but it does have safety
issues, mostly related to stack overflows but its going to need some
careful analysis with respect t
On 8/23/24 15:24, Michael Clark wrote:
On 8/15/24 06:24, Michael Clark wrote:
Hi Folks,
like I said this is crazy talk as alloca isn't even in the C standard.
but VLAs are, and the current implementation of VLAs depends on alloca.
one more thing. it doesn't require PT_GNU_STACK o
On 8/15/24 06:24, Michael Clark wrote:
Hi Folks,
*sending again with Thunderbird because Apple Mail munged the message*.
I wanted to share a seed of an idea I have been ruminating on for a
while, and that is being able to return alloca memory from a function.
I think it’s trivially possible
.
Michael L
Home Drafters
e
clumsy. If I could return alloca memory in a structure that would
largely solve this problem.
- https://github.com/michaeljclark/crefl
Regards,
Michael
or even just
convertible ones, and suchlike, but yeah, that sounds nice.
Ciao,
Michael.
Hello,
On Tue, 4 Jun 2024, Jakub Jelinek wrote:
> On Tue, Jun 04, 2024 at 07:43:40PM +0200, Michael Matz via Gcc wrote:
> > (Well, and without reverse-recognition of isfinite-like idioms in the
> > sources. That's orthogonal as well.)
>
> Why? If isfinite is bet
s and
ifns (instead of builtins) heeds it.
> A good solution would base this on (size) costs, the perfect solution
> would re-discover the builtins late and undo inlining that didn’t turn
> out to enable further simplification.
>
> How is inlined isdigit bad on AVR? Is a call really that cheap
> considering possible register spilling around it?
On AVR with needing to use 8bit registers to do everything? I'm pretty
sure the call is cheaper, yeah :)
Ciao,
Michael.
in advance
BR
Michael
ing (namely the config system of
libstdc++) needs to determine what is or isn't supported by the system in
order to correctly implement these abstractions. I.e. things you depend
on did the major lifting of hiding system divergence.
(Well, that, or you are very limited in the number of systems you support,
which can be the right thing as well!)
Ciao,
Michael.
like a problematic approach that may have been necessary
> decades ago, but it seems it may be time to move on.
I don't see that. Many aspects of systems remain non-standardized.
Ciao,
Michael.
nd have you looked at
other build systems? I have, and none of them are less complex, just
opaque in different ways from make+autotools).
Ciao,
Michael.
27;t share it with any other object".
If certain frontends find use for more fine-grained definitions of
life-times, then further note kinds need to be invented for those
frontends use. They likely won't have influence on the middle-end though
(perhaps for some sanitizers such new kinds might be useful?). But the
current BEGIN/END clobbers need to continue to mark the outermost borders
of storage validity for an object.
Ciao,
Michael.
x27; requires '-march' to subsume the 'M' extension
It seems to be trying to build test suites that are in conflict with my
march settings.
Interestingly, I didn't have this issue when trying to build the release
version tagged "releases/gcc-13.2.0". However, I wanted to use some
newer features that were only merged less than a month ago. I tried to
build the GIT tree and encountered this error. I attempted to bisect
the issue and found that it only happens when "gcc/DEV-PHASE" is set to:
experimental
I'm not very familar with GCC's build system, but this suggests to me
that the tests are only conditionally built on experimental/development
codebase snapshots.
Michael T. Kloos
e 'M' extension cc1plus: error:
'-mdiv' requires '-march' to subsume the 'M' extension It seems to be
trying to build test suites that are in conflict with my march settings.
Interestingly, I didn't have this issue when trying to build the release
version tagged "releases/gcc-13.2.0". However, I wanted to use some
newer features that were only merged less than a month ago. I tried to
build the GIT tree and encountered this error. I attempted to bisect
the issue and found that it only happens when gcc/DEV-PHASE is set to:
experimental I'm not very familar with GCC's build system, but this
suggests to me that the tests are only conditionally built on
experimental/development codebase snapshots. Michael T. Kloos
David Edelsohn via Gcc writes:
> n Fri, Aug 25, 2023 at 4:16 PM Michael Welsh Duggan via Gcc <
> gcc@gcc.gnu.org> wrote:
>
>> I am attempting to debug an issue in gcc (PR 110827, if curious). In
>> order to do this I have built a stage 1 compiler with debugging and
extensive command-line options, or
does this need to be installed? If the latter, what target do I use to
install the unoptimized stage 1 compiler?
--
Michael Welsh Duggan
(m...@md5i.com)
ffective it would be in practice. But it's very
non-trivial to do, and my guess is that it won't be super effective. So,
could be a typical research paper topic :-)
At least outside of extreme cases like the SSE regs, where none are
callee-saved, and which can be handled in a different way like the
explicit attributes.
Ciao,
Michael.
ons are marked with that attributes (and then of course do the
necessary call-save/restore).
Ciao,
Michael.
xoreax,eax
401028: c3 ret
401029: 0f 1f 80 00 00 00 00nopDWORD PTR [rax+0x0]
...
Testing with recent trunk works as well with no differences in output.
This is for x86_64-linux.
So, as suspected, something else is broken for you. Which compiler
version are you using? (And we need to check if it's something in the
mingw target)
Ciao,
Michael.
o complain if the value is outside the range [-1,
> 1].
... maybe not do that, at least optionally, that maybe somewhen someone
can look into fixing that all up? :-) -fdubious-bools?
Ciao,
Michael.
ng-code testcase ;)
(I'm saying that -1 should be replaced by something else for a wrong-code
testcase, because -1 is special and could justifieably be special-cased in
GCC: -1 is the proper arithmetic value for a signed boolean that is
"true").
Ciao,
Michael.
fully
solve it (even if it changes behaviour for you).
Ciao,
Michael.
being allocated on the stack during function expansion (see
expand_used_vars).
non-local variables are similarly handled, they are placed in various
lists that lead to appropriate assembler statements allocating static
storage for them (in the data or bss, or whatever other appropriate,
segment). They aren't defined (in the allocate-it sense) by gimple
statement either.
Ciao,
Michael.
t a mix. Exactly so to ...
> actually a minmax. Even if it allowed the cheap SSE constants,
> it wouldn't know that r84 is also zero (unless the expander checks that
> it is a pseudo with a single setter and verifies it or something similar).
... not have this problem.
Ciao,
Michael.
mpiler supporting all of C (otherwise you'd have to
resort to softfloat emulation). But I have no idea if the CPU and the DSP
parts are interconnected enough (hardware wise) to make that feasible (or
even required, maybe the CPU supports floating point itself already?).
> Michael, based on
tch
anyway :) (the current stuff from them/Infineon doesn't seem to be
GCC-based anymore?)
Ciao,
Michael.
came to be was explained in the thread.
Ciao,
Michael.
>
> Thank you
> ~Umesh
>
>
>
> On Tue, Jun 6, 2023 at 10:16 PM Segher Boessenkool
> wrote:
> >
> > Hi!
> >
> > On Tue, Jun 06, 2023 at 08:35:22PM +0530, Umesh Kalappa wrote:
> &
create a new one?
(FWIW: no, this should not be an error, a warning is fine, and I actually
think the current state of it not being in Wall is the right thing as
well)
Ciao,
Michael.
ith Florians proposal. I personally think the
arguments for upgrading the warnings to errors are _not_ strong enough,
but I don't think so very strongly :) )
Ciao,
Michael.
, improve the build process, fix a
number of bugs as well as make a number of enhancements.
DDD's maintainers are Stefan Eickler and Michael Eager. Please
send questions or comments to mailto:d...@gnu.org.
Information about DDD can be found on the DDD project page:
https://www.gnu.org/softwar
inimumNumber, but for background of the min/max woes:
https://754r.ucbtest.org/background/minNum_maxNum_Removal_Demotion_v3.pdf
In short: it's not so easy :-) (it may not be advisable to slavishly
follow 754-2008 for min/max)
> The NaN handling then possibly allows
> implementation with unordered compare + mask ops.
Ciao,
Michael.
e: never add something in (essentially) random places that is default
fallback anyway. (Obviously the above problem could be solved in a
different, more complicated, way. But this is the way it was solved since
about forever).
If mold doesn't look into {,/usr}/lib{,64} (as appropriate) by default
then that's the problem of mold.
Ciao,
Michael.
lems they would
need to special-case memory no matter what. (E.g. in GCC memory is dealt
with via the virtual operands, the '.MEM_x = VDEF<.MEM_y>' and VUSE
constructs you saw in the dumps, to make dealing with memory in an
SSA-based compiler at least somewhat natural).
Ciao,
Michael.
On 2/20/23 06:54, Joel Sherrill wrote:
On Mon, Feb 20, 2023 at 7:56 AM Vincent Fazio via Gcc <mailto:gcc@gcc.gnu.org>> wrote:
Michael, all,
Regarding:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101766
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10176
It's our round-about-way of passing the gcc options as the user gave
them downwards in case collect2 (a wrapper for the linking step for, gah,
don't ask) needs to call gcc itself recursively. But in the -### (or -v)
output, if the assembler is invoked in your example (i.e. cobol1 doesn't
fail for some reason) you should see your -I options being passed to that
one (wrongly so, of course :) ).
Ciao,
Michael.
> multiple source files", except that cobol1 accepts multiple source
> files on the command line, and iterates over them. If that's enough,
> then I'll set compiler::combinable to 1.
No good advise here for combinable. Try it :)
> As I mentioned, for a year I've been able to avoid the Specs Language,
> apparently because some things happen by default. The options defined
> in cobol/lang.opt are passed from gcobol to cobol1. The value of the
> -findicator-column option is available (but only if the option starts
> with "f"; -indicator-column doesn't work). cobol1 sees the value of
> -fmax-errors.
That's because "%{f*}" is contained in %(cc1_options): 'pass on all
options starting with "f"', and because you listed cc1_options in your
cobol1 command line.
Ciao,
Michael.
")
The "%@{I*F*}" is the one that makes gcc pass -Iwhatever to cc1 (and
ensures relative order with -F options is retained and puts all these into
an @file if one is given on the cmdline, otherwise leaves it on cmdline).
If you use the compiler driver then using '-v' when invoking it will
quickly tell you if that options passing worked, as it will show the
concrete command it exec's for the compiler proper.
Hope this helps.
Ciao,
Michael.
nk a
disrupting syntax change like that should have a higher bar than "in some
cases, depending on circumstance, we might even be able to warn".
Ciao,
Michael.
Joseph lists just in order to be able to write documentation when
there's a perfectly fine method to do so: comments.
Ciao,
Michael.
Hello,
On Wed, 16 Nov 2022, Paul Eggert wrote:
> On 2022-11-16 06:26, Michael Matz wrote:
> > char foobar(void);
> > int main(void) {
> >return &foobar != 0;
> > }
>
> That still has undefined behavior according to draft C23,
This is correct (and also h
n reserved and so the above definition
would have been wrong. I.e. I think adding the restriction wouldn't allow
the problematic situation either.
I'm aware that the argument would then invoke all the usual problems of
what constitutes a full program, and if that includes the library even
when not including headers and so on. And in any case currently the
standard does say they're reserved so it's idle speculation anyway :)
Ciao,
Michael.
xample at hand (because it doesn't
include e.g. and then printf wouldn't be reserved). A warning
is of course always okay and reasonable. As is, you could justify
erroring out, but I too think that would be overzealous.
Ciao,
Michael.
ronically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
> and thus no symbol reference remains in the resulting assembly.
Err, right, *head-->table*.
Playing with volatile should help:
char foobar(void);
char (* volatile ptr)(void);
int main(void) {
ptr = foobar;
return ptr != 0;
}
Ciao,
Michael.
l on most
platforms (after all it's not run).
The idea is so obvious that I'm probably missing something, why autoconf
can't use that idiom instead. But perhaps the (historic?) reasons why it
couldn't be used are gone now?
Ciao,
Michael.
ces are often compiled with defaults, and hence would change
semantics, which seems unattractive. New code can instead easily use
-std=c23 for a time.
E.g. c99/gnu99 (a largish deviation from gnu90) was never default and
gnu11 was made default only in 2014.
Ciao,
Michael.
I am trying to improve code generation for coremark to match a recent
improvement that was made in LLVM.
I added the following transformation to match.pd which attempts to
replace a branch with straight line code:
/* (cond (and (x , 0x1) == 0), y, (z ^ y) ) -> (-(and (x , 0x1)) & z ) ^
y */
general, that is not possible, and that case
> seems even quite common with C++. If the construction order is not
> known ahead of time, it is necessary to record it somewhere, so that
> destruction can happen in reverse. So I think storing things in .rodata
> is out.
Hmm, right. The basic idea could be salvaged by also pre-allocating a
linked list field in .data (or .tdata), and a per-object-file entry to
such list. But failable .init_array looks nicer to me right now.
Ciao,
Michael.
the thread-local ones it would need to store arguments to
__tls_get_addr).
Doing that or defining failure modes for ELF init/fini seems a better
design than hacking around the current limitation via counting static
cxa_atexit calls.
Ciao,
Michael.
form into
a dynamic tag or leave as note(s) in the PT_NOTE segment. The latter
wouldn't require any specific tooling support in the link editor. But the
consumer would have to iterate through all the notes to add the
individual counts together. Might be acceptable, though.
Ciao,
Michael.
On 17/08/22 7:10 pm, Richard Biener wrote:
Q. Why is it specifically of interest to GCC developers?
I think the best way to answer this is with questions. How can we model
a block-based iterator for a sparse array that is amenable to vectorization?
There are aspects to the zip_vector iterator
ves the ISC restriction that
all copies must include the copyright message, so while it is still
copyright material i.e. it is not public domain, it is, in fact,
compatible with the Apache Software License.
Please have a look at the benchmarks.
Regards,
Michael J. Clark
Twitter: @larkmjc
On Thu, Aug 04, 2022 at 03:53:55PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Aug 04, 2022 at 01:48:51PM -0400, Michael Meissner wrote:
> > At the moment, GCC 12 on the server PowerPC systems supports multiple
> > 128-bit
> > floating point types:
> >
&g
On Thu, Aug 04, 2022 at 10:14:10PM +0100, Jonathan Wakely wrote:
> On Thu, 4 Aug 2022 at 18:58, Michael Meissner via Gcc wrote:
> >
> > On Thu, Aug 04, 2022 at 10:49:24AM +0200, Nathan Sidwell wrote:
> > > Not a problem. I don't think I have anything to add- I presu
ompiled with previous GCC's that use explicit __ibm128 and
__float128 keywords. I don't how the users of these keywords (i.e. typically
libstdc++ and glibc developers, but potentially others as well).
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
them as
full fledged types, or are they just convenient ways to compile code with both
names rather than building two modules, with the different long double types?
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
evious GCC's that use explicit __ibm128 and
__float128 keywords. I don't how the users of these keywords (i.e. typically
libstdc++ and glibc developers, but potentially others as well).
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
On Fri, 15 Jul 2022 11:26:36 +1000, Nicholas Piggin wrote:
> Take the arm64 HWCAP documentation file and adjust it for powerpc.
>
>
Applied to powerpc/next.
[1/1] powerpc: add documentation for HWCAPs
https://git.kernel.org/powerpc/c/ef1911c6d26678b0e91fea33f076e98925997f0c
cheers
or
contains an uninformative expression (or one that isn't valid at the
program-counter gdb stops at), in which case you would want to look at
dwarf2out.cc:subrange_type_die or add_subscript_info (look for
TYPE_MAX_VALUE of the subscripts domain type). Hope this helps.
Ciao,
Michael.
Nicholas Piggin via Libc-alpha writes:
> This takes the arm64 file and adjusts it for powerpc. Feature
> descriptions are vaguely handwaved by me.
> ---
Thanks for attempting to document this.
> Anybody care to expand on or correct the meaning of these entries or
> bikeshed the wording of the in
access you would always need to ask 'is thise
for clock ticks, or is it a "real" volatile access for memmap IO'.
Ciao,
Michael.
;t have two files that differ only in casing. You need to find
a different solution, either consistently use .cc instead of .C, live with
the inconsistency or rename the base name of these files.
Ciao,
Michael.
>
> test-kunlun me/rename-testsuite-files
> Enumerating objects: 8
n at specific points in time.
So, I continue to see problems in precisely specifying what you want, _but
not more_.
I think all models in which you order the happening of UB with respect to
existing side effects (per abstract machine, so it includes modification
of objects!) have this same problem, it always becomes a side effect
itself (one where you don't specify what actually happens, but a side
effect nontheless) and hence becomes observable.
Ciao,
Michael.
not e.g. with other UB), and the
difficulty now is to define "some" and to create the dependency without
making that specific UB to be properly observable. I think to define this
all rigorously seems futile (you need a new category between observable
and UB), so it comes down to compiler QoI on a case by case basis.
Ciao,
Michael.
On Sun, Jan 02, 2022 at 11:58:29PM +0100, Thomas Koenig wrote:
> Hi Michael,
>
> > If you are building libraries that contain modules with multiple long double
> > types, you must use the '-mno-gnu-attribute'. We also use the '-Wno-psabi'
> > opt
y to force long double to be IBM 128-bit, no matter what the defaults
are use:
-mabi=iibmlongdouble -Wno-psabi -mno-gnu-attribute
The no-gnu-attribute says to disable setting the GNU attribute that says what
the default long double type is. It is necessary when building libraries with
both 128-
ubious joys of dynamic linking and use
> -static-libgfortran instead.
Yes, I tend to use -static-libgfortran for running Fortran spec things, and
-static-libstdc++ for C++, since it can be a quaqmire getting the right library
when you have several libraries on the system.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
in is to get access to newer libraries. I don't know
Ubuntu at all, but I believe the version that is installed is too old to have
the necessary changes in it. There isn't a LTS (long time support) version of
Ubuntu yet available that has the library. There are newer versions that
are
that is pointed to
# is incomplete. The msgfmt program then aborts because it doesn't have the
# right symbols. This script allows us to not use those environment variables.
unset LD_LIBRARY_PATH
unset RPATH_ENVVAR
for x in /usr/local/bin /usr/bin /bin; do
if [ -x "${x}/msgfmt"
On Mon, Nov 01, 2021 at 10:56:33AM -0500, Bill Schmidt wrote:
> Would starting from Advance Toolchain 15 with the most recent glibc make
> things easier for Thomas to test?
The problem is gcc135 runs Centos 7.x which is not compatible with AT 13-15.
--
Michael Meissner, IBM
PO Box 98
d glibc 2.34
or later.
> From 80d617264d80eb86806aecb2db5f37adb9b37ff6 Mon Sep 17 00:00:00 2001
> From: Michael Meissner
> Date: Fri, 29 Oct 2021 18:35:42 -0400
> Subject: [PATCH] Second patch for PowerPC Fortran KIND=16.
This replaces the first patch, and it is a work in progress. This patch
adds three target
On Fri, Oct 29, 2021 at 09:07:38PM +0200, Thomas Koenig wrote:
> Hi Michael,
>
> I tried this out on the one POWER machine where I can get something
> installed :-) It runs Ubuntu 20.04, but does not appear to have the
> right glibc version; it has
>
> $ lsb_release -a
thought it would be useful to share what I've done.
> From 443773ac040383311384577b48ecc0bd957ff328 Mon Sep 17 00:00:00 2001
> From: Michael Meissner
> Date: Thu, 28 Oct 2021 23:23:53 -0400
> Subject: [PATCH] Initial patch for PowerPC Fortran KIND=16
This is a work in progress pa
ailures, due to
libgfortran still being marked as IBM long double and the fortran modules are
marked as IEEE long double.
Right now, the only way to avoid these things is to build the entire toolchain
defaulting to IEEE 128-bit.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 014
unction address
plus this pointer.
There may be more items that can be imagined to be stuffed into a fat
function pointer.
So, I'm wondering what you are pondering about, to which extend you want
to go with fat function pointers, what the usecases will be, i.e. which
problem you want to solve :)
Ciao,
Michael.
t of args.
Or do you mean something else entirely? It might also help to know the
purpose of your question :)
Ciao,
Michael.
On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> On 07.10.21 05:35, Michael Meissner via Fortran wrote:
> > I tried this at one point. There are a lot of hidden assumptions that the
> > kind
> > number is the number of bytes. I'm sure it can be tracked
ld be nice if
any distro that changed the default used power9 as a base, instead of power8.
> Converting double-double to IEEE QP should not be hard or slow?
There are a lot of corner cases to get it right. IIRC, there are a few values
that double double can represent that are not expressable with exact precision
in IEEE 128-bit.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
support for the
LE systems. If there is BE glibc support, we could certainly add support for
enabling IEEE 128-bit in BE systems if the compiler was configured for power8
or higher.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
al purpose registers. An option that reflect AMODE(24)
would also be called -m24, despite the registers still being 32bit in
size.
Ciao,
Michael.
t;= 2
> succ edges to thread anything.
So, you are saying that any candidate thread path wouldn't have the latch
in the last position if it were just an empty forwarder? I simply wasn't
sure about that, so was conservative and only wanted to reject things I
knew where positively bad (namely code in the path following the latch
that is in danger of being moved into the latch).
Ciao,
Michael.
ter as suggested
above (only reject empty latches, and reject it only for the threaders
coming before the loop optims).
Ciao,
Michael.
not sure if the above check is _really_ testing it
wants to test or if the effects it achieves are side effects. Like in my
proposed patch: I could also test for existence of loop header in the
thread and reject that; it would work as well, except that it works
because any useful thread including a latch (which is the problematic one)
also includes the header. I'm not sure if the above check is in the same
line, or tests for some still another situation.
Ciao,
Michael.
Hello,
[lame answer to self]
On Wed, 8 Sep 2021, Michael Matz wrote:
> > > The forward threader guards against this by simply disallowing
> > > threadings that involve different loops. As I see
> >
> > The thread in question (5->9->3) is all within the sa
sable any backward threading when
any of the involved blocks is a latch when current_loops is set? (I guess
for that latter test to be effective you want to disable the
loop_optimizer_init() for the "late" jump thread passes)
Ciao,
Michael.
profitable_path_p() of
the backward threader wants to be careful in some situations involving
loops and latches; possibly it's not careful enough yet for the additional
power brought by ranger.
See also the additional tests tree-cfgcleanup.c:tree_forwarder_block_p is
doing when loops are active.
After the structural loop optimizers the threader can go wild and thread
everything it finds.
Ciao,
Michael.
illa updating) isn't done if that
place throws, so that should eventually be made more robust in the future.
Ciao,
Michael.
int converters are called
in a loop (which ultimately are the only interesting cases for
performance), where it's possible to load the constants before the loop
and keep them in registers (at the expense of two register pressure of
course) effectively removing the loads fro
ges can be fairly unintuitive,
e.g. there were old K8 CPUs where the memory loads for constants are
actually faster than the equivalent sequence of shifting and masking for
the >= compares. That's an irrelevant CPU now, but it shows that
intuition about speed consequences can be wrong.
Ciao,
Michael.
Hello,
On Wed, 4 Aug 2021, John Ericson wrote:
> On Wed, Aug 4, 2021, at 10:48 AM, Michael Matz wrote:
> > ... the 'as' and 'ld' executables should be simply found within the
> > version and target specific GCC libexecsubdir, possibly by being symlinks
&
a pedant strictly speaking
> the behavior is independent of whether the compiler is host == target or
> not.
Ciao,
Michael.
1 - 100 of 1313 matches
Mail list logo
