-fno-tree-cselim not working?
With yesterday's SVN sources, the following source produces the same
result with -ftree-cselim and -fno-tree-cselim on x86:
#include
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
static int acquires_count = 0;
int
trylock()
{
int res;
res = pthread_mutex_trylock(&mutex);
if (res == 0)
++acquires_count;
return res;
}
trylock:
subl$12, %esp
movl$mutex, (%esp)
callpthread_mutex_trylock
movlacquires_count, %edx
cmpl$1, %eax
adcl$0, %edx
movl%edx, acquires_count
addl$12, %esp
ret
Shouldn't the conditional store be preserved when -fno-tree-cselim is
set?
Sam
--
Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/
Re: -fno-tree-cselim not working?
On 10/25/07, Samuel Tardieu <[EMAIL PROTECTED]> wrote: > With yesterday's SVN sources, the following source produces the same > result with -ftree-cselim and -fno-tree-cselim on x86: Because another patch does this optimization, the RTL if conversion pass which implements conditional moves. -- Pinski
Re: -fno-tree-cselim not working?
On 25/10, Andrew Pinski wrote: | On 10/25/07, Samuel Tardieu <[EMAIL PROTECTED]> wrote: | > With yesterday's SVN sources, the following source produces the same | > result with -ftree-cselim and -fno-tree-cselim on x86: | | Because another patch does this optimization, the RTL if conversion | pass which implements conditional moves. Is there any way to turn it off (other than using -O0) (see current thread-safeness discussion)? It looks like this particular optimization is duplicated, as the comment in tree-ssa-phiopt.c exactly describes what happens here: /* This pass tries to transform conditional stores into unconditional ones, enabling further simplifications with the simpler then and else blocks. In particular it replaces this: bb0: if (cond) goto bb2; else goto bb1; bb1: *p = RHS bb2: with bb0: if (cond) goto bb1; else goto bb2; bb1: condtmp' = *p; bb2: condtmp = PHI *p = condtmp This transformation can only be done under several constraints, documented below. */
Decimal question and sqrt in math.h
I use Gentoo Linux, Gcc 4.1.1 and Intel Celeron processor.
I compiled this file:
#include
#include
int main()
{
printf("\n %1.55f \n", sqrt(3.999));
return 0;
}
I get 1.999777955395074968691915273666381835 9375000
If you add one more 9 to sqrt you get 2.
#include
#include
int main()
{
printf("\n %1.55f \n", sqrt(3.));
return 0;
}
Result: 2
Why does this return 2 ??
Miha Svalina
Re: -fno-tree-cselim not working?
On 10/25/07, Samuel Tardieu <[EMAIL PROTECTED]> wrote: > Is there any way to turn it off (other than using -O0) (see current > thread-safeness discussion)? -fno-if-conversion -fno-if-conversion2 > > It looks like this particular optimization is duplicated, as the comment > in tree-ssa-phiopt.c exactly describes what happens here: Yes it is duplicated. And it is not a new problem, if conversion has been with GCC since the 2.95 days so I don't understand why it is only being brought up now (except threading programming is becoming more popular). And really I still say these are thread safe, just not the way you think of them being thread safe. -- Pinski
Re: Decimal question and sqrt in math.h
On 10/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Why does this return 2 ?? You should read: http://www.validlab.com/goldberg/paper.pdf which is linked on http://gcc.gnu.org/readings.html . Thanks, Andrew Pinski
Re: Removal of pre-ISO C++ items from include/backwards
Joe Buck <[EMAIL PROTECTED]> writes: | On Wed, Oct 24, 2007 at 05:32:12PM -0700, Mark Mitchell wrote: | > Richard Guenther wrote: | > > 2007-10-18 Benjamin Kosnik <[EMAIL PROTECTED]> | > > | > > Removal of pre-ISO C++ items from include/backwards. | > > * include/Makefile.am (backward_headers): Remove all but | > > strstream, | > > backward_warning.h. | > > * include/Makefile.in: Regenerate. | > > * include/backward/new.h: Remove. | > > * include/backward/iterator.h: Same. | > > ... | > > | > > | > > I don't think this is a great idea. What is the benefit of this apart | > > from causing endless pain? (SPEC2000 eon now fails to build for example) | > | > I would like to ask the same question. | > | > Once an API is present in the C++ runtime library, my feeling is that it | > should be there forever, for very long definitions of forever. I don't | > even think we should move headers; for example, it seems better to | > create a new include directory to put new functionality into than to | > move old headers out of existing include directories. | | Agreed. We shouldn't be making gratuitous changes that just complicate | the lives of those who have to build thousands of free software packages | into GNU/Linux or BSD distributions. Extra headers in backward don't | hurt anything, while taking them out does. I agree. 'deprecated' in the standard does not carry much semantics weight, unless the feature is also removed. But, even then we would have to worry about existing codes that were written using the feature. That is one of the reasons why I'm unsympathetic to proposals before the committee to `deprecate' things. -- Gaby
Re: Decimal question and sqrt in math.h
[EMAIL PROTECTED] wrote:
>
> #include
> #include
>
> int main()
> {
> printf("\n %1.55f \n", sqrt(3.));
> return 0;
> }
>
> Result: 2
>
> Why does this return 2 ??
If you meant to use long double, you should have so specified. Decimal
digits beyond 17 aren't significant in conversion to IEEE 64-bit double.
Some of the properties of the floating point data types are shown in
.
Just as a matter of curiosity, how did you get this message marked as spam?
alias and pointers analysis
Hi, once i have been reading lots of documents about SSA computing. I have a few questions, conceptual ones, that stop me understanding the whole goal of the method. Here i go: * Why alias analysis? I mean, the pointers could be versioned like the others vars. (I'm not saying it's not usefull, i mean i don't understand the alias analisys goals) * What is the significance of Use-Def chains? How are they construct? Are related to VDEF/DEF and VUSE/USE? Note: i'm beginning i'd need something basic, conceptual docs. thanks and c u all
Re: -fno-tree-cselim not working?
"Andrew Pinski" <[EMAIL PROTECTED]> writes: > And it is not a new problem, if conversion has > been with GCC since the 2.95 days so I don't understand why it is only > being brought up now (except threading programming is becoming more > popular). And really I still say these are thread safe, just not the > way you think of them being thread safe. Misunderstanding of what code is thread safe is common, because the abstract memory model in the language standard does not conform to people's näive assumptions about memory accesses. People assume that memory will be accessed more or less as described in the code, but of course the standard has no such requirement. The standard permits just about anything, including, e.g., promoting globals to register variables. The standard gives exactly one out, which is that volatile requires the compiler to implement the näive memory model. Unfortunately that is not what most people want either. Until the C++0x memory model is implemented, people writing code that has to be thread safe need to use memory barriers around reads and writes to shared data. There is no standard approved way to implement a memory barrier, but acquiring or releasing a mutex should do it. And even memory barriers do not suffice if you are accessing bitfields, or, in general, fields in a struct which are smaller than int. This can break if you want to use different mutexes to protect different fields in the struct. The compiler may modify such fields using a read-partial modify-write cycle which will silently change adjacent fields in the struct. There are lots of problems with multi-threaded C/C++ code and few good solutions. It would be nice to figure out how gcc could improve matters. The answer is not going to be to disable certain optimizations. But perhaps we should implement the draft C++0x memory model for both C and C++. Ian
Re: cannot pass objects of non-POD type
On Wed, Oct 24, 2007 at 03:06:42PM -0700, Joe Buck wrote: > On Wed, Oct 24, 2007 at 01:37:25PM -0700, Andrew Pinski wrote: > > On 10/24/07, Jack Lloyd <[EMAIL PROTECTED]> wrote: > > > Is there a reason it's not just an error, then? (As a user) I don't > > > see the point of something being a warning when the compiled code is > > > intentionally set up to crash. > > > > Because the C++ standard (and the C standard) has mentioned that you > > cannot diagnostic an undefined runtime behavior. So the code is valid > > semantically but undefined at runtime. > > But the way that the object is passed in this case, and the stack layout, > are completely defined on any platform that obeys the cross-platform API > you will find at > > http://www.codesourcery.com/cxx-abi/ > > and this definition specifies that everything will look exactly the same > as if it were a POD with the same members declared in the same order. I don't think that's true. I believe the non-POD must be passed in memory, but GCC would be permitted to pass the POD in a register if it preferred. The layout is defined by the C++ ABI, but not the argument passing conventions. -- Daniel Jacobowitz CodeSourcery
Re: Removal of pre-ISO C++ items from include/backwards
On Thu, 2007-10-25 at 07:59 -0500, Gabriel Dos Reis wrote: > 'deprecated' in the standard does not carry much semantics weight, > unless the feature is also removed. But, even then we would have to > worry about existing codes that were written using the feature. That > is one of the reasons why I'm unsympathetic to proposals before the > committee to `deprecate' things. I think this is the wrong idea. Deprecated does carry a lot of weight. It allows a new compiler without a legacy to elide the feature and specify it is ISO compliant 'minus' the deprecated features, which is quite different from 'non-compliant'. In particular, for a product like gcc it means a switch like --no-deprecated-features can be added and then used by a client without risking 'all bets are off since the compiler isn't conforming'. Note I'm entirely agreeing with your the first line I quote from you above, but questioning lack of sympathy with proposals to deprecate features considered undesirable. A shop writing new code may tell programmers not to use deprecated features because the committee of 'experts' thinks they're undesirable, and enforce that with a switch, thereby attempting to enforce an improvement of code quality, and i would not laugh at such a policy, so I think 'deprecating' features really can have positive impacts. In fact if I may cite a REAL example from my own code in the last few days .. gcc 4.2 is now complaining about 'conversion of string literals to char* is deprecated'. Thanks you gcc! I have fixed all the examples. I believe my code quality is now better. By gcc 5.0 I expect and hope this deprecated feature will cause a hard error unless I specify a --allow-deprecated-features type of switch. Deprecation is a migration path -- isn't that what C++ is all about with respect to C? -- John Skaller Felix, successor to C++: http://felix.sf.net
Re: Removal of pre-ISO C++ items from include/backwards
skaller wrote: I think this is the wrong idea. Deprecated does carry a lot of weight. It allows a new compiler without a legacy to elide the feature and specify it is ISO compliant 'minus' the deprecated features, which is quite different from 'non-compliant'. are you sure? I thought conformance required deprecated features to be allowed In particular, for a product like gcc it means a switch like --no-deprecated-features can be added and then used by a client without risking 'all bets are off since the compiler isn't conforming'. You can always add any switch to do anything, the standard only requires that there be a mode that is conformant.
Re: cannot pass objects of non-POD type
On Thu, Oct 25, 2007 at 11:25:52AM -0400, Daniel Jacobowitz wrote: > On Wed, Oct 24, 2007 at 03:06:42PM -0700, Joe Buck wrote: > > But the way that the object is passed in this case, and the stack layout, > > are completely defined on any platform that obeys the cross-platform API > > you will find at > > > > http://www.codesourcery.com/cxx-abi/ > > > > and this definition specifies that everything will look exactly the same > > as if it were a POD with the same members declared in the same order. > > I don't think that's true. I believe the non-POD must be passed in > memory, but GCC would be permitted to pass the POD in a register if it > preferred. The layout is defined by the C++ ABI, but not the argument > passing conventions. One of the purposes of the C++ ABI is to allow different compilers to interoperate. The freedom you describe would prevent gcc-compiled code from behaving correctly with icc-compiled code, for example. So yes, argument passing conventions are part of the ABI. Now, in this case there is an "out": a compiler developer can argue that passing a non-pod to a variadic function isn't defined, so the ABI doesn't matter.
Re: -fno-tree-cselim not working?
Ian Lance Taylor writes: > perhaps we should implement the draft C++0x memory model for both C > and C++. Yes. I'm sure that's the right answer, given the way that if-conversion breaks simple code such as > res = pthread_mutex_trylock(&mutex); > if (res == 0) > ++acquires_count; Andrew.
Re: -fno-tree-cselim not working?
Ian Lance Taylor <[EMAIL PROTECTED]> writes: > It would be nice to figure out how gcc could improve matters. The > answer is not going to be to disable certain optimizations. It's just very questionable this particular transformation is a optimization at all. Turning a shared cache line into an exclusive one can be very expensive even on small MP systems. Also it increases traffic on the bus even on uniprocessor systems. For me it looks more like a mistuned optimization: if conversion is useful for values in registers; but questionable for arbitary memory stores that are not guaranteed to be in L1. The worst memory overhead will likely swamp what ever pipeline advantages you can get from not jumping. Or rather if it's done for stores it needs to guarantee cancel the store in the not taken case (that is possible even on x86 by redirecting the store using cmov to a temporary on the stack which is likely in L1) I guess that code just needs to cooperate better with the register allocator? -Andi
Re: Removal of pre-ISO C++ items from include/backwards
On Thu, 2007-10-25 at 11:37 -0400, Robert Dewar wrote: > skaller wrote: > > > I think this is the wrong idea. Deprecated does carry a lot > > of weight. It allows a new compiler without a legacy > > to elide the feature and specify it is ISO compliant > > 'minus' the deprecated features, which is quite different > > from 'non-compliant'. > > are you sure? I thought conformance required deprecated features > to be allowed yes, it does, but the point is, you can say 'conforms except deprecated features are removed' in one line. A standard is a very long winded document with a single practical purpose -- the ability to say "ISO C++" in two words and mean 1000 pages by it. It has no other semantic function than saving paper :) This makes it very easy for people to make purchasing or usage choices (instead of having to read 1000 pages of specifications for every product). So a list of deprecated features has the purpose of allowing one to say "ISO C++ minus deprecations" and expect the resulting compiler is still a good one to use, particularly if you can convert your compiler from "ISO C++" to "ISO C++--" with a single switch. You can view this as a parametrized version is C++, and so the compiler still judged conformant to a closely related standard. -- John Skaller Felix, successor to C++: http://felix.sf.net
Re: $RANLIB not passed to libiberty
On Thu, Sep 27, 2007 at 10:34:50AM +0200, Paolo Bonzini wrote: > Rask Ingemann Lambertsen wrote: > > I'm having a look at building GCC with OpenWatcom to reduce build > >times. There seems to be something wrong with the build machinery: > > Can you try this patch? RANLIB_FOR_BUILD was defined nowhere, hence it > was passed as empty to configure and detected (incorrectly) to be > "ranlib" instead of "owranlib". > > (It might even be that it worked with Cygnus configure, and stopped > working after autoconfiscation). Is there a way of using a different ranlib for building the stage1 compiler than for stage2 and stage3 (other than using a combined tree)? -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
Re: -fno-tree-cselim not working?
Andi Kleen <[EMAIL PROTECTED]> writes: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > > It would be nice to figure out how gcc could improve matters. The > > answer is not going to be to disable certain optimizations. > > It's just very questionable this particular transformation is a > optimization at all. Turning a shared cache line into an exclusive one > can be very expensive even on small MP systems. Also it increases > traffic on the bus even on uniprocessor systems. > > For me it looks more like a mistuned optimization: if conversion is useful > for values in registers; but questionable for arbitary memory stores that are > not > guaranteed to be in L1. The worst memory overhead will likely swamp what > ever pipeline advantages you can get from not jumping. > > Or rather if it's done for stores it needs to guarantee cancel the > store in the not taken case (that is possible even on x86 by > redirecting the store using cmov to a temporary on the stack which > is likely in L1) > > I guess that code just needs to cooperate better with the register allocator? > The current code (noce_try_addcc in ifcvt.c) does not even consider whether this conversion is being done for a store or not. I agree that that is most likely an optimization bug that this conversion is being for a store to a variable which is not on the stack. This should be filed as an optimization bug (not a correctness bug) in gcc bugzilla. (This is of course orthogonal to the main issue of what gcc can do to help code correctness.) Ian
Re: cannot pass objects of non-POD type
On Thu, Oct 25, 2007 at 08:44:26AM -0700, Joe Buck wrote: > One of the purposes of the C++ ABI is to allow different compilers to > interoperate. The freedom you describe would prevent gcc-compiled > code from behaving correctly with icc-compiled code, for example. > So yes, argument passing conventions are part of the ABI. You're using the term "ABI" too broadly - more than one applies. The C++ ABI only covers C++ specific additions on top of existing platform-specific ABIs. It's not a question of freedom. In any case, it seems that I was wrong. Non-PODs still get passed in registers if the layout-equivalent POD would, unless there is a non-trivial copy constructor or destructor; there are non-PODs without those. Sorry for the confusion. -- Daniel Jacobowitz CodeSourcery
Re: -fno-tree-cselim not working?
> I agree that that is most likely an optimization bug that this > conversion is being for a store to a variable which is not on the > stack. Even on the stack it might not be good -- e.g. if someone puts an 10MB array on the stack and does something with it you don't want such random stores inside it because they could be potentially an additional cache miss. -Andi
Re: $RANLIB not passed to libiberty
Is there a way of using a different ranlib for building the stage1 compiler than for stage2 and stage3 (other than using a combined tree)? I don't remember one. Remember though that when using a combined tree you can drop in only the binutils directory, and use the system gas/ld. Paolo
Re: Removal of pre-ISO C++ items from include/backwards
On Fri, 26 Oct 2007, skaller wrote: | | On Thu, 2007-10-25 at 07:59 -0500, Gabriel Dos Reis wrote: | | > 'deprecated' in the standard does not carry much semantics weight, | > unless the feature is also removed. But, even then we would have to | > worry about existing codes that were written using the feature. That | > is one of the reasons why I'm unsympathetic to proposals before the | > committee to `deprecate' things. | | I think this is the wrong idea. Deprecated does carry a lot | of weight. It allows a new compiler without a legacy | to elide the feature and specify it is ISO compliant | 'minus' the deprecated features, which is quite different | from 'non-compliant'. Do you know of any of those compilers with user base we can talk to? [...] | Note I'm entirely agreeing with your the first line I quote | from you above, but questioning lack of sympathy with proposals | to deprecate features considered undesirable. I'm just being realistic. Code base don't just vanish overnight because the ISO committee voted to deprecate things. I realize the situation might be different in a totally different, imaginary, perfect world. -- Gaby
Re: Removal of pre-ISO C++ items from include/backwards
On Fri, 26 Oct 2007, skaller wrote: | | On Thu, 2007-10-25 at 11:37 -0400, Robert Dewar wrote: | > skaller wrote: | > | > > I think this is the wrong idea. Deprecated does carry a lot | > > of weight. It allows a new compiler without a legacy | > > to elide the feature and specify it is ISO compliant | > > 'minus' the deprecated features, which is quite different | > > from 'non-compliant'. | > | > are you sure? I thought conformance required deprecated features | > to be allowed Deprecated features are still part of the language. A conforming compiler can't reject a feature solely based on the fact the the feature is deprecated. More importantly (i.e. the subject that fired up this discussion), existing codes written in conformance to an existing ISO standard won't just vanish because the next standard *may* deprecate some supported features. | yes, it does, but the point is, you can say 'conforms | except deprecated features are removed' in one line. You can also conform modulo bugs in the compiler. One just needs to define what counts as bugs. -- Gaby
Re: Removal of pre-ISO C++ items from include/backwards
On Thu, 2007-10-25 at 12:40 -0500, Gabriel Dos Reis wrote: > | I think this is the wrong idea. Deprecated does carry a lot > | of weight. It allows a new compiler without a legacy > | to elide the feature and specify it is ISO compliant > | 'minus' the deprecated features, which is quite different > | from 'non-compliant'. > > Do you know of any of those compilers with user base we can talk to? In approximation of the feature, yes: gcc! It has quite a number of switches for controlling pedantry, standards conformance, mapping errors to warnings etc. > [...] > > | Note I'm entirely agreeing with your the first line I quote > | from you above, but questioning lack of sympathy with proposals > | to deprecate features considered undesirable. > > I'm just being realistic. Code base don't just vanish overnight > because the ISO committee voted to deprecate things. I realize the > situation might be different in a totally different, imaginary, > perfect world. I agree, I wasn't suggesting removing support for deprecated features overnight: rather than you don't view deprecation unfavourably, precisely because it *doesn't* imply uncontrolled feature removal. Contrarily my point is that they can be enabled or disabled with a small number of comprehensible switches. gcc already does this kind of thing and it is good, although the exact features sets controlled by switch combinations are sometimes a bit hard to understand. -- John Skaller Felix, successor to C++: http://felix.sf.net
Re: Removal of pre-ISO C++ items from include/backwards
On Fri, 26 Oct 2007, skaller wrote: | | On Thu, 2007-10-25 at 12:40 -0500, Gabriel Dos Reis wrote: | | > | I think this is the wrong idea. Deprecated does carry a lot | > | of weight. It allows a new compiler without a legacy | > | to elide the feature and specify it is ISO compliant | > | 'minus' the deprecated features, which is quite different | > | from 'non-compliant'. | > | > Do you know of any of those compilers with user base we can talk to? | | In approximation of the feature, yes: gcc! I asking for an *existing* compiler, not a hypothetical one we have not released yet -- therefore we don't know what is in it. -- Gaby
Re: -fno-tree-cselim not working?
* Andrew Pinski: > Yes it is duplicated. And it is not a new problem, if conversion has > been with GCC since the 2.95 days so I don't understand why it is only > being brought up now (except threading programming is becoming more > popular). The cmov instruction is post-Pentium material, so it's only been stressed relatively recently by the amd64 target.
Re: Removal of pre-ISO C++ items from include/backwards
On Thu, 2007-10-25 at 13:41 -0500, Gabriel Dos Reis wrote: > On Fri, 26 Oct 2007, skaller wrote: > > | > | On Thu, 2007-10-25 at 12:40 -0500, Gabriel Dos Reis wrote: > | > | > | I think this is the wrong idea. Deprecated does carry a lot > | > | of weight. It allows a new compiler without a legacy > | > | to elide the feature and specify it is ISO compliant > | > | 'minus' the deprecated features, which is quite different > | > | from 'non-compliant'. > | > > | > Do you know of any of those compilers with user base we can talk to? > | > | In approximation of the feature, yes: gcc! > > I asking for an *existing* compiler, not a hypothetical one we have > not released yet -- therefore we don't know what is in it. Yes, gcc at it is right now has switches which control 'something like' what we're talking about. True, not exactly a list of deprecated features, I don't know of a compiler that does exactly that, sorry. I guess you really want to know exactly that since you might actually implement it if there were a positive response from users of some other compiler. I would actually like "strict ISO conformance without any deprecated features generates a hard error EXCEPT for X Y and Z" so I could determine easily exactly where my code doesn't conform ( by adding X, Y, and Z until the compiler stopped rejecting the program). -- John Skaller Felix, successor to C++: http://felix.sf.net
Any Ada changes for GCC 4.3?
I've noticed that the GCC changes pages (http://gcc.gnu.org/gcc-4.2/changes.html and http://gcc.gnu.org/gcc-4.3/changes.html ) are not usually updated for Ada and/or GNAT. It anyone designated as a maintainer for this? -- Britt
Re: Removal of pre-ISO C++ items from include/backwards
On Thu, 25 Oct 2007, Gabriel Dos Reis wrote: > 'deprecated' in the standard does not carry much semantics weight, > unless the feature is also removed. But, even then we would have to > worry about existing codes that were written using the feature. I have to admit I am also surprised about the use of "deprecated" in the context of removing these headers. My previous understanding was that we'd announce deprecation (and issue warnings) for at least one major release before actually removing the feature in a following one. Gerald
Re: Removal of pre-ISO C++ items from include/backwards
On 10/25/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > I have to admit I am also surprised about the use of "deprecated" in > the context of removing these headers. My previous understanding was > that we'd announce deprecation (and issue warnings) for at least one > major release before actually removing the feature in a following one. Well technically these headers have been deprecated since at least 3.2 (maybe even back in 3.0) with them producing a warning. So I don't know if we should move them or not but we have followed our own rules here. Thanks, Andrew Pinski
Re: Removal of pre-ISO C++ items from include/backwards
On Thu, 25 Oct 2007, Andrew Pinski wrote: > Well technically these headers have been deprecated since at least 3.2 > (maybe even back in 3.0) with them producing a warning. So I don't > know if we should move them or not but we have followed our own rules > here. Sorry, I misread the Subject: what disappeared under my back, without any warning nor deprecation period, actually was ext/hash_map and friends. Can we get these back, please? Gerald
Re: Removal of pre-ISO C++ items from include/backwards
Gerald Pfeifer wrote: > On Thu, 25 Oct 2007, Andrew Pinski wrote: >> Well technically these headers have been deprecated since at least 3.2 >> (maybe even back in 3.0) with them producing a warning. So I don't >> know if we should move them or not but we have followed our own rules >> here. > > Sorry, I misread the Subject: what disappeared under my back, without any > warning nor deprecation period, actually was ext/hash_map and friends. Whether or not we've been through a deprecation cycle, I still think there should be a very high bar for removing APIs from the library. My two cents, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Removal of pre-ISO C++ items from include/backwards
On 25/10/2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > On Thu, 25 Oct 2007, Andrew Pinski wrote: > > Well technically these headers have been deprecated since at least 3.2 > > (maybe even back in 3.0) with them producing a warning. So I don't > > know if we should move them or not but we have followed our own rules > > here. > > Sorry, I misread the Subject: what disappeared under my back, without any > warning nor deprecation period, actually was ext/hash_map and friends. http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#5_4 The non-standard hash containers have been deprecated by moving them to the backward directory. The headers that were completely removed were iostream.h etc. (note the pre-standard .h extension) which had been in backward for years and gave a warning without -Wno-deprecated. The plan is to also move auto_ptr and the old bind1st/bind2nd function binders to backward, if/when they are deprecated in C++0x, which would give them the same status as (deprecated in C++98) and the SGI hash containers (never standardised, now deprecated in libstdc++): http://gcc.gnu.org/ml/libstdc++/2007-10/msg00090.html Jon
Re: Removal of pre-ISO C++ items from include/backwards
On Thu, 25 Oct 2007, Jonathan Wakely wrote: | On 25/10/2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: | > On Thu, 25 Oct 2007, Andrew Pinski wrote: | > > Well technically these headers have been deprecated since at least 3.2 | > > (maybe even back in 3.0) with them producing a warning. So I don't | > > know if we should move them or not but we have followed our own rules | > > here. | > | > Sorry, I misread the Subject: what disappeared under my back, without any | > warning nor deprecation period, actually was ext/hash_map and friends. | | http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#5_4 | The non-standard hash containers have been deprecated by moving them | to the backward directory. | | The headers that were completely removed were iostream.h etc. (note | the pre-standard .h extension) which had been in backward for years | and gave a warning without -Wno-deprecated. The .h headers are not part of the C++ standards. I don't think I'm disputing that. My argument was more specific than that. libstdc++ still supports . However, the .h headers did provide an API that I don't think we should remove. No matter how long we have been emitting warnings. The reason is they don't pose any signofocant maintainance problem, they don't interferre with our supplying a standard conforming compiler. People interested in compiling codes that don't rely on deprecated stuff know how to get that. However, removing them only make users disappointed. -- Gaby Annex D (normative) Compatibility features 1 This clause describes features of the C++ Standard that are specified for compatibility with existing implementations. 2 These are deprecated features, where deprecated is defined as: Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions.
Re: Removal of pre-ISO C++ items from include/backwards
On Thu, Oct 25, 2007 at 02:48:09PM -0700, Mark Mitchell wrote: > Gerald Pfeifer wrote: > > On Thu, 25 Oct 2007, Andrew Pinski wrote: > >> Well technically these headers have been deprecated since at least 3.2 > >> (maybe even back in 3.0) with them producing a warning. So I don't > >> know if we should move them or not but we have followed our own rules > >> here. > > > > Sorry, I misread the Subject: what disappeared under my back, without any > > warning nor deprecation period, actually was ext/hash_map and friends. > > Whether or not we've been through a deprecation cycle, I still think > there should be a very high bar for removing APIs from the library. And moving a header from ext to backward means that programs will not compile. "ext" means "extension", so we already are giving a warning that a feature is non-standard. People that put out distributions are rightly irritated when we pull stuff like this. It's not even good enough to change "ext" to "backward", now you need an autoconf test to find the fine header, so your program compiles with both older and newer gcc's. But they should be using the new unordered containers, you say. But we already tell people that they shouldn't count on any stability in tr1, and maybe later you'll be moving the headers from tr1 to the top level when the committee fully blesses the new containers. Follow the bouncing headers, and practice your autoconf skills.
Re: alias and pointers analysis
On 10/25/07, Fran Baena <[EMAIL PROTECTED]> wrote:
> * Why alias analysis? I mean, the pointers could be versioned like the
> others vars. (I'm not saying it's not usefull, i mean i don't
> understand the alias analisys goals)
SSA names of pointers are also pointers, when points-to sets are
computed for SSA names, what you get is all the symbols that the
particular SSA name has been found to point to. Eg,
if (...)
p_1 = &a;
else
p_2 = &b;
endif
p_3 = phi (p_1, p_2)
points-to (p_1) = { a }
points-to (p_2) = { b }
points-to (p_3) = { a b }
> * What is the significance of Use-Def chains? How are they construct?
> Are related to VDEF/DEF and VUSE/USE?
On GIMPLE they are built with the VDEF/VUSE operators. The argument
of a VUSE/VDEF operator links to the VDEF operator that created the
argument. In RTL, the chains are maintained using the DF data
structures.
> Note: i'm beginning i'd need something basic, conceptual docs.
I suggest the tutorials and presentations in the Getting Started
section of the wiki (http://gcc.gnu.org/wiki/GettingStarted). Also,
some compiler books that may help are listed in that section as well
(IIRC).
problem with iv folding
target: m32c-elf
test case: cc1 -O3 -mcpu=m32c dj.c
void
cyg_hal_plf_serial_write(void* __ch_data, const unsigned char* __buf,
unsigned long __len)
{
while(__len-- > 0)
cyg_hal_plf_serial_putc(__ch_data, *__buf++);
}
We get here, and fold_binary returns NULL:
13560 tem = fold_binary (code, type, op0, op1);
13561 if (!tem)
13562 tem = build2_stat (code, type, op0, op1 PASS_MEM_STAT);
so it calls build2_stat, but fails at this assert:
3108 if ((code == MINUS_EXPR || code == PLUS_EXPR || code == MULT_EXPR)
3109 && arg0 && arg1 && tt && POINTER_TYPE_P (tt))
3110gcc_assert (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) ==
INTEGER_CST);
traceback, tt, and ops follow. Why is this going wrong? Note that
m32c pointers are PSImode (24 bits), int/size_t are 16 bits, and long
is 32 bits.
#1 0x08827a01 in build2_stat (code=PLUS_EXPR, tt=0xb7f5d2f4, arg0=0xb7f5f6e0,
arg1=0xb7f61c30)
at ../../gcc/gcc/tree.c:3110
#2 0x08387ccb in fold_build2_stat (code=PLUS_EXPR, type=0xb7f5d2f4,
op0=0xb7f5f6e0,
op1=0xb7f61c30) at ../../gcc/gcc/fold-const.c:13562
#3 0x0834d43b in fold_binary (code=PLUS_EXPR, type=0xb7f5d2f4, op0=0xb7f61c30,
op1=0xb7f5f6e0)
at ../../gcc/gcc/fold-const.c:9555
#4 0x08387ca2 in fold_build2_stat (code=PLUS_EXPR, type=0xb7f5d2f4,
op0=0xb7f61c30,
op1=0xb7f5f6e0) at ../../gcc/gcc/fold-const.c:13560
#5 0x086d3bc2 in create_mem_ref (bsi=0xbfcc617c, type=0xb7f5d288,
addr=0xbfcc6188)
at ../../gcc/gcc/tree-ssa-address.c:641
#6 0x0874bf9b in rewrite_use_address (data=0xbfcc62b8, use=0x8e76510,
cand=0x8ecd640)
at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5089
#7 0x0874c29f in rewrite_use (data=0xbfcc62b8, use=0x8e76510, cand=0x8ecd640)
at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5148
#8 0x0874c350 in rewrite_uses (data=0xbfcc62b8) at
../../gcc/gcc/tree-ssa-loop-ivopts.c:5177
#9 0x0874ccb4 in tree_ssa_iv_optimize_loop (data=0xbfcc62b8, loop=0xb7f6833c)
at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5347
#10 0x0874cd4d in tree_ssa_iv_optimize () at
../../gcc/gcc/tree-ssa-loop-ivopts.c:5380
#11 0x08760d74 in tree_ssa_loop_ivopts () at ../../gcc/gcc/tree-ssa-loop.c:549
#12 0x084811e2 in execute_one_pass (pass=0x8c3dfc0) at
../../gcc/gcc/passes.c:1116
#13 0x0848132e in execute_pass_list (pass=0x8c3dfc0) at
../../gcc/gcc/passes.c:1169
#14 0x0848134a in execute_pass_list (pass=0x8c3dc00) at
../../gcc/gcc/passes.c:1170
#15 0x0848134a in execute_pass_list (pass=0x8c3d400) at
../../gcc/gcc/passes.c:1170
#16 0x086810ea in tree_rest_of_compilation (fndecl=0xb7f5bb80) at
../../gcc/gcc/tree-optimize.c:404
#17 0x088a3a19 in cgraph_expand_function (node=0xb7f5bc80) at
../../gcc/gcc/cgraphunit.c:1070
#18 0x088a3c13 in cgraph_expand_all_functions () at
../../gcc/gcc/cgraphunit.c:1139
#19 0x088a422e in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1346
#20 0x08076156 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:8077
#21 0x085f66dd in compile_file () at ../../gcc/gcc/toplev.c:1052
#22 0x085f81b5 in do_compile () at ../../gcc/gcc/toplev.c:2235
#23 0x085f8217 in toplev_main (argc=4, argv=0xbfcc6644) at
../../gcc/gcc/toplev.c:2267
#24 0x08121e7a in main (argc=...) at ../../gcc/gcc/main.c:35
[ gdb ] call debug_tree(tt)
unit size
align 8 symtab 0 alias set -1 canonical type 0xb7f5d288 precision 8 min
max
pointer_to_this >
public unsigned PSI
size
constant invariant 32>
unit size constant invariant 4>
align 8 symtab 0 alias set -1 canonical type 0xb7f5d2f4>
[ gdb ] call debug_tree(arg0)
unit size
align 8 symtab 0 alias set -1 canonical type 0xb7f5d288 precision 8
min max
pointer_to_this >
public unsigned PSI
size
unit size
align 8 symtab 0 alias set -1 canonical type 0xb7f5d2f4>
arg 0 unit size
align 8 symtab 0 alias set -1 canonical type 0xb7efc438 precision
32 min max >
var def_stmt
version 1>>
[ gdb ] call debug_tree(arg1)
unit size
align 8 symtab 0 alias set -1 canonical type 0xb7f5d288 precision 8
min max
pointer_to_this >
public unsigned PSI
size
unit size
align 8 symtab 0 alias set -1 canonical type 0xb7f5d2f4>
volatile visited var def_stmt
version 4
ptr-info 0xb7ef3f90>
Re: Removal of pre-ISO C++ items from include/backwards
On Thu, 2007-10-25 at 22:56 +0100, Jonathan Wakely wrote: > On 25/10/2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > The plan is to also move auto_ptr and the old bind1st/bind2nd function > binders to backward, if/when they are deprecated in C++0x, which would > give them the same status as (deprecated in C++98) This would not be correct. When you deprecate C++2000 features, you should retain them in such a way that a compiler switch such as --std=C++2000 will ensure they're visible in the usual way. This means they don't have the same status as strstream, which was never standardised in non-deprecated status .. > and the > SGI hash containers (never standardised, now deprecated in libstdc++): > http://gcc.gnu.org/ml/libstdc++/2007-10/msg00090.html Nor sgi hash containers, which were never standardised. The compiler is expected to conform to the specified standard and the standard libraries are an intrinsic part of the standard, and IMHO it would be good practice to allow 'strict' conformance to an older standard, whilst still rejecting 'never standardised' features. Might not auto_ptr etc go into a distinct c++2000 directory? [BTW: very glad to hear auto_ptr is leaving is. The LWG made a total mess of my requirement and suggestion, the newer classes finally provide the right thing .. thank you to the new LWG members on that!] -- John Skaller Felix, successor to C++: http://felix.sf.net
Re: Removal of pre-ISO C++ items from include/backwards
On Thu, 2007-10-25 at 15:49 -0700, Joe Buck wrote: > People that put out distributions are rightly irritated when we pull stuff > like this. It's not even good enough to change "ext" to "backward", now > you need an autoconf test to find the fine header, so your program > compiles with both older and newer gcc's. So what? I have a binding for gcc hash containers. I *knew* when I created it what the status was. You can bet it is annoying having to use a configuration time test (I wouldn't touch autoconf with a barge pole..), but that is the price for tracking non-standard but desirable or optional features. I should point out retaining 'old' features can create a significant maintenance burden for gcc developers, and as such reduce the quality of the current and future implementations. -- John Skaller Felix, successor to C++: http://felix.sf.net
Re: Removal of pre-ISO C++ items from include/backwards
On Fri, 26 Oct 2007, skaller wrote: | I should point out retaining 'old' features can create a | significant maintenance burden for gcc developers, In this specific case, what are they? -- Gaby
Re: Removal of pre-ISO C++ items from include/backwards
Gabriel Dos Reis wrote: > On Fri, 26 Oct 2007, skaller wrote: > > | I should point out retaining 'old' features can create a > | significant maintenance burden for gcc developers, > > In this specific case, what are they? The maintenance burden argument always used to remove stuff. I've used it myself plenty of times. Sometimes, it really is too painful. But, sometimes -- and, again, I consider myself guilty -- we've ripped things out under the banner of tidiness and maintenance that imposed a lot of pain on users. This isn't something that one can argue in the abstract. Obviously, there are competing interests. We have to balance our pain as developers against the pain of our users. But, we should be setting the bar high for ourselves because there are many, many users with lots and lots of existing code. Things like "I went through the packages in and they all build" isn't a very good measure; those packages are probably reasonably actively maintained. It's the millions upon millions of lines of existing code in truly big applications out there that's a problem. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Removal of pre-ISO C++ items from include/backwards
On Thu, 2007-10-25 at 20:34 -0500, Gabriel Dos Reis wrote: > On Fri, 26 Oct 2007, skaller wrote: > > | I should point out retaining 'old' features can create a > | significant maintenance burden for gcc developers, > > In this specific case, what are they? You're in a better position than me to determine that. I don't know: it's a generalisation from experience with half a dozen compiler development projects I track. I could guess at things that might cause problems, for example changes in allocation strategy, thread safety, default allocators, etc which would be applied to all the standard containers, would also require work for the hash-ext containers, and, it may even create a conflict between remaining compatible with legacy code and simultaneously using conflicting new allocator technology. This may arise because, lacking standardisation, it is hard to say 'you shouldn't have been doing that it's undefined in the Standard' which you might say for the standard containers. Are the tr1 hash containers exactly the old ext containers? No? Then you just identified one such issue. -- John Skaller Felix, successor to C++: http://felix.sf.net
GCC 4.3.0 Status Report (2007-10-25)
Questions = Are there any major unreviewed patches for 4.3 that I could help to review? Quality Data We're still in Stage 3 for GCC 4.3. As before, I think a reasonable target for creating the release branch is less than 100 open regressions. At present, we're at 184 -- and, of those, 36 are P1. (Based on previous experience, the 33 P3s will probably turn out to be about 2 P1s and 10 P2s. So, 184 is a slight overstatement.) In looking at the P1s, we're not in the situation where most of the P1s are in fact new problems in 4.3 itself. So, these are, for example, ICEs on valid code that users of previous compilers would not have experienced. The good news is that we have more ICEs that wrong-code cases. I'm not sure how to estimate when we might hit the target of 100 regressions, but ... if we each fix a bug a day, we'd been done sometime next week. So, there shouldn't be that far to go... Priority# Change from Last Report --- - --- P1 36 N/A P2 115 N/A P3 33 N/A Previous Report === http://gcc.gnu.org/ml/gcc/2007-09/msg00286.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Removal of pre-ISO C++ items from include/backwards
On Thu, Oct 25, 2007 at 08:17:58PM -0700, Mark Mitchell wrote: > The maintenance burden argument always used to remove stuff. I've used > it myself plenty of times. Sometimes, it really is too painful. But, > sometimes -- and, again, I consider myself guilty -- we've ripped things > out under the banner of tidiness and maintenance that imposed a lot of > pain on users. In this case, it is proposed to move hash_set and hash_map from to . How does that decrease the maintainance burden? It just breaks code.
Re: Removal of pre-ISO C++ items from include/backwards
On Fri, Oct 26, 2007 at 11:06:43AM +1000, skaller wrote: > The compiler is expected to conform to the specified standard > and the standard libraries are an intrinsic part of the > standard, and IMHO it would be good practice to allow > 'strict' conformance to an older standard, whilst still > rejecting 'never standardised' features. The SGI hash containers are very widely used, also highly portable (the STLPort version runs on practically every C++ compiler in existence). It would be a disservice to the users to remove them. They live in indicating that they aren't standard. > Might not auto_ptr etc go into a distinct c++2000 directory? > > [BTW: very glad to hear auto_ptr is leaving is. The LWG made > a total mess of my requirement and suggestion, the newer > classes finally provide the right thing .. thank you to the > new LWG members on that!] Has anyone checked yet on the impact on a Debian distribution of these proposed changes (and even for things that are checked in, they should only be thought of as "proposed" at this point)?
Re: -fno-tree-cselim not working?
David Miller <[EMAIL PROTECTED]> writes:
> From: Ian Lance Taylor <[EMAIL PROTECTED]>
> Date: 25 Oct 2007 21:31:56 -0700
>
> > Samuel Tardieu <[EMAIL PROTECTED]> writes:
> >
> > > int
> > > trylock()
> > > {
> > > int res;
> > >
> > > res = pthread_mutex_trylock(&mutex);
> > > if (res == 0)
> > > ++acquires_count;
> > >
> > > return res;
> > > }
> ...
> > Code like needs to use volatile or explicit memory barriers.
>
> I totally disagree with you, and I think POSIX does too.
>
> Threaded programming is hard enough as it is.
>
> What's the point of the lock if a test on whether we've obtained it or
> not can't be used to conditionalize code execution?
>
> Any write to memory is a globally visible side effect, and even
> ignoring theading issues I bet similar cases can be constructed
> involving signals that behave equally unexpectedly and should not
> require bogus memory barriers or volatile.
>
> I'm not sure people realize the true ramifications of this suggested
> "fix". It is rediculious, by any measure.
Conversely, I'm not sure you realize the true ramifications of any
other fix.
The above code happens to use pthread_mutex_trylock, but there is no
need for that. We could have a global variable "lock_is_held". The
code could look like this:
if (lock_is_held)
++still_holding;
If the earlier code should work in a multi-threaded environment, then
this code should work.
But then we see that there is nothing special about stores. The code
could look like this:
if (lock_is_held)
waiting_count = threads_waiting;
// Do something complicated, but don't call any functions.
if (lock_is_held)
if (threads_waiting > waiting_count)
sched_yield();
If the earlier code should work in a multi-threaded environment, then
this code should work too.
But that means that we can't hoist the load of the global variable
threads_waiting--we have to explicitly load it twice. And remember:
this applies to all code.
That means that if a single function loads a global variable, we must
explicitly load it twice. And that is true even if that single
function is constructed by inlining several other functions.
At this point we are sacrificing significant optimization.
So now we have a choice: make subtle multi-threaded code, which is not
standard conformant, work as the programmer expects, or optimize
programs with global variables and inline functions. There is a lot
more of the latter than the former. And we do provide a way to make
the former work. And the former is not standard conformant while the
latter is.
So I really don't think my position is all that ridiculous.
And I challenge you to find anything in POSIX which says that this
code is supposed to work.
Ian
Re: -fno-tree-cselim not working?
From: Ian Lance Taylor <[EMAIL PROTECTED]>
Date: 25 Oct 2007 21:31:56 -0700
> Samuel Tardieu <[EMAIL PROTECTED]> writes:
>
> > int
> > trylock()
> > {
> > int res;
> >
> > res = pthread_mutex_trylock(&mutex);
> > if (res == 0)
> > ++acquires_count;
> >
> > return res;
> > }
...
> Code like needs to use volatile or explicit memory barriers.
I totally disagree with you, and I think POSIX does too.
Threaded programming is hard enough as it is.
What's the point of the lock if a test on whether we've obtained it or
not can't be used to conditionalize code execution?
Any write to memory is a globally visible side effect, and even
ignoring theading issues I bet similar cases can be constructed
involving signals that behave equally unexpectedly and should not
require bogus memory barriers or volatile.
I'm not sure people realize the true ramifications of this suggested
"fix". It is rediculious, by any measure.
Re: -fno-tree-cselim not working?
Samuel Tardieu <[EMAIL PROTECTED]> writes:
> #include
>
> static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
> static int acquires_count = 0;
>
> int
> trylock()
> {
> int res;
>
> res = pthread_mutex_trylock(&mutex);
> if (res == 0)
> ++acquires_count;
>
> return res;
> }
>
> trylock:
> subl$12, %esp
> movl$mutex, (%esp)
> callpthread_mutex_trylock
> movlacquires_count, %edx
> cmpl$1, %eax
> adcl$0, %edx
> movl%edx, acquires_count
> addl$12, %esp
> ret
By the way, since this is getting play on LKML and no doubt other
places:
This optimization (or pessimization, depending) is not new. gcc 4.1
does the same thing. The code has been in there since at least gcc
3.4, though I didn't build gcc 3.4 to test what happened.
Code like needs to use volatile or explicit memory barriers.
Ian
How widely used are and ?
The thread arguing about this has gone on for a while, so I think it's time to gather some data to answer the question of just how bad it will be if we accept the decision to move ext/hash_set and ext_hash_map into a different directory and to deprecate them. Any of you out there who put out distros or port collections: how many packages in your distro use these classes? You can grep for '# *include *
Re: How widely used are and ?
Joe Buck <[EMAIL PROTECTED]> writes: > The thread arguing about this has gone on for a while, so I think > it's time to gather some data to answer the question of just how bad > it will be if we accept the decision to move ext/hash_set and ext_hash_map > into a different directory and to deprecate them. > > Any of you out there who put out distros or port collections: how many > packages in your distro use these classes? You can grep for > > '# *include * > I'm particularly interested in the "Debian number", since the package > collection is so large. Other information about use of these classes > will be interesting as well. Here is something to look at: http://google.com/codesearch?q=%23include+%3Cext%2Fhash&btnG=Search&hl=en&lr= Ian
Re: -fno-tree-cselim not working?
From: Ian Lance Taylor <[EMAIL PROTECTED]> Date: 25 Oct 2007 21:50:16 -0700 > We could have a global variable "lock_is_held". The > code could look like this: > > if (lock_is_held) > ++still_holding; > > If the earlier code should work in a multi-threaded environment, then > this code should work. I think it should be disallowed for this code to write to memory if lock_is_held is falso too. When you conditionalize moves amongst registers, this is %100 local execution state. But once you start conditionlizing memory references, in particular things that write, you are asking for serious trouble. I realize the desire to use conditional compututations on memory on platforms that can do it, but in these circumstances it is simply unreasonable to do so. At best the compiler can, if it wants, conditionalize the store. This is not a game or some fun theoretical discussion about language semantics. People will be harmed and lose lots of their own personal time debugging these kinds of things if GCC generates code like this. It's unreasonable, regardless of what the standards say. Sometimes the standards are wrong or fail to guide the implementation in these grey areas, and GCC should do what's best for the users in these cases. And I believe that this means to not do conditional computations on memory even though it might be more efficient in some situations.
Re: alias and pointers analysis
On 10/26/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> SSA names of pointers are also pointers, when points-to sets are
> computed for SSA names, what you get is all the symbols that the
> particular SSA name has been found to point to. Eg,
>
> if (...)
> p_1 = &a;
> else
> p_2 = &b;
> endif
> p_3 = phi (p_1, p_2)
>
> points-to (p_1) = { a }
> points-to (p_2) = { b }
> points-to (p_3) = { a b }
What is the matter if the 'b' var. is unused and
optimally removed by the SSA algorithm?
int a;
int b;
a = 2;
p_4 = phi(a)
// b doesn't used here
if (...)
p_1 = &a;
else
p_2 = &b;
endif
p_3 = phi (p_1, p_2)
points-to (p_1) = { a }
points-to (p_2) = { b }
points-to (p_3) = { a b }
In this case, should exist hidden p_5 = phi(b) although 'b' is not used
but yes used his reference to phantom cell 'b'. It's weird for me.
I've not idea WHERE put "hidden p_5 = phi(b)"!
Too it's possible to ocurr *p_2 = c where 'b' will be hidden used through
the pointer p_2. It's too weird for me.
J.C. Pizarro
