gcc errors

[legacy]

I am trying to recompile gcc-v2.95 with gcc-8.3.0, and ... I see errors like this:

Code: [Select]

# define obstack_ptr_grow(OBSTACK,datum)                                \
__extension__                                                           \
({ struct obstack *__o = (OBSTACK);                                     \
   if (__o->next_free + sizeof (void *) > __o->chunk_limit)             \
     _obstack_newchunk (__o, sizeof (void *));                          \
   *((void **)__o->next_free)++ = ((void *)datum);                      \
   (void) 0; })


Code: [Select]

../../../src/gcc-2.95.3/gcc/../include/obstack.h:420:30: error: lvalue required as increment operand
    *((void **)__o->next_free)++ = ((void *)datum);   \
                              ^~

how would you fix this? (there are 219 similar lines  )

[malagas_on_fire]

Here's a hint:

https://stackoverflow.com/questions/3364445/lvalue-required-as-increment-operand#3364445

[legacy]

https://stackoverflow.com/questions/21172290/gcc-gdb-building-lvalue-required-as-increment-operand-on-void-o-nex

[malagas_on_fire]

Here is a newer version for that particular file obstack.h in binutils-gdb when comparing with the stackoverflow
 links which  are older

https://github.com/redox-os/binutils-gdb/blob/master/include/obstack.h

They've re-arranged in splitted macros.

[legacy]

Thanks! That file has just made my day since it has fixed the main problem!

gcc-2.95.* has a lot of other minor problems, but I have fixed them, and I have just compiled the crosscompier for the m88k (eight eight key) target

Code: [Select]

  target: m88k-coff
binutils: 2.12
     gcc: 2.95.3
    libc:
    path: /idp/bin/m88k-coff-*


Code: [Select]

NewOrangeBox # m88k-coff-gcc -v
Reading specs from /idp/lib/gcc-lib/m88k-coff/2.95.3/specs
gcc version 2.95.3 20010315 (release)


[SiliconWizard]

Yeah, apparently old GCC code was relying on non-standard rules to compile.
GCC 2.95 code base was all written BEFORE C99 came out, and anyway, GCC was not conforming to the standard as well as it does now either...

Now I'm wondering whether a typical (non GCC) C compiler of the time (~1999) would compile this (I kinda doubt it, although some old C compilers would treat void * kinda as char * ?), or if the above code would only compile with GCC itself, requiring some bootstrapping.

[NorthGuy]

Now I'm wondering whether a typical (non GCC) C compiler of the time (~1999) would compile this

It shouldn't. The C99 standard says:

"Except when it is the operand of the sizeof operator, the _Alignof operator, the
unary & operator, the++operator, the--operator, or the left operand of the. operator
or an assignment operator, an lvalue that does not have array type is converted to the
value stored in the designated object (and is no longer an lvalue)" (6.3.2.1.2)

So you shouldn't be able to cast to void** before ++.

The compliant way is to add sizeof(void*) to it instead of casting and incrementing, just as they do few lines earlier.

[SiliconWizard]

I know it shouldn't in C99. You probably didn't quite get what I meant.

Most C compilers in 1999 were NOT compliant with C99 (and it took a few years before reasonably compliant compilers came out), and GCC either IMO (or maybe it had very partial compliance, dunno).

So my question was whether a typical C89/90-compliant compiler at the time would be able to compile this properly, or whether it was just relying on GCC's particular implementation.

[malagas_on_fire]

Yeah, apparently old GCC code was relying on non-standard rules to compile.
GCC 2.95 code base was all written BEFORE C99 came out, and anyway, GCC was not conforming to the standard as well as it does now either...

Now I'm wondering whether a typical (non GCC) C compiler of the time (~1999) would compile this (I kinda doubt it, although some old C compilers would treat void * kinda as char * ?), or if the above code would only compile with GCC itself, requiring some bootstrapping.

Looks like it was a new feature implemented on the  GNU GCC 2.95 , whether it was able to compile with that option is dubious.

https://www.gnu.org/software/gcc/gcc-2.95/features.html