This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, wrong-code, 4.2/4.3/4.4 regression] Patch for PR38615


On Wed, Jan 21, 2009 at 2:15 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Wed, 21 Jan 2009, Richard Guenther wrote:
>
>> Ah, indeed.  It seems to cover this case already.  Quoting:
>>
>> "This option implies @option{-fmerge-constants}.  In addition to
>> @option{-fmerge-constants} this considers e.g.@: even constant initialized
>> arrays or initialized constant variables with integral or floating point
>> types.  Languages like C or C++ require each non-automatic variable to
>> have distinct location, so using this option will result in non-conforming
>> behavior."
>>
>> In the testcase the array is non-automatic (as you have its address
>> taken).
>
> The array has automatic storage duration (being declared inside a function
> without extern or static) whether or not its address is taken.
>
> The issue with the documentation (if the option is extended to cover this
> case) is that it should then say something like "each variable including
> multiple instances of the same variable in recursive calls to the same
> function" instead of "each non-automatic variable".

If it has automatic storage duration, do C or C++ require that automatic
variables have distinct locations?  Thus, is this bug invalid?  (Of course
both automatic variables have overlapping lifetime)

So, can a compiler assign the same memory to i and j in

  int i, j;
  i = 0;
  j = 0;
  return i + j;

?

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]