--- Comment #6 from uros at gcc dot gnu dot org 2007-03-15 07:25 ---
Subject: Bug 31167
Author: uros
Date: Thu Mar 15 07:25:22 2007
New Revision: 122945
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122945
Log:
PR target/31167
* config/i386/i386.md (*addti3_1, *
--- Comment #10 from burnus at gcc dot gnu dot org 2007-03-15 06:55 ---
Fixed.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from pault at gcc dot gnu dot org 2007-03-15 06:44 ---
Subject: Bug 30922
Author: pault
Date: Thu Mar 15 06:44:25 2007
New Revision: 122944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122944
Log:
2007-03-15 Tobias Burnus <[EMAIL PROTECTED]>
Paul T
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-15 06:44 ---
Subject: Bug 30879
Author: pault
Date: Thu Mar 15 06:44:25 2007
New Revision: 122944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122944
Log:
2007-03-15 Tobias Burnus <[EMAIL PROTECTED]>
Paul T
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-15 06:44 ---
Subject: Bug 30870
Author: pault
Date: Thu Mar 15 06:44:25 2007
New Revision: 122944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122944
Log:
2007-03-15 Tobias Burnus <[EMAIL PROTECTED]>
Paul T
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-15 06:44 ---
Subject: Bug 31163
Author: pault
Date: Thu Mar 15 06:44:25 2007
New Revision: 122944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122944
Log:
2007-03-15 Tobias Burnus <[EMAIL PROTECTED]>
Paul T
--- Comment #2 from bland at mail dot ru 2007-03-15 06:00 ---
I did not say that is bad. That is wrong and produces annoying warning.
Which can easily turn into error when reused in -Werror clean code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31180
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-15 05:46 ---
Actually this is not that bad.
#if __cplusplus will work as if it is not defined, the #if turns into "#if 0".
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-15 05:37 ---
I don't think this is a bug, 1407 and 14.7 are not exactly representable in
floating point.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from fang at csl dot cornell dot edu 2007-03-15 04:35
---
Subject: Re: preprocessor doubles up digits in token
pasting
With your example, "g++ -E -"
gives me:
:2:1: error: pasting "foo2" and "2.2" does not give a valid
preprocessing token
foo22.2
with versions 4.0.1
Very simple test case:
% cat /tmp/ff.s
#define Concat(a,b) a##b
Concat(foo,2.2)
% cpp -P /tmp/ff.s
foo22.2
Notice that what should be "2.2" becomes "22.2". Also note that this occurs
while preprocessing assembler (-x assembler-with-cpp) code.
--
Summary: preprocessor doubles up
--- Comment #1 from ahs3 at fc dot hp dot com 2007-03-15 03:11 ---
Created an attachment (id=13207)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13207&action=view)
code snippet showing the problem
This file originally came from libcrypt/des.c from the uClibc project. I cut
out e
While compiling uClibc, I saw a warning and narrowed it down. When I use this
invocation of gcc 4.1.2 (on Debian sid):
$ gcc -c short_des.c -Wall -Os -fno-tree-dominator-opts
I get the following warning:
short_des.c: In function '__des_crypt':
short_des.c:7: warning: 'f' may be used uninitializ
There is a minor problem in file:
http://gcc.gnu.org/viewcvs/trunk/gcc/unwind-pe.h?revision=101317&view=markup
/* If using C++, references to abort have to be qualified with std::. */
-#if __cplusplus
+#ifdef __cplusplus
#define __gxx_abort std::abort
--
Summary: Bad cpp condition i
--- Comment #13 from craig dot lawson at centrify dot com 2007-03-15 02:02
---
(reply to comment #11)
Shear luck: Fair enough. I don't claim to understand it all, either, especially
how it came to be this way.
What appears to be happening on Solaris 10 is that followed
by "/usr/inclu
This following small program will show the problem
# report.cpp
#include
#include
int main(int argc, char* argv[])
{
double A=140.70;
double x=floor((A*100));
std::cout << "Testing: A = " << A << " --> A*100 = " << A*100 << " but
floor(A*100) = " << x << "\n";
double B=140.60;
double y=
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-15 01:31 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-15 01:31 ---
Subject: Bug 31165
Author: pinskia
Date: Thu Mar 15 01:31:40 2007
New Revision: 122943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122943
Log:
2007-03-14 Andrew Pinski <[EMAIL PROTECTED]>
PR c+
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-03-15 01:30
---
Subject: Bug 31051
Author: jvdelisle
Date: Thu Mar 15 01:30:05 2007
New Revision: 122942
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122942
Log:
2007-03-14 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-15 01:27 ---
Subject: Bug 31165
Author: pinskia
Date: Thu Mar 15 01:27:29 2007
New Revision: 122941
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122941
Log:
2007-03-14 Andrew Pinski <[EMAIL PROTECTED]>
PR c+
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-03-15 01:25
---
Subject: Bug 31051
Author: jvdelisle
Date: Thu Mar 15 01:25:27 2007
New Revision: 122940
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122940
Log:
2007-03-14 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #12 from pcarlini at suse dot de 2007-03-15 01:24 ---
(In reply to comment #11)
> Honestly, I don't think that makes sense. Did you *really* test it? Because,
> as
> far as I can see, the cc file at issue includes the whole , which, in
> turn, includes , which is a link to
--- Comment #11 from pcarlini at suse dot de 2007-03-15 01:11 ---
(In reply to comment #10)
> The problem is that the library is not be ing properly compiled for
> multi-threaded use, but that by some luck basic_file.cc happened to be
> compiled
> that way anyway. c++locale.cc was not s
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org
--- Comment #3 from sje at cup dot hp dot com 2007-03-15 00:19 ---
My attempt to add an attachment failed (mail to dberlin has been sent) so here
is a cut down code segment from genautomata.c that generates different assembly
language when compiled with the PA stage1 compiler than it doe
--- Comment #11 from mueller at gcc dot gnu dot org 2007-03-14 23:20
---
Fixed for 4.3.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #10 from mueller at gcc dot gnu dot org 2007-03-14 23:17
---
Subject: Bug 30860
Author: mueller
Date: Wed Mar 14 23:17:03 2007
New Revision: 122934
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122934
Log:
2007-03-15 Dirk Mueller <[EMAIL PROTECTED]>
PR c
--- Comment #13 from hubicka at gcc dot gnu dot org 2007-03-14 23:03
---
Note that Michael Matz commited a patch to solve the problem independently.
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00950.html
I hope it will get into mainline in few days.
Honza
--
http://gcc.gnu.org/bu
--- Comment #2 from daney at gcc dot gnu dot org 2007-03-14 22:34 ---
http://gcc.gnu.org/ml/gcc/2007-03/msg00521.html may be the same problem. I
will try to test on both sides of 122821 to try to confirm.
--
daney at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from manu at gcc dot gnu dot org 2007-03-14 22:17 ---
(In reply to comment #6)
> Subject: Re: warning for comparison of different enum types impossible to
> control/is undocumented
>
> "manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
>
> | I could also add it t
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
namely [0, n) where n is the width of type a. (Or better type a's mode to be
safe). Look at infer_value_range().
--
Summary: VRP can infer a range for b in a >> b and a << b
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-
--- Comment #2 from michael dot meissner at amd dot com 2007-03-14 20:59
---
Patch committed:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00951.html
--
michael dot meissner at amd dot com changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-14 20:53 ---
--- ChangeLog (revision 122820)
+++ ChangeLog (revision 122821)
@@ -1,3 +1,12 @@
+2007-03-11 Richard Guenther <[EMAIL PROTECTED]>
+
+ PR tree-optimization/31115
+ * tree-vrp.c (extract_range_from_bi
--- Comment #6 from bangerth at dealii dot org 2007-03-14 20:49 ---
(In reply to comment #5)
> I know our code is wrong, but my point is that gcc34 generated correct code
> and gcc4x is not.
No, it happened to produce code that happened to do what you thought it would.
There is no way t
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|
--- Comment #5 from craig dot lawson at centrify dot com 2007-03-14 20:01
---
(oops. hit "verified" by mistake.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31177
--- Comment #4 from craig dot lawson at centrify dot com 2007-03-14 20:01
---
Yeah... I missed that one.
I have bash installed. If bash works, why can't the configure script find it
automatically?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31177
--- Comment #3 from craig dot lawson at centrify dot com 2007-03-14 20:00
---
Yeah... I missed that one.
I have bash installed. If bash works, why can't the configure script find it
automatically?
--
craig dot lawson at centrify dot com changed:
What|Removed
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-03-14 19:40 ---
Waiting for 4.2 to thaw before a backport.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-03-14 19:26 ---
Subject: Bug 30690
Author: tkoenig
Date: Wed Mar 14 19:26:38 2007
New Revision: 122927
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122927
Log:
2007-03-14 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-14 19:08 ---
(In reply to comment #4)
> Out of curiosity, which compiler does it?
Sun and Intel (and I think IBM's also)
> And what's the art hack?
The art hack is when changing array of structs to struct of arrays. The reaso
--- Comment #4 from sebor at roguewave dot com 2007-03-14 19:05 ---
(In reply to comment #2)
> Note actually some compilers actually do this even without an attribute. This
> is related to the art hack.
Out of curiosity, which compiler does it? And what's the art hack?
--
http://g
--- Comment #2 from pluto at agmk dot net 2007-03-14 19:05 ---
(In reply to comment #1)
> ifcvt could do this. But is cmpxchgq really faster with its atomictiy
> guarantee?
only `lock; cmpxchg' has atomicity guarantee on smp.
> They are all vector-path instructions, a compare - cmov s
--- Comment #3 from sebor at roguewave dot com 2007-03-14 19:04 ---
(In reply to comment #1)
> Interesting. Do the attributes apply to derived classes automatically?
I would say no.
>
[...]
> Is D also allowed to reorder members a and b? even with an explicit
> __attribute__((reord
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-14 19:01 ---
I think this was introduced by me, by making vector based CONSTRUCTOR with
CONSTANT set invariant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30784
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|debug |middle-end
E
--- Comment #5 from ubizjak at gmail dot com 2007-03-14 18:47 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00947.html.
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from patchapp at dberlin dot org 2007-03-14 18:46 ---
Subject: Bug number PR middle-end/19774
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/2007-03/msg00946.html
--
http://gcc.gnu.org
--- Comment #6 from manu at gcc dot gnu dot org 2007-03-14 18:39 ---
This is still not fixed. It needs to be re-examined what the proper fix (if
any) should be.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21438
--- Comment #5 from manu at gcc dot gnu dot org 2007-03-14 18:37 ---
Subject: Bug 21438
Author: manu
Date: Wed Mar 14 18:37:37 2007
New Revision: 122925
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122925
Log:
2007-03-14 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR c/
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-14 18:36 ---
http://gcc.gnu.org/install/specific.html#x-x-solaris2
Yes you can tell you did not set CONFIG_SHELL as you have /bin/sh in the error
message.
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-14 18:18 ---
Did you forget to set CONFIG_SHELL as mentioned by the instation documentation?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
make install fails with:
echo 'SYSTEM_HEADER_DIR="'"`echo /usr/include | sed -e :a -e
"s,[^/]*/\.\.\/,," -e ta`"'"' \
>
/test/gcc412/test/gcc-4.1.2/usr/local/lib/gcc/sparc-sun-solaris2.10/4.1.2/install-tools/mkheaders.conf
/bin/sh: : cannot execute
/bin/sh: /]*/../,, -e ta: not found
sed
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-14 18:16 ---
Note actually some compilers actually do this even without an attribute. This
is related to the art hack.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
--- Comment #9 from patchapp at dberlin dot org 2007-03-14 18:15 ---
Subject: Bug number PR 23572
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/2007-03/msg00943.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #1 from fang at csl dot cornell dot edu 2007-03-14 18:14
---
Interesting. Do the attributes apply to derived classes automatically?
struct B __attribute__((reorder)) {
char a;
int b;
};
struct D : public B {
char c, d, e;
};
Is D also allowed to reorder members a and b
--- Comment #10 from craig dot lawson at centrify dot com 2007-03-14 18:13
---
Found it.
The problem is that the library is not be ing properly compiled for
multi-threaded use, but that by some luck basic_file.cc happened to be compiled
that way anyway. c++locale.cc was not so lucky.
--- Comment #2 from ubizjak at gmail dot com 2007-03-14 17:38 ---
(In reply to comment #0)
> Examine the definition of isinf closely. It returns -1 for -inf.
But:
NOTE
Note that these functions are obsolete. C99 defines macros isfinite(),
isinf() and isnan() (for all t
While discussing how today's C++ compilers lay out data members of structs and
classes on the C++ committee's mailing list the observation was made that no
known implementation, including gcc, takes advantage of the permission to
rearrange members declared with their own access specifier (see
c++st
--- Comment #1 from schwab at suse dot de 2007-03-14 17:19 ---
The standard has no such requirement. It only talks about non-zero value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31175
#include
double x = -__builtin_inf ();
int main()
{
if (isinf (x) != -1)
abort ();
return 0;
}
Examine the definition of isinf closely. It returns -1 for -inf.
--
Summary: isinf incorrectly expanded
Product: gcc
Version: 4.3.0
Status: UNCO
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-14 16:35 ---
../.././gcc/gthr-posix.h:43:21: error: pthread.h: No such file
or directory
../.././gcc/gthr-posix.h:44:20: error: unistd.h: No such file
or directory
That just means you don't hav
--- Comment #3 from jv244 at cam dot ac dot uk 2007-03-14 16:30 ---
(In reply to comment #2)
this issue now seems fixed on trunk for me as well, so I guess this could be
closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30835
--- Comment #82 from jv244 at cam dot ac dot uk 2007-03-14 16:29 ---
>
> Huh, I somehow misread opteron for athlon. Your code is OK for x86_64, but it
> looks to me that you will have to upgrade binutils.
>
upgrading binutils is not much of an option for me, but with -march=x86-64 I
g
Ada compiler under gcc-4.2-20070307 fails ACATS c380004. Below is the content
of the test log
,.,. C380004 ACATS 2.5 07-03-12 14:21:49
C380004 Check evaluation of discriminant expressions when the
constraint depends on a discriminant, and the
discriminants have
--- Comment #1 from bhasker at unixindia dot com 2007-03-14 16:05 ---
Created an attachment (id=13206)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13206&action=view)
compilation log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31173
Hi,
I am cross compiling gcc-4.1.2 for arm
I am currently using gcc-4.1.2 for crosscompiling gcc-4.1.2 source tree
GNU binutils compiled on version 2.17 crosscompiled for ARM
I have attached the text of the error.
--
Summary: Error when cross-compiling gcc-4.1.2 for ARM
--- Comment #81 from ubizjak at gmail dot com 2007-03-14 15:30 ---
(In reply to comment #79)
> movsd %xmm2, (%rsp)
> fldl(%rsp)
> movsd %xmm1, (%rsp)
> fldl(%rsp)
> fxch%st(1)
> .L120:
> fprem
> fnstsw %ax
>
--- Comment #12 from uweigand at gcc dot gnu dot org 2007-03-14 15:26
---
This does fix my testcase on mainline. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
gfortran -c -O3 -ftree-loop-linear -ftree-vectorize -ffast-math -march=opteron
> -msse2 fparser.f90
> /tmp/ccNk6D7G.s: Assembler messages:
> /tmp/ccNk6D7G.s:820: Error: suffix or operands invalid for `sahf'
Does not seem to happen (20070314 on x86-64 Linux) with current CVS version of
CP2k.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #79 from jv244 at cam dot ac dot uk 2007-03-14 15:14 ---
(In reply to comment #78)
>
> Could you post the temporary asm (only lines around line 820 will be enough)
> to
> check what is going wrong?
>
.L157:
movslq %r13d,%rax
imulq %rsi, %rax
ad
--- Comment #14 from dberlin at gcc dot gnu dot org 2007-03-14 15:12
---
(In reply to comment #13)
> It's really all PTA memory.
>
> Mainline:
>
> tree PTA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
>
> 40 kB ( 0%) ggc
> TOTAL : 2.18
--- Comment #78 from ubizjak at gmail dot com 2007-03-14 15:01 ---
(In reply to comment #77)
> gfortran -c -O3 -ftree-loop-linear -ftree-vectorize -ffast-math -march=opteron
> -msse2 fparser.f90
>
> /tmp/ccNk6D7G.s: Assembler messages:
> /tmp/ccNk6D7G.s:820: Error: suffix or operands i
--- Comment #77 from jv244 at cam dot ac dot uk 2007-03-14 14:48 ---
Currently
GNU Fortran (GCC) 4.3.0 20070313 (experimental)
there seems to be a new gcc error on CP2K:
gfortran -c -O3 -ftree-loop-linear -ftree-vectorize -ffast-math -march=opteron
-msse2 fparser.f90
/tmp/ccNk6D7G.s
--- Comment #6 from dominiq at lps dot ens dot fr 2007-03-14 14:27 ---
Subject: Re: ICE with integer_exponentiation_1.f90 and -ffast-math
> On i686-linux, the unpatched compiler works OK without -ffast-math and
> segfaults with it.
I am a little bit worried about that. As far as I kno
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-03-14 14:21
---
It's really all PTA memory.
Mainline:
tree PTA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
40 kB ( 0%) ggc
TOTAL : 2.18 1.05 3.44
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-14 14:15
---
*** Bug 31172 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-14 14:15 ---
same source, same problem.
*** This bug has been marked as a duplicate of 30052 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-14 14:02
---
(In reply to comment #4)
> I'll do it tonight, but before could you test the following code
> [karma] f90/bug% gfc test_pow.f90
> Out of stack space.
> Try running 'limit stacksize unlimited' in the shell to raise
--- Comment #4 from dominiq at lps dot ens dot fr 2007-03-14 13:58 ---
Subject: Re: ICE with integer_exponentiation_1.f90 and -ffast-math
> And Dominique, I would appreciate if you could test the patch on ppc-darwin7.
I'll do it tonight, but before could you test the following code:
--- Comment #4 from ubizjak at gmail dot com 2007-03-14 13:43 ---
Created an attachment (id=13205)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13205&action=view)
Patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31167
--- Comment #3 from ubizjak at gmail dot com 2007-03-14 13:42 ---
Prototype patch that fixes the failure:
2007-03-14 Uros Bizjak <[EMAIL PROTECTED]>
* config/i386/i386.md (*addti3_1, *addti3_1 splitter): Use
x86_64_general_operand as operand[2] predicate.
(*su
--- Comment #2 from ubizjak at gmail dot com 2007-03-14 13:13 ---
The problem is with TImode *addti3_1 splitter. An immediate is splitted from
TImode into double DImode values and these values are passed to add/addc pair:
(define_split
[(set (match_operand:TI 0 "nonimmediate_operand"
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-14 12:31
---
Here's a patch that should make the code in gfc_conv_cst_int_power() work in
all cases:
Index: trans-expr.c
===
--- trans-expr.c(revision 12
--- Comment #8 from roberto dot gordo at gmail dot com 2007-03-14 12:29
---
I'm still unable to match the behavior of gcc with the ISO C standard. I will
try to explain myself.
The reason for which gcc produces different results with hex constants is now
clear. Also, in the following q
--- Comment #5 from dorit at il dot ibm dot com 2007-03-14 12:29 ---
this is the testcase I have ICE-ing on powerpc64-yellowdog, when compiled with
-ftree-vectorize -maltivec -m64 -O2:
long stack_vars_sorted[32];
void partition_stack_vars (long stack_vars_num)
{
long si, n = stack_var
--- Comment #4 from dorit at il dot ibm dot com 2007-03-14 12:13 ---
I also saw this on powerpc64, on a different testcase (vectorizing longs with
-m64). seems like constant propagation during dom3 propagates the vector
initializer into a BIT_FIELD_EXPR, which results in invalid gimple?
--- Comment #2 from bero at arklinux dot org 2007-03-14 11:21 ---
The difference between this and 30052 is that 30052 claims x86 is ok and the
problem occurs only on x86_64 -- it happens here with x86 (non-64).
Uploading preprocessed source currently gives a "bugzilla internal error".
--- Comment #1 from pluto at agmk dot net 2007-03-14 11:18 ---
this is a dup of PR30052
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31172
Compiling xf86ScanPci.c from xorg-server 1.2.99.901 with gcc 4.2 branch (SVN
118519) takes much longer than with older versions of gcc, and takes loads of
memory (approx. 3 GB).
Works as expected with older gccs and with 4.2 and -O0.
--
Summary: [4.2 Regression] Compiling xf86ScanPci
--
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
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-14 11:00 ---
ifcvt could do this. But is cmpxchgq really faster with its atomictiy
guarantee?
They are all vector-path instructions, a compare - cmov sequence looks
faster (8 cycle latency vs. 10 and also with less constraints o
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-14 10:55
---
(In reply to comment #2)
> ./cc1 -quiet -O -march=athlon-xp -m32 -ftree-vectorize x.i
> x.i: In function 'foo':
> x.i:2: error: invalid reference prefix
> {4, 4, 4, 4}
>
> x.i:2: error: invalid reference
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-14 10:49
---
Fixed on 4.2 and 4.3.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
long emit_cmpxchg( long volatile* p, long from, long to )
{
long v = *p;
if ( v == from )
*p = to;
return v;
}
gcc should be able to optimize this.
--
Summary: cmpxchgq not emitted.
Product: gcc
Version: 4.2.0
--- Comment #7 from roberto dot gordo at gmail dot com 2007-03-14 09:40
---
That's OK, it is not a bug, sorry.
--
roberto dot gordo at gmail dot com changed:
What|Removed |Added
-
--- Comment #6 from roberto dot gordo at gmail dot com 2007-03-14 09:27
---
I think I've found something. According to the ISO C standard, a decimal
constant without suffixes should ALWAYS be signed int (or signed long long if
it does not fit), but never be unsigned! An octal or hexadec
1 - 100 of 102 matches
Mail list logo
