Hello,
On Tue, 19 May 2020, Martin Liška wrote:
> > The common problems I remember is that e.g. when changing a function comment
> > above some function, it is attributed to the previous function rather than
> > following, labels in function confusing it:
> > void
> > foo ()
> > {
> > .
Hello,
On Tue, 19 May 2020, Jakub Jelinek wrote:
> On Tue, May 19, 2020 at 05:21:16PM +0100, Richard Earnshaw wrote:
> > This is really a wart in the GNU coding style. And one reason why I
> > tend to indent such labels by a single space. It particularly affects
> > things like class definition
Hello,
On Wed, 22 Jul 2020, Mallappa, Premachandra wrote:
> > That's deliberate, so that we can use the same x86-* names for 32-bit
> > library selection (once we define matching micro-architecture levels there).
>
> Understood.
>
> > If numbers are out, what should we use instead?
> > x86-sse
Hello,
On Sat, 25 Jul 2020, Gary Oblock via Gcc wrote:
> if ( TYPE_P ( type) )
> {
>TREE_TYPE ( ssa_name) = TYPE_MAIN_VARIANT ( type);
>if ( ssa_defined_default_def_p ( ssa_name) )
> {
> // I guessing which I know is a terrible thing to do...
>
Hello,
On Thu, 12 Nov 2020, Stefan Kanthak wrote:
> Does GCC generate (unoptimised) code there, similar to the following i386
> assembly, using 4 loads, 4 shifts, 2 ands plus 3 ors?
Try for yourself. '-m32 -O2 -march=i386' is your friend.
Ciao,
Michael.
Spoiler: it's generating:
mov
Hello,
On Sun, 29 Nov 2020, Allan Sandfeld Jensen wrote:
> On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote:
> > * Allan Sandfeld Jensen:
> > > If you _do_ change it. I would suggest changing it to 120, which is next
> > > common step for a lot of C++ projects.
> >
> > 120 can be
Hello,
On Mon, 30 Nov 2020, Allan Sandfeld Jensen wrote:
> > > On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote:
> > > > * Allan Sandfeld Jensen:
> > > > > If you _do_ change it. I would suggest changing it to 120, which is
> > > > > next
> > > > > common step for a lot of C++ proj
Hello,
On Tue, 1 Dec 2020, Bill Messmer via Gcc wrote:
> Thank you very much for the help. I was so fixated on the fact that the
> .rela.debug* sections were there that I didn't pay attention to the
> e_type in the ELF header. Apparently, neither did the library that I
> was using to parse t
Hello,
On Tue, 16 Mar 2021, Thomas Schwinge wrote:
> >>Indeed, given (Fortran) 'zzz = 1', we produce GIMPLE:
> >>
> >>gimple_assign
> >>
> >>..., and calling 'walk_stmt_load_store_addr_ops' on that, I see, as
> >>expected, the 'visit_store' callback invoked, with 'rhs' and 'arg':
> >>''.
> >
Hello,
On Wed, 17 Mar 2021, Richard Biener wrote:
> > The walk_gimple functions are intended to be used on the SSA form of
> > gimple (i.e. the one that it is in most of the time).
>
> Actually they are fine to use pre-SSA.
Structurally, sure.
> They just even pre-SSA distinguish between regi
Hello,
On Thu, 6 May 2021, Prathamesh Kulkarni via Gcc wrote:
> Well, I was thinking of this test-case:
>
> int f(int cond1, int cond2, int cond3, int x, int y)
> {
> void f1();
> void f2(int);
> void f3();
>
> if (cond1)
> f1 ();
> else
> {
> if (cond2)
> f2 (x
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 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,
On Thu, 17 Jun 2021, Martin Sebor via Gcc wrote:
> > The original problem is that the PR wasn't _in the body_ of the commit
>
> But I see [PR100085] right there at the end of the _summary line_:
Emphasis mine.
Ciao,
Michael.
t;
> > gold and ld.lld just emit an error unconditionally. I think non-x86
> > GNU ld ports which never support "copy relocations on protected data
> > symbols" may want to make the diagnostic unconditional as well.
> > Well, while (Michael Matz and ) I think compatibility che
Hello,
On Tue, 22 Jun 2021, H.J. Lu wrote:
> > > The issue is that libfoo.so used in link-time can be different from
> > > libfoo.so at run-time. The symbol, foobar, in libfoo.so at link-time
> > > has the default visibility. But foobar in libfoo.so at run-time can be
> > > protected. ld.so sh
Hello,
On Thu, 1 Jul 2021, Martin Liška wrote:
> On 7/1/21 3:33 PM, Eli Zaretskii wrote:
> > > Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@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 disappe
Hello,
On Thu, 22 Jul 2021, Richard Biener via Gcc wrote:
> But how does TLS usage transfer between threads? On the gimple level
> the TLS pointer is not visible and thus we'd happily CSE its address:
Yes. All take-address operations then need to be encoded explicitely with
a non-CSE-able in
Hello,
On Wed, 4 Aug 2021, John Ericson wrote:
> > Doesn't GCC automatically look for those commands in the --prefix
> > directory that you configure GCC with? Or is that only for native
> > compilers?
>
> It will search only if --with-*=... was not passed, and it will never
> prefix the quer
Hi,
On Thu, 20 Feb 2014, Linus Torvalds wrote:
> But I'm pretty sure that any compiler guy must *hate* that current odd
> dependency-generation part, and if I was a gcc person, seeing that
> bugzilla entry Torvald pointed at, I would personally want to
> dismember somebody with a rusty spoon..
Y
Hi,
On Fri, 21 Feb 2014, Paul E. McKenney wrote:
> > And with conservative I mean "everything is a source of a dependency, and
> > hence can't be removed, reordered or otherwise fiddled with", and that
> > includes code sequences where no atomic objects are anywhere in sight [1].
> > In the lig
Hi,
On Mon, 24 Feb 2014, Linus Torvalds wrote:
> > To me that reads like
> >
> > int i;
> > int *q = &i;
> > int **p = &q;
> >
> > atomic_XXX (p, CONSUME);
> >
> > orders against accesses '*p', '**p', '*q' and 'i'. Thus it seems they
> > want to say that it orders against aliased storage
Hi,
On Wed, 26 Feb 2014, Richard Biener wrote:
> > "\tstr wzr, [%2, #4]!\n"
> > "\tsub %1, %1, #1\n"
> > "\tcbnz %1, 0b\n"
> > : "=m"(*p), "+r"(len) : "r"(p));
> >
> > I presume this is wrong because *p only refers to p[0]. Is it
> > possible to tell GCC t
Hi,
On Thu, 27 Feb 2014, Richard Sandiford wrote:
> [... many cases where 'volatile' in asm doesn't inhibit optimizations
> ...]
>
> We do nothing this draconian for a normal function call, which could
> easily use a volatile asm internally. IMO anything that isn't flushed
> for a call shouldn
Hi,
On Thu, 17 Apr 2014, Richard Sandiford wrote:
> > "The constraints on a ‘movm’ must permit moving any hard register to
> > any other hard register provided..."
> >
> > by providing a define_expand that assigns from a general_operand to a
> > nonimmediate_operand and ...
> >
> > *ldsi instru
Hi,
On Thu, 15 May 2014, Richard Biener wrote:
> To me predicate (and capture without expression or predicate)
> differs from expression in that predicate is clearly a leaf of the
> expression tree while we have to recurse into expression operands.
>
> Now, if we want to support applying predica
Hi,
On Tue, 20 May 2014, Richard Biener wrote:
> > Syntaxwise I had this idea for adding generic predicates to expressions:
> >
> > (plus (minus @0 @1):predicate
> > @2)
> > (...)
>
> So you'd write
>
> (plus @0 :integer_zerop)
>
> instead of
>
> (plus @0 integer_zerop)
>
> ?
plus i
Hi,
On Mon, 16 Jun 2014, Richard Biener wrote:
> For
>
> (match_and_simplify
> (MINUS_EXPR @2 (PLUS_EXPR@2 @0 @1))
> @1)
Btw, this just triggered my eye. So with lumping the predicate to the
capture without special separator syntax, it means that there's a
difference between "minus_expr
Hi,
On Mon, 14 Jul 2014, Franzi Edo. wrote:
> It is like if gcc do not take in account of my BUILD_CFLAGS="-g -O2
> -fbracket-depth=1024“
GCC meanwhile is compiled with c++. Instead of CFLAGS use CXXFLAGS. I.e.
BUILD_CXXFLAGS, and so on. No guarantees, but at least foobar_CFLAGS only
shoul
Hi,
On Tue, 14 Oct 2014, Jamie Iles wrote:
> int foo(void)
> {
> if (getreturn() != 0)
> return -1;
>
> return 0;
> }
So if getreturn() returns zero it can simply reuse that return value ...
> but at -O1 I get
>
> 10:
Hi,
On Thu, 13 Nov 2014, H.J. Lu wrote:
> x86-64 psABI has
>
> name@GOT: specifies the offset to the GOT entry for the symbol name
> from the base of the GOT.
>
> name@GOTPLT: specifies the offset to the GOT entry for the symbol name
> from the base of the GOT, implying that there is a correspo
Hi,
On Thu, 13 Nov 2014, H.J. Lu wrote:
> @GOTPLT will create a PLT entry, but it doesn't mean PLT entry will be
> used.
Correct. The compiler was supposed to somehow make a good decision (e.g.
if there were calls and address-takings in the same unit).
> Only @PLTOFF will use PLT entry. Lin
Hi,
On Thu, 13 Nov 2014, H.J. Lu wrote:
> Linker does:
>
> ... code that looks like it might create just one GOT slot ...
>
> So if a symbol is accessed by both @GOT and @PLTOFF, its
> needs_plt will be true and its got.plt entry will be used for
> both @GOT and @GOTPLT. @GOTPLT has no advant
Hi,
On Mon, 17 Nov 2014, H.J. Lu wrote:
> It has nothing to do with large model.
Yes, I didn't say so. I've used it only to force GCC to emit @GOT relocs
(otherwise it would have used @GOTPCREL) to disprove your claim.
> The same thing happens to small model. We may be to able optimize it,
Hi,
On Wed, 19 Nov 2014, H.J. Lu wrote:
> > The first one (to 600ff8) is the normal GOT slot, the second one the GOT
> > slot for the PLT entry. Both are actually used:
> >
> > 004005f0 :
> > 4005f0: ff 25 32 0a 20 00 jmpq *0x200a32(%rip)#
> > 601028 <_GLOBAL_OFF
Hi,
On Mon, 19 Jan 2015, Sandra Loosemore wrote:
> > I'd be happy to work on a patch to bring the manual to using a common
> > naming convention, but what should it be? Wikipedia seems to use
> > "x86" (lowercase) to refer to the entire family of architectures
> > (including the original 16-b
Hi,
On Tue, 20 Jan 2015, H.J. Lu wrote:
> > ia32 is confusing because ia64 (a well known term) sounds related but
> > can't be farther away from it, and it's also vendor specific. Our
> > traditional i386 seems better to me (although it has its own problems,
> > but I'm not aware of any bette
Hi,
On Tue, 20 Jan 2015, Uros Bizjak wrote:
> > At least, IA-32 is clear, although IA-64 may be confusing :-). FWIW,
> > i386 is also vendor specific.
>
> Wikipedia agrees [1]:
I wouldn't use a wikipedia article that only cites sources from after 2008
(and most of them actually after the aft
Hi,
On Wed, 28 Jan 2015, Tobias Burnus wrote:
> I first want to point to POSIX, which has:
>
> "floor, floorf, floorl - floor function" [...]
> "An application wishing to check for error situations should set errno to
> zero and call feclearexcept(FE_ALL_EXCEPT) before calling these functions
Hi,
On Fri, 30 Jan 2015, Tom de Vries wrote:
> > Maybe you want to pick up the work?
>
> In principle yes, depending on the amount of work (at this point I have no
> idea what remains to be done and how long that would take me).
>
> Michael, are your patches posted somewhere?
I don't think I e
Hi,
On Mon, 2 Feb 2015, Tom de Vries wrote:
> I've minimized the vaarg-4a.c failure, and added it as testcase to the patch
> series as gcc.target/x86_64/abi/callabi/vaarg-4.c.
>
> The problem is in this code:
> ...
> e = va_arg (argp, char *);
> e = va_arg (argp, char *);
> ...
>
> which is
Hi,
On Tue, 3 Feb 2015, Tom de Vries wrote:
> Ironically, that fix breaks the va_list_gpr/fpr_size optimization, so
> I've disabled that by default for now.
>
> I've done a non-bootstrap and bootstrap build using all languages.
>
> The non-bootstrap test shows (at least) two classes of real fa
Hi,
On Tue, 3 Feb 2015, Jakub Jelinek wrote:
> It can be lowered during gimplification to some internal call.
That's what my patch does :)
> What arguments and return values will it have can be decided based on
> what will be most suitable for the lowering.
And that as well, just the concrete
Hi,
On Tue, 10 Feb 2015, Tom de Vries wrote:
> I've added two modifications to gimplify_modify_expr:
> - the WITH_SIZE_EXPR in which the CALL_TREE is wrapped, is dropped after
> gimplification, but we need the size expression at expansion in pass_stdarg.
> So I added the size expression as ar
Hi,
On Wed, 11 Feb 2015, Tom de Vries wrote:
> > My idea was to not generate temporaries and hence copies for
> > non-scalar types, but rather construct the "result" of va_arg directly
> > into the original LHS (that would then also trivially solve the
> > problem of nno-copyable types).
>
>
Hi,
On Thu, 2 Apr 2015, Jakub Jelinek wrote:
> > But it is dubious to require that, say, strdup ("example") returns a
> > pointer which is 16-byte-aligned, too.
> >
> > What is missing, it seems to me, is the qualification that for the
> > pointer returned by malloc, the alignment requirements
Hi,
On Wed, 6 May 2015, Richard Biener wrote:
> >> double f1(int x) { return (double)(float)x; } --> return (double)x;
> >> int f2(double x) { return (int)(float)x; } --> return (int)x;
> >>
> >> Is it Okay for the compiler to do the simplifications shown above with
> >> fast-match enabled?
> >
>
Hi,
On Mon, 11 May 2015, H.J. Lu wrote:
> To remove one direct branch to PLT for external function calls:
>
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg1.html
>
> I am proposing to add 2 new relocations, R_X86_64_RELAX_PC32
> and R_X86_64_RELAX_PLT32:
>
> 1. They can only be used on 32
Hi,
On Sun, 17 May 2015, H.J. Lu wrote:
> To remove one direct branch to PLT for external function calls:
>
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg1.html
>
> I am proposing to add 2 new relocations, R_X86_64_RELAX_PC32 and
> R_X86_64_RELAX_GOTPCREL:
>
> 1. R_X86_64_RELAX_PC32 can
Hi,
On Wed, 20 May 2015, Paul E. McKenney wrote:
> > > I'm not sure... you'd require the compiler to perform static analysis of
> > > loops to determine the state of the machine when they exit (if they exit!)
> > > in order to show whether or not a dependency is carried to subsequent
> > > operat
Hi,
On Thu, 21 May 2015, Paul E. McKenney wrote:
> The point is -exactly- to codify the current state of affairs.
Ah, I see, so it's not yet about creating a more useful (for compilers,
that is) model.
> > char * fancy_assign (char *in) { return in; }
> > ...
> > char *x, *y;
> >
> >
Hi,
On Sat, 20 Jun 2015, DJ Delorie wrote:
> Note that the DW_AT_decl_file refers to "dj.h" and not "dj.c". If you
> remove the "3" from the '# 1 "dj.h" 1 3' line, the DW_AT_decl_file
> instead refers to "dj.c". It's been this way for many releases.
>
> Is this intentional?
I think it came
Hi,
On Thu, 17 Sep 2015, Eric S. Raymond wrote:
> All I can say is every time I've tried this it's been a nightmare, and
> when you say "apart from CVS imported revisions" my hair stands on end.
> And the GCC history is two and a half times the size of the next largest
> repo I've tried this
Hi,
On Thu, 17 Sep 2015, Richard Earnshaw wrote:
> None of this has any chance of working for any commits to the pre-egcs
> sources. In those days there was no version control on the ChangeLog
> file.
>
> My feeling is we could spend months ratholing on this particular problem
> rather than
Hi,
On Tue, 24 Nov 2015, Richard Biener wrote:
> On Tue, Nov 24, 2015 at 12:01 AM, Jason Merrill wrote:
> > There's a proposal working through the C++ committee to define the order of
> > evaluation of subexpressions that previously had unspecified ordering:
> >
> > http://www.open-std.org/Jtc1/
Hi,
On Thu, 26 Nov 2015, David Brown wrote:
> That is all true - but if you have to pick an order that makes sense to
> users, especially of functions that are not varargs (i.e., most
> functions), then left-to-right is the only logical, natural order - at
> least for those of use who use left
Hi,
On Fri, 8 Jan 2016, Richard Biener wrote:
> > The only solution here is for ivopts to keep a pointer to the array,
> > not a pointer to some location near, but outside of the array.
>
> Yes, the solution is to make IVOPTs not do this (eventually controlled
> by a parameter because clearly
Hi,
On Mon, 11 Jan 2016, Ian Lance Taylor wrote:
> > Well, that's a hack. A solution is to design something that works
> > generally for garbage collected languages with such requirements
> > instead of arbitrarily limiting transformations here and there. It
> > could be something like the n
Hi,
On Thu, 11 Feb 2016, Jonathan Wakely wrote:
> On 11 February 2016 at 12:40, Matthijs van Duin wrote:
> > You never define "POD for the purposes of layout", and I can only
> > interpret it as being equivalent to "standard-layout".
>
> As Richard pointed out, it's defined in the C++ ABI.
Whic
Hi,
On Thu, 11 Feb 2016, H.J. Lu wrote:
> Any suggestions on new wording, something like
>
> 1. "class type". A class type is a structure, union or C++ class.
> 2. "empty type". An empty type is a type where it and all of its
> subobjects are of class or array type.
>
> Does it cover
>
>
Hi,
On Thu, 11 Feb 2016, Mark Wielaard wrote:
> If we could ask overseers to setup a new group/list gnu-gabi on
> sourceware where binutils, gcc, gdb, glibc and other interested parties
> could join to maintain these extensions and ask for clarifications that
> would be wonderful. I am not a b
Hi,
On Fri, 12 Feb 2016, Richard Biener wrote:
> >What do you think about refactoring iterators in GCC 7?
>
> I think refactoring towards STL style iterators would be welcome. It
> may be different for the actual instances though.
Oh God, please, for the live of all kittens, no. If anything,
Hi,
On Tue, 16 Feb 2016, Mikhail Maltsev wrote:
> > If anything, implement and use a range idiom like in D.
> >
> Could you please elaborate on that?
Motivation:
http://accu.org/content/conf2009/AndreiAlexandrescu_iterators-must-go.pdf
Detailed intro of the concept:
http://www.informit.com/a
Hi,
On Tue, 16 Feb 2016, H.J. Lu wrote:
> Here is the new definition:
>
> An empty type is a type where it and all of its subobjects (recursively)
> are of class, structure, union, or array type. No memory slot nor
> register should be used to pass or return an object of empty type.
The triv
Hi,
On Thu, 18 Feb 2016, Richard Smith wrote:
> >> An empty type is a type where it and all of its subobjects
> >> (recursively) are of class, structure, union, or array type. No
> >> memory slot nor register should be used to pass or return an object
> >> of empty type.
> >
> > The trivially
Hi,
On Thu, 18 Feb 2016, H.J. Lu wrote:
> >> An empty type is a type where it and all of its subobjects
> >> (recursively) are of class, structure, union, or array type. No
> >> memory slot nor register should be used to pass or return an object
> >> of empty type.
> >
> > The trivially copya
Hi,
On Fri, 19 Feb 2016, Richard Smith wrote:
> >> > The trivially copyable is gone again. Why is it not necessary?
> >>
> >> The C++ ABI doesn't defer to the C psABI for types that aren't
> >> trivially-copyable. See
> >> http://mentorembedded.github.io/cxx-abi/abi.html#normal-call
> >
> > Hmm,
Hi,
On Sat, 20 Feb 2016, Richard Smith wrote:
> > An empty type is a type where it and all of its subobjects
> > (recursively) are of class, structure, union, or array type.
> >
> > doesn't cover "trivially-copyable".
>
> That's correct. Whether a type is trivially copyable is unrelated to
> w
Hi,
On Tue, 23 Feb 2016, H.J. Lu wrote:
> > ---
> > An empty type is a type where it and all of its subobjects (recursively)
> > are of class, structure, union, or array type. No memory slot nor
> > register should be used to pass or return an object of empty type that's
> > trivially copyable.
Hi,
On Tue, 23 Feb 2016, H.J. Lu wrote:
> I thought
>
> ---
> An empty type is a type where it and all of its subobjects (recursively)
> are of class, structure, union, or array type.
> ---
>
> excluded
>
> struct empty
> {
> empty () = default;
> };
Why would that be excluded? There are no
Hi,
On Fri, 26 Feb 2016, H.J. Lu wrote:
> >> It is clear to me now. Let's go with
> >>
> >> ---
> >> An empty type is a type where it and all of its subobjects (recursively)
> >> are of class, structure, union, or array type. No memory slot nor
> >> register should be used to pass or return an
Hi,
On Sun, 28 Feb 2016, Linus Torvalds wrote:
> > So the kernel obviously is already using its own C dialect, that is
> > pretty far from standard C. All these options also have a negative
> > impact on the performance of the generated code.
>
> They really don't.
They do.
> Have you ever s
Hi,
On Sat, 27 Feb 2016, Paul E. McKenney wrote:
> But we do already have something very similar with signed integer
> overflow. If the compiler can see a way to generate faster code that
> does not handle the overflow case, then the semantics suddenly change
> from twos-complement arithmetic to
Hi,
On Mon, 29 Feb 2016, Jason Merrill wrote:
> > Also this insistence that all of "trivially copyable" is already quite
> > nicely specified in the C++ ABI is still not really relevant because
> > C++ _is not the only language out there_. I'm not sure how often I
> > have to repeat this unti
Hi,
On Tue, 1 Mar 2016, Richard Biener wrote:
> > What about the example I gave above? Is it unrealistic for compilers
> > do ever do something like this, or is it just unlikely to gain much
> > performance, or is it just that GCC does not do this today?
>
> GCC does not do this today with th
Hi,
On Thu, 10 Mar 2016, Richard Biener wrote:
> Then I'd like to be able to re-construct SSA without jumping through
> hoops (usually you can get close but if you require copies propagated in
> a special way you are basically lost for example).
>
> Thus my proposal to make the GSoC student at
Hi,
On Tue, 15 Mar 2016, Richard Biener wrote:
> So I am most worried about replicating all the complexity of types and
> decl parsing for the presumably nice and small function body parser.
>
> In private discussion we somewhat agreed (Micha - correct me ;)) that
> iff the GIMPLE FE would rep
Hi,
On Sat, 19 Mar 2016, Cy Cheng wrote:
> But I don't understand why &c - 8 is invalid? Which rule in C99 it volatile?
&x points to the start of object x, and &x - something (something != 0)
points outside object x. 'c' was a complete object, so &c-8 points
outside any object, hence the form
Hi,
On Mon, 18 Apr 2016, H.J. Lu wrote:
> > reason is DSO code (also handcoded assembly) may reasonably expect to
> > be able to load the address with a PC-relative load-address type
> > instruction (ADDIUPC, LEA, MOVAB, etc.) and the target may not even
> > have suitable dynamic relocations a
Hi,
On Tue, 19 Apr 2016, Richard Biener wrote:
> So with all this it sounds that current protected visibility is just
> broken and we should forgo with it, making it equal to default
> visibility?
Like how? You mean in GCC regarding protected as default visibility? No,
that's just throwing
Hi,
On Thu, 21 Apr 2016, Szabolcs Nagy wrote:
> there is also , , usage and go-system.h is special.
> (and gmp.h includes when built with c++)
>
> so i can prepare a patch with INCLUDE_{MAP,SET,LIST} and remove the
> explicit libc/libstdc++ includes.
This.
> >> auto-profile.c
> >> diagnost
Hi,
On Sat, 7 May 2016, Rich Felker wrote:
> > > * sigaltstack and swapcontext are broken too.
> >
> > We have prototype that supports swapcontext that we're happy to
> > release, but it clearly requires more work before being ready to merge
> > upstream.
>
> The *context APIs are deprecated
Hi,
On Mon, 9 May 2016, Rich Felker wrote:
> > > The *context APIs are deprecated and I'm not sure they're worth
> > > supporting with this. It would be a good excuse to get people to
> > > stop using them.
> >
> > How? POSIX decided to remove the facilities without any adequate
> > replacem
Hi,
On Mon, 9 May 2016, Rich Felker wrote:
> > Done. I never understood why they left in the hugely unuseful
> > {sig,}{set,long}jmp() but removed the actually useful *context()
> > (amended somehow like above).
>
> Because those are actually part of the C language
Sure. Same QoI bug in my
Hi,
On Tue, 10 May 2016, Szabolcs Nagy wrote:
> setjmp is defined so that the compiler can treat it
> specially and the caller has to make sure certain
> objects are volatile, cannot appear in arbitrary
> places (e.g. in the declaration of a vla), longjmp
> must be in same thread etc.
>
> all th
Hi,
On Sun, 19 Jun 2016, David Wohlferd wrote:
> All basic asm in trunk: 1,105 instances.
> - Exclude 273 instances with empty strings leaving 832.
> - Exclude 271 instances for boehm-gc project leaving 561.
> - Exclude 202 instances for testsuite project leaving 359.
> - Exclude 282 instances th
Hi,
On Mon, 20 Jun 2016, Andrew Haley wrote:
> On 20/06/16 18:36, Michael Matz wrote:
> > I see zero gain by deprecating them and only churn. What would be the
> > advantage again?
>
> Correctness.
As said in the various threads about basic asms, all correctness
prob
Hi,
On Tue, 21 Jun 2016, Andrew Haley wrote:
> > As said in the various threads about basic asms, all correctness
> > problems can be solved by making GCC more conservative in handling
> > them (or better said: not making it less conservative).
>
> Well, yes. That's exactly why we've agreed t
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 Wed, 13 Feb 2019, Peng Fan wrote:
> So the fix should be the following, right?
Yup.
Ciao,
Michael.
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 in
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 with.
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 g
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 "Interf
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 want
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 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 wit
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 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
> exp
how 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_hin
1 - 100 of 480 matches
Mail list logo
