--- Comment #11 from cnstar9988 at gmail dot com 2008-05-02 09:14 ---
I think it is a duplicate of PR 35169.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27794
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-05-02 09:19
---
I think it is a duplicate of PR 35169.
All the more so that this was reported on the same machine. :-)
*** This bug has been marked as a duplicate of 35169 ***
--
ebotcazou at gcc dot gnu dot org
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-05-02 09:19
---
*** Bug 27794 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenther at suse dot de 2008-05-02 09:02 ---
Subject: Re: [4.4 Regression] 435.gromacs
miscompares at -O3
On Fri, 2 May 2008, hjl dot tools at gmail dot com wrote:
--- Comment #2 from hjl dot tools at gmail dot com 2008-05-02 05:05
---
Revision
--- Comment #11 from jakub at gcc dot gnu dot org 2008-05-02 09:34 ---
The unexpected address is created by simplify_plus_minus on
(plus:DI (reg:DI 2 2)
(const:DI (minus:DI (symbol_ref/u:DI (*.LC1) [flags 0x2])
(symbol_ref:DI (*.LCTOC1)
and
(const_int 8 [0x8])
where
--- Comment #8 from burnus at gcc dot gnu dot org 2008-05-02 09:48 ---
Works for me for 4.4.0 20080424 on a X86-64 openSUSE Factory (approx. oS
11.0beta2) with a glibc 2.8 (20080410).
I wonder whether it has something to do with the recent sign/decimal comma
work.
Could those for
--- Comment #12 from jakub at gcc dot gnu dot org 2008-05-02 09:46 ---
Created an attachment (id=15561)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15561action=view)
gcc44-pr36090.patch
Untested patch that 1) tightens the checking in
legitimate_constant_pool_address_p -
--- Comment #9 from dominiq at lps dot ens dot fr 2008-05-02 10:08 ---
Could those for whose it fails try to find out which of the various LC_*
options fails?
For instance: LC_ALL=C LC_NUMERIC=zh_CN.UTF-8 or LC_CTYPE=zh_CN.UTF-8 or
...
Although I did not exhaust all the
--- Comment #48 from rguenth at gcc dot gnu dot org 2008-05-02 10:28
---
Btw, on x86_64 leslie3d performance is now above that from before r126326.
The differences you mention can be seen on x86_64 as well, but they are
not related to aliasing or partitioning but due to differences in
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-05-02 11:09 ---
Subject: Bug 36100
Author: hubicka
Date: Fri May 2 11:08:22 2008
New Revision: 134885
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134885
Log:
PR bootstrap/36100
* ipa-inline.c
--- Comment #4 from hubicka at ucw dot cz 2008-05-02 11:11 ---
Subject: Re: [4.4 Regression] always_inline attribute is broken at -O0
Hi,
I am testing the following patch that restores inlining at -O0.
Index: tree-pass.h
Attached testcases fail on x86_64 (with cmpxchg16b) or i386 (with cmpxchg8b),
in both cases the problem is that reading the original value using FPU and
storing it into a temporary doesn't mean bitwise identical copy (in the first
case because long double is said to be a 16 byte type, even when
--- Comment #1 from jakub at gcc dot gnu dot org 2008-05-02 11:40 ---
Created an attachment (id=15562)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15562action=view)
gcc44-pr36106-test.patch
Testcases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36106
When using __attribute__((weak)) on a constructor, the produced assembly file
contains an extra *INTERNAL* on the constructor declaration line.
- Here is my test code:
class Test {
public:
Test() __attribute__((weak));
};
int test() {
Test test;
}
- The compilation output:
$ g++ test.cc
--- Comment #49 from rguenth at gcc dot gnu dot org 2008-05-02 12:16
---
Missing jump-threading causes quite a number of missed FRE opportunities, we
have
if (i2 = 0)
{
... = load X
}
if (i2 = 0)
{
... = load X
}
where we figure out the redundancy
--- Comment #50 from dnovillo at google dot com 2008-05-02 12:32 ---
Subject: Re: [4.3/4.4 Regression] Revision
126326 causes 12% slowdown
On 05/02/08 08:16, rguenth at gcc dot gnu dot org wrote:
and dropping the final dom pass in favor of another FRE one (DOM has
weaker memory
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-02 12:36 ---
With a = b(k,:) - c manually unrolled the loop over k is unrolled with the
early loop unrolling pass which exposes the unvectorizable calls to sin/cos,
respective the complex temporaries introduced by the sincos
--- Comment #13 from dje at gcc dot gnu dot org 2008-05-02 12:41 ---
fwprop cannot be modified to produce the preferred RTL with the symbol_refs on
the inside and the constant on the outside instead of teaching another part of
the compiler how to print this peculiar construct?
--
Revision 134865:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01945.html
breaks gcc bootstrap:
cc1: warnings being treated as errors
/export/gnu/src/gcc/gcc/gcc/real.c: In function real_to_integer2:
/export/gnu/src/gcc/gcc/gcc/real.c:1387: error: array subscript is negative
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
Version|4.3.0 |4.4.0
--- Comment #1 from hjl dot tools at gmail dot com 2008-05-02 12:44 ---
It happens on Linux/Intel64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36108
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-02 12:46 ---
The vectorizer doesn't know to vectorize __builtin_cexpi or
{REAL,IMAG}PART_EXPR
either.
IMHO rather than somehow tweaking the early unroller the vectorizer should
know how to deal with complex types.
--
--- Comment #2 from hjl dot tools at gmail dot com 2008-05-02 12:48 ---
A simple testcase:
bash-3.2$ cat x.c
int foo [10];
int
bar (int i)
{
if (8 == 8)
return foo [1];
else
return foo [-1];
}
bash-3.2$ ./xgcc -B./ -O2 x.c -c -Wall -Werror
cc1: warnings being treated as
--- Comment #51 from rguenther at suse dot de 2008-05-02 12:55 ---
Subject: Re: [4.3/4.4 Regression] Revision
126326 causes 12% slowdown
On Fri, 2 May 2008, dnovillo at google dot com wrote:
--- Comment #50 from dnovillo at google dot com 2008-05-02 12:32 ---
Subject:
--- Comment #5 from hjl dot tools at gmail dot com 2008-05-02 12:59 ---
Gcc can't bootstrap due to PR 36108. Jan, you should revert revision 134865
when you do testing.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-05-02 13:06 ---
I believe those issues are fixed now. Can someone please confirm it?
(I've managed to swap two versions of patches and commit development version of
it)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36102
--- Comment #7 from hjl dot tools at gmail dot com 2008-05-02 13:09 ---
(In reply to comment #6)
I believe those issues are fixed now. Can someone please confirm it?
(I've managed to swap two versions of patches and commit development version
of
it)
Gcc is broken due to PR
GET_MODE_SIZE always does an array lookup. This is inefficient for mode
constants; in this case, it would be better to compare for equality for each
mode and then decide on the actual size. When workingh with mode macros, this
would allow conditionals to be folded to 0 or 1, and thus save both
--- Comment #10 from burnus at gcc dot gnu dot org 2008-05-02 13:40 ---
I can finally reproduce this - but for some reason not with 4.4 but with 4.3.
(I somehow misread the description how one should reproduce it.)
The problem is surely in
--- Comment #11 from burnus at gcc dot gnu dot org 2008-05-02 13:44 ---
(In reply to comment #10)
The problem is surely in http://gcc.gnu.org/viewcvs/trunk/gcc/po/zh_TW.po
I meant: http://gcc.gnu.org/viewcvs/trunk/gcc/po/zh_CN.po
--
--- Comment #1 from falk at debian dot org 2008-05-02 13:55 ---
I can reproduce this with 4.1, but not with 4.2.3 or 4.3.1 20080401. So it
seems to be fixed.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #52 from mmitchel at gcc dot gnu dot org 2008-05-02 14:16
---
Yes, the perfect pass problem is what concerns me too. For example, if we
try to do dynamic reordering of passes, or allow users to specify that, we have
to worry that, in practice, the compiler will crash or
--- Comment #3 from jv244 at cam dot ac dot uk 2008-05-02 14:35 ---
confirmed on x86_64-unknown-linux-gnu
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #8 from dominiq at lps dot ens dot fr 2008-05-02 14:36 ---
(In reply to comment #6 and #7)
I believe those issues are fixed now. Can someone please confirm it?
Incremental builds now work.
Gcc is broken due to PR 36108. I am testing gcc now by reverting revision
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-02 14:53 ---
It looks sub-optimal. But we should try to figure out why and what is wrong.
The optimality can be fixed with
Index: tree-ssa-loop-ivopts.c
===
---
--- Comment #53 from rguenther at suse dot de 2008-05-02 15:05 ---
Subject: Re: [4.3/4.4 Regression] Revision
126326 causes 12% slowdown
On Fri, 2 May 2008, mmitchel at gcc dot gnu dot org wrote:
--- Comment #52 from mmitchel at gcc dot gnu dot org 2008-05-02 14:16
---
--- Comment #14 from dje at gcc dot gnu dot org 2008-05-02 15:10 ---
The problematic transformation in simplify_plus_minus() is:
/* We suppressed creation of trivial CONST expressions in the
combination loop to avoid recursion. Create one manually now.
The combination loop
segmentation fault when compiling sgtrfs.f
my make.inc of lapack 3.1.1:
--
SHELL = /bin/sh
VERSION = 3.1.1
FORTRAN = gfortran
OPTS = ${FFLAGS}
DRVOPTS = $(OPTS)
NOOPT=
LOADER = $(FORTRAN)
LOADOPTS = $(OPTS)
TIMER= INT_ETIME
my $FFLAGS:
--- Comment #5 from jb at gcc dot gnu dot org 2008-05-02 15:37 ---
Working on a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
--- Comment #15 from dje at gcc dot gnu dot org 2008-05-02 15:43 ---
This patch groups RTX_CONST_OBJ before CONST_INT.
Index: simplify-rtx.c
===
*** simplify-rtx.c (revision 134851)
--- simplify-rtx.c (working
--- Comment #16 from dje at gcc dot gnu dot org 2008-05-02 15:45 ---
Copying Bonzini for him to comment on the precedence and canonicalization
issue.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-02 15:48 ---
This GCC version does not make sense: 4.4.0-20060501. I assume you mean
20080501.
The mentioned file is available at:
http://www.netlib.org/lapack/single/sgtrfs.f
I can reproduce the crash with:
$ gfortran -S -O2
--- Comment #2 from linuxl4 at sohu dot com 2008-05-02 15:56 ---
¡µThis GCC version does not make sense: 4.4.0-20060501. I assume you mean
¡µ20080501.
yes.
sorry for the wrong typing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36110
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-02 16:02 ---
See this is why I did not want this warning in the front-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from bonzini at gnu dot org 2008-05-02 16:29 ---
I wonder if your patch would be a problem because it sometimes removes a CONST
wrapping. It could also be possible to precede the CONST_INT optimization with
another test for two adjacent CONSTANT_P:
if (GET_CODE
--- Comment #12 from burnus at gcc dot gnu dot org 2008-05-02 16:38 ---
I'm not sure whether there are other problems, but at least the following is
wrong. Maybe this is enough to fix the bug. Could someone check?
I'll write the translation team to fix it there.
msgid '%s' argument of
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-05-02 16:50
---
Fixed
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
openmpi-1.2.6
--
cd openmpi-1.2.6
mkdir i95;cd i95;../configure --prefix=/usr/local/openmpi-1.2.6
make
my $CFLAGS:
-pipe -ggdb3 -limf -lsvml -O3 -march=pentium4 -mfpmath=sse -funswitch-loops
-ftree-loop-distribution -ftree-loop-linear -ftree-loop-im
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2008-05-02 17:34
---
GCC translation bug reports are taken care of by the translation project
(http://translationproject.org/). I have sent a mail to the chinese team
coordinator (LI Daobing) and GCC translation maintainer (Meng
--- Comment #18 from dje at gcc dot gnu dot org 2008-05-02 17:36 ---
Yes, the patch works, modulo typos.
if (GET_CODE (ops[n_ops - 1].op) == CONST_INT)
i = n_ops - 2;
else
i = n_ops - 1;
if (i = 1
ops[i].neg
!ops[i - 1].neg
CONSTANT_P (ops[i].op)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||spop at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-02 18:48 ---
Please attach pre-processed source of the offending source file which you can
obtain by appending -save-temps on the gcc command-line. The pre-processed
file will be named $FILE.i.
--
rguenth at gcc dot gnu dot
-Wall -Winline -Wwrite-strings
-fmerge-all-constants -quiet -Wstrict-prototypes
where
~/gcc-build-fast/gcc/cc1 --version
GNU C (GCC) version 4.4.0 20080502 (experimental) [trunk revision 134885]
(x86_64-unknown-linux-gnu)
configured with:
--enable-checking=all
Can you try latest SVN version
--- Comment #14 from lidaobing at gmail dot com 2008-05-02 18:50 ---
an updated zh_CN.po uploaded to TP[1], please help check whether it can fix
this bug.
PS. in emacs's po-mode, po-validate does not warning in this case, any script
to check this po file?
thanks.
[1]
Bounds-checking for correct character length in array-constructors without
F2003 typespec (all strings are required to have the same length) does not work
sometimes, for instance the code
call test (this is long)
contains
subroutine test(s)
character(len=*) :: s
character(len=128) ::
For compatibility with C++ and more reasonable GNU semantics, would we place
make the below program not print 0. Essentially, the type of all the
enumerators should be the underlying type of the enum, not the type that fits
the init.
#include stdio.h
#include stdint.h
#include stdlib.h
#include
--- Comment #1 from mrs at apple dot com 2008-05-02 20:16 ---
Radar 5881867
--
mrs at apple dot com changed:
What|Removed |Added
CC|
--
mrs at apple dot com changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
--- Comment #19 from bonzini at gnu dot org 2008-05-02 21:08 ---
Subject: Re: [4.3/4.4 Regression] ppc64 cacoshl miscompilation
Yes, the patch works, modulo typos.
It was not tested indeed.
Does it make sense to group any two RTX_CONST_OBJ together of not the same
type?
I don't
--- Comment #20 from dje at gcc dot gnu dot org 2008-05-02 21:23 ---
How do we proceed? Your initial patch is fine with me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #5 from hjl dot tools at gmail dot com 2008-05-02 21:35 ---
Fixed by revision 134889.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|jason at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--- Comment #3 from jason at gcc dot gnu dot org 2008-05-02 21:44 ---
*** This bug has been marked as a duplicate of 34937 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jason at gcc dot gnu dot org 2008-05-02 21:44 ---
*** Bug 34939 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34937
--- Comment #6 from hubicka at ucw dot cz 2008-05-02 21:44 ---
Subject: Re: [4.4 Regression] always_inline attribute is broken at -O0
Just for record, I am still testing the patch.
The testing scripts I used broke in a way that they ended up testing
empty patches (this is obviously
--- Comment #7 from hjl dot tools at gmail dot com 2008-05-02 21:49 ---
FYI, revision 134889 has following regressions on Linux/ia32:
FAIL: g++.dg/opt/pr30965.C scan-tree-dump-times optimized ;; Function 2
FAIL: gcc.c-torture/execute/va-arg-pack-1.c compilation, -O0
FAIL:
--- Comment #8 from hubicka at ucw dot cz 2008-05-02 21:59 ---
Subject: Re: [4.4 Regression] always_inline attribute is broken at -O0
FAIL: g++.dg/opt/pr30965.C scan-tree-dump-times optimized ;; Function 2
FAIL: gcc.c-torture/execute/va-arg-pack-1.c compilation, -O0
FAIL:
The following codes from pr29921 and pr35770:
ibook-dhum] f90/bug% cat pr29921.f90
! { dg-do compile }
SUBROUTINE foo
IMPLICIT DOUBLE PRECISION (A-H,O-Z)
LOGICAL MASWRK
COMMON /FRAME / W1,W2,W3
COMMON /FRAMES/ X1,Y1,Z1,X2,Y2,Z2,X3,Y3,Z3
PARAMETER (ZERO=0.0D+00,
This small program:
// built using g++ -o test -O2 main.cpp
#include iostream
struct stuff
{
int x;
};
class MyException : public std::exception
{
public:
MyException() { }
};
// make this global so conditional below doesn't get eliminated
bool should_throw = false;
void
--- Comment #1 from brett dot polivka at magnetar dot com 2008-05-02 22:31
---
Created an attachment (id=15563)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15563action=view)
preprocessed output of test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36115
--
brett dot polivka at magnetar dot com changed:
What|Removed |Added
Severity|normal |major
Known to fail||4.2.3
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |target
--- Comment #2 from brett dot polivka at magnetar dot com 2008-05-02 22:37
---
Created an attachment (id=15564)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15564action=view)
preprocessed output of test program
Previous version was from wrong code
--
--- Comment #15 from pinskia at gcc dot gnu dot org 2008-05-03 00:09
---
hehe:
tree DSE : 4.79 (14%) usr 0.05 ( 6%) sys 5.11 (14%) wall
2 kB ( 0%) ggc
tree PRE : 9.79 (29%) usr 0.12 (14%) sys 10.32 (29%) wall
2016 kB ( 1%) ggc
tree FRE
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
When the attached example is compiled by the
gcc version 4.4.0 20080430 (experimental) (GCC)
using
gcc -O2 -ftree-loop-distribution -funsafe-loop-optimizations -m32 -c
png2theora.c.c -o x.o
it produces the following error:
png2theora.c: In function
--- Comment #1 from martin dot drab at fjfi dot cvut dot cz 2008-05-03
02:27 ---
Created an attachment (id=15565)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15565action=view)
Triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36116
--- Comment #2 from linuxl4 at sohu dot com 2008-05-03 04:09 ---
Created an attachment (id=15566)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15566action=view)
malloc.i
ok.please see the attachment file.
cd
79 matches
Mail list logo
