[Bug objc++/35967] Local variables interpreted as volatile following a @try block

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35967

Nicola Pero nicola at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||nicola at gcc dot gnu.org
 Resolution||INVALID

--- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2010-10-04 01:23:07 
UTC ---
Yes, this is part of how -fobjc-exceptions is implemented on next with sjlj. 
There is not much that can be done I guess.

Thanks

[Bug objc++/35967] Local variables interpreted as volatile following a @try block

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2008-04-17 19:58 ---
Subject: Re:   New: Local variables interpreted as volatile following a @try
block



Sent from my iPhone

On Apr 17, 2008, at 12:37, ymeroz at earthlink dot net
[EMAIL PROTECTED] 
  wrote:

 Test case:
 - start file bug.mm
 @interface TestClass
 -(void) testMethod;
 @end

 void ff (int i)
 {
 }

 @implementation TestClass

 -(void) testMethod
 {
int i = 1;
int iref = i;

@try
{}
@catch (id)
{}
@finally
{}

ff (i); // Bug
ff (iref);  // OK
 }
 @end

 - end file

This is a side effect of how the next runtime implements their  
exceptions.




 gcc --version
 i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build  
 5370)

 gcc-4.0 -x objective-c++ -fobjc-exceptions -c bug.mm

 bug.mm: In function 'void -[TestClass testMethod](TestClass*,  
 objc_selector*)':
 bug.mm:23: error: invalid initialization of reference of type 'int'  
 from
 expression of type 'volatile int'
 bug.mm:5: error: in passing argument 1 of 'void ff(int)'

 Summary:
 Adding Obj-C try/catch/finally blocks causes i to be considered  
 volatile
 afterwards.

 Workaround:
 Create a reference to i and use that instead.


 -- 
   Summary: Local variables interpreted as volatile following  
 a @try
block
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ymeroz at earthlink dot net


 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35967



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35967

[Bug objc++/35967] Local variables interpreted as volatile following a @try block

[ymeroz at earthlink dot net]

--- Comment #2 from ymeroz at earthlink dot net  2008-04-17 23:41 ---
(In reply to comment #1)

 This is a side effect of how the next runtime implements their  
 exceptions.

This is a language syntax issue, as I see it. Variable type can not change by
itself in mid-scope in C++ or Obj-C. This is not an issue of runtime
implementation.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35967

Re: [Bug objc++/35967] Local variables interpreted as volatile following a @try block

[Andrew Pinski]

On Thu, Apr 17, 2008 at 4:41 PM, ymeroz at earthlink dot net
[EMAIL PROTECTED] wrote:
  This is a language syntax issue, as I see it. Variable type can not change by
  itself in mid-scope in C++ or Obj-C. This is not an issue of runtime
  implementation.

It is a little of both really. The way the runtime implements @throw
is via setjmp/longjmp and the compiler has to change them to volatile
variables.  I told Apple not to do this but I guess they never
understood how exceptions are used.

Thanks,
Andrew Pinski

[Bug objc++/35967] Local variables interpreted as volatile following a @try block

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2008-04-18 00:17 ---
Subject: Re:  Local variables interpreted as volatile following a @try block

On Thu, Apr 17, 2008 at 4:41 PM, ymeroz at earthlink dot net
[EMAIL PROTECTED] wrote:
  This is a language syntax issue, as I see it. Variable type can not change by
  itself in mid-scope in C++ or Obj-C. This is not an issue of runtime
  implementation.

It is a little of both really. The way the runtime implements @throw
is via setjmp/longjmp and the compiler has to change them to volatile
variables.  I told Apple not to do this but I guess they never
understood how exceptions are used.

Thanks,
Andrew Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35967