On Thu, 28 Sep 2023, Siddhesh Poyarekar wrote:
> Define a security process and exclusions to security issues for GCC and
> all components it ships.
Some typos and wording suggestions below.
> --- /dev/null
> +++ b/SECURITY.txt
> @@ -0,0 +1,205 @@
> +What is a GCC security bug?
> +=
Hi,
when using explicit register variables ('register int foo asm("%ebp");'),
using const/volatile type qualifiers on the declaration does not result in
the logically expected effect.
The main issue is that gcc-8 got "better" at propagating initializers of
'register const' variables to their uses
On Mon, 17 Jul 2023, Richard Biener wrote:
> > > > > OK. Btw, while I didn't spot this during review I would appreciate
> > > > > if the code could use vec.[q]sort, this should work with a lambda as
> > > > > well I think.
> > > >
> > > > That was my first use, but that hits
> > > > https://gc
On Fri, 21 Jul 2023, Xi Ruoyao via Gcc-patches wrote:
> Perhaps -ffp-contract=on (not off) is enough to fix the issue (if you
> are building GCC 14 snapshot). The default is "fast" (if no -std=
> option is used), which allows some contractions disallowed by the
> standard.
Not fully, see below
On Fri, 21 Jul 2023, Xi Ruoyao wrote:
> > See also PR 99903 for an earlier known issue which appears due to x87
> > excess precision and so tweaking -ffp-contract wouldn't help:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99903
>
> Does it affect AArch64 too?
Well, not literally (A
On Thu, 27 Jul 2023, Liu, Hongtao via Gcc-patches wrote:
> > +;; If the first and the second operands of ternlog are invariant and ;;
> > +the third operand is memory ;; then we should add load third operand
> > +from memory to register and ;; replace first and second operands with
> > +this reg
On Thu, 3 Aug 2023, Jeff Law wrote:
> The end goal here is to actually detect bitwise CRC implementations in the
> gimple optimizers and turn them into table lookups or carryless multiplies in
> RTL.
>
> Mariam has that working end-to-end and has proposed a talk for the Cauldron on
> the topic.
On Tue, 8 Aug 2023, Jeff Law wrote:
> That was my thinking at one time. Then we started looking at the distros and
> found enough crc implementations in there to change my mind about the overall
> utility.
The ones I'm familiar with are all table-based and look impossible to
pattern-match (and
On Tue, 8 Aug 2023, Jeff Law wrote:
> If the compiler can identify a CRC and collapse it down to a table or clmul,
> that's a major win and such code does exist in the real world. That was the
> whole point behind the Fedora experiment -- to determine if these things are
> showing up in the real
On Wed, 9 Aug 2023, Richard Biener via Gcc-patches wrote:
> The following teaches the non-loop reduction vectorization code to
> handle non-associatable reductions. Using the existing FOLD_LEFT_PLUS
> internal functions might be possible but I'd have to convince myself
> that +0.0 + x[0] is a s
On Fri, 11 Aug 2023, Richard Biener wrote:
> When we vectorize fold-left reductions with partial vectors but
> no target operation available we use a vector conditional to force
> excess elements to zero. But that doesn't correctly preserve
> the sign of zero. The following patch disables part
On Fri, 11 Aug 2023, Richard Biener wrote:
> > I think it converts SNan to QNan (when the partial vector has just one
> > element which is SNan), so is a test for -fsignaling-nans missing?
>
> Hm, I guess that's a corner case that could happen when there's no
> runtime profitability check on mo
On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote:
> 1. It makes it clear to users of the project the scope in which the project
> could be used and what safety it could reasonably expect from the project. In
> the context of GCC for example, it cannot expect the compiler to do a safety
> check of
On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote:
> There's no practical (programmatic) way to do such validation; it has to be a
> manual audit, which is why source code passed to the compiler has to be
> *trusted*.
No, I do not think that is a logical conclusion. What is the problem with
passing
On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
> Does this as the first paragraph address your concerns:
Thanks, this is nicer (see notes below). My main concern is that we shouldn't
pretend there's some method of verifying that arbitrary source code is "safe"
to pass to an unsandboxed compiler
On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
> > Thanks, this is nicer (see notes below). My main concern is that we
> > shouldn't pretend there's some method of verifying that arbitrary source
> > code is "safe" to pass to an unsandboxed compiler, nor should we push
> > the responsibility of
On Tue, 15 Aug 2023, David Edelsohn wrote:
> > Making users responsible for verifying that sources are "safe" is not okay
> > (we cannot teach them how to do that since there's no general method).
> > Making users responsible for sandboxing the compiler is fine (there's
> > a range of sandboxing
On Tue, 15 Aug 2023, Paul Koning wrote:
> Now I'm confused. I thought the whole point of what GCC is trying to, and
> wants to document, is that it DOES preserve security properties. If the
> source code is standards-compliant and contains algorithms free of security
> holes, then the compiler
On Tue, 15 Aug 2023, David Malcolm via Gcc-patches wrote:
> I'd prefer to reword this, as libgccjit was a poor choice of name for
> the library (sorry!), to make it clearer it can be used for both ahead-
> of-time and just-in-time compilation, and that as used for compilation,
> the host conside
> > Unfortunately the lines that follow:
> >
> >> either sanitized by an external program to allow only trusted,
> >> safe compilation and execution in the context of the application,
> >
> > again make a reference to a purely theoretical "external program" that
> > is not going to ex
On Wed, 16 Aug 2023, Siddhesh Poyarekar wrote:
> No I understood the distinction you're trying to make, I just wanted to point
> out that the effect isn't all that different. The intent of the wording is
> not to prescribe a solution, but to describe what the compiler cannot do and
> hence, use
On Wed, 16 Aug 2023, Siddhesh Poyarekar wrote:
> > Yeah, indicating scenarios that fall outside of intended guarantees should
> > be helpful. I feel the exact text quoted above will be hard to decipher
> > without knowing the discussion that led to it. Some sort of supplementary
> > section with
On Tue, 15 Aug 2023, Jeff Law wrote:
> Because if the compiler can optimize it automatically, then the projects have
> to do literally nothing to take advantage of it. They just compile normally
> and their bitwise CRC gets optimized down to either a table lookup or a clmul
> variant. That's t
On Wed, 16 Aug 2023, Philipp Tomsich wrote:
> > > I fully expect that latency to drop within the next 12-18 months. In that
> > > world, there's not going to be much benefit to using hand-coded libraries
> > > vs
> > > just letting the compiler do it.
>
> I would also hope that the hand-coded
On Tue, 11 Oct 2022, Jakub Jelinek wrote:
> So, does this mean one has to have gcc configured --with-arch=sm_70
> or later to make reverse offloading work (and then on the other
> side no support for older PTX arches at all)?
> If yes, I was kind of hoping we could arrange for it to be more
> user
On Wed, 12 Oct 2022, Tobias Burnus wrote:
> On 11.10.22 13:12, Alexander Monakov wrote:
> > My understanding is such trickery should not be necessary with
> > the barrier-based approach, i.e. the sequence of PTX instructions
> >
> >st % plain store
> >
> > > This grew insn-automata.cc from 201502 lines to 639968 lines and the
> > > build of the automata (genautomata) to several minutes in my dev tree.
> >
> > Yeah, in my unoptimized non-bootstrapped development tree genautomata
> > now takes over 12 minutes on a fast box, that is simply not accep
On Mon, 24 Oct 2022, Jan Hubička wrote:
> > By the way, it appears pre-existing znver[123] models are also causing
> > some kind
> > of combinatorial blow-up, but before znver4 it was not a blocking issue:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832
>
>
> It is really easy to make
When upgrading TLS access model based on optimized symbol visibility
status, we attempted to assert that recomputing the model would not
weaken it. It turns out that C, C++, and Fortran front-ends all can
(unintentionally) assign a stronger model than what can be derived
from the declaration.
Let'
On Wed, 26 Oct 2022, Kumar, Venkataramanan wrote:
> > Looking at znver1.md again, I think the problem is caused by incorrect
> > modeling of division instructions: they have descriptions like
> >
> > (define_insn_reservation "znver1_idiv_DI" 41
> > (and (eq_attr "cpu" "znve
1
From: Alexander Monakov
Date: Mon, 31 Oct 2022 17:35:57 +0300
Subject: [PATCH] i386: correct integer division modeling in znver.md
In znver.md, division instructions have descriptions like
(define_insn_reservation "znver1_idiv_DI" 41
(and (eq_attr &quo
b[dt]ver[123].md have similar issues.
Alexander Monakov (2):
i386: correct x87&SSE division modeling in znver.md
i386: correct x87&SSE multiplication modeling in znver.md
gcc/config/i386/znver.md | 67
1 file changed, 34 insertions(+),
Correct modeling of division instructions in the SIMD/FP domain for
AMD Zen architectures and avoid combinatorial explosion of automaton
tables by modeling the separate floating-point division unit and
correcting reservations to reflect reciprocal throughput of the
corresponding instructions, simil
All multiplication instructions are fully pipelined, except AVX256
instructions on Zen 1, which issue over two cycles on a 128-bit unit.
Correct the model accordingly to reduce combinatorial explosion in
automaton tables.
Top znver table sizes in insn-automata.o:
Before:
30056 r znver1_fp_min_is
New test.
> * gcc.dg/tls/vis-flag-hidden.c: New test.
> * gcc.dg/tls/vis-pragma-hidden-gd.c: New test.
> * gcc.dg/tls/vis-pragma-hidden.c: New test.
>
> Co-Authored-By: Alexander Monakov
> Signed-off-by: Artem Klimov
> ---
> gcc/ipa-visibility.cc
On Mon, 2 May 2022, Martin Jambor wrote:
> > Co-Authored-By: Alexander Monakov
>
> (Minor nit and I don't care too much, but in GCC we traditionally
> specify co-authors in the ChangeLog entry beginning by providing more
> names, one per line. But perhaps we want to
On Wed, 4 May 2022, Martin Liška wrote:
> The patch is a follow-up of the discussion we've got in:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593901.html
>
> Mold linker would appreciate knowing in advance if get_symbols_v3 is supported
> by a GCC plug-in or not.
>
> Ready to be instal
On Wed, 4 May 2022, Martin Liška wrote:
> On 5/4/22 14:32, Alexander Monakov wrote:
> > On Wed, 4 May 2022, Martin Liška wrote:
> >
> >> The patch is a follow-up of the discussion we've got in:
> >> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/5
On Thu, 5 May 2022, Richard Biener via Gcc-patches wrote:
> > I think they should simply try to not register LDPT_GET_SYMBOLS or
> > LDPT_GET_SYMBOLS_V2 with the plugin in the onload hook and if
> > that fails they will know the plugin doesn't support V3 only. I suppose
> > it should work to call
On Thu, 5 May 2022, Jan Hubicka wrote:
> Also note that visibility pass is run twice (once at compile time before
> early optimizations and then again at LTO). Since LTO linking may
> promote public symbols to local/hidden, perhaps we want to do this only
> second time the pass is executed?
The f
On Thu, 5 May 2022, Jan Hubicka wrote:
> > It follows from how local-dynamic model is defined: we call __tls_get_addr
> > with an argument that identifies the current DSO (not the individual
> > thread-local variable), and then compute the address of the variable with
> > a simple addition, so whe
On Thu, 5 May 2022, Martin Liška wrote:
> On 5/5/22 12:52, Alexander Monakov wrote:
> > Feels a bit weird to ask, but before entertaining such an API extension,
> > can we step back and understand the v3 variant of get_symbols? It is not
> > documented, and from what littl
On Mon, 2 May 2022, Alexander Monakov wrote:
> > > --- a/gcc/ipa-visibility.cc
> > > +++ b/gcc/ipa-visibility.cc
> > > @@ -872,6 +872,22 @@ function_and_variable_visibility (bool whole_program)
> > > }
> > > }
> > > }
> > &
On Mon, 9 May 2022, Jan Hubicka wrote:
> > On second thought, it might be better to keep the assert, and place the loop
> > under 'if (optimize)'?
>
> The problem is that at IPA level it does not make sense to check
> optimize flag as it is function specific. (shlib is OK to check it
> anywhere
On Wed, 23 Oct 2019, Eduard-Mihai Burtescu wrote:
> @@ -384,6 +384,14 @@ rust_demangle_callback (const char *mangled, int options,
> return 0;
>rdm.sym_len--;
>
> + /* Legacy Rust symbols also always end with a path segment
> + that encodes a 16 hex digit hash, i.e.
Ping.
On Sun, 5 Jan 2020, Alexander Monakov wrote:
> Hi,
>
> I noticed there's a costly signed 64-bit division in rtx_cost on x86 as well
> as
> any other target where UNITS_PER_WORD is implemented like TARGET_64BIT ? 8 :
> 4.
> It's also evident that rtx_cos
Ping.
On Sun, 5 Jan 2020, Alexander Monakov wrote:
> Hi,
>
> I noticed there's a costly signed 64-bit division in rtx_cost on x86 as well
> as
> any other target where UNITS_PER_WORD is implemented like TARGET_64BIT ? 8 :
> 4.
> It's also evident that rtx_cos
On Mon, 20 Jan 2020, H.J. Lu wrote:
> We can that only if function is static:
>
[ship asm]
>
> In this case, foo must be global.
H.J., can you rephrase more clearly? Your response seems contradictory and
does not help to explain the matter.
Alexander
On Mon, 20 Jan 2020, H.J. Lu wrote:
> For,
>
> ---
> __attribute__((target_clones("avx","default")))
> int
> foo ()
> {
> return -2;
> }
>
>
> foo's resolver must be global. For
>
> ---
> __attribute__((target_clones("avx","default")))
> static int
> foo ()
> {
> return -2;
> }
> --
On Mon, 20 Jan 2020, H.J. Lu wrote:
> > Bare IFUNC's don't seem to have this restriction. Why do we want to
> > constrain target clones this way?
> >
>
> foo's resolver acts as foo. It should have the same visibility as foo.
What do you mean by that? From the implementation standpoint, there
Hi,
we have this paragraph in the documentation that attempts to prohibit something
that is allowed by the language. Instead, I think we should say that this
generally should work and explain that a problem in GCC implementation
breaks this.
OK to apply?
Thanks.
Alexander
* doc/implem
On Mon, 20 Jan 2020, Sandra Loosemore wrote:
> I'm not happy with this -- we shouldn't be talking about internal concepts
> like GIMPLE and RTL in the GCC user manual. Can we instead talk about which
> user-visible optimization options cause problems, so that users who feel the
> urgent need to w
On Mon, 20 Jan 2020, Joseph Myers wrote:
> On Mon, 20 Jan 2020, Alexander Monakov wrote:
>
> > Hi,
> >
> > we have this paragraph in the documentation that attempts to prohibit
> > something that is allowed by the language. Instead, I think we should
> >
On Tue, 21 Jan 2020, Richard Biener wrote:
> Fourth. That PNVI (I assume it's the whole pointer-provenance stuff)
> wants to get the "best" of both which can never be done since a compiler
> needs to have a way to be conservative - in this area it's conflicting
> conservative treatment which is i
On Wed, 22 Jan 2020, Stefan Schulze Frielinghaus wrote:
> Hi David,
>
> In function `tree_cmp` an invariant [1] is assumed which does not necessarily
> exist. In case both input trees are finally compared via `strcmp`, then
>
> tree_cmp (t1, t2) == -tree_cmp (t2, t1)
>
> does not hold in g
On Thu, 23 Jan 2020, Martin Liška wrote:
> > So this doesn't help review including two different target changes. Making
> > ifunc dispatchers of public functions non-public looks like an unrelated
> > thing
> > to the bug (sorry if I mis-suggested). So I feel comfortable approving the
> > earli
On Thu, 23 Jan 2020, David Malcolm wrote:
> Removing the assertions fixes it for me (a stage1 build, at least, and
> it then passes the testsuite).
>
> I've made this blunder in four places in the analyzer:
>
> call-string.cc:162: call_string::cmp
> program-point.cc:461: function_point::cm
On Tue, 28 Jan 2020, Uecker, Martin wrote:
> > (*) this also shows the level of "obfuscation" needed to fool compilers
> > to lose provenance knowledge is hard to predict.
>
> Well, this is exactly the problem we want to address by defining
> a clear way to do this. Casting to an integer would be
On Tue, 28 Jan 2020, Uecker, Martin wrote:
> Unfortunately, this is not as simple. It is not trivial to
> define the set of objects whose "address could have participated
> in the computation"
> [...]
I am not satisfied with the response, but I'm not sure I should
continue arguing here.
Alexande
On Tue, 28 Jan 2020, Jeff Law wrote:
> On Tue, 2019-10-08 at 18:04 +0300, Alexander Monakov wrote:
> > On Thu, 3 Oct 2019, Jeff Law wrote:
> >
> > > You may want to review the 2018 discussion:
> > >
> > > https://www.mail-archive.com/gcc-patches@gcc.gn
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> I've not seen any follow-up to this version. Should we go ahead and adopt
> this?
Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED?
Spelling this with all-caps seems like a recent thing on gcc-patches, before
every
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> Upper case is what glibc has, though it appears that it's a rule that is not
> strictly followed. If we change it, then it becomes another friction point
> between developer groups. Personally, I'd leave it as is, then turn a blind
> eye to s
Ping^3.
On Sun, 5 Jan 2020, Alexander Monakov wrote:
> Hi,
>
> I noticed there's a costly signed 64-bit division in rtx_cost on x86 as well
> as
> any other target where UNITS_PER_WORD is implemented like TARGET_64BIT ? 8 :
> 4.
> It's also evident that rtx_cos
2On Sun, 8 Dec 2019, Jan Hubicka wrote:
> Other explanation would be that our new qsort with broken comparator due to
> overflow can actualy remove some entries in the array, but that sounds bit
> crazy.
gcc_qsort only reorders elements, making it possible for gcc_qsort_chk (that
runs afterwards)
On Tue, 10 Dec 2019, Jan Hubicka wrote:
> > I would recommend to make these variables uint64_t, then you can simply do
> >
> > tp_first_run_a--;
> > tp_first_run_b--;
> >
> > making 0 wrap around to UINT64_MAX. Then they will naturally sort after all
> > other nodes.
>
> Then we would still
Hi,
I'm posting an updated patch for GCC gdbinit originally proposed by Konstantin.
The patch amends debugging shorthands such as 'pr' to accept an explicit
argument, in addition to taking an implicit argument from $ as today. In other
words,
pr x
will be accepted to call 'debug_rtx (x)' just
Hi,
I noticed there's a costly signed 64-bit division in rtx_cost on x86 as well as
any other target where UNITS_PER_WORD is implemented like TARGET_64BIT ? 8 : 4.
It's also evident that rtx_cost does redundant work for a SET rtx argument.
Obviously the variable named 'factor' rarely exceeds 1, s
/valgrind-annotations-1.C: New test.
* g++.dg/valgrind-annotations-2.C: New test.
Co-authored-by: Alexander Monakov
---
Changes in v2:
* Take new clobber kinds into account.
* Do not link valgrind-interop.o into libgcc_s.so.
gcc/Makefile.in
I would like to propose Valgrind integration previously sent as RFC for trunk.
Arsen and Sam, since you commented on the RFC I wonder if you can have
a look at the proposed configure and documentation changes and let me
know if they look fine for you? For reference, gccinstall.info will say:
‘--e
/valgrind-annotations-1.C: New test.
* g++.dg/valgrind-annotations-2.C: New test.
Co-authored-by: Alexander Monakov
---
gcc/Makefile.in | 1 +
gcc/builtins.def | 3 +
gcc/common.opt|
On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> Does VALGRIND_MAKE_MEM_UNDEFINED macro ever change onarches once implemented
> there?
It seems Valgrind folks take binary compatibility seriously, so that sounds
unlikely.
> Wouldn't this be better done by emitting the sequence inline?
> Even if it is
On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> On Fri, Dec 08, 2023 at 06:43:19PM +0300, Alexander Monakov wrote:
> > On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> > > In your version, did the new function go just to libgcc.a or to
> > > libgcc_s.so.1?
> >
> >
On Sun, 10 Dec 2023, Richard Biener wrote:
> > It seems wrong to me: CLOBBER_EOL is documented to mean that the storage is
> > expiring at that point as well, which a (pseudo-)destructor does not imply;
> > it's perfectly valid to destroy an object and then create another in the
> > same storage.
On Tue, 12 Dec 2023, Jakub Jelinek wrote:
> On Mon, Dec 11, 2023 at 05:00:50PM -0500, Jason Merrill wrote:
> > In discussion of PR71093 it came up that more clobber_kind options would be
> > useful within the C++ front-end.
> >
> > gcc/ChangeLog:
> >
> > * tree-core.h (enum clobber_kind):
On Tue, 12 Dec 2023, Richard Biener wrote:
> On Tue, Dec 12, 2023 at 3:38 PM Jan Hubicka wrote:
> >
> > Hi,
> > this patch disables use of FMA in matrix multiplication loop for generic
> > (for
> > x86-64-v3) and zen4. I tested this on zen4 and Xenon Gold Gold 6212U.
> >
> > For Intel this is
t; will also do some regression testing.
Hi, I'm not sure at which court the ball is, but in the interest at moving
things forward here's the complete patch with the testcase. OK to apply?
---8<---
From: Alexander Monakov
Date: Fri, 13 Jan 2023 21:04:02 +0300
Subject: [PATCH] sche
On Wed, 8 Nov 2023, Richard Biener wrote:
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.dg/setjmp-7.c
> >> @@ -0,0 +1,13 @@
> >> +/* { dg-do compile } */
> >> +/* { dg-options "-O2 -fno-guess-branch-probability -w" } */
> >> +/* { dg-require-effective-target indirect_jumps } */
> >> +
> >> +str
On Thu, 9 Nov 2023, Maxim Kuvyrkov wrote:
> Hi Kewen,
>
> Below are my comments. I don't want to override Alexander's review, and if
> the patch looks good to him, it's fine to ignore my concerns.
>
> My main concern is that this adds a new entity -- forceful skipping of
> DEBUG_INSN-only bas
On Thu, 9 Nov 2023, Jeff Law wrote:
> > Yeah, I noticed that the scheduler takes care of DEBUG_INSNs as normal
> > operations. When I started to work on this issue, initially I wanted to try
> > something similar to your idea #2, but when checking the APIs, I realized
> > why not just skip the
On Fri, 10 Nov 2023, Richard Biener wrote:
> > I'm afraid ignoring debug-only BBs goes contrary to overall var-tracking
> > design:
> > DEBUG_INSNs participate in dependency graph so that schedulers can remove or
> > mutate them as needed when moving real insns across them.
>
> Note that debug
On Fri, 10 Nov 2023, Richard Biener wrote:
> On Fri, Nov 10, 2023 at 3:18 PM Alexander Monakov wrote:
> >
> >
> > On Fri, 10 Nov 2023, Richard Biener wrote:
> >
> > > > I'm afraid ignoring debug-only BBs goes contrary to overall
> > > >
On Sat, 11 Nov 2023, Arsen Arsenović wrote:
> > +#else
> > +# define VALGRIND_MAKE_MEM_UNDEFINED(ptr, sz) __builtin_trap ()
> > +#endif
> > +
> > +void __valgrind_make_mem_undefined (void *ptr, unsigned long sz)
> > +{
> > + VALGRIND_MAKE_MEM_UNDEFINED (ptr, sz);
> > +}
>
> Would it be preferab
On Sat, 11 Nov 2023, Sam James wrote:
> > Valgrind client requests are offered as macros that emit inline asm. For
> > use
> > in code generation, we need to wrap it in a built-in. We know that
> > implementing
> > such a built-in in libgcc is undesirable, [...].
>
> Perhaps less objectiona
On Mon, 13 Nov 2023, Richard Biener wrote:
> Another generic comment - placing a built-in call probably pessimizes code
> generation unless we handle it specially during alias analysis (or in
> builtin_fnspec).
But considering the resulting code is intended to be run under Valgrind,
isn't a bit
On Wed, 15 Nov 2023, Kewen.Lin wrote:
> >> And I suppose it would be OK to do that. Empty BBs are usually removed by
> >> CFG cleanup so the situation should only happen in rare corner cases where
> >> the fix would be to actually run CFG cleanup ...
> >
> > Yeah, sel-sched invokes 'cfg_cleanu
On Fri, 17 Nov 2023, Kewen.Lin wrote:
> > I don't think you can run cleanup_cfg after sched_init. I would suggest
> > to put it early in schedule_insns.
>
> Thanks for the suggestion, I placed it at the beginning of haifa_sched_init
> instead, since schedule_insns invokes haifa_sched_init, altho
On Mon, 20 Nov 2023, Maxim Kuvyrkov wrote:
> This patch avoids sched-deps.cc:find_inc() creating exponential number
> of dependencies, which become memory and compilation time hogs.
> Consider example (simplified from PR96388) ...
> ===
> sp=sp-4 // sp_insnA
> mem_insnA1[sp+A1]
> ...
> mem_insnA
On Mon, 20 Nov 2023, Maxim Kuvyrkov wrote:
> > On Nov 20, 2023, at 17:52, Alexander Monakov wrote:
> >
> >
> > On Mon, 20 Nov 2023, Maxim Kuvyrkov wrote:
> >
> >> This patch avoids sched-deps.cc:find_inc() creating exponential number
> >> of d
On Mon, 13 Nov 2023, Richard Biener wrote:
> > Ideally we'd position it such that more locals are put in SSA form,
> > but not too late to miss some UB, right? Perhaps after first pass_ccp?
>
> I guess it’s worth experimenting. Even doing it right before RTL expansion
> might work. Note if you
On Tue, 21 Nov 2023, Alexander Monakov wrote:
> I am concerned that if GCC ever learns to leave out the following access
> to 'this->foo', leaving tmp uninitialized, we will end up with:
>
> this->foo = 42;
Sorry, this store will be DSE'd out,
On Tue, 21 Nov 2023, Richard Biener wrote:
> and this, too, btw. - the DSE actually happens, the latter transform not.
> We specifically "opt out" of doing that for QOI to not make undefined
> behavior worse. The more correct transform would be to replace the
> load with a __builtin_trap () dur
On Tue, 21 Nov 2023, Maxim Kuvyrkov wrote:
> This patch avoids sched-deps.cc:find_inc() creating exponential number
> of dependencies, which become memory and compilation time hogs.
> Consider example (simplified from PR96388) ...
> ===
> sp=sp-4 // sp_insnA
> mem_i
cc-patches/20231024141124.210708-1-exactl...@ispras.ru/
Alexander Monakov (2):
libcpp: configure: drop unused Valgrind detection
gcc: configure: drop Valgrind 3.1 compatibility
gcc/config.in | 12 ---
gcc/configure | 80 +++--
gcc/configure.
When top-level configure has either --enable-checking=valgrind or
--enable-valgrind-annotations, we want to activate a couple of workarounds
in libcpp. They do not use anything from the Valgrind API, so just
delete all detection.
libcpp/ChangeLog:
* config.in: Regenerate.
* config
Our system.h and configure.ac try to accommodate valgrind-3.1, but it is
more than 15 years old at this point. As Valgrind-based checking is a
developer-oriented feature, drop the compatibility stuff and streamline
the detection.
gcc/ChangeLog:
* config.in: Regenerate.
* configure
Avoid using 'network sort' (a misnomer) in sort.cc, the correct term is
'sorting networks'.
gcc/ChangeLog:
* sort.cc: Use 'sorting networks' in comments.
---
gcc/sort.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/sort.cc b/gcc/sort.cc
index 9a0113fb62f.
On Fri, 15 Sep 2023, Richard Biener via Gcc-patches wrote:
> +@itemize @bullet
> +@item
> +When the result of negation, addition, subtraction or division of two signed
> +integers or signed integer vectors not subject to @option{-fwrapv} cannot be
> +represented in the type.
It would be a bit a
ffmpeg, zlib, bzip2, xz-utils, and zstd I'm aware of only
a single instance where bitwise CRC is used. It's in the table
initialization function in xz-utils. The compiler would transform that
to copying one table into another. Is that a valuable transform?
> Alexander Monakov:
> > U
On Tue, 26 Sep 2023, Jeff Law wrote:
> What ultimately pushed us to keep moving forward on this effort was
> discovering numerous CRC loop implementations out in the wild, including 4
> implementations (IIRC) in the kernel itself.
The kernel employs bitwise CRC only in look-up table generators.
On Thu, 18 Jul 2024, Richard Biener wrote:
> The following adds support for vector conditionals in C. The support
> was nearly there already but c_objc_common_truthvalue_conversion
> rejecting vector types. Instead of letting them pass there unchanged
> I chose to instead skip it when parsing
1 - 100 of 1023 matches
Mail list logo
