Re: Add corollary extension
On 06/28/2012 08:39 PM, Rick Hodgin wrote:
>> Why do you want to bother with a non-standard,
>> unportable extension instead of just writing:
>>
>> inline bool isSystemClosed()
>> { return !isSystemOpen; }
>>
>> Which is simple, conventional, easy to understand
>> and portable.
>>
>> Or in C++ just define a suitable type, instead of
>> needing changes to the core language:
>>
>> struct inv_bool {
>> bool& b;
>> operator bool() const { return !b; }
>> };
>>
>> inv_bool isSystemClosed = { isSystemOpen };
or, better:
inv_bool isSystemClosed(isSystemOpen);
>
> There are certain fundamentals in data processing. The inverse bool
> is one of them. Why not be able to reference it more naturally in
> code utilizing something the compiler already knows about and can
> wield effortlessly?
>
> I've thought more about the syntax, and I see this making more sense:
> bool isSystemOpen[!isSystemClosed];
But why is this new syntax better than
inv_bool isSystemClosed(isSystemOpen);
Andrew.
gcc@gcc.gnu.org
On Thu, Jun 28, 2012 at 5:23 PM, Ilya Enkovich wrote: > Hello, > > I faced a problem with usage of force_gimple_operand function for > specific tree. I have a TARGET_MEM_REF tree node whose address I want > to pass as argument to the function call. I use build_fold_addr_expr > to get address tree and then pass it to force_gimple_operand which > generates strange sequence of statements. > > Original mem ref: MEM[base: arr_5, index: ivtmp.130_22, step: 8, offset: 0B] > > build_fold_addr_expr result: &MEM[base: dirlist_5, index: > ivtmp.130_22, step: 8, offset: 0B] > > force_gimple_operand result: > D.5638_65 = MEM[base: dirlist_5, index: ivtmp.130_22, step: 8, offset: 0B]; > D.5639_66 = D.5638_65; > D.5640_67 = D.5639_66; > D.5642_68 = D.5640_67; > D.5641_69 = &D.5642_68; > > Code produced by force_gimple_operand is incorrect, has changed > semantics compared to original tree and fails later at gimple > verification. > > Do I use wrong interfaces? You cannot take the address of a TARGET_MEM_REF. Richard. > Thanks > Ilya
Re: [onlinedocs]: No more automatic rebuilt?
Next problem: libiberty. This looks reasonably well in dvi and pdf. OK? That should really be the last error. Andreas. * copying-lib.texi (Library Copying): Don't use @heading inside @enumerate. diff --git a/libiberty/copying-lib.texi b/libiberty/copying-lib.texi index 79e1038..31ef68b 100644 --- a/libiberty/copying-lib.texi +++ b/libiberty/copying-lib.texi @@ -476,12 +476,7 @@ decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. -@iftex -@heading NO WARRANTY -@end iftex -@ifinfo @center NO WARRANTY -@end ifinfo @item BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO -- 1.7.11.1 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [onlinedocs]: No more automatic rebuilt?
On Fri, 29 Jun 2012, Andreas Schwab wrote: > Next problem: libiberty. This looks reasonably well in dvi and pdf. > OK? That should really be the last error. > > Andreas. > > * copying-lib.texi (Library Copying): Don't use @heading inside > @enumerate. Looks reasonable. Thanks, Andreas. Gerald
gcc@gcc.gnu.org
2012/6/29 Richard Guenther : > On Thu, Jun 28, 2012 at 5:23 PM, Ilya Enkovich wrote: >> Hello, >> >> I faced a problem with usage of force_gimple_operand function for >> specific tree. I have a TARGET_MEM_REF tree node whose address I want >> to pass as argument to the function call. I use build_fold_addr_expr >> to get address tree and then pass it to force_gimple_operand which >> generates strange sequence of statements. >> >> Original mem ref: MEM[base: arr_5, index: ivtmp.130_22, step: 8, offset: 0B] >> >> build_fold_addr_expr result: &MEM[base: dirlist_5, index: >> ivtmp.130_22, step: 8, offset: 0B] >> >> force_gimple_operand result: >> D.5638_65 = MEM[base: dirlist_5, index: ivtmp.130_22, step: 8, offset: 0B]; >> D.5639_66 = D.5638_65; >> D.5640_67 = D.5639_66; >> D.5642_68 = D.5640_67; >> D.5641_69 = &D.5642_68; >> >> Code produced by force_gimple_operand is incorrect, has changed >> semantics compared to original tree and fails later at gimple >> verification. >> >> Do I use wrong interfaces? > > You cannot take the address of a TARGET_MEM_REF. > > Richard. I found I should use tree_mem_ref_addr. Thanks for help! Ilya > >> Thanks >> Ilya
Re: Add corollary extension
On Thu, Jun 28, 2012 at 12:39:16PM -0700, Rick Hodgin wrote: > I've thought more about the syntax, and I see this making more sense: > bool isSystemOpen[!isSystemClosed]; You've just declared an array of bool, whose size is the expression !isSystemClosed. As developers have already showed you how to achieve what you want in the existing language, you should define an inv_bool class, then write inv_bool isSystemOpen(isSystemClosed); and use the feature to your heart's content. There's a very high bar to accepting a language extension, because developers need to know, to "draft standard" level of detail, how that feature interacts with existing language features, and you can't change the meaning of valid code. Furthermore, the vast engineering effort isn't worth doing if users can achieve the same thing in the standard language, perhaps with slightly different syntax. The previous proposal was for a "self" keyword. But #define self (*this) and you're done.
Online Film
Merhaba, online ve ücretsiz olarak film izlemek isterseniz filmkutum.com her an güncellenen içeriğiyle herzaman hizmetinizde.
Re: GCC and Clang produce undefined references to functions with vague linkage
Richi asked me to also report a gcc bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808 > But that's pervasively true in C++ — the linker has to eliminate duplicates > all the time. Idiomatic C++ code ends up plunking down hundreds, if > not thousands, of inline functions in every single translation unit. This is > already a massive burden for linking C++ programs, particularly in debug > builds. Adding a few extra symbols when the optimizer determines that > it can devirtualize, but declines to inline, is essentially irrelevant. > > In fact, it is particularly unimportant because it's very likely that this > duplicate > will be in the same DSO as the vtable. That means that the first solution > imposes some extra work on the static linker alone (but again, only when > devirtualizing a call to a function we don't want to inline!) while preserving > our ability to reduce work for the dynamic linker (since calls do not rely > on address equality of the function across translation units). The second > solution is an irrevocable guarantee that every symbol mentioned in > a strong vtable *must* be exported to the whole world. > > Also recall that these symbols can already be emitted in arbitrary > other translation units — we cannot change the ABI to say that these > symbols are *only* emitted in the file defining the v-table. I would just like to point out that the ABI could says that they only *need* to be emitted in the file with the vtable, but yes, for a long time it would have to support the symbols showing up in other translation units produce by older compilers. > Finally, both the language standard and the ABI are clearly designed > around an assumption that every translation unit that needs an inline > function will emit it. > > John. Cheers, Rafael
Re: GCC and Clang produce undefined references to functions with vague linkage
On Jun 29, 2012, at 11:40 AM, Rafael Espíndola wrote: >> But that's pervasively true in C++ — the linker has to eliminate duplicates >> all the time. Idiomatic C++ code ends up plunking down hundreds, if >> not thousands, of inline functions in every single translation unit. This is >> already a massive burden for linking C++ programs, particularly in debug >> builds. Adding a few extra symbols when the optimizer determines that >> it can devirtualize, but declines to inline, is essentially irrelevant. >> >> In fact, it is particularly unimportant because it's very likely that this >> duplicate >> will be in the same DSO as the vtable. That means that the first solution >> imposes some extra work on the static linker alone (but again, only when >> devirtualizing a call to a function we don't want to inline!) while >> preserving >> our ability to reduce work for the dynamic linker (since calls do not rely >> on address equality of the function across translation units). The second >> solution is an irrevocable guarantee that every symbol mentioned in >> a strong vtable *must* be exported to the whole world. >> >> Also recall that these symbols can already be emitted in arbitrary >> other translation units — we cannot change the ABI to say that these >> symbols are *only* emitted in the file defining the v-table. > > I would just like to point out that the ABI could says that they only > *need* to be emitted in the file with the vtable, but yes, for a long > time it would have to support the symbols showing up in other > translation units produce by older compilers. There's no "for a long time" here. The ABI does not allow us to emit these symbols with non-coalescing linkage. We're not going to break ABI just because people didn't consider a particular code pattern when they hacked in devirtualization through external v-tables. John.
Re: [testsuite] don't use lto plugin if it doesn't work
On Jun 28, 2012, at 3:19 PM, Alexandre Oliva wrote: > On Jun 28, 2012, Mike Stump wrote: >> The next would be because it would be a speed hit to re-check at >> runtime the qualities of the linker and do something different. > > But then, our testsuite *does* re-check at runtime, but without my > patch, we're not using completely the result of the test. Hum, we're not making progress in the conversation. Let me reboot it. First, let get to the heart of the matter. That is the behavior of compiler. Do you think it works perfectly and needs no changing in this area, or if not, what changes do you want? My take was, the compiler should not try and use the plugin that won't work, and that this should be a static config bit built up from the usual config time methods for the host system. Do you agree, if not why, and what is your take?
Re: GCC and Clang produce undefined references to functions with vague linkage
> There's no "for a long time" here. The ABI does not allow us to emit these > symbols with non-coalescing linkage. We're not going to break ABI > just because people didn't consider a particular code pattern when they > hacked in devirtualization through external v-tables. If we take "the ABI" to mean compatibility with released versions of the compilers, then it *is* broken, as released compilers assume behavior that is not guaranteed by the ABI (the document). It is not possible to avoid all incompatibilities. To avoid most we would have to * Say that the symbol must be exported by the file that exports the vtable. Not doing so causes incompatibilities with files compiled by gcc version 4.6 and 4.7, open source clang versions 2.9, 3.0, 3.1 and Apple's releases 318.0.58 and 421-10.48 (those are the ones I have on my laptop). * Say that the symbol must remain mergeable so that current files still work, which on OS X requires it to be weak. In other words, we have to take the worse of both options. The only thing that would still be broken (in released versions) are libraries built with gcc's LTO, but hopefully changing that is the option with the least impact on the users. > John. Cheers, Rafael
Re: Are we fast yet?
On Thu, 28 Jun 2012, Dimitrios Apostolou wrote: > you may have thought I'd disappeared but here I am, after weeks of working on > a small project of mine. What started as a very small hack for visualising > callgrind's profiles is now an -experimental still- website, a GCC version of > mozilla's "arewefastyet.com". For now you can see it at: > > http://teras-ics.mooo.com:8003/ Love the brief what-was-in-that-making/breaking-revision analysis! Probably won't use it for anything deeper or more detailed. I guess people who can change the figures would similarly follow-up by their own analysis, but I may be biased. I also appreciate that you put up the callgrind analysis and svg code, not that I'm considering using it, but anyway. brgds, H-P
Re: LTO inlining of transactional builtins
In theory we should be able to do multiple "LTO" passes. So we could do
a.c a.o
... -> -> WPA -> LTRANS and TM lowering -> WPA -> LTRANS and RTL
expand
x.c x.o
Thus, after a first wave of WPA and LTRANS in non-lowered TM we can,
after the TM lowering in the first LTRANS phase write out LTO bytecode again
and re-start WPA from that. It might get tricky with respect to how we drive
the compile via the linker plugin but in theory GCC itself should not care
if the LTO objects that we feed into WPA stage come from early optimizations
or from LTRANS optimizations (well, you have to cut off at a suitable place
before RTL expansion of course).
So - I suppose enhancing the infrastructure for such multiple runs through
WPA / LTRANS would be a nice thing to have anyways and would probably
solve your issue, too.
Richard.
I'm not particularly thrilled by the overhead, but I do agree that this
approach has the potential for being more generic and thorough.
Also, with the double streaming, we could move ipa_tm to a full IPA
pass, and solve this...
foo.c:bar.c
foo () { bar() { ... }
__transaction {
bar();
}
}
...for which we currently do not clone bar on TM.
So unless I hear otherwise (AFAIK rth is also on board with this), I'd
prefer to go this route, but will not be able to start work on it until
I return from vacation 2 weeks after Cauldron.
I'd be delighted to receive tips, feedback, and advice along the way.
I'll be giving away beers at Cauldron for anyone who wants to help,
though at this point, I think I owe Richi a few kegs. :)
Aldy
gcc-4.6-20120629 is now available
Snapshot gcc-4.6-20120629 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120629/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 189085 You'll find: gcc-4.6-20120629.tar.bz2 Complete GCC MD5=5771c7dc3bc87dcbd561d8ada96452cb SHA1=08a361bda723b4be31f7db8e5c9c2f1b8a027447 Diffs from 4.6-20120622 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC and Clang produce undefined references to functions with vague linkage
On Jun 29, 2012, at 2:23 PM, Rafael Espíndola wrote: >> There's no "for a long time" here. The ABI does not allow us to emit these >> symbols with non-coalescing linkage. We're not going to break ABI >> just because people didn't consider a particular code pattern when they >> hacked in devirtualization through external v-tables. > > If we take "the ABI" to mean compatibility with released versions of > the compilers, then it *is* broken, as released compilers assume > behavior that is not guaranteed by the ABI (the document). It is not > possible to avoid all incompatibilities. By "breaking the ABI", I mean changing the required output of compilers that conform to it. It is understood that compilers will occasionally have bugs that cause them to not conform; as a somewhat trivial example, both gcc and clang have mis-mangled symbols in the past. Typically, compiler implementers choose to fix those bugs, rather than trying to codify them by modifying the ABI. Again, the ABI clearly expects that every object file that references an inline function will define it, and do so with coalescing linkage. That is an invaluable invariant. Our proposed visibility-modifying optimization is hardly the only reasonable consumer of it. As with most compatibility problems, it would be better if no compiler had ever strayed from the One True Path, and yet it's happened. Given that the chance of actual incompatibility in practice is low — as I believe I've argued several times — I continue to believe that the proper response is to just fix the bug, rather than imposing a novel and permanent constraint on ourselves out of unmotivated worry. Also, as a point of order: when you said you were going to make a proposal to the GCC list, I was under the impression that we'd reached some level of consensus. John.
