Hello,
On Mon, 23 Dec 2024, Robert Dubner wrote:
> > +static tree
> > +gg_get_larger_type(tree A, tree B)
> > + {
> > + tree larger = TREE_TYPE(B);
> > + if( TYPE_SIZE(TREE_TYPE(A)) > TYPE_SIZE(TREE_TYPE(B)) )
> > +{
> > +larger = TREE_TYPE(A);
> >
> > that doesn't work - TYPE_SIZE is
Hello,
On Wed, 13 Nov 2024, Michael Matz wrote:
> Hello,
>
> this is essentially
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651025.html
>
> from Kewen in functionality. When discussing this with Segher at the
> Cauldron he expressed reservations ab
Hello,
On Tue, 26 Nov 2024, Jonathan Wakely wrote:
> So the 'const int' doesn't really matter for any -On level, as you
> say, but just avoiding two separate uses of the __deque_buf_size
> function is worthwhile for -std=c++98 -O0
Oh, definitely. Avoiding duplicate calls in C++ sources (no matt
Hello,
thanks for bearing with me :)
On Tue, 26 Nov 2024, Jonathan Wakely wrote:
> Being a member function makes no difference, but yes, I'm specifically
> talking about the case of calling a constexpr function.
>
> constexpr int bla() { return 2; }
> int foo (void) {
> const int x = bla();
>
Hello,
I don't have anything to add to the threads topic itself, but was
triggered by something:
On Tue, 26 Nov 2024, Jonathan Wakely wrote:
> > > const size_t __bufsz = __deque_buf_size(sizeof(_Tp));
> > ...
> > I wonder why "const" is useful here.
>
> Because if you don't initialize a cons
Hello,
this is essentially
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651025.html
from Kewen in functionality. When discussing this with Segher at the
Cauldron he expressed reservations about changing the default
implementation of -fpatchable-function-entry. So, to move forward, l
Hello again,
On Thu, 10 Oct 2024, Michael Matz wrote:
> > Can you please open a bugreport tracking this?
>
> PR116850.
Gah, too many tabs :) PR117064 I meant.
Ciao,
Michael.
Hi,
On Thu, 10 Oct 2024, Richard Biener wrote:
> > This also shows a general confusion in that function and the target hook
> > interface here:
> >
> > for (i = nregs - 1; i >= 0; --)
> >...
> >|| ! HARD_REGNO_RENAME_OK (reg + i, new_reg + i))
>
> Can you please open a bugreport tracki
(this came up for m68k vs. LRA, but is a generic problem)
Regrename wants to use new registers for certain def-use chains.
For validity of replacements it needs to check that the selected
candidates are unused up to then. That's done in check_new_reg_p.
But if it so happens that the new register
Hello,
On Tue, 8 Oct 2024, Jonathan Wakely wrote:
> We originally had global static variables, which means a different
> variable per TU. That causes ODR violations which were silently
> ignored until we try to use them in modules, where they're diagnosed.
> So we need to replace them.
Aren't th
Hello,
On Thu, 12 Sep 2024, Stefan Schulze Frielinghaus wrote:
> > > #define call_on_stack(stack, func, asm_call, argconstr...) \
> > > { \
> > > register void *tos asm("r11");
Hello,
On Mon, 26 Aug 2024, Paul Koning wrote:
> >>> Yeah, I wondered as well. For things to go wrong some instructions that
> >>> contain pre/post-inc/dec of the stack pointer need to have reloads in
> >>> such
> >>> a way that the actual SP-change sideeffect moves to a different
> >>> inst
Hello,
On Mon, 26 Aug 2024, Paul Koning wrote:
> >>> 550: [--sp] = 0 sp_off = 0 {pushexthisi_const}
> >>> 551: [--sp] = 37sp_off = -4 {pushexthisi_const}
> >>> 552: [--sp] = r37 sp_off = -8 {movsi_m68k2}
> >>> 554: [--sp] = r116 - r37sp_off = -12 {su
Hello,
On Sun, 25 Aug 2024, Jeff Law wrote:
> >550: [--sp] = 0 sp_off = 0 {pushexthisi_const}
> >551: [--sp] = 37sp_off = -4 {pushexthisi_const}
> >552: [--sp] = r37 sp_off = -8 {movsi_m68k2}
> >554: [--sp] = r116 - r37sp_off = -12 {subsi3}
>
when experimenting with m68k plus LRA one of the
changes in the backend is to accept ASHIFTs (not only
MULT) as scale code for address indices. When then not
turning on LRA but using reload those addresses are
presented to it which chokes on them. While reload is
going away the change to make the
This is part of making m68k work with LRA. See PR116429.
In short: setup_sp_offset is internally inconsistent. It wants to
setup the sp_offset for newly generated instructions. sp_offset for
an instruction is always the state of the sp-offset right before that
instruction. For that it starts at
this is part of making m68k work with LRA. See PR116374.
m68k has the property that sometimes the elimation offset
between %sp and %argptr is zero. During setting up elimination
infrastructure it's changes between sp_offset and previous_offset
that feed into insns_with_changed_offsets that ultima
Hello,
I have implemented the separate shrink wrapping hooks for x86, and this is
the result. With it we can now generate the pro- and epilogue sequences
individually and possibly split over multiple BBs, unlike the non-separate
shrink wrapping we implement (which can only move the whole
prol
Hello,
On Wed, 19 Jun 2024, Tamar Christina wrote:
> So this is where we compare different IV expressions to determine which
> IVs compute the same thing and thus can be in the same group.
>
> The STRIP_NOPS don't work because while the incoming types are the same
> the casts are different. So:
Hello,
On Mon, 3 Jun 2024, Jakub Jelinek wrote:
> > Hmm. I count six tests in about 25 lines of code in
> > tree-tailcall.cc:suitable_for_tail_opt_p and suitable_for_tail_call_opt_p.
> >
> > Are you perhaps worrying about the sibcall discovery itself (i.e. much of
> > find_tail_calls)? Why w
Hello,
On Fri, 31 May 2024, Andi Kleen wrote:
> > I think the ultimate knowledge if a call can or cannot be implemented as
> > tail-call lies within calls.cc/expand_call: It is inherently
> > target and ABI specific how arguments and returns are layed out, how the
> > stack frame is generated,
On Tue, 21 May 2024, Andi Kleen wrote:
> - Give error messages for all causes of non sibling call generation
> - When giving error messages clear the musttail flag to avoid ICEs
> - Error out when tree-tailcall failed to mark a must-tail call
> sibcall. In this case it doesn't know the true reason
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 a
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 (&dfs[bb_in
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 sav
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, t
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. somet
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 PU
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 seq
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 shi
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 sizeof(str
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 t
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 t
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 current
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 yield
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.
> Runnin
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 wouldn't
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(&obj, &expected2, newval);
> >
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 atomic_co
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 __arm(b
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 r
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 ac
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 manipula
Hello,
On Thu, 27 Apr 2023, Jakub Jelinek wrote:
> The first really large error I see is for sinl with
> x/2gx &val
> 0x748160ed90d9425b0xefd8b811d6293294
> i.e.
> 1.5926552660973502228303666578452949e+253
> with most significant double being
> 1.5926552660973502e+253
> and low double
> -5.99
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 sin/cos
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, somethin
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 either
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 c
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 that
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 simulation
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 c
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 acc
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 abs
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
st
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 a
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 th
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 reachable,
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 initializati
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; 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 = &i;
> 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 (t
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
> > > ar
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
> > > CLOBBER
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
> CLOBBER
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 will
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. Mayb
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 t
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:
> >
> >
> > https://lnt.opensuse.org/db_default/v4/SP
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 (h
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 wr
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.
> */
W
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 that
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, fla
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 dsp1
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 shuff
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 seem
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 .m
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 disapp
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 @@ tree_loop_interchange::val
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 h
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
> spill_
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 q
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
> >&g
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 with
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 a
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
1 - 100 of 857 matches
Mail list logo
