compiler output conflict
I ran across this puzzling difference between gcc and llvm today and think the specification to produce consistent output for this code should be worked out. http://stackoverflow.com/questions/15929795/llvm-and-gcc-different-output-same-code/23856132#23856132 I presented this in the Freenode #gcc chatroom too. John T http://www.mozilla.org Firefox browser, Thunderbird email, Seamonkey all-in-one, Sunbird calendar and more. Free open-source software for Windows, Linux, Mac OS and other systems
Known regression ? gcc-4.0.0-20050312 FPE's on C++
Hi. I'm just asking if this is a known bug. If not I'll prepare a bug report, with bzipped preprocessed source. I'm seeing this: hpm05fuvec0.cpp:5538: internal compiler error: Floating point exception Please submit a full bug report, quite often when compiling large chunks of machine-generated C++. gcc-3.4.3 works fine on the same testcases. The compiler is: $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../sources/gcc-4.0-20050312/configure --enable-languages=c,c++ --enable-__cxa_atexit --disable-checking --disable-nls --prefix=/usr/local/gcc/gcc-4.0-20050312 Thread model: posix gcc version 4.0.0 20050312 (prerelease) The compiler was bootstrapped with gcc-3.4.3 I can have another go without the "--disable-checking" if that's likely to help. Anything else you'd like in the bug report ? gcc-4 is a lot faster at compiling templatey C++ than 3.4.3, but the compiled code performance is sometimes better, sometimes worse. It's a bit hard to tell, since our big testcases currently ICE with FPE's on gcc-4.0. Regards, John.
Re: Copyright question: libgcc GPL exceptions
Mike Stump wrote: The canonical form can be found in gcc/libgcc2.c: [...] (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combine executable.) (Been wondering about this for a while...) Possibly this is one of those North American dialect things, but to this (non-American) English speaker this canonical form appears to contain a typo. "[...] when not linked into a combined executable", surely? John
[gnu.org #232556] GNU Mirror: SWITCHmirror replaces Swiss SunSITE
Hello, I've updated the mirror list on gnu.org. I'm passing this on to you so you can consider it for the GCC mirrors list as per his request. Start of forwarded message Subject: [gnu.org #232556] GNU Mirror: SWITCHmirror replaces Swiss SunSITE From: "[EMAIL PROTECTED] via RT" <[EMAIL PROTECTED]> Hello Gnu SWITCHmirror replaces the mirror service on Swiss SunSITE (sunsite.cnlab-switch.ch). Could you please add SWITCHmirror to the page <http://gcc.gnu.org/mirrors.html> On the page <http://www.gnu.org/order/ftp.html>, could you please replace the reference to Swiss SunSITE with the one to SWITCHmirror? The correct links for our mirror are now: http://mirror.switch.ch/ftp/mirror/gnu/ ftp://mirror.switch.ch/mirror/gnu/ The new contact address is: [EMAIL PROTECTED] it replaces the old address: [EMAIL PROTECTED] Country: Switzerland Many thanks ikn advance! Kind Regards Thomas _ Thomas Lenggenhager[EMAIL PROTECTED] SWITCH The Swiss Education & Research Network Neumuehlequai 6 Tel: +41 44 268 1520 CH-8001 Zurich, Switzerland Fax: +41 44 268 1568 End of forwarded message -- John Sullivan Program Administrator| Phone: (617)542-5942 51 Franklin Street, 5th Fl. | Fax: (617)542-2652 Boston, MA 02110-1301 USA| GPG: AE8600B6
Multi-Kulturell = Multi-Kriminell
Lese selbst: http://www.npd.de/npd_info/meldungen/2005/m0105-19.html
Cross compiler libgcc.a with -mthumb-interwork
I'm trying to create a cross compiler hosted on i386 linux targetting an embedded arm thumb device with thumb-interworking on. When I attempt to link my app which has some ARM code in it (hence the need for interwork) I get this message... /opt/gcc4thumb/lib/gcc/arm-elf/4.1.0/../../../../arm-elf/bin/ld: Warning: /opt/gcc4thumb/lib/gcc/arm-elf/4.1.0/thumb/libgcc.a(_udivdi3.o) does not support interworking, whereas test_Application does (I'm trying to get an estimate of how much ram/flash our very resource constrained embedded app will use if we move to gcc 4.1 when it comes out.) I have tried configuring CVS version of gcc latest to.. ../combined/configure --target=arm-elf --enable-languages=c,c++ \ --with-newlib --prefix=/opt/gcc4arm --with-cpu=arm7tdmi \ --enable-target-optspace I have tried exporting the following flags before building... export CFLAGS_FOR_TARGET='-Os -mthumb -mthumb-interwork' export CXXFLAGS_FOR_TARGET='-Os -mthumb -mthumb-interwork' export LDFLAGS_FOR_TARGET='-Os -mthumb -mthumb-interwork' export LIBCFLAGS_FOR_TARGET='-Os -mthumb -mthumb-interwork' export LIBCXXFLAGS_FOR_TARGET='-Os -mthumb -mthumb-interwork' but no success. Please, what is the magic handshake to do this? I been around this track sooo many times, in soo many different ways, I'm getting tired of my own tail! (One of the other routes I tried was building --target=thumb-elf, but gas doesn't support that...) Thanks for your patience, John Carter Phone : (64)(3) 358 6639 Tait ElectronicsFax : (64)(3) 359 4632 PO Box 1645 ChristchurchEmail : [EMAIL PROTECTED] New Zealand Carter's Clarification of Murphy's Law. "Things only ever go right so that they may go more spectacularly wrong later." From this principle, all of life and physics may be deduced.
options for compiling C using C++ compiler
I'm working on a project where I post-process AST (.tu) output from gcc using the -fdump-translation-unit option. Problem is the C compiler does not generate useful AST data. So I actually run the preprocessed source again thru g++ to get AST data. This works fine unless there are constructs not allowed under C++. Particular problems are bool and other keyword stuff and K&R style function declarations. I'm trying to find the best way to minimize the problem via options or other ways. I already use "-fpermissive" and this eases it a bit. Suggestions? -J _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
options for compiling C using C++ compiler [trying 1 more time]
I'm working on a project where I post-process AST (.tu) output from gcc using the -fdump-translation-unit option. Problem is the C compiler does not generate useful AST data. So I actually run the preprocessed source again thru g++ to get AST data. This works fine unless there are constructs not allowed under C++. Particular problems are bool and other keyword stuff and K&R style function declarations. I'm trying to find the best way to minimize the problem via options or other ways. I already use "-fpermissive" and this eases it a bit. Suggestions? -J _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
GCC 3.x and -fvtable-thunks
Hi, It appears GCC 3.x no longer supports the -fvtable-thunks option. Is gcc 3.x using thunks by default for its vtable format? Also, can the _G_USING_THUNKS macro no longer used to determine if thunks are being used? Thanks, John __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/
successful bootstrap
Hey, just a note to let you guys know i bootstrapped gcc 3.4.5 on my SPARC64/OpenSolaris ( ultrasparc II / opensolaris nv28) box (after fighting with it, but that's my fault). I haven't tried to compile g77 or ada or any such thing, since i only need c and c++. Only one processor in the box, no idea how this'd work with SMP. evidently GNU make is a must. GNU binutils, similarly. The compiler i used to build GCC (and everything previous) was SunStudio10 (which is register-for-free-smokes free). also, the requirement that one passes CC="cc -xildoff -xarch=v9" is still in effect with studio10/solaris11 here's the shell output you guys want: [SPARCy] error404 :: objdir $ ./config.guess sparc-sun-solaris2.11 [SPARCy] error404 :: objdir $ gcc -v Reading specs from /opt/GNU/lib/gcc/sparc- sun-solaris2.11/3.4.5/specs Configured with: ../configure --with-gnu-as --with-as=/opt/GNU/bin/as --with-gnu-ld --with-ld=/opt/GNU/bin/ld --prefix=/opt/GNU --enable-languages=c,c++ --disable-nls --enable-shared Thread model: posix gcc version 3.4.5 Cheers! -john -- PGP public key availiable on wwwkeys.pgp.net
Re: GCC association with the FSF
On Wed, Apr 07, 2021 at 11:15:14AM -0400, David Malcolm via Gcc wrote: > It reflects the same message that has been sent to new GNU > maintainers > for the decades. The GNU structure and organization document > (https://www.gnu.org/gnu/gnu-structure.en.html) is basically a > reflection of that, and how we have been doing things for decades. "We've always done it this way" is not necessarily a good defence of an existing practice. You are right. The GNU Structure document doesn't claim to be. It just documents the way things are. > That is true, RMS appoints which projects become GNU projects or not, > and who maintains them. And as maintainers we have a lot of freedom, > as > can be seen here, and elsewhere. What you're describing sounds like a dictatorship to me. I cannot see how you reach that conclusion. I don't think you get to speak for who is or is not a member of the GNU project. As far as I know, "GNU" isn't trademarked. It certainly used to be, unless those guys at the FSF have let it lapse again. J'
Re: GCC association with the FSF
On Wed, Apr 07, 2021 at 06:34:12PM -0400, David Malcolm wrote: > > What you're describing sounds like a dictatorship to me. > > I cannot see how you reach that conclusion. Having one guy at the top from whom all power flows. Power does not "flow" from RMS. Since you have used a political analogy: I think it is more akin to a constitutional monarchy. What's the process for replacing the guy at the top, if he's become a liability to the project? What would a healthy structure look like? Many countries have a single person as head of state with no formally defined process for replacing him or her. Most of those countries are not usually descibed as "dictatorships". Further, history has shown, in cases where that head of state has been forcibly removed (eg France, Russia). the regime that replaced them turned out to be composed of murderous powermongers concerned with nobody's interest but their own. I for one, will not sit back and let that heppen to GNU. J'
Re: GCC association with the FSF
On Thu, Apr 08, 2021 at 07:56:14AM -0400, Richard Kenner wrote: > Having one guy at the top from whom all power flows. > > Power does not "flow" from RMS. Since you have used a political analogy: > I think it is more akin to a constitutional monarchy. I think it's like the Queen of England. As a British person I used to know said: "The Queen of England has the power to veto anything passed by the Parliament in any Commonwealth country until she actually does it; at that point she'll lose that power". In 1975 she dismissed the prime minister of Australia, yet nearly 50 years later she is still the head of state. I see it as the same here: if RMS tried to exert an inappropriate level of control over some GNU project, it would soon be made clear that that something he can't do. Generally I agree. Such draconian measures like dismissal of people has to be done tactfully, only occasionally and only when there is very good cause. So far as I'm aware, her majesty has done it only once; rms has done it only twice. J'
Re: GCC association with the FSF
On Thu, Apr 08, 2021 at 10:54:25AM -0400, David Malcolm wrote: I think it's important to distinguish between the figurative and literal here. No one is literally calling for anyone's head. Nobody has explicitly done so. However in the last 2 or 3 years there has been a growing campaign of hatred. The people feeding that campaign are unhappy with things that RMS and others have said. However they have taken it further than that. These people seek eliminate *anyone* who holds certain opinions - they don't care how they get eliminated - so long as they go. What's more, they cite numerous putative moralistic justifications to give an air of legitmacy to that hatred. Once such hatefulness becomes accepted, people DON'T any longer make that literal--figurative distinction. Some of us don't want RMS in a leadership position in a project we're associated with (be it the FSF or GNU, and thus, GCC). RMS was the first person to be involved in GNU and GCC. Others became involved later (under his leadership). Their contribution was and continues to be welcome. They are also free to stop contributing any time they wish to do so. My opinions, not my employer's, as usual. Then why do you write this from your employer's email? That is like writing it on the company letterhead. I suggest that when speaking for yourself you use your own email. J'
Re: GCC association with the FSF
On Thu, Apr 08, 2021 at 09:35:23PM -0400, David Malcolm wrote: > RMS was the first person to be involved in GNU and GCC. Others > became > involved later (under his leadership). Their contribution was and > continues to be welcome. They are also free to stop contributing any > time they wish to do so. I intend to continue contributing to GCC (and to Free Software in general), but RMS is not my leader. Nobody is suggesting that RMS should be regarded by everyone or indeed anyone as "mein Führer". I think he would be very much concerned if anyone tried to confer a cult hero status on him. Sooner or later, if for no reason other than his age, RMS will have to step down as leader of GNU. Rather than calling for his head on a block it would be more constructive to think to the future. Unfortunately to date, I have not seen anyone who in my opinion would have the qualities necessary to take over the role. > Then why do you write this from your employer's email? My employer gives me permission. That's good to know. My employer on the other hand expressly forbids it. And I think that is a reasonable prohibition (we're allowed to use their internet connection for personal use) but not allowed to use the company name (including email addresses) in personal communication. Even if they didn't prohibit this, I wouldn't dream of using my company's email or letterhead for personal communication. Given the reaction that some have faced for questioning RMS, I'd prefer to keep that address private. So in other words, you are happy to make contraversial statements, but don't wish to face the responsibility. Come on David! By all means question RMS (or anyone else) but have the guts to do this under your own identity rather than duck in and out behind a veil of quasi-anonymity! I'm glad that you're going to continue to contribute to GCC. J'
Re: GCC association with the FSF
On Fri, Apr 09, 2021 at 07:01:07PM +0200, David Brown wrote: Different opinions are fine. Bringing national or international politics into the discussion (presumably meant to be as an insult) is not fine. This is not a political discussion - please stop trying to make it one. For the record it was David who first brought up the political allegory so this comment should be directed in his direction. As for your second point, I find it disappointing but not suprising that you "presumed" this comment to be an insult. This is precisely the thing which has caused so much poisonous discourse in recent years. Some people take any opinion they disagree with and look for ways to interpret it as an insult. This gives them a lever to claim that anyone who holds that opinion is a chauvanist, a bigot or worse. This must stop.
Re: GCC association with the FSF
On Sat, Apr 10, 2021 at 01:50:42PM +0100, Bronek Kozicki via Gcc wrote: I would very much prefer if a person who openly expressed opinions, and also openly exercised behaviours, which I consider abhorrent, was *not* associated with the GCC project. It does not matter to me what kind of control that person exerts on the project, if any. What matters to me is association, even if indirect one (other than historical). I suppose I feel the same. I would also prefer it if all people involved with GCC (and all my other interests) did not do or say things which made me uncomfortable. I don't however feel that I have the right to call for anyone to be excluded simply because I'm uncomfortable with that person's words or deeds (ie. "consider them abhorent"). That would be an utterly dystopian, world. Of course persons should not use a project's name or infrastructure to make comments unrelated to the project. But if that person wishes to make a comment under his/her own name in an unrelated forum, that is his/her right. Even if we consider them abhorrent, we must respect the rights of others. J'
Re: GCC association with the FSF
On Sun, Apr 11, 2021 at 12:30:41AM +0200, Gerald Pfeifer wrote: There are a number of people arguing here who have contributed little to nothing to GCC, whose names even did not trigger memories - unlike David M. or Jonathan, for example, or Nathan or Alexandre. For myself, I have been a long term user/contributor to GCC albiet hardly in a major role. I don't think I've ever posted to this list until a few days ago, when all of a sudden these messages started popping up in my inbox. So either I subscribed to this list many years ago and it has been dormant until recently or someone subscribed me just recently. When it comes to deciding the direction of a project like GCC - technical and otherwise - in my mind it primarily should be those actually involved and contributing. I disagree. The principle by which high level decisions in all GNU projects have always been made is how it best helps the GNU system as a whole. Contributors are exactly that. They offer *contributions* - the very meaning of the word implies there is no expectation of anything in return. Obviously I hope all contributors *do* get some satisfaction and maybe even some tangible benefit. But contributions are not to be seen as a means to gain control of the project at a high level. J'
Re: GCC association with the FSF
On Sun, Apr 11, 2021 at 09:30:48AM -0400, Richard Kenner via Gcc wrote: > > When it comes to deciding the direction of a project like GCC - technical > > and otherwise - in my mind it primarily should be those actually involved > > and contributing. > > GNU follows the general principle of the Free Software movement, that > freedom for *users* is the priority. Assigning *higher* importance to > developers' preferences is *not* a position I share. I think there's a difference between philosophy and practicality here. Sure, the importance of work done by different developers, measured on the scale of advancing the goals of the Free Software movement, is different for each. But what actually advances a project (which can be viewed as "deciding [its] direction") is what work developers choose to do, not the importance of each piece of work on that metric. I guess my point is that the direction in which a project *does* go is not always the direction in which it *should* go. I conceed that the converse is also true: Technical experts are very useful for putting the brakes on Joe Average User's crazy ideas when they are doomed to failure from the outset. So I certainly agree with what you said above, but don't think that changes the reality that it's ultimately what developers choose to work on that most affects the direction of a project. That indeed is often the reality, but equally as often *not* what is desired. To give just one small practical example, I'm told (by people who are more familiar with GCC internals than I) that it is not feasible with today's GCC to port to backends which have a small number of registers. This has meant that whole familys of CPUs work only with proprietary compilers. J'
Chat about a possible working agreement with gcc.gnu.org
Hey there, I wanted to contact you about how we can work together linkbuilding. Would you be open to the idea? - John
Re: GCC association with the FSF
41;344;0cOn Sun, Apr 11, 2021 at 07:30:13PM -0300, Adhemerval Zanella via Gcc wrote: And there was no hate (at least not from my side) only *disappointment* that you used your status to do it even though most of senior developers and maintainers said explicitly you shouldn’t do it. In GNU, there are no "senior" (or junior) developers/maintainers. Maintainers have some specific responsibilities, with which developers are not emcumbered. In almost all projects, the maintainers are also developers, but this need not be the case. But all maintainers are equal, and all developers are equal. J'
Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers
On 9/21/15 12:27 PM, H.J. Lu via cfe-dev wrote: On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu wrote: On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu wrote: To implement interrupt and exception handlers for x86 processors, a compiler should support: 1. void * __builtin_ia32_interrupt_data (void) I got a feedback on the name of this builtin function. Since it also works for 64-bit, we should avoid ia32 in its name. We'd like to change it to void * __builtin_interrupt_data (void) Here is the updated spec. This updated spec adds unsigned int __builtin_exception_error (void) unsigned long long int __builtin_exception_error (void) This function returns the exception error code pushed onto the stack by processor. Its return value is 64 bits in 64-bit mode and 32 bits in 32-bit mode. This function can only be used in exception handler. Exception handlers can, in general, call regular functions which, in turn, might want to access the error code. Given that operating system kernels are always entered via an interrupt, trap, or system call, there should always be an error code available (on x86, non-error-code interrupts can just make up an error code). It also changes the definition of void * __builtin_interrupt_data (void) so that it returns a pointer to the data layout pushed onto stack by processor for both interrupt and exception handlers. You might want to have a look at Secure Virtual Architecture (SVA). One of the things we discovered is that commodity operating systems access the most recently used interrupt data (which SVA calls an "interrupt context"). Over the years, we figured out that it's better to provide intrinsics (i.e., builtins) that implicitly access the top-most interrupt context. We also found that we could limit the operations performed on interrupt contexts so that we could safely implement signal handlers and exception recovery without letting the operating system kernel have pointers to the interrupt context which would need to be checked. In short, despite common belief, the OS does not need to do whatever it wants with interrupted program state. I recommend you take a look at Appendix A of my dissertation (https://www.ideals.illinois.edu/handle/2142/50547). It describes the SVA-OS instructions used to abstract away the hardware details. You'll also notice that the design is pretty processor transparent (MMU notwithstanding), so designing your builtins based on SVA may make them more portable if you decide to use another processor later on. Chapter 2 describes some of the rationale behind the design, though it's for the first version of SVA (Appendix A is the final instruction set after 4 papers). If the implementation is useful, SVA is publicly available at https://github.com/jtcriswell/SVA. Finally, to echo Joerg's concerns, it's not clear that having exception/interrupt handlers declared as a special type is really helpful. It's not immediately obvious that you get a benefit from doing that vs. doing what most system software does (having assembly code that saves processor state and calls a C function). I think you should do some experiments to demonstrate the benefit that one can get with your method to see if it is worth adding complexity to the compiler. Regards, John Criswell -- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell
Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers
On 9/21/15 4:45 PM, H.J. Lu wrote: On Mon, Sep 21, 2015 at 11:52 AM, John Criswell wrote: On 9/21/15 12:27 PM, H.J. Lu via cfe-dev wrote: On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu wrote: On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu wrote: To implement interrupt and exception handlers for x86 processors, a compiler should support: 1. void * __builtin_ia32_interrupt_data (void) I got a feedback on the name of this builtin function. Since it also works for 64-bit, we should avoid ia32 in its name. We'd like to change it to void * __builtin_interrupt_data (void) Here is the updated spec. This updated spec adds unsigned int __builtin_exception_error (void) unsigned long long int __builtin_exception_error (void) This function returns the exception error code pushed onto the stack by processor. Its return value is 64 bits in 64-bit mode and 32 bits in 32-bit mode. This function can only be used in exception handler. Exception handlers can, in general, call regular functions which, in turn, might want to access the error code. Given that operating system kernels are always entered via an interrupt, trap, or system call, there should always be an error code available (on x86, non-error-code interrupts can just make up an error code). It also changes the definition of void * __builtin_interrupt_data (void) so that it returns a pointer to the data layout pushed onto stack by processor for both interrupt and exception handlers. You might want to have a look at Secure Virtual Architecture (SVA). One of I believe my x86 interrupt attribute is unrelated to SVA. Actually, I really think that it is. Part of the SVA work extended the LLVM IR to support an operating system kernel. Your design for interrupt handlers and accessing interrupted program state looks very similar to my first draft of those extensions and has the exact same limitations (plus at least one limitation that my design did not have). It's pretty clear to me that you're redesigning a subset of the SVA-OS extensions from scratch; I find that unfortunate because you are literally reinventing the wheel. If the implementation is useful, SVA is publicly available at https://github.com/jtcriswell/SVA. Finally, to echo Joerg's concerns, it's not clear that having exception/interrupt handlers declared as a special type is really helpful. It's not immediately obvious that you get a benefit from doing that vs. doing what most system software does (having assembly code that saves processor state and calls a C function). I think you should do some experiments to demonstrate the benefit that one can get with your method to see if it is worth adding complexity to the compiler. The main purpose of x86 interrupt attribute is to allow programmers to write x86 interrupt/exception handlers in C WITHOUT assembly stubs to avoid extra branch from assembly stubs to C functions. I want to keep the number of new intrinsics to minimum without sacrificing handler performance. I leave faking error code in interrupt handler to the programmer. If you want to do that, there is another approach that should work just as well and will require only localized changes to the compiler. Interrupt handlers are typically registered to some interrupt vector number using a registration function. In FreeBSD, it's setidt(), and in Linux, I think it's set_gate(). You can write a compiler transform that looks for these registration functions, determines the function that is registered as an interrupt handler, and generate the more efficient code for that interrupt handler function as you describe. This solution avoids language extensions to the C/C++ front-end (which requires getting approval from the Clang developers) yet should get you the performance that you want (provided that it does improve performance, for which I'm a little skeptical but open to convincing via performance measurements). You can probably write this transform as a single LLVM MachineFunctionPass that your patched version of Clang runs during code generation. In any event, that's my two cents. Regards, John Criswell -- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell
Re: Removing "Severity" from New Bug form
On 12/8/2015 4:26 PM, Frédéric Buclin wrote: > Le 08. 12. 15 14:16, Jonathan Wakely a écrit : >>> Dropping it is ok I think. >> >> Yes, even for the valid "enhancement" cases a maintainer who triages >> the report could set that easily enough. > > If maintainers still use the severity field to triage bugs, then it > should not be dropped. It would be much easier to restrict the ability > to edit the severity field to users with editbugs privs (basically users > with a @gcc.gnu.org account + a few other accounts). > If the person submitting the PR gets to set the severity field, it should be dropped. If anybody sets the severity, it should be the people *doing* the triage or the person to whom the PR is eventually assigned. John
Re: Using associativity for optimization
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[Apologies if I'm talking rubbish, or spamming folk with the obvious]
Such an optimisation would ideally be dependent on some estimate on
the register pressure for the relevant register class[es], and perhaps
on some heuristic estimate of the relative execution frequency.
As a standalone function on many RISC machines, register allocation
for foo() is free. But if we inline foo() into a larger function,
register pressure and code fetch time become more important, perhaps
depending on whether the code is executed at most once per invocation,
or known to be executed a million times per invocation.
John.
On 02/12/14 10:23, Richard Biener wrote:
> On Tue, Dec 2, 2014 at 12:11 AM, shmeel gutl
> wrote:
>> While testing my implementation of passing arguments in
>> registers, I noticed that gcc 4.7 creates instruction
>> dependencies when it doesn't have to. Consider:
>>
>> int foo(int a1, int a2, int a3, int a4) { return a1|a2|a3|a4; }
>>
>> gcc, even with -O2 generated code that was equivalent to
>>
>> temp1 = a1 | a2; temp2 = temp1 | a3; temp3 = temp2 | a4;
>>
>> return temp3;
>>
>> This code must be executed serially.
>>
>> Could I create patterns, or enable optimizations that would cause
>> the compiler to generate
>>
>> temp1 = a1 | a2; temp2 = a3 | a4; temp3 = temp1 | temp2;
>>
>> Thereby allowing the scheduler to compute temp1 and temp2 in
>> parallel.
>
> You can tune it with --param tree-reassoc-width=N, not sure if
> that was implemented for 4.7 already.
>
> Richard.
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBAgAGBQJUfdQ2AAoJEOFemvuvogvZI7cP+gKv+q2ZHlPADVfdU+jK4CRK
RjLtCsfhj216l7mCFB6Gx5FMNExOYkwK3I9r8Da7TC/o/zDAAHX3aqhWFy64/JGW
o1dCZd8Cr1fwTvqM6jWKjcY1ddkdDsPLA2rHG0GZGn6VQWWdyvfpTFNjG8VK4KBl
GO01bcvcHJ88pwQQd2q/4FrFcTcBgdEZO7IfBgTeTEfZDdWPBe9+fWPXvqHoHZRM
ti74fe/8K39SUopVPrBqkgUPXs4iGwNg0VLoRQhRoYeuiruexzXCDAl0j4MuihAD
A4ssrp+CJV6gf7hPiZCm6T8p0XN3+W1UB9xTrn055dujVK0/uSvYhjrR8c3HMx0M
4jRZG7+5tJqC45hEyHZ+m+cmtjIWGzVPevYv2pzH6lyzd8eFf4q+4VBDVdDQRT3s
4RkBosccVgj7CHn0/rVJfTa/ONQMNSikq1HUYeXJwg8Lclm929jXNRP/tEj37OH0
UibM38t+ZMwI0LvKhbQm4904ASFCi8qNTEN/c3VS86A0smMPlGX7OSq2k/IuEcRx
lDd4msu2/aRTIgunmEl2558wlSbOlxtO6jPjri5HdzTajaQSC9t5T3pmi+P+Y5R5
+6OPy/BFSVyqKXS+kPA0IyOFE2iBgbHHfTbtptzeN2Tk3eGm1Ssk20JBqhRBvZTt
/doeToTwibJ8ZDgF2Q/O
=CghE
-END PGP SIGNATURE-
Re: Rename C files to .c in GCC source
On 1/31/2015 02:55, Jonathan Wakely wrote:
> On 30 January 2015 at 21:39, DJ Delorie wrote:
>>
>> pins...@gmail.com writes:
>>> No because they are c++ code so capital C is correct.
>>
>> However, we should avoid relying on case-sensitive file systems
>> (Windows) and use .cc or .cxx for C++ files ("+" is not a valid file
>> name character on Windows, so we can't use .c++).
>
> These files are only compiled by GCC's own build system, with GCC's
> own makefiles, so we know we invoke the C++ compiler and so the
> language isn't inferred from the file extension, and so we aren't
> relying on case-sensitive file systems.
To give a counter-perspective, having files that need to be compiled
with c++ driver having the extension ".c" gives external build systems
fits. Case in point, I'm working on bringing gcc5 into DragonFly as a
next base compiler and the make's base scripts all immediately use the c
driver for c files -- I had to apply hacks everywhere and even create
new local equivalents of "bsd.*.mk" files in some cases. (vendor
makefiles are never used by policy, new "bmake" ones have to be created
and imported -- this seems to be common to all BSD)
Even if this issue is normally hidden due to gcc's makefiles accounting
for it, having misleading file names can only cause problems.I'll
add a "+1" to the suggestion to go rename everything consistently and
accurately.
Sorry about butting in, but I thought that my recent experience with
this might be relevant to the topic.
John
Re: is it time to mass change from .c to .cc in gcc/ ?
On 4/15/2015 10:09, Richard Biener wrote: > On Wed, Apr 15, 2015 at 2:09 AM, Trevor Saunders > wrote: > I don't buy this kind of argument given that the switch to C++ has > complicated things instead of simplifying them. I've written before about how problematic having c++ files with .c extensions was for importing gcc into DragonFly's base. The system .mk files have targets based on extension (e.g. .c=.o) and it chooses cc or c++ based on those targets. We had to install difficult hacks to work around it. Honestly, mandatory renaming of the files should have been a condition of allowing c++ in the code base. e.g. "guys, if we do this, we have to rename all files requiring compilation by c++ compiler". I know you can wave this off as "we provide a build system for gcc, this isn't a valid reason" but the fact is this is counter-intuitive and confusing. I also think this should be fixed properly, and ripping off the band-aid seems reasonable to me. Regards, John
gcc 8.3 estimated release date?
Hi Guys, I guess back in July, the release of 8.3 was expected by the end of 2018. Now it's February. Is the next release of the 8 series imminent? if not, any idea when it might come? Thanks, John
Re: Re: [GSoC'19, libgomp work-stealing] Task parallelism runtime
unsubscribe On Mon, Jun 24, 2019, at 3:55 PM, 김규래 wrote: > Hi, > I'm not very familiar with the gomp plugin system. > However, looking at 'GOMP_PLUGIN_target_task_completion' seem like > tasks have to go in and out of the runtime. > In that case, is it right that the tasks have to know from which queue > they came from? > I think I'll have to add the id of the corresponding queue of each task > in the gomp_task structure. > > Ray Kim >
Indirect memory addresses vs. lra
I'm trying to write a back-end for an architecture (s12z - the ISA you can
download from [1]). This arch accepts indirect memory addresses. That is to
say, those of the form (mem (mem (...))) and although my
TARGET_LEGITIMATE_ADDRESS
function returns true for such addresses, LRA insists on reloading them out of
existence.
For example, when compiling a code fragment:
volatile unsigned char *led = 0x2F2;
*led = 1;
the ira dump file shows:
(insn 7 6 8 2 (set (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8])
(const_int 754 [0x2f2])) "/home/jmd/MemMem/memmem.c":15:27 96 {movpsi}
(nil))
(insn 8 7 14 2 (set (mem/v:QI (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8]) [0
*led_7+0 S1 A8])
(const_int 1 [0x1])) "/home/jmd/MemMem/memmem.c":16:8 98 {movqi}
(nil))
which is a perfectly valid insn, and the most efficient assembler for it is:
mov.p #0x2f2, y
mov.b #1, [0,y]
However the reload dump shows this has been changed to:
(insn 7 6 22 2 (set (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8])
(const_int 754 [0x2f2])) "/home/jmd/MemMem/memmem.c":15:27 96 {movpsi}
(nil))
(insn 22 7 8 2 (set (reg:PSI 8 x [22])
(mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8]))
"/home/jmd/MemMem/memmem.c":16:8 96 {movpsi}
(nil))
(insn 8 22 14 2 (set (mem/v:QI (reg:PSI 8 x [22]) [0 *led_7+0 S1 A8])
(const_int 1 [0x1])) "/home/jmd/MemMem/memmem.c":16:8 98 {movqi}
(nil))
and ends up as:
mov.p #0x2f2, y
mov.p (0,y) x
mov.b #1, (0,x)
So this wastes a register (which leads to other issues which I don't want to go
into in this email).
After a lot of debugging I tracked down the part of lra which is doing this
reload to the function process_addr_reg at lra-constraints.c:1378
if (! REG_P (reg))
{
if (check_only_p)
return true;
/* Always reload memory in an address even if the target supports such
addresses. */
new_reg = lra_create_new_reg_with_unique_value (mode, reg, cl, "address");
before_p = true;
}
Changing this to
if (! REG_P (reg))
{
if (check_only_p)
return true;
return false;
}
solves my immediate problem. However I imagine there was a reason for doing
this reload, and presumably a better way of avoiding it.
Can someone explain the reason for this reload, and how I can best ensure that
indirect memory operands are left in the compiled code?
[1] https://www.nxp.com/docs/en/reference-manual/S12ZCPU_RM_V1.pdf
--
Avoid eavesdropping. Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.
signature.asc
Description: PGP signature
Re: Indirect memory addresses vs. lra
On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote: Yea, it's certainly designed with the more mainstream architectures in mind. THe double-indirect case that's being talked about here is well out of the mainstream and not a feature of anything LRA has targetted to date. So I'm not surprised it's not working. My suggestion would be to ignore the double-indirect aspect of the architecture right now, get the port working, then come back and try to make double-indirect addressing modes work. This sounds like sensible advice. However I wonder if this issue is related to the other major outstanding problem I have, viz: the large number of test failures which report "Unable to find a register to spill" - So far, nobody has been able to explain how to solve that issue and even the people who appear to be more knowlegeable have expressed suprise that it is even happening at all. Even if it should turn out not to be related, the message I've been receiving in this thread is lra should not be expected to work for non "mainstream" backends. So perhaps there is another, yet to be discovered, restriction which prevents my backend from ever working? On the other hand, given my lack of experience with gcc, it could be that lra is working perfectly, and I have simply done something incorrectly.But the uncertainty voiced in this thread means that it is hard to be sure that I'm not trying to do something which is currently unsupported. J' -- Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.
Re: Indirect memory addresses vs. lra
On Fri, Aug 09, 2019 at 01:34:36PM -0400, Vladimir Makarov wrote: If you provide LRA dump for such test (it is better to use -fira-verbose=15 to output full RA info into stderr), I probably could say more. I've attached such a dump (generated from gcc/testsuite/gcc.c-torture/compile/pr53410-2.c). The less regs the architecture has, thoke easier to run into such error message if something described wrong in the back-end.?? I see your architecture is 16-bit micro-controller with only 8 regs, some of them is specialized.?? So your architecture is really register constrained. That's not quite correct. It is a 24-bit micro-controller (the address space is 24 bits wide). There are 2 address registers (plus stack pointer and program counter) and there are 8 general purpose data registers (of differing sizes). J' -- Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. Building IRA IR Pass 0 for finding pseudo/allocno costs r36: preferred X_REG, alternative NO_REGS, allocno X_REG a0 (r36,l0) best X_REG, allocno X_REG r35: preferred X_REG, alternative NO_REGS, allocno X_REG a10 (r35,l0) best X_REG, allocno X_REG r34: preferred X_REG, alternative NO_REGS, allocno X_REG a1 (r34,l0) best X_REG, allocno X_REG r33: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a11 (r33,l0) best DATA_REGS, allocno DATA_REGS r32: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a12 (r32,l0) best DATA_REGS, allocno DATA_REGS r31: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a14 (r31,l0) best DATA_REGS, allocno DATA_REGS r30: preferred NO_REGS, alternative NO_REGS, allocno NO_REGS a13 (r30,l0) best NO_REGS, allocno NO_REGS r29: preferred X_REG, alternative NO_REGS, allocno X_REG a15 (r29,l0) best X_REG, allocno X_REG r28: preferred X_REG, alternative NO_REGS, allocno X_REG a16 (r28,l0) best X_REG, allocno X_REG r27: preferred X_REG, alternative NO_REGS, allocno X_REG a17 (r27,l0) best X_REG, allocno X_REG r26: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a2 (r26,l0) best DATA_REGS, allocno DATA_REGS r25: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a4 (r25,l0) best DATA_REGS, allocno DATA_REGS r24: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a3 (r24,l0) best DATA_REGS, allocno DATA_REGS r23: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a5 (r23,l0) best DATA_REGS, allocno DATA_REGS r22: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a6 (r22,l0) best DATA_REGS, allocno DATA_REGS r21: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a8 (r21,l0) best DATA_REGS, allocno DATA_REGS r20: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a7 (r20,l0) best DATA_REGS, allocno DATA_REGS r19: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a9 (r19,l0) best DATA_REGS, allocno DATA_REGS a0(r36,l0) costs: X_REG:0 MEM:5000 a1(r34,l0) costs: X_REG:0 MEM:84000 a2(r26,l0) costs: DATA_REGS:0 MEM:5000 a3(r24,l0) costs: DATA_REGS:0 MEM:5000 a4(r25,l0) costs: DATA_REGS:0 MEM:5000 a5(r23,l0) costs: DATA_REGS:0 MEM:5000 a6(r22,l0) costs: DATA_REGS:0 MEM:5000 a7(r20,l0) costs: DATA_REGS:0 MEM:5000 a8(r21,l0) costs: DATA_REGS:0 MEM:5000 a9(r19,l0) costs: DATA_REGS:0 MEM:5000 a10(r35,l0) costs: X_REG:0 MEM:5000 a11(r33,l0) costs: DATA_REGS:0 MEM:8000 a12(r32,l0) costs: DATA_REGS:0 MEM:7000 a13(r30,l0) costs: MEM:8000 a14(r31,l0) costs: DATA_REGS:0 MEM:7000 a15(r29,l0) costs: X_REG:0 MEM:8000 a16(r28,l0) costs: X_REG:0 MEM:8000 a17(r27,l0) costs: X_REG:2000 MEM:8000 Insn 43(l0): point = 0 Insn 39(l0): point = 3 Insn 38(l0): point = 5 Insn 37(l0): point = 7 Insn 36(l0): point = 9 Insn 35(l0): point = 11 Insn 34(l0): point = 13 Insn 33(l0): point = 15 Insn 32(l0): point = 17 Insn 31(l0): point = 19 Insn 30(l0): point = 21 Insn 29(l0): point = 23 Insn 28(l0): point = 25 Insn 27(l0): point = 27 Insn 26(l0): point = 29 Insn 25(l0): point = 31 Insn 24(l0): point = 33 Insn 23(l0): point = 35 Insn 22(l0): point = 37 Insn 21(l0): point = 39 Insn 20(l0): point = 41 Insn 19(l0): point = 43 Insn 18(l0): point = 45 Insn 17(l0): point = 47 Insn 16(l0): point = 49 Insn 15(l0): point = 51 Insn 14(l0): point = 53 Insn 9(l0): point = 55 Insn 8(l0): point = 57 Insn 7(l0): point = 59 Insn 6(l0): point = 61 Insn 5(l0): point = 63 Insn 4(l0): point = 65 Insn 3(l0): point = 67 Insn 2(l0): point = 69 Insn 10(l0): point = 71 a0(r36): [4..5] a1(r34): [4..55] a2(r26): [18..21] a3(r24): [20..25] a4(r25): [22..23] a5(r23): [26..27] a6(r22):
Re: Indirect memory addresses vs. lra
On Fri, Aug 09, 2019 at 09:16:44AM -0500, Segher Boessenkool wrote: Is your code in some branch in our git? No. But it could be pushed there if people think it would be appropriate to do so, and if I'm given the permissions to do so. Or in some other public git? It's in my repo on gcc135 ~jmd/gcc-s12z (branch s12z) Do you have a representative testcase? I think gcc/testsuite/gcc.c-torture/compile/pr53410-2.c is as representative as any. J' -- Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. signature.asc Description: PGP signature
Re: Indirect memory addresses vs. lra
On Sat, Aug 10, 2019 at 11:12:18AM -0500, Segher Boessenkool wrote:
Hi!
On Sat, Aug 10, 2019 at 08:05:53AM +0200, John Darrington wrote:
> Choosing alt 5 in insn 14: (0) m (1) m {*movsi}
>14: [r40:PSI+0x20]=[r41:PSI]
> Inserting insn reload before:
>48: r40:PSI=r34:PSI
>49: r41:PSI=[y:PSI+0x2f]
insn 14 is a mem-to-mem move (another feature not many more modern /
more RISCy CPUs have). That requires both of your address registers.
So far, so good. The reloads (insn 48 and 49) require address
registers themselves; that isn't necessarily a problem either.
So far as I can see, insn 48 is completely redundant. It's copying a
pseudo reg (74) into another pseudo reg (40).
This is pointless and a waste, since insn 14 does not modify 74.
I don't understand why lra feels the need to do it.
If lra knew about (mem (mem ...)) style addressing, then insn 49 would
also be redundant (which is why I raised the topic).
In summary, what we have is:
(insn 48 84 49 2 (set (reg/f:PSI 40 [34])
(reg/f:PSI 74 [34]))
(nil))
(insn 49 48 14 2 (set (reg:PSI 41)
(mem/f/c:PSI (plus:PSI (reg/f:PSI 9 y)
(const_int 47 [0x2f])) [3 p+0 S4 A8]))
(nil))
(insn 14 49 15 2 (set (mem:SI (plus:PSI (reg/f:PSI 40 [34])
(const_int 32 [0x20])) [2 S4 A64])
(mem:SI (reg:PSI 41) [2 *p_5(D)+0 S4 A8]))
where, like you say, insns 48 and 49 are reloads. But these two reloads
are unnecessary and cause the machine to run out of PSImode registers.
The above could be easier and more efficiently done simply as:
(insn 14 11 15 2 (set
(mem:SI (plus:PSI (reg/f:PSI 74 [34]) (const_int 32 [0x20])) [2 S4
A64])
(mem/f/c:PSI (mem:PSI (plus:PSI (reg/f:PSI 9 y)
(const_int 47 [0x2f])) [3 p+0 S4 A8])))
This is exactly what we had before lra messed with things. It can be
represented in the ISA with one assembler instruction:
mov.p (32, x), [47, y]
and if I'm not mistaken, alternative 5 of my "movpsi" pattern should do
this just fine.
But
this requires careful juggling. Maybe you will need some backend code
Could you give a hint into which set of hooks/constraints/predicates
this backend code should go?
--
Avoid eavesdropping. Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.
Re: Indirect memory addresses vs. lra
On Thu, Aug 15, 2019 at 12:29:13PM -0400, Vladimir Makarov wrote:
Thank you for providing the sources.?? It helped me to understand what is
going on.?? So the test crashes on
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c: In
function ???f1???:
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
error: unable to find a register to spill
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
error: this is the insn:
(insn 14 49 15 2 (set (mem:SI (plus:PSI (reg/f:PSI 40 [34])
(const_int 32 [0x20])) [2 S4 A64])
(mem:SI (reg:PSI 41) [2 *p_5(D)+0 S4 A8]))
"/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c":9:9 95
{*movsi}
(expr_list:REG_DEAD (reg:PSI 41)
(expr_list:REG_DEAD (reg/f:PSI 40 [34])
(nil
Thanks for taking a look.
Your target has only 2 non-fixed addr registers (r8, r9). One (r9) is
defined as a hard reg pointer pointer.
That is correct.
Honestly, I never saw a target with such register constraints.
My recollection is that MC68HC11 was the same.
So what can be done, imho. The simplest solution would be preventing
insns with more one memory operand.
I tried this solution earlier. But unfortunately it makes things worse. What
happens is it libgcc cannot
even be built -- ICEs occur on a memory from address reg insn such as:
(insn 117 2981 3697 5 (set (mem/f:PSI (plus:PSI (reg:PSI 1309)
(const_int 102 [0x66])) [3 fs_129(D)->pc+0 S4 A8])
(reg:PSI 1310))
"/home/jmd/Source/GCC2/libgcc/unwind-dw2.c":977:9 96 {movpsi}
J'
--
Avoid eavesdropping. Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.
Re: Indirect memory addresses vs. lra
On Thu, Aug 15, 2019 at 06:38:30PM +0200, Richard Biener wrote: Couldn't we spill the frame pointer? Basically we should be able to compute the first address into a reg, spill that, do the second (both could require the frame pointer), spill the frame pointer, reload the first computed address from the stack, execute the insn and then reload the frame pointer. Maybe the frame pointer can also be implemented 'virually' in an index register that you keep updated so that sp + reg Is the FP. Or frame accesses can use a Stack slot as FP and the indirect memory Addressing... (is there an indirect lea?) Yes. lea x, [4,x] is a valid instruction. J' -- Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.
Special Memory Constraint [was Re: Indirect memory addresses vs. lra]
On Thu, Aug 15, 2019 at 02:23:45PM -0400, Vladimir Makarov wrote:
> I tried this solution earlier. But unfortunately it makes things worse.
What happens is it libgcc cannot
> even be built -- ICEs occur on a memory from address reg insn such as:
> (insn 117 2981 3697 5 (set (mem/f:PSI (plus:PSI (reg:PSI 1309)
> (const_int 102 [0x66])) [3 fs_129(D)->pc+0 S4 A8])
> (reg:PSI 1310))
"/home/jmd/Source/GCC2/libgcc/unwind-dw2.c":977:9 96 {movpsi}
>
I see.?? Then for the insn, you could try to create a pattern
"memory,special memory constraint".?? The special memory constraint
should satisfy only spilled pseudo (pseudo with reg_renumber == -1).?? I
believe lra-constraints.c can spill the pseudo and the end you will have
mem[disp1 + r8|r9|sp] = mem[disp1+sp].
You mean something like this:
(define_special_memory_constraint "a"
"My special memory constraint"
(match_operand 0 "my_special_predicate")
)
(define_predicate "my_special_predicate"
(match_operand 0 "memory_operand")
{
debug_rtx (op);
if (MEM_P (op))
{
op = XEXP (op, 0);
if (GET_CODE (op) == PLUS)
{
op = XEXP (op, 0);
if (REG_P (op))
{
fprintf (stderr, "Reg number is %d\n", REGNO (op));
if (REGNO (op) >= 0)
return false;
}
}
}
return true;
})
When I use this I get lots of the following ICEs
"internal compiler error: maximum number of generated reload insns per
insn achieved (90)"
It seems logical to me that this would happen since the constraint is not going
to match any
operand with resolved registers. Thus it will continually reload.
... which makes me think I've probably misunderstood what you are saying.
J'
--
Avoid eavesdropping. Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.
Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]
On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote:
No I meant something like that
(define_special_memory_constraint "a" ...)
(define_predicate "my_special_predicate" ...
{
if (lra_in_progress_p)
return REG_P (op) && REGNO (op) >= FIRST_PSEUDO_REGISTER &&
reg_renumber[REGNO(op)] < 0;
return true if memory with sp addressing;
})
I think LRA spills pseudo-register and it will be memory addressed by sp
at the end of LRA.
What I've done is this:
(define_predicate "my_special_predicate"
(match_operand 0 "memory_operand")
{
debug_rtx (op);
gcc_assert (MEM_P (op));
op = XEXP (op, 0);
if (GET_CODE (op) == PLUS)
op = XEXP (op, 0);
if (lra_in_progress)
{
fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
return REG_P (op) && REGNO (op) >= FIRST_PSEUDO_REGISTER &&
reg_renumber[REGNO(op)] < 0;
}
if (REG_P (op))
{
int regno = REGNO (op);
return (regno == 10); // register is the stack pointer
}
return true;
})
(and many variations) Unfortunately, any moderately complicated input
still results in a (mem (reg) ) insn repeatedly entering the
lra_in_progress case and returning false, and eventually terminating with
"internal compiler error: maximum number of generated reload insns per insn
achieved (90)"
Any other ideas?
J'
Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]
On Mon, Aug 19, 2019 at 10:07:11AM -0500, Segher Boessenkool wrote: > ? As I remember there were a few other ideas from Richard Biener and > Segher Boessenkool.? I also proposed to add a new address register which > will be always a fixed stack memory slot at the end. Unfortunately I am > not familiar with the target and the port to say in details how to do > it.? But I think it is worth to try. The m68hc11 port used the fake Z register approach, and I believe it had some special machine pass to get rid of it right before assembler output. (r171302 is when it was removed -- last version was https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/m68hc11/m68hc11.c;h=1e414102c3f1fed985e4fb8db7954342e965190b;hb=bae8bb65d842d7ffefe990c1f0ac004491f3c105#l4061 for the machine reorg stuff). No idea how well it works... But it's only needed if you are forced to have a frame pointer IIUC? Segher Most of these suggestions involve adding some sort of virtual registers So I hacked the machine description to add two new registers Z1 and Z2 with the same mode as X and Y. Obviously the assembler balks at this. However the compiler still ICEs at the same place as before. So this suggests that our original diagnosis, viz: there are not enough address registers was not accurate, and in fact there is some other problem? J' -- Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.
Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]
On Tue, Aug 20, 2019 at 08:56:39AM +0200, Richard Biener wrote: > Most of these suggestions involve adding some sort of virtual registers > So I hacked the machine description to add two new registers Z1 and Z2 > with the same mode as X and Y. > > Obviously the assembler balks at this. However the compiler still > ICEs at the same place as before. > > So this suggests that our original diagnosis, viz: there are not enough > address registers was not accurate, and in fact there is some other > problem? That sounds likely. Given you have indirect addressing you could simulate N virtual regs by placing them in a virtual reg table in memory and accessed via a fixed address register (assuming all instructions that would need an address reg also can take that indirect from memory). That was my plan. Accordingly, extending the md to provide N additional regs (N currently = 2) was the first step. Having doubled the number of available address registers, I had expected this would fix most of the ICEs (but cause a lot of assembler errors). However it hasn't eliminated any ICEs. lra is still complaining "unable to find a register to spill" So the plan seems to have fallen over at the first hurdle. Why can it still not spill registers despite having a lot more of them? J'
How to insert a new function in plugin?
Hi,
I want to insert a new function `test_fn` in plugin and call it in `main`,
but got `undefined reference to `test_fn’ in `ld`. Can someone please give
any help? Thanks.
Here is the example code,
//== plugin.c
#include "gcc-plugin.h"
#include "plugin-version.h"
#include "tree.h"
#include "tree-iterator.h"
#include "toplev.h"
#include "c-family/c-common.h"
#include "cgraph.h"
#include "langhooks.h"
int plugin_is_GPL_compatible = 1;
// this example is from gcc/function-tests.c. The built function is
//
// int test_fn (void) { return 42; }
//
static tree build_fn() {
// build function fndecl
auto_vec param_types;
tree fn_type = build_function_type_array(
integer_type_node, param_types.length(), param_types.address());
tree fndecl = build_fn_decl("test_fn", fn_type);
TREE_PUBLIC(fndecl) = 1;
tree retval =
build_decl(UNKNOWN_LOCATION, RESULT_DECL, NULL_TREE,
integer_type_node);
DECL_ARTIFICIAL(retval) = 1;
DECL_IGNORED_P(retval) = 1;
DECL_RESULT(fndecl) = retval;
DECL_CONTEXT(retval) = fndecl;
tree stmt_list = alloc_stmt_list();
tree_stmt_iterator stmt_iter = tsi_start(stmt_list);
tree block = make_node(BLOCK);
tree bind_expr = build3(BIND_EXPR, void_type_node, NULL, stmt_list, block);
tree modify_retval = build2(MODIFY_EXPR, integer_type_node, retval,
build_int_cst(integer_type_node, 42));
tree return_stmt = build1(RETURN_EXPR, integer_type_node, modify_retval);
tsi_link_after(&stmt_iter, return_stmt, TSI_CONTINUE_LINKING);
DECL_INITIAL(fndecl) = block;
BLOCK_SUPERCONTEXT(block) = fndecl;
DECL_SAVED_TREE(fndecl) = bind_expr;
BLOCK_VARS(block) = BIND_EXPR_VARS(bind_expr);
// But how to deal with this function?
allocate_struct_function(fndecl, false);
announce_function(fndecl);
c_determine_visibility(fndecl);
c_genericize(fndecl);
cgraph_node::finalize_function(fndecl, true);
return fndecl;
}
void on_start_parse_function(void *gcc_data, void *user_data) {
build_fn();
}
int plugin_init(struct plugin_name_args *plugin_info,
struct plugin_gcc_version *version) {
if (!plugin_default_version_check(version, &gcc_version)) {
return 1;
}
register_callback(NULL, PLUGIN_START_PARSE_FUNCTION,
on_start_parse_function,
NULL);
return 0;
}
// === main.c
int main() {
test_fn(); // error: `undefined reference to `test_fn’` in ld
}
New Payment Request
Hi You can get a new payment in your personal account. You have to manage it right away or it will be removed. Go HERE To Confirm Your Payment Info Is Correct. Registered email: g...@gnu.org User ID: UEMG6C1SHB Enjoy & please let me know if all is well. Thanks! Jeff E Marketer 202 Lower High Street Watford WD17 2EH United Kingdom You received this email because you are registered with L Marketer. Unsubscribe here model basket
Re: timeouts/malloc failures in ada tests?
On 7/7/2017 17:38, Eric Botcazou wrote: I see large numbers of timeouts in Ada tests on trunk in parallel run s (make -j96) on x86_64. Messages like the one below appear in the logs, suggesting some sort of heap corruption. I'm having trouble reproducing it outside the rest of the test suite (i.e., by just running the Ada tests by themselves) but maybe I'm doing it wrong. Unless this is a known problem I can try to pinpoint it closer if someone could share the magic spell to run just Ada tests to speed up the debugging. Is it (a known problem)? No, but regressions were recently introduced in the ACATS testsuite: === acats tests === FAIL: cb4008a FAIL: cb41001 so this could be related. Ada is not enabled by default so this is not surprising. It's OK for small changes and bug fixes, but people making extensive changes to the compiler should really consider enabling it (and it's a very good testbed). Good timing on this post! I just finished my first test build in a while using a new unwind patch for dragonfly (it moved the signal trampoline, breaking the previous unwind) and I saw these exact two failures. Even though the new patch has been in use for months, I was still thinking it caused the test failures. Thanks for piping up, Eric! :) John P.S. I'll post the dragonfly-specific unwind patch to the patches mail list later today. It's been tested internally for weeks.
Make minmax detection more flexible in tree-ssa-phiopt.c
Hi,
I'm trying to improve the asm code generated for C code like:
long f(long a, long b) {
_int64 s;
s = (((long long) a) + ((long long) b));
s = (s > 0x7fffL ? (long) 0x7fffL :
(s <-0x8000L ? (long)-0x8000L :
s));
return((long) s);
}
A key step is minmax detection in tree-ssa-phiopt.c. However, in my test cases
sometimes minmax detection fails because of input like:
if (D.5591_11 <= 2147483647)
goto ;
else
goto ;
:
D.5594_19 = MAX_EXPR ;
iftmp.0_20 = (long int) D.5594_19;
:
# iftmp.0_1 = PHI
Minmax detection expects the middle block to have one statement, but in this
case there is an additional cast. Minmax would be detected if the cast
was moved after the middle block:
...
:
D.5594_19 = MAX_EXPR ;
:
# s_1 = PHI
iftmp.0_20 = (long int) s_1;
The limitation occurs around line 725 in tree-ssa-phiopt.c in GCC 4.5.2:
/* Recognize the following case, assuming d <= u:
if (a <= u)
b = MAX (a, d);
x = PHI
This is equivalent to
b = MAX (a, d);
x = MIN (b, u); */
gimple assign = last_and_only_stmt (middle_bb);
tree lhs, op0, op1, bound;
I was wondering if anyone could give me guidance on how to add flexibility
to minmax detection in order to handle this case.
Thanks,
John Lu
clz pattern
Hi, I'm trying to utilize the clz pattern: (define_insn "clzhi2" [(set (match_operand:HI 0 "register_operand" "=r") (clz:HI (match_operand:HI 1 "register_operand" "r")))] "" "cntlz %0 %1") I can build a compiler successfully with this pattern, but I can't find any C source that will utilize this pattern. I was wondering how GCC utilizes these patterns (and others like it), which have a functionality that does not straightforwardly map to any C operator. Thanks, John Lu
Re: [Dwarf-Discuss] RFC: DWARF Extensions for Separate Debug Info Files ("Fission")
Hi Jason, Jason Molenda wrote: > On Sep 23, 2011, at 10:58 AM, Cary Coutant wrote: > >>> The compiler puts DWARF in the .o file, the linker adds some records in the >>> executable which help us to understand where files/function/symbols landed >>> in the final executable[1]. >> Did you intend to add a footnote? > > Yeah, I realized after I sent the email - it didn't seem interesting enough > to warrant a separate followup. > > The records that our linker puts in the executable are in the form of stabs > entries. There are a handful of stabs records created - file start, file > end, function start, function end, symbol, pointer to a .o file, maybe one or > two others. We chose that format because it was trivial to support and we > already had tools for stripping these records out of the executable once the > dSYM had been created. I don't remember the exact details, but the problem I recall with the Darwin scheme is that it builds an incomplete index in the Mach-O symbol table. IIRC, it was missing things that a user might want to lookup by-name in the debugger, like static functions or variables, and type names with external linkage. Without a reasonably complete index, the debugger can't know where to find the definitions of certain things, and that forces the user to navigate using other information, like source file name or global function definitions to force the debug information in the object to be read. Of course, the current DWARF indexes (like pubnames/pubtypes) have the same problem, and some compilers do a really bad job at generating those sections. But at least when there's a single .debug_info section, the debugger can decide to ignore the indexes and "skim" the full debug information. The compilers on IRIX did a better job at generating indexes, so the debugger could find by-name static functions/objects. > Once a dSYM has been created with all of the DWARF collected in a single > file, our DWARF is parseable by any debug info consumer with minimal changes > -- they need to know to look in a separate file for the DWARF from the main > executable, but the format itself is unchanged. Supporting the > debug-information-in-.o-files is more involved, I don't know if any of the > third-party debuggers on our platform work with it. TotalView supports debug information in .o files on Darwin, and has since day one. Perhaps you recall all those email exchanges you and I had several years back. It was a modest amount of work, given that we already supported debug information in .o files on the Sun and HP platforms. I seem to recall one of the sore spots for us on Dawrin was getting good address information for certain DWARF location operations, like DW_OP_addr. Fortran was a particularly messy because some compilers didn't supply a linkage name attribute, so the debugger had to make several guesses at the name, and look things up by trial and error. Cheers, John D. >> We're trying to achieve something very similar, but we have the >> additional goal of separating the info from the .o files because of >> our distributed build environment. I also wanted to attempt to >> standardize the approach, instead of having each vendor go in separate >> directions. > > > Yeah, if your regular build environment involves distributed compilation, and > the .o files need to be copied to a central system for the linker, then I can > see why you're pursuing this approach. For us, the most common usage is > single-computer compilation & linking -- where the linker never pages in the > debug info sections from the .o files so their size is not particular > important. > > J > ___ > Dwarf-Discuss mailing list > dwarf-disc...@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org >
Re: Volatile qualification on pointer and data
What can't make sense is a /static/ "volatile const" which is /defined/ locally, rather than just declared. The code in question sounds well-defined (but probably poor style) to me. It is never OK to access a qualified object through an unqualified pointer, but my understanding is that accessing an unqualified object through a qualified pointer is well-defined and that the usual qualifier rules apply to that access. David, is your "can't make sense" backed up by a standard? There is no "lying to the compiler", there is only conforming and non-conforming code. John
Re: Volatile qualification on pointer and data
it. And while I think the compiler should be allowed to generate the optimised code of 4.6 (i.e., the change is not a bug IMHO), I fully understand the idea of generating the older, slower, but definitely correct code of 4.5. My understanding is that the standard mandates the old behavior, so 4.6 is in error. I am still trying to imagine a real-world use-case for declaring an object "static const" and later accessing it as "volatile". Yeah, it would seem far clearer to declare it as static const volatile in the first place. I've done a bunch of automated testing of GCC's implementation of volatile. None of that testing would have exposed this bug because we only count acceses to objects declared as volatile. I've come to the conclusion that "volatile" is a language design error. It complicates the compiler implementation and has confusing, underspecified semantics. If you want to force a load or store, an explicit function call is a clearer way to do it. John
Trouble installing gfortran
Recently I have been describing my troubles installing gfortran in the comp.lang.fortran newsgroup, and FX has given useful help. But today my system won't let me read anything in that newsgroup so I'm emailing to you. One thing that wasn't suggested but I find allowed me to configure GCC, make and make install was rm -f /tmp/gccobj/prev-* before starting. (I used a bash shell script saying inter alia srcdir=/tmp/gcc-4.6.2 objdir=/tmp/gccobj prefix=/tmp/gf gccopts=" --prefix=$prefix --enable-languages=c,c++,fortran" gccopts=$gccopts" --disable-libada" # unlikely to need ADA! gccopts=$gccopts" --with-gmp=$HOME --with-mpfr-include=$HOME/mpfr-3.0.0" gccopts=$gccopts" --with-mpfr-lib=$HOME/mpfr-3.0.0/.libs" gccopts=$gccopts" --with-mpc=$HOME/mpc-0.9" $srcdir/configure $gccopts # http://gcc.gnu.org/install/configure.html because my HOME disk space is too small for GCC and all the things it needs.) My little test program then compiled but wouldn't run even though the library said to be missing does exist. It was peresumably put somewhere that gfortran couldn't find it. What should I do now? Evidence: rimu[/tmp]$ ls -l */*/libquadmath.so* lrwxrwxrwx 1 harperj1 harperj1 20 Jan 10 12:35 gf/lib/libquadmath.so -> libquadmath.so.0.0.0 lrwxrwxrwx 1 harperj1 harperj1 20 Jan 10 12:35 gf/lib/libquadmath.so.0 -> libquadmath.so.0.0.0 -rwxr-xr-x 1 harperj1 harperj1 966329 Jan 10 12:35 gf/lib/libquadmath.so.0.0.0 rimu[/tmp]$ cd rimu[~]$ /tmp/gf/bin/gfortran -v hello.f Driving: /tmp/gf/bin/gfortran -v hello.f -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=/tmp/gf/bin/gfortran COLLECT_LTO_WRAPPER=/tmp/gf/libexec/gcc/i686-pc-linux-gnu/4.6.2/lto-wrapper Target: i686-pc-linux-gnu Configured with: /tmp/gcc-4.6.2/configure --prefix=/tmp/gf --enable-languages=c,c++,fortran --disable-libada --with-gmp=/home/harperj1 --with-mpfr-include=/home/harperj1/mpfr-3.0.0 --with-mpfr-lib=/home/harperj1/mpfr-3.0.0/.libs --with-mpc=/home/harperj1/mpc-0.9 Thread model: posix gcc version 4.6.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /tmp/gf/libexec/gcc/i686-pc-linux-gnu/4.6.2/f951 hello.f -ffixed-form -quiet -dumpbase hello.f -mtune=generic -march=pentiumpro -auxbase hello -version -fintrinsic-modules-path /tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/finclude -o /tmp/ccDukrje.s GNU Fortran (GCC) version 4.6.2 (i686-pc-linux-gnu) compiled by GNU C version 4.6.2, GMP version 4.3.2, MPFR version 3.0.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.6.2 (i686-pc-linux-gnu) compiled by GNU C version 4.6.2, GMP version 4.3.2, MPFR version 3.0.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' as --32 -o /tmp/ccGzx8Uk.o /tmp/ccDukrje.s Reading specs from /tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/../../../libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' COMPILER_PATH=/tmp/gf/libexec/gcc/i686-pc-linux-gnu/4.6.2/:/tmp/gf/libexec/gcc/i686-pc-linux-gnu/4.6.2/:/tmp/gf/libexec/gcc/i686-pc-linux-gnu/:/tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/:/tmp/gf/lib/gcc/i686-pc-linux-gnu/ LIBRARY_PATH=/tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/:/tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /tmp/gf/libexec/gcc/i686-pc-linux-gnu/4.6.2/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/crtbegin.o -L/tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2 -L/tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/../../.. /tmp/ccGzx8Uk.o -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/crtend.o /usr/lib/crtn.o rimu[~]$ ./a.out ./a.out: error while loading shared libraries: libquadmath.so.0: cannot open shared object file: No such file or directory rimu[~]$ -- John Harper, School of Mathematics Statistics and Operations Research Victoria University, PO Box 600, Wellington 6140, New Zealand e-mail john.har...@vuw.ac.nz phone (+64)(4)463 5276 fax (+64)(4)463 5045
Re: [lambda] Segmentation fault in simple lambda program
Jason Merrill wrote: Experimenting with a working version and seeing it's issues will be useful to me. To others to maybe. With concepts gone from C++0x and being reworked for C++15(?) maybe support for polymorphic lambdas could be reintroduced? -- though I'm sure its much too late for that and that its likely been around the buoy many times. From what I have read I got the idea that the Callable concept was the primary reason for polymorphic lambdas not being accepted. I don't know what the reasoning was there, but people have been somewhat conservative about what usages of lambdas are allowed for fear of unforseen implementation issues. Certainly having a working implementation would go a lot toward convincing people to allow it, even if it doesn't make it into C++0x. There were several issues with polymorphic lambdas in the presence of concepts that concerned many on the committee. I've come to accept that it's too late to re-introduce polymorphic lambdas into C++0x (now C++1x), but there's no stopping GCC from implementing it as an extension. Implied template typename arguments via auto are not currently supported. The syntax parses but I haven't yet synthesized the template arguments and therefore not replaced the auto's with them so it doesn't compile. Since templates work so differently from normal functions, I'm a little uncomfortable with the idea of templates that don't involve any template syntax, just the use of auto in the parameter list. But I'm open to giving it a try, at least in the lambda context. Maybe outside of lambda it could be used with a small template introducer... Just my opinion, but I don't think there should be any special template syntax. The whole point of argument deduction was terseness. It doesn't have to be implemented using templates, so I don't equate it with templates. - John
Re: [lambda] Segmentation fault in simple lambda program
I haven't been following GCC, so I need to thank Jason for forwarding
this issue to me.
I just read through the messages on the list, and had some more comments:
+/* relayout again -- to allow for implicit
+ * parameters to have been added to the capture if it was a
+ * 'default capture' -- note that this would not be necessary if
+ * the stack-pointer variant was implemented -- since the layout
+ * would be known.
+ * Relayingout here might have nasty effect if one were to query
+ * sizeof *this from within the body -- would that even be
+ * possible -- *this would refer to the lambda or the enclosing
+ * class instance -- if there was one.???
+ *
+ * NOTE: I think this is a redefinition error; I'm just faking that
+ * it isn't by clearing the size node... need to use stack pointer
+ * method. But that will likely bring its own issues -- not with
+ * class layout though.
+ */
+TYPE_SIZE (type) = NULL_TREE;
+finish_struct_1 (type);
Relaying out the class after the lambda body was parsed is something I
had attempted to do, but possibly failed at. It will absolutely need to
be done.
The way 'default reference capture' is implemented on the lambda branch seems
to be kind of reactive. I would expect
that inheriting the stack somehow (maybe using just a stack pointer) would be
better but without more investigation I
don't know if that is possible or how one would go about doing it.
This won't be suitable in the general case, because of the copy default
capture [=]. Implicit captures will have to be reactive.
/*
* Rather than looping through the identifiers used in the scope of
* the lambda and synthesizing individual captures of them, it would
* be better to ref the stack frame as transparently as possible...
* e.g. given just three ints i, j and k in scope:
* Instead of transforming:
*
*[&] { i = 1; j = 2; k = 3; };
*
* into
*
*[&i,&j,&k] { i = 1; j = 2; k = 3; };
*
* and thus storing three pointers to int, transform it into:
*
*[sp=enclosing-stack-pointer] { var-from-stack(i,sp) = 1;
* var-from-stack(j,sp) = 2;
* var-from-stack(k,sp) = 3; };
*
* and only store one pointer.
This is preferred for reference default captures, but I was not familiar
with stack pointer mechanics in GCC. I just wanted to get something
working first that could be improved later.
* I don't know if its possible but it may be possible to 'append'
* the lambda's stack to the existing scope rather than creating a
* new constrained scope -- from a logical point of view.
Again, this is not suitable to the general case because a lambda can
outlast its enclosing scope.
My motivation for investigating is that I consider constraining lambdas to be
monomorphic significantly reduces their
usefulness. I'm sure there are many good reasons why the committee decided
that it was the way to go.
I don't think it handicaps lambdas as much as some may believe, but
still wanted polymorphic lambdas as well. There were just too many
issues with deduction. When I last left the discussion, the biggest
issue in my opinion was concept map dropping. The workaround made the
deduction algorithm intimidatingly complex.
The following program generates the expected code and runs correctly.
auto f = [&] (T n, T const& m, U u) { i = ++n; j =
u(++n); k = ++n; };
This is exciting. The main thing I failed to add was dependent type
support, so I want to check this out. (I need to register a new ssh key)
- John
Re: [lambda] Segmentation fault in simple lambda program
Adam Butcher wrote: Hopefully. From my point of view the class generated by a lambda expression should be equivalent to something you could write yourself -- aside from the single stack-pointer reference optimization which only a compiler could achieve -- the class has a name, albeit invisible to the user (except in errors/warnings), and instances of should be useable just as if there were user-defined functors. I'm sure there are things I've overlooked but hopefully this proof-of-concept will help to allay people's fears. In my opinion, lambdas are not intended as just a shortcut to writing a function object class. This is why our proposal did not require that lambdas be implemented as classes; it is simply one implementation. (Awaiting word to see if this is still the case in the working draft of the standard; it may not be, but that doesn't change my opinion :) Thus, users should never see the class name. In warnings and errors, a lambda should be treated like an anonymous class, swapping its compiler-generated name with a placeholder like (similar to ). Additionally, users should never be able to instantiate a function call operator member, as below: Makes sense. I suppose to specify explicit template arguments users would have to write lambdaob.operator()(fn-arg) That would be the case for explicit instantiation yes. With my implementation you could only get such as nullary function template if you explicitly specified the template parameters and explicitly specified an empty call argument list. I've made the template parameter list optional within the already optional lambda-parameter-declaration. If present, it has to be followed by a function parameter list. The intent of course is that any template parameters will be referenced in the function parameter list. Though it does not prevent having unreferenced template parameters that would need to be explicitly bound. If a higher-order function were to accept a "function-like object" and instantiate its function call operator member, then it is using it as a class, and should not pretend to accept function pointers or lambdas. The argument types of a lambda function can be deduced from the context of the lambda expression, meaning a template constant lambda function should never be necessary. Since templates work so differently from normal functions, I'm a little uncomfortable with the idea of templates that don't involve any template syntax, just the use of auto in the parameter list. But I'm open to giving it a try, at least in the lambda context. Maybe outside of lambda it could be used with a small template introducer... In response to Jason's concern here, a template implementation is not required, just convenient. Hopefully you won't think of it as "templates without template syntax", but "deduction using the existing template mechanism". [snip] The benefit of using it in lambdas is that the call operator is never 'seen', so whether its a template or not shouldn't affect the caller providing the input arguments are compatible. Exactly. so we'd really expect them to be only deduced. Yes. Exactly. When I last left the discussion, the biggest issue in my opinion was concept map dropping. The workaround made the deduction algorithm intimidatingly complex. I am not up to speed with the issues but they obviously exist. One thing I don't understand, and perhaps you could help, is that whatever issues polymorphic lambdas have -- surely manually written function objects with template call operators have the same issues. Is this true? We did not want (and I doubt a concept proposal would approve) polymorphic lambdas to interrupt the modular type checking of constrained templates, i.e. templates using concepts, so the constraints would have to be deduced and added to the function call operator (in a class implementation for lambdas). Hand-written function object classes bypass this issue by not allowing the deduction of constraints - they must be hand-written if the function object class is to be used in a constrained context. And if so does it mean that future standard library algorithms will be more constraining than exisiting ones -- or am I barking up the wrong tree? When concepts come, standard library algorithms /will/ be constrained, but not to disallow any correct uses. The constraints /will/ expose improper uses of the standard library. - John
Re: [lambda] Segmentation fault in simple lambda program
Jason Merrill wrote: On 08/04/2009 09:35 AM, John Freeman wrote: In my opinion, lambdas are not intended as just a shortcut to writing a function object class. This is why our proposal did not require that lambdas be implemented as classes; it is simply one implementation. (Awaiting word to see if this is still the case in the working draft of the standard; it may not be, but that doesn't change my opinion :) From N2859: "The type of the lambda-expression (which is also the type of the closure object) is a unique, unnamed non-union class type—called the closure type" Yes, this is the wording I'm worried about (it changed in N2914, but is similar). I don't think it was in our original proposal. I'm awaiting a response from Daveed Vandevoorde to see if it prescribes an implementation. IMO, it's better to define new functionality in terms of already familiar features rather than have to specify everything about how a new feature interacts with the rest of the language. Right. We defined the new functionality in terms of existing functionality for just this reason, but we did not prescribe an implementation (similar to other features in the standard). Granted, a class is the obvious and intended implementation, but we don't want to prevent optimizations where possible, as long as they preserve behavior. I'm not sure if this allowance is implicit in the wording; I'm not a standardese expert. Hopefully, this answers the below as well. In response to Jason's concern here, a template implementation is not required, just convenient. Hopefully you won't think of it as "templates without template syntax", but "deduction using the existing template mechanism". As above, suggesting that it doesn't have to be a template suggests that there's a lot more specification left to do, such as how do you deal with expressions whose type you don't know yet? If you allow non-lambda uses, how do they fit into overload resolution? If you just say it's a template, we already know how they work. Reiterating, to allow more freedom in implementation, we can just say it "behaves as" a template, rather than "is" a template. - John
Re: [lambda] Segmentation fault in simple lambda program
Jason Merrill wrote: On 08/04/2009 10:17 AM, John Freeman wrote: Reiterating, to allow more freedom in implementation, we can just say it "behaves as" a template, rather than "is" a template. I don't see the difference. As long as they work the same, the compiler is free to do whatever it wants internally. Ok, sounds great then. Like I said, I wasn't sure if that allowance was implicit in the wording. - John
Re: [lambda] Segmentation fault in simple lambda program
Jason Merrill wrote: Incidentally, how does it work to just move the existing call of finish_struct to after we parse the body? I don't see why we need it to be complete while we're in the body. When I was working on it, there were some checks to make sure the class was complete. I can't recall exactly where or why, but it was what led to me have two calls to finish_struct. - John
Re: [lambda] Segmentation fault in simple lambda program
John Freeman wrote: +/* relayout again -- to allow for implicit + * parameters to have been added to the capture if it was a + * 'default capture' -- note that this would not be necessary if + * the stack-pointer variant was implemented -- since the layout + * would be known. + * Relayingout here might have nasty effect if one were to query + * sizeof *this from within the body -- would that even be + * possible -- *this would refer to the lambda or the enclosing + * class instance -- if there was one.??? + * + * NOTE: I think this is a redefinition error; I'm just faking that + * it isn't by clearing the size node... need to use stack pointer + * method. But that will likely bring its own issues -- not with + * class layout though. + */ +TYPE_SIZE (type) = NULL_TREE; +finish_struct_1 (type); Relaying out the class after the lambda body was parsed is something I had attempted to do, but possibly failed at. It will absolutely need to be done. I just inspected my code again. The call to layout_class_type at the beginning of finish_lambda_function_body at semantics.c:5241 was intended to recalculate offsets to members in the case of default captures. Here is the complete order of the pertinent function calls (file location has nothing to do with call order; I supply them to help the reader to follow): finish_struct @ parser.c:6985 cp_parser_lambda_body @ parser.c:6992 --> finish_lambda_function_body @ parser.c:7380 > layout_class_type @ semantics.c:5241 finish_struct_1 @ I don't see this added yet. I've checked out revision 150396. - John
Re: [lambda] Segmentation fault in simple lambda program
On Thu, Aug 6, 2009 at 6:27 AM, Adam Butcher <mailto:a...@jessamine.co.uk>> wrote: I take you're point on [finish_struct_1] potentially being overkill but at least it means that user programs that copy can work. Right. I only added that comment so that other developers who come along and want to optimize it won't fall into the same trap I did. I've attached my two diffs made against the latest lambda head. First is explicit polymorphic lambda support via the additional template parameter syntax, second is the very hacky 'for-discovery-purposes-only' prototype for typename inference. I was hesitant to add the first patch alone, but now that you've got the second, I'm eager to take another look. Currently for auto typename inference, cv-qualifiers (and other bits like attributes) are lost One thing I'm worried about is that I'm using make_tree_vec() with a length one greater than that of the previous vector in order to grow the template parameter list whilst parsing function arguments. I'll be sure to look at these issues. There's a number of things I'm not sure about regarding location of the implementation (parser.c, semantics.c, decl.c etc). The general guideline I followed was to put as much non-parsing logic into semantics.c as possible, and call into it from parser.c when needed. I'm not sure what needs to go into decl.c either. I will try to take this opportunity of renewed interest in the lambdas branch to look at dependent type support and name mangling. When I say dependent type support, I mean using lambdas that capture or declare variables of dependent type from a surrounding template context. Many people won't be able to effectively use lambdas until these features are added. - John
Minor problem messaging C++ wrappers in Objective-C with gcc4.2
Hi,
I've found it very useful to be able to use C++ to extend Objective-C
using a little judicious operator overloading and I notice that gcc-4.2
now automatically "unboxes" wrapper classes with no warning when
they are messaged - provided an appropriate cast is available.
For example:
class AStringClass {
NSMutaableString *str;
public:
AStringClass( NSMutableString *str ) {
this->str = str;
}
operator NSMutableString * () {
return str;
}
};
This class can now be messaged in gcc4.2 as below without a warning:
AStringClass aString( nil );
[aString doubleValue];
Unfortunately is can also be sent a message which the compiler
is in a position to know is not available given the only cast
available was to a NSMutableString:
[aString count]; // not a valid method for NSMutableString *
This happens as internally as there is an implicit cast to type "id" in
${GCCROOT}gcc/objc/objc-act,c, function: objc_finish_message_expr
/* APPLE LOCAL begin decay function/array receivers */
#ifndef OBJCPLUS
/* In C need to decay array/function receivers so can be converted
to id. */
struct c_expr exp;
exp.value = receiver;
exp = default_function_array_conversion (exp);
receiver = exp.value;
/* APPLE LOCAL begin radar 3533972 */
#else
if (can_convert_arg (objc_object_type, TREE_TYPE (receiver),
receiver, LOOKUP_NORMAL))
{
/* In rare cases, 'receiver' must be converted to type 'id' using
user-defined type conversion. 'id' is type of the 1st
argument to
objc_msgSend (id self, SEL op, ...); */
tree cnv_rec = perform_implicit_conversion (objc_object_type,
receiver);
if (cnv_rec && cnv_rec != error_mark_node)
return objc_finish_message_expr (cnv_rec, sel_name,
method_params);
}
/* APPLE LOCAL end radar 3533972 */
#endif
Would it not be possible for the implicit conversion retain the type
which it was forced into using when searching for a match for "id"
and using this as the type of the receiver of the message rather
than "id". I've looked and the code but can't quite get to where
the change (probably quite a small one) would need to be made.
Perhaps even, this is already fixed...
Can anybody help?
John Holdsworth
objcpp.johnholdsworth.com
On 8 Apr 2009, at 14:34, David Ayers wrote:
Am Samstag, den 21.03.2009, 11:59 +0100 schrieb John Holdsworth:
I was wondering if it would be a useful extension to Objective-C
expand the [] operator
to support array and hash references to NSArray and NSDictionary
classes directly to
greatly improve the readability of code:
I'm not an ObjC front end maintainer and have no authority but one
issue
I would have with this feature with gcc proper is that the ObjC front
end would have to learn about the semantics of "NSArray" and
"NSDictionary" which are actually not part of the language but part of
an external library.
Now gcc already supports the -fconstant-string-class option as one way
to embed knowledge about an external library into an executable.
But I
would like adding options with all these semantics from a foreign
library into the language implementation.
Maybe this could be done more elegantly with plugin infrastructure
that
that es being currently added: http://gcc.gnu.org/wiki/plugins
Cheers,
David
Bus error gcc compiler for any for ( x in array ) inside Objective-C++ template
Hi,
I've encountered a bus error using Apple's gcc in Xcode 3.1, 3.2
compiling the following code or any containing for( x in y ) is used
inside a template in Objective-C++.
template
class OODictionary {
void boom() {
NSArray *keys = nil;
for ( NSString *key in keys ) {
}
}
};
I've not been able to build with a more recent gcc so I can't tell
if it is still present but figure I'd better let you guys know.
Thanks,
John H.
http://objcpp.johnholdsworth.com
On 8 Sep 2009, at 21:30, John Holdsworth wrote:
Hi,
I've found it very useful to be able to use C++ to extend Objective-C
using a little judicious operator overloading and I notice that
gcc-4.2
now automatically "unboxes" wrapper classes with no warning when
they are messaged - provided an appropriate cast is available.
For example:
class AStringClass {
NSMutaableString *str;
public:
AStringClass( NSMutableString *str ) {
this->str = str;
}
operator NSMutableString * () {
return str;
}
};
This class can now be messaged in gcc4.2 as below without a warning:
AStringClass aString( nil );
[aString doubleValue];
Unfortunately is can also be sent a message which the compiler
is in a position to know is not available given the only cast
available was to a NSMutableString:
[aString count]; // not a valid method for NSMutableString *
This happens as internally as there is an implicit cast to type "id"
in
${GCCROOT}gcc/objc/objc-act,c, function: objc_finish_message_expr
/* APPLE LOCAL begin decay function/array receivers */
#ifndef OBJCPLUS
/* In C need to decay array/function receivers so can be converted
to id. */
struct c_expr exp;
exp.value = receiver;
exp = default_function_array_conversion (exp);
receiver = exp.value;
/* APPLE LOCAL begin radar 3533972 */
#else
if (can_convert_arg (objc_object_type, TREE_TYPE (receiver),
receiver, LOOKUP_NORMAL))
{
/* In rare cases, 'receiver' must be converted to type 'id'
using
user-defined type conversion. 'id' is type of the 1st
argument to
objc_msgSend (id self, SEL op, ...); */
tree cnv_rec = perform_implicit_conversion (objc_object_type,
receiver);
if (cnv_rec && cnv_rec != error_mark_node)
return objc_finish_message_expr (cnv_rec, sel_name,
method_params);
}
/* APPLE LOCAL end radar 3533972 */
#endif
Would it not be possible for the implicit conversion retain the type
which it was forced into using when searching for a match for "id"
and using this as the type of the receiver of the message rather
than "id". I've looked and the code but can't quite get to where
the change (probably quite a small one) would need to be made.
Perhaps even, this is already fixed...
Can anybody help?
John Holdsworth
objcpp.johnholdsworth.com
On 8 Apr 2009, at 14:34, David Ayers wrote:
Am Samstag, den 21.03.2009, 11:59 +0100 schrieb John Holdsworth:
I was wondering if it would be a useful extension to Objective-C
expand the [] operator
to support array and hash references to NSArray and NSDictionary
classes directly to
greatly improve the readability of code:
I'm not an ObjC front end maintainer and have no authority but one
issue
I would have with this feature with gcc proper is that the ObjC front
end would have to learn about the semantics of "NSArray" and
"NSDictionary" which are actually not part of the language but part
of
an external library.
Now gcc already supports the -fconstant-string-class option as one
way
to embed knowledge about an external library into an executable.
But I
would like adding options with all these semantics from a foreign
library into the language implementation.
Maybe this could be done more elegantly with plugin infrastructure
that
that es being currently added: http://gcc.gnu.org/wiki/plugins
Cheers,
David
Re: Why does GCC Preprocessor NOT support such macro?
2009/10/23 Zhang Lin : > Hello, > I have encountered an issue when building ACE with MinGW and GCC 4.4.1 > The following macro was not accepted by the preprocessor and it reported such > an error: "error: operator '==' has no left operand". > > #if !defined (ACE_HAS_NONSTATIC_OBJECT_MANAGER) > # define ACE_HAS_NONSTATIC_OBJECT_MANAGER > #elif (ACE_HAS_NONSTATIC_OBJECT_MANAGER == 0) > # undef ACE_HAS_NONSTATIC_OBJECT_MANAGER > #endif /* ACE_HAS_NONSTATIC_OBJECT_MANAGER */ > > As I think, since ACE_HAS_NONSTATIC_OBJECT_MANAGER isn't defined, the #elif > branch should not be processed. > This macro is accepted by VC7.1 and Sun Studio 12. > > Thanks. > > Best Regards, > Lin Zhang > 2009-10-23 You'll get this error if ACE_HAS_NONSTATIC_OBJECT_MANAGER is defined, but has a null value - i.e. if somewhere before it was: #define ACE_HAS_NONSTATIC_OBJECT_MANAGER and not: #define ACE_HAS_NONSTATIC_OBJECT_MANAGER 1 (for example) I'm not sure if there's a way to test for a macro being null, but if you change your previous declarations to defining it so something instead of nothing, everything should be dandy. John G
copyright assignment
Hello. I would like to get the necessary forms for copyright assignment to GCC for future work on GNAT. I was told this is the way to kick off the process. Thanks for the help. - John Nowak
detailed comparison of generated code size for GCC and other compilers
See here: http://embed.cs.utah.edu/embarrassing/ There is a lot of data there. Please excuse bugs and other problems. Feedback would be appreciated. John Regehr
Re: detailed comparison of generated code size for GCC and other compilers
I wonder if the original program was already broken or was this something your conversion introduced? Not sure about this specific case but I'm sure there's some of each. I also noticed these testcases but decided to leave them in for now. Obviously the code is useless, but it can still be interpreted according to the C standard, and code can be generated. Once you start going down the road of exploiting undefined behavior to create better code -- and gcc already does this pretty aggressively -- why not keep going? That said, if there's a clear sentiment that this kind of test case is undesirable, I'll make an effort to get rid of these for subsequent runs. The bottom line is that these results are supposed to provide you folks with useful directions for improvement. Looking further down the table a lot of the differences on empty-after-optimization functions (lots of 5 vs 2 bytes) seem to be that gcc-head uses frame pointers and the other compiler doesn't. Clearly for a fair comparison these settings should be the same. I wanted to avoid playing flag games and go with -Os (or nearest equivalent) for all compilers. Maybe that isn't right. John Regehr
Re: detailed comparison of generated code size for GCC and other compilers
Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to agree with both of your suggestions. I'll re-run everything w/o frame pointers and ignoring testcases where some compiler warns about use of uninitialized local. I hate the way these warnings are not totally reliable, but realistically if GCC catches most cases (which it almost certainly will) the ones that slip past won't be too much of a problem. No doubt there are plenty more improvements to make but hopefully this is a good start. John Regehr
Re: detailed comparison of generated code size for GCC and other compilers
My opinion is that code containing undefined behaviors is definitely interesting, but probably it is interesting in a different way than functions that are more meaningful. If I have time I'll just separate out the testcases into two groups: one containing functions that are more or less sensible code, the other containing functions that can be automatically categorized as bogus. Thanks, John Regehr Actually, I think they're very interesting - especially if they are valid code, and one compiler optimizes them away, but the other doesn't. You may have heard of a commercial testsuite built on this principle :-) -- Daniel Jacobowitz CodeSourcery
Re: detailed comparison of generated code size for GCC and other compilers
Optimizations based on uninitialized variables make me very nervous.
If uninitialized memory reads are transformed into don't-cares, then
checking tools like valgrind will no longer see the UMR (assuming that
the lack of initialization is a bug).
Did I understand that icc does this? It seems like a dangerous practice.
Yes, it looks like icc does this. But so does gcc, see below. There is
no "add" in the generated code.
John Regehr
[reg...@babel ~]$ cat undef.c
int foo (int x)
{
int y;
return x+y;
}
[reg...@babel ~]$ current-gcc -O3 -S -o - undef.c -fomit-frame-pointer
.file "undef.c"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
movl4(%esp), %eax
ret
.size foo, .-foo
.ident "GCC: (GNU) 4.5.0 20091117 (experimental)"
.section.note.GNU-stack,"",@progbits
Re: detailed comparison of generated code size for GCC and other compilers
I would only be worried for cases where no warning is issued *and* unitialized accesses are eliminated. Yeah, it would be excellent if GCC maintained the invariant that for all uses of uninitialized storage, either the compiler or else valgrind will issue a warning. We could test for violations of this. Several times I've thought about cross-testing various compilers and versions of compilers for consistency of warnings. But I never managed to convince myself that developers would care enough to make it worth the trouble. John
Re: detailed comparison of generated code size for GCC and other compilers
Also, we're not running LTO in any compiler and we removed all "static" declarations from the code to keep compilers from making closed-world assumptions. John Regehr
updated code size comparison
[cross-posting to the GCC and LLVM lists] I've updated the code size results here: http://embed.cs.utah.edu/embarrassing/dec_09/ The changes for this run were: - delete a number of testcases that contained use of uninitialized local variables - turn off frame pointer emission for all compilers - ask all compilers to target x86 + SSE3 - ask all compilers to not emit stack protector code - run unix2dos on the .c files so people on Windows don't see all the lines running together Hopefully the results are more fair and useful now. Again, feedback is appreciated. Once people are happy with how these results are obtained, I'll plan on just re-running the scripts every few months so we can see how the compilers evolve. Also there are many possibilities for enhancement including adding new architectures, harvesting more and larger functions, and harvesting C++ code. Thanks, John Regehr
Re: updated code size comparison
Moreover, aggregating those boolean results to yield things like "X generated larger code than Y NN% of the time" seems even weirder. Is this really useful information, other than for marketing? Hi Miles- Did you click through to one of the pages that shows a rank-ordered list of functions where one compiler generates bigger code than another? Those are the pages that are supposed to contain useful information. You're right, the aggregated results are not useful other than to get a broad overview. John Regehr
Re: updated code size comparison
Hi Paolo, I would also avoid testcases using volatile. Smaller code on these testcases is often a sign of miscompilation rather than optimization. For example, http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/076389.c is miscompiled on GCC 3.4 and SunCC 5.10. Yeah, there are definitely several examples where small code is generated by miscompilation, especially of volatiles. However I would prefer to leave these testcases in, unless there is a strong feeling that they are too distracting. They serve as poignant little reminders about how easy it is to get volatile wrong... John
Re: updated code size comparison
Yes, that was my point. If you want to make a separate section for volatile, that would indeed be helpful. I checked and there are about 37,000 harvested functions containing the volatile qualifier. Next time, there will be even more since we'll be harvesting code from the FreeBSD kernel in addition to Linux. It doesn't seem at all clear that it's productive to separate these out. If people are really hating volatile and think it leads to unfair results, I'll probably just #define away volatile next time. John
updated code size comparison
Hi folks, I've posted an updated code size comparison between LLVM, GCC, and others here: http://embed.cs.utah.edu/embarrassing/ New in this version: - much larger collection of harvested functions: more than 360,000 - bug fixes and UI improvements - added the x86 Open64 compiler John
expression statements, volatiles, and C vs. C++
The question is, what should C and C++ compilers do with this code?
volatile int x;
void foo (void) {
x;
}
This question is not totally stupid: embedded systems use code like this
when reading a hardware register has a useful side effect (usually
clearing the register).
It is reasonably clear that a C compiler should load from x and throw
away the value. gcc does this, as do most decent C compilers.
However, g++ also loads from x and this does not appear to be supported
by the 1998 C++ standard. In 6.2, it is explicitly stated that for an
expression statement, no conversion from lvalue to rvalue occurs. If
there's no rvalue, there should not be a load from x.
Anyway, I'm curious: is the C-like interpretation of a volatile
expression statement considered to be a feature by the g++ maintainers?
If so, what is the rationale?
I haven't do extensive testing, but there do exist compiler families
(such as those from IAR and Intel) where the C compiler loads from x and
the C++ compiler does not.
Thanks,
John Regehr
Re: expression statements, volatiles, and C vs. C++
I'm not sure this follows. It's stated explicitly that "The expression is evaluated and its value is discarded." How can you evaluate the expression without reading the volatle? I'm certainly not an expert on this material but I wouldn't think you'd normally read a variable in order to evaluate it as an lvalue. My guess is that evaluating the expression means computing the address for something like "*(p+1)". Also, there's the non-normative [Note: volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation. See 1.9 for detailed semantics. In general, the semantics of volatile are intended to be the same in C++ as they are in C. ] Yep. Besides, all that changing this would do is break programs. Well they're broken anyway since widely-used C++ compilers are choosing to not read the variable under these circumstances. The obvious solution is "don't do that" but there's plenty of code doing this out there, and plenty of developers who need re-educating. John
LIM/Alias Analysis performance issue
Hi,
I've encountered a performance issue in a port of GCC I'm working on,
where the behavior of LIM is affected by the ordering of fields in a
structure. I've been able to re-create it with a GCC 4.3.1
Linux X86 compiler. With GCC 4.3.1 Linux X86, when I compile:
struct foo {
int *p;
int t;
} T;
void o() {
unsigned int i;
for (i = 0; i < 256; i++) {
T.p[i]=0;
}
}
with the command:
gcc -S -O2 -fdump-tree-all good.c
the file good.c.095t.lim shows T.p being moved outside the loop:
:
pretmp.10_8 = T.p;
:
# i_14 = PHI
D.1556_4 = (long unsigned int) i_14;
D.1557_5 = D.1556_4 * 4;
D.1558_6 = pretmp.10_8 + D.1557_5;
*D.1558_6 = 0;
i_7 = i_14 + 1;
if (i_7 <= 255)
goto ;
else
goto ;
:
goto ;
If the fields of the structure are reversed:
struct foo {
int t;
int *p;
} T;
T.p is kept inside the loop:
:
# i_21 = PHI
D.1555_3 = T.p;
D.1556_4 = (long unsigned int) i_21;
D.1557_5 = D.1556_4 * 4;
D.1558_6 = D.1555_3 + D.1557_5;
*D.1558_6 = 0;
i_7 = i_21 + 1;
if (i_7 <= 255)
goto ;
else
goto ;
:
goto ;
On my port, this causes a large performance degradation, and I suspect
the
cause is ultimately in the alias analysis pass. I was wondering if
there
is a way to configure GCC to avoid this issue.
Thanks,
John Lu
Re: Transforms on SSA form
There are documented methods of SSA decomposition. The naive method is a simple reversal of SSA composition: SSA composition: rename variables (typically by adding suffix), add phi nodes SSA decomposition: rename variables (by dropping suffix), remove phi nodes The short answer to your question is that there is no C equivalent of a phi node. You simply drop it. Hope this helps, John
Re: register int variable being written to/read from stack
First, off the volatile qualifier means "source-level reads/write must
turn into real loads and stores" so take that out of your declaration and
see how the code looks then. I don't know if the standard addresses the
interaction of volatile and register, but I'd expect volatile to win since
register doesn't actually mean anything (in the standard, at least).
John Regehr
On Tue, 20 Jan 2009, Ian Lance Taylor wrote:
baver writes:
A sample code listing is at the bottom of the email, as well as the lines we've
added to opcodes/mips-opc.c for our opcodes.
Anyone know how to stop the register from being stored and read from on the
stack? We've defined it as
volatile register int idx asm("s0");
Show us the change you made to the MD file, or, if you didn't make a
change, show us the asm statement you are using.
Anyone know how to stop the register from being stored and read from on the
stack? We've defined it as
volatile register int idx asm("s0");
Are you doing this inside or outside of a function? That is, a global
variable or not? The two cases act quite differently, as discussed
briefly in the documentation.
Ian
Re: Split Stacks proposal
This effort is relevant: http://research.microsoft.com/en-us/um/people/jcondit/capriccio-sosp-2003.pdf John Regehr
Re: bitwise dataflow
I'm thinking about adding bitwise dataflow analysis support to RTL. Before embarking on this, I'd suggest playing with the bitwise domain analysis that one of my students did as part of his cXprop tool: http://www.cs.utah.edu/~coop/research/cxprop/#DOWNLOADS This is a source-level analysis in CIL and so is not quite analogous to what you propose. However, it should give you some ideas about what kind of results you can expect at the RTL level. Our experience was that the bitwise domain is not that powerful. On the other hand, it converges quickly compared to intervals. John Regehr
Re: Syntactic sugar to access arrays and hashes in Objective-C
Hi gcc'ers,
I was wondering if it would be a useful extension to Objective-C
expand the [] operator
to support array and hash references to NSArray and NSDictionary
classes directly to
greatly improve the readability of code:
NSArray *players = [NSArray arrayWithObjects:..., nil];
[players[0] play]; // expanded by compiler to: [(AVAudioPlayer *)
[players objectAtIndex:0] play];
players[0] = aPlayer // expanded to: [players replaceObjectAtIndex:0
withObject:aPlayer]; or for NSDictionary:
NSDictionary *playersDict = [NSDictionary ];
[playersDict[@"playerOne"] play]; // -> [(AVAudioPlayer *)[playersDict
objectForKey:@"playerOne"] play];
playersDict[@"playerTwo"] = aPlayer; // becomes: [players
setObject:aPlayer forKey:@"playerTwo"];
This also makes use of a form of templates for Objective-C containers
which might also be a useful extension.
@interfcae NSArray : NSObject {
- (T)objectAtIndex:(NSUInteger)index;
@end
@interface NSMutableObject : NSArray {
- (void)replaceObjectAtIndex:(NSUInteger)index withObject:(T)anObject
@end
Where not specified, type T would default to (id) for backward
compatibility.
I've looked at the code and such an extension would involve code
generation inside
the subscript operator which looks difficult but if you want me to
have a go and
can provide some pointers let me know. I know this introduces coupling
between
the compiler and the runtime but I would have thought the benefits
outweighed this.
Perhaps classes which wish to support subscripting make methods
available by convention:
for NSArray:
- (id)operatorSubscriptInt:(NSUInteger)index;
- (id)operatorSubscriptObject:(id)key;
for NSDictionary
- (id)operatorSubscriptInt:(NSUInteger)index setValue:(id)anObject;
- (id)operatorSubscriptObject:(id)key setValue:(id)anObject;
I know, it sounds like one step on the way to operator overloading
Best Regards & Thanks for your work,
John Holdsworth
Fwd: Objective-C and C99 strict aliasing
I've long wondered how GCC deals with C99 strict aliasing rules when
compiling Objective-C code. There's no language spec for Objective-C,
other than the written prose description of the language that Apple
provides (which, until recently, has been virtually unmodified since
it's NeXT origins), so there's no definitive source to turn to to help
answer these kinds of questions.
I recently had some time to dig in to the compiler to try to find an
answer. Keep in mind I'm no expert on GCC's internals.
The problem is roughly this: How does C99's strict aliasing rules
interact with pointers to Objective-C objects. Complicating matters,
how do those rules apply to the complexities that object-oriented
polymorphism causes? As an example,
id object;
NSString *string;
NSMutableString *mutableString;
Objective-C (and object-oriented principles) say the following are legal:
object = string;
object = mutableString;
string = object;
string = mutableString;
mutableString = object;
And the following results in 'warning: assignment from distinct
Objective-C type', which is expected:
mutableString = string;
There's really two distinct ways of looking at this problem: What is
permitted under Objective-C and object-oriented principles (of which
there doesn't seem to be any problem), and what is permitted under C,
specifically, C99 and its strict-aliasing rules.
Without a language spec to guide us, we need to make some reasonable
assumptions at some point. I've never seen a 'standards grade
language specification' definition of what a 'class' (ie, NSString in
the above) is. Is it a genuinely opaque type that exists outside of C
defined 'types'? Or is it really just syntactic sugar for a C struct?
I've always subscribed to the syntactic sugar definition, as this is
how GCC represents things internally, and the way that every
Objective-C compiler I'm aware of has done things.
Working under the assumption that it really is just syntactic sugar,
this would seem to interact rather poorly with C99's 'new' type-based
strict-aliasing rules. In fact, I have a hard time reconciling
Objective-C's free-wheeling type-punning ways with C99's
strict-aliasing rules, with the possible exception of recasting
Objective-C in terms of C's unions. When I went looking through the
compiler sources to see how it managed with the problem, I was unable
to find anything that dealt with these problems. Is that really the
case, or have I missed something?
Objective-C defines 'c_common_get_alias_set' as its language specific
alias set manager. c_common_get_alias_set() seems(?) to only
implement C's strict aliasing rules, with no provisions for
Objective-C's needs. To test this, I added the following to
c_common_get_alias_set to see what happens:
if(((c_language == clk_objc) || (c_language == clk_objcxx)) &&
((TYPE_LANG_SPECIFIC (t) && (TYPE_LANG_SPECIFIC(t)->objc_info)) ||
objc_is_object_ptr(t))) {
warning(OPT_Wstrict_aliasing, "Caught and returning 'can alias
anything' for objc type");
return(0);
}
right before the following line:
if (c_language != clk_c || flag_isoc99)
Compiling with -O2 -Wstrict-aliasing causes an awful lot of 'Caught..'
messages to be returned. Assuming that ivar access is really just
syntactic sugar for self->IVAR, then it would seem like there can be
times where strict-aliasing can cause the compiler to generate "bad
code", for some extremely complicated definition of what the correct
thing to do without the benefit of having a standards grade language
specification.
Can anyone with a much better understanding of GCC's internals comment on this?
Re: Syntactic sugar to access arrays and hashes in Objective-C
Hi David, Thanks for the reply, I've managed to find a solution for my needs in the end. It turns out the Apple gcc compiler supports mixing C++ and Objective-C in the same source file so I've been able to implement what I was looking for using operator overloading - a much more flexible solution that doesn't require the compiler to have knowledge of Apple's XCode core libraries. I've attached the source, its a rather odd hybrid to say the least: The documentation is here: http://johnholdsworth.com/objcpp/html I need to write the unit tests now.. I'm not sure its saved me any time in reality but it was an interesting digression and hopefully it will be useful to somebody :) objcpp.h Description: Binary data Cheers, John Holdsworth On 8 Apr 2009, at 14:34, David Ayers wrote: Am Samstag, den 21.03.2009, 11:59 +0100 schrieb John Holdsworth: I was wondering if it would be a useful extension to Objective-C expand the [] operator to support array and hash references to NSArray and NSDictionary classes directly to greatly improve the readability of code: I'm not an ObjC front end maintainer and have no authority but one issue I would have with this feature with gcc proper is that the ObjC front end would have to learn about the semantics of "NSArray" and "NSDictionary" which are actually not part of the language but part of an external library. Now gcc already supports the -fconstant-string-class option as one way to embed knowledge about an external library into an executable. But I would like adding options with all these semantics from a foreign library into the language implementation. Maybe this could be done more elegantly with plugin infrastructure that that es being currently added: http://gcc.gnu.org/wiki/plugins Cheers, David
Re: Fwd: Objective-C and C99 strict aliasing
On Wed, Apr 8, 2009 at 5:42 PM, Ian Lance Taylor wrote: > John Engelhart writes: > >> Objective-C defines 'c_common_get_alias_set' as its language specific >> alias set manager. c_common_get_alias_set() seems(?) to only >> implement C's strict aliasing rules, with no provisions for >> Objective-C's needs. > >> Can anyone with a much better understanding of GCC's internals comment on >> this? > > I think you are correct about what is happening today. > > Since I don't know anything about Objective C, I don't know what should > happen instead. I would guess that you would want to set up a tree of > alias sets, using record_alias_subset. The 'right thing' is pretty tricky. I've given it some thought and I can't come up with a simple set of rules that cleanly mesh with C99's rules. I think that coming up with a 'right answer' would take an awful lot of very carefully considered thought. The easiest, and I think safest, course of action would be to add a line in c_common_get_alias_set similar to the one I suggested. That is, if it is a pointer to something that looks even remotely like an objective-c "object", then just assume that it can alias anything. Any recommendations on what to do next? Filing a bug seems like the step, I just wanted to see if I had missed something in my analysis of the problem.
dwarf, step over
Hi, Im working on a C source level debugger. The debug info available in elf format. How could be 'step over' implemented? The problem is at 'Point1', anyway I can wait for the next source line (reading it from the .debug_line table). Thanks ... if (a == 1) x = 1; //Point1 else if (a == 2) x = 1; z = 1; ...
some integer undefined behaviors in gcc
I ran gcc 162830 on x86 under a tool that checks for integer undefined behaviors. The attached error messages show up when running "make check" and when recompiling gcc. Each line in the attachment is an error message giving the problematic operator, its srcloc, the types of its operands, and examples of offending values. Let me know if more detail is needed or if it would be better for me to file all 71 bug reports. Thanks, John Regehr <../../gcc/alias.c, (1896:25)> : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int32): -2147483647 right (int32): -4 <../../gcc/alias.c, (322:44)> : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int32): 39996 right (int32): 8 <../../gcc/builtins.c, (7681:57)> : Op: -, Reason : Signed Subtraction Overflow, UNARY OPERATION: right (int32): -2147483648 <../../gcc/builtins.c, (7699:57)> : Op: -, Reason : Signed Subtraction Overflow, UNARY OPERATION: right (int32): -2147483648 <../../gcc/builtins.c, (7709:25)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 <../../gcc/builtins.c, (7717:25)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 <../../gcc/combine.c, (10620:62)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 <../../gcc/combine.c, (10655:62)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 <../../gcc/combine.c, (11350:54)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 <../../gcc/combine.c, (7047:63)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 <../../gcc/combine.c, (7205:54)> : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647 right (int32): 1 <../../gcc/combine.c, (7838:22)> : Op: <<, Reason : Unsigned Left Shift Error: Right operand is negative or is greater than or equal to the width of the promoted left operand, BINARY OPERATION: left (uint32): 4294967295 right (uint32): 4294967291 <../../gcc/config/i386/i386.c, (10253:10)> : Reason : The current index is greater than array size! <../../gcc/config/i386/i386.c, (16316:17)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): 0 right (int32): -2147483648 <../../gcc/config/i386/i386.c, (16362:18)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): 0 right (int32): -2147483648 <../../gcc/config/i386/i386.c, (16473:11)> : Op: -, Reason : Signed Subtraction Overflow, UNARY OPERATION: right (int32): -2147483648 <../../gcc/dbxout.c, (674:14)> : Op: -, Reason : Signed Subtraction Overflow, UNARY OPERATION: right (int32): -2147483648 <../../gcc/double-int.c, (115:13)> : Op: -, Reason : Signed Subtraction Overflow, UNARY OPERATION: right (int32): -2147483648 <../../gcc/double-int.c, (158:21)> : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int32): 65535 right (int32): 65535 <../../gcc/dse.c, (1636:28)> : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647 right (int32): 1 <../../gcc/dwarf2out.c, (4753:46)> : Op: -, Reason : Signed Subtraction Overflow, UNARY OPERATION: right (int32): -2147483648 <../../gcc/emit-rtl.c, (261:44)> : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int32): 134217728 right (int32): 5 <../../gcc/emit-rtl.c, (262:40)> : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int32): 786432 right (int32): 250 <../../gcc/expmed.c, (1092:13)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 <../../gcc/expmed.c, (2928:15)> : Op: -=, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 <../../gcc/expmed.c, (3107:8)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 <../../gcc/expmed.c, (3707:52)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 <../../gcc/expmed.c, (3813:23)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 <../../gcc/expmed.c, (4151:12)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 <../../gcc/expmed.c, (949:38)> : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 <../../gcc/expmed.c, (954:42)> : Op: -, Reason : Signed Subtractio
Re: some integer undefined behaviors in gcc
I think the messages are clear enough. You should probably wait a few days to let people comment and/or fix, and then file PRs. 1 per file seems to be the right granularity. Thanks Eric, that's what I'll do. John
Re: some integer undefined behaviors in gcc
On Sat, 7 Aug 2010, Florian Weimer wrote: I wonder if we should give up and make -fwrapv the default. My sense is that there are not that many of these integer bugs, and probably all of them are simple to fix. Best to just fix them and then run a tool like ours every now and then to see if anything new has popped up. John Regehr
Is Ada 2005 Issue AI-0157 implemented correctly in GCC 4.6.0?
This Ada 2012 amendment titled "Calling Unchecked Deallocation is illegal for zero-sized pools" has been implemented in GCC 4.6.0 recently (ada/sem_intr.adb). However, the restriction is enforced even when -gnat2005 (or -gnat95) switched are explicitly passed to gcc. Shouldn't this check only be enforced with the -gnat2012 switch? I discovered this trying to build Adacore's gprbuild_gpl_2010 package. The build fails with GCC 4.6.0 with the message "sinput.adb:808:19: deallocation from empty storage pool" The -gnat05 switch is explicitly used in the gpr settings, so I would expect AI-0157 to not be in effect. Am I wrong? Regards, John
Re: Is Ada 2005 Issue AI-0157 implemented correctly in GCC 4.6.0?
Thanks for the explanation, Robert. To be clear, it's code maintained by Adacore that has run afoul of the change. I don't believe gprbuild is part of Adacore's public repository, so I'm not quite sure how I'm supposed to obtain a version of gprbuild that will compile with GCC 4.6.0. This version was released with GNAT GPL 2010 recently, rather than separately, so I'm afraid that I'll need to wait until around July 2011 before the next release! :( Maybe a patch for gprbuild_gpl_2010 can be made available? Regards, John On 28/10/2010 15:47, Robert Dewar wrote: On 10/28/2010 9:37 AM, John Marino wrote: This Ada 2012 amendment titled "Calling Unchecked Deallocation is illegal for zero-sized pools" has been implemented in GCC 4.6.0 recently (ada/sem_intr.adb). However, the restriction is enforced even when -gnat2005 (or -gnat95) switched are explicitly passed to gcc. Shouldn't this check only be enforced with the -gnat2012 switch? I discovered this trying to build Adacore's gprbuild_gpl_2010 package. The build fails with GCC 4.6.0 with the message "sinput.adb:808:19: deallocation from empty storage pool" The -gnat05 switch is explicitly used in the gpr settings, so I would expect AI-0157 to not be in effect. Am I wrong? This is a binding interpretation, which means that it is something that should have been there all along and is reasonable to include in earlier versions, so this change is indeed deliberate and fine. If your code runs afoul of the change, you were doing erroneous things anyway.
Re: concurrence.h compiler error on head
In message <4cf69533.10...@oarcorp.com> Joel Sherrill wrote: > Hi, > > Compiling C++ on the head targeting > arm-rtems4.11, I get this error. It doesn't > occur on m68k-rtems4.11. I don't know about > the other targets yet. > > Any suggestions on what is causing this > and how to resolve it? > > [...] > In destructor '__gnu_cxx::__scoped_lock::~__scoped_lock()': > /users/joel/test-gcc/b-gcc1-arm/arm-rtems4.11/libstdc++-v3/include/ext/concurrence.h:313:5: > > error: __gnu_cxx::__scoped_lock::~__scoped_lock() causes a section type > conflict > In file included from > /users/joel/test-gcc/b-gcc1-arm/arm-rtems4.11/libstdc++-v3/include/ext/pool_allocator.h:51:0, > from > /users/joel/test-gcc/gcc-svn/libstdc++-v3/src/pool_allocator.cc:31: > /users/joel/test-gcc/b-gcc1-arm/arm-rtems4.11/libstdc++-v3/include/ext/concurrence.h:313:5: > > error: __gnu_cxx::__scoped_lock::~__scoped_lock() causes a section type > conflict This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46667 and caused by Jan Hubicka's change r167085. John. -- John Tytgat, in his comfy chair at home john.tyt...@aaug.net
Re: [Ada, or FC5?] Storage_Error stack overflow (or erroneous memory access)|
This is caused by EXEC SHIELD, new to FC5, preventing execution of trampolines out of the stack. You can turn it off via: echo 0 > /proc/sys/kernel/exec-shield HTH, John Parkes
Making *-netbsd-* to mean ELF not a.out for all CPUs
Hello Binutils and GCC lists[1], I would like to propose that GNU tools consistently interpret configs with "netbsd" as meaning ELF as opposed to a.out. Currently, newer CPUs do that, but older ones have "netbsd" mean a.out for historical reasons, and "netbsdelf" is used instead. This inconsistency is a bit of a nuisance to my distro / package set[2] which aims to support cross compilation to/from arbitrary platforms without special cases. Other platforms that formerly used a.out (like Linux) have long since changed the default to be ELF, so I don't know why NetBSD shouldn't too. I first reached out to the NetBSD toolchain developers[3]. They convinced me some alternate disambiguater (my first suggestion) wasn't worth it, with a.out being so old. But they did offer some tentative support for my second suggestion of changing the meaning of bare "netbsd" --- "netbsdaout" would still be available to unambiguously request a.out for anyone that wants it. I come now to just ask about that second suggestion. I have prepared a first draft of patches for Binutils and GCC, but before polishing them off to submit, I figured I should ask about the openness to such a change. Thanks, John [1]: I hope it's OK to email both lists at once like this; this is a question about a change that I think only makes sense if both projects approve. [2] Nixpkgs, https://github.com/nixos/nixpkgs/ [3]: https://mail-index.netbsd.org/tech-toolchain/2021/06/10/msg003976.html this post goes more into more why I am interested in this change for anyone that's curious. Apologies for the duplicate emails; I thought the list was rejecting emails with HTML but it was something else.
Optional machine prefix for programs in for -B dirs, matching Clang
Problem: It's somewhat annoying to have to tell GCC --with-as=... --with-ld=... just to prefix those commands the same way GCC is prefixed. In particular, when doing host-only build (skipping all target libraries), one otherwise doesn't need the target-specific binutils to be yet built, but --with-as and --with-ld will complain if the referenced exes cannot be found. This might sound esoteric, but as someone that spends a lot of time optimizing bootstrap dependency graphs for incrementality / parallelism, it is quite a real-world annoyance. Solution: I think the solution is to stop making cross compilers rely on these --with-flags to do the obvious things. Executables like `collect2` hidden within a libexesubdir (libexec/gcc//) have no need for prefixing, but the assembler and linker are very much public-facing executables in their own right, and usually are prefixed. Per [1], Clang does in fact look up prefixed exes against -B across the board. Making GCC look up exes that same way seems like a fine solution too. What do you all think? John [1]: https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-b-prefix
Re: Optional machine prefix for programs in for -B dirs, matching Clang
On Wed, Aug 4, 2021, at 3:32 AM, Jonathan Wakely via Gcc 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 query. So yes in practice for cross compilers people do the --with-* and no searching happens, and for native compilers no one bothers and searching does happen. But to be a pedant strictly speaking the behavior is independent of whether the compiler is host == target or not.
Re: Optional machine prefix for programs in for -B dirs, match ing Clang
On Wed, Aug 4, 2021, at 10:48 AM, Michael Matz wrote:
> ... the 'as' and 'ld' executables should be simply found within the
> version and target specific GCC libexecsubdir, possibly by being symlinks
> to whatever you want. That's at least how my crosss are configured and
> installed, without any --with-{as,ld} options.
Yes that does work, and that's probably the best option today. I'm just a
little wary of unprefixing things programmatically.
For some context, this is NixOS where we assemble a ton of cross compilers
automatically and each package gets its own isolated many FHS. For that reason
I would like to eventually avoid the target-specific subdirs entirely, as I
have the separate package trees to disambiguate things. Now, I know that exact
same argument could also be used to say target prefixing is also superfluous,
but eventually things on the PATH need to be disambiguated. There is no
requirement that the libexec things be named like the bin things, but I sort of
feel it's one less thing to remember and makes debugging easier.
I am sympathetic to the issue that if GCC accepts everything Clang does and
vice-versa, we'll Postel's-law ourselves ourselves over time into madness as
mistakes are accumulated rather than weeded out. But this one thing feels
pretty innocuous to me, and it could also be made stricter by ensuring that we
never *both* add the machine subdir *and* prefix the path --- i.e. at most 1
target-disambiguating method is used at a time.
I now have some patches for this change I suppose I could also submit.
Cheers,
John
Re: Optional machine prefix for programs in for -B dirs, match ing Clang
On Thu, Aug 5, 2021, at 8:30 AM, Michael Matz wrote:
> Hello,
>
> On Wed, 4 Aug 2021, John Ericson wrote:
>
> > On Wed, Aug 4, 2021, at 10:48 AM, Michael Matz wrote:
> > > ... the 'as' and 'ld' executables should be simply found within the
> > > version and target specific GCC libexecsubdir, possibly by being symlinks
> > > to whatever you want. That's at least how my crosss are configured and
> > > installed, without any --with-{as,ld} options.
> >
> > Yes that does work, and that's probably the best option today. I'm just
> > a little wary of unprefixing things programmatically.
>
> The libexecsubdir _is_ the prefix in above case :)
Right. I meant stripping off the `cpu-vendor-os-` (conventionally) that ld and
as are prefixed with. stripping off leading directories is easier.
> > For some context, this is NixOS where we assemble a ton of cross
> > compilers automatically and each package gets its own isolated many FHS.
> > For that reason I would like to eventually avoid the target-specific
> > subdirs entirely, as I have the separate package trees to disambiguate
> > things. Now, I know that exact same argument could also be used to say
> > target prefixing is also superfluous, but eventually things on the PATH
> > need to be disambiguated.
>
> Sure, which is why (e.g.) cross binutils do install with an arch prefix
> into ${bindir}. But as GCC has the capability to look into libexecsubdir
> for binaries as well (which quite surely should never be in $PATH on any
> system), I don't see the conflict.
Yes there is no actual conflict. Our originally wrapper scripts may have been
confused about this at some point but that's on us.
>
> > There is no requirement that the libexec things be named like the bin
> > things, but I sort of feel it's one less thing to remember and makes
> > debugging easier.
>
> Well, the naming scheme of binaries in libexecsubdir reflects the scheme
> that the compilers are using: cc1, cc1plus etc. Not
> aarch64-unknown-linux-cc1.
Right.
>
> > I am sympathetic to the issue that if GCC accepts everything Clang does
> > and vice-versa, we'll Postel's-law ourselves ourselves over time into
> > madness as mistakes are accumulated rather than weeded out.
>
> Right. I supposed it wouldn't hurt to also look for "${targettriple}-as"
> in $PATH before looking for 'as' (in $PATH). But I don't think we can (or
> should) switch off looking for 'as' in libexecsubdir. I don't even see
> why that behaviour should depend on an option, it could just be added by
> default.
OK I agree with that. so if someone passes -B$x, how about looking for
- $x/$machine/$version/$prog
- $x/$machine/$prog
- $x/$machine-prog
- $x/prog
so no prefixing in the subdir, only in the main dir?
($libexecsubdir is morally $libexec being a search dir + subdir IIRC)
> > I now have some patches for this change I suppose I could also submit.
>
> Even better :)
Great!
I will continue improving my patch based on the above. In the meantime, I
posted https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576725.html which
is a small cleanup that, while helping with my changes, doesn't change the
behavior and I hope is good in any event.
website correction
Apologies if this is the wrong place to send this, but the bottom of the page said send comments here. The link to Apple's website on the page "http://gcc.gnu.org/install/specific.html#powerpc-*-darwin*" needs to be updated. It reads: "http://developer.apple.com/tools/compilers.html" The new correct link is "http://developer.apple.com/darwin/projects/compiler/" Thanks!
TYPO - http://gcc.gnu.org/gcc-4.8/changes.html
"cpmpilation" probably meant "compilation"
Re: [Regression] d96ac6f2: time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons
On 06/01/2013 11:45 AM, Jens Taprogge wrote: On Sat, Jun 01, 2013 at 05:37:05PM +0200, Jens Taprogge wrote: On Fri, May 31, 2013 at 05:16:49PM -0700, John Stultz wrote: On 05/31/2013 04:42 PM, Jens Taprogge wrote: On Fri, May 31, 2013 at 02:14:47PM -0700, John Stultz wrote: Ok. None of this is yet making any sense to me. (And I worry enumerating all the mix and match of configs that work or don't only blurs the issues). Few base questions: 1) What distro is this on? arch linux 2) What gcc version are you using? gcc (GCC) 4.8.0 20130502 (prerelease) (Sorry, I'm not very familiar with arch) Are you able to also install a 4.7 gcc in parallel to try to build with? If so, you might want to try that. Your results are just weird enough I want to just be sure we're not chasing compiler caused ghosts. I will compile gcc4.6 and see if using that makes any difference. I have compiled two of the broken configurations with gcc-4.6 and both boot up. I am not sure how to proceed from here. Ok. That at least helps make me feel better that I'm not just crazy. First thing, I'd probably file a bug against the Arch gcc 4.8 package, just in case there's any out-of-tree changes there. I've also added the gcc mailing list to the thread to see if someone there can help narrow down what might be going wrong. thanks -john
