I am getting tired of simply pointing out factual errors, and this will be my last on this sub-thread.
In article , "Wilco Dijkstra" writes: |> |> > |> It's only when you implement the standard you realise many of the issues are |> > |> irrelevant in practice. Take sequence points for example. They are not even |> > |> modelled by most compilers, so whatever ambiguities there are, they simply |> > |> cannot become an issue. |> >
|> > They are relied on, heavily, by ALL compilers that do any serious |> > optimisation. That is why I have seen many problems caused by them, |> > and one reason why HPC people still prefer Fortran. |> |> It's only source-to-source optimizers that might need to consider these |> issues, but these are very rare (we bought one of the few still available). |> |> Most compilers, including the highly optimizing ones, do almost all |> optimization at a far lower level. This not only avoids most of the issues |> you're talking about, but it also ensures badly behaved programs are |> correctly optimized, while well behaved programs are still optimized |> aggressively.
I spent 10 years managing a wide range of HPC machines (and have advised on such uses for much longer). You are wrong in all respects, as you can find out if you look. Try Sun's and IBM's compiler documentation, for a start, and most of the others (though I can't now remember which).
Your claims that it isn't a problem would make anyone with significant HPC experience laugh hollowly. Few other people use aggressive optimisation on whole, complicated programs. Even I don't, for most code.
|> > |> Similarly various standard pendantics are moaning |> > |> about shifts not being portable, but they can never mention a compiler that |> > |> fails to implement them as expected... |> >
|> > Shifts are portable if you code them according to the rules, and don't |> > rely on unspecified behaviour. I have used compilers that treated |> > signed right shifts as unsigned, as well as ones that used only the |> > bottom 5/6/8 bits of the shift value, and ones that raised a 'signal' |> > on left shift overflow. There are good reasons for all of the |> > constraints. |> >
|> > No, I can't remember which, offhand, but they included the ones for |> > the System/370 and Hitachi S-3600. But there were also some |> > microprocessor ones - PA-RISC? Alpha? |> |> S370, Alpha and PA-RISC all support arithmetic right shifts. There |> is no information available on the S-3600.
All or almost all of those use only the bottom few bits of the shift. I can't remember the recent systems that had only unsigned shifts, but they may have been in one or of the various SIMD extensions to various architectures.
|> > Signed left shifts are undefined only if they overflow; that is undefined |> > because anything can happen (including the CPU stopping). Signed right |> > shifts are only implementation defined for negative values; that is |> > because they might be implemented as unsigned shifts. |> |> No. The standard is quite explicit that any left shift of a negative value |> is undefined, even if they there is no overflow. This is an inconsistency |> as compilers change multiplies by a power of 2 into a left shift and visa |> versa. There is no similar undefined behaviour for multiplies however.
From the standard:
[#4] The result of E1 Once we agree that it is feasible to emulate types, it is reasonable to |> mandate that each implemenation supports the sized types.That is clearly your opinion. Almost all of those of us with experience of when that was claimed before for the previous 'universal' standard disagree.
Regards, Nick Maclaren.