Hi,
On Wed, 23 Oct 2019, Michael Matz wrote:
> On Tue, 22 Oct 2019, Rainer Orth wrote:
>
> > > testsuite/
> > > * gcc.dg/unroll-and-jam.c: Add three invalid and one valid case.
> >
> > this testcase now FAILs on 32-bit targets (seen on i386-pc-solaris2.11
Hello,
On Tue, 22 Oct 2019, Rainer Orth wrote:
> > testsuite/
> > * gcc.dg/unroll-and-jam.c: Add three invalid and one valid case.
>
> this testcase now FAILs on 32-bit targets (seen on i386-pc-solaris2.11
> and sparc-sun-solaris2.11, also reports for i686-pc-linux-gnu and
>
Hello,
I've only noticed a couple typos, and one minor remark. From my
perspective it's okay, but you still need the okay of a proper reviewer,
for which you might want to state the testing/regression state of this
patch relative to trunk. The remarks follow:
On Tue, 22 Oct 2019, Feng Xue
Hi,
this was still collecting dust on my disk, so here it is. See the
extensive comment in the patch for what happens, in short invariant IVs
are affine but still have to be handled more conservative than other
affine IVs in transformations that reorder instructions. Making our
dependence
Hi,
On Tue, 15 Oct 2019, Philipp Tomsich wrote:
> This looks good from our side and has shown useful (combined with the other 2
> patches) in
> our testing with SPEC2017.
> Given that this looks final: what is the plan for getting this merged?
I'll get to review this v3 version this week.
Hi,
On Thu, 10 Oct 2019, David Malcolm wrote:
> This patch uses the support for pretty-printing escaped URLs added in
> the previous patch (PR 87488) so that in a sufficiently capable terminal
> the [-Wname-of-option] emitted at the end of each diagnostic becomes a
> hyperlink to the
Hi,
On Fri, 9 Aug 2019, Martin Sebor wrote:
> The solution introduced in C99 is a flexible array. C++
> compilers usually support it as well. Those that don't are
> likely to support the zero-length array (even Visual C++ does).
> If there's a chance that some don't support either do you
Hi,
On Mon, 12 Aug 2019, Martin Liška wrote:
> > You seem to need it only to have the possibility of virtual functions,
> > i.e. fancy callbacks. AFAICS you only have one derived class, i.e. a
> > simple distinction of two cases. What do you think about encoding the
> > additional new (ICF)
Hi,
On Fri, 9 Aug 2019, Richard Biener wrote:
> Of course I'm still afraid that the other code exists for a reason
> (tuning/hack/whatever...).
>
> Note that with the patch we're now applying LOOP_ALIGN to L2 here:
> if (a)
> foo = bar;
> L2:
> blah;
>
> because there's a jump-around
Hi,
On Mon, 10 Jun 2019, Martin Liska wrote:
> 2019-07-24 Martin Liska
>
> * fold-const.c (operand_equal_p): Rename to ...
> (operand_compare::operand_equal_p): ... this.
> (add_expr): Rename to ...
> (operand_compare::hash_operand): ... this.
>
Hi,
On Wed, 7 Aug 2019, Arvind Sankar wrote:
> => x->is_a (REG)
Oh god, please no. Currently at least the RTL parts of GCC still have
mostly a consistent and obvious style, which is a good thing. I have no
idea why anyone would think the above is easier to read than REG_P (x).
Ciao,
Hi,
On Thu, 8 Aug 2019, Martin Liška wrote:
> > So docs have
> >
> > @defmac JUMP_ALIGN (@var{label})
> > The alignment (log base 2) to put in front of @var{label}, which is
> > a common destination of jumps and has no fallthru incoming edge.
So, per docu: JUMP_ALIGN implies !fallthru ...
> >
Hi,
On Wed, 7 Aug 2019, senthilkumar.selva...@microchip.com wrote:
> gcc/testsuite/c-c++-common/pr60101.c fails with an ICE for the
> avr target, because of a gcc_assert firing at reload1.c:4233
>
> The assert (in the patch below) looks bogus to me, as it's in
> the if block of
>
>
Hello Feng,
first, sorry for the terrible delay in reviewing, but here is one now :)
Generally I do like the idea of the transformation, and the basic building
blocks seem to be sound. But I dislike it being a separate pass, so
please integrate the code you have written into the existing loop
Hi,
On Tue, 23 Jul 2019, Jeff Law wrote:
> > great you found time to make this. It should become the default for
> > -flto IMO.
> I was going to hack it into the rpm configury bits since we have access
> to the # cores there. But an auto-selector within GCC is even better.
>
> BTW, isn't this
Hi,
On Wed, 17 Jul 2019, Romain Geissler wrote:
> However at scale, I think this can become a problem. What will happen
> when in gcc 9.3 we change the version to 8.2 ? Will Tumbleweed recompile
> 100% of the static libraris it ships ?
Every compiler change causes the whole distro to be
Hi,
On Tue, 9 Jul 2019, Richard Biener wrote:
> >The basic block index is not a DFS index, so no, that's not a test for
> >backedge.
>
> I think in CFG RTL mode the BB index designates the order of the BBs in
> the object file? So this is a way to identify backwards jumps?
Even if it means a
Hi,
On Tue, 9 Jul 2019, Richard Biener wrote:
> > So a "backedge" in this sense would be e->dest->index < e->src->index.
> > No?
>
> To me the following would make sense.
The basic block index is not a DFS index, so no, that's not a test for
backedge.
Ciao,
Michael.
Hi,
On Thu, 13 Jun 2019, Jeff Law wrote:
> > (In fact I think our builtin_alloca implementation could benefit when we
> > added that behaviour as well; it's a natural wish to be able to free
> > memory that you allocated).
>
> Also note that simply sprinkling alloca(0) calls won't magically
Hi,
On Thu, 13 Jun 2019, Jeff Law wrote:
> > (In fact I think our builtin_alloca implementation could benefit when we
> > added that behaviour as well; it's a natural wish to be able to free
> > memory that you allocated).
>
> Also note that simply sprinkling alloca(0) calls won't magically
Hi,
On Wed, 12 Jun 2019, Martin Sebor wrote:
> > Otherwise LGTM as the patch, but I'd like to hear from others whether
> > it is kosher to add such a special case to the warn_unused_result
> > attribute warning. And if the agreement is yes, I think it should be
> > documented somewhere that
Hi,
On Wed, 12 Jun 2019, Martin Sebor wrote:
> > Otherwise LGTM as the patch, but I'd like to hear from others whether
> > it is kosher to add such a special case to the warn_unused_result
> > attribute warning. And if the agreement is yes, I think it should be
> > documented somewhere that
Hi,
On Tue, 11 Jun 2019, Martin Liška wrote:
> I see 3 occurrences of the alloca (0) in libiberty/regex.c, but there are
> properly
> guarded within:
>
> # ifdef C_ALLOCA
> alloca (0);
> # endif
>
> and then I noticed 2 more occurrences in gdb that break build right now:
>
>
Hello,
On Thu, 23 May 2019, Indu Bhagat wrote:
> > OK. So I wonder how difficult it is to emit CTF by walking dwarf2outs own
> > data structures? That is, in my view CTF should be emitted by
> > dwarf2out_early_finish () (which is also the point LTO type/decl debug
> > is generated from). It
Hi,
On Tue, 21 May 2019, Richard Biener wrote:
> > Index: gcc/tree-ssa-dce.c
> > ===
> > --- gcc/tree-ssa-dce.c (revision 271415)
> > +++ gcc/tree-ssa-dce.c (working copy)
> > @@ -417,7 +417,7 @@ find_obviously_necessary_stmts
Hi,
On Mon, 20 May 2019, Richard Biener wrote:
> > The C++ standard says that do{}while(1) is __builtin_unreachable(), we
> > don't have to preserve it. There is no mention of anything like a
> > "nontrivial exit condition". Other languages may have a different
> > opinion though, so it would
Hi,
On Wed, 15 May 2019, Jakub Jelinek wrote:
> Just one thing to note, our "memcpy" expectation is that either there is
> no overlap, or there is 100% overlap (src == dest), both all the current
> movmem == future cpymem expanders and all the supported library
> implementations do support
do we move from the existing movmem pattern
> (which Michael Matz tells us should be renamed cpymem anyway) to this
> new thing. Are you proposing that we still have both movmem and cpymem
> optab entries underneath to call the patterns but introduce this new
> memmove_with_hints()
Hi,
On Tue, 14 May 2019, Aaron Sawdey wrote:
> memcpy -> expand with movmem pattern
> memmove (no overlap) -> transform to memcpy -> expand with movmem pattern
> memmove (overlap) -> remains memmove -> glibc call
...
> However in builtins.c expand_builtin_memmove() does not actually do the
>
Hi,
On Tue, 14 May 2019, Jakub Jelinek wrote:
> In https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00484.html I've posted
> a patch that would set it earlier (or it could be set during
> gimplification and propagated during inlining, would need to be in
> cfun->calls_eh_return instead of
Hi,
On Tue, 16 Apr 2019, Jakub Jelinek wrote:
> > + if (type1 == type2)
> > +return true;
> > + if (TYPE_MAIN_VARIANT (type1) != TYPE_MAIN_VARIANT (type2))
> > +return false;
>
> Is this second one correct though? Doesn't comptypes return for various
> cases true even if the
Hi,
On Wed, 17 Apr 2019, Richard Biener wrote:
> for the C++ FE the LRU cache effectively moves the unqualified
> variants first in the variant list. Since we always first
> build the unqualified variants before the qualified ones
> the unqualified ones tend to be at the end of the list.
Hi,
On Tue, 16 Apr 2019, Jeff Law wrote:
> So going back to Jakub's patch... I think the discussion points to
> avoiding the REG_EQUIV notes for outgoing argument slots.
In the long run definitely, but maybe his current solution is more
amenable to stage 4, no idea.
Ciao,
Michael.
Hi,
On Tue, 16 Apr 2019, Richard Biener wrote:
> Comments?
I was quickly testing also with some early-outs but didn't get conclusive
performance results (but really only superficial testing) so I'm not
proposing it, like so:
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index
Hi,
On Tue, 16 Apr 2019, Jeff Law wrote:
> > I still don't think that what you want follows. Imagine this:
> >
> > int foo (int i) { ++i; return i; }
> >
> > To claim that this function is anything else than const+pure seems weird
> > (in fact this function doesn't access anything that
Hello Martin,
On Tue, 16 Apr 2019, Martin Liška wrote:
> Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm
> going to start using kdecore.ii as well.
If the kdecore.cc is the one from me it's also preprocessed and doesn't
contain any #include directives, I just edited it
Hi,
On Mon, 15 Apr 2019, Jakub Jelinek wrote:
> > It seems the C++ parser got quite a bit slower with gcc 9 :-( Most
> > visible in the compile time for tramp-3d (24%) and kdecore.cc (18%
> > slower with just PGO); it seems that the other .ii files are C-like
> > enough to not
>
> Is that
Hi,
On Fri, 12 Apr 2019, Jeff Law wrote:
> > I don't think this follows. Imagine a pure foo tailcalling a pure bar.
> > To make the tailcall, foo may need to change some of its argument slots
> > to pass new arguments to bar.
> I'd claim that a pure/const call can't tail call another function as
Hi,
On Mon, 15 Apr 2019, Martin Liška wrote:
> There's a similar comparison that I did for the official openSUSE gcc
> packages. gcc8 is built with PGO, while the gcc9 package is built in 2
> different configurations: PGO, LTO, PGO+LTO (LTO used for FE in stage4,
> for generators in stage3 as
Hi,
On Fri, 12 Apr 2019, Richard Biener wrote:
> > > > You miss PARM_DECLs and RESULT_DECLs, i.e. it's probably better to
> > > > factor out tree.c:auto_var_in_fn_p and place the new auto_var_p in
> > > > tree.c as well.
> > >
> > > Hmm, I left the above unchanged from a different variant of
Hi,
On Fri, 12 Apr 2019, Richard Biener wrote:
> > You miss PARM_DECLs and RESULT_DECLs, i.e. it's probably better to factor
> > out tree.c:auto_var_in_fn_p and place the new auto_var_p in tree.c as
> > well.
>
> Hmm, I left the above unchanged from a different variant of the patch
> where
Hi,
On Fri, 12 Apr 2019, Richard Biener wrote:
> @@ -332,6 +337,24 @@ struct obstack final_solutions_obstack;
> Indexed directly by variable info id. */
> static vec varmap;
>
> +/* Return whether VAR is an automatic variable. */
> +
> +static bool
> +auto_var_p (const_tree var)
> +{
>
Hi,
On Mon, 8 Apr 2019, Richard Biener wrote:
> Not sure if in this case we run into an RTL optimization that breaks things
> (PRE / scheduling / invariant motion are candidates).
That's true, what Josef sees might point to a genuine bug in the
middle-end observed only on msp430; but we do
Hello,
On Fri, 5 Apr 2019, Jozef Lawrynowicz wrote:
> Some setjmp/longjmp tests[1] depend on the value of an auto set before setjmp
> to to be retained after returning from the longjmp. As I understand, this
> behaviour is actually undefined, according to the gccint manual.
>
> Section 3
Hi,
On Tue, 19 Mar 2019, Richard Biener wrote:
> It doesn't really. Consider the following IMHO valid testcase:
>
> enum X { A, B };
> enum Y { C, D };
> void foo (int *p)
> {
> *(enum X *)p = A;
> *(enum Y *)p = D;
> return *(enum X *)p;
> }
>
> int main()
> {
> int storage;
> if (foo
Hi,
On Mon, 18 Mar 2019, Richard Biener wrote:
> > Or, because an enum with these properties could be modelled as a struct
> > containing one member of basetype you could also change
> > record_component_aliases(), though that doesn't allow language specific
> > behaviour differences.
>
>
Hi,
On Fri, 15 Mar 2019, Michael Matz wrote:
> I.e. what you touched is the naming of sets (giving them identifiers),
> whereas you should have touched where the relations between the sets are
> established. I _think_ instead of giving enum and basetypes the same
> alias set you
Hi,
On Fri, 15 Mar 2019, Richard Biener wrote:
> >But different enums aren't compatible with each other (or are they?),
> >while your fix simply gives enums the aliasing set of the underlying
> >type, i.e. makes all of them alias with each other. That's quite
> >conservative.
>
> But that
Hi,
On Fri, 15 Mar 2019, Richard Biener wrote:
> The following is an attempt to fix PR71598 where C (and C++?) have an
> implementation-defined compatible integer type for each enum and the
> TBAA rules mandate that accesses using a compatible type are allowed.
But different enums aren't
Hi,
On Mon, 25 Feb 2019, Segher Boessenkool wrote:
> Yup. All good points, I didn't think this through enough obviously.
>
> The _1+_1 isn't great if that single pseudo then ends up in mem (it will
> need a reload again on most archs, probably causing another spill), btw.
But at least it'll
Hi,
On Tue, 26 Feb 2019, Richard Biener wrote:
> get_build_id_1 (struct dl_phdr_info *info, size_t, void *data)
> {
Isn't this all a bit silly? We could simply encode the svn revision, or
maybe even just some random bytes generated once in stage1 at build time
as "checksum" and be done
Hi,
On Thu, 21 Feb 2019, Segher Boessenkool wrote:
> > That said, the "bug" in the case we're seeing, is that asmcons rewrote
> > all of "input"'s pseudos, and it should be more careful to not create
> > rtl with illegal constraint usage that LRA cannot fix up. With the
> > fix, operand %1
Hi,
On Wed, 20 Feb 2019, Jeff Law wrote:
> No, I'm saying the distinction between maybe and always uninitialized is
> a false distinction. Code duplication can easily take something that
> triggers a "maybe" warning and turn it into a "always" warning. The
> distinction between them is just
Hi,
On Wed, 13 Feb 2019, Peng Fan wrote:
> So the fix should be the following, right?
Yup.
Ciao,
Michael.
Hi,
On Wed, 13 Feb 2019, Peng Fan wrote:
> asm volatile (
> "ldxr %3, %2\n\t"
> "ands %1, %3, %4\n\t"
> "b.ne 1f\n\t"
> "orr%3, %3, %4\n\t"
> "1:\n\t"
Hi,
On Mon, 28 Jan 2019, Richard Biener wrote:
> > - MEM[(struct &)] ={v} {CLOBBER};
> > + buf1 ={v} {CLOBBER};
>
> Eww :/ That means they are not semantically the same which IMHO is
> bad.
But they really are different. One is saying "these bytes contain nothing
anymore", the other says
Hi,
On Fri, 7 Dec 2018, H.J. Lu wrote:
> > > On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton wrote:
> > > >
> > > > Is the patch OK with you ?
> > >
> >
> > This caused:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
> >
>
> Here is the fix. OK for trunk?
I think this points
Hi,
On Fri, 30 Nov 2018, Nick Clifton wrote:
> Not without modifying the current demangling interface. The problem is
> that the context structure is created for each invocation of a
> demangling function (from outside the library), and no state is
> preserved across demangling calls. Thus
Hi,
On Wed, 21 Nov 2018, Richard Biener wrote:
> then this leads to wrong debug info showing a value for 'a' that never
> existed.
var-tracking was specifically created so that the base-vars of SSA names
aren't necessary for debug info anymore ...
> when you build this with -O -g
Hi,
On Tue, 20 Nov 2018, Richard Biener wrote:
> > Anyway, regstrapped on x86-64-linux, no regressions. Okay for trunk?
>
> Ick. Given you do that only for one stmt kind and it looks kind of ugly
> wouldn't it be better to splat out gimple_set_location (g,
> input_location) to all 108
Hi,
this bug report is about cris generating worse code since tree-ssa. The
effect is also visible on x86-64. The symptom is that the work horse of
adler32.c (from zlib) needs spills in the inner loop, while gcc 3 did not,
and those spills go away with -fno-tree-reassoc.
The underlying
Hi,
the testcase gcc.dg/20020425-1.c was once a compile time hog. With
current trunk it only needs 7 seconds (on my machine, with -O0 cc1) but
there's still something to improve as virtually all of that time is
wasted in repeatedly scanning the same (long) sequence of gimple
statements to
Hi,
On Fri, 16 Nov 2018, Segher Boessenkool wrote:
> > I.e. like volatile they can arbitrarily change their value. I don't
> > know if other peoples mind model is similar, but it certainly is the
> > model that is implemented in the GIMPLE pipeline (and if memory serves
> > well of the RTL
Hi,
On Fri, 16 Nov 2018, Alexander Monakov wrote:
> > Not really, it ignores the fact that 'a' can change at any time, which
> > is what happens.
>
> Are you saying that local register variables, in your model, are
> essentially unfit for passing operands to inline asm on specific
>
Hi,
On Thu, 15 Nov 2018, Alexander Monakov wrote:
> Reading the documentation certainly does not make that impression to me.
> In any case, can you elaborate a bit further please:
>
> 1. Regarding the comparison to 'volatile' qualifier. Suppose you have an
> automatic variable 'int v;' in a
Hi,
On Wed, 14 Nov 2018, Alexander Monakov wrote:
> On Wed, 14 Nov 2018, Segher Boessenkool wrote:
> > Yeah, using local register vars to access global registers only works
> > by accident. It does work currently though, and people apparently use
> > it, so we shouldn't break it :-/
>
> In the
Hi,
On Thu, 15 Nov 2018, Richard Biener wrote:
> > Okay, probably. Then consider the same patch with sprinkling casts to
> > long for all these arguments (the actual numbers will fit that type in
> > reality). I could of course also use PRIu64 but that makes my eyes
> > bleed.
>
> Hmm.
Hi,
On Wed, 14 Nov 2018, Alexander Monakov wrote:
> On Wed, 14 Nov 2018, Michael Matz wrote:
>
> > Hi,
> >
> > it's not c++98 conforming and I get 1 million warnings when compiling.
> > Initially I had also casts to long at the various arguments, but I get no
Hi,
it's not c++98 conforming and I get 1 million warnings when compiling.
Initially I had also casts to long at the various arguments, but I get no
warning with this variant either, so I removed them again. I'm currently
regstrapping this, okay for trunk if successfull?
Ciao,
Michael.
Hi,
On Wed, 14 Nov 2018, Marek Polacek wrote:
> > static gimple *
> > collect_fallthrough_labels (gimple_stmt_iterator *gsi_p,
> > - auto_vec *labels)
> > + auto_vec *labels,
> > + location_t *prevloc)
> > {
> >gimple
Hi,
our warning code sometimes adds locations to statement which didn't have
them before, which can in turn lead to code changes (here only label
numbers change). It seems better to not do that from warning code, and
here it's easy to do: just return the location we want to use for
warnings,
Hi,
On Mon, 12 Nov 2018, Segher Boessenkool wrote:
> > > Wouldn't this also break compiling code that contains power9
> > > instructions but guarded by runtime tests to only be executed on
> > > power9 machines? That seems a valid usecase, and it'd be bad if the
> > > assembler fails to
Hi,
On Mon, 12 Nov 2018, Alan Modra wrote:
> I'd like to remove -many from the options passed by default to the
> assembler, on the grounds that a gcc bug in instruction selection (eg.
> emitting a power9 insn for -mcpu=power8) is better found at assembly
> time than run time.
>
> This might
Hi,
On Mon, 12 Nov 2018, Martin Liška wrote:
> > There's no fundamental reason why we can't poison identifiers in other
> > headers. Indeed we do in vec.h. So move the whole thing including
> > poisoning to hash-table.h?
>
> That's not feasible as gcc/gcc/genhooks.c files use the function
Hi,
On Thu, 8 Nov 2018, Martin Liška wrote:
> > That seems better. But still, why declare this in system.h? It seems
> > hash-table.h seems more appropriate.
>
> I need to declare it before I'll poison it. As system.h is included very
> early, one can guarantee that there will be no usage
Hi,
On Wed, 7 Nov 2018, Martin Liška wrote:
> > Whereever the new function belongs it certainly isn't system.h. Also
> > the definition in a header seems excessive. Sure, it enables inlining
> > of it, but that seems premature optimization. It contains a loop, and
> > inlining anything
Hi,
On Mon, 5 Nov 2018, Jeff Law wrote:
> >> Don't we have a flag specific to honoring nans? Would that be better
> >> to use than flag_unsafe_math_optimizations? As Uli mentioned,
> >> there's
> >
> > That's only relevant for the comparison optimization, of course.
> >
> > Converting erfc
Hi,
On Fri, 2 Nov 2018, Martin Liška wrote:
> V2 of the patch.
>
> Thoughts?
Whereever the new function belongs it certainly isn't system.h. Also the
definition in a header seems excessive. Sure, it enables inlining of it,
but that seems premature optimization. It contains a loop, and
Hi,
On Mon, 29 Oct 2018, Bill Seurer wrote:
> >> Just for the record: am I right that any system using 44 bit of VMA will
> >> fail because
> >> anything + (1 << 44) will be out of process address space?
> >
> > Yes.
> >
> >> And I noticed that documentation in sanitizer_linux.cc is
Hi,
On Mon, 8 Oct 2018, Paul Koning wrote:
> > So all you'd actually have to say is
> >
> > void f1(void)
> > {
> >*i; *j;
> >__builtin_memcpy (i, j, 32);
> > }
>
> No, that doesn't help. Not even if I make it:
>
> void f1(void)
> {
> k = *i + *j;
> __builtin_memcpy (i, j,
Hi,
On Mon, 8 Oct 2018, Alexander Monakov wrote:
> > Only if you somewhere visibly add accesses to *i and *j. Without them
> > you only have the "accesses" via memcpy, and as Richi says, those
> > don't imply any alignment requirements. The i and j pointers might
> > validly be char*
Hi,
On Mon, 8 Oct 2018, Paul Koning wrote:
> >> extern int *i, *j;
> >> extern int iv[40], jv[40];
> >>
> >> void f1(void)
> >> {
> >>__builtin_memcpy (i, j, 32);
> >> }
> >>
> >> void f2(void)
> >> {
> >>__builtin_memcpy (iv, jv, 32);
> >> }
> >
> > Yes, memcpy doesn't require
Hi,
On Wed, 26 Sep 2018, Florian Weimer wrote:
> > Therefore, I've created small out-of-line helpers that are directly
> > linked into every library or executable that requires them. There
> > will be two direct branches, both of which will be well-predicted.
>
> This seems reasonable to me,
Hi,
On Fri, 14 Sep 2018, Aldy Hernandez wrote:
> Is there a subtle reason why we're avoiding unsigned truncating conversions of
> the form:
>
> [X, +INF]
>
> If the X fits in the new type, why can't we just build [X, +INF] in the new
> type?
But (uin8_t)((unsigned)[255,+INF]) aka
Hi,
On Wed, 5 Sep 2018, Aldy Hernandez wrote:
> No apologies needed. I welcome all masochists to join me in my personal hell
> :).
;-)
> > How can this test and following code catch all problematic cases? Assume
> > a range of [253..257], truncating to 8 bits unsigned. The size of the
> >
Hi,
On Tue, 4 Sep 2018, Aldy Hernandez wrote:
> > to make the result ~[0, 5], is it? At least the original code dropped
> > that to VARYING. For the same reason truncating [3, 765] from
> > short to unsigned char isn't [3, 253]. But maybe I'm missing something.
Sorry for chiming in, but this
Hi,
On Mon, 3 Sep 2018, H.J. Lu wrote:
> > So, what's the testcase testing then? Before the patch it doesn't ICE,
> > after the patch it doesn't ICE. What should I look out for so I can see
> > that what the testcase is producing without the patch is wrong?
>
> Before the patch, debug info is
Hi,
On Mon, 3 Sep 2018, H.J. Lu wrote:
> > % ./gcc/cc1plus -quiet -O -g -fno-omit-frame-pointer -fno-var-tracking x.cc
> > % ./gcc/cc1plus -quiet -O -g -fno-omit-frame-pointer -fvar-tracking x.cc
>
> It is because of
>
> gcc_assert ((SUPPORTS_STACK_ALIGNMENT
>
Hi,
On Sun, 2 Sep 2018, H.J. Lu wrote:
> Here is the patch to replace hard frame pointer with stack pointer
> - UNITS_PER_WORD in x86 backend.
>
> OK for trunk?
>
> +// { dg-options "-O -g -fno-omit-frame-pointer -fvar-tracking" }
> +
> +struct Foo
> +{
> + int bar(int a, int b, int c, int
Hi,
On Sat, 1 Sep 2018, Segher Boessenkool wrote:
> > With -fno-omit-frame-pointer, arg pointer is eliminated with hard frame
> > pointer. But
> >
> > commit cd557ff63f388ad27c376d0a225e74d3594a6f9d
> > Author: hjl
> > Date: Thu Aug 10 15:29:05 2017 +
> >
> > i386: Don't use frame
Hi,
On Thu, 30 Aug 2018, Nathan Sidwell wrote:
> > struct foo
> > {
> > unsigned a : 21;
> > union x1 { char x; };
> > unsigned b : 11;
> > union x1 u;
> > };
>
> (for C++) this happens to be a case we already get right. I think
> that'd be a C vendor extension, I
Hi,
as Jakub correctly identified, uses of values produced by the inner loop
that occur inside the outer loop prevent fusion as well. We are
in LCSSA so the check is easy. (Uses outside the outer loop are okay, see
the comment)
Regstrapping on x86-64-linux in progress. Okay for trunk?
Hi,
On Tue, 28 Aug 2018, Alexander Monakov wrote:
> > I think your proposed one
> > warrants some comments. Maybe trade speed for some clearer code?
>
> I think it's not too complicated, but how about adding this comment:
>
> profile_count m = c1.max (c2);
> /* Return 0 if counts are
Hi,
On Fri, 24 Aug 2018, Martin Liška wrote:
> If I see correctly, for libgcc has following files:
>
> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc_eh.a
> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc.a
> /home/marxin/bin/gcc/lib64/libgcc_s.so.1
>
Hi,
On Fri, 24 Aug 2018, Martin Liška wrote:
> >> Where
> >> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.so
> >> points to /home/marxin/bin/gcc/lib64/libgcov.so.1 ?
> >
> > Any symlinks need to be *relative*, not absolute, so the install tree
> > is relocatable. There's
Hi,
On Thu, 23 Aug 2018, Richard Biener wrote:
> > > Can you write a not \0 terminated string literal in C?
> >
> > Yes: char a[2] = "12";
>
> I thought they are fully defined in translation phase #1 ...
No, you can't write a string literal which is not zero terminated, because
in translation
Hi,
On Thu, 16 Aug 2018, Joseph Myers wrote:
> On Thu, 16 Aug 2018, Michael Matz wrote:
>
> > > About the location of libgcov.{a,so}, I believe right place would be now:
> > >
> > > /home/marxin/bin/gcc/lib64/libgcov.so.1
> > > /home/marxin/bin/gcc/l
Hi,
On Thu, 16 Aug 2018, Martin Liška wrote:
> SHLIB_SOVERSION = 1
> SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION)
>
> which would require a substitution for soversion, show I generalize even
> so much?
I wouldn't bother. libgcov.so.1 sounds just fine, and due to symbol
versioning
Hi,
On Tue, 14 Aug 2018, Martin Liška wrote:
> I'm sending second version of the patch candidate. I was able to create
> a mapfile and generate versioned symbols for libgcov.so file.
>
> Unresolved issues:
> 1) I still see linking with static library:
>
> $ find /home/marxin/bin/gcc -name
Hi,
On Wed, 8 Aug 2018, Bernhard Reutner-Fischer wrote:
> How come?
>
> If one wants to develop on a distro that is notoriously outdated then
> you have to obtain the missing pieces yourself.
It's not about developing on an "notoriously outdated" distro, but about
_testing_ on it. There are
201 - 300 of 1254 matches
Mail list logo
