Summary ===
# of expected passes117
# of expected failures 1
=== ld tests ===
Running target unix
=== ld Summary ===
# of expected passes263
# of expected failures 5
version: 2.16.91 20051124
Platform
Nathan Sidwell [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| Assuming the extension was gone, do you see a reason we not move the
| default arguments to FUNCTION_DECLs and have FUNCTION_TYPEs use
| TREE_VEC instead of TREE_LIST to hold the parameter-type list?
|
| you could
Hi,
I'm having a lot of problems bootstrapping this compiler on said target.
What I did so far:
from the build dir (which I located in the extracted source dir)
../configure --srcdir=.. --enable-languages=c c++ --with-gnu-as
--with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld
Nathan Sidwell [EMAIL PROTECTED] wrote:
In the C++ front end, default arguments are recorded in
FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are
the reasons for that?
There used to be an extension that allowed default arguments on
function pointer types. We agreed to
Giovanni Bajo [EMAIL PROTECTED] writes:
| Nathan Sidwell [EMAIL PROTECTED] wrote:
|
| In the C++ front end, default arguments are recorded in
| FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are
| the reasons for that?
|
|
| There used to be an extension that allowed
Gabriel Dos Reis [EMAIL PROTECTED] writes:
[...]
| | The obvious place is on the DECL_INITIAL of the PARM_DECLs, but I
| | don't think they exist until the function is defined.
| |
| |
| | I heard once that there was some long-term project of storing function
| | declarations (without
On Wed, 2005-11-23 at 21:13, Ludovic Brenta wrote:
I've read the wiki page that explains how to mirror GCC's repository
using SVK, and I would like to pick up just the parts I need so I can
keep the size of the mirror below 4 Gb due to limited disk space.
Specifically, I need just a few
Hello!
Mark Mitchell's @file documentation change adds a @set directive to
gcc-vers.texi in the build directory, but that file only depends on
DEV-PHASE and BASE-VER, so it will never be correctly rebuilt using
the new make rule. Just deleting it will remedy the problem.
Another problem is
I noticed that in the config.h generated for libiberty has HAVE_DECL_ASPRINTF
defined as 0. This hapens because _GNU_SOURCE is not used when running the
test programs.
Coping the test that enables _GNU_SOURCE from gcc/configure.ac to
libiberty/configure.ac results in HAVE_DECL_ASPRINTF being
On 11/24/05, Uros Bizjak [EMAIL PROTECTED] wrote:
Hello!
Mark Mitchell's @file documentation change adds a @set directive to
gcc-vers.texi in the build directory, but that file only depends on
DEV-PHASE and BASE-VER, so it will never be correctly rebuilt using
the new make rule. Just
On Thu, 24 Nov 2005, Uros Bizjak wrote:
Attached (untested) diff should update the required version of texinfo.
It also need updating everywhere in install.texi that mentions a required
Texinfo version.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL
Gabriel Dos Reis [EMAIL PROTECTED] wrote:
templateint struct X { };
void fu(int a, Xsizeof(a)) { } // #1
I gave a look to PR 17395 and you are probably right. This testcase requires
us to build PARM_DECLs even for function declarations. That's really too
bad.
You should though
Hi,
I am stuck with PR libfortran/22097 because currently, the libgfortran
configury isn't clever enough to get cabsl (among others) right on
mips-irix6.5. config.h has
#define HAVE_CABSF 1
and
/* #undef HAVE_COMPLEX_H */
while the correct definition of cabsl is provided in complex.h. Can
Rafael Ávila de Espíndola wrote:
I noticed that in the config.h generated for libiberty has HAVE_DECL_ASPRINTF
defined as 0. This hapens because _GNU_SOURCE is not used when running the
test programs.
Another long-staying bug in the libiberty configure system is that it
claims newlib missing
If we do this, then anyone else testing for asprintf needs the same
logic. If libiberty uses a more naive test, it would provide
substitutes for other modules that are also naive.
Giovanni Bajo [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] wrote:
|
| templateint struct X { };
|
| void fu(int a, Xsizeof(a)) { } // #1
|
| I gave a look to PR 17395 and you are probably right. This testcase requires
| us to build PARM_DECLs even for function
Gabriel Dos Reis [EMAIL PROTECTED] wrote:
Once I'm finished, I'll post the patch and I would probably ask you
help in the testing department and suggest better concrete
solution. That PR needs to be fixed.
Fixing a PR introducing a regression is not a proper fix for any bug,
*especially* for
Giovanni Bajo [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] wrote:
|
| Once I'm finished, I'll post the patch and I would probably ask you
| help in the testing department and suggest better concrete
| solution. That PR needs to be fixed.
|
|
| Fixing a PR introducing a
Giovanni Bajo [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] wrote:
|
| Fixing a PR introducing a regression is not a proper fix for any bug,
| *especially* for a bug which is not a regression itself.
|
| Thanks for the lecture.
|
| Not just because this is not a regression
I am currently bootstraping the trunk with the patch applied.
bootstraped and tested...
Thanks,
Rafael
In http://gcc.gnu.org/ml/gcc/2005-11/msg01163.html, Ian Lance Taylor wrote:
Either way, register elimination can cause addresses which were valid
to become invalid, typically because valid offsets from the frame
pointer become invalid offsets from the stack pointer. So that needs
to be cleaned
Kaveh R. Ghazi wrote:
On Sat, 2005-11-19 at 10:14 -0500, Kaveh R. Ghazi wrote:
Hi Dan,
(BTW, sorry for the reposted messages.)
While I was waiting for some svn commands to finish (cleanup,
update) on my solaris2.7 box, which has a slow filesystem, I
happened to run
I've been quietly watching the conversation, largely as an interested
user as opposed to a GCC developer. One of my concerns lies with:
GENERIC - GIMPLE - LLVM - GIMPLE - RTL
That design adds two phases (GIMPLE - LLVM, LLVM - GIMPLE) here --
perhaps simple one, perhaps not. The line
Hi Ulrich,
In http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01557.html, you
changed the return value of find_reloads_address to be tristate, in the
process modifying the meaning of a win from LEGITIMIZE_RELOAD_ADDRESS.
Prior to your change, a win meant that LEGITIMIZE_RELOAD_ADDRESS had
--- Comment #2 from uros at kss-loka dot si 2005-11-24 08:09 ---
The testsuite patch that fixes IA32 tests (and should also fix IA64 issues
reported here) is at http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01059.html.
Patch is still waiting for review, however I can't test it on IA64.
--- Comment #14 from jakub at gcc dot gnu dot org 2005-11-24 08:36 ---
Comment #7 seems to suggest that (even just --enable-languages=c,fortran).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
--- Comment #9 from amodra at bigpond dot net dot au 2005-11-24 08:59
---
Indeed it's not a stack slot. Instead, reg 1824 is an invariant, equal to
sfp+16512. Code in reload1.c:eliminate_regs_1 substitutes r1 for sfp, then
reorganises the order of the additions, so we get
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-24 09:01
---
Subject: Re: Bootstrap: Failure to build doc/gcc.info
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| (In reply to comment #4)
| still does not work with bubblestrap and friends
|
| After a
--- Comment #8 from gdr at integrable-solutions dot net 2005-11-24 09:03
---
Subject: Re: Bootstrap: Failure to build doc/gcc.info
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| (In reply to comment #3)
| Subject: Re: Bootstrap: Failure to build doc/gcc.info
| pinskia
--- Comment #2 from rmathew at gcc dot gnu dot org 2005-11-24 09:33 ---
Confirmed on mainline. Also confirmed that GCJX does not have this bug.
--
rmathew at gcc dot gnu dot org changed:
What|Removed |Added
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot
|dot org
--- Comment #2 from uros at kss-loka dot si 2005-11-24 10:19 ---
This also fails for i686-pc-linux-gnu with '-march=athlon'.
The patch at http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01648.html fixes
i86_64-pc-linux-gnu failure in original report and -march=athlon failure.
FWIW,
--- Comment #5 from uros at kss-loka dot si 2005-11-24 10:19 ---
*** Bug 24995 has been marked as a duplicate of this bug. ***
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #10 from amodra at bigpond dot net dot au 2005-11-24 10:21
---
I think I've sorted this out after all.. Testing a fix.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
--- Comment #6 from uros at kss-loka dot si 2005-11-24 10:24 ---
(In reply to comment #4)
I've proposed a patch to this PR in
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01648.html
Does it solve PR 24995?
Yes, both i86_64 and -march=athlon failures.
--
uros at kss-loka dot
The following bug occurs only if -O (or higher optimization) is switched on.
I did not find out which of the single optimization switches is responsible for
it. The complete if statement is true, although none of each boolean value is
true. If I replace the enum variable Type by an int, the code
Compiling the following code snippet with g++ -fopenmp -O -Wall
I get a hosed error message:
int i;
void foo()
{
#pragma omp parallel
{
int j;
i = j;
}
}
bug.cc: In function 'void _Z3foov.omp_fn.0(void*)':
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-11-24 10:48 ---
Subject: Bug 14024
Author: rguenth
Date: Thu Nov 24 10:48:15 2005
New Revision: 107459
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107459
Log:
2005-11-24 Richard Guenther [EMAIL PROTECTED]
Dirk
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-11-24 10:55 ---
Fixed in 4.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #38 from ebotcazou at gcc dot gnu dot org 2005-11-24 11:14
---
That doesn't cover the Ada tools. They build for me at -O0 on PowerPC so with
Andrew's FE patch + a possible tweak in the Makefile, you should have an Ada
compiler.
They even build for me at -O2 on PowerPC
_Jv_CondWait makes no allowances for the possibility of an integer
overflow, and this means we can return too early.
This causes very hard to track down bugs. See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161483
--
Summary: Integer overflow in _Jv_CondWait
--- Comment #1 from aph at gcc dot gnu dot org 2005-11-24 11:48 ---
Consider this program:
public class TimedWait
{
public static void main (String[] argv)
throws InterruptedException
{
Object o = new Object();
synchronized (o)
{
o.wait(Long.MAX_VALUE);
--- Comment #2 from aph at gcc dot gnu dot org 2005-11-24 11:48 ---
Patch at http://gcc.gnu.org/ml/java-patches/2005-q4/msg00222.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25016
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Status|NEW |ASSIGNED
Seen on intel architectures (i686, x86_64). Run following example code:
program test
complex cres1, cres2, ivc
parameter(ivc = (0,1))
const= 0
fact = 0.5
cres1 = csqrt(const + ivc*fact)
cres2 = csqrt(const - ivc*fact)
print*,'cres1=',cres1,
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-24 12:56 ---
We see a _lot_ of ICEs like this on i686 package builds of f.i. xgl, MPlayer,
openafs...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-24 13:05
---
This bug is in glibc (same code on non-glibc platform, such as sparc-solaris,
will give the right answer). It was reported in glibc bugzilla as #1466
(http://sources.redhat.com/bugzilla/show_bug.cgi?id=1466), and
--- Comment #2 from pluto at agmk dot net 2005-11-24 13:11 ---
and another failure on 4.1 (rev 107414) on PPC:
Bootstrap comparison failure!
./alias.o differs
./builtins.o differs
./combine.o differs
./ddg.o differs
./function.o differs
./global.o differs
./modulo-sched.o differs
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-24 13:25 ---
The patch seems to fix the failures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24982
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-11-24 13:26
---
I think this bug is caused by the fact that simplification of array slices
isn't implemented yet; from expr.c (simplify_const_ref):
switch (p-ref-type)
{
.
.
.
default:
/* TODO: Simplify array
[EMAIL PROTECTED]:~/src/work cat const.f90
module const
real(8), parameter :: g = - sqrt(2._8) * Gf
end module const
[EMAIL PROTECTED]:~/src/work ../gcc/build/gcc/f951 const.f90
const.f90:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if
--- Comment #15 from jb at gcc dot gnu dot org 2005-11-24 13:38 ---
Just to be sure, you should be building outside the gcc directory hierarchy.
This is (a cleaned up version of the) script I use for doing a clean build:
#!/bin/sh
GCCDIR=trunk
cd $GCCDIR
contrib/gcc_update
cd ..
rm
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2005-11-24 14:09
---
Created an attachment (id=10332)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10332action=view)
Reduced testcase.
Compile at -O on x86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18659
--- Comment #9 from uros at kss-loka dot si 2005-11-24 14:40 ---
Critical, according to comment #7 and #8.
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #39 from pluto at agmk dot net 2005-11-24 14:46 ---
(In reply to comment #38)
That doesn't cover the Ada tools. They build for me at -O0 on PowerPC so
with
Andrew's FE patch + a possible tweak in the Makefile, you should have an Ada
compiler.
They even build for
Promoting of longs to long longs gives incorrect results (i.e. sign extension
is not done; upper half of result may in some cases be the upper half of a
previous 64-bit computation), and does not give a warning in most cases.
I have tried http://cjb.ie/32-64bug.c on the following, on various
--- Comment #3 from overholt at redhat dot com 2005-11-24 15:21 ---
This test case does not work for me when I have not applied the patch. After
application and building, it does appear to run forever :)
Also, the Eclipse issue that spurred this on (referenced in comment #1) is
fixed
--- Comment #1 from cjb at cjb dot ie 2005-11-24 15:21 ---
Created an attachment (id=10333)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10333action=view)
Test case for 32-64 bit promotion bug
Most recent version of this file available at http://cjb.ie/32-64bug.c or
Hi,
it would be nice if gfortran implemented a facility like
NAG's F90_UNIX module. The program
implicit none
call abort ()
end
compiles and links with gfc -std=gnu but not with -std=f95
With the NAG compiler one can write
USE f90_unix, ONLY: abort
implicit none
call abort ()
end
have
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |middle-end
Target Milestone|--- |4.1.0
--- Comment #8 from ed at eh3 dot com 2005-11-24 16:26 ---
Hi Jerry, thank you for looking into this issue and clarifing it!
The use of correct array triplets is a very quick and easy thing for us to
do. And its certainly a good idea to follow the Fortran standard.
--
fxcoudert at gcc dot gnu dot org wrote:
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-24 13:05
---
This bug is in glibc (same code on non-glibc platform, such as sparc-solaris,
will give the right answer). It was reported in glibc bugzilla as #1466
--- Comment #2 from jvdelisle at verizon dot net 2005-11-24 16:33 ---
Subject: Re: sqrt,
csqrt may give a wrong result if real part of compex argument is zero
fxcoudert at gcc dot gnu dot org wrote:
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-24 13:05
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-24 16:41 ---
This is a dup of bug 24313. Gfortran cannot fix a glibc bug. We don't know
when glibc is going to be released (also maybe if you complain to the distro
you use they will release a newer glibc with the fix).
***
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-24 16:41
---
*** Bug 25017 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Building ant 1.6.5 normally with gcj 4.0.2 works nicely; trying to compile the
resulting jar files into a binary fails:
After ant dist:
cd bin/lib
LINKTO=-L.
for i in *.jar; do
[ $i = ant-launcher.jar ] continue
gcj -O2 -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -o
Given the following program:
#define _GNU_SOURCE
#include stdio.h
int main ()
{
fputs_unlocked(\n, stdout);
return 0;
}
GCC fails to turn fputs_unlocked into fputc_unlocked. This fails in all GCC
versions as of 3.4 through mainline, but works in gcc-3.3 so it's a regression.
The regular
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-24 16:50 ---
a=1b;
is done in the type of b and not of type of a so this is invalid as the
behavior is undefined.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-11-24 16:51 ---
This happens because the replacement functions are obtained in builtins.c from
the array implicit_built_in_decls. This array is initialized to null when the
replacement function is an extension builtin, as are all
We fail to build the linux kernel on i686 with debugging enabled.
drivers/usb/media/w9968cf.c:
/usr/lib/gcc/i586-suse-linux/4.1.0/cc1 -fpreprocessed w9968cf.i -quiet
-dumpbase w9968cf.i -m32 -msoft-float -mpreferred-stack-boundary=2 -march=i586
-mregparm=3 -auxbase-strip
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||rth at gcc dot gnu dot org
Target Milestone|---
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-24 16:56 ---
The candidate which likely broke it is
2005-11-17 Richard Henderson [EMAIL PROTECTED]
* dwarf2out.c (dw_cfi_oprnd_struct): Reduce dw_cfi_reg_num to int.
(lookup_cfa_1): Apply data alignment to
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-11-24 16:58
---
Testcase with fewer nesting levels of templates:
templateint struct A
{
static void foo() {}
};
void bar(void (*)()) {}
templateint struct B
{
B() {
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-24 16:58 ---
Created an attachment (id=10334)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10334action=view)
testcase (unreduced)
testacse
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25023
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.2,4.1,4.0,3.4 regression]|[3.4/4.0/4.1/4.2 regression]
|failure to transform
--- Comment #3 from falk at debian dot org 2005-11-24 17:01 ---
Well, there's one actual issue here, namely that there is no warning about:
int f() {
int x = 40;
return 1 x;
}
even though we could of course detect this, albeit probably only in the
middle-end. It might be
--- Comment #5 from ghazi at gcc dot gnu dot org 2005-11-24 17:03 ---
Here's a version of the testcase that doesn't rely on _unlocked functions since
25022 inhibits the unlocked transformations. Compile at -O2 with and without
-DPUTCHAR_DIRECT to see the effect. Using putchar directly
--- Comment #4 from kargl at gcc dot gnu dot org 2005-11-24 17:03 ---
c99_functions.c contains implementations of csqrt[fl],
which are the fixed glibc routines. We can remove
the #if !defined(HAVE_CSQRTF) and simply have gfortran
use its own versions.
--
kargl at gcc dot gnu dot
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-24 17:04 ---
Created an attachment (id=10335)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10335action=view)
testcase
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25023
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-24 17:05 ---
(In reply to comment #4)
c99_functions.c contains implementations of csqrt[fl],
which are the fixed glibc routines. We can remove
the #if !defined(HAVE_CSQRTF) and simply have gfortran
use its own versions.
--- Comment #1 from reichelt at gcc dot gnu dot org 2005-11-24 17:10
---
Confirmed.
The duplicate definition was introduced in GCC 3.0.
I'll take care of the patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-24 17:11 ---
-O2 -m32 -msoft-float -mpreferred-stack-boundary=2 -march=i586 -mregparm=3
-fno-strict-aliasing -fno-common -ffreestanding -fomit-frame-pointer
-fno-unit-at-a-time -g
--
--- Comment #1 from bero at arklinux dot org 2005-11-24 17:20 ---
Verified still broken with gcc 4.0.3 SVN 107424
--
bero at arklinux dot org changed:
What|Removed |Added
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2005-11-24 17:22 ---
Subject: Re: sqrt, csqrt may give a wrong result if real part of compex
argument is zero
On Thu, Nov 24, 2005 at 05:05:12PM -, pinskia at gcc dot gnu dot org wrote:
(In reply to comment
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-11-24 17:25
---
After going to comp.lang.fortran I determined this is not a bug and gfortran is
correctly handling the given namelist. To get desired behavior use array
qualifiers with array triplet notation.
--
jvdelisle
--- Comment #4 from schwab at suse dot de 2005-11-24 17:28 ---
(In reply to comment #2)
a=1b;
is done in the type of b and not of type of a
The type of the right operand of a shift expression has no significance at all.
1 has type int, so has 1b.
--
--- Comment #30 from phython at gcc dot gnu dot org 2005-11-24 17:34
---
On powerpc-linux, I get the following timings:
Using the following command line:
g++ -O3 -o t41 -mcpu=7450 -mtune=7450 pr17863.cc -static
real user
3.4 0m11.761s 0m11.148s
4.0 0m10.196s 0m9.495s
--- Comment #5 from bero at arklinux dot org 2005-11-24 18:07 ---
This should be marked important regression IMO, it breaks a number of
applications out there
--
bero at arklinux dot org changed:
What|Removed |Added
The following simple procedure causes an ICE:
subroutine A()
EXTERNAL A
END
Error message with compiler gcc version 4.2.0 20051124 (experimental) is:
crash2.f:0: internal compiler error: in build_function_decl, at
fortran/trans-decl.c:1114
With compiler gcc version 4.0.2
Following is the relevant output from my make.
gmake[3]: Entering directory
`/usr/local/.src/gcc.obj/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++'
/bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile
/usr/local/src/gcc.obj/gcc/xgcc -shared-libgcc -B/usr/local/src/gcc.obj/gcc/
--- Comment #5 from amylaar at gcc dot gnu dot org 2005-11-24 18:56 ---
Subject: Bug 21623
Author: amylaar
Date: Thu Nov 24 18:55:53 2005
New Revision: 107468
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107468
Log:
PR target/21623:
* regclass.c
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-24 20:03 ---
Confirmed, the inline-asm is required (this testcase does not reduce any
further really).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #40 from pluto at agmk dot net 2005-11-24 20:21 ---
it also builds on i486. unfortunately amd64 fails on a-except even with -O0.
(...)
stage1/xgcc -Bstage1/ -B/usr/x86_64-pld-linux/bin/ -c -march=x86-64 -O2 -ggdb
-gnatpg -gnata -g -O0 \
-I- -I. -Iada -I../../gcc/ada
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-24 20:42 ---
Here is a reduced testcase as far as I can get it:
struct device_driver {
const char * name;
};
struct video_picture {
unsigned short a,b,c,d,e;
};
struct w9968cf_device {
struct device_driver *driver;
my gcc is configured with:
../configure
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--infodir=/usr/share/info --mandir=/usr/share/man
--x-libraries=/usr/X11R6/lib --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-languages=c,c++,ada,java --enable-c99
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-24 21:19 ---
Patch posted.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-24 21:19 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01780.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-24 22:11
---
(In reply to comment #5)
The -x option in gfortran is not really a good replacement as described
in my comment #2.
While I completely agree with you, I don't see a way to do that with the
current framework. On
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2005-11-24 22:14
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
1 - 100 of 119 matches
Mail list logo
