--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-03-10 08:11
---
I can confirm this on latest trunk. Its blocking bootstrap.
From config log on objdir/gcc:
config.log:conftest.c:2: error: parse error before me
config.log:conftest.c:62: error: `__int64' undeclared (first use
The following program produces the wrong error:
ivec_= 1 2
Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of
array 'ivec' (in file 'x.f90', at line 20)
with -fbounds-check.
Taken from:
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-10 08:47 ---
The problem is that the bounds of an optional argument are checked,
regardlessly whether it is present.
int8 ubound.0;
if (ivec != 0B)
{
ubound.0 = (ivec-dim[0].ubound - ivec-dim[0].lbound) + 1;
--- Comment #23 from Jean-pierre dot vial at wanadoo dot fr 2007-03-10
08:48 ---
the two test files from the LAPACK library
dget33.f and sget33.f whose compilation with gfortran failed
with -O3 optmisation are now compiled without error or warning.
tested with gfortran 4.3 experimental
With gfortran 4.3.0 20070309 (powerpc-apple-darwin7) compiling
integer_exponentiation_1.f90 with -ffast-math gives an ICE with:
[address=806b1964 pc=00087bfc]
integer_exponentiation_1.f90: In function 'MAIN__':
integer_exponentiation_1.f90:4: internal compiler error: Segmentation Fault
This has
--- Comment #1 from dominiq at lps dot ens dot fr 2007-03-10 10:25 ---
FX Coudert reported that compiling the following code
real :: a, b
a = 3.0
b = a**(-4294967296_8)
print *, b
end
segfaults on i686-linux (without -ffast-math). On OSX 10.3.9 I get
Out of stack space.
Try
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-10 10:49 ---
Confirmed on OSX 10.3.9 with snapshot 4.3.0 20070309.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
Configured with: ../trunk/configure --enable-languages=c,c++ --disable-nls
--enable-checking=release build_alias=i486-linux-gnu host_alias=i486-linux-gnu
target_alias=i486-linux-gnu
Thread model: posix
gcc version 4.3.0 20070310 (experimental)
./cc1plus -quiet -v -iprefix
/home/stevenb/src/build/gcc
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-03-10 12:34 ---
(In reply to comment #7)
(In reply to comment #6)
This makes minloc have rank 0, and allows for
inlining.
No, it's wrong. See F95 13.14.71: Result Characteristics. The result is of
type default integer. If
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-03-10 12:33 ---
(In reply to comment #1)
FX Coudert reported that compiling the following code
real :: a, b
a = 3.0
b = a**(-4294967296_8)
print *, b
end
segfaults on i686-linux (without -ffast-math).
This is
--- Comment #10 from patchapp at dberlin dot org 2007-03-10 12:55 ---
Subject: Bug number PR30531
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-03/msg00602.html
--
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-10 12:56 ---
(In reply to comment #2)
I have just submitted a ptch to the list.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31086
--- Comment #3 from ubizjak at gmail dot com 2007-03-10 13:04 ---
(In reply to comment #2)
No, this is not a target problem. I have traced the problem down to
This _was_ a target problem after all...
Fixed by patch at http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00603.html:
--- Comment #3 from hp at gcc dot gnu dot org 2007-03-10 13:13 ---
r122748 affects newlib's __free_r, __malloc_r, __strtod_r, ___ulp and __dtoa_r.
The investigation continues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31115
--- Comment #4 from wouter dot vermaelen at pi dot be 2007-03-10 13:51
---
I originally triggered this bug in SVN revision 122749.
In revision 122793 I can't reproduce it anymore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31102
gcc (not g++) seems to treat for loops rather oddly. Sometimes (not all the
time -- appears to be somewhat random), if a variable is declared in the header
of the for loop it complains with the following message:
for loop initial declaration used outside C99 mode
The following program
--- Comment #1 from frederik dot hertzum at gmail dot com 2007-03-10 14:00
---
This was tested on a dual core i686 Fedora Core 6.
gcc -v output:
Target: i386-redhat-linux
Konfigureret med: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared
--- Comment #3 from aldyh at gcc dot gnu dot org 2007-03-10 14:14 ---
This has nothing to do with my patch. When I remove the cse.c patch, the
-ftree-vectorize goes away, so it's probably related to that patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31116
With this configure and build:
#!/bin/tcsh
/bin/rm -rf * ; env CC='/pkgs/gcc-4.2.0-64/bin/gcc' ../configure
--host=powerpc64-apple-darwin8.8.0 --target=powerpc64-apple-darwin8.8.0
--build=powerpc64-apple-darwin8.8.0 --prefix=/pkgs/gcc-4.2.0-64-test
--with-gmp=/pkgs/gmp-4.2.1-64
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-10 14:57 ---
Oh, I missed this was a cris-axis-elf target (newlib supposedly), my
investigation
was on a x86_64-linux target. I suspect my patch may be wrong in the case of
negative shift counts, I'm investigating.
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-03-10 15:11 ---
Created an attachment (id=13185)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13185action=view)
patch
Can you check if the attached patch fixes the failures for you?
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-10 15:27 ---
Can you check if this is a dup of PR31115 by applying the proposed patch in
there?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31122
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-10 15:27 ---
Err, ignore that. That's not about 4.2.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31122
--- Comment #6 from hp at gcc dot gnu dot org 2007-03-10 16:31 ---
That patch didn't help. FWIW, for 6.cc it's _strtod_r that fails.
Investigating.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31115
--- Comment #12 from burnus at gcc dot gnu dot org 2007-03-10 16:47 ---
Latest patch:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00607.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-10 16:57 ---
GCC defaults to GNU89 mode and declares loop initial declaration as invalid,
use either -std=gnu99 or -std=c99 if you want to use loop initial declaration
in C.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-03-10 16:57
---
It was supposed to have been fixed on 03/04 (see PR ada/26797).
Could you post the list of ACATS failures you still have on this platform?
--
ebotcazou at gcc dot gnu dot org changed:
What
--- Comment #17 from mueller at gcc dot gnu dot org 2007-03-10 17:26
---
Subject: Bug 17946
Author: mueller
Date: Sat Mar 10 17:26:33 2007
New Revision: 122798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122798
Log:
2007-03-10 Dirk Mueller [EMAIL PROTECTED]
PR
--- Comment #3 from lucier at math dot purdue dot edu 2007-03-10 17:44
---
Removing the build directory from the source tree got rid of this problem for
me.
So I don't know what people want to do about this bug. Over the years some
people have worked to fix such problems as bugs; and
Executing on host: /home/dave/gnu/gcc-4.3/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4
.3/objdir/gcc/
/home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/bu
iltin-bitops-1.c -w -O3 -fomit-frame-pointer -funroll-loops -fno-show-column
-lm -o
As suggested at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/a19c9fdd1503e9c5/
While gfortran does not has this kind of warning, g95 -Wextra warns:
In file crud.f90:5
integer, parameter :: one = 1
1
Warning (159): PARAMETER 'one' at (1) is never
--- Comment #8 from mmitchel at gcc dot gnu dot org 2007-03-10 19:35
---
Subject: Bug 20924
Author: mmitchel
Date: Sat Mar 10 19:35:03 2007
New Revision: 122801
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122801
Log:
PR c++/20924
* tree.c (walk_type_fields):
--- Comment #2 from eweddington at cso dot atmel dot com 2007-03-10 19:40
---
From the link in comment #1, on the gcc list, from Jim Wilson:
DW_AT_member_location seems to consequently equal -1 (ff ff ff ff) for
the first member of a bitfield.
FYI You can get descriptive
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-03-10 19:44
---
Subject: Bug 20924
Author: mmitchel
Date: Sat Mar 10 19:44:11 2007
New Revision: 122802
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122802
Log:
PR c++/20924
* tree.c (walk_type_fields):
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-03-10 19:49
---
Fixed in 4.2, 4.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #24 from paolo at gcc dot gnu dot org 2007-03-10 20:29 ---
Subject: Bug 28080
Author: paolo
Date: Sat Mar 10 20:29:45 2007
New Revision: 122805
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122805
Log:
2007-03-10 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #4 from tg at mirbsd dot org 2007-03-10 20:31 ---
It's not fixed on 4.1 branch:
[EMAIL PROTECTED]:~/tmp $ cat _t.c
typedef unsigned size_t;
char *xxcpy( char *pDest, const char *pSrc, size_t n);
char *strncpy( char *pDest, const char *pSrc, size_t n) {
if (pDest == 0 ||
--- Comment #3 from pcarlini at suse dot de 2007-03-10 20:46 ---
Humm, I'm afraid this is basically a WONTFIX or at least WONTFIX-ANY-TIME-SOON,
because we talking about targets using the GENERIC locale model, where, at
variance with the GNU locale model, on which we are focused of
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-03-10 20:55 ---
Reopening. It's fixed for 64bit systems but not 32bit ones!? vrp dump
difference:
Visiting statement:
-D.1617_3 = pDest_2 == 0B;
+D.1286_3 = pDest_2 == 0B;
-Found new range for D.1617_3: VARYING
+Found new
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-03-10 21:18
---
I cannot reproduce it with GCC 4.1.2, but only with GCC 4.0.0 - 4.1.1.
IMHO it's a duplicate of PR 29730, which got fixed in December.
*** This bug has been marked as a duplicate of 29730 ***
--
reichelt at
--- Comment #8 from reichelt at gcc dot gnu dot org 2007-03-10 21:18
---
*** Bug 31026 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-10 21:24 ---
Actually, strncpy is a reserved name so we assume pDest and pSrc are non-null.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-10 21:29 ---
You can use -fno-builtin-strncpy or -ffreestanding to fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30785
--- Comment #4 from reichelt at gcc dot gnu dot org 2007-03-10 21:37
---
I'm getting a different error message:
bug.m:2: warning: cannot find interface declaration for 'NGActiveSocket'
bug.m:2: error: 'm' undeclared here (not in a function)
bug.m:2: internal compiler error: tree
--- Comment #18 from manu at gcc dot gnu dot org 2007-03-10 21:43 ---
(In reply to comment #17)
Modified:
trunk/gcc/testsuite/ChangeLog
Just Changelog changes??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-10 22:04 ---
extern void abort(void);
void foo (int e1)
{
if (e1 0)
{
e1 = -e1;
if (e1 = 4)
{
if (e1 = 1 5)
abort();
}
}
}
int main()
{
foo(-(15));
return 0;
}
--- Comment #8 from hp at gcc dot gnu dot org 2007-03-10 22:04 ---
Created an attachment (id=13186)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13186action=view)
Preprocessed code
cc1 -fpreprocessed strtod.i -melf -quiet -dumpbase strtod.c -auxbase-strip
nrblib_a-strtod.o -g -O2
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-03-10 22:08 ---
Actually the testcase from comment #7 should abort() and I got the numbers
wrong. The following is more usual at that it aborts if the code is wrong:
extern void exit(int);
extern void abort();
void foo (int e1)
{
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-10 22:15
---
It's the same issue as the SPEC/Polyhedron regression from ians patches.
Reverting them fixes the testcase, my patch just did uncover it for newlib :/
--
rguenth at gcc dot gnu dot org changed:
--- Comment #7 from reichelt at gcc dot gnu dot org 2007-03-10 22:15
---
Here's a shorter testcase, that crashes since GCC 4.0.0 on i686-pc-linux-gnu:
=
module FOO
interface BAR
module procedure X, Y,
end interface BAR
end module
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-10 22:46
---
Actually my patch is wrong as well. We just trigger it only with ians patch as
-[-INF,-1] is [1, +INF(OVF)] with overflowed +INF.
I'll re-test the following with my previous fix for negative shift counts.
--- Comment #4 from reichelt at gcc dot gnu dot org 2007-03-10 22:59
---
No preprocessed source provided for 9 months.
I downloaded the respective package and tried to reproduce the bug
(on i686-pc-linux-gnu) to no avail.
GCC 4.1.x compiles the file in question.
Mainline and 4.2
The following invalid code snippet triggers an ICE since GCC 4.1.0:
===
@interface
===
bug.mm:1: error: expected identifier at end of input
bug.mm:1: internal compiler error: tree check: expected identifier_node, have
error_mark in outer_binding, at cp/name-lookup.c:3886
The compiler enters an infinite loop since GCC 4.1.0 on the following
invalid code snippet:
===
@interface A
===
bug.mm:1: error: expected unqualified-id at end of input
bug.mm:1: error: expected unqualified-id at end of input
bug.mm:1: error: expected unqualified-id at
--- Comment #9 from manu at gcc dot gnu dot org 2007-03-11 00:31 ---
I tried setting TREE_OVERFLOW on a new node created from the zero of the
division by zero and then replacing the zero in 1/0 by this new node. It didn't
work, it seems that somehow the node that represents the result
I have destilled the following small testcase from Wine, specifically
dlls/advapi32/security.c.
Compiling this with -O2 results in an ICE in cse_find_path at cse.c:5930.
void ParseStringSidToSid(char *s, int* p) {
int i = 0;
while (*s) {
while (*s *s != '-')
s++;
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-11 01:37 ---
Most likely caused by:
2007-03-09 Alexandre Oliva [EMAIL PROTECTED]
PR rtl-optimization/30643
* cse.c (cse_insn): Recompute dest_hash after insert_regs for
dest_addr_elt.
In a delta reduction from an ICE compiling code from LLVM's C backend, I get
the following one-line testcase:
void f() { __builtin_stack_restore(f); }
$ gcc-4.1 b2.c -c
b2.c: In function foo:
b2.c:2: internal compiler error: in lhd_set_decl_assembler_name, at
langhooks.c:165
Please submit a
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-11 01:51 ---
I get a different ICE on the mainline with checking enabled:
t.c:1: internal compiler error: tree check: expected tree that contains 'decl
with RTL' structure, have 'addr_expr' in expand_stack_restore, at
I think this is what #31124 is really about.
Consider the following:
program fred
integer::i
integer,parameter::j=9
end
With -Wunused a warning is generated for i, but not j. (At least with my 4.2
prerelease.)
--
Summary: No warning on unused parameters
Product: gcc
--- Comment #1 from terry at chem dot gu dot se 2007-03-11 01:57 ---
I've filed #31129 specifically for the parameter case. This is unrelated to
the private attribute.
--
terry at chem dot gu dot se changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-11 01:58 ---
I have a patch to force this not to be exposed to the user, these builtin was
never documented so they should not be exposed and they are never used outside
of the internals of the compiler either.
--
pinskia at
--- Comment #3 from nicholas at mxc dot ca 2007-03-11 02:16 ---
That's fair; we were relying on an undocumented builtin (see llvm.org/PR1028).
If you remove it, can you provide a substitute?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31128
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-11 02:20 ---
The solution I have for you is to use VLAs correctly and {}, basically going
lowered VLAs of __builtin_stack_restore/__builtin_stack_save/__builtin_alloca
to back VLAs.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-11 02:57 ---
Created an attachment (id=13187)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13187action=view)
patch which hides the stack functions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31128
--- Comment #10 from mmitchel at gcc dot gnu dot org 2007-03-11 03:08
---
Subject: Bug 30274
Author: mmitchel
Date: Sun Mar 11 03:07:59 2007
New Revision: 122813
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122813
Log:
PR c++/30274
* cp-tree.h
--- Comment #11 from mmitchel at gcc dot gnu dot org 2007-03-11 03:09
---
Subject: Bug 30274
Author: mmitchel
Date: Sun Mar 11 03:09:32 2007
New Revision: 122814
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122814
Log:
PR c++/30274
* cp-tree.h
--- Comment #12 from mmitchel at gcc dot gnu dot org 2007-03-11 03:10
---
Fixed in 4.2.0, 4.3.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-03-11 03:22
---
Joseph --
Do you have any insight into this bug, from your work on SPE?
Thanks,
-- Mark
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-11 03:30 ---
Fixed in 4.2.0 by the patch which Mark applied for PR 30274.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from fang at csl dot cornell dot edu 2007-03-11 03:47
---
In fact, I'm having trouble reproducing the problem when operator delete []
returns anything BUT NULL. It's as if, the actual call to operator delete []
is guarded by a NULL check. Now, if I'm RTHS (reading the
76 matches
Mail list logo
