On Tue, 2006-10-10 at 04:22, Mark Mitchell wrote:
Kaveh R. GHAZI wrote:
Has there been any thought to including GMP/MPFR in the GCC repository
like we do for zlib and intl?
I do not think we should be including more such packages in the GCC
repository. It's complicated from an FSF
Another, technical, reason to consider the s390x to be a primary
platform is that it is a different 64-bit big-endian target.
I always watch the test-result outcomes for gfortran of s390x closely -
it's too easy to mess things up using little-endian.
Same here. In C++ land it also has many
Steve Kargl writes:
Steve Should we consider removing zlib and intl? In particular, zlib 1.2.3
Steve was released on 19 Jul 05 and included 2 fixes for security issues.
Steve GCC did not update zlib until 12 Sep 05. Whether the security issues
Steve in GCC's version of zlib could be exploited,
Hello,
I am a PhD student working on the extended use of
expression templates for solving partial differential equations.
Thus, I did a lot of studying of expression templates papers,
articles and expression templates implementations. Actually,
I had some ideas for improving them for high
On Tue, Oct 10, 2006 at 08:51:55AM -0400, David Edelsohn wrote:
Steve Kargl writes:
Steve Should we consider removing zlib and intl? In particular, zlib 1.2.3
Steve was released on 19 Jul 05 and included 2 fixes for security issues.
Steve GCC did not update zlib until 12 Sep 05. Whether
No. I am not volunteering to maintain zlib. If you reread the
first 7 words, you'll note that I'm suggesting that zlib and
intl should be removed. Why shouldn't these libraries be treated
the same as gmp and mpfr?
... and infoZIP, which is now required to build libjava.
Interestingly, other
On Tue, Oct 10, 2006 at 04:28:34PM +0200, Paolo Bonzini wrote:
Interestingly, other GNU projects (including bison) are no longer
distributing intl. So, I think I agree that zlib and libintl should not
be distributed.
While zlib would probably be only moderately painful to remove, I
Interestingly, other GNU projects (including bison) are no longer
distributing intl. So, I think I agree that zlib and libintl should not
be distributed.
While zlib would probably be only moderately painful to remove, I
recommend anyone who wants to attempt intl be very very careful.
Daniel Jacobowitz wrote:
On Tue, Oct 10, 2006 at 04:28:34PM +0200, Paolo Bonzini wrote:
Interestingly, other GNU projects (including bison) are no longer
distributing intl. So, I think I agree that zlib and libintl should not
be distributed.
While zlib would probably be only
Kai Tietz writes:
I am currently on to build the gcc target support for x86_64-pc-mingw64.
While this porting I found a strange register truncation, I do not believe
it is valid. For the c code:
int foo(char *,...);
int doo(char *h) { return foo(abc ,h); }
Richard Earnshaw wrote:
I think there's a very important distinction that needs to be drawn
between a tool that needs to be installed to *build* gcc and a tool that
needs to be installed in order to *run* gcc. GMP/MPFR is needed for the
latter; and to date we have never relied on such an
On Tue, Oct 10, 2006 at 08:30:46AM -0400, Richard Kenner wrote:
Regardless of what happens with 4.3, I think the reality is that s/390
has been one of the better supported platforms for gcc since at least
3.2.x. The maintainers are very responsive and gcc-testresults is
updated on a daily
The attached patch adds all of the relevant targets to enable make pdf
to work; it produces the same files (modulo extension, of course) in the
same locations as make dvi. The changes are, I believe, relatively
straightforward and simple.
I have attached two separate .diff files; the first
[EMAIL PROTECTED] writes:
- the default versions of operator new and the aligned version of
operator new should be defined in the same section. That way,
when a user overrides the default operator new, they will get
a link error (duplicate definitions of new) unless they also
Steve == Steve Kargl [EMAIL PROTECTED] writes:
Steve Should we consider removing zlib and intl?
Note that zlib is built both as a host library and a target library.
So, if it is removed, cross builds of libgcj will no longer work.
Steve In particular, zlib 1.2.3
Steve was released on 19 Jul 05
On Tue, 10 Oct 2006, Paolo Bonzini wrote:
One point in favor of distributing gmp is that (according to its maintainers)
it's an incredible stress test for GCC, and a lot of .0 GCC versions are known
to miscompile it.
That's a case for adding application testing back to the release criteria,
Brooks == Brooks Moses [EMAIL PROTECTED] writes:
Brooks The attached patch adds all of the relevant targets to enable
Brooks make pdf to work; it produces the same files (modulo
Brooks extension, of course) in the same locations as make dvi.
The gcc/java bits are ok assuming that the rest is
On Tue, Oct 10, 2006 at 09:20:26AM -0700, Brooks Moses wrote:
---gcc/fortran
2006-10-10 Brooks Moses [EMAIL PROTECTED]
* Make-lang.in: Added fortran.pdf, gfortran.pdf target
support.
This part is OK. Of course, I can't approve
Hi,
I currently have a problem of how to best preserve a register note across
an instruction split, e.g. I had to change a define_split like this (from
m68k.md):
(define_split
[(set (match_operand 0 register_operand )
(zero_extend (match_operand 1 nonimmediate_src_operand )))]
October 2006
This is the thirteenth code drop of the GCC front-end for
the PL/I programming language.
PL/I for GCC is released under the terms of the
GNU Public License; version 2.
Main new feature in pl1gcc-0.0.13 is the preprocessor %GOTO statement.
There is still no code generation taking
On Oct 10, 2006, at 6:25 AM, Jochen Haerdtlein wrote:
I am a PhD student working on the extended use of expression
templates for solving partial differential equations.
Since compile time of huge expression template programs is a severe
problem
I fear that trying to solve that problem
Survey Introduction
www.MusiCoop.com is conducting a survey regarding musician support services and
would appreciate your response. MusiCoop.com is a *free* registry for bands,
musicians, fans and promoters.
The survey will take less than five minutes and you will not be asked to
purchase
Survey Introduction
www.MusiCoop.com is conducting a survey regarding musician support services and
would appreciate your response. MusiCoop.com is a *free* registry for bands,
musicians, fans and promoters.
The survey will take less than five minutes and you will not be asked to
purchase
Survey Introduction
www.MusiCoop.com is conducting a survey regarding musician support services and
would appreciate your response. MusiCoop.com is a *free* registry for bands,
musicians, fans and promoters.
The survey will take less than five minutes and you will not be asked to
purchase
What is the situation with multilib builds
of libffi and libjava in gcc 4.2 on architectures
like x86_64 and ppc64 linux? I ask because I noticed
that Fedora's gcc 4.1.1 specfile explicitly disables
the multilib builds in libjava and doesn't seem to
package libffi. Thanks in advance for any
Hi all,
I am upgrading my cross-compiler from 3.4.6 to 4.1.1. It has built
successfully. But while running the test suites, i am getting lots of
run time errors during optimization tests (Mostly size optimization -
Os). But the same code with same level of optimization works fine with
3.4.6.
1.
Rohit Arul Raj [EMAIL PROTECTED] writes:
I am upgrading my cross-compiler from 3.4.6 to 4.1.1. It has built
successfully. But while running the test suites, i am getting lots of
run time errors during optimization tests (Mostly size optimization -
Os). But the same code with same level of
--- Comment #2 from steven at gcc dot gnu dot org 2006-10-10 06:48 ---
I'll look into this.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
I tried to build avr-gcc 4.1.1 but i got an error message:
../gcc-4.1.1/gcc/. -I../../gcc-4.1.1/gcc/../include
-I../../gcc-4.1.1/gcc/../libcpp/include -DL_fixunssfsi -c
../../gcc-4.1.1/gcc/libgcc2.c -o libgcc/./_fixunssfsi.o
../../gcc-4.1.1/gcc/libgcc2.c: In function '__fixunssfsi':
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-10 07:31
---
For the TRANSPOSE case, the generated code shows that the {u,l}bounds simply
aren't set right:
$ cat pr29391.f90
integer :: i(-1:1,-1:1)=0, j(2)
j = lbound(transpose(i))
end
$ cat pr29391.f90.003t.original
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-10 07:56
---
Paul,
I'm not sure, but I think PR29394 is related to that one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-10 08:13
---
I'm very interested in that. I think it would really benefit the compiler: the
Fortran front-end would gain much in stability (and ease of installation) and
the C front-end could also benefit from this (as
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-10 08:27 ---
Subject: Bug 29323
Author: rguenth
Date: Tue Oct 10 08:27:02 2006
New Revision: 117598
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117598
Log:
2006-10-10 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-10 08:27 ---
Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-10 08:52 ---
It's at least accepted by EDG and Comeau in strict-ansi mode. (so, confirmed)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following code:
program chop
integer ix, iy
real x, y
x = 1.
y = x
ix = transfer(x,ix)
iy = transfer(y,iy)
print '(2z20.8)', ix, iy
if (ix /= iy) call abort
end program chop
when compiled with -O1 (or below) on PPC OSX 10.3, gives the correct result:
3F80
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #13 from jakub at gcc dot gnu dot org 2006-10-10 09:47 ---
Subject: Bug 29272
Author: jakub
Date: Tue Oct 10 09:46:59 2006
New Revision: 117599
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117599
Log:
PR middle-end/29272
* builtins.c
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-10 09:50 ---
FX,
There are two problems here; one is specific to LEN and the other is generic to
intrinsics and array valued actual arguments:
The LEN specific problem is that there is no need to call the function at all,
in the
--- Comment #26 from bkoz at gcc dot gnu dot org 2006-10-10 09:54 ---
Ok. I think I'll put this in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
From comment #7 in 29095 we have:
The technical issue is that in the following code:
extern C {
typedef void (*p1)();
}
typedef void (*p2)();
p1 and p2 are distinct types, and, in fact, you can overload based on that.
G++ doesn't implement that distinction; we don't keep track of
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-10-10 10:09 ---
This would be an enhancement to both g++ and the IA64 C++ ABI.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from bkoz at gcc dot gnu dot org 2006-10-10 10:14 ---
Subject: Bug 29118
Author: bkoz
Date: Tue Oct 10 10:14:13 2006
New Revision: 117600
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117600
Log:
2006-10-09 Benjamin Kosnik [EMAIL PROTECTED]
PR
Recently I upgraded gcc from 3.3.2(really outdated!) to 3.4.6 on HPUX 11.23
June 2006 update. This build on both ia64 and pa-risc machines.
This gcc is built on HPUX 11.23 by using the native ANSI C compiler.
# what /opt/ansic/bin/cc
/opt/ansic/bin/cc:
HP aC++/C for Integrity Servers
--- Comment #41 from rguenth at gcc dot gnu dot org 2006-10-10 11:19
---
We're still 100% slower than 4.0.3 on the mainline:
Execution times (seconds)
callgraph construction: 0.21 ( 0%) usr 0.03 ( 2%) sys 0.23 ( 0%) wall
11563 kB (13%) ggc
callgraph optimization: 0.01 (
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-10-10 11:58
---
On mainline we now have
f:
xorl%eax, %eax
movla, %edx
cmpl$0, 4(%esp)
movlb, %ecx
jne .L4
movl%edx, %eax
sarl$31, %edx
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-10 12:40 ---
Created an attachment (id=12402)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12402action=view)
Fix for this PR
Regtested on FC5/Athlon
Will submit asap.
Paul
--
pault at gcc dot gnu dot org changed:
--- Comment #4 from pault at gcc dot gnu dot org 2006-10-10 12:41 ---
Created an attachment (id=12403)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12403action=view)
Fix for the problem
Regtested on FC5/Athlon
Will submit asap.
Paul
--
pault at gcc dot gnu dot org changed:
--- Comment #5 from pault at gcc dot gnu dot org 2006-10-10 12:47 ---
(In reply to comment #4)
Created an attachment (id=12403)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12403action=view) [edit]
Fix for the problem
Sorry, I should have said that this gets rid of the TWO
--- Comment #4 from pault at gcc dot gnu dot org 2006-10-10 12:48 ---
(In reply to comment #3)
Paul,
I'm not sure, but I think PR29394 is related to that one.
Yes, I already verified that yesterday but forgot to make a note of it. I'm
just gearing up to an afternoon of gfortran
--- Comment #3 from vincent at vinc17 dot org 2006-10-10 13:53 ---
(In reply to comment #2)
What's worrying me a bit is the versioning of MPFR.
Note that GMP is similar.
Vincent, would it be possible that some version number is increased every
time a patch is posted, so that the
--- Comment #5 from patchapp at dberlin dot org 2006-10-10 13:55 ---
Subject: Bug number PR25519
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-10/msg00542.html
--
--- Comment #14 from amacleod at redhat dot com 2006-10-10 14:03 ---
TER acts only within a basic block, and that will probably not change. Its
primary function is simply to mash trees back together so the expander gets a
better look.
This is more likely to handled by the RABLET work
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-10 14:06 ---
Confirmed (as in comment #1). With -Os instead of -O2 we even produce
.L3:
movl%ebx, -4(%edx)
incl%eax
.L2:
addl$4, %edx
cmpl%ecx, %eax
jb .L3
(because
$ mips-linux-gcc -EL -dM -E -C -x c /dev/null | grep MIPSE
#define MIPSEB 1
#define __MIPSEB__ 1
#define _MIPSEB 1
#define __MIPSEB 1
$ mipsel-linux-gcc -EB -dM -E -C -x c /dev/null | grep MIPSE
#define __MIPSEL__ 1
#define MIPSEL 1
#define _MIPSEL 1
#define __MIPSEL 1
$ mips64el-linux-gcc -EB -dM
--- Comment #4 from igodard at pacbell dot net 2006-10-10 14:17 ---
Yes, there IS something you can do about it. The compiler already checks
whether a
template is resolved by its data arguments (the message is something like
nothing
of foo depends on any template argument and so
--- Comment #6 from bangerth at dealii dot org 2006-10-10 14:25 ---
(In reply to comment #5)
foo should not have been injected by the friend.
True, but that's irrelevant here. We get a tentative declaration that we
simply have to unify with the later real declaration.
Note the
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-10-10 14:32
---
No, it's extract_range_from_binary_expr operating on [0, +INF] + [0, 65535] and
blindly using int_const_binop to compute the resulting range...
I believe the following is completely bogus and we cannot ignore
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
Issues building GNU java on Solaris2.10 X64:
Configured to use: GNU as, SUN linker, pthreads, java-awt=xlib
* SUN's /bin/sh is broken... set CONFIGURE_SHELL to /bin/ksh or /bin/bash
* SUN tools like sed, grep, tar, find are also deficit. Use GNU tools.
* the java build requires a version of
--- Comment #7 from uros at kss-loka dot si 2006-10-10 14:48 ---
(In reply to comment #6)
Confirmed (as in comment #1). With -Os instead of -O2 we even produce
.L3:
movl%ebx, -4(%edx)
The -4(...) part comes from PR 24669.
--
--- Comment #10 from mi at aldan dot algebra dot com 2006-10-10 14:52
---
(In reply to comment #9)
finding the relevant patch using a binary search of the subversion archive
between the revision numbers of the 3.4 branchpoint and the 4.0 release
That's the problem -- how can I, who
--- Comment #11 from bangerth at dealii dot org 2006-10-10 14:56 ---
(In reply to comment #10)
For you, the developers, it is, probably, indeed faster, than writing another
explanation, why you have no resources to do it...
No, it will actually take significant time, since one has to
--- Comment #12 from mi at aldan dot algebra dot com 2006-10-10 15:13
---
In comment #9: shouldn't be too hard.
In comment #11: No, it will actually take significant time
If the explanation for the above discrepancy is simply not having access to a
FreeBSD machine, such an access can
--- Comment #13 from bangerth at dealii dot org 2006-10-10 15:18 ---
(In reply to comment #12)
In comment #9: shouldn't be too hard.
In comment #11: No, it will actually take significant time
It's a long and boring process. It's not complicated, it just takes time.
If the
Using gcc 4.2 snapshot 20061007 on x86, the compiler is miscompiling glibc 2.5
(see http://sourceware.org/bugzilla/show_bug.cgi?id=3328)
What is happening is that a test of a variable after an inline asm block is
moved around so that the load of the struct member is moved above the asm block
even
--- Comment #1 from christophe at saout dot de 2006-10-10 15:40 ---
Created an attachment (id=12404)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12404action=view)
preprocessed pthread_mutex_lock.c causing the miscompiled code
Call with gcc -O2 -o test.o -c pthread_mutex_lock.c
This is with:
gcc (GCC) 4.2.0 20061007 (experimental)
On x86 Debian and under Fedora Core 3.
Using the lamba part of the boost library, the following is seen:
/tmp/ccNdhcXx.o:(.debug_info+0xec9): undefined reference to
`boost::lambda::(anonymous namespace)::free2'
--- Comment #1 from peter at chocky dot org 2006-10-10 16:17 ---
Created an attachment (id=12405)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12405action=view)
minimal test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29417
--- Comment #7 from mark at codesourcery dot com 2006-10-10 16:23 ---
Subject: Re: [4.0/4.1/4.2 Regression] Bogus ambiguity with
templates + friend
bangerth at dealii dot org wrote:
We've been over that before, Andrew. It has always been the case that
bugmasters do the initial
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-10 16:27 ---
Already fixed for 4.1.2.
*** This bug has been marked as a duplicate of 26504 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-10-10 16:27
---
*** Bug 29409 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-10 16:30 ---
(In reply to comment #3)
It's at least accepted by EDG and Comeau in strict-ansi mode. (so, confirmed)
Don't take EDG/Comeau as conforming to the standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-10-10 16:33
---
*** Bug 29411 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-10 16:33 ---
This is really a dup of bug 2316. I forgot to mention that in PR 29095.
Oh and this is not an enhancement because you can have wrong code and also
rejects valid testcases see the dup bug report about those cases.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-10 16:35 ---
Why do you think this is a GCC bug and not a GNUStep bug?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-10 16:46 ---
__asm __volatile ( call *_dl_sysinfo\n\t : =a (__status) : 0 (240), b
(mutex-__data.__lock), S (0), c (0), d (_val), i (__builtin_offsetof
(tcbhead_t, sysinfo)) : memory);
I think what you are doing here is
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from tromey at gcc dot gnu dot org 2006-10-10 17:19 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from debian-gcc at lists dot debian dot org 2006-10-10
18:04 ---
20060928 works
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
--- Comment #6 from debian-gcc at lists dot debian dot org 2006-10-10
18:25 ---
r117410 is the first version showing the failure.
r117410 | mmitchel | 2006-10-03 20:06:00 +0200 (Di, 03 Okt 2006) | 12 lines
PR c++/29138
* decl2.c (grokfield): Don't handle access
--- Comment #4 from tromey at gcc dot gnu dot org 2006-10-10 18:44 ---
Subject: Bug 29205
Author: tromey
Date: Tue Oct 10 18:44:06 2006
New Revision: 117610
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117610
Log:
PR libgcj/29205:
* Makefile.in: Rebuilt.
--- Comment #5 from tromey at gcc dot gnu dot org 2006-10-10 18:45 ---
I've checked in the fix on the trunk.
Do we need this in 4.1? I assume not on the theory that
now the file names won't clash...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29205
--- Comment #3 from jakub at gcc dot gnu dot org 2006-10-10 18:55 ---
No, that's perfectly valid, you can't jump out of an asm or jump into it,
but if you enter the asm and exit it, it doesn't matter what branches or calls
were used inside it (of course if the function you call inside
--- Comment #6 from tromey at gcc dot gnu dot org 2006-10-10 19:32 ---
Subject: Bug 29362
Author: tromey
Date: Tue Oct 10 19:31:56 2006
New Revision: 117612
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117612
Log:
PR classpath/29362:
*
--- Comment #7 from jjohnstn at redhat dot com 2006-10-10 19:35 ---
I am confirming that the patch does fix the problem. With patch, the original
Eclipse CDT problems have gone away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
--- Comment #3 from pault at gcc dot gnu dot org 2006-10-10 19:36 ---
(In reply to comment #2)
One last comment: I'm not sure the stride shouldn't be set to one. The patch
above regtests fine, and can compile correctly everything I threw at it, but
maybe I have not been clever
--- Comment #8 from tromey at gcc dot gnu dot org 2006-10-10 19:38 ---
Subject: Bug 29362
Author: tromey
Date: Tue Oct 10 19:37:52 2006
New Revision: 117613
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117613
Log:
PR classpath/29362:
*
--- Comment #9 from tromey at gcc dot gnu dot org 2006-10-10 19:39 ---
I checked this in.
I'd still appreciate a review from Chris though.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
FAIL: gcc.dg/tree-ssa/ivopts-2.c scan-tree-dump-not \n candidates
.*,.*,.*\n[^\n]*\nFinal cost
appeared on mainline between 20060924 and 20060925 on hppa64-hp-hpux11.11 (this
is a new test assertion so probably not a regression).
--
Summary: gcc.dg/tree-ssa/ivopts-2.c
--- Comment #12 from bkoz at gcc dot gnu dot org 2006-10-10 20:07 ---
adding ABI keyword as implementing this may change mangling for C functions.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2006-10-10 20:49 ---
Created an attachment (id=12406)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12406action=view)
A development of the previous patch (ie. it works!).
This now regtests, apart from alloc_comp_basics_1.f90, which
--- Comment #2 from mtrudel at gmx dot ch 2006-10-10 21:20 ---
Fixed... The path separator was set to : on all platforms instead of ; for
windows.
--
mtrudel at gmx dot ch changed:
What|Removed |Added
The following code (derived from allocatable_1.f90)
Type drv
Integer::i
Integer,allocatable::arr(:)
End type drv
print *, fun1()
contains
Function fun1 ()
Type(drv)::fun1
Fun1%i=10
end function fun1
end
gives
allocatable_1_db.f90: In function MAIN__:
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-10 22:04
---
(In reply to comment #3)
Are you sure that this renormalization of the bounds is required? After all:
(i) indices should always be realtive to lbound, whatever it is; and
(ii) why would anybody be interested
--- Comment #18 from aesok at gcc dot gnu dot org 2006-10-10 22:18 ---
Subject: Bug 26504
Author: aesok
Date: Tue Oct 10 22:18:06 2006
New Revision: 117616
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117616
Log:
* config/avr/predicates.md: New file.
*
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.fortran-torture/execute/intrinsic_rrspacing.f90 -w -O0
-L/test/g
nu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
--- Comment #28 from danglin at gcc dot gnu dot org 2006-10-10 22:26
---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-10 22:34 ---
Update your source directory and rebuild in a clean obj directory.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 124 matches
Mail list logo
