--- Comment #8 from domob at gcc dot gnu dot org 2008-09-11 07:29 ---
Subject: Bug 36214
Author: domob
Date: Thu Sep 11 07:28:18 2008
New Revision: 140264
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140264
Log:
2008-09-11 Daniel Kraft <[EMAIL PROTECTED]>
PR fortran
--- Comment #6 from jakub at gcc dot gnu dot org 2008-09-11 07:34 ---
Subject: Bug 37382
Author: jakub
Date: Thu Sep 11 07:33:23 2008
New Revision: 140265
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140265
Log:
PR target/37382
* expmed.c (extract_low_bits): Av
--- Comment #7 from jakub at gcc dot gnu dot org 2008-09-11 07:40 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
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 #5 from rhorstmann at securecomputing dot com 2008-09-11 07:49
---
I think this is the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
So should be fixed in 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36391
--- Comment #9 from dodji at gcc dot gnu dot org 2008-09-11 07:56 ---
@Jakub:
* I think (x ? c.i : c.j) = y; should be valid. because we then fall into the
item 4 of the spec, PDF page 115, section 5.16: Conditional operator which
reads:
"If the second and third operands are lvalues an
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-11 08:19 ---
vect_analyze_slp_instance/vect_supported_load_permutation_p/vect_supported_slp_permutation_p
are buggy.
0x00a51e93 in vect_supported_slp_permutation_p
(instance=0x7fffe4bfafd8) at ../../gcc/tree-vect-analyze.c:
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37474
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-11 08:22 ---
It has absolutely nothing to do with mpfr (neither did the other memory
corruption), no idea where you got it from.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
The following member functions of the class codecvt
result in(stateT& state, const externT* from, const externT* from_end, const
externT*& from_next, internT* to, internT* to_limit, internT*& to_next) const
and
result out(stateT& state, const internT* from, const internT* from_end, const
internT
--- Comment #1 from tsyvarev at ispras dot ru 2008-09-11 09:35 ---
Created an attachment (id=16291)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16291&action=view)
test.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #4 from irar at il dot ibm dot com 2008-09-11 09:58 ---
Testing:
Index: tree-vect-analyze.c
===
--- tree-vect-analyze.c (revision 140274)
+++ tree-vect-analyze.c (working copy)
@@ -3200,6 +3200,10 @@ vect_suppor
The description of uncaught_exception() throw() function states (18.6.4):
Returns: true after completing evaluation of a throw-expression until either
completing initialization of the exception-declaration in the matching handler
or entering unexpected() due to the throw; or after entering termina
--- Comment #1 from tsyvarev at ispras dot ru 2008-09-11 10:18 ---
Created an attachment (id=16292)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16292&action=view)
test.tar
Reproduce situations when terminate is called implicitly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #2 from paolo dot carlini at oracle dot com 2008-09-11 10:29
---
Note this is a libsupc++ issue, we don't have a specific Bugzilla component,
but as a matter of fact the code has been mostly implemented and maintained by
different people than the libstdc++ maintainers... I'm
--- Comment #2 from paolo dot carlini at oracle dot com 2008-09-11 10:31
---
http://gcc.gnu.org/ml/libstdc++/2008-09/msg00090.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
Compiling:
typedef struct t {
char *d;
union {
int aa;
float ab;
} a;
} T;
int f() {
T s = {"one", 1};
return s.a.aa;
}
with -Wall --std=c99 yields:
structinit.c: In function 'f':
structinit.c:10: warning: missing braces around initializer
structinit.c:10: wa
Compiling anything I get:
undefined reference to `std::ctype const&
std::use_facet >(std::locale const&)@GLIBCXX_3.4'
--
Summary: undefined reference to `ctype const&
use_facet>(locale const&)'
Product: gcc
Version: 4.4.0
Status:
--- Comment #1 from paolo dot carlini at oracle dot com 2008-09-11 11:12
---
Hey Chris, it's something on your side, because as you can see on testresults
nobody has any problem (myself included ;)
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2008-09-11
11:23 ---
Subject: Re: [4.4 regression] dwarf2 unwind info patches produce undefined
symbols
jakub at gcc dot gnu dot org writes:
> references undefined label. I'm afraid at least until some support is added
> to
It's possible to create null references which contradicts the standard:
Assume simple structs:
template
struct null_val {
null_val(T t = T()) : value(t) {}
T value;
};
template
struct null_ref : null_val {};
Now it's possible to use 'null_ref().value' which is null reference!
--
--- Comment #3 from dominiq at lps dot ens dot fr 2008-09-11 11:37 ---
I cannot reproduce it on ppc/intel Darwin9, however the following code:
PROGRAM bug
IMPLICIT NONE
DOUBLE PRECISION r
COMMON /91/ r
DOUBLE PRECISION x
x = 1000
write(6
I just noticed that the new -fdwarf2-cfi-asm option isn't documented in
gcc/doc/invoke.texi.
Filing as component other since there seems to be noc doc component.
--
Summary: -fdwarf2-cfi-asm is undocumented
Product: gcc
Version: 4.4.0
Status: UNCONFI
--- Comment #5 from jamborm at gcc dot gnu dot org 2008-09-11 11:42 ---
I guess this is mine.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #1 from rarut at mail dot ru 2008-09-11 11:45 ---
Generally reference members when used like this seem to behaive like pointers:
- have default constructor (making null reference)
- store garbage when when left uninitialized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #2 from dominiq at lps dot ens dot fr 2008-09-11 11:45 ---
I see the same errors (a lot of them) on Darwin (see also
http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00938.html).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37460
--- Comment #2 from paolo dot carlini at oracle dot com 2008-09-11 12:01
---
This is already fixed in mainline and 4_3-branch. I bet this PR is a
duplicate...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37480
--- Comment #5 from irar at gcc dot gnu dot org 2008-09-11 12:09 ---
Subject: Bug 37474
Author: irar
Date: Thu Sep 11 12:08:01 2008
New Revision: 140276
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140276
Log:
PR tree-optimization/37474
* tree-vect-analyze.c (v
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-09-11 12:36
---
Subject: Bug 37448
Author: hubicka
Date: Thu Sep 11 12:34:53 2008
New Revision: 140281
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140281
Log:
PR middle-end/37448
* tree-inline.c (add_le
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-09-11 12:40
---
Subject: Bug 37448
Author: hubicka
Date: Thu Sep 11 12:38:57 2008
New Revision: 140284
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140284
Log:
PR middle-end/37448
* cgraph.c (cgraph_cre
--- Comment #17 from pault at gcc dot gnu dot org 2008-09-11 13:11 ---
I agree with Dominique's last comment and have closed this PR accordingly.
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from jakub at gcc dot gnu dot org 2008-09-11 13:24 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #15 from bonzini at gnu dot org 2008-09-11 13:46 ---
Uros, does your comment #11 apply also to SSE registers (Yi), which could
alleviate for PR 37437, or only to MMX (Ym)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
--
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 #4 from burnus at gcc dot gnu dot org 2008-09-11 14:27 ---
Jerry, do you know why gfortran 4.3/4.4 prints one trailing zero more for 1000
than for other numbers? 4.2 used the same number of trailing digits.
1000.0
1001.
for
print *, 1000.0
print *, 1001.0
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-09-11 14:46 ---
This is a stylistic warning from -Wall that the code is potentially confusing,
not that the code is invalid. If you don't want such warnings, don't use
-Wall, or use -Wno-missing-braces.
--
jsm28 at gcc dot gnu do
--- Comment #3 from schwab at suse dot de 2008-09-11 15:19 ---
Caused by:
2007-07-23 Peter Bergner <[EMAIL PROTECTED]>
Jakub Jelinek <[EMAIL PROTECTED]>
PR middle-end/PR28690
Can be reproduced with gcc.c-torture/execute/20060420-1.c when compiled with
-O2.
--
--- Comment #4 from bonzini at gnu dot org 2008-09-11 15:29 ---
I think there is a missing constrain_operands somewhere, because in
(define_insn "*addsi3_internal"
[(set (match_operand:SI 0 "nonimmediate_operand" "=m,?a,?a,d,a")
(plus:SI (match_operand:SI 1 "general_operand" "
--- Comment #6 from tbm at cyrius dot com 2008-09-11 15:36 ---
Adding Adam Nemet since I see the segfault on a Cavium Octeon based
machine (from Movidis).
--
tbm at cyrius dot com changed:
What|Removed |Added
---
struct Foo { int i; char a[]; } foo = { 1, "" }; // No warning
struct Bar { int i; char a[]; } bar = { 1, {0} }; // Warning
Line 1 passes -pedantic, but C99 6.7.2.1p16 says it is invalid:
Flexible array members are ignored except with ',', '->',
and for aligning the size of the struct.
Related
--- Comment #4 from dominiq at lps dot ens dot fr 2008-09-11 16:33 ---
At r140286 with the patch in
http://gcc.gnu.org/ml/fortran/2008-09/msg00210.html, the failure is gone!-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
--- Comment #10 from dodji at gcc dot gnu dot org 2008-09-11 16:40 ---
Created an attachment (id=16293)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16293&action=view)
another patch that fixes the problem.
This patch proposes a fix for the problem and complies with my comment
htt
--- Comment #2 from spop at gcc dot gnu dot org 2008-09-11 16:47 ---
Jan proposed to switch to a different algorithm for detecting scops
based on the fact that scops are single entry, single exit regions.
Instead of detecting scops from the innermost to the outermost, we
should instead
With current trunk on powerpc (revision 140291)
(sid)2635:[EMAIL PROTECTED]: ..4.3-2008-09-11-r140291/gcc] ./cc1 -quiet -O3
-maltivec
~/mednafen-convert.i
sexyal/convert.c: In function 'SexiALI_Convert':
sexyal/convert.c:42: error: definition in block 51 follows the use
for SSA_NAME: vect_var_.1
With current trunk on powerpc (revision 140291):
(sid)2644:[EMAIL PROTECTED]: ..4.3-2008-09-11-r140291/gcc] ./cc1plus -quiet -O3
-maltivec ~/gdc-4.2-constfold.ii
../../src/gcc/d/dmd/constfold.c: In function 'Expression* Ushr(Type*,
Expression*, Expression*)':
../../src/gcc/d/dmd/constfold.c:635: i
--- Comment #1 from tbm at cyrius dot com 2008-09-11 16:55 ---
Created an attachment (id=16294)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16294&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37483
--- Comment #1 from tbm at cyrius dot com 2008-09-11 16:55 ---
Created an attachment (id=16295)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16295&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37482
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reco
--- Comment #3 from janis at gcc dot gnu dot org 2008-09-11 16:56 ---
Fixed in mainline. It's not a regression so the fix has not been applied to
4.3.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from tbm at cyrius dot com 2008-09-11 16:57 ---
(gdb) run -quiet -O3 -maltivec ~/gdc-4.2-constfold.ii
Starting program: /home/tbm/tmp/gcc/4.3-2008-09-11-r140291/gcc/cc1plus -quiet
-O3 -maltivec ~/gdc-4.2-constfold.ii
Program received signal SIGSEGV, Segmentation fault.
no
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||16989
nThis||
Sta
--- Comment #3 from tbm at cyrius dot com 2008-09-11 17:08 ---
Created an attachment (id=16296)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16296&action=view)
Preprocessed source
Here's another testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37483
--- Comment #1 from harsha dot jagasia at amd dot com 2008-09-11 17:15
---
Created an attachment (id=16297)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16297&action=view)
Fixes invalid reads/writes for cpu2006 403.gcc benchmark.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #16 from ubizjak at gmail dot com 2008-09-11 17:33 ---
(In reply to comment #15)
> Uros, does your comment #11 apply also to SSE registers (Yi), which could
> alleviate for PR 37437, or only to MMX (Ym)?
Comment #11 is also true for Yi SSE registers (for TARGET_INTER_UNIT_MO
Valgrind report
---
valgrind --leak-check=yes ./cc1 -DSPEC_CPU -DNDEBUG -I
~/WORK/benchmarks/cpu2006/benchspec/CPU2006/403.gcc/src -O2 -fgraphite
-floop-block -DSPEC_CPU_LP64
~/WORK/benchmarks/cpu2006/benchspec/CPU2006/403.gcc/src/c-common.c
==23086== Memcheck, a memory er
--- Comment #3 from janis at gcc dot gnu dot org 2008-09-11 17:35 ---
Fixed on mainline.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
Status|A
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last re
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #7 from ubizjak at gmail dot com 2008-09-11 17:57 ---
There is a runtime difference between -O1 and -O2:
g++ -O1 pr37096.cpp main.o
./a.out
nz: 3
g++ -O2 pr37096.cpp main.o
./a.out
nz: 3
98
Target: x86_64-unknown-linux-gnu
gcc version 4.4.0 20080911 (experimental) [trunk
--- Comment #8 from ubizjak at gmail dot com 2008-09-11 18:16 ---
Hm, with -O2 -fno-strict-aliasing, it works fine.
Is there an aliasing issue involved?
short Transform4x4(short *pMatrix)
{
__m128i r4, r5;
__m128i r0 = _mm_loadl_epi64((__m128i *)(pMatrix + 0 * 16));
--- Comment #8 from domob at gcc dot gnu dot org 2008-09-11 19:15 ---
Subject: Bug 37199
Author: domob
Date: Thu Sep 11 19:13:59 2008
New Revision: 140296
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140296
Log:
2008-09-08 Daniel Kraft <[EMAIL PROTECTED]>
PR fortran
--- Comment #9 from domob at gcc dot gnu dot org 2008-09-11 19:15 ---
Fixed on 4.3 branch.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-09-11 19:30 ---
(In reply to comment #2)
> Yes, FLUSH works, but
>
> * I don't think it was part of standards until 2003,
> * I need to place it several places in my code,
> * I really didn't want gfortran specific code if I coul
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-09-11 19:48 ---
Do we really want to do this any more?
I nobody objects, I'll close this as WONTFIX in a few days.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18584
--- Comment #2 from charles at schwieters dot org 2008-09-11 19:51 ---
thanks for pointing that out. -fdefault-integer-8 works fine.
However, the -i8 behavior *is* confusing:
% gfortran -c -i8 t.f
% gfortran -c -i8 t.F
cc1: error: unrecognized command line option "-i8"
i.e. it *seems*
In tranlate_clast when clast stmt is a stmt_user, we can end up disconnecting
the edge that is the exit_edge of the scop that is transformed. This state
creates problems because the exit_edge no longer has a destination. Hence when
after translate_clast, the exit_edge is redirected with redirect_ed
--- Comment #1 from harsha dot jagasia at amd dot com 2008-09-11 20:05
---
Created an attachment (id=16298)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16298&action=view)
Reduced test case for bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
--- Comment #19 from joel at gcc dot gnu dot org 2008-09-11 20:08 ---
Now merged on SVN trunk. Closing. Thanks Arnaud.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from joel at gcc dot gnu dot org 2008-09-11 20:12 ---
ping. Still not fixed as of 20080910 [trunk revision 140246]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21327
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-11 20:23 ---
Reducing ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37482
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-11 20:30 ---
Nice reduced testcase:
void SexiALI_Convert(void *vdest, void *vsrc, unsigned int frames)
{
unsigned int x;
short *src = vsrc;
unsigned char *dest = vdest;
for(x=0;xhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=374
--- Comment #7 from burnus at gcc dot gnu dot org 2008-09-11 20:49 ---
> Do we really want to do this any more?
> I nobody objects, I'll close this as WONTFIX in a few days.
I think some are still interested in F; however, as it is does not support the
new Fortran 2003/2008 features, I
Currently, gfortran automatically aligns data in COMMON blocks, as in the
following example:
implicit none
integer(kind=4) :: n
real(kind=8) :: p
common /foo/ n,p
end
This gives the warning:
COMMON 'foo' at (1) requires 4 bytes of padding at start
This automatic padding can result in unexpected
For return by value optimization, instead of calling the copy constructor or
the assignment operator, gcc decides to optimize and push the address of the
lhs of the expression into the rhs.
Foo createFoo() { Foo f2; return f2; }
int main(){
Foo f1 = createFoo();
return 0;
}
OPTIMIZED TO
void
--- Comment #1 from khoaduynguyen at gmail dot com 2008-09-11 21:00 ---
Created an attachment (id=16299)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16299&action=view)
Reproduction
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37487
--- Comment #7 from nemet at gcc dot gnu dot org 2008-09-11 21:00 ---
I was able to reproduce this with 140295. Assigning to myself.
--
nemet at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from khoaduynguyen at gmail dot com 2008-09-11 21:02 ---
-bash-3.1$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checki
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-11 21:02 ---
This is allowed by the standard. THe compiler can elide constructors as
defined by the C++ standard. If you want not this behavior use
-fno-elide-constructors.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-11 21:15 ---
Here is a simple reduced testcase for the first one:
typedef unsigned long long int uint64_t;
uint64_t Ushr( unsigned count,int i)
{
uint64_t value;
if (i==0)
value = (value & 0x) >> count;
return
--- Comment #8 from nemet at gcc dot gnu dot org 2008-09-11 21:46 ---
It's caused by this http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02376.html.
In this hunk:
@@ -1901,7 +1904,8 @@ noce_try_sign_mask (struct noce_if_info
INSN_B which can happen for e.g. conditional stores to
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-09-11 21:48 ---
I think this is the same bug as PR 37483.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37395
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-11 22:11 ---
And the other:
typedef struct {
short rbearing;
short width;
} XCharStruct;
typedef long I32;
typedef I32 Bool;
typedef unsigned long Handle;
typedef struct _Point {
int x;
int y;
} Point, *PPoint;
static P
In the provided testcase, gcc spills an xmm register onto the stack even though
there is only one register being used. This does not occur with similar code
using general purpose registers.
const void* test(int action, void* ptr)
{
static void * const addrs[] = {&&L1, &&L2};
if (action =
--- Comment #1 from jstrother9109 at gmail dot com 2008-09-11 23:15 ---
Created an attachment (id=16300)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16300&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37488
Consider the c++ code:
--
class StatVal {
public:
StatVal(double ev, double va)
: m(ev),
v(va) {}
StatVal(const StatVal& other)
: m(other.m),
v(other.v) {}
StatVal& operator*=(const StatVal& other) {
double A = m == 0 ? 1.0 : v / (m * m);
double B = other.m ==
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37490
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-11 23:47 ---
I forgot to mention, not choosing a FLOAT_REG causes a reload to happen which
did not happen before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37490
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-11 23:53 ---
This is a target bug really since it is SSE which needs to set
FLOAT_STORE_FLAG_VALUE correctly.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from hjl at gcc dot gnu dot org 2008-09-11 23:53 ---
Subject: Bug 37424
Author: hjl
Date: Thu Sep 11 23:52:12 2008
New Revision: 140303
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140303
Log:
2008-09-11 Eric Botcazou <[EMAIL PROTECTED]>
PR rtl-optimi
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-11 23:54 ---
The exact revision I was using is:
gcc version 4.4.0 20080910 (experimental) [trunk revision 140245] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37490
--- Comment #2 from hjl dot tools at gmail dot com 2008-09-12 00:45 ---
(In reply to comment #1)
> This is a target bug really since it is SSE which needs to set
> FLOAT_STORE_FLAG_VALUE correctly.
>
How can you define FLOAT_STORE_FLAG_VALUE only for float/double
when SSE math is used?
--- Comment #3 from raksit at gcc dot gnu dot org 2008-09-12 01:08 ---
(In reply to comment #1)
> This is a target bug really since it is SSE which needs to set
> FLOAT_STORE_FLAG_VALUE correctly.
>
In that case, I think simplify-rtx.c:simplify_relational_operation() is being
overly co
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-09-12 03:52
---
I will have to explore a bit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-09-12 05:26
---
Subject: Bug 37424
Author: ebotcazou
Date: Fri Sep 12 05:24:41 2008
New Revision: 140312
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140312
Log:
PR rtl-optimization/37424
* ira-color.c
--- Comment #6 from tbm at cyrius dot com 2008-09-12 05:28 ---
(In reply to comment #4)
> This works now with revision 140075.
Maybe the reduced one works now, but the original preprocessed source
still shows the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37392
--- Comment #14 from nightstrike at gmail dot com 2008-09-12 05:47 ---
I just wanted to confirm that Joesph's patch does indeed work (thank you!), and
ask that the status of this PR change from INVALID to FIXED.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37086
99 matches
Mail list logo
