Florian Weimer | 1 Jan 2005 01:02
Picon

Re: -funsafe-loop-optimizations

* Zdenek Dvorak:

> several times some people sounded opinion that in addition to improving
> analyses in loop optimizer, we might also add a flag that would enable
> the compiler to assume that the compiled code does not contain loops
> behaving in "weird" way (loops whose control induction variables
> overflows, infinite loops with nontrivial exit conditions).

Are these optimizations permitted by the C standard, the Ada standard
etc.?

If not, the documentation should mention this fact, and it should
provide proper documentation.  With the current documentation, I have
no idea whether it's safe to use this option for my code or not.  (The
situation is a bit different from the floating point case, IMHO.)

Daniel Berlin | 1 Jan 2005 01:13

Re: -funsafe-loop-optimizations


On Fri, 31 Dec 2004, Richard Henderson wrote:

> On Fri, Dec 31, 2004 at 04:50:12PM -0500, Daniel Berlin wrote:
>> Almost all compilers i know of turn this on by default at -O2 or higher.
>> So if we do tihs, i believe we should do that same.
>
> Um, no.

Who actually uses unsigned variable overflow to accomplish infinite loops, 
except as a bug?

Zdenek Dvorak | 1 Jan 2005 01:29
Picon
Favicon

Re: -funsafe-loop-optimizations

Hello,

> > several times some people sounded opinion that in addition to improving
> > analyses in loop optimizer, we might also add a flag that would enable
> > the compiler to assume that the compiled code does not contain loops
> > behaving in "weird" way (loops whose control induction variables
> > overflows, infinite loops with nontrivial exit conditions).
> 
> Are these optimizations permitted by the C standard, the Ada standard
> etc.?

in general no; they may alter semantics of the program, if there happens
to be such a "weird" loop in the program.

> If not, the documentation should mention this fact, and it should
> provide proper documentation.  With the current documentation, I have
> no idea whether it's safe to use this option for my code or not.

Almost surely yes.  There are several patterns that might get
misscompiled with this flag, but none of them is likely to occur
in "normal" code (some of the constants in the examples need
to be replaced by variables with a given value, since with the explicit
constants loop optimizer recognizes that the loop is "weird" and will
not try to optimize it even with the -funsafe-loop-optimizations flag):

1) You write empty loops that may be infinite, although they have
   nontrivial exit condition. E.g.

   for (i = 1; i != 3; i *= 2)
     {
(Continue reading)

Richard Kenner | 1 Jan 2005 01:41
Picon

Re: -funsafe-loop-optimizations

    In particular programs that might get misscompiled with
    -funsafe-loop-optimizations are usually not portable,
    since they depend on exact sizes of types.

Note that depending on exact sizes of types is only non-portable if
you use the standard types (e.g., "int" in C).  If you use types that
specific explicit sizes, it is portable.

Richard Henderson | 1 Jan 2005 01:56
Picon
Favicon

Re: -funsafe-loop-optimizations

On Fri, Dec 31, 2004 at 07:13:34PM -0500, Daniel Berlin wrote:
> Who actually uses unsigned variable overflow to accomplish infinite loops, 
> except as a bug?

I dunno, but language semantics are language semantics.
Thou shalt not alter them by default.

r~

Daniel Berlin | 1 Jan 2005 03:15

Re: -funsafe-loop-optimizations


On Fri, 31 Dec 2004, Richard Henderson wrote:

> On Fri, Dec 31, 2004 at 07:13:34PM -0500, Daniel Berlin wrote:
>> Who actually uses unsigned variable overflow to accomplish infinite loops,
>> except as a bug?
>
> I dunno, but language semantics are language semantics.
> Thou shalt not alter them by default.

Oh well, it was worth a try.
:)

Russell Shaw | 1 Jan 2005 05:03
Picon

Debugging with gdb

Hi,
I have a bit of C code and i want to set a breakpoint in gdb just before
an area that generates some rtl. I want to be able to step thru some
backend code in gcc/config/avr/avr.c.

I got an output listing from my program:

   16:main.c        ****     uint16_t reg=16000000/(16*baud) - 1;
   76               	.LM3:
   77               	 ; (insn 11 10 13 main.c:16 (set (reg:HI 24 r24 [orig:43 baud ] [43])
   78               	 ;         (mem/f:HI (plus:HI (reg/f:HI 28 r28)
   79               	 ;                 (const_int 1 [0x1])) [0 baud+0 S2 A16])) 12 {*movhi} (nil)
   80               	 ;     (nil))
   81 0010 8981      		ldd r24,Y+1	 ;  11	*movhi/2	[length = 2]
   82 0012 9A81      		ldd r25,Y+2

Where do i set gdb in the gcc code so that i can step thru the generation
of rtl output in a high-level kind of way?

Russell Shaw | 1 Jan 2005 05:45
Picon

Debugging with gdb

Hi,
I have a bit of C code and i want to set a breakpoint in gdb just before
an area that generates some rtl. I want to be able to step thru some
backend code in gcc/config/avr/avr.c.

I got an output listing from my program:

   16:main.c        ****     uint16_t reg=16000000/(16*baud) - 1;
   76               	.LM3:
   77               	 ; (insn 11 10 13 main.c:16 (set (reg:HI 24 r24 [orig:43 baud ] [43])
   78               	 ;         (mem/f:HI (plus:HI (reg/f:HI 28 r28)
   79               	 ;                 (const_int 1 [0x1])) [0 baud+0 S2 A16])) 12 {*movhi} (nil)
   80               	 ;     (nil))
   81 0010 8981      		ldd r24,Y+1	 ;  11	*movhi/2	[length = 2]
   82 0012 9A81      		ldd r25,Y+2

Where do i set gdb in the gcc code so that i can step thru the generation
of rtl output in a high-level kind of way?

Gdb can't find the function output_movhi in gcc/config/avr/avr.c. Do i need
to dynamically load something?

Richard Stallman | 1 Jan 2005 06:25
Picon
Picon

Re: -fdump-translation-unit considered harmful

    is there a reason for not making the front ends dynamic libraries which 
    could be linked by any program that wants to parse source code?

One of our main goals for GCC is to prevent any parts of it from being
used together with non-free software.  Thus, we have deliberately
avoided many things that might possibly have the effect of
facilitating such usage, even if that consequence wasn't a certainty.

We're looking for new methods now to try to prevent this, and the outcome
of this search would be very important in our decision of what to do.

Richard Stallman | 1 Jan 2005 06:25
Picon
Picon

Re: -fdump-translation-unit considered harmful

       One possible remedy is to allow "direct" function calls across 
    address spaces. In this situation the GCC's cc1(plus) would be started 
    in one process, with a source-analyzing application(s) in another 
    process(es). These processes would communicate using pipes and /readonly 
    pairwise shared/ memory (each one can read, but not write data of its peer).

       Hence my question: would GPL cover an executable that runs in a 
    separate address space, albeit having some sections /readonly pairwise 
    shared/ with GCC's cc1(plus)?

I think so.  However, it might depend on a number of details.

Anyway, I don't see how using separate address spaces in this way
would be of any kind of benefit.


Gmane