public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
* Re: Problem building vector/reim_source.c
  2001-12-19 13:20 ` gsl-discuss
@ 2001-12-19 13:20   ` gsl-discuss
  2001-12-19 13:20     ` Brian Gough
  0 siblings, 1 reply; 12+ messages in thread
From: gsl-discuss @ 2001-12-19 13:20 UTC (permalink / raw)
  To: gsl-discuss

On Sat, Aug 18, 2001 at 09:02:49PM -0500, gsl-discuss@lists.thewrittenword.com wrote:
> On Sat, Aug 18, 2001 at 08:24:23PM -0500, gsl-discuss@lists.thewrittenword.com wrote:
> > I don't think this is legal C89 code (from vector/reim_source.c):
> > 
> > QUALIFIED_REAL_VIEW(gsl_vector, view)
> > FUNCTION(gsl_vector, real) (QUALIFIED_TYPE(gsl_vector) * v)
> > {
> >   REAL_TYPE(gsl_vector) s = NULL_VECTOR;
> > 
> >   s.data = v->data;
> >   s.size = v->size;
> >   s.stride = MULTIPLICITY * v->stride;
> >   s.block = 0;  /* FIXME: should be v->block, but cannot point to
> >                    block of different type */
> >   s.owner = 0;
> > 
> >   {
> >     QUALIFIED_REAL_VIEW(gsl_vector,view) view = NULL_VECTOR_VIEW;
> >     ((REAL_VIEW(gsl_vector,view) *)(&view))->vector = s;
> >     return view;
> >   }
> > }
> > 
> > The Solaris C compiler gives:
> > 
> > cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -mr -Qn -xstrconst -xO2
> > -xtarget=generic -c reim.c  -KPIC -DPIC -o reim.o
> > "./reim_source.c", line 35: left operand must be modifiable lvalue: op "="
> > "./reim_source.c", line 53: left operand must be modifiable lvalue: op "="
> > "./reim_source.c", line 35: left operand must be modifiable lvalue: op "="
> > "./reim_source.c", line 53: left operand must be modifiable lvalue: op "="
> > "./reim_source.c", line 35: left operand must be modifiable lvalue: op "="
> > "./reim_source.c", line 53: left operand must be modifiable lvalue: op "="
> > cc: acomp failed for reim.c
> > 
> > I don't believe you can cast an lvalue.
> 
> Ok, upon further investigation, the following code in vector/reim.c:
> 
> #define USE_QUALIFIER
> #define QUALIFIER const
> 
> #define BASE_GSL_COMPLEX_LONG
> #include "templates_on.h"
> #include "reim_source.c"
> #include "templates_off.h"
> #undef  BASE_GSL_COMPLEX_LONG
> 
> causes the chunk above in vector/reim_source.c to cpp to:
> 
> gsl_vector_long_double_const_view 
> gsl_vector_complex_long_double_const_real  (
> 	const gsl_vector_complex_long_double  * v)
> {
>   gsl_vector_long_double  s =  { 0 , 0 , 0 , 0 };
> 
>   s.data = v->data;
>   s.size = v->size;
>   s.stride =  2 * v->stride;
>   s.block = 0;   
>   s.owner = 0;
> 
>   {
>      gsl_vector_long_double_const_view  view =  { { 0 , 0 , 0 , 0 } };
>     (( gsl_vector_long_double_view  *)(&view))->vector = s;
>     return view;
>   }
> }
> 
> So, the Solaris C compiler isn't allowing you to throw away the
> const'ness of view (seems correct to me). I tried compiling with the
> native compilers on Tru64 UNIX, IRIX, HP, and AIX and they all accept
> the construct above.

Actually, it's complaining about "return view".

-- 
albert chin (china@thewrittenword.com)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Problem building vector/reim_source.c
@ 2001-12-19 13:20 gsl-discuss
  2001-12-19 13:20 ` gsl-discuss
  0 siblings, 1 reply; 12+ messages in thread
From: gsl-discuss @ 2001-12-19 13:20 UTC (permalink / raw)
  To: gsl-discuss

I don't think this is legal C89 code (from vector/reim_source.c):

QUALIFIED_REAL_VIEW(gsl_vector, view)
FUNCTION(gsl_vector, real) (QUALIFIED_TYPE(gsl_vector) * v)
{
  REAL_TYPE(gsl_vector) s = NULL_VECTOR;

  s.data = v->data;
  s.size = v->size;
  s.stride = MULTIPLICITY * v->stride;
  s.block = 0;  /* FIXME: should be v->block, but cannot point to
                   block of different type */
  s.owner = 0;

  {
    QUALIFIED_REAL_VIEW(gsl_vector,view) view = NULL_VECTOR_VIEW;
    ((REAL_VIEW(gsl_vector,view) *)(&view))->vector = s;
    return view;
  }
}

The Solaris C compiler gives:

cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -mr -Qn -xstrconst -xO2
-xtarget=generic -c reim.c  -KPIC -DPIC -o reim.o
"./reim_source.c", line 35: left operand must be modifiable lvalue: op "="
"./reim_source.c", line 53: left operand must be modifiable lvalue: op "="
"./reim_source.c", line 35: left operand must be modifiable lvalue: op "="
"./reim_source.c", line 53: left operand must be modifiable lvalue: op "="
"./reim_source.c", line 35: left operand must be modifiable lvalue: op "="
"./reim_source.c", line 53: left operand must be modifiable lvalue: op "="
cc: acomp failed for reim.c

I don't believe you can cast an lvalue.

-- 
albert chin (china@thewrittenword.com)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem building vector/reim_source.c
  2001-12-19 13:20         ` Brian Gough
@ 2001-12-19 13:20           ` gsl-discuss
  2001-12-19 13:20             ` Brian Gough
  0 siblings, 1 reply; 12+ messages in thread
From: gsl-discuss @ 2001-12-19 13:20 UTC (permalink / raw)
  To: gsl-discuss

On Mon, Aug 20, 2001 at 12:25:41PM +0100, Brian Gough wrote:
> gsl-discuss@lists.thewrittenword.com writes:
>  > I've opened a problem report with Sun and gave them a small test case
>  > to reproduce the bug. I'll forward your info below if they need
>  > convincing.
> 
> Sounds good.  You probably saw it on comp.std.c but just for reference
> this was the simplest test case I could find:

According to the Sun engineer:
  I don't think that's valid C code.

  I don't think you can initialize a variable in C with the value of a
  function call like that.

This is using your C code below. Can you point me at the section in
C89 that says the code below should work?

> ----------------------------------------------------------------------
> $ cat test.c
> #include <stdio.h>
> 
> typedef struct {
>   int k;
>   const int kmax;
> } A;
> 
> A create_A (void)
> {
>   A a = { 1, 2 };
>   return a ;
> }
> 
> int main (void)
> {
>   A a = create_A ();
>   printf("a.k=%d\n", a.k);
>   printf("a.kmax=%d\n", a.kmax);
>   return 0;
> }
> 
> $ gcc -ansi -pedantic -Wall -O2 test.c    # gcc-2.7.2.3 and gcc-3.0
> $ ./a.out
> a.k=1
> a.kmax=2
> 
> $ cc -V test.c
> cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11
> acomp: Sun WorkShop 6 update 1 C 5.2 2000/09/11
> "test.c", line 11: left operand must be modifiable lvalue: op "="
> "test.c", line 16: left operand must be modifiable lvalue: op "="
> cc: acomp failed for test.c
> 
> ----------------------------------------------------------------------

-- 
albert chin (china@thewrittenword.com)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem building vector/reim_source.c
  2001-12-19 13:20             ` Brian Gough
@ 2001-12-19 13:20               ` gsl-discuss
  2001-12-19 13:20                 ` Brian Gough
  0 siblings, 1 reply; 12+ messages in thread
From: gsl-discuss @ 2001-12-19 13:20 UTC (permalink / raw)
  To: gsl-discuss

On Thu, Aug 23, 2001 at 02:42:35PM +0100, Brian Gough wrote:
> gsl-discuss@lists.thewrittenword.com writes:
>  > On Mon, Aug 20, 2001 at 12:25:41PM +0100, Brian Gough wrote:
>  > > gsl-discuss@lists.thewrittenword.com writes:
>  > >  > I've opened a problem report with Sun and gave them a small test case
>  > >  > to reproduce the bug. I'll forward your info below if they need
>  > >  > convincing.
>  > > 
>  > > Sounds good.  You probably saw it on comp.std.c but just for reference
>  > > this was the simplest test case I could find:
>  > 
>  > According to the Sun engineer:
>  >   I don't think that's valid C code.
>  > 
>  >   I don't think you can initialize a variable in C with the value of a
>  >   function call like that.
>  > 
>  > This is using your C code below. Can you point me at the section in
>  > C89 that says the code below should work?
> 
> I've been looking at it some more and it may be a moot point now.  
> 
> The Sun C compiler accepts the code in gsl_vector if the const is
> moved outside the struct, e.g. typedef const struct... instead of
> typedef struct { const ... }, which is suitable for this case.
> 
> I've checked this into CVS if you want to try it.

It works with Forte 6.1 and 6.2 (C 5.1 and 5.2). I also tested with
IRIX C, HP-UX C, Tru64 UNIX C, and AIX C. Everything works fine except
AIX which reports:

gmake[2]: Entering directory `/opt/build/gsl-0.9.1/vector'
/bin/sh ../libtool --mode=compile xlc -DHAVE_CONFIG_H -I. -I. -I..
-I.. -I..    -O2 -qmaxmem=-1 -qarch=com -c init.c
mkdir .libs
xlc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -O2 -qmaxmem=-1 -qarch=com
-c init.c  -DPIC
"../gsl/gsl_vector_long_double.h", line 88.1: 1506-120 (S) Function
cannot return a const qualified type.
"../gsl/gsl_vector_long_double.h", line 91.1: 1506-120 (S) Function
cannot return a const qualified type.
"../gsl/gsl_vector_long_double.h", line 107.1: 1506-120 (S) Function
cannot return a const qualified type.
"../gsl/gsl_vector_long_double.h", line 112.1: 1506-120 (S) Function
cannot return a const qualified type.

-- 
albert chin (china@thewrittenword.com)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem building vector/reim_source.c
  2001-12-19 13:20               ` gsl-discuss
@ 2001-12-19 13:20                 ` Brian Gough
  2001-12-19 13:20                   ` gsl-discuss
  0 siblings, 1 reply; 12+ messages in thread
From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw)
  To: gsl-discuss

gsl-discuss@lists.thewrittenword.com writes:
 > It works with Forte 6.1 and 6.2 (C 5.1 and 5.2). I also tested with
 > IRIX C, HP-UX C, Tru64 UNIX C, and AIX C.

Good work.

 > -c init.c -DPIC "../gsl/gsl_vector_long_double.h", line 88.1:
 > 1506-120 (S) Function cannot return a const qualified type.

I've checked in a change to CVS which separates the const from the
return type.  I've tested it with Sun's cc at sourceforge and it
worked ok.  Hopefully this will fix everything.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem building vector/reim_source.c
  2001-12-19 13:20                 ` Brian Gough
@ 2001-12-19 13:20                   ` gsl-discuss
  2001-12-19 13:20                     ` Brian Gough
  0 siblings, 1 reply; 12+ messages in thread
From: gsl-discuss @ 2001-12-19 13:20 UTC (permalink / raw)
  To: gsl-discuss

On Sat, Aug 25, 2001 at 07:05:58PM +0100, Brian Gough wrote:
> gsl-discuss@lists.thewrittenword.com writes:
>  > It works with Forte 6.1 and 6.2 (C 5.1 and 5.2). I also tested with
>  > IRIX C, HP-UX C, Tru64 UNIX C, and AIX C.
> 
> Good work.
> 
>  > -c init.c -DPIC "../gsl/gsl_vector_long_double.h", line 88.1:
>  > 1506-120 (S) Function cannot return a const qualified type.
> 
> I've checked in a change to CVS which separates the const from the
> return type.  I've tested it with Sun's cc at sourceforge and it
> worked ok.  Hopefully this will fix everything.

Ok, your changes made it work on all the platforms above.

-- 
albert chin (china@thewrittenword.com)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem building vector/reim_source.c
  2001-12-19 13:20   ` gsl-discuss
@ 2001-12-19 13:20     ` Brian Gough
  2001-12-19 13:20       ` gsl-discuss
  0 siblings, 1 reply; 12+ messages in thread
From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw)
  To: gsl-discuss

gsl-discuss@lists.thewrittenword.com writes:
 > >   {
 > >      gsl_vector_long_double_const_view  view =  { { 0 , 0 , 0 , 0 } };
 > >     (( gsl_vector_long_double_view  *)(&view))->vector = s;
 > >     return view;
 > >   }
 > > }
 > > 
 > > So, the Solaris C compiler isn't allowing you to throw away the
 > > const'ness of view (seems correct to me). I tried compiling with the
 > > native compilers on Tru64 UNIX, IRIX, HP, and AIX and they all accept
 > > the construct above.
 > 
 > Actually, it's complaining about "return view".

Right. 

I believe the Solaric C compiler is incorrect on this point.

I should have added this to the release notes but forgot (now added).

For more info see my recent post on comp.std.c and Eric Rose's
and my posts on comp.lang.c.moderated.

I think they are misinterpreting section 6.6.6.4,

    If a return statement with an expression is executed the value of
    the expression is returned to the caller as the value of the
    function call expression.  If the expression has a type different
    from that of the function in which it appears, it is converted as
    if it were assigned to an object of that type.

It looks like they are applying the second rule, since the '=' sign in
the error message indicates assignment.  This results in an error,
since the return type is a struct containing a const element.
However, the expression type is the same as the function type, so this
rule should not be applied here.

regards
Brian Gough

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem building vector/reim_source.c
  2001-12-19 13:20 Problem building vector/reim_source.c gsl-discuss
@ 2001-12-19 13:20 ` gsl-discuss
  2001-12-19 13:20   ` gsl-discuss
  0 siblings, 1 reply; 12+ messages in thread
From: gsl-discuss @ 2001-12-19 13:20 UTC (permalink / raw)
  To: gsl-discuss

On Sat, Aug 18, 2001 at 08:24:23PM -0500, gsl-discuss@lists.thewrittenword.com wrote:
> I don't think this is legal C89 code (from vector/reim_source.c):
> 
> QUALIFIED_REAL_VIEW(gsl_vector, view)
> FUNCTION(gsl_vector, real) (QUALIFIED_TYPE(gsl_vector) * v)
> {
>   REAL_TYPE(gsl_vector) s = NULL_VECTOR;
> 
>   s.data = v->data;
>   s.size = v->size;
>   s.stride = MULTIPLICITY * v->stride;
>   s.block = 0;  /* FIXME: should be v->block, but cannot point to
>                    block of different type */
>   s.owner = 0;
> 
>   {
>     QUALIFIED_REAL_VIEW(gsl_vector,view) view = NULL_VECTOR_VIEW;
>     ((REAL_VIEW(gsl_vector,view) *)(&view))->vector = s;
>     return view;
>   }
> }
> 
> The Solaris C compiler gives:
> 
> cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -mr -Qn -xstrconst -xO2
> -xtarget=generic -c reim.c  -KPIC -DPIC -o reim.o
> "./reim_source.c", line 35: left operand must be modifiable lvalue: op "="
> "./reim_source.c", line 53: left operand must be modifiable lvalue: op "="
> "./reim_source.c", line 35: left operand must be modifiable lvalue: op "="
> "./reim_source.c", line 53: left operand must be modifiable lvalue: op "="
> "./reim_source.c", line 35: left operand must be modifiable lvalue: op "="
> "./reim_source.c", line 53: left operand must be modifiable lvalue: op "="
> cc: acomp failed for reim.c
> 
> I don't believe you can cast an lvalue.

Ok, upon further investigation, the following code in vector/reim.c:

#define USE_QUALIFIER
#define QUALIFIER const

#define BASE_GSL_COMPLEX_LONG
#include "templates_on.h"
#include "reim_source.c"
#include "templates_off.h"
#undef  BASE_GSL_COMPLEX_LONG

causes the chunk above in vector/reim_source.c to cpp to:

gsl_vector_long_double_const_view 
gsl_vector_complex_long_double_const_real  (
	const gsl_vector_complex_long_double  * v)
{
  gsl_vector_long_double  s =  { 0 , 0 , 0 , 0 };

  s.data = v->data;
  s.size = v->size;
  s.stride =  2 * v->stride;
  s.block = 0;   
  s.owner = 0;

  {
     gsl_vector_long_double_const_view  view =  { { 0 , 0 , 0 , 0 } };
    (( gsl_vector_long_double_view  *)(&view))->vector = s;
    return view;
  }
}

So, the Solaris C compiler isn't allowing you to throw away the
const'ness of view (seems correct to me). I tried compiling with the
native compilers on Tru64 UNIX, IRIX, HP, and AIX and they all accept
the construct above.

-- 
albert chin (china@thewrittenword.com)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem building vector/reim_source.c
  2001-12-19 13:20       ` gsl-discuss
@ 2001-12-19 13:20         ` Brian Gough
  2001-12-19 13:20           ` gsl-discuss
  0 siblings, 1 reply; 12+ messages in thread
From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw)
  To: gsl-discuss

gsl-discuss@lists.thewrittenword.com writes:
 > I've opened a problem report with Sun and gave them a small test case
 > to reproduce the bug. I'll forward your info below if they need
 > convincing.

Sounds good.  You probably saw it on comp.std.c but just for reference
this was the simplest test case I could find:

----------------------------------------------------------------------
$ cat test.c
#include <stdio.h>

typedef struct {
  int k;
  const int kmax;
} A;

A create_A (void)
{
  A a = { 1, 2 };
  return a ;
}

int main (void)
{
  A a = create_A ();
  printf("a.k=%d\n", a.k);
  printf("a.kmax=%d\n", a.kmax);
  return 0;
}

$ gcc -ansi -pedantic -Wall -O2 test.c    # gcc-2.7.2.3 and gcc-3.0
$ ./a.out
a.k=1
a.kmax=2

$ cc -V test.c
cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11
acomp: Sun WorkShop 6 update 1 C 5.2 2000/09/11
"test.c", line 11: left operand must be modifiable lvalue: op "="
"test.c", line 16: left operand must be modifiable lvalue: op "="
cc: acomp failed for test.c

----------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem building vector/reim_source.c
  2001-12-19 13:20           ` gsl-discuss
@ 2001-12-19 13:20             ` Brian Gough
  2001-12-19 13:20               ` gsl-discuss
  0 siblings, 1 reply; 12+ messages in thread
From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw)
  To: gsl-discuss

gsl-discuss@lists.thewrittenword.com writes:
 > On Mon, Aug 20, 2001 at 12:25:41PM +0100, Brian Gough wrote:
 > > gsl-discuss@lists.thewrittenword.com writes:
 > >  > I've opened a problem report with Sun and gave them a small test case
 > >  > to reproduce the bug. I'll forward your info below if they need
 > >  > convincing.
 > > 
 > > Sounds good.  You probably saw it on comp.std.c but just for reference
 > > this was the simplest test case I could find:
 > 
 > According to the Sun engineer:
 >   I don't think that's valid C code.
 > 
 >   I don't think you can initialize a variable in C with the value of a
 >   function call like that.
 > 
 > This is using your C code below. Can you point me at the section in
 > C89 that says the code below should work?

I've been looking at it some more and it may be a moot point now.  

The Sun C compiler accepts the code in gsl_vector if the const is
moved outside the struct, e.g. typedef const struct... instead of
typedef struct { const ... }, which is suitable for this case.

I've checked this into CVS if you want to try it.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem building vector/reim_source.c
  2001-12-19 13:20     ` Brian Gough
@ 2001-12-19 13:20       ` gsl-discuss
  2001-12-19 13:20         ` Brian Gough
  0 siblings, 1 reply; 12+ messages in thread
From: gsl-discuss @ 2001-12-19 13:20 UTC (permalink / raw)
  To: gsl-discuss

On Sun, Aug 19, 2001 at 11:53:37AM +0100, Brian Gough wrote:
> gsl-discuss@lists.thewrittenword.com writes:
>  > >   {
>  > >      gsl_vector_long_double_const_view  view =  { { 0 , 0 , 0 , 0 } };
>  > >     (( gsl_vector_long_double_view  *)(&view))->vector = s;
>  > >     return view;
>  > >   }
>  > > }
>  > > 
>  > > So, the Solaris C compiler isn't allowing you to throw away the
>  > > const'ness of view (seems correct to me). I tried compiling with the
>  > > native compilers on Tru64 UNIX, IRIX, HP, and AIX and they all accept
>  > > the construct above.
>  > 
>  > Actually, it's complaining about "return view".
> 
> Right. 
> 
> I believe the Solaric C compiler is incorrect on this point.
> 
> I should have added this to the release notes but forgot (now added).

I've opened a problem report with Sun and gave them a small test case
to reproduce the bug. I'll forward your info below if they need
convincing.

> For more info see my recent post on comp.std.c and Eric Rose's
> and my posts on comp.lang.c.moderated.
> 
> I think they are misinterpreting section 6.6.6.4,
> 
>     If a return statement with an expression is executed the value of
>     the expression is returned to the caller as the value of the
>     function call expression.  If the expression has a type different
>     from that of the function in which it appears, it is converted as
>     if it were assigned to an object of that type.
> 
> It looks like they are applying the second rule, since the '=' sign in
> the error message indicates assignment.  This results in an error,
> since the return type is a struct containing a const element.
> However, the expression type is the same as the function type, so this
> rule should not be applied here.
> 
> regards
> Brian Gough

-- 
albert chin (china@thewrittenword.com)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem building vector/reim_source.c
  2001-12-19 13:20                   ` gsl-discuss
@ 2001-12-19 13:20                     ` Brian Gough
  0 siblings, 0 replies; 12+ messages in thread
From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw)
  To: gsl-discuss

gsl-discuss@lists.thewrittenword.com writes:
 > Ok, your changes made it work on all the platforms above.
 > 

Excellent.. I think I finally understand the relevant parts of the
ANSI standard now.

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2001-12-19 13:20 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-12-19 13:20 Problem building vector/reim_source.c gsl-discuss
2001-12-19 13:20 ` gsl-discuss
2001-12-19 13:20   ` gsl-discuss
2001-12-19 13:20     ` Brian Gough
2001-12-19 13:20       ` gsl-discuss
2001-12-19 13:20         ` Brian Gough
2001-12-19 13:20           ` gsl-discuss
2001-12-19 13:20             ` Brian Gough
2001-12-19 13:20               ` gsl-discuss
2001-12-19 13:20                 ` Brian Gough
2001-12-19 13:20                   ` gsl-discuss
2001-12-19 13:20                     ` Brian Gough

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).