C and C++ parser performing optimizations

C and C++ parser performing optimizations

[Stefan Franke]

Consider this simple example:

 

  const char * foo() {

    char const * const a = "test";

    char const * const b = a;

    return b;

  }

 

And compile it with

 

gcc -O1 -S test.c -fdump-tree-original

 

you get

 

;; Function foo (null)

;; enabled by -tree-original

 

 

{

  const char * const a = (const char * const) "test";

  const char * const b = (const char * const) "test";

 

    const char * const a = (const char * const) "test";

    const char * const b = (const char * const) "test";

  return (const char *) "test";

}

 

So the parser performs unwanted and uncontrollable optimizations, which I
consider bogus.

 

Any thoughts on this?

 

cheers

 

Stefan

Re: C and C++ parser performing optimizations

[Alexander Monakov]

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

AW: C and C++ parser performing optimizations

[Stefan Franke]

> -----Ursprüngliche Nachricht-----
> Von: Alexander Monakov <amonakov@ispras.ru>
> Gesendet: Sonntag, 2. August 2020 20:41
> An: Stefan Franke <stefan@franke.ms>
> Cc: gcc-help@gcc.gnu.org
> 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));
}

gcc -O1 -S test.c -fdump-tree-original

The variable p gets replaced and the asm input parameters are wrong:

__asm__(" call _faa":"=r" dx:"rf" (const char * const) "hello");

Uh - oh!

Stefan

Re: AW: C and C++ parser performing optimizations

[Alexander Monakov]

On Tue, 4 Aug 2020, Stefan Franke wrote:

> 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));
> }
> 
> gcc -O1 -S test.c -fdump-tree-original
> 
> The variable p gets replaced and the asm input parameters are wrong:
> 
> __asm__(" call _faa":"=r" dx:"rf" (const char * const) "hello");

I think it's a separate issue: even if the frontend wouldn't do such
propagation, I'm pretty sure later passes would. const and volatile
qualifiers just do not work as expected with register variables, and
since recently the documentation mentions that:

6.47.5.2 Specifying Registers for Local Variables

Do not use type qualifiers such as const and volatile, as the outcome may be
contrary to expectations. In particular, when the const qualifier is used, the
compiler may substitute the variable with its initializer in asm statements,
which may cause the corresponding operand to appear in a different register. 


6.47.5.1 Defining Global Register Variables

Do not use type qualifiers such as const and volatile, as the outcome may be
contrary to expectations. In particular, using the volatile qualifier does not
fully prevent the compiler from optimizing accesses to the register. 

Re: AW: C and C++ parser performing optimizations

[Segher Boessenkool]

Hi!

On Tue, Aug 04, 2020 at 10:13:12AM +0300, Alexander Monakov via Gcc-help wrote:
> On Tue, 4 Aug 2020, Stefan Franke wrote:
> > 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));

  return dx; // and then it is valid code, even

> > }
> > 
> > gcc -O1 -S test.c -fdump-tree-original
> > 
> > The variable p gets replaced and the asm input parameters are wrong:
> > 
> > __asm__(" call _faa":"=r" dx:"rf" (const char * const) "hello");
> 
> I think it's a separate issue: even if the frontend wouldn't do such
> propagation, I'm pretty sure later passes would.

I don't think so?  That would be separate extra bugs.

> const and volatile
> qualifiers just do not work as expected with register variables, and
> since recently the documentation mentions that:
> 
> 6.47.5.2 Specifying Registers for Local Variables
> 
> Do not use type qualifiers such as const and volatile, as the outcome may be
> contrary to expectations. In particular, when the const qualifier is used, the
> compiler may substitute the variable with its initializer in asm statements,
> which may cause the corresponding operand to appear in a different register. 

Either we should warn for this, or we should fix this to behave as
expected for "const".  "volatile" otoh, well, what would that even mean
here, maytbe we should just error for that.

(Global register vars are different still...  together with -ffixed-*
that should be pretty easy, but *without* -ffixed-*, global register
vars aren't very well defined anyway).


Segher

Re: C and C++ parser performing optimizations

[Gunther Nikl]

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

AW: C and C++ parser performing optimizations

[Stefan Franke]

> -----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