Hello,
On Tue, 15 Apr 2025, Bill Wendling wrote:
> > [... the horrors ...]
>
> All of this horribleness is because of the insistence of allowing for
> primary expressions in the attributes, which I find to be a horrible
> idea.
I whole-heartedly agree with you :) But in light of this insistence
Hello,
On Mon, 14 Apr 2025, Bill Wendling wrote:
> Now, I don't think this will be necessarily confusing to the
> programmer, but it's inconsistent. In other words, either 'counted_by'
> *must* forward declare the in-structure identifier or neither must.
If that's your concern then both should r
Hey,
On Tue, 8 Apr 2025, Uros Bizjak wrote:
> > From: Ard Biesheuvel
> >
> > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > __fentry__") updated the logic that emits mcount() / __fentry__() calls
> > into function prologues when profiling is enabled, to avoid GOT-based
Hello,
On Mon, 7 Apr 2025, Martin Uecker wrote:
> > So, what specifically would the two attributes do different? FWIW: what
> > worries me about accepting a generic expression in counted_by, that isn't
> > prefixed by a (possibly empty) decl, is that after seeing a non-type
> > identifier the
Hello,
On Sat, 5 Apr 2025, Bill Wendling wrote:
> > >>> So, a different attribute name “counted_by_exp” might be better?
> > >>
> > >> I would prefer Martins empty-decl idea to that: "counted_by(;len+0)"
> > >> (looks up 'len' normally, i.e. doesn't look into current struct). It
> > >> would nat
fit the either decl+expr or lone-ident parse.
It may look weird but empty declarations are okayish IMHO.
But overall: I just don't know, it all looks a bit unsexy, there only seem
to be rocks and hard places :)
Ciao,
Michael.
>
> Qing
>
> > On Apr 4, 2025, at 11:55, Mich
Hello,
On Fri, 4 Apr 2025, Qing Zhao wrote:
> A:
> constexpr int len = 20;
> struct s {
> int len;
> int *buf __attribute__ ((counted_by (len))); // this continues to be member
> ‘len’, not global ‘len'
> };
>
> B:
> constexpr int len = 20;
> struct s {
> int len;
> int *buf __attribute
Hello,
On Fri, 4 Apr 2025, Bill Wendling wrote:
> > > I don’t have strong preference here. As mentioned by Jacub in a
> > > previous email, these two syntaxes can be distinguished by the number
> > > of arguments of the attribute.
> > >
> > > So for GCC, there should be no issue w
Hello,
On Mon, 31 Mar 2025, Bill Wendling wrote:
> 1. The use of '__self' isn't feasible, so we won't use it.
That's a bold statement. How's that? The only thing I read here is that
the very spelling of "self" was objected to. So, call it _Self,
_Selfref, or something. Even _Whatever42 wou
Hey,
On Thu, 20 Feb 2025, Richard Biener wrote:
> > > +@opindex msplit-patch-nops
> > > +@item -msplit-patch-nops
> > > +When adding NOPs for a patchable area via the
> > > +@option{-fpatchable-function-entry} option emit the "before" NOPs in
> > > front
> > > +of the global entry point and the
Hello,
On Wed, 12 Mar 2025, Martin Uecker wrote:
> > To me, this is clearer. But I am okay with the designator syntax.
>
> I am also okay with __self__ if people have concerns about resuing the
> designator syntax. We could still always drop the requirement for
> writing __self__ later.
So,
Hello,
On Mon, 24 Feb 2025, Jeff Law wrote:
> The pass rejects the transformation when there are instructions in the
> sequence that might throw an exception. This was added due to having
> cases that the load instruction contains a REG_EH_REGION note and
> moving it before th
Hello,
On Mon, 3 Feb 2025, H.J. Lu wrote:
> Author: Surya Kumari Jangala
> Date: Tue Jun 25 08:37:49 2024 -0500
>
> ira: Scale save/restore costs of callee save registers with block
> frequency
>
> scales the cost of saving/restoring a callee-save hard register in epilogue
> and prologu
Hello,
On Tue, 28 Jan 2025, Surya Kumari Jangala wrote:
> The following patch has been bootstrapped and regtested on
> powerpc64le-linux, aarch64-linux and x86_64-linux. This patch is a
> proposed fix for PR118533. Request you to please review the patch.
A full insn-scan should not be needed f
Hey,
On Tue, 28 Jan 2025, Richard Biener wrote:
> > I think as long as that is the case your proposed changes makes sense.
> > But perhaps it's worth a comment to that effect, i.e. that because
> > dependence analysis is wonky (sometime using zero as unknown) we do these
> > "strange" tests.
Hello,
On Thu, 23 Jan 2025, Richard Biener wrote:
> When we get a zero distance vector we still have to check for the
> situation of a common inner loop with zero distance. But we can
> still allow a zero distance for the loop we distribute
> (gcc.dg/tree-ssa/ldist-33.c is such a case). This is
Hello,
On Wed, 22 Jan 2025, Martin Uecker wrote:
> > > > If y is not a member it must be an expression, true. But if it's
> > > > a member you don't know, it may be a designation or an expression.
> > >
> > > In an initializer I know all the members.
> >
> > My sentence was ambiguous :-) Try
Hello,
On Wed, 22 Jan 2025, Martin Uecker wrote:
> > > In .y[1][3].z after .y you can decide whether y is a member of the
> > > struct being initialized. If it is, it is a designator and if not
> > > it must be an expression.
> >
> > If y is not a member it must be an expression, true. But if
Hello,
On Wed, 22 Jan 2025, Martin Uecker wrote:
> > > So you do not need to look further. But maybe I am missing something
> > > else.
> >
> > Like ...
> >
> > > > Note further that you may have '{ .y[1][3].z }', which is still not a
> > > > designation, but an expression under your proposa
Hello,
On Wed, 22 Jan 2025, Martin Uecker wrote:
> > You need to decide which is which after seeing the ".". I'm guessing what
> > you mean is that on seeing ".ident" as first two tokens inside in
> > initializer-list you go the designator route, and not the
> > initializer/assignment-express
Hello,
On Tue, 21 Jan 2025, Martin Uecker wrote:
> > > Coudn't you use the rule that .len refers to the closest enclosing
> > > structure
> > > even without __self__ ? This would then also disambiguate between
> > > designators
> > > and other uses.
> >
> > Right now, an expression cannot sta
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
1 - 100 of 878 matches
Mail list logo
