Hello,
On Wed, 3 Apr 2024, Jonathon Anderson wrote:
> Of course, this doesn't make the build system any less complex, but
> projects using newer build systems seem easier to secure and audit than
> those using overly flexible build systems like Autotools and maybe even
> CMake. IMHO using a
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
Hello,
On Wed, 3 Apr 2024, Martin Uecker wrote:
> The backdoor was hidden in a complicated autoconf script...
Which itself had multiple layers and could just as well have been a
complicated cmake function.
> > (And, FWIW, testing for features isn't "complex". And have you looked at
> >
Hello,
On Wed, 3 Apr 2024, Martin Uecker via Gcc wrote:
> > > Seems reasonable, but note that it wouldn't make any difference to
> > > this attack. The liblzma library was modified to corrupt the sshd
> > > binary, when sshd was linked against liblzma. The actual attack
> > > occurred via 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
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, 21 Feb 2024, Daniil Frolov wrote:
> >> Following the recent introduction of more detailed CLOBBER types in GCC, a
> >> minor
> >> inconsistency has been identified in the description of
> >> CLOBBER_OBJECT_BEGIN:
> >>
> >> /* Beginning of object lifetime, e.g. C++ constructor.
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 Sun, 30 Jul 2023, Thomas Koenig wrote:
> > I've recently submitted a patch that adds some attributes that basically
> > say "these-and-those regs aren't clobbered by this function" (I did them
> > for not clobbered xmm8-15). Something similar could be used for the new
> > GPRs as
Hey,
On Thu, 27 Jul 2023, Thomas Koenig via Gcc wrote:
> Intel recommends to have the new registers as caller-saved for
> compatibility with current calling conventions. If I understand this
> correctly, this is required for exception unwinding, but not if the
> function called is
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, 29 Jun 2023, Julian Waters via Gcc wrote:
> int main() {
> asm ("nop" "\n"
> "\t" "nop" "\n"
> "\t" "nop");
>
> asm volatile ("nop" "\n"
> "\t" "nop" "\n"
> "\t" "nop");
> }
>
> objdump --disassemble-all -M intel -M
Hello,
On Thu, 29 Jun 2023, Krister Walfridsson wrote:
> > The thing with signed bools is that the two relevant values are -1 (true)
> > and 0 (false), those are used for vector bool components where we also
> > need them to be of wider type (32bits in this case).
>
> My main confusion comes
Hello,
On Wed, 28 Jun 2023, Krister Walfridsson via Gcc wrote:
> Type safety
> ---
> Some transformations treat 1-bit types as a synonym of _Bool and mix the types
> in expressions, such as:
>
>_2;
> _Bool _3;
> _Bool _4;
> ...
> _4 = _2 ^ _3;
>
> and similarly mixing _Bool
Hello,
On Wed, 28 Jun 2023, Julian Waters via Gcc wrote:
> On the contrary, code compiled with gcc with or without the applied patch
> operates very differently, with only gcc with the applied patch producing a
> fully correctly operating program as expected. Even if the above inline
> assembly
Hello,
On Tue, 27 Jun 2023, Pierrick Philippe wrote:
> My main problem is regarding uninitialized definition, but still not being
> considered undefined behavior.
> For example, the following code:
>
>int x;
>int *y =
>*y = 6;
>
> What I'm doing is basically looking at each gimple
Hello,
On Tue, 20 Jun 2023, Jakub Jelinek via Gcc wrote:
> ce1 pass results in emit_conditional_move with
> (gt (reg/v:SF 83 [ x ]) (reg:SF 84)), (reg/v:SF 83 [ x ]), (reg:SF 84)
> operands in the GCC 11 case and so is successfully matched by
> ix86_expand_fp_movcc as ix86_expand_sse_fp_minmax.
t.com/2017/08/writing-gcc-backend_4.html
which is something not too old. For concrete questions this mailing list
is a good place to ask.
Good luck,
Michael.
>
> Ciao
> Claudio
>
> Il giorno lun 19 giu 2023 alle ore 16:16 Michael Matz ha
> scritto:
>
> > He
Hello,
On Mon, 19 Jun 2023, Richard Biener via Gcc wrote:
> On Sun, Jun 18, 2023 at 12:00 PM Claudio Eterno via Gcc
> wrote:
> >
> > Hi, this is my first time with open source development. I worked in
> > automotive for 22 years and we (generally) were using tricore series for
> > these
Hey,
On Tue, 6 Jun 2023, Umesh Kalappa via Gcc wrote:
> Question is : Why does GCC choose to use GPR's here and have any
> reference to support this decision ?
You explicitely used -m32 ppc, so
https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf
Hello,
On Fri, 12 May 2023, Florian Weimer wrote:
> * Alexander Monakov:
>
> > This is not valid (constraint violation):
> >
> > unsigned x;
> >
> > int *p =
> >
> > In GCC this is diagnosed under -Wpointer-sign:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
>
> Thanks for
Hello,
On Fri, 12 May 2023, Jakub Jelinek via Gcc wrote:
> On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:
> > > One fairly big GCC-internal task is to clear up the C test suite so that
> > > it passes with the new compiler defaults. I already have an offer of
> > > help for
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 Tue, 11 Apr 2023, Richard Biener via Gcc wrote:
> In the case we ever implement conforming FP exception support
> either targets would need to be fixed to mask unexpected exceptions
> or we have to refrain from moving instructions where the target
> implementation may rise exceptions
Hello,
On Thu, 6 Apr 2023, Shiqi Zhang wrote:
> Currently, gcc delibrately filters out default library paths "/lib/" and
> "/usr/lib/", causing some linkers like mold fails to find libraries.
If linkers claim to be a compatible replacement for other linkers then
they certainly should behave in
Hello,
On Fri, 17 Mar 2023, Pierrick Philippe wrote:
> > This means that global variables, volatile variables, aggregates,
> > variables which are not considered aggregates but are nevertheless
> > partially modified (think insertion into a vector) or variables which
> > need to live in memory
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
Hey,
On Fri, 2 Dec 2022, James K. Lowden wrote:
> > > 3. Correct the entries in the default_compilers array. Currently I
> > > have in cobol/lang-specs.h:
> > >
> > > {".cob", "@cobol", 0, 0, 0},
> > > {".COB", "@cobol", 0, 0, 0},
> > > {".cbl", "@cobol", 0, 0, 0},
> > >
Hey,
On Thu, 1 Dec 2022, James K. Lowden wrote:
> > E.g. look in gcc.cc for '@c' (matching the file extension) how that
> > entry uses '%(cpp_unique_options)', and how cpp_unique_options is
> > defined for the specs language:
> >
> > INIT_STATIC_SPEC ("cpp_unique_options",
Hello,
On Tue, 29 Nov 2022, James K. Lowden wrote:
> I don't understand how to access in a front end the arguments to the -I
> option on the command line.
>
> Cobol has a feature similar to the C preprecessor, known as the
> Compiler Directing Facility (CDF). The CDF has a COPY statement
Hey,
On Tue, 29 Nov 2022, Uecker, Martin wrote:
> It does not require any changes on how arrays are represented.
>
> As part of VM-types the size becomes part of the type and this
> can be used for static or dynamic analysis, e.g. you can
> - today - get a run-time bounds violation with the
Hey,
On Tue, 29 Nov 2022, Alex Colomar via Gcc wrote:
> How about the compiler parsing the parameter list twice?
This _is_ unbounded look-ahead. You could avoid this by using "." for
your new syntax. Use something unambiguous that can't be confused with
other syntactic elements, e.g. with a
Hello,
On Wed, 16 Nov 2022, Paul Eggert wrote:
> On 2022-11-16 06:26, Michael Matz wrote:
> > char foobar(void);
> > int main(void) {
> >return != 0;
> > }
>
> That still has undefined behavior according to draft C23,
This is correct (and also holds for t
Hello,
On Wed, 16 Nov 2022, Jonathan Wakely wrote:
> > > Unrelated but I was a bit tempted to ask for throwing in
> > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > > it, but I suppose we don't want the world to burn too much,
> >
> > :-) It's IMHO a bug in the
Hello,
On Wed, 16 Nov 2022, Sam James wrote:
> Unrelated but I was a bit tempted to ask for throwing in
> -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> it, but I suppose we don't want the world to burn too much,
:-) It's IMHO a bug in the standard that it misses
Hey,
On Wed, 16 Nov 2022, Alexander Monakov wrote:
> > The idea is so obvious that I'm probably missing something, why autoconf
> > can't use that idiom instead. But perhaps the (historic?) reasons why it
> > couldn't be used are gone now?
>
> Ironically, modern GCC and LLVM optimize ' != 0'
Hi,
On Tue, 15 Nov 2022, Paul Eggert wrote:
> On 2022-11-15 11:27, Jonathan Wakely wrote:
> > Another perspective is that autoconf shouldn't get in the way of
> > making the C and C++ toolchain more secure by default.
>
> Can you cite any examples of a real-world security flaw what would be
>
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
Hello,
On Thu, 3 Nov 2022, Florian Weimer via Gcc wrote:
> will not have propagated widely once GCC 13 releases, so rejecting
> implicit ints in GCC 13 might be too early. GCC 14 might want to switch
> to C23/C24 mode by default, activating auto support, if the standard
> comes out in 2023
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, 24 Aug 2022, Florian Weimer wrote:
> > On Wed, 24 Aug 2022, Florian Weimer wrote:
> >
> >> > Isn't this merely moving the failure point from exception-at-ctor to
> >> > dlopen-fails?
> >>
> >> Yes, and that is a soft error that can be handled (likewise for
> >> pthread_create).
Hello,
On Wed, 24 Aug 2022, Florian Weimer wrote:
> > Isn't this merely moving the failure point from exception-at-ctor to
> > dlopen-fails?
>
> Yes, and that is a soft error that can be handled (likewise for
> pthread_create).
Makes sense. Though that actually hints at a design problem with
Hello,
On Tue, 23 Aug 2022, Florian Weimer via Gcc wrote:
> We currently have a latent bug in glibc where C++ constructor calls can
> fail if they have static or thread storage duration and a non-trivial
> destructor. The reason is that __cxa_atexit (and
> __cxa_thread_atexit_impl) may have to
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, 8 Jun 2022, Carl Love via Gcc wrote:
> Is there dwarf information that gives the size of a variable?
Yes, it's in the type description. For array types the siblings of it
give the index types and ranges. If that range is
computed at runtime DWARF will (try to) express it as
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 Sat, 15 Jan 2022, Martin Uecker wrote:
> > Because it interferes with existing optimisations. An explicit
> > checkpoint has a clear meaning. Using every volatile access that way
> > will hurt performance of code that doesn't require that behaviour for
> > correctness.
>
> This is
Hello,
On Fri, 14 Jan 2022, Martin Liška wrote:
> Hello.
>
> I'm working on a testsuite clean-up where some of the files are wrongly named.
> More precisely, so files have .cc extension and should use .C. However there's
> existing C test-case and it leads to:
>
>
Hello,
On Thu, 13 Jan 2022, Martin Uecker wrote:
> > > > Handling all volatile accesses in the very same way would be
> > > > possible but quite some work I don't see much value in.
> > >
> > > I see some value.
> > >
> > > But an alternative could be to remove volatile
> > > from the
Hello,
On Tue, 11 Jan 2022, Martin Uecker via Gcc wrote:
> > Handling all volatile accesses in the
> > very same way would be possible but quite some work I don't
> > see much value in.
>
> I see some value.
>
> But an alternative could be to remove volatile
> from the observable behavior in
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,
On Wed, 13 Oct 2021, Martin Uecker wrote:
> > [... static chain ...]
> > If you mean that, then it's indeed psABI specific, and possibly not
> > al ABIs specify it (in which case GCC will probably have set a de-
> > facto standard at least for unixy systems). The x86-64 psABI for
> >
Hello,
On Wed, 13 Oct 2021, Martin Uecker wrote:
> does anybody know if all architectures support passing
> an environment pointer in their function call ABI?
Define "environment pointer". I can imagine two things you could mean:
the custom to pass envp as third argument to main() in hosted
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
1 - 100 of 1247 matches
Mail list logo
