Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #38202 > unrolled thread

rhel 7 and kforth

Back to article view | Back to comp.lang.forth

Contents

  rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-15 11:20 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-15 19:09 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 04:13 -0700
      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 04:55 -0700
        Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-16 12:08 +0000
          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 05:29 -0700
            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 07:07 -0700
              Re: rhel 7 and kforth franck.bensusan@gmail.com - 2015-04-16 07:44 -0700
                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 08:14 -0700
            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-16 14:02 +0000
              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 08:12 -0700
        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 12:25 -0700
          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:02 -0700
            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:06 -0700
              Re: rhel 7 and kforth foxaudioresearch@gmail.com - 2015-04-16 17:24 -0700
                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:39 -0700
                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 17:47 -0700
                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 18:44 -0700
                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 18:50 -0700
                      Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 19:10 -0700
                        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 19:29 -0700
                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 20:10 -0700
                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 20:27 -0700
                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 02:04 -0700
                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-17 11:41 +0000
                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:45 -0700
                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:01 +0000
                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 07:47 -0700
                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:35 -0700
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 10:33 -0700
                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 11:15 -0700
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 11:47 -0700
                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:51 -0700
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:41 +0000
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 11:42 -0700
                                              Re: rhel 7 and kforth "Elizabeth D. Rather" <erather@forth.com> - 2015-04-24 09:02 -1000
                                              Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 10:53 +0000
                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-05-03 17:22 -0700
                                                  Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 10:23 +0000
                                          Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-22 00:10 +0200
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 17:45 -0700
                                            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 13:08 +0000
                                  Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 20:27 +0000
                                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:41 -0700
                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:11 +0000
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 15:47 -0700
                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:34 +0000
                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-18 14:09 -0700
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-19 20:31 -0700
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 11:35 +0000
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 18:07 -0700
                                              Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 11:21 +0000
                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 19:34 -0700
                                                  Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 08:36 +0000
                                                    Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-25 11:36 +0000
                                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 16:29 +0000
                              Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-19 10:08 +0000
                                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-19 20:11 -0700
                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 12:05 +0000
                                  Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-22 01:27 +0200
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 18:18 -0700
                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 11:00 +0000
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 11:28 -0700
                                          Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-25 01:34 +0200
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 21:07 -0700
                                            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 16:41 +0000
                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-25 10:06 -0700
                                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-26 14:56 +0000
                                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-26 20:22 -0700
                                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 09:02 +0000
                                                      Re: rhel 7 and kforth mhx@iae.nl - 2015-04-27 03:59 -0700
                                                      Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-27 15:45 +0000
                                                      Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-27 18:09 -0400
                                                      Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 03:55 +0200
                                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-27 19:30 -0700
                                                        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-27 19:44 -0700
                                                        Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-28 02:03 -0400
                                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 01:44 -0700
                                                            Re: rhel 7 and kforth Mark Wills <markwills1970@gmail.com> - 2015-04-28 02:44 -0700
                                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 16:47 -0700
                                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 17:00 -0700
                                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 17:14 -0700
                                                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 17:59 -0700
                                                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 21:41 -0700
                                                                  Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-29 03:07 +0200
                                                                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 18:13 -0700
                                                              Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-29 00:07 +0000
                                                        Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 22:22 +0200
                                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 14:23 -0700
                                                            Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 23:51 +0200
                                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 16:50 -0700
                                                            Re: rhel 7 and kforth David Thompson <dave.thompson2@verizon.net> - 2015-05-10 12:24 -0400
                                                  Re: rhel 7 and kforth mhx@iae.nl - 2015-04-26 22:16 -0700
                                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 09:19 +0000
                                                      Re: rhel 7 and kforth mhx@iae.nl - 2015-04-27 04:03 -0700
                                                      Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-27 18:21 -0400
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-01 14:46 +0000
                                      Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-23 16:46 +0200
                          Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 10:35 +0000
                            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:43 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:41 -0700

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#38702

On Tuesday, April 28, 2015 at 6:47:40 PM UTC-5, Paul Rubin wrote:
> krishna.myneni@ccreweb.org writes:
> >         int x=0;
> >         do {
> >           a[i++] = x;
> >           x += 1;
> >           i = i % 16;
> >         } while (x > 0 );
> 
> Signed integer overflow is undefined behaviour in C, so that the
> compiler can assume the invariant x+1 > x for all signed ints x,
> allowing some loops to run faster (less tests) in the expected case of
> no overflow.  That is not an accident artifact of the compiler writers
> relying on some tricky unintended interpretation of the standard.  From
> what I can tell, the standard was written that way on purpose, to enable
> that optimization.  So it is that way for a reason--whether it's a GOOD
> reason is debatable, but it's a reason.

We are in the debate phase now, to try to understand how bad is the actual situation. The rationalization of crazy compiler behavior is no longer important. It's a question of its prevalence. I think many of us probably agree that the compiler has gone off the rails, with its optimizations. For my own Forth system, I won't be able to replace the C/C++ compiler very quickly. For the present, I'm starting to move as much of the functionality as possible into assembler code. But, I expect I will still need a high-level language to implement the top layer of the Forth system.

Krishna

[toc] | [prev] | [next] | [standalone]

#38704

krishna.myneni@ccreweb.org writes:
> The rationalization of crazy compiler behavior is no longer
> important. It's a question of its prevalence. 

I think optimizers will get even more aggressive rather than less.  The
only promising countermeasure is to define a dialect like Regehr's
"friendly C" and get compilers to implement it. 

> I think many of us probably agree that the compiler has gone off the
> rails, with its optimizations.

I think the x+1>x optimization was "legitimate" in the sense that it
wasn't based on inferring something from the assumption that some other
part of the program didn't do a UB.  The compiler is not off the rails.
One can argue that the language (or anyway the ANSI standard) is off the
rails, but the compiler is doing what the standard writers intended for
it to do.

> For my own Forth system, I won't be able to replace the C/C++ compiler
> very quickly.

You might try something like Frama-C to check for other such issues.

> For the present, I'm starting to move as much of the functionality as
> possible into assembler code. But, I expect I will still need a
> high-level language to implement the top layer of the Forth system.

If your Forth is PC-hosted, is there a reason to not use something like
Python at the high levels?

[toc] | [prev] | [next] | [standalone]

#38705

On Tuesday, April 28, 2015 at 7:14:53 PM UTC-5, Paul Rubin wrote:
> krishna.myneni@ccreweb.org writes:
...
> I think the x+1>x optimization was "legitimate" in the sense that it
> wasn't based on inferring something from the assumption that some other
> part of the program didn't do a UB.  The compiler is not off the rails.
> One can argue that the language (or anyway the ANSI standard) is off the
> rails, but the compiler is doing what the standard writers intended for
> it to do.
> 

Does the standard say precisely that the compiler *must* eliminate the section of code in which the UB occurs? If not, then clearly the compiler is not restricted to doing that type of behavior. Perhaps if the standard explicitly states that in a UB case, the compiler must always optimize to the fastest execution time, then the compiler maintainers would be correct to do so. This is why I say the compiler is off the rails. No rational coder would take such an interpretation when he reads the source. As for doing what the standard permits, like I say, there's no dispute about that. But, we certainly can take the compiler to task for doing something inconsistent with prior practice.


> > For my own Forth system, I won't be able to replace the C/C++ compiler
> > very quickly.
> 
> You might try something like Frama-C to check for other such issues.
> 

It sounds like it's worth the effort. Thanks.


> > For the present, I'm starting to move as much of the functionality as
> > possible into assembler code. But, I expect I will still need a
> > high-level language to implement the top layer of the Forth system.
> 
> If your Forth is PC-hosted, is there a reason to not use something like
> Python at the high levels?

Yes, it's intended for use on the PC. Python may be a possibility.

Krishna

[toc] | [prev] | [next] | [standalone]

#38709

krishna.myneni@ccreweb.org writes:
> Does the standard say precisely that the compiler *must* eliminate the
> section of code in which the UB occurs? 

No, but it's in the standard's spirit, which the compiler devs followed.
And again, whether the standard's spirit shows wisdom is debatable, but
the theory is that the standard committee represents the C user
community, and an awful lot of C programmers (maybe a majority) will
vote for speed over freedom from hazards.  If it skipped that
optimization you're complaining about, other users would ask why the
compiler was generating suboptimal code for their oh-so-important
program, just for the sake of programmers who weren't careful or
responsible enough to study the standard before coding.

> Perhaps if the standard explicitly states that in a UB case, the
> compiler must always optimize to the fastest execution time,

The compiler isn't required to optimize for fastest execution time and
doesn't always do so.  It does it when you ask it to, by putting -O on
the command line.

> No rational coder would take such an interpretation when he reads the
> source. 

Rational coders unfamiliar with C's quirks might make plausible
assumptions that turn out to be wrong and get them bitten.  That's what
happened to you.  Some possible rational reactions might include: 1)
learn about the quirks (they are well documented) and take them into
account in the future so you hopefully won't get bitten again; 2) decide
that C is unsafe for anything critical and look toward other languages;
3) participate in constructive discussions about updating the standard,
e.g. Regehr's proposal of a friendly dialect. 4) Program in C with a lot
of trepidation, making use of -Wall and other analysis tools, and (the
standards guy I had the discussion with was big on this) have detailed
multi-person code reviews for anything important.  

Not-so-rational is: calling a permitted optimization a compiler bug when
there's evidence that other users (maybe not all of them) want the
optimization.

Anyway, you now know something new about signed ints in C, so use the
knowledge well.  Or if you want wraparound arithmetic, you can use
unsigned or -fwrapv.

> As for doing what the standard permits, like I say, there's no dispute
> about that. But, we certainly can take the compiler to task for doing
> something inconsistent with prior practice.

These issues were debated when the standard was written in the 1980s and
knowledgeable C programmers have understood the issue the whole time
since then.  It's not clear to me what "prior practice" was but this
optimization has been in GCC for quite a while.

> Yes, it's intended for use on the PC. Python may be a possibility.

Forth also seems like the obvious choice, but I assume you already had
some reason not to have used it.

[toc] | [prev] | [next] | [standalone]

#38706

Paul Rubin wrote:

>> For the present, I'm starting to move as much of the functionality as
>> possible into assembler code. But, I expect I will still need a
>> high-level language to implement the top layer of the Forth system.
> 
> If your Forth is PC-hosted, is there a reason to not use something like
> Python at the high levels?

Well, I suggest to use Forth for the higher level of implementing a Forth 
system...

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#38707

On Tuesday, April 28, 2015 at 8:07:05 PM UTC-5, Bernd Paysan wrote:
...
> Well, I suggest to use Forth for the higher level of implementing a Forth 
> system...
> 

A perfect idea!

Krishna

[toc] | [prev] | [next] | [standalone]

#38703

In article <87h9rzvmqt.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>krishna.myneni@ccreweb.org writes:
>>         int x=0;
>>         do {
>>           a[i++] = x;
>>           x += 1;
>>           i = i % 16;
>>         } while (x > 0 );

If you want to view x as an unsigned, then later as signed
you must make your intentions clear:

"
         union {
                  unsigned int u;
                  int i;
               } x;
         x.u = 0;
         do {
           a[i++] = x.u;
           x.u += 1;
           i = i % 16;
         } while (x.i > 0 );
"

>
>Signed integer overflow is undefined behaviour in C, so that the
>compiler can assume the invariant x+1 > x for all signed ints x,
>allowing some loops to run faster (less tests) in the expected case of
>no overflow.  That is not an accident artifact of the compiler writers
>relying on some tricky unintended interpretation of the standard.  From
>what I can tell, the standard was written that way on purpose, to enable
>that optimization.  So it is that way for a reason--whether it's a GOOD
>reason is debatable, but it's a reason.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#38694

krishna.myneni@ccreweb.org wrote:

> I'm having trouble understanding why the compiler does this. To avoid
> issues of initialization and such, I modified the example as follows:
> 
> int main()
> {
> int i=0, a[16];
> int x=0;
> do {
> a[i++] = x;
> x += 1;
> } while (x != 0 );
> printf("%d\n", a[0]);
> return 0;
> }
> 
> 
> gcc v 4.9.x generates the following, with -S -Wall -O3 :
> :
> main:
> .LFB0:
> .cfi_startproc
> .p2align 4,,10
> .p2align 3
> .L2:
> jmp     .L2
> .cfi_endproc
> :
> 
> Ok, that's an infinite loop, and I can't see why.

The idea is that x is an integer, and therefore, overflow is undefined.  
Undefined means the compiler can do whatever it wants, especially eliminate 
code.  What's eliminated here is the x != 0.  It's != 0 for all defined 
cases, and then it's overflowing, in which case it's undefined, and 
undefined != 0.  If you compile it with -fwrapv, it works.

This sort of problem was introduced in GCC 2.95, and the -fwrapv was 
introduced in GCC 3.4.  GCC 4.8 introduced treating out-of-bounds accesses 
as 0.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#38695

On Tuesday, April 28, 2015 at 3:22:38 PM UTC-5, Bernd Paysan wrote:
> krishna.myneni@ccreweb.org wrote:
> 
> > I'm having trouble understanding why the compiler does this. To avoid
> > issues of initialization and such, I modified the example as follows:
> > 
> > int main()
> > {
> > int i=0, a[16];
> > int x=0;
> > do {
> > a[i++] = x;
> > x += 1;
> > } while (x != 0 );
> > printf("%d\n", a[0]);
> > return 0;
> > }
> > 
> > 
> > gcc v 4.9.x generates the following, with -S -Wall -O3 :
> > :
> > main:
> > .LFB0:
> > .cfi_startproc
> > .p2align 4,,10
> > .p2align 3
> > .L2:
> > jmp     .L2
> > .cfi_endproc
> > :
> > 
> > Ok, that's an infinite loop, and I can't see why.
> 
> The idea is that x is an integer, and therefore, overflow is undefined.

So, this means I can't use a byte length signed number as a wrapping counter any more (without -fwrapv)?
  
> Undefined means the compiler can do whatever it wants, especially eliminate 
> code.

That's crazy talk, especially the last part about eliminating code. Is that how the presently evolving Forth standard views an undefined condition?

> What's eliminated here is the x != 0.  It's != 0 for all defined 
> cases, and then it's overflowing, in which case it's undefined, and 
> undefined != 0.  If you compile it with -fwrapv, it works.
> 
> This sort of problem was introduced in GCC 2.95, and the -fwrapv was 
> introduced in GCC 3.4.  GCC 4.8 introduced treating out-of-bounds accesses 
> as 0.
> 

Krishna

[toc] | [prev] | [next] | [standalone]

#38696

krishna.myneni@ccreweb.org wrote:

> On Tuesday, April 28, 2015 at 3:22:38 PM UTC-5, Bernd Paysan wrote:
>> The idea is that x is an integer, and therefore, overflow is undefined.
> 
> So, this means I can't use a byte length signed number as a wrapping
> counter any more (without -fwrapv)?

Indeed.

>> Undefined means the compiler can do whatever it wants, especially
>> eliminate code.
> 
> That's crazy talk, especially the last part about eliminating code. Is
> that how the presently evolving Forth standard views an undefined
> condition?

I'm just citing the crazy talk of the GCC and LLVM maintainers.  Note that 
there are some differences between Clang and GCC with respect to access of 
out-of-bound memory: GCC converts those to all-zero, and clang converts them 
to all non-zero.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#38701

On Tuesday, April 28, 2015 at 4:51:53 PM UTC-5, Bernd Paysan wrote:
> krishna.myneni@ccreweb.org wrote:
..
> 
> >> Undefined means the compiler can do whatever it wants, especially
> >> eliminate code.
> > 
> > That's crazy talk, especially the last part about eliminating code. Is
> > that how the presently evolving Forth standard views an undefined
> > condition?
> 
> I'm just citing the crazy talk of the GCC and LLVM maintainers.  ...

Yes, I know. :-)

Krishna

[toc] | [prev] | [next] | [standalone]

#38942

On Tue, 28 Apr 2015 14:23:17 -0700 (PDT), krishna.myneni@ccreweb.org
wrote:

> On Tuesday, April 28, 2015 at 3:22:38 PM UTC-5, Bernd Paysan wrote:
> > krishna.myneni@ccreweb.org wrote:
<snip: GCC optimizing away loop test>
> > The idea is that x is an integer, and therefore, overflow is undefined.
> 
A _signed_ integer. C unsigned integers do reliably wraparound.

> So, this means I can't use a byte length signed number as a wrapping counter any more (without -fwrapv)?
>   
On most targets C's 'byte' types ([un/signed] char) are 8 bits and
you're okay. Also if you use an 8-bit bitfield (in a struct) or the
C99+ exact-width type int8_t. Addition including incrementing is an
arithmetic operation and (at least notionally) first promotes operands
narrower than signed or unsigned int, which must be at least 16 bits
(and for GCC is always 32). Thus the addition 127+1 is safe. On
assignment back to the variable 128 doesn't fit, which may look like
overflow, but comes under a different provision in the C standard:
out-of-range signed integer conversion is _implementation-defined_,
which means it can give you the wrong result or raise a signal but
nothing worse (not undefined behavior) and it must be documented and
GCC documents it to be wraparound (thus -128).

C standard allows an implementation to make s,u/char 16 bits or more
and u/short and u/int the same size, in which case SCHAR_MAX+1 (and
CHAR_MAX+1 if plain char is signed) _does_ overflow. I don't know any
GCC targets that do this, but I haven't searched. On such an
implementation int8_t isn't available, but :8 bitfield is still okay.

[toc] | [prev] | [next] | [standalone]

#38636

On Sunday, April 26, 2015 at 5:09:38 PM UTC+2, Anton Ertl wrote:
> krishna.myneni@ccreweb.org writes:
> >On Saturday, April 25, 2015 at 11:49:22 AM UTC-5, Anton Ertl wrote:
>                       but it goes something like:
> 
> Array a has indexes 0-15, and is indexed with a[i], so i can only have
> values 0-15 at that point (everything else would be undefined
> behaviour).  So obviously i<16 is always true and we can "optimize" it
> to true.
> 
> The compiler is oblivious to the fact that i<16 controls a loop that
> is "optimized" into an endless loop.

I don't know if I am understanding your explanation
correctly, but by magical coincidence this matches a
problem in circuit simulation (SPICE) that I am
currently looking at.

In SPICE you can have behavioral expressions of the type
IF ( voltage_at_x > voltage_at_y ) THEN voltage_at_z = 1,
else voltage_at_z = 0. The problem is that this expression
is discontinuous, meaning that V(z) is not differentiable,
neither with respect to V(x), nor with respect to V(y).
When time-stepping, the simulator is then confronted with
a signal at z that suddenly and unpredictably changes
(e.g. that V(x) is a ramp, k*time and V(y) a constant 2).

"So obviously i<16 is always true and we can "optimize" it
to true." seems to be equivalent to the above IF statement:
i<16 is always true but not differentiable. Therefore,
something funny canand does happen between 15 and 16
when we check 'i''s progress versus *time*.

In SPICE the solution is to not hard clip the I<16
expression to either yes or no, but instead soft-limit
it to a value between 0 and 1, with 0.5 being the logic
threshold. The TANH function is nearly ideal for that.

-marcel

[toc] | [prev] | [next] | [standalone]

#38644

mhx@iae.nl writes:
>On Sunday, April 26, 2015 at 5:09:38 PM UTC+2, Anton Ertl wrote:
>> krishna.myneni@ccreweb.org writes:
>> >On Saturday, April 25, 2015 at 11:49:22 AM UTC-5, Anton Ertl wrote:
>>                       but it goes something like:
>> 
>> Array a has indexes 0-15, and is indexed with a[i], so i can only have
>> values 0-15 at that point (everything else would be undefined
>> behaviour).  So obviously i<16 is always true and we can "optimize" it
>> to true.
>> 
>> The compiler is oblivious to the fact that i<16 controls a loop that
>> is "optimized" into an endless loop.
>
>I don't know if I am understanding your explanation
>correctly, but by magical coincidence this matches a
>problem in circuit simulation (SPICE) that I am
>currently looking at.

Your description of the SPICE problem sounds very different from the
problem in the compiler as I understand it.  Differentiability does
not play a role in compilers.  I'll try to explain it again:

If you have

i=5;
if (i<16)
  ...

you know that "i<16" is true, so you can optimize it to true.

If you have

i=...
if (i<16) {
  ... \ no change in i
  if (i<16)
    ...

In the second "i<16", you know that it is true, so you can optimize it
to true.

That's all fine and well.  Now consider:

int a[16];
i=...; \ too complex to determine the range of i
r=a[i];
if (i<16)
  ...

Here the compiler does not really know the range of i, but because it
occurs in a[i], it assumes that i<16 (otherwise the access a[i] would
be undefined behaviour), so it miscompiles the "i<16" to true (or at
least the version that miscompiled the SPEC program did).

However, in real programs out-of-bounds accesses and other undefined
behaviours do happen (not frequent for out-of-bounds accesses, but
still), and "optimizing" based on the assumption that they don't is
miscompilation.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#38647

On Monday, April 27, 2015 at 11:38:07 AM UTC+2, Anton Ertl wrote:
> mhx@iae.nl writes:
> >On Sunday, April 26, 2015 at 5:09:38 PM UTC+2, Anton Ertl wrote:
> >> krishna.myneni@ccreweb.org writes:
> >> >On Saturday, April 25, 2015 at 11:49:22 AM UTC-5, Anton Ertl wrote:
> >>                       but it goes something like:
> >> 
> >> Array a has indexes 0-15, and is indexed with a[i], so i can only have
> >> values 0-15 at that point (everything else would be undefined
> >> behaviour).  So obviously i<16 is always true and we can "optimize" it
> >> to true.
> >> 
> >> The compiler is oblivious to the fact that i<16 controls a loop that
> >> is "optimized" into an endless loop.
> >
> >I don't know if I am understanding your explanation
> >correctly, but by magical coincidence this matches a
> >problem in circuit simulation (SPICE) that I am
> >currently looking at.
> 
> Your description of the SPICE problem sounds very different from the
> problem in the compiler as I understand it.  Differentiability does
> not play a role in compilers.  I'll try to explain it again:

No, you were clear enough. I was focusing on the inability of the 
compiler to see how "I" was being used.

-marcel

[toc] | [prev] | [next] | [standalone]

#38662

On Mon, 27 Apr 2015 05:19:48 -0400, Anton Ertl  
<anton@mips.complang.tuwien.ac.at> wrote:

> I'll try to explain it again:
>
> If you have
>
> i=5;
> if (i<16)
>   ...
>
> you know that "i<16" is true, so you can optimize it to true.
>
> If you have
>
> i=...
> if (i<16) {
>   ... \ no change in i
>   if (i<16)
>     ...
>
> In the second "i<16", you know that it is true, so you can optimize it
> to true.
>
> That's all fine and well.  Now consider:
>
> int a[16];
> i=...; \ too complex to determine the range of i
> r=a[i];
> if (i<16)
>   ...
>
> Here the compiler does not really know the range of i, but because it
> occurs in a[i], it assumes that i<16 (otherwise the access a[i] would
> be undefined behaviour),

So?  Who said undefined behavior is incorrect?  There is a difference.

AIR, the C specifications say that undefined behavior can be
defined for a platform, i.e., correct on a specific platform.
E.g., it's common for most C platforms to allow a value to be
assigned to a pointer.  That's undefined behavior which is
defined for the specific host.

It's not the compiler's job to correct undefined behavior.
Undefined behavior might be exactly what the coder wanted.
The compiler's job is to do exactly what it was told to do
without changing the end result as understood by people.
Clearly, it fails here.

> so it miscompiles the "i<16" to true (or at
> least the version that miscompiled the SPEC program did).

Logic error.  Why should it assume "i<16" is true from "a[i]"?
It could just as easily assume "a[i]" is incorrect, but "i<16" isn't.

> However, in real programs out-of-bounds accesses and other undefined
> behaviours do happen (not frequent for out-of-bounds accesses, but
> still), and "optimizing" based on the assumption that they don't is
> miscompilation.

Agreed.


Rod Pemberton

-- 
Cars kill more people than guns in the U.S.
Yet, no one is trying to take away your car.

[toc] | [prev] | [next] | [standalone]

#38746

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> "0 ," costs about the same space as "cell allot", so memory constrains
>> are not the issue.
>
>Good point, that strengthens the case for standardization.
>
>>>accuse other implementations of "miscompiling" even though what they
>>>do is allowed by the standard.
>> That's not the usual complaint, so why are you mentioning it?
>> Spin-doctoring?
>
>Because we're in a thread involving that complaint being made against C
>compilers.  

No, the complaint was about miscompilation from newer versions of the
same compiler.

>> The usual complaint is about miscompilation from newer versions of the
>> same compiler.
>
>I think you're saying that if you run code that does UB under two
>versions of a compiler, the UB should be guaranteed to do the same thing
>both times.  But the whole concept of UB is that there is no such
>guarantee, even within one compiler version let alone two.  If there
>was, it wouldn't be UB any more.  What you really want is to eliminate
>UB from the specification.

No, I don't care at all about the specification.  If the C standard is
used as excuse for miscompilation, then it should be retracted.

I care about the compiler.  And I want a compiler that is developed
and maintained with the idea of compiling production programs as
intended.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [next] | [standalone]

#38540

Paul Rubin wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>> looking at the decompilation of VARIABLE in Gforth, VFX, and
>>> SwiftForth, the 0 comes from explicit initialization, not by
>>> accident.
>> There's a reason why all these Forths you looked at zero-initialize
>> variables: It makes the program behave deterministic.  The question is:
>> should we put this into the standard?
> 
> Those are all PC-hosted Forths with nothing like the memory constraints
> of traditional small-machine Forths.  It looks like Mikael's Flashforth
> telnet server isn't around any more, but I looked at the source code to
> the Atmega version and while I may have missed something, it looks to me
> like variables don't get zeroed when allocated.

Mecrisp initializes all variables (actually, with a fig-Forth-style 
VARIABLE, which takes the initializer).  Zeoring out all variables at boot 
is pretty cheap; usually, on embedded machines, you really, really want 
initialized variables.

Gforth EC does keep the variable region, too, so it's the same behavior.  
Bulk copying a block of data from Flash to RAM is definitely less expensive 
than writing initializer code for each variable.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#38265

In article <eee4002b-a756-4d33-94ca-5abfec0c76b9@googlegroups.com>,
 <krishna.myneni@ccreweb.org> wrote:
>On Thursday, April 16, 2015 at 9:10:31 PM UTC-5, Paul Rubin wrote:
>> krishna.myneni@ccreweb.org writes:
>> >    *sp-- = *(sp + 1)
>> > This lays out a pretty specific sequence for access and
>> > assignment. Are you saying that the LHS can be (partially) evaluated
>> > before the RHS?
>>
>> Yes, I believe so.  The condition that says thing A must be evaluated
>> before thing B is the presence of a sequence point between A and B.  And
>> it's explicit that an assignment operator (the = sign) does not create a
>> sequence point.  See the paragraph in that FAQ starting
>>
>>     The second sentence can be quite difficult to understand. It turns out
>>     that it disallows code like
>>             a[i] = i++
>>     ...
>>
>> for more discussion.  This is similar, I think.
>
>Hmm... I need to think about this some more. In the case of the statement,
>
>  a[i] = i++;
>
>the rationale for making it an invalid statement is, "there's no good
>way to define--either for our understanding or the compiler's--whether
>the access should take place before or after the incremented value is
>stored."
>
>It's not clear that the same rationale applies to,
>
>   *sp-- = *(sp + 1);
>
>but, maybe it does. To me, the statement above appears free of ambiguity
>since sp is not being modified on the RHS.

Firstly, and secondly it is modified on the left hand side after it
has been used.

I thought that = would constitute a sequence point, (which is false) but even
so there is nothing that is changed twice in this expression, which could cause
problems.
sp[1] is not changed (just fetched)
sp[0] is changed, but only once
sp is changed but only after all its uses

But I remember an example:
a = i + i-- ;

This is incorrect because it is unclear if the first or second term is evaluated
first.

This is sooo much clearer in Algol68.

That much I know that

*sp++ = *sp-- +*sp-- ;
(code for + ) smells bad.

>
>Krishna
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#38280

On Friday, April 17, 2015 at 5:35:08 AM UTC-5, Albert van der Horst wrote:
...
> That much I know that
> 
> *sp++ = *sp-- +*sp-- ;
> (code for + ) smells bad.
> ...


Well, that's clearly going overboard! :-)

Krishna

[toc] | [prev] | [next] | [standalone]

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

Back to top | Article view | comp.lang.forth

csiph-web