Mark Mitchell wrote:
> What cygcheck output would be helpful? I've never run cygcheck until
> just now, and it seems to have lots of options.
By the way, I don't see any reason to suspect that there's a Cygwin bug.
The situation is:
1. A Cygwin xterm does not have an associated console.
2. Yo
Christopher Faylor wrote:
> I don't see any reason why cygwin should be causing a console window to
> flash when spawn is used.
>
> Maybe this is something that should be pursued in the Cygwin list. The
> test cases will be useful but please also provide cygcheck output - as
> an attachment, ple
On Sun, Mar 12, 2006 at 03:27:02PM -0500, Ross Ridge wrote:
>Mark Mitchell wrote:
>>Cygwin Xterm
>>
>>parent spawn: Pops up DOS window.
>>parent nostd: No output from child.
>>parent std: Works.
>>
>>DOS Console
>>===
>>parent spawn: Works.
>>parent nostd: No output from child
Ross Ridge wrote:
> Cygwin rxvt
> ===
> parent spawn: Works.
> parent nostd: No output from child.
> parent std: Works.
>
> I wasn't able to test it with xterm, I don't have an X server handy,
> but it looks your problem is with xterm, not gcc.
CodeSoucery's 3.4-based code worked in all
On Sat, Mar 11, 2006 at 02:09:27PM -0800, Dan Kegel wrote:
> This is the list of problem reports (PRs) from GCC's bug tracking
> system that are known to be fixed in the 4.0.3 release. ...
>
> This was done for the previous two releases, and it's a nice touch.
> Can someone make the change?
I was
On 3/13/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Actually the best way of improving the inline heuristics is to get
> a real testcase (and not some benchmark) where the inline heuristics
> is messed up.
Ah, you mean a brand new testcase because PR-21195 wasn't good enough?
$ /usr/local/gcc-
Hi,
I'm using NetBSD3.0 and gcc3.3.3.
Following program exits when it receives SIGWINCH signal
if built with -foptimize-sibling-calls.
$ gcc -Wall -foptimize-sibling-calls -g a.c
$ ./a.out &
[1] 15605
$ pkill -WINCH a.out
[1]+ Done ./a.out
If built without -f
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > On 3/12/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
| > > > Yes, why is the benchmark not valid?
| > >
| > > It is valid. We should understand why this behavior has changed so
drastically.
| > This benchmark maybe useless, it still exposes a
tbp <[EMAIL PROTECTED]> writes:
| On 3/12/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
| > > Yes, why is the benchmark not valid?
| >
| > It is valid. We should understand why this behavior has changed so
drastically.
| This benchmark maybe useless, it still exposes a weakness of gcc4. At
| le
>
> On 3/12/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> > > Yes, why is the benchmark not valid?
> >
> > It is valid. We should understand why this behavior has changed so
> > drastically.
> This benchmark maybe useless, it still exposes a weakness of gcc4. At
> least it's not news to me:
>
On 3/12/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> > Yes, why is the benchmark not valid?
>
> It is valid. We should understand why this behavior has changed so
> drastically.
This benchmark maybe useless, it still exposes a weakness of gcc4. At
least it's not news to me:
http://gcc.gnu.org
Dear GCC developers,
I would like a compiler that produces identical object files when run
several times with identical source files and headers.
I noticed the documentation of -frandom-seed in the GCC man page and
found a simple way to make compiles reproducible while still reliably
matching obj
Mark Mitchell wrote:
>Cygwin Xterm
>
>parent spawn: Pops up DOS window.
>parent nostd: No output from child.
>parent std: Works.
>
>DOS Console
>===
>parent spawn: Works.
>parent nostd: No output from child.
>parent std: No output from child.
This is what I got using your c
Bradley Lucier wrote:
Please let us know ([EMAIL PROTECTED]) if there are any issues
with the new import. It has been tested on x86, x86-64 and ppc-32 on
GNU/Linux and sun-sparc-solaris8 multilib and darwin-pcc 32-bit. But
more testing is helpful (it also includes an update to the fdlibm
library)
Please let us know ([EMAIL PROTECTED]) if there are any issues
with the new import. It has been tested on x86, x86-64 and ppc-32 on
GNU/Linux and sun-sparc-solaris8 multilib and darwin-pcc 32-bit. But
more testing is helpful (it also includes an update to the fdlibm
library).
I don't know if it
On 3/12/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> So, I tried to reproduce the slowdown and on i686 get all
> memcpy/memset inlined on 3.3, 3.4, 4.0 and 4.1. On ppc I get calls to
> memcpy/memset in all cases. This might be more a glibc issue I think.
So my suggestion is to file a bugzil
On 12 Mar 2006 18:09:26 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
> "Richard Guenther" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | this one should be measured. But note that the benchmark is a
> | no-op and can be validly optimizes to int main() { return 0; } by the
> | compiler. This is
"Richard Guenther" <[EMAIL PROTECTED]> writes:
[...]
| this one should be measured. But note that the benchmark is a
| no-op and can be validly optimizes to int main() { return 0; } by the
| compiler. This is why I call it a stupid benchmark.
please let's refrain from getting into that back ho
On 3/12/06, Ernest L. Williams Jr. <[EMAIL PROTECTED]> wrote:
> On Sun, 2006-03-12 at 15:17 +0100, Richard Guenther wrote:
> > On 3/12/06, Ernest L. Williams Jr. <[EMAIL PROTECTED]> wrote:
> > > > In any case: memcpy/memset inlining is broken in current GCC at least
> > > > on athlon arch.
> >
> >
On Sun, 2006-03-12 at 15:17 +0100, Richard Guenther wrote:
> On 3/12/06, Ernest L. Williams Jr. <[EMAIL PROTECTED]> wrote:
> > > In any case: memcpy/memset inlining is broken in current GCC at least
> > > on athlon arch.
>
> let's say it changed. Also memcpy/memset "inlining" is not regular inlin
On 3/12/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
>
> It is valid. We should understand why this behavior has changed so
> drastically.
>
I've attached assembler output from different compiler versions:
3.4.5-athlon-xp: gcc-3.4.5 -O3 -march=athlon-xp
3.4.5-pentium4: gcc-3.4.5 -O3 -march=pe
On 3/12/06, Ernest L. Williams Jr. <[EMAIL PROTECTED]> wrote:
> > In any case: memcpy/memset inlining is broken in current GCC at least
> > on athlon arch.
let's say it changed. Also memcpy/memset "inlining" is not regular inlining
but driven by completely different heuristics.
> Yes, why is the
> Yes, why is the benchmark not valid?
It is valid. We should understand why this behavior has changed so drastically.
Gr.
Steven
On Sun, 2006-03-12 at 16:55 +0300, Nickolay Kolchin wrote:
> On 3/12/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > On 3/12/06, Nickolay Kolchin <[EMAIL PROTECTED]> wrote:
> > > During "bashmark" memory benchmark perfomance analyze, I found 100x
> > > perfomance
> > > regression between gcc 3
On 3/12/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 3/12/06, Nickolay Kolchin <[EMAIL PROTECTED]> wrote:
> > During "bashmark" memory benchmark perfomance analyze, I found 100x
> > perfomance
> > regression between gcc 3.4.5 and gcc 4.X.
> >
> > -- test_cmd.cpp (simplified bashmark me
On 3/12/06, Nickolay Kolchin <[EMAIL PROTECTED]> wrote:
> During "bashmark" memory benchmark perfomance analyze, I found 100x perfomance
> regression between gcc 3.4.5 and gcc 4.X.
>
> -- test_cmd.cpp (simplified bashmark memory RW test) ---
> #include
> #include
>
> template
> static vo
Hello GCC developers,
Has anyone ever tried to build a scripting interface into the guts of
GCC with something like SWIG ?
I am currently working on a program where I want to embed a portion of
another program into my project. It would be very nice if I could use a
static call graph from my entry
27 matches
Mail list logo
