On Fri, 10 Nov 2006, Mike Stump wrote:
On Nov 10, 2006, at 12:46 PM, H. J. Lu wrote:
Will use C++ help or hurt compiler parallelism? Does it really matter?
I'm not an expert, but, in the simple world I want, I want it to not matter
in the least. For the people writing most code in the compi
On Wed, 24 Jan 2007, [GB2312] ÎâêØ wrote:
I am working on gcc 4.0.0. I want to use gcc to intercept each call to
read, and taint the data readed in. For example:
transform
read(fd, buf, size)
to
read(fd, buf, size)
if(is_socket(fd))
taint(buf, size)
So, wh
On Wed, 24 Jan 2007, [GB2312] ÎâêØ wrote:
I know valgrind, it is an emulator ,but we are restricted not to use
an emulator. :-(
Well, for some definition of "emulator".
Nick
On Mon, 19 Mar 2007, Doug Gregor wrote:
> It's going to have a big performance impact. To extract a 9-bit value,
> the compiler will need to do a lot of masking every time it accesses
> the TREE_CODE.
So, about 16% slower with --enable-checking, 5% slower with
--disable-checking.
Subcodes mi
On Mon, 19 Mar 2007, Doug Gregor wrote:
But what is the solution? We can complain about performance all we
want (and we all love to do this), but without a plan to fix it we're
just wasting effort. Shall we reject every patch that causes a slow
down? Hold up releases if they are slower than thei
On Tue, 20 Mar 2007, Nicholas Nethercote wrote:
GCC is a very ambitious compiler:
- it supports a lot of platforms
- it supports a lot of languages
However, most users do not use most of those combinations. The problem is
that supporting all these combinations hurts the specific
On Thu, 21 Mar 2007, Ian Lance Taylor wrote:
I think you may misunderstand the mission statement. The mission
statement is not a technical roadmap. It's a statement of general
goals. If the community has a serious disagreement, the mission
statement can sometimes help clarify matters.
[...]
T
On Wed, 21 Mar 2007, Paul Brook wrote:
The problem is that I don't think writing a detailed "mission statement" is
actually going to help anything. It's either going to be gcc contributors
writing down what they're doing anyway, or something invented by the SC or
FSF. I the latter case nothing's
Several alternatives were tried -- the sub-code approach, the 9-bit
approach, the 16-bit approach. It might be interesting to try using
Cachegrind or Callgrind to better understand why the performance changes
occurred.
Nick
On Mon, 14 Mar 2005, J. Hart wrote:
Valgrind is an excellent product as far as it goes, but is x86 only, and
apparently lacks the sort of stack checking that Purify and Checker have.
Valgrind is currently being officially ported to several other platforms.
We hope to have AMD64/Linux and PPC32/Linu
On Tue, 12 Apr 2005, Karel Gardas wrote:
cachegrind can also be used to estimate the number (though, not sure
how accurate it is, possibly not very). I use Shark to actually get
the real number.
Perhaps it's possible that cachegrind is wrong or cache misses differ from
platform to platform, but I
Hi,
I've been looking at GCC's use of sign-extensions when dealing with
integers smaller than a machine word size. It looks like there is room
for improvement.
Consider this C function:
short g(short x)
{
short i;
for (i = 0; i < 10; i++) {
x += i;
}
On Mon, 18 Apr 2005, Steven Bosscher wrote:
I've been looking at GCC's use of sign-extensions when dealing with
integers smaller than a machine word size. It looks like there is room
for improvement.
Is your problem the same as the one described on one of the Wiki pages,
"http://gcc.gnu.org/wiki/E
On Tue, 28 Jun 2005, Joe Buck wrote:
There is no such assumption. Rather, we assume that overflow does not
occur about what happens on overflow. Then, for the case where overflow
does not occur, we get fast code. For many cases where overflow occurs
with a 32-bit int, our optimized program be
On Wed, 29 Jun 2005, Daniel Berlin wrote:
So i would advise anyone arguing against turning on -fwrapv simply
because it doesn't seem to hurt us at O2.
And i'll again point out that the exact opposite is the default in every
other compiler i'm aware of.
Sorry, I couldn't parse those sentences.
On Sat, 2 Jul 2005, Florian Weimer wrote:
I am puzzled, why would *ANYONE* who knows C use int
rather than unsigned if they want wrap around semantics?
Both OpenSSL and Apache programmers did this, in carefully reviewed
code which was written in response to a security report. They simply
didn
Hi,
There was recently a very long thread about the overflow behaviour of
signed integers in C. Apparently this is undefined according to the C
standard. I searched the standard on this matter, and while I did find
some paragraphs that described how unsigned integers must wrap around upon
o
On Mon, 11 Jul 2005, Dave Korn wrote:
There was recently a very long thread about the overflow behaviour of
signed integers in C. Apparently this is undefined according to the C
standard. I searched the standard on this matter, and while I did find
some paragraphs that described how unsigned i
On Mon, 11 Jul 2005, Daniel Berlin wrote:
Also, a web-browser is much slower than an info-browser, especially
when doing searchs.
You must be close to the only user i've met who uses the info browser :)
I use it. Info pages suck in many ways, but they're fast to load from an
xterm, fast to
Hi,
I've been looking at the gcc.c-torture tests, it seems some of them rely
on undefined behaviour. For example, 920612-1.c looks like this:
f(j)int j;{return++j>0;}
main(){if(f((~0U)>>1))abort();exit(0);}
AIUI, this passes the largest possible positive integer to f(), which then
incre
On Tue, 12 Jul 2005, Joseph S. Myers wrote:
My question is: what exactly is gcc.c-torture testing? It seems to be
That GNU C code compiles or executes as expected for GNU C.
Is there a definition for GNU C? implement-c.texi and extend.texi have
some information about this, are there any
On Fri, 5 Aug 2005, Dave Korn wrote:
Hallo,
what must I do for becomming the GNU Fortran Compiler?
Sincerely, Hans.
To become the compiler, you must _think_ like the compiler.
It's an easy mistake to make for Germans speaking English, because the
German verb "bekommen" means "to get, obtain
On Tue, 30 Aug 2005, Rafael ?vila de Esp?ndola wrote:
One problem is that compiler technology generally requires more background
then OS:
1) the new O(1) scheduler
2) the new PCI interface
or
1) the new SSA based intermediate representation
2) the new DFA based pipeline hazard recognizer
I don
On Tue, 13 Sep 2005, Steven J. Hill wrote:
You might want to first make sure that your program has no memory
access errors. You could try building it for x86 and debugging
with valgrind, to see if that catches anything.
A good idea. I built it for x86. Unfortunately, from the output it
appear
On Sat, 1 Oct 2005, [EMAIL PROTECTED] wrote:
C++ would be a better language if the boolean type did not implicitly
convert from int. For example, many novice programmers make the
mistake.
if (i = j) dosomething(); // Should be i == j
If conversion to boolean required explicit this would all
On Mon, 21 Nov 2005, Giovanni Bajo wrote:
I didnt get your point. I am allocating space only for 400 inregers
then as soon as in the loop if it crosses the value of 400 , it should
have given a segementation voilation ?
No. For that to happen, you need some memory checker. GCC has -fmudflap, t
On Mon, 28 Nov 2005, Joe Buck wrote:
On Mon, 28 Nov 2005, Mark Mitchell wrote:
We're collectively putting a lot of energy into performance
improvements in GCC. Sometimes, a performance gain from one patch gets
undone by another patch -- which is itself often doing something else
beneficial.
On Mon, 6 Oct 2008, Kai Henningsen wrote:
You're not the first person to come up with this idea, and you
probably won't be the last, but it's a misbegotten idea, and there's
In fact, I believe it came up around the time when COBOL was invented.
And you'll notice that it didn't get implemente
On Tue, 18 Nov 2008, H.J. Lu wrote:
I used malloc to create my arrays instead of creating the in the stack. My
program is working now but it is very slow.
I use two-dimensional arrays. The way I access element (i,j) is:
array_name[i*row_length+j]
The server that I use has 16GB ram. The ulimit
On Sat, 17 Jun 2006, Marc Alff wrote:
2) Licensing
For technical reasons, I can not use the gcov library itself,
and plan to implement code to read/write the files the GCOV program needs.
Then why do you need to use the gcov file formats?
Nick
On Thu, 28 Sep 2006, Tzi-cker Chiueh wrote:
We have considered the bound instruction in the CASH project. But
we found that bound instruction is slower than the six normal
instructions it is meant to replace for range checking. For example, the
bound instruction on a 1.1 GHz PIII machine require
On Wed, 23 Feb 2005, Doug Graham wrote:
Regarding memory consumption, perhaps libmudflap's default backtrace
parameter should be set to zero, for both speed and space reasons.
If it's storing all the backtraces that is burning up all the memory,
another approach might be to keep a separate hash tab
On Wed, 16 Jan 2008, Tom Tromey wrote:
Kaveh> A valgrind suppression only silences the error for valgrind. What if
Kaveh> someone uses another memory checking tool? Better to fix it for real
Kaveh> IMHO.
Add suppressions for all of them. Any decent memory checker has to
account for the reali
On Thu, 13 Mar 2008, David Woodhouse wrote:
I could never understand why anyone would use anything but CVS (if that
works for them), or git. The VCS-du-jour craze just confuses me.
Version control is complicated, much more so than it first appears. There's
a very large design space. Knowing
On Thu, 31 May 2007, Andrew Haley wrote:
No. Speed is always measured in reciprocal units of time: s^-1.
A program that runs in 10 seconds has a speed of 0.1 s^-1. Thus, 200%
is (0.1 * 200/100) s^-1 faster, giving a speed of 0.3 s^-1.
Um, 0.1 * 200/100 = 0.2.
Amdahl's Law says:
speedup =
On Fri, 13 Jul 2007, Alexandre Oliva wrote:
One way to view it: the license is a feature. Therefore changing the
license is changing a feature.
Every release of GCC in the past decade (and then some) was GPLv2+.
GPLv3 has always been one of the options.
Anyone who had their heads in the san
On Thu, 12 Jul 2007, Michael Eager wrote:
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.
This seems to confabulate the meaning of v
On Sun, 2 Dec 2007, Andreas Schwab wrote:
| 2007-11-30 Jan Hubicka <[EMAIL PROTECTED]>
|
| * ggc-common.c (dump_ggc_loc_statistics): Reset ggc_force_collect
| flag.
How could a newcomer guess why the gcc_force_collect flag needs to be
reset?
That is supposed to be written in
On Mon, 3 Dec 2007, Andi Kleen wrote:
Commit logs are basically invisible;
That's just a (fixable) problem in your coding setup. In other
projects it is very common to use tools like cvs annotate / cvsps /
git blame / git log / etc. to find the reasons for why code is the way
it is. In fact in
On Wed, 12 Dec 2007, J.C. Pizarro wrote:
[...]
* "executable" means "it's from an execution to death of the e-prisoner"?
* "Indirect call promotion" means "this promotion indirectly e?"?
* "Dead variable elimination" means "elimination variable of R.I.P.s"?
* etc.
J.C.Pizarro i though
40 matches
Mail list logo
