Re: Question about strange register calling truncates to SImode on x86_64

Hi, On Thu, 12 Oct 2006, Kai Tietz wrote: > thanks for description. I wasn't aware, that the upper 32 bits are > zeroed. Does this means that even the stack has to be in the first 4 Gb, > too. Why should it? I.e. no, it doesn't have to. > Or does this mov instruction does a sign-extention.

Re: Unwinding CFI gcc practice of assumed `same value' regs

Hi, On Tue, 12 Dec 2006, Andrew Haley wrote: > > > In practice, %ebp either points to a call frame -- not necessarily > > > the most recent one -- or is null. I don't think that having an > > > optional frame pointer mees you can use %ebp for anything random at > > > all, but we need to m

Re: Unwinding CFI gcc practice of assumed `same value' regs

Hi, On Mon, 11 Dec 2006, Jan Kratochvil wrote: > currently (on x86_64) the gdb backtrace does not properly stop at the > outermost > frame: > > #3 0x0036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0 > #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6 > #5 0x00

Re: Unwinding CFI gcc practice of assumed `same value' regs

Hi, On Tue, 12 Dec 2006, Ulrich Drepper wrote: > > Really? Well, that's one interpretation. I don't believe that, > > though. It's certainly an inconsistency in the specification, which > > says that null-termination is supported, and this implies that you > > can't put a zero in there. >

Re: Error help

Hi, On Wed, 2 Mar 2005, Rajkishore Barik wrote: > Checked out a version of new-regalloc code and patched some of my code. It > crashes in the bootstrapping > part where "xgcc" runs some of my code on __dtor* modules. Is there a way > to avoid this > bootstrapping? I do not really care about th

Re: matching constraints in asm operands question

Hi, On Sat, 5 Mar 2005 [EMAIL PROTECTED] wrote: > > Well, I assumed the same thing when I started poking at that code, but > > then someone pointed out that it didn't actually work that way, and as > > I recall the code does in fact assume a register. I certainly would > > not object to making '

Re: Installation into 'const' directory

Hi, On Wed, 16 Mar 2005, Art Haas wrote: > This morning's build of GCC mainline installed various files into a > directory named 'const' instead of a version number like name. The c++ > headers from yesterday's build were in a '4.1.0' directory, for example. > A perusal of the ChangeLog suggests

Re: Strange build errors compiling SPEC with mainline

Hi, On Fri, 18 Mar 2005, Diego Novillo wrote: > Starting around 2005-03-17, I haven't been able to compile > several SPEC tests with mainline. Has there been any change in > the pre-processor that might explain these errors? > > I'm pretty sure my installation is correct because this worked > u

Re: about new_regalloc

Hi, On Thu, 31 Mar 2005, zouq wrote: > in gcc3.4.1,i found rest_of_new_handle_regalloc > why in gcc4.0, it has been removed? It was removed from gcc 4 because it bitrotted and broke on all kinds of code. If you want to see a more recent and more working version look at the new-regalloc-branch

Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410

Hi, On Wed, 13 Apr 2005, Nick Rasmussen wrote: > I'm running into an ICE in the prerelease, that is proving to be > very difficult in reducing to a small testcase. If I preprocess > the source (via -E or -save-temps) the code successfully compiles. > If I minimally change the source file in som

Re: Should there be a GCC 4.0.1 release quickly?

Hi, On Thu, 28 Apr 2005, Mark Mitchell wrote: > I'd rather not rush to a 4.0.1 release. I'm a fan of release early, release often. Really. Even if this means we would end up with a 4.0.20 after half a year. Basically I can think of only one reason _not_ to release after a critical bug is fi

Re: Backporting to 4_0 the latest friend bits

Hi, On Sat, 30 Apr 2005, Kriang Lerdsuwanakij wrote: > Sure, this code compiles with 4.1 and 3.4 but doesn't compile with 4.0. > Although the code is valid, I'd bet it doesn't work the way the > programmer of the above code (or other 99% who doesn't track > the standard closely) would expect. No

Re: Backporting to 4_0 the latest friend bits

Hi, On Mon, 2 May 2005, Mark Mitchell wrote: > At the same time, if the code in question doesn't mean what the person > who wrote it wants it to mean (e.g., if it implicitly declares classes > in the scope of the friendly class, rather than nominating other classes > as friends), then that code s

Re: restrict and char pointers

Hi, On Thu, 5 May 2005, Daniel Berlin wrote: > You can do it, but apparently restrict isn't as simple as "a and b are > both restrict pointers and therefore can never alias", because that's > not the actual definition of restrict. It says stuff about pointers > "based on" restricted objects, etc.

RFA: Integrate ABI testsuite in GCC

Hi, I have this x86-64 ABI testsuite I worked on lately again (after some years lingering around, it was first written when we did the port on simulators still). It currently lies on cvs.x86-64.org in the 'abitest' module, for the curious (it has anoncvs too). I would like to somehow integrat

Re: Function Inlining for FORTRAN

Hi, On Wed, 20 Jul 2005, Steven Bosscher wrote: > On Wednesday 20 July 2005 17:22, Paul Brook wrote: > > To implement (b) this needs to be changed to: > > > > - Do everything up until gfc_generate{,_module}_code as normal. > > - Save the results somewhere and repeat for each PU. > > - Identify ca

Re: Link-time optimzation

Hi, On Thu, 17 Nov 2005, Kenneth Zadeck wrote: > A stack machine representation was chosen for the same reason. Tree > gimple is a series of statements each statement being a tree. IMHO we should follow that path of thinking. The representation of GIMPLE where we do most optimizations on (i.e

Re: Link-time optimzation

Hi, On Fri, 18 Nov 2005, Steven Bosscher wrote: > On Friday 18 November 2005 17:31, Michael Matz wrote: > > Perhaps even a merger of both > > approaches is sensible, three address form for most simple gimple > > statements with falling back to stack encoding for deeply neste

Re: Register Allocation

Hi, On Tue, 22 Nov 2005, Peter Bergner wrote: > Spill Location Optimizer [page(s) 11]: > * The IBM iSeries backend has this optimization. During spilling, > it inserts copies to/from spill pseudos (essentially like another > register class) which represent the stores/loads from t

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > Where does your '50 chars' limit come from? It's not in the glibc text, > and it's not in the linux kernel text either. AFAICT this is your > invention and you seem to be the only person proposing it. Nope, it's fairly common, so m

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hi, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > The idea is that the [...] part is NOT part of the commit, only part of > the email. I understand that, but the subject line of this thread says "e-mail subject lines", so I thought we were talking about, well, exactly that; and I see

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Jakub Jelinek wrote: > > > The idea is that the [...] part is NOT part of the commit, only part of > > > the email. > > > > I understand that, but the subject line of this thread says "e-mail > > subject lines", so I thought we were talking about, well, exactly that;

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > Well, I'd review a patch differently depending on whether or not it was > already committed, a patch requiring review or an RFC looking for more > general comments, so I *do* think such an email prefix is useful. As I said: a very go

Re: Question about undefined functions' parameters during LTO

Hello, On Fri, 13 Mar 2020, Erick Ochoa wrote: > +for (tree parm = DECL_ARGUMENTS (undefined_function->decl); parm; parm = > DECL_CHAIN (parm)) > + { > + tree type = TREE_TYPE(parm); > + if (dump_file) fprintf(dump_file, "I want the type, do I have it? > %s\n", type ? "true" :

Re: Not usable email content encoding

Hi, On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > > The key here is to realize that the raw message is not what you get > > > back from the mailing list reflector, and also not the raw message > > > that was sent by the sender. In this day of mta intermediaries, > > > proxies, reflect

Re: Not usable email content encoding

Hello, On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > > The From: header rewriting for DMARC participants is something sourceware > > > is doing now. > > > > Out of curiousity, is this rewriting you are talking about the cause for a > > lot of mails showing up as "From: GCC List" rathe

Re: Question about undefined functions' parameters during LTO

Hello, On Tue, 7 Apr 2020, Erick Ochoa wrote: > Thanks for this lead! It is almost exactly what I need. I do have one more > question about this. It seems that the types obtained via > FOR_EACH_FUNCTION_ARGS and TREE_TYPE are different pointers when compiled with > -flto. > > What do I mean by t

Re: Question about undefined functions' parameters during LTO

Hello, On Tue, 7 Apr 2020, Erick Ochoa wrote: > > So, when you want to compare types use useless_type_conversion_p (for > > equivalence you need useless(a,b) && useless(b,a)). In particular, > > for record types T it's TYPE_CANONICAL(T) that needs to be > > pointer-equal. (I.e. you could hard

Re: Not usable email content encoding

Hello, On Tue, 7 Apr 2020, Jonathan Wakely via Gcc wrote: > On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc > wrote: > > And can certainly score a positive though not a definite rating in spam > > qualification. I don't think we ought to encourage bad IT management > > practices by try

Re: Not usable email content encoding

Hello, On Tue, 7 Apr 2020, Frank Ch. Eigler wrote: > > I find that unconvincing, because even googlegroup email lists don't > > mangle From: from sender domains that are now mangled by sourceware.org > > :-/ > > It turns out receiving mail FROM google-groups mail is itself > sometimes at risk

Re: Not usable email content encoding

Hello, On Wed, 8 Apr 2020, Mark Wielaard wrote: > On Tue, 2020-04-07 at 11:53 +0200, Florian Weimer via Overseers wrote: > > Gmail can drop mail for any reason. It's totally opaque, so it's a > > poor benchmark for any mailing list configuration changes because it's > > very hard to tell if a pa

Re: Not usable email content encoding

Hello, On Mon, 13 Apr 2020, Christopher Faylor wrote: > On Wed, Apr 08, 2020 at 04:15:27PM -0500, Segher Boessenkool wrote: > >On Wed, Apr 08, 2020 at 01:50:51PM +, Michael Matz wrote: > >>On Wed, 8 Apr 2020, Mark Wielaard wrote: > >>>Earlier versions of Mainma

Re: GCC optimizations with O3

Hello, On Wed, 22 Apr 2020, Erick Ochoa wrote: > in order for me to debug my issue, I'm going to have to refactor passes > which directly reference optimize. For debugging you can also work backwards: use -O3 and add -fno-xy options. At least you then know (after disabling all O3 passes) that

Re: Should ARMv8-A generic tuning default to -moutline-atomics

Hello, On Wed, 29 Apr 2020, Florian Weimer via Gcc wrote: > Distributions are receiving requests to build things with > -moutline-atomics: > > > > Should this be reflected in the GCC upstream defaults for ARMv8-A > generic tuning? It

Re: New mklog script

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 () > > { > > .

Re: New mklog script

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

RE: New x86-64 micro-architecture levels

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

Re: Problems with changing the type of an ssa name

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... >

Re: [libgcc2.c] Implementation of __bswapsi2()

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

Re: [RFC] Increase libstdc++ line length to 100(?) columns

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

Re: [RFC] Increase libstdc++ line length to 100(?) columns

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

RE: [EXTERNAL] Re: DWARF Debug Info Relocations (.debug_str STRP references)

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

Re: 'walk_stmt_load_store_addr_ops' for non-'gimple_assign_single_p (stmt)'

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': > >>''. > >

Re: 'walk_stmt_load_store_addr_ops' for non-'gimple_assign_single_p (stmt)'

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

Re: dwarf DW_AT_decl_name: system headers vs source files?

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

Re: Repository for the conversion machinery

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

Re: Repository for the conversion machinery

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

Re: C++ order of evaluation of operands, arguments

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/

Re: C++ order of evaluation of operands, arguments

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

Re: ivopts vs. garbage collection

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

Re: ivopts vs. garbage collection

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

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 > >

Re: gnu-gabi group

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

Re: gengtype: conditional GTY ? (to add before GCC 6 release)

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,

Re: gengtype: conditional GTY ? (to add before GCC 6 release)

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

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,

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

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.

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

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

Re: [isocpp-parallel] Proposal for new memory_order_consume definition

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

Re: [isocpp-parallel] Proposal for new memory_order_consume definition

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

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

Re: Importance of transformations that turn data dependencies into control dependencies?

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

Re: [gimplefe] [gsoc16] Gimple Front End Project

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

Re: [gimplefe] [gsoc16] Gimple Front End Project

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

Re: Aggressive load in gcc when accessing escaped pointer?

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

Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

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

Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

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

Re: GCC 6 symbol poisoning and c++ header usage is fragile

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

Re: SafeStack proposal in GCC

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

Re: SafeStack proposal in GCC

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

Re: SafeStack proposal in GCC

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

Re: SafeStack proposal in GCC

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

Re: Deprecating basic asm in a function - What now?

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

Re: Deprecating basic asm in a function - What now?

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

Re: Deprecating basic asm in a function - What now?

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

Re: [GSoC] writing test-case

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

Re: [GSoC] writing test-case

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

Re: [GSoC] decision tree first steps

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

Re: GCC 4.9.1 Status Report (2014-07-10)

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

Re: Eliminated function return values in retarget

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:

Re: What is R_X86_64_GOTPLT64 used for?

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

Re: What is R_X86_64_GOTPLT64 used for?

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

Re: What is R_X86_64_GOTPLT64 used for?

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

Re: What is R_X86_64_GOTPLT64 used for?

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,

Re: What is R_X86_64_GOTPLT64 used for?

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

Re: [ping] Re: proper name of i386/x86-64/etc targets

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

Re: [ping] Re: proper name of i386/x86-64/etc targets

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

Re: [ping] Re: proper name of i386/x86-64/etc targets

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

Re: Why is floor() only compiled to roundsd when using -funsafe-math-optimizations?

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

Re: pass_stdarg problem when run after pass_lim

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

Re: pass_stdarg problem when run after pass_lim

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

Re: pass_stdarg problem when run after pass_lim

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

Re: pass_stdarg problem when run after pass_lim

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

Re: Postpone expanding va_arg until pass_stdarg

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

  1   2   3   4   5   >