Hi, everyone
I'm a guy working on IA64 with gcc version 4.1.1, and I need to do
some instrumentation to do information flow tracking.
Instrumentation is insert after register allocation and before the
second scheduling, I suppose gcc will automatic maintain data flow,
and it seems to be
except
Hi,
I'm working on IA64 with GCC-4.1.1; what I do is to instrument some
sensitive instructions (e.g. memory access) to do information flow
tracking. As I insert the instrumentation after register allocation,
I need to allocate general registers and predicates myself; for
corner cases in
Hi,
I'm working on IA64 with GCC-4.1.1; what I do is to instrument some
sensitive instructions (e.g. memory access) to do information flow
tracking. As I insert the instrumentation after register allocation,
I need to allocate general registers and predicates myself; for
corner cases in
Hi, There!
For testing reasons I started to build gcc-4.1.1 on an embedded ppc system
which has a working
gcc-4.2.1 on it already:
$ gcc -v
Using built-in specs.
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.2.1/configure --prefix=/usr --libexecdir=/usr/lib
On Mon, 8 Oct 2007, Gerald Pfeifer wrote:
As others noted, MetaHTML can be made to work on a current GNU/Linux
system, and while this probably will not be our long term strategy, I
am trying to brush up my scripts/patches that will allow for this more
easily and then share this with you and
Hi,
While profiling a test case of exporting data from PostgreSQL, I noticed
that a lot of CPU time was spent in sprintf, formatting timestamps like
2007-10-01 12:34. I could speed that up by an order of magnitude by
replacing the sprintf call with tailored code, but it occurred to me
that we
On Monday 08 October 2007 13:50, Heikki Linnakangas wrote:
While profiling a test case of exporting data from PostgreSQL, I noticed
that a lot of CPU time was spent in sprintf, formatting timestamps like
2007-10-01 12:34. I could speed that up by an order of magnitude by
replacing the sprintf
Heikki Linnakangas [EMAIL PROTECTED] writes:
I don't have much experience with GCC hacking, but I did put together a
prototype to do some of the above, and it does look like you can get
very significant speedups. Before I continue with that, has something
like this been proposed before? I
Steve Kenton [EMAIL PROTECTED] writes:
Is it ever possible to build libmudflap, libssp, or libgomp when
inhibit_libc is set?
It seems unlikely.
If not, is is reasonable to add a check to the top level configure to detect
situations that will cause gcc configure to set inhibit_libc and add
Denys Vlasenko wrote:
On Monday 08 October 2007 13:50, Heikki Linnakangas wrote:
While profiling a test case of exporting data from PostgreSQL, I noticed
that a lot of CPU time was spent in sprintf, formatting timestamps like
2007-10-01 12:34. I could speed that up by an order of magnitude by
It's too far-fetched for my tastes. I think gcc should not do it.
How gcc can know what printf() and puts() mean in *my* libc?
Well, that's what -fno-builtin is for.
More precisely, -ffreestanding.
I think such optimizations should be done in glibc.
The point is that you can't. GCC knows
Ian Lance Taylor wrote:
Steve Kenton [EMAIL PROTECTED] writes:
Is it ever possible to build libmudflap, libssp, or libgomp when
inhibit_libc is set?
It seems unlikely.
OK, then I'll pursue this idea
If not, is is reasonable to add a check to the top level configure to detect
On Monday 08 October 2007 16:08, Heikki Linnakangas wrote:
Denys Vlasenko wrote:
On Monday 08 October 2007 13:50, Heikki Linnakangas wrote:
While profiling a test case of exporting data from PostgreSQL, I noticed
that a lot of CPU time was spent in sprintf, formatting timestamps like
Denys Vlasenko writes:
On Monday 08 October 2007 13:50, Heikki Linnakangas wrote:
While profiling a test case of exporting data from PostgreSQL, I noticed
that a lot of CPU time was spent in sprintf, formatting timestamps like
2007-10-01 12:34. I could speed that up by an order of
Michael_fogel wrote:
The failing instruction is a call. The compiler loads every symbol
reference into a register and calls the function using this. In front of
the error this load is missing. In smaller files the compiler uses the
reference, which is the way i want him to do it.
We need
Ô¬Á¢Íþ wrote:
So, my question becomes clear:
How to solve this problem by making GCC knows the data dependencies
between mov X = pr (or mov pr = X, -1) and other usage of a specific
predicate register (e.g. p6, p7)?
We already have support for these move instructions. See the
movdi_internal
Jim Wilson wrote:
Michael_fogel wrote:
The failing instruction is a call. The compiler loads every symbol
reference into a register and calls the function using this. In front
of the error this load is missing. In smaller files the compiler uses
the reference, which is the way i want him to
On Sat, 2007-10-06 at 19:48 -0700, Gary Funck wrote:
While working on UPC, we ran into an interesting problem
where if -O1 is enabled, and -funit-at-a-time is disabled
(which is not the default configuration) a static variable
declaration was not emitted by the assembler. I haven't
quite
Michael_fogel wrote:
In my opinion the compiler ran out of registers and was not able to
allocate the pseudo register. In this case the compiler has to spill
these registers. How is this done in GCC? Is there a way to control it?
There are a lot of things that affect this. The main things
Snapshot gcc-4.1-20071008 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20071008/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Mon, 2007-10-08 at 11:42 -0500, Stephen M. Kenton wrote:
Is it ever possible to build libmudflap, libssp, or libgomp when
inhibit_libc is set?
It seems unlikely.
OK, then I'll pursue this idea
Please do -- that would be really great. It would be useful if your
work could
rws_access_reg should be handling this correctly. It uses
HARD_REGNO_NREGS to get the number of regs referred to by a reg rtl.
So it should return 64 in this case, and then it will iterate over all
64-bit PR regs when checking for a dependency.
I have found HARD_REGNO_NREGS in ia64.h
#define
--- Comment #3 from bje at gcc dot gnu dot org 2007-10-08 06:46 ---
Subject: Bug 33454
Author: bje
Date: Mon Oct 8 06:45:56 2007
New Revision: 129121
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129121
Log:
PR ada/33454
Revert:
2007-08-31 Ben Elliston
--- Comment #4 from bje at gcc dot gnu dot org 2007-10-08 06:47 ---
This patch created more problems than it solved. Reverting for the time being.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
A simple program that is supposed to invert a permutation P gives wrong result
with gfortran 4.2.1. A quite recent trunk 4.3 gfortran also gave wrong result.
See also discussion in comp.lang.fortran subject Most elegant syntax for
inverting a permutation?. The concensus seems to be that this
#include limits
template typename T
int is_infinity( T value ) throw()
{
if ( !std::numeric_limits T ::has_infinity )
return 0;
T const inf = std::numeric_limits T ::infinity();
if ( value == +inf )
return +1;
if ( value == -inf )
--- Comment #26 from rguenther at suse dot de 2007-10-08 08:47 ---
Subject: Re: wrong types in character array/scalar binop
On Sun, 7 Oct 2007, pault at gcc dot gnu dot org wrote:
--- Comment #25 from pault at gcc dot gnu dot org 2007-10-07 12:49
---
(In reply to
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-08 08:53 ---
The first store is for the truncation to float, the second store is because
of the volatile. Now we could combine the first into the second, but in
general we don't care too much to try optimize code which uses
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #21 from ubizjak at gmail dot com 2007-10-08 08:56 ---
The problem is, that we don't have correct REG_DEP_TRUE expr of the call to
powf after we have pushed ebp+const into temp register.
I'm testing following patch to explow.c:
Index: explow.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-08 08:56 ---
*** This bug has been marked as a duplicate of 33667 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-10-08 08:56 ---
*** Bug 33685 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
We are using gcc and Gnat.Sockets and have the need to filter incoming packets
according to their origin (device, IP, port), in order to enable this we have
patched gcc to offer the constant IP_PKTINFO.
I am going to attach an archive with the patched files for gcc-snapshot. The
addition is quite
The following program is valid and compiles with GCC 4.2.x. However, using
today's 4.3.0 it is rejected with the message:
REAL, save :: c(0:(lmaxd+1)*(lmaxd+1))
1
Error: automatic object 'c' at (1) cannot have the SAVE attribute
Obviously, 'C' is not
--- Comment #1 from kayhayen at gmx dot de 2007-10-08 09:03 ---
Created an attachment (id=14321)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14321action=view)
Patch adding IP_PKTINFO constand and implementation changes to Gnat.Sockets
I can also make it in a patch form, but I am
--- Comment #1 from burnus at gcc dot gnu dot org 2007-10-08 09:07 ---
Fails:
2007-10-08-r129121
Works:
2007-09-27-r128828
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-08 09:13 ---
I thought modifying a variable while acessing the same one in a forall loop was
undefined behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33686
--- Comment #2 from enok at lysator dot liu dot se 2007-10-08 09:42 ---
Do you mean the fact that assignment expressions within a forall loop may be
executed in any order? But within a single assignment it seems that the right
hand side and any expressions within the left hand side must
unsigned int mgaSetTexImages(int i)
{
return ((i | 0x40) 0xffc0);
}
mga_texstate.c:67: error: type mismatch in binary expression
unsigned int
int
unsigned int
D.24173 = D.24172 63
--
Summary: [4.3 Regression] Type checking error with bitwise and/or
Product:
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-08 09:46 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-08 10:11 ---
works with revision 129038 (20071005).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33689
--- Comment #6 from chrbr at gcc dot gnu dot org 2007-10-08 11:02 ---
patch+testcase at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01902.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19531
- gfortran 4.1.3 20070724; 4.2.1; 4.2.2 20070927; 4.3.0 20071008 [Rev.129121]
and 3, 1, 4, 2 with:
- ifort 9.1 and 10.0
- sunf95 (Sunstudio 11 and 12)
Now we need only to find out which compiler is right and whether the program
itself is valid. Cf. also
http://groups.google.com/group/comp.lang.fortran
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-08 12:05 ---
You can add xlf to the (3, 1, 4, 2) list. I think this is the right answer.
The following code
PROGRAM TST
IMPLICIT NONE
INTEGER :: P(4),Q(4),I
P = (/2,4,1,3/)
FORALL(I=1:4)
Q(P(I)) = I
END FORALL
struct sndrv_pcm_info { };
typedef struct sndrv_pcm_info snd_pcm_info_t;
typedef struct {
snd_pcm_info_t info;
} snd_pcm_shm_ctrl_t;
int pcm_shm_cmd(volatile snd_pcm_shm_ctrl_t *ctrl)
{
snd_pcm_info((snd_pcm_info_t *) ctrl-info);
}
aserver.3.min.i: In function 'pcm_shm_cmd':
unsigned long modify_field (unsigned long mask, long fieldval)
{
return (~fieldval ~mask);
}
value.2.min.i: In function 'modify_field':
value.2.min.i:2: error: type mismatch in binary expression
long unsigned int
long int
long unsigned int
D.1544 = fieldval | mask
value.2.min.i:2: internal
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-08 12:12 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-08 12:12 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2007-10-08 12:15 ---
Now we need only to find out which compiler is right and whether the program
itself is valid.
After some contemplating, I agree that the program is valid (let's see whether
NAG's support agrees as well).
--
--- Comment #22 from ubizjak at gmail dot com 2007-10-08 12:15 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00420.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
__SIZE_TYPE__ cnfs_mapcntl(void *p, long pagesize)
{
return ~(__SIZE_TYPE__)(pagesize - 1);
}
cnfs.2.min.i: In function 'cnfs_mapcntl':
cnfs.2.min.i:2: error: type mismatch in unary expression
long unsigned int
long int
D.1543 = -pagesize
cnfs.2.min.i:2: internal compiler error:
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-08 12:22 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
unsigned int bfstages(int M, float *Utbl, int Ustride)
{
return ((unsigned int) 1 M) * Ustride;
}
fftlib.3.min.i: In function 'bfstages':
fftlib.3.min.i:2: error: type mismatch in shift expression
unsigned int
int
int
D.1544 = Ustride M
fftlib.3.min.i:2: internal compiler error:
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-08 12:33 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from Kenneth dot Zadeck at NaturalBridge dot com
2007-10-08 12:35 ---
Subject: Re: [4.3 regression]: wrong code with -fforce-addr
Your (a) solution would only paper over the problem: dse assumes that
it can see all of the loads and stores off of the frame in more
typedef unsigned char uint8_t;
typedef unsigned int uint_least32_t;
extern int foo (long int __off);
void write (uint_least32_t chunk_len)
{
uint8_t tmp[4];
foo (-(long)chunk_len - sizeof(tmp));
}
smm.3.min.ii: In function 'write':
smm.3.min.ii:5: error: type mismatch in binary
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-08 12:46 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from patchapp at dberlin dot org 2007-10-08 13:05 ---
Subject: Bug number PR33672
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/2007-10/msg00424.html
--
typedef signed short gint16;
typedef unsigned short guint16;
gint16 dissect_old_pflog(gint16 rnr)
{
return (guint16) ((guint16) ((guint16)rnr 8) | (guint16) ((guint16)rnr
8));
}
packet-pflog.3.min.i: In function 'dissect_old_pflog':
packet-pflog.3.min.i:4: error: type mismatch in shift
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-08 13:23 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from haubi at gentoo dot org 2007-10-08 14:17 ---
No - I do not use GNU binutils on aix, but symlinks and wrappers to native
binutils, much like:
powerpc-ibm-aix5.3.0.0-nm - /usr/ccs/bin/nm
or
$ cat powerpc-ibm-aix5.3.0.0
#! /bin/sh
exec /usr/ccs/bin/ld $@
--
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-10-08 14:23
---
Subject: Bug 30541
Author: rguenth
Date: Mon Oct 8 14:23:33 2007
New Revision: 129126
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129126
Log:
Backport
Author: rguenth
Date: Tue Jan 23 16:37:09 2007
New
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-08 14:44 ---
Subject: Bug 33691
Author: rguenth
Date: Mon Oct 8 14:44:14 2007
New Revision: 129128
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129128
Log:
2007-10-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-08 14:44 ---
Subject: Bug 33696
Author: rguenth
Date: Mon Oct 8 14:44:14 2007
New Revision: 129128
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129128
Log:
2007-10-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-08 14:44 ---
Subject: Bug 33694
Author: rguenth
Date: Mon Oct 8 14:44:14 2007
New Revision: 129128
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129128
Log:
2007-10-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-08 14:44 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-08 14:45 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-08 14:45 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from bangerth at dealii dot org 2007-10-08 14:56 ---
I've just found a number of other places where currently a VLA
is used and we consequently get a warning with current sources if
using the right flags. These are:
quicksort.h:68
multiway_mergesort.h:142
Benjamin, as a
--- Comment #9 from clemens dot koller at anagramm dot de 2007-10-08 15:11
---
The next release of OpenSSL will have this problem fixed.
Verified already on the latest snapshot:
openssl-0.9.8-stable-SNAP-20071008 builds fine now.
--
clemens dot koller at anagramm dot de changed
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-08 15:24 ---
Subject: Bug 33697
Author: rguenth
Date: Mon Oct 8 15:23:49 2007
New Revision: 129130
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129130
Log:
2007-10-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-08 15:24 ---
Subject: Bug 33693
Author: rguenth
Date: Mon Oct 8 15:23:49 2007
New Revision: 129130
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129130
Log:
2007-10-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-08 15:24 ---
Subject: Bug 33695
Author: rguenth
Date: Mon Oct 8 15:23:49 2007
New Revision: 129130
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129130
Log:
2007-10-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-08 15:32 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-08 15:33 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-08 15:33 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from bkoz at gcc dot gnu dot org 2007-10-08 15:58 ---
Subject: Bug 33489
Author: bkoz
Date: Mon Oct 8 15:58:06 2007
New Revision: 129132
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129132
Log:
2007-10-08 Benjamin Kosnik [EMAIL PROTECTED]
PR
On 8 Oct 2007 14:56:18 -, bangerth at dealii dot org
[EMAIL PROTECTED] wrote:
quicksort.h:68
multiway_mergesort.h:142
Benjamin, as a stopgap would you mind using __builtin_alloca in these
places as well?
Why not use __extension__ in those places?
-- Pinski
--- Comment #8 from pinskia at gmail dot com 2007-10-08 16:34 ---
Subject: Re: parallel v3: do not use __builtin_alloca, use VLA
On 8 Oct 2007 14:56:18 -, bangerth at dealii dot org
[EMAIL PROTECTED] wrote:
quicksort.h:68
multiway_mergesort.h:142
Benjamin, as a stopgap would
--- Comment #18 from danglin at gcc dot gnu dot org 2007-10-08 16:41
---
I see the same failure as HJL on hppa-unknown-linux-gnu.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/test/gnu/gcc/gcc/gcc/testsui
te/gfortran.dg/gamma_5.f90 -O0 -pedantic-errors
-L/test/gnu/gcc/objdir/hppa
64-hp-hpux11.11/./libgfortran/.libs
Same problem for
-0s/-02
version 4.1.0
etc...
[Code]
typedef unsigned * ptr_t;
void f (void) {
ptr_t p = (ptr_t)0xFED0;
p[0] = 0xDEAD;
p[2] = 0xDEAD;
p[4] = 0xDEAD;
p[6] = 0xDEAD;
}
[Assembly generated by version gcc-4.3-20071005]
f:
0: 3404deadli
--- Comment #3 from burnus at gcc dot gnu dot org 2007-10-08 17:58 ---
Works: r129068; fails: r129069.
http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00174.html
r129069 | tobi | 2007-10-07 13:45:15 +0200 (So, 07 Okt 2007) | 14 lines
PR 20851
fortran/
* expr.c (check_inquiry): Typo fix in
--- Comment #4 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-10-08 18:02 ---
Subject: Re: [Regression 4.3] Array with constant bound
rejected as automatic array
burnus at gcc dot gnu dot org wrote:
--- Comment #3 from burnus at gcc dot gnu dot org 2007-10-08
--- Comment #9 from bkoz at gcc dot gnu dot org 2007-10-08 18:11 ---
I'd rather do all these the same way.
Wolfgang, do you have a patch?
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33485
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v
3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/g
nu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/
--- Comment #5 from tobi at gcc dot gnu dot org 2007-10-08 18:25 ---
I think I have a fix. Needs some more testing, though.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from danglin at gcc dot gnu dot org 2007-10-08 18:37 ---
The following tests fail with revision 129120 due to this problem:
FAIL: 18_support/numeric_limits/min_max.cc (test for excess errors)
FAIL: 22_locale/money_get/get/char/5.cc
FAIL:
--- Comment #1 from pcarlini at suse dot de 2007-10-08 18:57 ---
So the problem is new, right? Has it to do with the recent fixes for the
deadlock bug?
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2007-10-08 19:03 ---
(In reply to comment #5)
Now we need only to find out which compiler is right and whether the program
itself is valid.
After some contemplating, I agree that the program is valid (let's see whether
NAG's support
--- Comment #10 from bangerth at dealii dot org 2007-10-08 19:15 ---
Created an attachment (id=14323)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14323action=view)
diffs to multiway_mergesort.h and quicksort.h
The attached diffs appear to do it for me.
W.
--
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-08
19:32 ---
Subject: Re: FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess
errors)
--- Comment #1 from pcarlini at suse dot de 2007-10-08 18:57 ---
So the problem is new, right? Has it to do
--- Comment #3 from dougkwan at google dot com 2007-10-08 19:50 ---
Subject: Re: FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess
errors)
That's strange. I am looking at it. I ran the libstdc++ testsuite
before and did not see this problem.
-Doug
8 Oct 2007 19:32:42
--- Comment #11 from bkoz at gcc dot gnu dot org 2007-10-08 19:55 ---
Wolfgang this is ok to check in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33485
--- Comment #7 from pault at gcc dot gnu dot org 2007-10-08 20:02 ---
(In reply to comment #6)
Oh dear, oh dear, we are going to have to implement
PROGRAM TST
IMPLICIT NONE
INTEGER :: P(4),I
integer, allocatable :: Q(:)
P = (/2,4,1,3/)
allocate (Q(size(P)))
FORALL(I=1:4)
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-08
20:10 ---
Subject: Re: FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess
errors)
That's strange. I am looking at it. I ran the libstdc++ testsuite
before and did not see this problem.
This is
--- Comment #12 from seongbae dot park at gmail dot com 2007-10-08 20:18
---
Subject: Re: [4.3 Regression] Revision 128957 miscompiles 481.wrf
Please remove the extra blank line above the line 984 (in new file).
This patch is OK.
Seongbae
On 10/7/07, Kenneth Zadeck [EMAIL
--- Comment #6 from patchapp at dberlin dot org 2007-10-08 20:26 ---
Subject: Bug number PR33689
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/2007-10/msg00439.html
--
--- Comment #8 from burnus at gcc dot gnu dot org 2007-10-08 20:28 ---
I am going to vote that this bug is invalid. IFORT and Sun F95 also reject
this.
Remark: The compilers, which accept the ('(a)') all reject
READ(*,*), a
because of the comma after *) (g95, NAG f95); the compiler
1 - 100 of 148 matches
Mail list logo
