Re: problem with data alignment with egcs-19990602

Re: problem with data alignment with egcs-19990602

[Mumit Khan]

Andris Pavenis <andris@stargate.astr.lu.lv> writes:
> Problem seems to be related with use of #pragma pack():
> 	I had to put definition of some structures between
> 		#pragma pack(1)
> 	and
> 		#pragma pack()
> 
> It looks that with gcc 2.95 tree the second line (#pragma pack())
> is ignored and as result I'm getting wrong code.
> 	- using __attribute__(packed) instead fixes the problem
> 	- no changes needed for egcs-1.1.2 (#pragma pack() works
> 	   as I expect)
> 
> Below is simple test example that ilustrates the problem
> 
> ----------------------------------------------------
> #include <stdio.h>
> #include <assert.h>
> 
> 
> #pragma pack(1)
> #pragma pack()
> 
> 
> class  Test1
>   {
>   public:
>       char a;
>       long b;
>       Test1 (void)
>         {
> 	    printf ("%p\n",(((char *) & b)-((char *) & a)));
> 	}
>   };
>   
>   
> int main (void)
>   {
>       Test1 x;
>       return 0;
>   }
>   
> ----------------------------------------------------		
> With gcc-1.1.2 I'm getting output 4
> With gcc-2.95 prerelease I'm getting 1
> 
> So we should either have a warning from compiler that #pragma pack()
> should not be used or this problem must be fixed
> 

The alignment should revert to the default when `#pragma pack()' is 
encountered (ie., without an token between the '(' and ')').

Does the following fix it?

Tue Jun  8 17:31:18 1999  Mumit Khan  <khan@xraylith.wisc.edu>

	* c-pragma.c (handle_pragma_token): Handle `#pragma pack()'
	correctly.

Index: c-pragma.c
===================================================================
RCS file: /cvs/egcs/egcs/gcc/c-pragma.c,v
retrieving revision 1.16
diff -u -3 -p -r1.16 c-pragma.c
--- c-pragma.c	1999/04/26 21:18:07	1.16
+++ c-pragma.c	1999/06/08 23:37:49
@@ -383,8 +383,15 @@ handle_pragma_token (string, token)
     case ps_left:
 
       if (token == NULL_TREE)
-	state = (strcmp (string, ")") ? ps_bad : ps_right);
-
+	{
+	  if (strcmp (string, ")") == 0)
+	    {
+	      align = 0;
+	      state = ps_right;
+	    }
+	  else
+	    state = ps_bad;
+	}
       else if (TREE_CODE (token) == INTEGER_CST)
 	goto handle_align;
 
Regards,
Mumit

Re: problem with data alignment with egcs-19990602

[Andris Pavenis]

Problem seems to be related with use of #pragma pack():
	I had to put definition of some structures between
		#pragma pack(1)
	and
		#pragma pack()

It looks that with gcc 2.95 tree the second line (#pragma pack())
is ignored and as result I'm getting wrong code.
	- using __attribute__(packed) instead fixes the problem
	- no changes needed for egcs-1.1.2 (#pragma pack() works
	   as I expect)

Below is simple test example that ilustrates the problem

----------------------------------------------------
#include <stdio.h>
#include <assert.h>


#pragma pack(1)
#pragma pack()


class  Test1
  {
  public:
      char a;
      long b;
      Test1 (void)
        {
	    printf ("%p\n",(((char *) & b)-((char *) & a)));
	}
  };
  
  
int main (void)
  {
      Test1 x;
      return 0;
  }
  
----------------------------------------------------		
With gcc-1.1.2 I'm getting output 4
With gcc-2.95 prerelease I'm getting 1

So we should either have a warning from compiler that #pragma pack()
should not be used or this problem must be fixed

Andris


On Mon, 07 Jun 1999, Andris Pavenis wrote:
> On Mon, 07 Jun 1999, pavenis@lanet.lv wrote:
> > 	compiler generates code which access class member
> > 	via wrong address (result is SIGSEGV for me). Below is 		
> > 	some test data I got (I simply copied this from rhide watch 
> > 	window and added some comments)
> > 
> >  this: (TEphApp *) 0x240f20
> >  App: (TEphApp *) 0x240f20
> >  &slrcfg: (LoadedConfigFile *) 0x240f84
> >  &App->slrcfg: (LoadedConfigFile *) 0x240f84
> >  &satinfo: (LoadedConfigFile *) 0x240fa5             - false address 
> > 	 (but this address is used both when I call satinfo.foo() and
> > 	App->satinfo.foo() (name changed) from member function)
> >  &(App->satinfo): (LoadedConfigFile *) 0x240fa8   - right value (I can 
> >       get contents here)
> > 
> > I have this problem in rather big application (TVision + different 
> > other stuff, TEphApp is derived from TApplication such stuff as
> > virtual base classes etc is present) only.
> > 
> > I tried to reproduce this problem in a simple test example but didn't 
> > succeed. Perhaps I'll check the same sometime under Linux as this
> > app can be built (and it should normally work) also under Linux.
> > 
> 
> I reproduced the same thing with egcs-19990601 (I updated gcc 2.95
> branch with CVS then) under Linux (kernel 2.2.9, glibc-2.1.1). 
> As I don't have good test example to send then perhaps I'll retry the same
> with later snapshots. Perhaps it would be worth to try also with
> gcc-2.96 tree to see whether something changes.
> 
> Andris

Re: egcs-19990602 (gcc-2.95 prerelease) binaries for testing

[Andris Pavenis]

On Mon, 07 Jun 1999, pavenis@lanet.lv wrote:
> 	compiler generates code which access class member
> 	via wrong address (result is SIGSEGV for me). Below is 		
> 	some test data I got (I simply copied this from rhide watch 
> 	window and added some comments)
> 
>  this: (TEphApp *) 0x240f20
>  App: (TEphApp *) 0x240f20
>  &slrcfg: (LoadedConfigFile *) 0x240f84
>  &App->slrcfg: (LoadedConfigFile *) 0x240f84
>  &satinfo: (LoadedConfigFile *) 0x240fa5             - false address 
> 	 (but this address is used both when I call satinfo.foo() and
> 	App->satinfo.foo() (name changed) from member function)
>  &(App->satinfo): (LoadedConfigFile *) 0x240fa8   - right value (I can 
>       get contents here)
> 
> I have this problem in rather big application (TVision + different 
> other stuff, TEphApp is derived from TApplication such stuff as
> virtual base classes etc is present) only.
> 
> I tried to reproduce this problem in a simple test example but didn't 
> succeed. Perhaps I'll check the same sometime under Linux as this
> app can be built (and it should normally work) also under Linux.
> 

I reproduced the same thing with egcs-19990601 (I updated gcc 2.95
branch with CVS then) under Linux (kernel 2.2.9, glibc-2.1.1). 
As I don't have good test example to send then perhaps I'll retry the same
with later snapshots. Perhaps it would be worth to try also with
gcc-2.96 tree to see whether something changes.

Andris

Re: egcs-19990602 (gcc-2.95 prerelease) binaries for testing

[pavenis]

On 7 Jun 99, at 12:21, pavenis@lanet.lv wrote:

> We could expect release of gcc-2.95 after not so long time. Therefore
> I have built 2 June snapshot of egcs for DJGPP and made binaries of 
> C and C++ compilers are available for testing.
> 
> http://www.lanet.lv/~pavenis/gcc295snap.zip  - C compiler
> http://www.lanet.lv/~pavenis/gpp295snap.zip  - C++ compiler + libstdcxx.a
> http://www.lanet.lv/~pavenis/lgp295snap.zip   - libgpp.a built with this compiler
> 
> Please test them (I'll do the same).
> 

Perhaps You may try it, but more likely I'll have to remove it due to  
serious problems with C++ (so be carefull):
	compiler generates code which access class member
	via wrong address (result is SIGSEGV for me). Below is 		
	some test data I got (I simply copied this from rhide watch 
	window and added some comments)

 this: (TEphApp *) 0x240f20
 App: (TEphApp *) 0x240f20
 &slrcfg: (LoadedConfigFile *) 0x240f84
 &App->slrcfg: (LoadedConfigFile *) 0x240f84
 &satinfo: (LoadedConfigFile *) 0x240fa5             - false address 
	 (but this address is used both when I call satinfo.foo() and
	App->satinfo.foo() (name changed) from member function)
 &(App->satinfo): (LoadedConfigFile *) 0x240fa8   - right value (I can 
      get contents here)

I have this problem in rather big application (TVision + different 
other stuff, TEphApp is derived from TApplication such stuff as
virtual base classes etc is present) only.

I tried to reproduce this problem in a simple test example but didn't 
succeed. Perhaps I'll check the same sometime under Linux as this
app can be built (and it should normally work) also under Linux.

Andris