AW: C and C++ parser performing optimizations

["Stefan Franke" <s.franke@bebbosoft.de>]

> -----Ursprüngliche Nachricht-----
> Von: Gunther Nikl <gnikl@justmail.de>
> Gesendet: Montag, 24. August 2020 21:06
> An: Stefan Franke <stefan@franke.ms>; gcc-help@gcc.gnu.org
> Betreff: Re: C and C++ parser performing optimizations
> 
> stefan@franke.ms (Stefan Franke) wrote:
> 
> > > Von: Alexander Monakov <amonakov@ispras.ru>
> > > Betreff: Re: C and C++ parser performing optimizations
> > >
> > > On Sun, 2 Aug 2020, Stefan Franke wrote:
> > >
> > > > So the parser performs unwanted and uncontrollable optimizations,
> > > > which I consider bogus.
> > >
> > > On occasion they are also incorrect.
> > >
> > > My (possibly wrong or incomplete) understanding is that GCC does not
> > > have internal separation of mandatory simplifications that need to
> > > be done in
> > the
> > > frontend (like constant folding in the context of integer constant
> > > expressions) vs. optional simplifications (optimizing
> > > substitutions). So it just does both at the same time.
> > >
> > > Alexander
> >
> > Here is an example where gcc creates wrong code:
> >
> > test.c:
> > int foo() {
> >   const char * const txt = "hello";
> >   register const char * const p asm("ecx") = txt;
> >   register int dx asm("edx");
> >   asm(" call _faa" :"=r" (dx) :"rf" (p)); }
> 
> Let me guess: this is about the m68k-amigaos LP macros? Can you show an
> example for that target?
> 
> Gunther

Your guess is correct, the m68k-amigaos LP macros are affected. And you may
choose any bogus defined lib function. E.g.

#define InitStruct(___initTable, ___memory, ___size) \
      LP3NR(0x4e, InitStruct , const APTR, ___initTable, a1, APTR,
___memory, a2, ULONG, ___size, d0,\
      , EXEC_BASE_NAME)

What's wrong here? It yields
	register const APTR  __initTable asm("a1");
which is
	register void * const __initTable asm("a1");
(some might expect
	register const void * __initTable asm("a1");
but that's not the case).

So __initTable is const which triggers the bogus optimization in the parsers
(c and c++ don't share the code - they reimplemented that bug).

I patched the parsers to omit that optimization. There are many other passes
which handle const propagation without dropping the register information.

One could fix the headers to circumvent that bug, all 'const <typedef>'
locations need a fix, but that's another story...

Stefan