2007/10/11, Jim Wilson <[EMAIL PROTECTED]>:
Thanks for you helpful hints ! And I am sorry for such a late reply.
I have figured out this problem yesterday :-).
> Do we know for sure that the scheduler is failing here? Have you looked
> at -da RTL dumps to verify which pass is performing the inco
On Wed, Oct 10, 2007 at 04:22:45PM -0400, Kaveh R. GHAZI wrote:
> > But these things are rarely going to be a huge win, and I get
> > the impression that competing compiler developers only do them
> > when they help with standard benchmarks.
>
> Their loss. I agree with avoiding these micro opts
ÎâêØ wrote:
Well... Is there anything I miss or forget to do ?
Someone needs to step through code in a debugger and try to figure out
what is going wrong.
I made an initial attempt at that. I hacked gcc a little to try to
force a failure with a contrived testcase. The first thing I notice
On Wed, 10 Oct 2007, Joe Buck wrote:
> On Wed, Oct 10, 2007 at 12:12:25AM -0400, Kaveh R. GHAZI wrote:
> > One simplification I don't believe we do yet, that should always be a win,
> > is turning: sprintf (foo, "%c", bar); into:*foo = bar;
>
> You need the null terminator: foo[0] = bar; f
$ ./config.guess
i686-pc-linux-gnu
$gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared --enable-threads
--enable-languages=c,c++,fortran,java,objc,obj-c++,treelang
--enable-__cxa_atexit
Thread model: posix
gcc version 4.2.2
Linux d
David Daney <[EMAIL PROTECTED]> writes:
> There are two GCC tests for which I cannot explain the failures:
>
> FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times nasty_local 0
This is on my list of things to look at. It seems to fail on 32-bit
MIPS targets but not 64-bit ones.
> FAIL: gcc.target/mips/
I am pleased that the current trunk is looking to be in very good shape
for the mipsel-linux target:
http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00397.html
The gcc.c-torture/execute/loop-2[fg].c FAILures are due to kernel bugs.
gcc.c-torture/execute/mayalias-[23].c FAIL on x86_64-pc-linux
Hello,
I am currently looking for a topic for graduation thesis. I would
like it to be in the area of GCC code generation enhancements, and my
current best choice is providing predication support in selective
scheduling. If you have anything to suggest, I will be very glad to
hear; or maybe your
FYI this was libstdc++/33682, and was fixed with:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00415.html
Which was checked in yesterday. Please update your sources and try again.
best,
-benjamin
Jason Merrill wrote:
fafa wrote:
I tried to build gcc from the latest snapshot (gcc-4.3-20071005),
but I undefined the symbol "__GTHREAD_HAS_COND"
which is desribed in libstdc++-v3\ChangeLog as follows:
...
[!__GTHREAD_HAS_COND] Fall back to the old code, which deadlocks.
...
But libstdc
On Wed, Oct 10, 2007 at 12:12:25AM -0400, Kaveh R. GHAZI wrote:
> One simplification I don't believe we do yet, that should always be a win,
> is turning: sprintf (foo, "%c", bar); into:*foo = bar;
You need the null terminator: foo[0] = bar; foo[1] = 0;
But these things are rarely going to
> On 10/10/07, Wolfgang Gellerich <[EMAIL PROTECTED]> wrote:
> >
> > There is a conflict between the command line switches that turn
> off individual
> > optimization steps and their preconditions. Compiling a "hello
> world" with the
> > following options:
>
> This one issue is know, it was report
Hi Gcc Webmaster,
I estabilished an http mirror via rsync, updated four times a day with a
cron job, located in Utah (US), available at the URL
"http://gcc.bigsearcher.com/";, from my server bigsearcher.com;
Please add this mirror to the list of available mirror location.
Best regards,
Andrea
On 10/10/07, Wolfgang Gellerich <[EMAIL PROTECTED]> wrote:
>
> There is a conflict between the command line switches that turn off individual
> optimization steps and their preconditions. Compiling a "hello world" with the
> following options:
This one issue is know, it was reported as PR 33092.
There is a conflict between the command line switches that turn off individual
optimization steps and their preconditions. Compiling a "hello world" with the
following options:
-O1 -fno-tree-salias
causes gcc to fail with an internal consistency check. Pass return_slot has
PROP_alias in its pr
Joe Buck wrote:
> If your program has one or two dominant sprintf calls (as in the example
> that motivated this exercise), it pays off. But for a large program with
> thousands of {,s,f}printf calls, this kind of code size expansion could
> easily hurt instead of help. Without some data showing
Kaveh R. GHAZI wrote:
> On Mon, 8 Oct 2007, Heikki Linnakangas wrote:
>
>> sprintf(dest, "%d", arg1); -> a new function that does the same thing,
>> but without the overhead of parsing the format string. Like itoa on some
>> platforms. We could inline it as well. That would allow further
>> optimi
17 matches
Mail list logo
