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
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 memory RW test)
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.4.5 and gcc 4.X.
Yes, why is the benchmark not valid?
It is valid. We should understand why this behavior has changed so drastically.
Gr.
Steven
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
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
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 inlining
but
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.
let's say it
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 hole.
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 bugzilla
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
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
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 code and
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
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:
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
| least
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 weakness of
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
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?
$
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 the
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 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.
parent std: No
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, please.
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. You
--- Comment #10 from pluto at agmk dot net 2006-03-12 09:14 ---
so, 4.1.0 was released with bootstrap blocker.
alpha-linux bootstrap is possible only with configure-hack.
-errors=`(${CC} -c conftest.adb) 21 || echo failure`
+errors=`(${CC} -c conftest.adb) 2/dev/null || echo failure`
--- Comment #17 from h dot m dot brand at xs4all dot nl 2006-03-12 12:26
---
Super! I moved binutil's ld out of the way, removed those two default CCFLAGS,
Conf/Build/Install worked fine.
r3:/pro/3gl/CPAN/perl-current 129 /usr/local/pa20_64/bin/gcc --version
gcc (GCC) 4.1.0
Copyright
int main()
{
#pragma omp parallel
{
#pragma omp for ordered
for(int i = 0; i 1; i++)
;
}
}
produces 44 bytes memory leak because after the omp for ordered
gomp_work_share_start() gets called and allocs a struct gomp_work_share
which never gets freed because neither
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-12 14:50 ---
_mm_store_ss((float*)(((float*) rays[0]) + 0), (pvx));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26650
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-12 14:52 ---
I don't think rays[0] is a POD so this might turn out to be a bug in your code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26650
--- Comment #5 from schwab at suse dot de 2006-03-12 15:45 ---
vec_t is a non-POD type because it has a user-defined copy assignment operator,
thus ray_t can't be a POD either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26650
--- Comment #10 from paolo at gcc dot gnu dot org 2006-03-12 16:56 ---
Subject: Bug 26532
Author: paolo
Date: Sun Mar 12 16:56:08 2006
New Revision: 111979
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111979
Log:
2006-03-12 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #11 from pcarlini at suse dot de 2006-03-12 16:57 ---
Fixed for 4.1.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
Exact version of GCC: gcc-4.2-20060304
Problem since: unknown (gcc-4.0.3-20060212 compiles OK both under -O2
and -O3)
Built with: ./configure --prefix=/usr/local; make bootstrap
Hardware: Athlon Thunderbird 1.33 GHz; 256 MB
Compilation of the attached code (adapted from
http://gcc.gnu.org/projects/tree-ssa/vectorization.html
example3)
* works and vectorizes with gcc-4.0.1
g++ -O -msse -ftree-vectorizer -c vect.cpp
* works with gcc-4.1.0 and 4.2.0-20060311 if one of the above options is
omitted
(but does not or
--- Comment #1 from hjl at lucon dot org 2006-03-12 17:42 ---
I don't think
__asm__ ( ldmxcsr %0\n : : X (trunc_mxcsr) );
will work well. Can you try
__asm__ (ldmxcsr %0 : : m (*trunc_mxcsr));
--
hjl at lucon dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-12 17:53 ---
This comes down to PR 19893.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26654
--- Comment #2 from mtodorov at alu dot hr 2006-03-12 17:57 ---
Subject: Re: Wrong assembly generated with -O2, -O OK for
cinelerra source item
On Sun, 12 Mar 2006, hjl at lucon dot org wrote:
--- Comment #1 from hjl at lucon dot org 2006-03-12 17:42 ---
I don't think
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-12 18:01 ---
(In reply to comment #2)
Any idea?
The inline-asm is just wrong. X means any register or memory which means it
could pick esp or xmm3 without caring that much.
Also the code is hiding all the mmx register uses
--- Comment #4 from mtodorov at alu dot hr 2006-03-12 18:06 ---
Subject: Re: Wrong assembly generated with -O2, -O OK for
cinelerra source item
On Sun, 12 Mar 2006, pinskia at gcc dot gnu dot org wrote:
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-12 18:01
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot
|dot org
--- Comment #5 from mtodorov at alu dot hr 2006-03-12 18:22 ---
Subject: Re: Wrong assembly generated with -O2, -O OK for
cinelerra source item
Why then -O passes, and does it generate right code? Does 4.0.3 do the
worng thing when compiling this without complaint?
How can I
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-12 18:25 ---
(In reply to comment #5)
IMHO this is a bug after all, since behavior is inconsitent (-O and -O2 do
nto work the same), and code is generated that breaks later stage.
no it is not a bug as X in asm says any
--- Comment #7 from steven at gcc dot gnu dot org 2006-03-12 18:30 ---
The problem is in your asm constraints. You allow GCC to do certain things
with the wrong constraints. Now, it may or may not do those things, depending
on what it thinks is best. Apparently it thinks one thing is
Summary: ICE in gcc
Version: gcc-4.2.0 20060304
Hardware: Athlon Thunderbird 1.33 GHz, 256 MB
OS: GNU/Linux Debian Knoppix kernel 2.6.11
Command Line:
gcc -O3 -g -Wall -Wno-switch -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o snow.o snow.c
--- Comment #8 from mtodorov at alu dot hr 2006-03-12 18:41 ---
Subject: Re: Wrong assembly generated with -O2, -O OK for
cinelerra source item
On Sun, 12 Mar 2006, steven at gcc dot gnu dot org wrote:
--- Comment #7 from steven at gcc dot gnu dot org 2006-03-12 18:30
--- Comment #2 from dubos at lmd dot polytechnique dot fr 2006-03-12 18:42
---
(In reply to comment #1)
This comes down to PR 19893.
Thanks for commenting on this. I fully agree that arrays of aint should be
rejected. The point is that there are no arrays here, only pointers.
The
--- Comment #1 from mtodorov at alu dot hr 2006-03-12 18:45 ---
Subject: Re: ICE in ix86_secondary_memory_needed, at
config/i386/i386.c:16446
I am truly sorry, but resulting snow.i is 11389 lines, 325K long, so it
does not fit into comment.
I don't know what to do (novice bug
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-12 18:46 ---
(In reply to comment #1)
I don't know what to do (novice bug reporter).
There is a link called Create a New Attachment which you should be using.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26655
--- Comment #3 from mtodorov at alu dot hr 2006-03-12 18:53 ---
Created an attachment (id=11026)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11026action=view)
Created snow.i with -save-temps
gcc -O3 -g -Wall -Wno-switch -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-12 18:58 ---
This is invalid inline-asm:
static inline uint64_t read_time(void)
{
uint64_t a, d;
asm volatile( rdtsc\n\t
: =a (a), =d (d)
);
return (d 32) | (a 0x);
}
-
The correct way to implement this
--- Comment #5 from steven at gcc dot gnu dot org 2006-03-12 19:03 ---
Note that we should never ICE after an error. So this is still also a bug in
GCC itself.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
I'm on Gentoo Linux, my the use flags affecting GCC are fortran and nls. I
have tried the following with -O2. If I write a piece of code that looks like
one of these :
example 1 : a = (b == 1 ? 1 : 0);
example 2 : a = (b == 1 ? 2 : 0);
example 3 : if( b == 1 )
a = 2;
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-12 19:32 ---
Confirmed, not a regression, short testcase:
typedef unsigned long long int uint64_t;
uint64_t read_time(void)
{
uint64_t a, d;
asm volatile( rdtsc\n\t : =a (a), =d (d) );
}
--
pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-12 19:33 ---
Could you give a testcase which can be compiled?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26656
--- Comment #7 from mtodorov at alu dot hr 2006-03-12 19:33 ---
Subject: Re: ICE in ix86_secondary_memory_needed, at
config/i386/i386.c:16446
On Sun, 12 Mar 2006, pinskia at gcc dot gnu dot org wrote:
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-12 18:58
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-12 19:35 ---
(In reply to comment #7)
Confirmed. This workaround works.
It is not a work around :). It is correcting the inline-asm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26655
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26640
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-12 19:41 ---
it is not that slow at least on my two machines but it is still about 2x slower
than when java is disabled.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-12 19:44 ---
I should note that the diagnostic is produced in varasm.c while it really
should be produced in the front-end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24293
--- Comment #7 from steven at gcc dot gnu dot org 2006-03-12 19:53 ---
Good luck Erik.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
GCC host
--- Comment #9 from mtodorov at alu dot hr 2006-03-12 19:56 ---
Subject: Re: ICE in ix86_secondary_memory_needed, at
config/i386/i386.c:16446
It is not a work around :). It is correcting the inline-asm.
Mais oui. :-)
M.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26655
--- Comment #4 from jonas dot mellin at his dot se 2006-03-12 19:58 ---
(In reply to comment #3)
Your compiler simply runs out of memory.
The compiler gives an error message to leave a message on bugzilla when it runs
out of memory instead of saying that it ran out of memory. I
-fopenmp use does not cause gcc to automatically link with gomp, this is
because Darwin defines its own LINK_COMMAND_SPEC which does not include the
following section from the generic version:
%{fopenmp:%:include(libgomp.spec)%(link_gomp)}
--
Summary: With -fopenmp, gcc does not link
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-12 20:04 ---
I will take care of this once my current bootstrap/test has finished.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
During bashmark memory benchmark perfomance analyze, I found ~100x perfomance
regression between gcc 3.4.5 and gcc 4.X.
Compiler options: -march=athlon-xp -O3
test_cmd execution time:
- GCC 3.4.5: 0.43user 0.00system 0:00.44elapsed
- GCC 4.0.2: 34.83user 0.68system 0:36.09elapsed
- GCC 4.1.0:
--- Comment #1 from nbkolchin at gmail dot com 2006-03-12 20:12 ---
Created an attachment (id=11027)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11027action=view)
test_cmd.cpp
testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26658
--- Comment #2 from nbkolchin at gmail dot com 2006-03-12 20:13 ---
Created an attachment (id=11028)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11028action=view)
test_cmd-3.4.5.ii
-save-temps output from gcc 3.4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26658
--- Comment #3 from nbkolchin at gmail dot com 2006-03-12 20:14 ---
Created an attachment (id=11029)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11029action=view)
test_cmd-4.1.0.ii
-save-temps output from gcc 4.1.0 and gcc 4.0.2 (they are different only in
version numbers)
--
--- Comment #6 from tbptbp at gmail dot com 2006-03-12 21:03 ---
You're right, but that's a _mm_store_ss/movss asking for a 4 bytes alignment
(which is satisfied) and not a movaps with a 16 bytes constraint. The latter
are what are causing problems.
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-12 21:07 ---
apart from visibility stuff, both preprocessed sources are equal and do not
contain inline memcpy/memset from glibc.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-12 21:12 ---
Confirmed. 3.4.5 requires -march=athlon-xp to inline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26658
--- Comment #2 from dominic dot quiet at gmail dot com 2006-03-12 21:23
---
Created an attachment (id=11030)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11030action=view)
Benchmark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26656
--- Comment #3 from dominic dot quiet at gmail dot com 2006-03-12 21:31
---
Created an attachment (id=11031)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11031action=view)
My results without -march=athlon-xp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26656
--- Comment #7 from tbptbp at gmail dot com 2006-03-12 21:35 ---
For clarification i should say that rt::mono::ray_t which uses vec_t etc, isn't
a source of trouble, it's part of the single ray path where mostly scalar ops
are used.
There's a symmetrical set of structures in rt::packet
--- Comment #4 from dominic dot quiet at gmail dot com 2006-03-12 21:41
---
Created an attachment (id=11032)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11032action=view)
My results with -march=athlon-xp
The behavior of the ?: compared to without -march=athlon-xp may be a sign
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-12 21:45 ---
Your benchmark is bad news as one rand is not a good randomizer for the lower
bits, oh after 127, the condition for your benchmark becomes always true which
is why it gets slower again.
--
pinskia at gcc dot gnu
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-12
22:05 ---
Subject: Re: 4.1.0 doesn't build in 64bit on PA-RISC
(I tried to close this bug, but I got re-assign errors. Using Opera 9)
Don't. This is a regression. It's caused by the addition of EH exception
gcc.target/powerpc/ppc-vector-memset.c fails on the mainline after one of the
follow patches:
+2006-03-10 Richard Guenther [EMAIL PROTECTED]
+
+ PR middle-end/26565
+ * builtins.c (get_pointer_alignment): Handle component
+ references for field alignment.
+
+2006-03-10 Jorn
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenther at suse dot de
Target Milestone|---
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-12 22:24 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dominic dot quiet at gmail dot com 2006-03-12 22:25
---
Created an attachment (id=11033)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11033action=view)
Fixed benchmark
I fixed my benchmark. You are right about the condition always being true after
127. I was
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-12 22:25 ---
This fails also on powerpc64-linux-gnu so this is not darwin specific.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dominic dot quiet at gmail dot com 2006-03-12 22:26
---
Created an attachment (id=11034)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11034action=view)
My new results without -marh=athlon-xp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26656
create an empty file called t.hh.
create a file called t1.cc with:
#include t.hh
extern __inline__ int
stat (__const char *__path, struct stat *__statbuf) throw ()
{
--
compile the PCH like:
g++ t.hh
and the source file with:
g++ t1.cc -save-temps --param ggc-min-expand=0 --param
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-13 00:52 ---
This worked with 4.1.0 20060208.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-13 00:53 ---
I should note I found this wil trying to figure out why a libstdc++ testcase
was failing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26660
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-13 01:41 ---
Related to PR 10591.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dje at gcc dot gnu dot org 2006-03-13 02:10 ---
AIX 4.2 configuration does not include aix64.opt to define 64BIT.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-13 02:41 ---
Just a note the reason why this is ICE on valid and not just ICE on invalid is
because the source to t1.cc could also be:
#include t.hh
extern __inline__ int
stat (__const char *__path, struct stat *__statbuf) throw
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-13 02:42 ---
I am almost wanting to say this was caused by the openmp merge but I don't know
for sure.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2006-03-13 04:22
---
Reopening, the new test case given in Comment #14 is a valid case. Will submit
patch shortly.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from patchapp at dberlin dot org 2006-03-13 04:35 ---
Subject: Bug number PR26509
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00724.html
--
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2006-03-13 04:36
---
Changing sunnary to reflect new case.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
When reading sequential formatted files, and the last line of the file does not
contain an LF or CR, and EOF error occurs when there is available format
specifiers, but no data. Test case to follow.
--
Summary: Sequential formatted read goes too far
Product: gcc
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-03-13 04:48
---
Created an attachment (id=11035)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11035action=view)
Example showing read statement that fails.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26661
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-03-13 04:50
---
Created an attachment (id=11036)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11036action=view)
Example data file to read.
Note: The error only occurs if there are no LF or CRLF on the last line of data
The following code produces possibly wrong-code with -O2 on Apple's g++-3.3,
but I'm not sure if this is reproducible on other platforms. First, I'm
pasting the unpreprocessed source, will attach .ii momentarily. (Yes, I
realize 3.3 is closed, but I'd like to know if this is a known problem, or
--- Comment #1 from fang at csl dot cornell dot edu 2006-03-13 07:25
---
Created an attachment (id=11037)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11037action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26662
99 matches
Mail list logo
