Hello,
On Thu, 4 Apr 2024, Richard Biener wrote:
> I have reworded the comment before the all-to-all conflict recording
> since it seemed to be confusing and missing the point - but maybe I
> am also missing something here.
The point of the comment was to explain how this differs from building
Hey,
On Wed, 27 Mar 2024, Jakub Jelinek wrote:
> > @@ -1712,12 +1711,9 @@ compute_idf (bitmap def_blocks, bitmap_head *dfs)
> >gcc_checking_assert (bb_index
> >< (unsigned) last_basic_block_for_fn (cfun));
> >
> > - EXECUTE_IF_AND_COMPL_IN_BITMAP
Hello,
On Tue, 27 Feb 2024, Jakub Jelinek wrote:
> On Tue, Feb 27, 2024 at 10:13:14AM +0100, Jakub Jelinek wrote:
> > For __libc_start_main, glibc surely just could use no_callee_saved_registers
> > attribute, because that is typically the outermost frame in backtrace,
> > there is no need to
Hello,
On Mon, 26 Feb 2024, Jakub Jelinek wrote:
> > Will update the patch, I think any improvement should be done
> > to get_range_pos_neg (it's a bit odd in behavior for unsigned
> > but I have only signed things incoming).
>
> For unsigned if it always returned 1, it would be quite useless,
Hi,
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> > Hmm, shouldn't you be able to use (nonexistence of) the PREV_WHITE flag on
> > the second COLON token to see that it's indeed a '::' without intervening
> > whitespace? Instead of setting a new flag on the first COLON token?
> >
> > I.e.
Hello,
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> So, the following patch adds a flag during preprocessing at the point
> where we normally create CPP_SCOPE tokens out of 2 consecutive colons
> on the first CPP_COLON to mark the consecutive case (as we are tight
> on the bits, I've reused the
Hello,
On Wed, 17 Jan 2024, Ajit Agarwal wrote:
> > first is even, since OOmode is only ok for even vsx register and its
> > size makes it take two consecutive vsx registers.
> >
> > Hi Peter, is my understanding correct?
> >
>
> I tried all the combination in the past RA is not allocating
On Tue, 10 Oct 2023, Roger Sayle wrote:
>
> This patch is the middle-end piece of an improvement to PRs 101955 and
> 106245, that adds a missing simplification to the RTL optimizers.
> This transformation is to simplify (char)(x << 7) != 0 as x & 1.
Random observation:
So, why restrict to
Hey,
On Thu, 10 Aug 2023, Martin Uecker wrote:
> > offset(struct foo_flex, t[0]) + N * sizeof(foo->t);
> >
> > With GCC, offset(struct foo_flex,t[0]) == 6, which is also correct.
>
> This formula might be considered incorrect / dangerous because
> it might allocate less storage than
Hello,
On Wed, 9 Aug 2023, Qing Zhao wrote:
> > So, should the equivalent FAM struct also have this sizeof()? If no:
> > there should be a good argument why it shouldn't be similar to the non-FAM
> > one.
>
> The sizeof() of a structure with FAM is defined as: (after I searched online,
> I
Hello,
On Wed, 9 Aug 2023, Qing Zhao wrote:
> Although this is an old FAM related issue that does not relate to my current
> patch
> (and might need to be resolved in a separate patch). I think that it’s
> necessary to have
> more discussion on this old issue and resolve it.
>
> The first
Hello,
On Wed, 9 Aug 2023, Zhang, Annita via Gcc-patches wrote:
> > The question is whether you want to mandate the 16-bit floating point
> > extensions. You might get better adoption if you stay compatible with
> > shipping
> > CPUs. Furthermore, the 256-bit tuning apparently benefits
Hello,
On Tue, 8 Aug 2023, Martin Uecker via Gcc-patches wrote:
> There at least three different size expression which could
> make sense. Consider
>
> short foo { int a; short b; char t[]; };
>
> Most people seem to use
>
> sizeof(struct foo) + N * sizeof(foo->t);
>
> which for N == 3
Hello,
On Tue, 8 Aug 2023, Jakub Jelinek via Gcc-patches wrote:
> What I'd really like to avoid is having all compiler bugs (primarily ICEs)
> considered to be security bugs (e.g. DoS category), it would be terrible to
> release every week a new compiler because of the "security" issues.
>
Hello,
On Tue, 1 Aug 2023, Joseph Myers wrote:
> > Only because cmpxchg is defined in terms of memcpy/memcmp. If it were
> > defined in terms of the == operator (obviously applied recursively
> > member-wise for structs) and simple-assignment that wouldn't be a problem.
>
> It also
Hello,
On Mon, 31 Jul 2023, Martin Uecker wrote:
> > Say you have a loop like so:
> >
> > _Atomic T obj;
> > ...
> > T expected1, expected2, newval;
> > newval = ...;
> > expected1 = ...;
> > do {
> > expected2 = expected1;
> > if (atomic_compare_exchange_weak(, , newval);
> > break;
>
Hello,
On Fri, 28 Jul 2023, Martin Uecker wrote:
> > > Sorry, somehow I must be missing something here.
> > >
> > > If you add something you would create a new value and this may (in
> > > an object) have random new padding. But the "expected" value should
> > > be updated by a failed
Hello,
On Mon, 17 Jul 2023, Richard Sandiford via Gcc-patches wrote:
> >> There are some existing attributes that similarly affect semantics
> >> in ways that cannot be ignored. vector_size is one obvious example.
> >> But that doesn't make it a good thing. :)
> >...
> > If you had added
Hey,
On Tue, 11 Jul 2023, Alexander Monakov via Gcc-patches wrote:
> > > > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered
> > >
> > > This is the weak/active form; I'd suggest "preserve_high_sse".
> >
> > But it preserves only the low parts :-) You swapped the two in your
Hello,
On Mon, 10 Jul 2023, Alexander Monakov wrote:
> I think the main question is why you're going with this (weak) form
> instead of the (strong) form "may only clobber the low XMM regs":
I want to provide both. One of them allows more arbitrary function
definitions, the other allows more
Hello,
On Tue, 11 Jul 2023, Jan Hubicka wrote:
> > > > When a function doesn't contain calls to
> > > > unknown functions we can be a bit more lenient: we can make it so that
> > > > GCC simply doesn't touch xmm8-15 at all, then no save/restore is
> > > > necessary.
>
> One may also take into
Hello,
the ELF psABI for x86-64 doesn't have any callee-saved SSE
registers (there were actual reasons for that, but those don't
matter anymore). This starts to hurt some uses, as it means that
as soon as you have a call (say to memmove/memcpy, even if
implicit as libcall) in a loop that
Hello,
On Thu, 27 Apr 2023, Jakub Jelinek wrote:
> The first really large error I see is for sinl with
> x/2gx
> 0x748160ed90d9425b0xefd8b811d6293294
> i.e.
> 1.5926552660973502228303666578452949e+253
> with most significant double being
> 1.5926552660973502e+253
> and low double
>
Hello,
On Wed, 26 Apr 2023, Jakub Jelinek via Gcc-patches wrote:
> For glibc I've gathered data from:
> 4) using attached ulp-tester.c (how to invoke in file comment; tested
>both x86_64, ppc64, ppc64le 50M pseudo-random values in all 4 rounding
>modes, plus on x86_64 float/double
Hello,
On Wed, 18 Jan 2023, Jakub Jelinek wrote:
> > > > > Partly OT, what is riscv not defaulting that on as well? Does it have
> > > > > usable unwind info even without that option, something else?
> > > >
> > > > The RISC-V ABI does not address this, AFAICS.
> > >
> > > And neither do many
Hello,
On Wed, 18 Jan 2023, Jakub Jelinek wrote:
> On Wed, Jan 18, 2023 at 04:09:08PM +0100, Andreas Schwab wrote:
> > On Jan 18 2023, Jakub Jelinek wrote:
> >
> > > Partly OT, what is riscv not defaulting that on as well? Does it have
> > > usable unwind info even without that option,
On Wed, 18 Jan 2023, Andreas Schwab via Gcc-patches wrote:
> No unwind tables are generated, as if -funwind-tables is ignored. If
> LTO is disabled, everything works as expected.
On Risc-V btw. (which, unlike i386,aarch64,s390,rs6000 does not
effectively enable funwind-tables always via
Hello,
On Thu, 10 Nov 2022, Martin Liška wrote:
> > These changes are part of
> > commit r13-2361-g7e0db0cdf01e9c885a29cb37415f5bc00d90c029
> > "STABS: remove -gstabs and -gxcoff functionality". What this does is
> > remove these identifiers from "poisoning":
> >
> > /* As the last action
Hello,
On Thu, 10 Nov 2022, Martin Liška wrote:
> This is a patch which adds support for Sphinx in lib*/Makefile.am where
> I wrongly modified Makefile.in that are generated.
>
> One thing that's missing is that the generated Makefile.in does not
> contain 'install-info-am' target and thus the
Hello,
On Wed, 9 Nov 2022, Martin Liška wrote:
> I think we should remove documentation for unsupported GCC releases
> as it's indexed by Google engine. Second reason is that the page is long
> one one can't easily jump to Current development documentation.
>
> Thoughts?
I think everything
Hey,
On Thu, 20 Oct 2022, Thomas Schwinge wrote:
> This had been done in
> wwwdocs commit 5c7ecfb5627e412a3d142d8dc212f4cd39b3b73f
> "Document deprecation of OpenMP MIC offloading in GCC 12".
>
> I'm sad about this, because -- in theory -- such a plugin is very useful
> for offloading
Hello,
On Tue, 11 Oct 2022, Jørgen Kvalsvik wrote:
> I apologise for the confusion. The diff there is not a part of the
> change itself (note the indentation) but rather a way to reproduce,
Ah! Thanks, that explains it, sorry for adding confusion on top :-)
Ciao,
Michael.
Hello,
On Tue, 11 Oct 2022, Jørgen Kvalsvik via Gcc-patches wrote:
> The coverage support will under some conditions decide to split edges to
> accurately report coverage. By running the test suite with/without this
> edge splitting a small diff shows up, addressed by this patch, which
> should
Hello,
On Tue, 20 Sep 2022, Aldy Hernandez wrote:
> > FWIW, in IEEE, 'abs' (like 'copy, 'copysign' and 'negate') are not
> > arithmetic, they are quiet-computational. Hence they don't rise
> > anything, not even for sNaNs; they copy the input bits and appropriately
> > modify the bit pattern
Hello,
On Mon, 19 Sep 2022, Richard Biener via Gcc-patches wrote:
> > but I guess it's good we do the right thing for correctness sake, and
> > if it ever gets used by someone else.
> >
> > >
> > > That said, 'set_nonnegative' could be interpreted to be without
> > > NaNs?
> >
> > Sounds good to
Hello,
okay, I'll bite :) DBG_REGISTER_NUMBER? DEBUGGER_REGNO?
Ciao,
Michael.
Hello,
On Wed, 3 Aug 2022, Jeff Law via Gcc-patches wrote:
> > .optimized dump shows:
> >_1 = ABS_EXPR ;
> >_3 = _1 & 1;
> >return _3;
> >
> > altho combine simplifies it to x & 1 on RTL, resulting in code-gen:
> > f1:
> > and w0, w0, 1
> > ret
> Doesn't the
Hello,
On Wed, 25 May 2022, Richard Biener via Gcc-patches wrote:
> I guess we might want to (warn about labels in the "toplevel"
> scope in switch statements). So warn about
>
> switch (x)
> {
> case 1:
> bar:
> };
That style is actually used quite some time in GCC itself. Sometimes with
Hello,
On Wed, 13 Apr 2022, Roger Sayle wrote:
> The x86 instruction encoding for SImode andn is longer than the
> equivalent notl/andl sequence when the source for the not operand
> is the same register as the destination.
_And_ when no REX prefixes are necessary for the notl,andn, which they
Hi,
On Thu, 10 Feb 2022, Richard Biener via Gcc-patches wrote:
> On Wed, Feb 9, 2022 at 2:21 PM Thomas Schwinge
> wrote:
> >
> > Hi!
> >
> > OK to push (now, or in next development stage 1?) the attached
> > "Consider 'TDF_UID', 'TDF_NOUID' in 'print_node_brief', 'print_node'",
> > or should
Hello,
On Wed, 9 Feb 2022, Richard Biener wrote:
> > That breaks down when a birth is there (because it was otherwise
> > reachable) but not on the taken path:
> >
> > if (nevertrue)
> > goto start;
> > goto forw;
> > start:
> > {
> > int i;
> > printf("not really
Hey,
On Tue, 8 Feb 2022, Joseph Myers wrote:
> On Tue, 8 Feb 2022, Richard Biener via Gcc-patches wrote:
>
> > which I think is OK? That is, when the abstract machine
> > arrives at 'int i;' then the previous content in 'i' goes
> > away? Or would
>
> Yes, that's correct. "If an
Hello,
On Tue, 8 Feb 2022, Richard Biener wrote:
> > int state = 2, *p, camefrom1 = 0;
> > for (;;) switch (state) {
> > case 1:
> > case 2: ;
> > int i;
> > if (state != 1) { p = i = 0; }
> > if (state == 1) { (*p)++; return *p; }
> > state = 1;
> > continue;
> > }
> >
Hello,
On Tue, 8 Feb 2022, Richard Biener wrote:
> int foo(int always_true_at_runtime)
> {
> {
> int *p;
> if (always_true_at_runtime)
> goto after;
> lab:
> return *p;
> after:
> int i = 0;
> p =
> if (always_true_at_runtime)
> goto lab;
> }
> return
Hello,
On Thu, 3 Feb 2022, Richard Biener via Gcc-patches wrote:
> /* Preserve explicit divisions by 0: the C++ front-end wants to detect
>undefined behavior in constexpr evaluation, and assuming that the
> division
>traps enables better optimizations than these anyway. */
> (for div
Hello,
On Thu, 3 Feb 2022, Richard Biener via Gcc-patches wrote:
> > > It indeed did occur to me as well, so as we're two now I tried to
> > > see how it looks like. It does like the following (didn't bother to
> > > replace all build_clobber calls but defaulted the parameter - there
> > >
Hello,
On Thu, 3 Feb 2022, Richard Biener wrote:
> > > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers this
> > > marks the end-of-life of storage as opposed to just ending the lifetime
> > > of the object that occupied it. The dangling pointer diagnostics uses
> > >
Hello,
On Wed, 2 Feb 2022, Richard Biener via Gcc-patches wrote:
> This adds a flag to CONSTRUCTOR nodes indicating that for clobbers this
> marks the end-of-life of storage as opposed to just ending the lifetime
> of the object that occupied it. The dangling pointer diagnostics uses
>
Hello,
On Mon, 20 Dec 2021, Uros Bizjak wrote:
> > Thanks.
> > I see nobody commented on Micha's post there.
> >
> > Here is a patch that implements it in GCC, i.e. C++ doesn't change ABI (at
> > least
> > not from the past few releases) and C does for GCC:
> >
> > 2021-12-15 Jakub Jelinek
>
Hello,
On Thu, 25 Nov 2021, Richard Biener via Gcc-patches wrote:
> It seems to be a style to place gcc_unreachable () after a
> switch that handles all cases with every case returning.
> Those are unreachable (well, yes!), so they will be elided
> at CFG construction time and the middle-end
Hello,
On Thu, 25 Nov 2021, Richard Biener wrote:
> > Yes, that's definitely the case - I was too lazy to re-use the old
> > option name here. But I don't have a good name at hand, maybe clang
> > has an option covering the cases I'm thinking about.
As you asked: I already have difficulties to
Hello,
On Wed, 24 Nov 2021, Richard Biener wrote:
> >> +/* Unreachable code in if (0) block. */
> >> +void baz(int *p)
> >> +{
> >> + if (0)
> >> + {
> >> +return; /* { dg-bogus "not reachable" } */
> >
> >Hmm? Why are you explicitely saying that warning here would be bogus?
>
Hello,
> +/* Unreachable code in if (0) block. */
> +void baz(int *p)
> +{
> + if (0)
> + {
> +return; /* { dg-bogus "not reachable" } */
Hmm? Why are you explicitely saying that warning here would be bogus? It
quite clearly _is_ unreachable, so warning there makes sense.
Hello,
On Mon, 18 Oct 2021, Richard Sandiford wrote:
> > (It's a really cute hack that works as a micro optimization, the question
> > is, do we really need to go there already, are all other less hacky
> > approaches not bringing similar improvements? The cuter the hacks the
> > less often
Hello,
On Thu, 14 Oct 2021, Richard Biener via Gcc-patches wrote:
> > I have bisected an AMD zen2 10% performance regression of SPEC 2006 FP
> > 433.milc bechmark when compiled with -Ofast -march=native -flto to this
> > commit. See also:
> >
> >
> >
Hello,
On Thu, 14 Oct 2021, Richard Biener wrote:
> > So, at _this_ write-through of the email I think I like the above idea
> > best: make ao_ref be a tree (at least its storage, because it currently
> > is a one-member-function class), make ao_ref.volatile_p be
> > tree_base.volatile_flag
Hello,
[this is the fourth attempt to write a comment/review/opinion for this
ao_ref-in-tcc_reference, please accept some possible incoherence]
On Tue, 12 Oct 2021, Richard Biener via Gcc-patches wrote:
> This prototype hack introduces a new tcc_reference TREE_AOREFWRAP
> which we can use to
Hello,
On Sat, 9 Oct 2021, apinski--- via Gcc-patches wrote:
> + (lshift (convert (convert:boolean_type_node @0)) { shift; })))
> +/* a ? -1 : 0 -> -a. No need to check the TYPE_PRECISION not being 1
> + here as the powerof2cst case above will handle that case correctly.
> */
Hello,
On Tue, 5 Oct 2021, Richard Biener wrote:
> > First notice that this doesn't have an empty latch block to start with
> > (in fact, there is no separate latch block at all), so the loop
> > optimizers haven't been initialized for simple latches at this point.
> > Still, I would say
Hello,
On Mon, 4 Oct 2021, Jeff Law wrote:
> And just in case it got lost. Here's the analysis on 960218-1 on visium:
>
> We've got this going into ethread:
>
> int f (int x)
> {
> int D.1420;
> int a;
>
> ;; basic block 2, loop depth 0, maybe hot
> ;; prev block 0, next block 3,
Hello,
On Thu, 16 Sep 2021, Richard Biener via Gcc-patches wrote:
> > Typically for the native_interpret/native_encode we punt if
> > BITS_PER_UNIT != 8 || CHAR_BIT != 8 because nobody had the energy to
> > deal with the weird platforms (especially if we have currently none, I
> > believe
Hello,
On Mon, 13 Sep 2021, Aldy Hernandez via Gcc-patches wrote:
The testcase still tests what it's supposed to test with ...
> > typedef unsigned short uint16_t;
> >
> > uint16_t a, b;
> >
> > int *j_global;
> > uint16_t f(void)
> > {
> >int c, **p;
> >short d = 2, e = 4;
> >
... "c
Hello,
On Mon, 13 Sep 2021, Jeff Law via Gcc-patches wrote:
> > So it looks like there's some undefined behavior going on, even before
> > my patch. I'd like to get some feedback, because this is usually the
> > type of problems I see in the presence of a smarter threader... things
> > get
Hello,
On Fri, 10 Sep 2021, Richard Biener via Gcc-patches wrote:
> diagnostic from the Ada frontend. The warnings are pruned from the
> testsuite output via prune_gcc_output but somehow this doesn't work
> for the tests in gfortran.dg/debug which are now failing with excess
> errors. That
Hello,
On Fri, 10 Sep 2021, Aldy Hernandez via Gcc-patches wrote:
> Like this?
Yep, but I can't approve.
Ciao,
Michael.
Hi,
On Fri, 10 Sep 2021, Aldy Hernandez via Gcc-patches wrote:
> }
> +
> + /* Threading through a non-empty latch would cause code to be added
"through an *empty* latch". The test in code is correct, though.
And for the before/after loops flag you added: we have a
cfun->curr_properties
Hello,
On Tue, 10 Aug 2021, Jakub Jelinek via Gcc-patches wrote:
> > +# Place ISO_Fortran_binding.h also under include/ in the build directory
> > such
> > +# that it can be used for in-built-tree testsuite runs without
> > interference of
> > +# other files in the build dir - like intrinsic
Hello,
On Thu, 1 Jul 2021, Richard Sandiford wrote:
> Well, it does feel like this is pressing the reset button on a thread
> whose message count is already in the high double figures. There's a
> risk that restarting the discussion now is going to repeat a lot of the
> same ground, probably at
Hello,
On Thu, 1 Jul 2021, Martin Liška wrote:
> On 7/1/21 3:33 PM, Eli Zaretskii wrote:
> > > Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> > > From: Martin Liška
> > > Date: Thu, 1 Jul 2021 14:44:10 +0200
> > >
> > > > It helps some, but not all of the issues
Hello,
On Thu, 1 Jul 2021, Richard Biener wrote:
> diff --git a/gcc/gimple-loop-interchange.cc b/gcc/gimple-loop-interchange.cc
> index 43045c5455e..43ef112a2d0 100644
> --- a/gcc/gimple-loop-interchange.cc
> +++ b/gcc/gimple-loop-interchange.cc
> @@ -1043,8 +1043,11 @@
Hello,
I haven't followed this thread too closely, in particular I haven't seen
why the current form of the .DEFERRED_INIT call was chosen or suggested,
but it triggered my "well, that's obviously wrong" gut feeling; so sorry
for stating something which might be obvious to thread participants
Hello,
On Tue, 8 Jun 2021, Jeff Law wrote:
> On 6/8/2021 9:06 AM, H.J. Lu wrote:
> > On Tue, Jun 8, 2021 at 7:56 AM Jakub Jelinek via Gcc-patches
> > wrote:
> >> On Tue, Jun 08, 2021 at 08:47:26AM -0600, Jeff Law wrote:
> Why is the machinery involving STACK_SLOT_ALIGNMENT and
>
Hello,
On Mon, 7 Jun 2021, Jeff Law wrote:
>
> So, as many of you know I left Red Hat a while ago and joined Tachyum. We're
> building a new processor and we've come across an issue where I think we need
> upstream discussion.
>
> I can't divulge many of the details right now, but one of the
Hello,
On Tue, 1 Jun 2021, Martin Liška wrote:
> On 5/31/21 5:49 PM, Michael Matz wrote:
> > Hello Martin,
> >
> > On Mon, 31 May 2021, Martin Liška wrote:
> >
> >> I've made quite some progress with the porting of the documentation and
> >> I
Hello Martin,
On Mon, 31 May 2021, Martin Liška wrote:
> I've made quite some progress with the porting of the documentation and
> I would like to present it to the community now:
> https://splichal.eu/scripts/sphinx/
>
> Note the documentation is automatically ([1]) generated from texinfo
Hello,
On Fri, 28 May 2021, Bernd Edlinger wrote:
> >> I was wondering, why gimple-match.c and generic-match.c
> >> are not built early but always last, which slows down parallel
> >> makes significantly.
> >>
> >> The reason seems to be that generated_files does not
> >> mention gimple-match.c
Hello,
On Mon, 3 May 2021, Jan Hubicka wrote:
> > (it should not abort). The documentation of 'pure' must be read
> > as that 'pure' is not valid for 'foo' since throwing an exception
> > is obviously an observable effect on the state of the program
> > (in particular for the testcase at hand).
Hello,
On Wed, 7 Apr 2021, Martin Liška wrote:
> > I like the output quite a bit, especially that things like option
> > references are automagically linked to their documentation. I spent
> > just a bit of time looking through the HTML and PDF above and found
> > a few minor issues. I suspect
Hello,
On Mon, 30 Nov 2020, Jeff Law wrote:
> >> So, then let's start with one of
> >> the prime examples of SSA deconstruction problems, the lost swap, and how
> >> it comes to be: we start with a swap:
> >>
> >> x = ..., y = ...
> >> if (cond)
> >> tmp=x, x=y, y=tmp
> >>
> >> (1)
Hello,
On Thu, 26 Nov 2020, Richard Sandiford via Gcc-patches wrote:
> >> The aim is only to provide a different view of existing RTL instructions.
> >> Unlike gimple, and unlike (IIRC) the old RTL SSA project from way back,
> >> the new framework isn't a “native” SSA representation. This means
Hello,
On Wed, 16 Sep 2020, Richard Biener wrote:
> This removes the canonicalization of X + -CST to X - CST to facilitate
> SLP vectorization analysis where we currently treat the added testcase
> as two-operation plus blend vectorization opportunity. While there
> may be the possibility to
Hello,
On Tue, 8 Sep 2020, Richard Biener wrote:
> CCing some people to double-check my graph partitioning algorithm.
I seem to not know the pre-existing data structures enough to say anything
about this, but I noticed small things which might or might not indicate
thinkos or incompleteness:
Hello,
On Tue, 19 May 2020, Jakub Jelinek wrote:
> On Tue, May 19, 2020 at 05:21:16PM +0100, Richard Earnshaw wrote:
> > This is really a wart in the GNU coding style. And one reason why I
> > tend to indent such labels by a single space. It particularly affects
> > things like class
Hello,
On Tue, 19 May 2020, Martin Liška wrote:
> > The common problems I remember is that e.g. when changing a function comment
> > above some function, it is attributed to the previous function rather than
> > following, labels in function confusing it:
> > void
> > foo ()
> > {
> >
Hello,
On Mon, 18 May 2020, Florian Weimer wrote:
> * Michael Matz:
>
> >> So does -fcf-protection. -fno-omit-frame-pointer does not work for me at
> >> all for some reason, the frame pointer is always missing?
> >
> > Not for me:
>
> I see. I did
Hello,
On Mon, 18 May 2020, Florian Weimer wrote:
> >> In glibc, we already have this:
> >>
> >> /* Used to disable stack protection in sensitive places, like ifunc
> >>resolvers and early static TLS init. */
> >> #ifdef HAVE_CC_NO_STACK_PROTECTOR
> >> # define inhibit_stack_protector \
>
Hello,
On Mon, 18 May 2020, Florian Weimer via Gcc-patches wrote:
> > The patch adds new no_stack_protect attribute. The change is requested
> > from kernel folks and is direct equivalent of Clang's no_stack_protector.
> > Unlike Clang, I chose to name it no_stack_protect because we already
> >
Hello,
On Thu, 26 Mar 2020, Jan Hubicka wrote:
> > I think we should continue to try to model ELF semantics re weak and
> > aliases. If so, then yes, LTO gets it wrong and the above testcase should
> > not abort. Weak doesn't enter the picture for creating aliases (the
> > aliases is
Hello,
On Thu, 26 Mar 2020, Richard Biener wrote:
> > = b.c:
> >
> > __attribute__((weak))
> > __attribute__((noinline))
> >
> > int a()
> > {
> > return 1;
> > }
> >
> > __attribute__((noinline))
> > static int b() __attribute__((alias("a")));
> > void
> > test()
> > {
> > if
Hello,
On Thu, 19 Mar 2020, J.W. Jagersma via Gcc-patches wrote:
> I just realized that changing all outputs to in+out would generate
> worse code for *every* single asm that has any outputs.
Under -fnon-call-exception only. And I'm not sure what you mean, the only
effect of the additional
Hello,
On Wed, 18 Mar 2020, J.W. Jagersma via Gcc-patches wrote:
> > Well, it's both: on the exception path the compiler has to assume that the
> > the value wasn't changed (so that former defines are regarded as dead) or
> > that it already has changed (so that the effects the throwing
> >
Hello,
On Wed, 18 Mar 2020, Segher Boessenkool wrote:
> > > Similarly for non-call exceptions on other statements. It sounds like
> > > what you're describing requires the corresponding definition to happen
> > > for memory outputs regardless of whether the asm throws or not, so that
> > >
Hello,
On Mon, 16 Mar 2020, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Mon, Mar 16, 2020 at 05:47:03PM +, Richard Sandiford wrote:
> >> Segher Boessenkool writes:
> >> >> we do delete "x = 1" for f1. I think that's the expected behaviour.
> >> >> We don't yet delete the
Hello,
On Tue, 10 Mar 2020, Martin Liška wrote:
> >>> We nee to support different variables, like TLS, data and bss variables.
> >>
> >> Why do we need TLS? Right now, it's not supported by nm.
> >
> > Of course it does. It's the 'T' (or 't') character.
>
> Thank you reply!
>
> Are you sure
Hello,
On Mon, 9 Mar 2020, Martin Liška wrote:
> On 3/9/20 4:36 PM, H.J. Lu wrote:
> > We nee to support different variables, like TLS, data and bss variables.
>
> Why do we need TLS? Right now, it's not supported by nm.
Of course it does. It's the 'T' (or 't') character. When you introduce
Hello,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> Well, I'd review a patch differently depending on whether or not it was
> already committed, a patch requiring review or an RFC looking for more
> general comments, so I *do* think such an email prefix is useful.
As I said: a very
Hello,
On Mon, 3 Feb 2020, Jakub Jelinek wrote:
> > > The idea is that the [...] part is NOT part of the commit, only part of
> > > the email.
> >
> > I understand that, but the subject line of this thread says "e-mail
> > subject lines", so I thought we were talking about, well, exactly
Hi,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> The idea is that the [...] part is NOT part of the commit, only part of
> the email.
I understand that, but the subject line of this thread says "e-mail
subject lines", so I thought we were talking about, well, exactly that;
and I see
Hello,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> Where does your '50 chars' limit come from? It's not in the glibc text,
> and it's not in the linux kernel text either. AFAICT this is your
> invention and you seem to be the only person proposing it.
Nope, it's fairly common, so
Hi,
On Thu, 30 Jan 2020, Michael Matz wrote:
> > and the pointers have the same address, then it would evaluate to true
> > at run-time. If I understand correctly, you somehow want to make this
> > case be UB, but I haven't quite understood how (if it is not t
1 - 100 of 784 matches
Mail list logo
