--- Comment #7 from rguenth at gcc dot gnu dot org 2006-08-09 07:31 ---
So, I have a fix as the problem is latent on mainline, too.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bonzini at gnu dot org 2006-08-09 07:42 ---
Uhm, fixing this will resurface a wrong-code bug, PR28651, which is more
important than this missed optimization. :-(
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #8 from pluto at agmk dot net 2006-08-09 09:45 ---
works fine with 4.2.0-20060806 rev. 115974 on x86-64.
current 4.1.2 build in progress...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20586
--- Comment #8 from patchapp at dberlin dot org 2006-08-09 09:50 ---
Subject: Bug number PR28651
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-08/msg00247.html
--
When compiling the code below with '-O -Wuninitialized', I get spurious
warnings:
piekana:~$ cat gforttest.f90
program runoptf90
implicit none
real :: x(1)
call simulated_annealing (x)
contains
subroutine simulated_annealing (xmin)
real, intent(inout) :: xmin(:)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 10:20 ---
Actually this is worse than what is said here, this is wrong code. In a
prerelease of 4.1.0, we allocate r after we allocate x so the size of x is not
know at the time we allocate r.
--
pinskia at gcc dot gnu
--- Comment #9 from pluto at agmk dot net 2006-08-09 10:36 ---
the only C bootstrap still shows failures for 4.1.2.
Bootstrap comparison failure!
./c-format.o differs
./combine.o differs
./expmed.o differs
./global.o differs
./i386.o differs
./reg-stack.o differs
./regclass.o differs
--- Comment #2 from snordin_ng at yahoo dot fr 2006-08-09 10:39 ---
Thanks for this astuteness. It's great and works well.
Since we use lcov to obtain a suitable output in html format
for class and method's coverage, I'll try to modify it using
c++filt.
I'll inform you about results.
--- Comment #2 from erik dot edelmann at iki dot fi 2006-08-09 10:54
---
(In reply to comment #1)
Actually this is worse than what is said here, this is wrong code. In a
prerelease of 4.1.0, we allocate r after we allocate x so the size of x is not
know at the time we allocate r.
--- Comment #8 from jr at e-integration dot net 2006-08-09 13:52 ---
Created an attachment (id=12046)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12046action=view)
gcc-4.1.1/gcc/gthr-solaris.h weak declaration
Fails with latest gcc-4.1.1/gcc/gthr-solaris.h file during
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
See http://gcc.gnu.org/ml/fortran/2006-08/msg00145.html
Currently gfortran calls cpp with the option -traditional-cpp. Using this
option, newer macros like
#define msg(x) print *, #x
don't work (the #x causes the argument to be quoted). (See url/email for
example.)
I couldn't find any
--- Comment #3 from patchapp at dberlin dot org 2006-08-09 14:20 ---
Subject: Bug number PR28630
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-08/msg00265.html
--
--- Comment #4 from patchapp at dberlin dot org 2006-08-09 14:20 ---
Subject: Bug number PR28600
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-08/msg00266.html
--
--- Comment #5 from jakub at gcc dot gnu dot org 2006-08-09 14:29 ---
It was caused by the openmp changes, but guess usually the parent routine
at least touches the dummy argument and therefore it would be added to the
right context.
I was testing:
--- trans-decl.c.jj 2006-08-09
--- Comment #52 from whaley at cs dot utsa dot edu 2006-08-09 14:33 ---
Paolo,
In some sense, this is the peephole I would rather *not* do. But the answer
is yes. :-)
Ahh, got it :)
So, do you now agree that the bug would be fixed if the patch that is in GCC
4.2 was backported to
gcj -O2 -fomit-frame-pointer -fweb -frename-registers -fPIC -fjni -shared
-Wl,-O2,--as-needed,--enable-new-dtags,-soname,libecj.so.3 -o libecj.so.3
ecj.jar
org/eclipse/jdt/internal/compiler/lookup/Scope.java: In class
'org.eclipse.jdt.internal.compiler.lookup.Scope':
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-08-09 14:38 ---
I can trivially fix this, but the code isn't going to do what you want when i'm
done, since it is an aliasing violation :)
The assert in question just happens to be good at catching them.
--
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot
|dot org
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot
|dot org
--- Comment #2 from janis at gcc dot gnu dot org 2006-08-09 15:46 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=revrev=102182
r102182 | giovannibajo | 2005-07-20 01:19:59 + (Wed, 20 Jul 2005)
--
janis at gcc dot gnu dot
--- Comment #53 from whaley at cs dot utsa dot edu 2006-08-09 15:52 ---
Created an attachment (id=12047)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12047action=view)
benchmark wt vectorizable kernel
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-08-09 15:52
---
Fails with latest gcc-4.1.1/gcc/gthr-solaris.h file during bootstrap.
As indicated in the target milestone field, this will be fixed in 4.1.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28247
--- Comment #54 from whaley at cs dot utsa dot edu 2006-08-09 16:08 ---
Dorit,
OK, I've posted a new tarfile with a safe kernel code where the loop is not
unrolled, so that the vectorizer has a chance. With this kernel, I can make it
vectorize code, but only if I throw the
+++ This bug was initially created as a clone of Bug #28247 +++
gcc 4.1.1 cannot buld on Solaris 9 sparc:
$ ./configure --prefix=/home/gcc --enable-threads=solaris
--enable-languages=c,c++ --enable-shared=libstdc++ --disable-multilib
--disable-nls sparc64-sun-solaris2.9
$ make
...
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-09 16:44
---
*** Bug 28665 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 16:44 ---
What don't you understand that this was already fixed for the next release of
4.1.x aka 4.1.2?
*** This bug has been marked as a duplicate of 28247 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from jr at e-integration dot net 2006-08-09 16:52 ---
Created an attachment (id=12048)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12048action=view)
/gcc-4.1.1/gcc/gthr-solaris.h Solaris threads header file
bootstrap fails:
Here's my configure:
--- Comment #3 from pault at gcc dot gnu dot org 2006-08-09 17:47 ---
uuuhhh! This is horrible and is a reflection of the symtree being ordered as a
binary tree. If 'r' is renamed 'zr', the order of translation is changed and
the code runs correctly; albeit still with an unrequited
--- Comment #1 from janis at gcc dot gnu dot org 2006-08-09 17:48 ---
A regression hunt using an s390-linux cross compiler on powerpc-linux, with the
submitter's testcase and options, identified this patch:
http://gcc.gnu.org/viewcvs?view=revrev=88869
r88869 | pinskia |
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-09 17:56 ---
My patch just exposed a latent bug as it does nothing that was not already done
before RTH removed the folding.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24367
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 18:03 ---
One problem without using -tranditional-cpp is that some tokens in C are not
tokens in Fortran so you could get the wrong result. This is why
-tranditional-cpp is used.
There is no standard for Preprocessed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28600
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28663
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-08-09 18:10 ---
One problem without using -tranditional-cpp is that some tokens in C are not
tokens in Fortran so you could get the wrong result. This is why
-tranditional-cpp is used.
I though the
/* { dg-do compile } */
/* { dg-options -O2 -fforce-addr } */
extern int foo (void *, long, double *);
extern int bar (void *, double, long *);
extern double copysign (double, double);
extern double floor (double);
int
test (void *a, long *b, long *c)
{
double x, z;
if (!foo (a, b[0], x))
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28132
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 18:16 ---
This is a dup of bug 28132.
*** This bug has been marked as a duplicate of 28132 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-09 18:16 ---
*** Bug 28667 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2006-08-09 18:27 ---
(In reply to comment #5)
It was caused by the openmp changes, but guess usually the parent routine
at least touches the dummy argument and therefore it would be added to the
right context.
I was testing:
---
--- Comment #7 from jakub at gcc dot gnu dot org 2006-08-09 18:36 ---
Go with your version, you posted first ;).
I added the comment just to support your patch, that I independently came
to a (almost) same fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:43
---
Subject: Bug 28637
Author: lmillward
Date: Wed Aug 9 18:43:06 2006
New Revision: 116043
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116043
Log:
2006-08-09 Lee Millward [EMAIL PROTECTED]
PR
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-08-09 18:43
---
Subject: Bug 28639
Author: lmillward
Date: Wed Aug 9 18:43:06 2006
New Revision: 116043
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116043
Log:
2006-08-09 Lee Millward [EMAIL PROTECTED]
PR
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-08-09 18:43
---
Subject: Bug 28641
Author: lmillward
Date: Wed Aug 9 18:43:06 2006
New Revision: 116043
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116043
Log:
2006-08-09 Lee Millward [EMAIL PROTECTED]
PR
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-08-09 18:43
---
Subject: Bug 28638
Author: lmillward
Date: Wed Aug 9 18:43:06 2006
New Revision: 116043
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116043
Log:
2006-08-09 Lee Millward [EMAIL PROTECTED]
PR
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-08-09 18:43
---
Subject: Bug 28640
Author: lmillward
Date: Wed Aug 9 18:43:06 2006
New Revision: 116043
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116043
Log:
2006-08-09 Lee Millward [EMAIL PROTECTED]
PR
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:44
---
Fixed on mainline. Will be fixed on 4.1 branch when the patch for PR 27668 is
reverted.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:45
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-09 18:45
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:47
---
Partially fixed on mainline, the testcase now ICE's in the same place as PR
24791.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:47
---
Partially fixed on mainline, the testcase now ICE's in the same place as PR
24791.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 19:08 ---
6809 is not in the FSF GCC at all.
Contact the person who you got the compiler from.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Here's some questions I need to figure out:
(1) Why do I have to throw the -funsafe-math-optimizations flag to
enable this?
-- I see where the .vect file warns of it, but it refers to an SSA
line,
so I'm not sure what's going on.
This flag is needed in order to allow vectorization
--- Comment #55 from dorit at il dot ibm dot com 2006-08-09 19:10 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code
on all platforms than gcc 3
Here's some questions I need to figure out:
(1) Why do I have to throw the -funsafe-math-optimizations flag to
enable
Tied to version 3.4.5, unable to try with current build.
Here is the output, followed by part of the preprocessed source:
Output:
[EMAIL PROTECTED] flt]$ /usr/users/bonomo/gnu/cross/m6809/bin/gcc -v -save-temps
-Wall -B/usr/users/bonomo/gnu/cros
s/m6809/bin/ -S -c test.c^M
Reading specs from
--- Comment #2 from bonomo at sal dot wisc dot edu 2006-08-09 19:14 ---
Subject: Re: internal compiler error: in find_reloads, at
reload.c:3690
Ah! This is not really a gcc bug then. That's a bit of
a relief.
Rich
On Wed, 9 Aug 2006, pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from bonomo at sal dot wisc dot edu 2006-08-09 19:14
---
Subject: Re: internal compiler error: in find_reloads, at
reload.c:3690
Ah! This is not really a gcc bug then. That's a bit of
a relief.
It is most likely a GCC bug but with the port to the target
--- Comment #3 from pinskia at physics dot uc dot edu 2006-08-09 19:16
---
Subject: Re: internal compiler error: in find_reloads, at reload.c:3690
--- Comment #2 from bonomo at sal dot wisc dot edu 2006-08-09 19:14
---
Subject: Re: internal compiler error: in
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-08-09 19:17
---
The file you've attached is incorrectly patched. Please get it from a snapshot
or the SVN repository.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28665
In cp/decl.c there is this code.
error (%smember function %qD cannot have cv-qualifier,
(ctype ? static : non-), decl);
The first string, %smember ... is available for translation in the po-file,
but not the parts substituted, static and non-. And even if they were, it
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-08-09 20:03
---
poog% uname -a
SunOS poog 5.9 Generic_117171-12 sun4u sparc SUNW,Sun-Fire-V250
poog% gcc/xgcc -v
Using built-in specs.
Target: sparc64-sun-solaris2.9
Configured with: /home/eric/svn/gcc-4_1-branch/configure
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 21:08 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #56 from whaley at cs dot utsa dot edu 2006-08-09 21:33 ---
Dorit,
This flag is needed in order to allow vectorization of reduction (summation
in your case) of floating-point data.
OK, but this is a bd flag to require. From the computational scientist's
point of view,
--- Comment #56 from whaley at cs dot utsa dot edu 2006-08-09 21:33
---
Dorit,
This flag is needed in order to allow vectorization of reduction (summation
in your case) of floating-point data.
OK, but this is a bd flag to require. From the computational scientist's
--- Comment #57 from pinskia at physics dot uc dot edu 2006-08-09 21:46
---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code on all
platforms than gcc 3
--- Comment #56 from whaley at cs dot utsa dot edu 2006-08-09 21:33
---
Dorit,
This flag is
--- Comment #15 from eedelman at gcc dot gnu dot org 2006-08-09 21:55
---
Created an attachment (id=12049)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12049action=view)
Updated patch
Fix the problem reported by Jack.
--
eedelman at gcc dot gnu dot org changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28600
struct X { X( int ); };
struct Y { Y( X const ); };
void test()
{
Y y1( 1 ); // conversion works fine.
Y y2 = 2; // error: conversion from #8216;int#8217; to non-scalar
// type #8216;Y#8217; requested.
}
msvc accepts both variants, g++ only one.
is it a bug in g++ or
This happens when trying to compile strigi 0.3.2
(http://www.vandenoever.info/software/strigi/) with gcc trunk from today
results in
Linking CXX executable dummyindexer
CMakeFiles/dummyindexer.dir/dummyindexer.o: In function `__exchange_and_add':
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 22:51 ---
What options are being used to compile the software with?
if -march=i386, then this is not a bug with the compiler.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from bero at arklinux dot org 2006-08-09 22:54 ---
-O2 -march=i586 -mcpu=i686 -fomit-frame-pointer
--
bero at arklinux dot org changed:
What|Removed |Added
--- Comment #58 from whaley at cs dot utsa dot edu 2006-08-09 23:01 ---
Andrew,
Except for the fact IEEE compliant fp does not allow for reordering at all
except
in some small cases. For an example is (a + b) + (-a) is not the same as (a +
(-a)) + b,
so reordering will invalid IEEE fp
--- Comment #3 from pcarlini at suse dot de 2006-08-09 23:08 ---
First, a general remark: this kind of error must never happen, irrespective of
the options used to build user code and/or GCC.
Then, it looks like _GLIBCXX_ATOMIC_BUILTINS is defined for that installation
of GCC. In turn,
--- Comment #4 from pcarlini at suse dot de 2006-08-09 23:30 ---
One additional remark: if the entire software package is really built with
-march=i586, then, in any case, the __sync_fetch_and_add call at line 47 of
atomicity.h is expanded in line and the link problem cannot occur as
--- Comment #5 from pcarlini at suse dot de 2006-08-09 23:48 ---
Benjamin, in case this problem is confirmed (and some strange details of the PR
are sorted out), can you please double check that we are not incurring in the
issue I was fearing here:
--- Comment #6 from bero at arklinux dot org 2006-08-09 23:55 ---
Ok, misunderstanding about the compiler flags -- -march=i586 was used to build
the compiler, strigi was built without any -march= tags (making the default
i386, I guess).
Using -march=i586 in strigi makes the problem go
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-09 23:58 ---
Can you give your exact commands use to build GCC?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pcarlini at suse dot de 2006-08-10 00:05 ---
(In reply to comment #6)
Ok, misunderstanding about the compiler flags -- -march=i586 was used to build
the compiler, strigi was built without any -march= tags (making the default
i386, I guess).
Using -march=i586 in
With revision 116045, gcc mainline went into infinite loop when compiling
libstdc++-v3/src/wlocale-inst.cc.
--
Summary: [4.2 Regression]: Gcc went into infinite loop when
building libstdc++
Product: gcc
Version: 4.2.0
Status:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-10 02:08 ---
Testcase?
Do you ever follow directions?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from pault at gcc dot gnu dot org 2006-08-10 04:29 ---
(In reply to comment #3)
order the declarations or something.
Paul
Having slept on it, I realise that this will not work because the statement
order should not matter. I think that there will have to be a
--- Comment #5 from patchapp at dberlin dot org 2006-08-10 04:35 ---
Subject: Bug number PR25828
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-08/msg00300.html
--
--- Comment #3 from pault at gcc dot gnu dot org 2006-08-10 04:56 ---
I can see what the problem is - when I wrote this section of code in expr.c, I
did the conditions for step and finish correctly but for begin, I wrote:
/* Obtain the start value for the index. */
if
84 matches
Mail list logo
