--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-02
10:57 ---
Reconfirmed with gcc version 4.0.0 20050101 (experimental) at -O0 on SPARC
32-bit.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-02
11:03 ---
Clobber_Hour_Of:
save%sp, -112, %sp
st %i0, [%fp+68]
ld [%fp+68], %g1
add %g1, 5, %g1
mov %g1, %o0
callAssign_Hour_Of, 0
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-02
11:11 ---
.t03.generic is already wrong:
Clobber_Hour_Of (dt)
{
struct Time_T * D.1122;
D.1122 = dt-Time;
Assign_Hour_Of (D.1122);
}
struct Time_T is 32-bit aligned so D.1122 must be a multiple of 4; as
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-02
11:27 ---
Patch submitted:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00036.html
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-02
11:30 ---
Confirmed, a regression from 3.3.2 present on 3.4 branch only.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-02
11:32 ---
Investigating.
--
What|Removed |Added
CC|ebotcazou at gcc dot gnu dot|
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-02
11:53 ---
Pop probably wants to know about this too. Obviously a regression because
pre-4.0 there was no scev, and so no infinite loop either.
--
What|Removed |Added
--- Additional Comments From aj at gcc dot gnu dot org 2005-01-02 12:05
---
I've reduced the testcase to the following loop:
int
add_long(long tl1, long tl2, long tloop_cnt, long *res)
{
int n;
long l1, l2, l;
l1 = tl1;
l2 = tl2;
l = 0;
for (n = tloop_cnt; n
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-02
12:07 ---
The problem comes from the address representation clauses:
Parameter_Table : PARAMETER_TABLE_TYPE;
for Parameter_Table'Address use Full_Parameter_Table.Element'Address;
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From baldrick at free dot fr 2005-01-02 14:26
---
(In reply to comment #1)
D.351 = (system__address *) (SIGNED_32) D.359;
Confirmed, looks like a front-end problem, it should have made a temprary
variable to hold the value
and then taken the address.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02
15:55 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
What|Removed |Added
Keywords||ice-on-valid-code, memory-
||hog
Target Milestone|---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02
16:04 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00034.html.
--
What|Removed |Added
When running the testsuite on i686-pc-linux-gnu using 3.4.x or mainline with
either -fpic or -fPIC, I get an execution failure in g++.dg/eh/omit-frame-
pointer2.C as shown here:
http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00085.html
http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00084.html
--
What|Removed |Added
Component|c++ |middle-end
Keywords||EH, wrong-code
Summary|[3.4,4.0
--- Additional Comments From giovannibajo at libero dot it 2005-01-02
16:45 ---
Are we really forced to support ADDR_EXPR on unaligned fields? How would you
fix it with a temporary? Are you going to generate a FINALLY_EXPR to copy the
contents of the temporary back into the original
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-02
16:46 ---
Subject: Bug 12092
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-01-02 16:46:46
Modified files:
gcc:
When running the GCC testsuite on i686-pc-linux-gnu using -fpic or -fPIC, I get
additional failures with 3.3, 3.4 and mainline:
FAIL: g++.old-deja/g++.pt/asm1.C (test for excess errors)
FAIL: g++.old-deja/g++.pt/asm2.C (test for excess errors)
as shown here:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02
17:04 ---
Lets look at the testcases:
__asm__ __volatile__(addl %1, %0 : =a (v) : b (i));
Hmm, IIRC ebx is the PIC register so this should not be tested at all
-fPIC/-fpic.
--
What|Removed
When running the testsuite on 3.3, 3.4 and mainline with -fpic or -fPIC I get
the following additional error at -O0:
FAIL: gcc.c-torture/compile/2804-1.c, -O0
3.4 additionally gets an error at -O1 as seen in these results:
http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00029.html
--- Additional Comments From kghazi at verizon dot net 2005-01-02 17:18
---
Subject: Re: ICE in g++.old-deja/g++.pt/asm1.C and asm2.C with -fpic/-fPIC
I'm not familiar with inline asm, what exactly in the testcase reveals that
ebx will be used?
Thanks.
--
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-02
17:20 ---
Are we really forced to support ADDR_EXPR on unaligned fields? How would you
fix it with a temporary? Are you going to generate a FINALLY_EXPR to copy the
contents of the temporary back into the
When running the testsuite on 3.3, 3.4 and mainline with -fpic or -fPIC I get
the following additional error:
FAIL: gcc.dg/2009-1.c (test for excess errors)
The failures can be seen here:
http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00029.html
When running the testsuite on 3.3 with -fpic or -fPIC I get the following
additional error:
FAIL: gcc.dg/asm-names.c (test for excess errors)
http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00029.html
http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00085.html
When running the testsuite on 3.3 with -fpic or -fPIC I get the following
additional error:
FAIL: gcc.dg/asm-names.c (test for excess errors)
http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00029.html
http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00085.html
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-01-02 17:58
---
*** Bug 19230 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19229
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-01-02 17:58
---
*** This bug has been marked as a duplicate of 19229 ***
--
What|Removed |Added
When running the testsuite on mainline with -fpic or -fPIC I get these
additional execute failures:
FAIL: gcc.c-torture/execute/builtins/strlen-3.c execution, -O2
FAIL: gcc.c-torture/execute/builtins/strlen-3.c execution, -O3 -fomit-frame-
pointer
FAIL:
When running the testsuite with mainline on i686-pc-linux-gnu with -fpic or -
fPIC, I get the following additional failures:
FAIL: gcc.dg/assign-warn-3.c (test for warnings, line 9)
FAIL: gcc.dg/assign-warn-3.c (test for warnings, line 13)
The expected warnings simply fail to appear with the
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-01-02
18:48 ---
The loop probably is not infinite (after removing a few commands from the loop,
compilation finishes after a long time). Investigating further.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19224
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-01-02
18:55 ---
Caused by an exponential time complexity of instantiate_parameters.
I am working on a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19224
With LAST_UPDATED: Sun Jan 2 12:24:12 UTC 2005 I get:
FAIL: g++.old-deja/g++.ext/attrib5.C (test for excess errors)
With the message in the .log being:
/gcc/testsuite/g++.old-deja/g++.ext/attrib5.C:7: warning: 'void f()' aliased to
undefined symbol '_f'
Last known to work on: Sat Jan 1
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-01-02 19:10 ---
Here a further reduction of the problem.
This compiles fine
logical a, b
a(b) = .true.
b = .false.
if (a(b)) b = .true.
end
The parse tree is
ASSIGN b
--- Additional Comments From danglin at gcc dot gnu dot org 2005-01-02
19:53 ---
Adding a bit of assembler code to the .s file to define
_ZNSt6locale13_S_categoriesE eliminates the error:
...
.globl __ZNSt6locale18_S_categories_sizeE
.text
.align 2
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-01-02
20:29 ---
Patch coming.
This is also a latent bug forever in gcc.
We've been generating fbreg for a lot of things we shouldn't, we just never
noticed before now because it didn't try to evaluate them at runtime
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-01-02 20:37 ---
(In reply to comment #5)
Caused by an exponential time complexity of instantiate_parameters.
I am working on a patch.
The following patch solves the exponential time complexity.
Sorry for the
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-02 20:56 ---
Subject: Re: [4.0 regression] Endless loop compiling simple file: Bug in
tree-scalar-evolution.c (instantiate_parameters_1)?
(In reply to comment #5)
Caused by an exponential time
--- Additional Comments From andre dot maute at gmx dot de 2005-01-02
21:06 ---
well i've tested gcc-4.0-20050102, (compiled with gcc-4.0-20041212)
g++-4.0-20050102 -v
Using built-in specs.
Configured with: ../gcc-4.0-20050102/configure --prefix=/opt/gcc-4.0-20050102
--enable
I was trying to work around the problem described in PR 19120 by doing totaly
unoptimized build:
[EMAIL PROTECTED]:::~/tmp/gcc-head/objdir CFLAGS=-O0 -fno-omit-frame-pointer
-g3
BOOT_CFLAGS=-O0 -fno-omit-frame-pointer -g3 LIBCFLAGS=-O0
-fno-omit-frame-pointer -g3 ../srcdir/configure
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-01-02 21:46 ---
(In reply to comment #7)
Subject: Re: [4.0 regression] Endless loop compiling simple file: Bug in
tree-scalar-evolution.c (instantiate_parameters_1)?
not really (well, maybe in this
--- Additional Comments From giovannibajo at libero dot it 2005-01-02
22:14 ---
(In reply to comment #6)
But users will definitely notice slower bootstraps, thus further
contributing to the perceived feeling that GCC is forever getting
slower.
This is an urban legend. Please do
--- Additional Comments From gschafer at zip dot com dot au 2005-01-02
22:27 ---
This is an urban legend.
I agree with the above comment, but you've completely missed my point.
With gcc-3.4.3, I can `make bootstrap' with --enable-languages=c and it takes
7:25. With gcc-4.0, I do the
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-01-02 23:15 ---
Subject: Re: [4.0 regression] Endless loop compiling simple file: Bug in
tree-scalar-evolution.c (instantiate_parameters_1)?
rakdver at gcc dot gnu dot org wrote:
--- Additional
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-01-02
23:19 ---
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00052.html
--
What|Removed |Added
--- Additional Comments From andre dot maute at gmx dot de 2005-01-02
23:44 ---
the C-version works with every compiler
nan.c ---
#include stdio.h
int main() {
double x = 0.8023;
printf( %f , x );
printf( %f , x );
When compiling with following CVS HEAD snapshot from 30.12.2004
---
# gcc -v
Using built-in specs.
Configured with: ../../../gcc-CVS-20041230/gcc-CVS-20041230/configure
--host=i686-pc-linux-gnu --prefix=/usr/local/opt/gcc-4.0
--exec-prefix=/usr/local/opt/gcc-4.0
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-03
03:34 ---
Subject: Bug 12092
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-03 03:33:58
Modified files:
gcc/testsuite : ChangeLog
--- Additional Comments From danglin at gcc dot gnu dot org 2005-01-03
03:35 ---
Created an attachment (id=7862)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7862action=view)
Patch to add missing static member to instantiation
--
The C compiler crashes upon seeing the 'log1p()' function, as follows:
$ gcc-snap -ffast-math -c test-logsum.c
test-logsum.c: In function 'test':
test-logsum.c:6: error: unrecognizable insn:
(insn 9 8 10 1 (set (reg:XF 63)
(float_extend:XF (reg:XF 61))) -1 (nil)
(expr_list:REG_DEAD
--- Additional Comments From bangerth at dealii dot org 2005-01-03 05:24
---
Confirmed. This is a regression over 3.4.x.
My mainline snapshot if from 20041214, so the problem predates that date.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-01-03 05:30
---
The minimal testcase is this:
extern double log1p (double __x);
double test () {
return log1p(1.0);
}
g/x /home/bangerth/bin/gcc-4.0-pre/bin/c++ -ffast-math
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-03
06:26 ---
Subject: Bug 14631
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-03 06:26:52
Modified files:
gcc: ChangeLog
gcc/config/i386:
--- Additional Comments From uros at kss-loka dot si 2005-01-03 06:33
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From aj at gcc dot gnu dot org 2005-01-03 07:30
---
Let's add Uros since he worked on the i386 backend lately and Honza as another
expert.
--
What|Removed |Added
--- Additional Comments From aj at gcc dot gnu dot org 2005-01-03 07:46
---
Confirmed with gcc 4.0.0 20050102.
Adding Uros since he made recent patches in this area, and also Honza as
another expert.
--
What|Removed |Added
56 matches
Mail list logo
