What can't make sense is a /static/ "volatile const" which is /defined/
locally, rather than just declared.
The code in question sounds well-defined (but probably poor style) to me.
It is never OK to access a qualified object through an unqualified
pointer, but my understanding is that accessi
it. And while I think the compiler should be allowed to generate the
optimised code of 4.6 (i.e., the change is not a bug IMHO), I fully
understand the idea of generating the older, slower, but definitely correct
code of 4.5.
My understanding is that the standard mandates the old behavior, so
See here:
http://embed.cs.utah.edu/embarrassing/
There is a lot of data there. Please excuse bugs and other problems.
Feedback would be appreciated.
John Regehr
n functions (lots of 5 vs 2 bytes) seem to be
that gcc-head uses frame pointers and the other compiler doesn't.
Clearly for a fair comparison these settings should be the same.
I wanted to avoid playing flag games and go with -Os (or nearest
equivalent) for all compilers. Maybe that isn't right.
John Regehr
iable, but realistically if GCC catches most cases (which it almost
certainly will) the ones that slip past won't be too much of a problem.
No doubt there are plenty more improvements to make but hopefully this is
a good start.
John Regehr
less sensible code, the other
containing functions that can be automatically categorized as bogus.
Thanks,
John Regehr
Actually, I think they're very interesting - especially if they are
valid code, and one compiler optimizes them away, but the other
doesn't. You may have heard
seems like a dangerous practice.
Yes, it looks like icc does this. But so does gcc, see below. There is
no "add" in the generated code.
John Regehr
[reg...@babel ~]$ cat undef.c
int foo (int x)
{
int y;
return x+y;
}
[reg...@babel ~]$ current-gcc -O3 -S -o - undef.c -fomi
I would only be worried for cases where no warning is issued *and*
unitialized accesses are eliminated.
Yeah, it would be excellent if GCC maintained the invariant that for all
uses of uninitialized storage, either the compiler or else valgrind will
issue a warning.
We could test for violati
Also, we're not running LTO in any compiler and we removed all "static"
declarations from the code to keep compilers from making closed-world
assumptions.
John Regehr
+ code.
Thanks,
John Regehr
functions where one compiler generates bigger code than another?
Those are the pages that are supposed to contain useful information.
You're right, the aggregated results are not useful other than to get a
broad overview.
John Regehr
Hi Paolo,
I would also avoid testcases using volatile. Smaller code on these testcases
is often a sign of miscompilation rather than optimization. For example,
http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/076389.c is
miscompiled on GCC 3.4 and SunCC 5.10.
Yeah, there are defin
Yes, that was my point. If you want to make a separate section for
volatile, that would indeed be helpful.
I checked and there are about 37,000 harvested functions containing the
volatile qualifier. Next time, there will be even more since we'll be
harvesting code from the FreeBSD kernel in
Hi folks,
I've posted an updated code size comparison between LLVM, GCC, and
others here:
http://embed.cs.utah.edu/embarrassing/
New in this version:
- much larger collection of harvested functions: more than 360,000
- bug fixes and UI improvements
- added the x86 Open64 compiler
John
tensive testing, but there do exist compiler families
(such as those from IAR and Intel) where the C compiler loads from x and
the C++ compiler does not.
Thanks,
John Regehr
I'm not sure this follows. It's stated explicitly that "The
expression is evaluated and its value is discarded." How can you
evaluate the expression without reading the volatle?
I'm certainly not an expert on this material but I wouldn't think you'd
normally read a variable in order to evalua
olatile to win since
register doesn't actually mean anything (in the standard, at least).
John Regehr
On Tue, 20 Jan 2009, Ian Lance Taylor wrote:
baver writes:
A sample code listing is at the bottom of the email, as well as the lines we've
added to opcodes/mips-opc.c for our
This effort is relevant:
http://research.microsoft.com/en-us/um/people/jcondit/capriccio-sosp-2003.pdf
John Regehr
urce-level analysis in CIL and so is not quite analogous to
what you propose. However, it should give you some ideas about what kind
of results you can expect at the RTL level.
Our experience was that the bitwise domain is not that powerful. On the
other hand, it converges quickly compared to interva
rands, and examples of
offending values.
Let me know if more detail is needed or if it would be better for me to
file all 71 bug reports.
Thanks,
John Regehr
<../../gcc/alias.c, (1896:25)> : Op: +, Reason : Signed Addition Overflow,
BINARY OPERATION: left (int32): -2147483647 r
I think the messages are clear enough. You should probably wait a few days to
let people comment and/or fix, and then file PRs. 1 per file seems to be the
right granularity.
Thanks Eric, that's what I'll do.
John
anything new has popped
up.
John Regehr
http://blog.regehr.org/archives/697
John
23 matches
Mail list logo
