--- Comment #6 from jason at gcc dot gnu dot org 2006-09-04 07:51 ---
Fixed in 4.1. The patch is too dangerous to backport to 4.0.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from tbm at cyrius dot com 2006-09-04 10:10 ---
And what if you don't specify --with-sysroot? Everything else compiles fines
without this option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28009
--- Comment #29 from paul dot richard dot thomas at cea dot fr 2006-09-04
10:31 ---
Created an attachment (id=12183)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12183&action=view)
Fix for HJ's problems
HJ,
Could you try this one, please? I am pretty certain it will do the job
--- Comment #6 from jakub at gcc dot gnu dot org 2006-09-04 11:28 ---
Can you
readelf -Ws libstdc++.so.6 | egrep '[EMAIL PROTECTED]' | grep -v ' _Z'
on both libraries (the 4.0 built one and 4.1.x --with-long-double-128 one)?
The 4.0.x built one should contain the (DFmode) long double *l
[EMAIL PROTECTED]:~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--enable-nls
--- Comment #8 from paul dot richard dot thomas at cea dot fr 2006-09-04
12:08 ---
Even simpler is:
trans-array.c(gfc_trans_array_constructor_value)
replace loopvar = se.expr;
byloopvar = gfc_evaluate_now (se.expr, pblock);
gfc_expand_constructor is called f
--- Comment #7 from jakub at gcc dot gnu dot org 2006-09-04 12:14 ---
I have downloaded your tarball and it seems you are not building gcc to default
to 128-bit long double on a glibc 2.4+ system. That's very bad idea,
you either shouldn't have upgraded to glibc 2.4+, or should have swi
--- Comment #3 from kumura at r2 dot dion dot ne dot jp 2006-09-04 12:48
---
When I ported gcc to our processor architecture a year ago, I found this might
be a problem.
But, now things have changed.
Old version of the function reg_overlap_mentioned_for_reload_p() had abort() in
it
and
Hi *,
the attached code exhibits bad code generation for a
double invocation of MATMUL ().
Running the code with any recent gfortran gives:
h(3,:) = -3.4028235E+38 -3.4028235E+38 -3.4028235E+38
Bummer!
The result should be:
h(3,:) = 2.00 2.00 3.00
Cheers,
-ha
--- Comment #1 from anlauf at gmx dot de 2006-09-04 12:51 ---
Created an attachment (id=12184)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12184&action=view)
Demo code for MATMUL bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28947
--- Comment #9 from jv244 at cam dot ac dot uk 2006-09-04 14:10 ---
(In reply to comment #7)
> Looking at how we deal with all this, we seem to like pow() very much during
> folding, even doing the reverse transformations you suggest. The
> transformation
> back to sqrt ( x**N ) with N
The exact version of GCC: 3.4.2
The system type; WINDOWS XP, DEV C++ IDE
The options given when GCC was configured/built; --
The complete command line that triggers the bug; NA
The compiler output (error messages, warnings, etc.); NONE
The preprocessed file (*.i*) that triggers the bug, generated
--- Comment #10 from rguenther at suse dot de 2006-09-04 14:17 ---
Subject: Re: Missed optimization with power
On Mon, 4 Sep 2006, jv244 at cam dot ac dot uk wrote:
>
>
> --- Comment #9 from jv244 at cam dot ac dot uk 2006-09-04 14:10 ---
> (In reply to comment #7)
> > Look
--- Comment #13 from nathan at gcc dot gnu dot org 2006-09-04 15:22 ---
Subject: Bug 23287
Author: nathan
Date: Mon Sep 4 15:21:50 2006
New Revision: 116679
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116679
Log:
cp/
PR 23287 Revert my 2006-09-01 patch.
* par
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-09-04 15:22 ---
> Furthermore, defining _Tag in an anonymous namespace will cause the compiler
> to
> give all functions with _Tag in their signature internal linkage. I don't
> understand why you would want this.
This is precisely
--- Comment #14 from nathan at gcc dot gnu dot org 2006-09-04 15:22 ---
I have reverted this patch.
--
nathan at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-09-04 15:25 ---
...this is a PCH vs. anonymous namespace issue. Crack smoking! If PCH is
incommpatible with anonymous namespaces, then -Winvalid-pch needs to warn about
it at the time of pch creation.
I'm going to check in a fix to
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-09-04 15:26 ---
Fixed.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
As the subject says. Take this:
-
namespace {
void f() {}
}
int main () {
f();
}
-
and then do this:
g/x> c++ -fprofile-generate x.cc ; ./a.out
g/x> c++ -fprofile-use x.cc
x.cc: In function 'void::f()':
x.cc:6: error: coverage mismatch for funct
I did:
../configure --target=arm-linux --prefix=/usr/local/DIR/gcc-arm- svn20060904
--enable-languages=c --with-as=/usr/local/bin/arm-linux-as
--with-ld=/usr/local/bin/arm-linux-ld --without-headers --disable-shared
--disable-multilib --enable-threads=single --disable-nls --disable-libmudflap
--di
--- Comment #1 from bunk at stusta dot de 2006-09-04 15:34 ---
Created an attachment (id=12185)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12185&action=view)
configure log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
--- Comment #2 from bunk at stusta dot de 2006-09-04 15:34 ---
Created an attachment (id=12186)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12186&action=view)
make log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-09-04 15:41 ---
Subject: Bug 28871
Author: bkoz
Date: Mon Sep 4 15:41:18 2006
New Revision: 116680
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116680
Log:
2006-09-04 Benjamin Kosnik <[EMAIL PROTECTED]>
PR c++/28
--- Comment #1 from bangerth at dealii dot org 2006-09-04 16:04 ---
I forgot to say that this comes from trying to use -fprofile-use on 447.dealII
from SPEC 2006...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28948
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28947
I am able to verify that the regex for
gcc/testsuite/gcc.target/powerpc/ppc-and-1.c is
incorrect as previously diagnosed on the gcc mailing list...
http://gcc.gnu.org/ml/gcc/2006-09/msg00030.html
...and that the following change fixes the problem...
--- gcc-4.2-20060901/gcc/testsuite/gcc.target
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-04 16:16 ---
This is a dup of bug 26399 which was fixed for 4.2.0.
*** This bug has been marked as a duplicate of 26399 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-04 16:16 ---
*** Bug 28948 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-04 16:21 ---
What does config.log show? This works for me for a cross to powerpc64-linux,
though I am using a sysroot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-04 16:23 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #4 from bunk at stusta dot de 2006-09-04 16:27 ---
Created an attachment (id=12187)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12187&action=view)
arm-linux/libiberty/config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-04 16:42 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from bunk at stusta dot de 2006-09-04 16:46 ---
I can reproduce it trying to build a cross compiler for a powerpc64-linux-
target.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-04 16:50 ---
Confirmed, a regression from 2.95.3 which almost means the new ia32 back-end
caused this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-04 17:07 ---
Once my current builds are finished, I will look into fixing this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #30 from hjl at lucon dot org 2006-09-04 17:39 ---
Gcc 4.2.0 revision 116560 plus the patch in comment #29 fixes this regression
and passes SPEC CPU 2006. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
--- Comment #31 from paulthomas2 at wanadoo dot fr 2006-09-04 17:48 ---
Subject: Re: [4.1/4.2 Regression]: fold_convert fails
for Fortran operator
hjl at lucon dot org wrote:
>--- Comment #30 from hjl at lucon dot org 2006-09-04 17:39 ---
>Gcc 4.2.0 revision 116560 plus the
--- Comment #2 from hjl at lucon dot org 2006-09-04 17:49 ---
It is entirely coincident. For some processors, it is an optimization to avoid
partial flag register stall. When it is fixed, it should be reenabled with a
new flag, something like TARGET_PARTIAL_FLAG_REG_STALL.
--
hjl at
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-09-04
17:56 ---
This specific case can probably be solved at the tree level by changing the
test:
(nb >> 5) != 0
to
nb > 32
--
dann at godzilla dot ics dot uci dot edu changed:
What|Removed
When compiling with g++ 4.1.1 (shipping build on Fedora 5 i386), the following
line cause runtime segmentation fault.
voidAddElement (const T& val) { _array[Newidx()] = val; }
A complete test case is attached below.
The error also occurs on gcc 4.2.0 (built from snapshot, gcc version 4.2.0,
--- Comment #1 from sourceinsight001 at gmail dot com 2006-09-04 18:46
---
Created an attachment (id=12188)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12188&action=view)
[4.1.1 regression] runtime segfault with AddElement(): assignment of array
element
A complete test case
-
--- Comment #2 from sourceinsight001 at gmail dot com 2006-09-04 18:49
---
No special compilation option is used. It looks like this:
g++ -c test_addelem.cxx -o test_addelem.o
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28951
tree check error with -ftree-vectorize: expected class 'expression', have
'exceptional' (ssa_name) in vectorizable_condition, at
tree-vect-transform.c:2122
(sid)142:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-gcc -c -ftree-vectorize
-O1
freeciv-spacerace.c
freeciv-spacerace.c: In function 'sen
--- Comment #1 from tbm at cyrius dot com 2006-09-04 18:56 ---
Created an attachment (id=12189)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12189&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28952
--
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 #32 from howarth at nitro dot med dot uc dot edu 2006-09-04
18:58 ---
Paul,
FYI, between the changes in the proposed patch here and others in gcc trunk
to gfortran.h, resolve.c and trans-types.c, the proposed patch for PR 20541
needs to be readjusted again.
--- Comment #2 from tbm at cyrius dot com 2006-09-04 19:00 ---
Reduced some more:
struct player_spaceship
{
_Bool structure[32];
};
struct player
{
struct player_spaceship spaceship;
};
struct packet_spaceship_info
{
char structure[32 + 1];
};
send_spaceship_info (void)
{
int j;
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-04 19:09 ---
voidAddElement (const T& val) { _array[Newidx()] = val; }
I think this code contains unspecified behavior.
There are no sequence points between the this->_array and the function call
Newidx() so we load this
--
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 #3 from pinskia at gcc dot gnu dot org 2006-09-04 19:15 ---
Confirmed, we have:
D.1539_10 = pplayer_4->spaceship.structure[j_11];
iftmp.1_2 = D.1539_10 ? 49 : 48;
Which is valid.
It is caued by:
/* We do not handle two different vector types for the condition
and
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-04 19:20 ---
Yep, that worked so this is not a bug but a bug in your code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from gin at mo dot msk dot ru 2006-09-04 19:32 ---
Subject: Re: -B$(build_tooldir)/bin/
> Why do you think this wrong? -B. is suppied first so this is not a bug
If during build all files are found through `-B./' (or other
specification of part of build tree containing
operand.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20060904-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cse.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27616
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-09-04 19:33
---
The proposed change in comment #8 appears to give several testsuite failures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28914
operand.
Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/20060904-1.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/cse.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27616
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-09-04 19:38
---
Fixed everywhere.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Hello,
the documentation for the program gprmake is missing.
--
Summary: Documentation for gprmake is missing
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo:
--- Comment #4 from gin at mo dot msk dot ru 2006-09-04 20:02 ---
A question was sent to original reporter:
> Why do you think this wrong?
If it was needed at all, the actions on the bug could have depended on the
answer, and whether it should be closed could be decided only after rece
--- Comment #33 from paulthomas2 at wanadoo dot fr 2006-09-04 20:33 ---
Subject: Re: [4.1/4.2 Regression]: fold_convert fails
for Fortran operator
Jack,
I know *sigh* First I have to fix that which was working that I
broke. Then I will fix that which was neither broken nor fixe
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-09-04 23:11
---
Well I confirmed this is not on cygwin. Now I have to build a mingw version.
Sorry this is taking so long.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
--- Comment #9 from patchapp at dberlin dot org 2006-09-05 01:07 ---
Subject: Bug number PR tree-opt/28937
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-09/msg00121.html
--
http://gcc.gnu.org/b
--- Comment #16 from patchapp at dberlin dot org 2006-09-05 01:09 ---
Subject: Bug number PR 26069
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-09/msg00117.html
--
http://gcc.gnu.org/bugzilla/
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-05 02:22 ---
I have a fix, just move the conditional below the next one which checks for
comparisions expressions.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-05 04:19 ---
I have a fix for this, it needed a couple of different fixes.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #34 from pault at gcc dot gnu dot org 2006-09-05 04:26 ---
Subject: Bug 28908
Author: pault
Date: Tue Sep 5 04:26:10 2006
New Revision: 116690
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116690
Log:
2006-09-05 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/2
--- Comment #35 from pault at gcc dot gnu dot org 2006-09-05 04:30 ---
Subject: Bug 28908
Author: pault
Date: Tue Sep 5 04:29:56 2006
New Revision: 116691
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116691
Log:
2006-09-05 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/2
--- Comment #36 from pault at gcc dot gnu dot org 2006-09-05 04:32 ---
Closed, at last!
Thanks everybody.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-05 04:52 ---
Actually it looks like an oversight of what relayout_decl does. The reason is
that relayout_decl was added by the patch to fix "PR c++/16115" and I think
Jason forgot about user specified alignment because he was on
--- Comment #4 from uros at kss-loka dot si 2006-09-05 06:20 ---
(In reply to comment #2)
> It is entirely coincident. For some processors, it is an optimization to avoid
> partial flag register stall. When it is fixed, it should be reenabled with a
> new flag, something like TARGET_PART
69 matches
Mail list logo
