--- Comment #69 from jv244 at cam dot ac dot uk 2007-02-17 09:17 ---
(In reply to comment #68)
Current gfortran compiles the code with the standard -OX switches, however,
still ICEs with '-O2 -fbounds-check -ftree-vectorize -ftree-loop-linear
-ffast-math -O2 -msse3' on our local
Configuring with:
/usr/local/src/gcc/configure --prefix=/home/Marco/Desktop/manual-test/gcc
--with-sysroot=/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/sys-root
--enable-languages=c,c++ --with-gmp=/home/Marco/Desktop/compile-lin-lin/gmp-out
--- Comment #1 from schwab at suse dot de 2007-02-17 10:16 ---
Your sysroot is missing the kernel headers. There should be a dependency of
glibc-devel on the appropriate package that contains them.
--
schwab at suse dot de changed:
What|Removed
--- Comment #2 from mtrudel at gmx dot ch 2007-02-17 11:30 ---
No, for these reasons:
- It worked for 4.2
- I would agree if I used --with-build-sysroot
- It works with a cross host=mingw target=linux
- It doesn't work if I copy the missing headers to sysroot
--
mtrudel at gmx dot
--- Comment #3 from schwab at suse dot de 2007-02-17 12:12 ---
Please show the output of ls
/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/sys-root/usr/include/linux/errno.h.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #4 from mtrudel at gmx dot ch 2007-02-17 12:23 ---
Update:
It works if I copy the kernel-headers into $SYS_ROOT/usr/include instead of
$SYS_ROOT/include.
However, I really think this should not be required since it worked with gcc
4.2 and everything else is the same. So
paolo:~/Work/lex g++ -fdump-tree-all -c ice.cc
ice.cc:14: internal compiler error: in dequeue_and_dump, at tree-dump.c:326
--
Summary: ICE with -fdump-tree-all
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from pcarlini at suse dot de 2007-02-17 13:00 ---
Created an attachment (id=13060)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13060action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30833
--- Comment #8 from steven at gcc dot gnu dot org 2007-02-17 14:12 ---
*** Bug 30790 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2007-02-17 14:12 ---
*** This bug has been marked as a duplicate of 30773 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from schwab at suse dot de 2007-02-17 14:31 ---
$SYS_ROOT/include has no significance. The standard include directory is
/usr/include, and sysroot mirrors exactly the standard directory layout.
--
schwab at suse dot de changed:
What|Removed
--- Comment #6 from michael dot haubenwallner at salomon dot at 2007-02-17
14:35 ---
(In reply to comment #5)
There is another bug (PR15087) about GCC not obeying the IA64 runtime
alignment
requrements in other cases.
Huh, this one is nearly three years old.
After reading that
--- Comment #7 from michael dot haubenwallner at salomon dot at 2007-02-17
15:01 ---
Maybe coincident, but using gcc-3.4.5 with '-O2' works for this one testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30826
--- Comment #11 from tobi at gcc dot gnu dot org 2007-02-17 15:10 ---
(In reply to comment #9)
(In reply to comment #8)
Oh, just noticed this by chance: Steve's testcase also fails with
optimization
disabled, again the call to mpfr_erf is issued in do_mpfr_arg1.
Do you get a
$ gfortran pow.f90
pow.f90:3.15:
end program pow
1
Internal Error at (1):
gfc_arith_power(): Bad exponent
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/ig25/gcc/trunk/configure --prefix=/home/ig25
--enable-maintainer-mode
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-02-17 15:22 ---
The test case was missing :-)
Here it is:
$ cat pow.f90
program pow
print *,1.0**(2_8**33_8)
end program pow
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
--- Comment #10 from manu at gcc dot gnu dot org 2007-02-17 15:46 ---
How can this be tested? Would this work?
Index: gcc/prefix.c
===
--- gcc/prefix.c(revision 121953)
+++ gcc/prefix.c(working copy)
@@
--- Comment #70 from steven at gcc dot gnu dot org 2007-02-17 16:01 ---
The -ftree-loop-linear work is still too buggy at this time to be taken
seriously. I would strongly recommend against even considering the use of it.
--
steven at gcc dot gnu dot org changed:
What
the following, reduced from PR29975, causes a gfortran ICE:
MODULE test
INTEGER, PARAMETER :: dp=KIND(0.0D0), xas_scf_default=1, xas_2s_type=2
TYPE xas_control_type
INTEGER :: state_type,nexc_atoms
END TYPE
TYPE xas_environment_type
INTEGER :: scf_method
END TYPE
CONTAINS
--- Comment #12 from ghazi at gcc dot gnu dot org 2007-02-17 16:15 ---
(In reply to comment #11)
I understand the idea of bulding with --prefix, it's just that I've had mixed
success using it wiht mpfr/gmp. Especially, when the system administrator
installed them locally behind my
--- Comment #71 from jv244 at cam dot ac dot uk 2007-02-17 16:17 ---
(In reply to comment #68)
Current gfortran compiles the code with the standard -OX switches, however,
still ICEs with '-O2 -fbounds-check -ftree-vectorize -ftree-loop-linear
-ffast-math -O2 -msse3' on our local
--- Comment #13 from tobi at gcc dot gnu dot org 2007-02-17 17:12 ---
Midair collision, I had just written this, but I do indeed have problems with
shared libraries taking precedence over others, so it looks like I'll have to
rebuild gcc once more:
OK, I tried the following:
1. I built
--- Comment #14 from tobi at gcc dot gnu dot org 2007-02-17 17:14 ---
(In reply to comment #13)
Midair collision, I had just written this, but I do indeed have problems with
shared libraries taking precedence over others, so it looks like I'll have to
rebuild gcc once more:
That is
--- Comment #23 from pault at gcc dot gnu dot org 2007-02-17 17:17 ---
Subject: Bug 30617
Author: pault
Date: Sat Feb 17 17:16:56 2007
New Revision: 122074
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122074
Log:
2007-02-17 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #15 from pault at gcc dot gnu dot org 2007-02-17 17:17 ---
Subject: Bug 30554
Author: pault
Date: Sat Feb 17 17:16:56 2007
New Revision: 122074
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122074
Log:
2007-02-17 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #7 from pault at gcc dot gnu dot org 2007-02-17 17:17 ---
Subject: Bug 30319
Author: pault
Date: Sat Feb 17 17:16:56 2007
New Revision: 122074
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122074
Log:
2007-02-17 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #16 from pault at gcc dot gnu dot org 2007-02-17 17:18 ---
Fixed on trunk and 4.2
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pault at gcc dot gnu dot org 2007-02-17 17:20 ---
Fixed on trunk and 4.2
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pcarlini at suse dot de 2007-02-17 17:34 ---
I have some improvements in testing...
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #15 from tobi at gcc dot gnu dot org 2007-02-17 17:46 ---
I moved my system gmp mpfr out of the way, re-built gmp and mpfr with
--disable-shared, and I'm now getting a bootstrap failure
/usr/bin/ld: Undefined symbols:
___gmpn_preinv_divrem_1
collect2: ld returned 1 exit
The code:
#include iostream
templatetypename T struct foo {
static const int i = 0; };
template
templatetypename U struct fooU[] {
static const int i = 1; };
int main() {
int v[5];
std::cerr fooint[5]::i : fooint[]::i \n;
return 0;
}
prints:
0:1
which shows that int[5] is
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-17 17:49 ---
I am 99% sure this was caused by the CALL_EXPR change as tcc_vl_exp is not
handled in that switch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2007-02-17 17:55 ---
Yup! Does it for me too.
Thanks, Thomas
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2007-02-17 18:36 ---
Yup, these lines in gfc_arith_power make the assumption that we'll
never have an integer exponent outside the range INT_MIN to INT_MAX.
if (gfc_extract_int (op2, power) != NULL)
gfc_internal_error
--- Comment #16 from ghazi at gcc dot gnu dot org 2007-02-17 18:36 ---
(In reply to comment #14)
(In reply to comment #13)
Midair collision, I had just written this, but I do indeed have problems
with
shared libraries taking precedence over others, so it looks like I'll have
--- Comment #3 from sandra at codesourcery dot com 2007-02-17 18:51 ---
Created an attachment (id=13061)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13061action=view)
patch to tree-dump.c
I've verified that this patch gets rid of the ICE.
--
--- Comment #4 from pcarlini at suse dot de 2007-02-17 19:08 ---
I would venture to say you can commit it as obvious (after proper
regtesting)...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30833
--- Comment #17 from ghazi at gcc dot gnu dot org 2007-02-17 19:10 ---
(In reply to comment #16)
Maybe we should have gcc -v print out the gmp and mpfr versions to help
debug
situations like this.
Patch for gcc -v here:
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01503.html
--
--- Comment #1 from igodard at pacbell dot net 2007-02-17 19:11 ---
p.s. I know I can catch it with:
template
templateType T, size_t N
struct fooT[N] {...}
but I though that plain [] would catch it too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30836
struct foo{ typedef int bar; };
int main() {
foo f;
typeof(f)::bar i = 0;
return 0;
}
gets you:
~/ootbc/sim/test$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:4: error: expected initializer before 'i'
--
Summary: typeof fails
Product: gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-17 20:02 ---
*** This bug has been marked as a duplicate of 6709 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-17 20:02 ---
*** Bug 30837 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709
--- Comment #1 from steven at gcc dot gnu dot org 2007-02-17 20:24 ---
(gdb) run
Starting program: ./f951 -O2 -ftree-loop-linear t.f90
xas_env_init
Analyzing compilation unit
Performing interprocedural optimizations
visibility early_local_cleanups inline static-var pure-const
--- Comment #11 from Woebbeking at web dot de 2007-02-17 20:42 ---
Subject: Re: header dependencies
On Saturday 17 February 2007, pcarlini at suse dot de wrote:
I have some improvements in testing...
Nice to hear :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
--- Comment #2 from igodard at pacbell dot net 2007-02-17 20:50 ---
Not fixed for four years? How come?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30837
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-17 21:10 ---
After looking at this a little bit, I think we may want to
change the error message to report the invalid integer exponent
value and document that INT_MIN = e = INT_MAX. Why? Well,
other than the special values of
--- Comment #6 from drow at gcc dot gnu dot org 2007-02-17 21:24 ---
Subject: Re: [regression] --with-sysroot=foobar wrong handled
On Sat, Feb 17, 2007 at 12:23:51PM -, mtrudel at gmx dot ch wrote:
However, I really think this should not be required since it worked with gcc
4.2
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-02-17 21:27 ---
After looking at this a little bit, I think we may want to
change the error message to report the invalid integer exponent
value and document that INT_MIN = e = INT_MAX. Why? Well,
other than the special
--- Comment #13 from tkoenig at gcc dot gnu dot org 2007-02-17 21:29
---
Hi Tobias,
should we close this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30512
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-02-17 21:43 ---
This appears to have been fixed in the meantime:
$ perl multi-case-c 30 multi-case.c
(reverse-i-search)`g': gcc multi-case.c
$ gdb ~/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1
GNU gdb 6.4.90-debian
Copyright (C)
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2007-02-17 21:51 ---
Subject: Re: ICE with kind=8 exponentiaton
On Sat, Feb 17, 2007 at 09:27:07PM -, tkoenig at gcc dot gnu dot org wrote:
After looking at this a little bit, I think we may want to
change
--- Comment #8 from pault at gcc dot gnu dot org 2007-02-17 22:42 ---
This works and regtests OK:
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 121864)
--- gcc/fortran/resolve.c (working
--- Comment #3 from bangerth at dealii dot org 2007-02-17 23:33 ---
(In reply to comment #2)
Not fixed for four years? How come?
No volunteers to fix it? Not an important bug that bothers many people?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30837
The file libjava/classpath/lib/gen-classlist.sh.in, which apparantly
generates
sparc-sun-solaris2.10/sparcv9/libjava/classpath/lib/gen-classlist.sh, has at
line 58
if test ! ${top_builddir} -ef @top_srcdir@; then
However, the -ef operator is not supported by the sh shell under Solaris
(which is
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-18 02:10 ---
You did not read the installation instructions which mentions you need to set
CONFIG_SHELL for solaris.
http://gcc.gnu.org/install/specific.html#x-x-solaris2
The Solaris 2 /bin/sh will often fail to configure
55 matches
Mail list logo
