--- Comment #4 from dominiq at lps dot ens dot fr 2008-07-18 06:46 ---
This is due to revision 137859:
2008-07-15 Daniel Berlin <[EMAIL PROTECTED]>
* tree-ssa-sccvn.c (expressions_equal_p): Check type equality.
* tree-ssa-pre.c (pre_expr_eq): Ditto
(get_consta
gcc: cannot specify -o with -c or -S and multiple compilations
make: *** [clicmds.def] Error 1
--
Summary: i was getting the error as below when i am making
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priorit
--- Comment #19 from cnstar9988 at gmail dot com 2008-07-18 03:37 ---
ping...
gcc 4.2.3 works well, gcc 4.2.4/4.3.0/4.3.1 works failed.
i386-pc-solaris2.10
gas 2.18 + sun ld
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
--- Comment #14 from dj at redhat dot com 2008-07-18 00:22 ---
Subject: Re: [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in
reload
Seems to work for m32c too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-17 22:30 ---
Created an attachment (id=15927)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15927&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36864
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-17 22:28 ---
Full backtrace:
#0 0x00502761 in get_constant_for_value_id (v=427, type=0x42e163f0) at
/Users/apinski/src/local/gcc/gcc/tree-ssa-pre.c:1027
#1 0x005029f4 in fully_constant_expression (e=0x440408d8) at
/Users/apinsk
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-17 22:24 ---
0x004ffca7 in get_constant_for_value_id (v=427, type=0x4402c710) at
/Users/apinski/src/local/gcc/gcc/tree-ssa-pre.c:1027
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from burnus at gcc dot gnu dot org 2008-07-17 21:12 ---
The problem is the following in matchexp.c:
gfc_get_parentheses (gfc_expr *e)
{
gfc_expr *e2;
/* This is a temporary fix, awaiting the patch for various
other character problems. The resolution and transla
--- Comment #3 from ubizjak at gmail dot com 2008-07-17 21:10 ---
Created an attachment (id=15926)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15926&action=view)
Proposed patch
Attached patch copies missing SImode patterns as DImode equivalent.
Does this patch fix build failure
--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-17 21:09 ---
Indeed, the problem is the same, see PR 36795
*** This bug has been marked as a duplicate of 36795 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-17 21:09 ---
*** Bug 36803 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-17 20:24 ---
So here is how to get an ICE out of the trunk.
--- t.h
class A
{
public:
template static T foo1(T [3][3]);
};
template T A::foo1(T t[3][3])
{
return t[0][1];
}
--- t.cc ---
#include "t.h"
#in
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-07-17 20:19
---
No, it's still not analyzed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
--- Comment #9 from lothar at tradescape dot biz 2008-07-17 20:15 ---
in reply to #7:
Does this mean the status is no longer UNCONFIRMED?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE in extract_insn, at |[4.4 Regression] ICE in
|recog.c:1990
--- Comment #2 from ubizjak at gmail dot com 2008-07-17 19:54 ---
Mine.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #1 from pentek dot imre at gmail dot com 2008-07-17 19:16
---
Created an attachment (id=15925)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15925&action=view)
any.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36866
Hello, the attached code compiles without any warning when compiled with the
command
g++ -W -Wall any.cpp -c -o any.o
but x gets initialised from itself, actually dereferencing x prior to
initializing it. At this point it is trivial that x wasn't initialised.
Using built-in specs.
Target: x86_6
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-17 18:49 ---
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|code generation regression |[4.3 Regression] code
|with -O3
g++ -v -save-temps -DHAVE_CONFIG_H -I. -I./gl -I./GNU
-I/usr/local/include/libxm
l2 -Wall -W -Wcast-align -g -O2 -MT libdap_la-Structure.lo -MD -MP -MF
.deps/lib
dap_la-Structure.Tpo -c Structure.cc -DDLL_EXPORT -DPIC -o
.libs/libdap_la-Stru
cture.o
Reading specs from /usr/local/lib/gcc/i686-pc-
--- Comment #8 from lothar at tradescape dot biz 2008-07-17 18:09 ---
If you have questions about the internal implementation of the boost avl tree
you can contact Ion GaztaƱaga igaztanaga at gmail dot com. He is aware of this
problem already.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-07-17 18:01 ---
pointer_plus_2_bits will confuse points-to alias analysis galore. Of course
this doesn't explain the difference to -O0.
Still, -O1 is fast, -O1 -fstrict-aliasing is _very_ slow.
--
rguenth at gcc dot gnu dot or
--- Comment #6 from lothar at tradescape dot biz 2008-07-17 17:52 ---
in reply to #4:
-fno-tree-vectorize does not help
$ /opt2/linux/ix86/bin/g++-4.3.1 -m64 -O3 -fno-tree-vectorize -g -save-temps
-I/opt2/linux/x86_64/include/boost-1_35 -DUSE_OPTIMIZATION=0 -o ./avltest-no
./avltest.cpp
--- Comment #5 from lothar at tradescape dot biz 2008-07-17 17:50 ---
Created an attachment (id=15924)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15924&action=view)
the preprocessed file for case that is slower
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-07-17 17:47 ---
Does -O3 -fno-tree-vectorize cause the speed back to normal?
Not everyone has boost installed :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-17 17:42 ---
Please provide preprocessed source for the testcase which you get when
appending -save-temps to the compilation command. It will be called
avltest.ii.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #2 from lothar at tradescape dot biz 2008-07-17 16:54 ---
Created an attachment (id=15923)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15923&action=view)
updated testcase
changed the test case to resemble my application a bit closer. Here it is
almost 40 times slower
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-07-17 15:55 ---
Subject: Bug 36792
Author: rguenth
Date: Thu Jul 17 15:54:27 2008
New Revision: 137927
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137927
Log:
2008-07-16 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #1 from tomby at gcc dot gnu dot org 2008-07-17 15:38 ---
It seems that compilation breaks this patch:
http://gcc.gnu.org/viewcvs?view=rev&revision=137201
Wrong insn is generated during splitting
(parallel [
(set (reg:TI 0 ax [orig:65 D.5521 ] [65])
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36864
--- Comment #16 from burnus at gcc dot gnu dot org 2008-07-17 13:30 ---
The problem seems to be this code in scanner.c's gfc_new_file:
if (gfc_cpp_enabled ())
{
result = gfc_cpp_preprocess (gfc_source_file);
if (!gfc_cpp_preprocess_only ())
result = load_file (
--- Comment #2 from bitti at iki dot fi 2008-07-17 13:13 ---
I managed to duplicate the bug in a simpler environment. OpenSuse 11.0 32-bit
i686, gcc configured with
../gcc-4.3.1/configure --prefix=/home/bitti/gcc-4.3.1
--enable-languages=c,c++,java,ada,fortran
I attached the resulting c
--- Comment #1 from bitti at iki dot fi 2008-07-17 13:11 ---
Created an attachment (id=15922)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15922&action=view)
config.log from the failing build
config.log created with
../gcc-4.3.1/configure --prefix=/home/bitti/gcc-4.3.1
--enable-l
--- Comment #121 from mbrudka at filbico dot pl 2008-07-17 12:51 ---
Thank you Vincent. I fact after commenting I realized that this is a plain
numerical error on the last digit of double in multiplication. I think that my
comment was rather irrelevant and I am the more ashamed the more
--- Comment #2 from djh at emss dot co dot za 2008-07-17 12:47 ---
I have successfully reproduced this problem:
Create a header file with the following structure, saving it as "a.h":
class A
{
public:
template static T foo1(T [3][3]);
};
template T A::foo1(T t[3][3])
{
--- Comment #120 from vincent at vinc17 dot org 2008-07-17 12:41 ---
(In reply to comment #119)
> REAL RESULT:
> 5.313991e+33
> 5.313991e+33
> 0.00e+00
> 0.00e+00
Only without optimizations. But since the ISO C standard allows expressions to
be evaluated in a higher precision, t
On i686-apple-darwin9 (XCode 3.0 or 3.1) bootstrap fails at revision 137901 up
to now (works at revision 137781) with:
...
if /bin/sh ./libtool --tag=CC --mode=compile /opt/gcc/i686-darwin/./gcc/xgcc
-B/opt/gcc/i686-darwin/./gcc/ -B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/i686-a
--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-17 11:45
---
() it's just work in progress: from the users point of view
almost nothing works yet (and the implementation status info in the libstdc++
docs reflects that)
--
paolo dot carlini at oracle dot com changed:
We can not successfully use std::tr1::regex functionality with GCC 4.3.0 on
i686-pc-cygwin. Even the simplest of match expressions can not be successfully
matched. Perhaps there is a user error on our side here (sorry if this is the
case). Perhaps there is an actual compiler issue here.
The follow
--- Comment #119 from mbrudka at filbico dot pl 2008-07-17 10:45 ---
Another example related with fp on x87?
EXPECTED RESULT:
0 (with EPS accuracy)
0 (with EPS accuracy)
0 (with EPS accuracy)
0 (with EPS accuracy)
REAL RESULT:
5.313991e+33
5.313991e+33
0.00e+00
0.00e+00
CODE
#
--- Comment #3 from brian at dessent dot net 2008-07-17 10:21 ---
Subject: Re: New: Optimization O2 causes infinite loop
Yes, this code is broken as indeed overflow of signed integers is
undefined, so transforming this to an infinite loop is legitimate. Here
are some links to read:
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-17 10:06
---
(In reply to comment #0)
>int bit;
>for( bit = 1; bit; bit *= 2 )
This is pretty straightforward, isn't it? At some point bit - a *signed*
integral type - overflows and this leads to undefined bahavior
--- Comment #11 from doko at gcc dot gnu dot org 2008-07-17 10:05 ---
Subject: Bug 25343
Author: doko
Date: Thu Jul 17 10:04:51 2008
New Revision: 137918
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137918
Log:
2008-07-17 Roman Zippel <[EMAIL PROTECTED]>
PR target/25
--- Comment #1 from ben at zeus dot com 2008-07-17 09:53 ---
Sorry, forgot to include any compiler details:
[hera ben]$ /usr/local/gcc-4.3/bin/gcc -O2 -v -save-temps loop.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.1/configure --prefi
Sorry, not sure if this is a real bug or whether the code is broken and relying
on undefined behaviour when an integer overflows. The test case is very simple:
#include
int main( int argc, char *argv[] )
{
int bit;
for( bit = 1; bit; bit *= 2 ) {
printf( "%d\n", bit );
}
return
--- Comment #4 from burnus at gcc dot gnu dot org 2008-07-17 09:46 ---
FIXED on the trunk (4.4) and for 4.3 (i.e. for 4.3.2).
Thanks for the bugreport.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-17 09:45 ---
Subject: Bug 36824
Author: burnus
Date: Thu Jul 17 09:44:33 2008
New Revision: 137917
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137917
Log:
2008-07-17 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #12 from bonzini at gnu dot org 2008-07-17 09:20 ---
Subject: Bug 36753
Author: bonzini
Date: Thu Jul 17 09:19:31 2008
New Revision: 137915
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137915
Log:
gcc:
2008-07-17 Paolo Bonzini <[EMAIL PROTECTED]>
PR rtl-
--- Comment #11 from bonzini at gnu dot org 2008-07-17 09:19 ---
committed to trunk and 4.3.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASS
--- Comment #3 from paolo dot carlini at oracle dot com 2008-07-17 09:13
---
Fixed for mainline.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo at gcc dot gnu dot org 2008-07-17 09:11 ---
Subject: Bug 36855
Author: paolo
Date: Thu Jul 17 09:11:11 2008
New Revision: 137914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137914
Log:
/cp
2008-07-17 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #10 from bonzini at gnu dot org 2008-07-17 09:08 ---
Subject: Bug 36753
Author: bonzini
Date: Thu Jul 17 09:07:31 2008
New Revision: 137913
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137913
Log:
gcc:
2008-07-17 Paolo Bonzini <[EMAIL PROTECTED]>
PR rtl-
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-07-17
08:16 ---
Patch submitted
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01250.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
--- Comment #1 from lothar at tradescape dot biz 2008-07-17 07:28 ---
Created an attachment (id=15921)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15921&action=view)
test case to reproduce the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
gcc 4.3.1 generates code with -O3 that is more than 10 times slower than with
-O0. gcc 4.2.3 does not show this behavior. I am going to attach the test case
that I used to produce these numbers:
with gcc 4.2.3:
( time ./avltest-nn >/dev/null; time ./avltest-no >/dev/null; time ./avltest-on
>/dev/n
56 matches
Mail list logo