--- Comment #35 from bonzini at gnu dot org 2009-02-04 07:57 ---
(and all bugs depending on this one are also fixed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
--- Comment #34 from bonzini at gnu dot org 2009-02-04 07:57 ---
> Reopen since revision 143757 isn't supposed to fix it.
Who cares if 143757 "isn't supposed to fix it", it *is* fixed:
movqx(%rip), %mm0
paddd y(%rip), %mm0
movd%mm0, %rax
ret
--- Comment #6 from bonzini at gnu dot org 2009-02-04 07:53 ---
andrew, ping the patch :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38699
--- Comment #29 from bonzini at gnu dot org 2009-02-04 07:46 ---
A similar problem was fixed with PR38533, is this still an issue?
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from bonzini at gnu dot org 2009-02-04 07:44 ---
Did the patch cure PR28481 too?
--
bonzini at gnu dot org changed:
What|Removed |Added
CC|
--- Comment #14 from bonzini at gnu dot org 2009-02-04 07:40 ---
We should make up our mind and close either this one or 23821... they are
requesting exactly opposite things.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
--- Comment #9 from bonzini at gnu dot org 2009-02-04 07:04 ---
sizeof (tree_block) is 52 bytes on 32-bit hosts. Of these, 8 are unused (ann
and type), 8 are frequently unused (block_fragment stuff -- always write-only
at debug level 0). Moving fragments into an annotation and reusing
--- Comment #6 from danglin at gcc dot gnu dot org 2009-02-04 04:24 ---
I tried the testcase with 4.4.0. The problem is not fixed. All the explicit
register variables are optimized away at -O.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32820
The problem happens when I try to optimize this procedure:
inline void*
bcAtomCompareExchange(void **destination,
void *exchange,
void *compare)
{
void* old = *destination;
if (old == compare)
--- Comment #1 from danglin at gcc dot gnu dot org 2009-02-04 03:47 ---
This has gone away.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Sta
Executing on host:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/
../libtool --silent --tag=GCJ --mode=link /test/gnu/gcc/objdir/gcc/gcj
-B/test/g
nu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/ -B/test/gnu/gcc/objdir/gcc/
--encod
ing=UTF-8 -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/l
--- Comment #4 from bkoz at gcc dot gnu dot org 2009-02-04 02:51 ---
This isn't a bug, but rather part of a deliberate linkage strategy.
For C++, types that are to be used across shared libraries have to be visible.
See:
http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Ge
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-04 02:32 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00137.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from Joey dot ye at intel dot com 2009-02-04 02:17 ---
GCC doesn't follow x86-64 psABI on this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-02-04 01:55
---
I agree, closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jsm28 at gcc dot gnu dot org 2009-02-04 01:01 ---
Fixed in 4.4 and it's safest not to apply the fix to release branches.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from jsm28 at gcc dot gnu dot org 2009-02-04 00:59 ---
Subject: Bug 29129
Author: jsm28
Date: Wed Feb 4 00:59:21 2009
New Revision: 143918
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143918
Log:
PR c/29129
* c-decl.c (grokdeclarator): Mark [*]
--- Comment #7 from dberlin at gcc dot gnu dot org 2009-02-04 00:29 ---
Subject: Re: PTA constraint processing for *x =
y is wrong
On Tue, Feb 3, 2009 at 9:24 AM, rguenther at suse dot de
wrote:
>
>
> --- Comment #6 from rguenther at suse dot de 2009-02-03 14:24 ---
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-04 00:09 ---
*** This bug has been marked as a duplicate of 36550 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-02-04 00:09 ---
*** Bug 39088 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from bkoz at gcc dot gnu dot org 2009-02-03 23:47 ---
Created an attachment (id=17240)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17240&action=view)
test std::complex, __complex init
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39056
--- Comment #5 from bkoz at gcc dot gnu dot org 2009-02-03 23:47 ---
> Benjamin, does you have an opinion about initializer-lists and complex? I
> guess the library complex class will accept { real, imag } naturally because
> it
> has a suitable constructor.
It would be great if this
--- Comment #82 from paolo dot carlini at oracle dot com 2009-02-03 23:46
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #81 from paolo at gcc dot gnu dot org 2009-02-03 23:45 ---
Subject: Bug 25191
Author: paolo
Date: Tue Feb 3 23:44:53 2009
New Revision: 143913
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143913
Log:
2009-02-03 Paolo Carlini
PR libstdc++/25191
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-02-03 22:39
---
Fixed on the trunk at least.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-02-03 22:38 ---
Subject: Bug 36607
Author: pinskia
Date: Tue Feb 3 22:38:16 2009
New Revision: 143909
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143909
Log:
2009-02-03 Andrew Pinski
PR C++/36607
* c
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-02-03 22:24 ---
*** This bug has been marked as a duplicate of 38522 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-03 22:24 ---
*** Bug 39089 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from oleg dot smolsky at riverbed dot com 2009-02-03 22:23
---
Created an attachment (id=17239)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17239&action=view)
The fix from gcc4.4
This is the naive fix merged from the trunk. Fixes two out of three warnings in
C++
--- Comment #5 from ramana dot r at gmail dot com 2009-02-03 22:06 ---
(In reply to comment #4)
> Looking at the dumps this rtx is generated by the rename registers pass in
> 4.3.x . In trunk however rename register does not generate this rtx and hence
> there is no problem. It could st
--- Comment #4 from ramana dot r at gmail dot com 2009-02-03 21:43 ---
(In reply to comment #2)
> No problem with the trunk, but it's still there in the 4.3 branch.
>
> Here's a test case. Requires -funroll-loops -Os, no problem with any other
> -O,
> or without -funroll-loops, curi
--- Comment #2 from daney at gcc dot gnu dot org 2009-02-03 21:32 ---
I guess you are right. I thought I had a failing testcase, but I can't make it
fail any more.
Marking as invalid.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from oleg dot smolsky at riverbed dot com 2009-02-03 21:13
---
I've just built gcc 4.4 and it emits no warnings for the test case above.
Is there any chance the fix could be back-ported into 4.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39089
--- Comment #2 from danglin at gcc dot gnu dot org 2009-02-03 20:53 ---
I also see this. Also seen with 4.3.3.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from jsm28 at gcc dot gnu dot org 2009-02-03 20:41 ---
Fixed for 4.4; will fix for 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-02-03 20:38 ---
Subject: Bug 35433
Author: jsm28
Date: Tue Feb 3 20:38:12 2009
New Revision: 143906
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143906
Log:
PR c/35433
* c-typeck.c (composite_type): Set TYP
--- Comment #10 from jsm28 at gcc dot gnu dot org 2009-02-03 20:33 ---
The conclusion on DR#341 was that this should indeed be accepted; I'll fix
this.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pault at gcc dot gnu dot org 2009-02-03 19:59 ---
I have just realised that this is a case of complete overlap that we miss
completely in dependency analysis:
If one of the lhs or rhs is a full array, the stride is unity and one of lbound
== start or ubound == end, t
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-03 19:46 ---
I think this is a duplicate of bug 38522 which is fixed for 4.4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39089
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-03 19:35 ---
sqrt is usually implemented as a library function and GCC does not implement it
for you. Do you use newlib?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2009-02-03 19:32 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary|
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-03 19:31 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-03 19:30 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary|
gcc.target/x86_64/abi doesn't test __float128, __int128 nor DFP.
--
Summary: x86_64/abi doesn't test __float128, __int128 nor DFP
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tes
--- Comment #3 from gcc at gaul dot org 2009-02-03 18:57 ---
After talking with Oleg, there are differences between gcc and g++ compiling
the code in comment #2:
$ g++ --version
g++ (GCC) 4.3.0
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for c
--- Comment #2 from gcc at gaul dot org 2009-02-03 18:40 ---
Original description is not quite accurate, the or operator does not cause a
spurious warning while the and operator does. Here is a more minimal test
case:
void func(char a, char b, char c)
{
c = a | b;
c = a & b;
--- Comment #1 from nemet at gcc dot gnu dot org 2009-02-03 18:36 ---
> Register $3 (v1) returns with uninitialized garbage. This is the high part of
> the 64 bit return value.
>
> I am not sure what should happen here. Really the "d" asm constraint should
> not match a 64 bit variabl
--- Comment #6 from mikael dot morin at tele2 dot fr 2009-02-03 18:01
---
(In reply to comment #1)
> Only departure from defaults is --prefix
No, -prefix ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
--- Comment #5 from mikael dot morin at tele2 dot fr 2009-02-03 18:00
---
/export/home/eckerta/Desktop/objdir/./gcc/gfortran
-B/export/home/eckerta/Desktop/objdir/./gcc/
-B/usr/local/gcc-4.3.3/i686-pc-linux-gnu/bin/
-B/usr/local/gcc-4.3.3/i686-pc-linux-gnu/lib/ -isystem
/usr/local/gcc-4
--- Comment #1 from oleg dot smolsky at riverbed dot com 2009-02-03 17:58
---
Created an attachment (id=17238)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17238&action=view)
The test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39089
With GCC: (GNU) 4.4.0 20090116 (experimental) [trunk revision 143437]
Consider this program (bug1900.c):
---8<---
unsigned long long bar()
{
unsigned long long rv;
asm volatile ("rdhwr %0, $30" : "=d" (rv));
return rv;
}
---8<--
--- Comment #17 from bonzini at gnu dot org 2009-02-03 17:57 ---
Thanks, I'll merge it with mine, bootstrap/regtest i686-pc-linux-gnu and submit
it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
g++ 4.3.3 emits warnings for every statement in the following function when the
code is built this way:
/gcc43/bin/g++ -c -Wall -Wconversion test.cpp
void func(unsigned char a, unsigned char b, unsigned char *out)
{
*out = a | b;
*out = out[0] & 0x20;
out[0] &= 0x20;
}
I'd expect
--- Comment #16 from hp at gcc dot gnu dot org 2009-02-03 17:54 ---
(In reply to comment #15)
> If you submit it, I'll happily take care of the conflicts.
I've put it in the PR, though it's not a proper submit yet.
Also, only regtested for cris-elf on the 4.3 branch and
x86_64-unknown-l
--- Comment #9 from hp at gcc dot gnu dot org 2009-02-03 17:46 ---
Created an attachment (id=17237)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17237&action=view)
Proposed fix
Also folds may_trap_after_code_motion_p into may_trap_or_fault_p, as being the
original semantics.
--
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-02-03 17:38 ---
Working on a patch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #8 from jakub at gcc dot gnu dot org 2009-02-03 17:28 ---
Subject: Bug 35318
Author: jakub
Date: Tue Feb 3 17:27:45 2009
New Revision: 143901
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143901
Log:
PR target/35318
* function.c (match_asm_constrain
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-03 17:26 ---
Subject: Bug 39059
Author: jakub
Date: Tue Feb 3 17:26:28 2009
New Revision: 143900
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143900
Log:
PR inline-asm/39059
* c-parser.c (c_parser_postfi
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-03 17:23 ---
Subject: Bug 39056
Author: jakub
Date: Tue Feb 3 17:23:11 2009
New Revision: 143899
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143899
Log:
PR c++/39056
* typeck2.c (digest_init_r): Don't c
--- Comment #7 from bonzini at gnu dot org 2009-02-03 17:21 ---
Interesting: we actually propagate *more* on 64-bit targets, and end up with
__builtin___memcpy_chk (&buf, valbuf_7(D), 16, 8);
while on 32-bit we get
__builtin___memcpy_chk (&buf, valbuf_7(D), D.1293_2, 8);
--
b
--- Comment #80 from paolo dot carlini at oracle dot com 2009-02-03 17:20
---
Many solutions are better, in principle, but really this issue is too old.
After all we are uglifying also in other cases. Let's do that and be done with
it. Unless there are objections (or, better, constructi
--- Comment #79 from bonzini at gnu dot org 2009-02-03 17:15 ---
Yeah, but it seems better than uglifying __try/__catch all over the place...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #6 from bonzini at gnu dot org 2009-02-03 17:15 ---
Only fails on 64-bit targets.
--
bonzini at gnu dot org changed:
What|Removed |Added
CC|
--- Comment #78 from paolo dot carlini at oracle dot com 2009-02-03 17:14
---
Nope, we never do that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #77 from bonzini at gnu dot org 2009-02-03 17:10 ---
Can't the library just #undef try/catch at the end of each file that includes
exception_defines.h?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-02-03 16:56 ---
Created an attachment (id=17236)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17236&action=view)
Preprocessed source
OK, this one is hopefully without any precompiled headers.
--
jamborm at gcc dot gnu d
--- Comment #4 from bonzini at gnu dot org 2009-02-03 16:56 ---
no he's not.
--
bonzini at gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from bonzini at gnu dot org 2009-02-03 16:52 ---
more precisely, without -ffast-math gcc is not able to change abs(z) < 2 to
r*r+i*i < 4 and computes a square root on every iteration.
--
bonzini at gnu dot org changed:
What|Removed |
--- Comment #13 from bonzini at gnu dot org 2009-02-03 16:40 ---
I agree that the patch is correct *without* the -1, so... ping :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
--- Comment #15 from bonzini at gnu dot org 2009-02-03 16:40 ---
Subject: Re: [4.3/4.4 Regression] SEGV,
conditional execution proactively executed the false arm.
> Yes, I found that out too ;) but haven't had time to follow up.
> FWIW, I have an overlapping patch for PR38921
--- Comment #17 from etienne_lorrain at yahoo dot fr 2009-02-03 16:38
---
(In reply to comment #15)
> The advantage of such a RTL pass (or just adding such optimization to another
> RTL pass) would be that it would handle also say: ...
Why only limit that pass to constants, and only to
--- Comment #14 from hp at gcc dot gnu dot org 2009-02-03 16:34 ---
(In reply to comment #11)
> No, the patch does not fix it.
Yes, I found that out too ;) but haven't had time to follow up.
FWIW, I have an overlapping patch for PR38921 that does fold the code as
suggested. It doesn't
--- Comment #68 from bonzini at gnu dot org 2009-02-03 16:32 ---
This was fixed on trunk (see comment #65).
Open another bug for long-term solutions, this is cluttering the 4.4
regressions. :-)
--
bonzini at gnu dot org changed:
What|Removed |Adde
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #8 from bonzini at gnu dot org 2009-02-03 16:28 ---
changing summary, inlining _is_ the right thing to do.
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #23 from bonzini at gnu dot org 2009-02-03 16:26 ---
Subject: Bug 37314
Author: bonzini
Date: Tue Feb 3 16:26:28 2009
New Revision: 143898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143898
Log:
gcc/cp:
2009-02-03 Paolo Bonzini
PR c++/36897
*
--- Comment #9 from bonzini at gnu dot org 2009-02-03 16:26 ---
Subject: Re: [4.2 Regression] ICE with function pointer
template parameter
> Did you really commit it to mainline? I don't see it.
I was doing it. :-)
--- Comment #10 from bonzini at gnu dot org 2009-02-03
--- Comment #9 from bonzini at gnu dot org 2009-02-03 16:26 ---
Subject: Re: [4.2 Regression] ICE with function pointer
template parameter
> Did you really commit it to mainline? I don't see it.
I was doing it. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36897
--- Comment #12 from bonzini at gnu dot org 2009-02-03 16:25 ---
When generating 64-bit code we produce good induction variables either with or
without ivopts, but with an extra mov.
For 32-bit code the situation is the same as reported originally.
--
bonzini at gnu dot org changed:
--- Comment #22 from paolo dot carlini at oracle dot com 2009-02-03 16:22
---
Likewise... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
--- Comment #8 from paolo dot carlini at oracle dot com 2009-02-03 16:22
---
Did you really commit it to mainline? I don't see it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36897
--- Comment #21 from bonzini at gnu dot org 2009-02-03 16:21 ---
fixed on 4.3/4.4, still needs backporting to 4.2
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from bonzini at gnu dot org 2009-02-03 16:20 ---
fixed on 4.3/4.4, still needs backporting to 4.2
--
bonzini at gnu dot org changed:
What|Removed |Added
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
--- Comment #32 from bonzini at gnu dot org 2009-02-03 16:16 ---
The patch for partial memory writes was committed.
How are we doing on this benchmark now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-03 16:15 ---
Use -ffast-math.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39087
--- Comment #3 from s dot neumann at phase-zero dot de 2009-02-03 16:14
---
The code in flac that triggered the problem does also make gcc crash with "-O3
-funroll-loops". I've also tested -O1 and -O2, same problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
--- Comment #20 from bonzini at gnu dot org 2009-02-03 15:56 ---
Subject: Bug 37314
Author: bonzini
Date: Tue Feb 3 15:56:05 2009
New Revision: 143896
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143896
Log:
gcc/cp:
2009-02-03 Paolo Bonzini
PR c++/36897
*
--- Comment #6 from bonzini at gnu dot org 2009-02-03 15:56 ---
Subject: Bug 36897
Author: bonzini
Date: Tue Feb 3 15:56:05 2009
New Revision: 143896
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143896
Log:
gcc/cp:
2009-02-03 Paolo Bonzini
PR c++/36897
* p
Following emits a warning about potential use of uninitialized variable,
even though the variable initialization and it's use are guarded by the
same predicate.
int f (void);
int g (int a)
{
int b;
if (a) b = f ();
asm volatile ("#");
if (a) return b;
return 1;
}
$ gcc -O -W
--- Comment #2 from m4341 at abc dot se 2009-02-03 15:50 ---
Notice that the test cases have been executed on a Pentium III computer with
dual 866MHz processors.
The 'depth' variable in the example code has been set to produce comfortable
execution times for the forementioned computer.
--- Comment #13 from bonzini at gnu dot org 2009-02-03 15:48 ---
Created an attachment (id=17235)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17235&action=view)
patch to be tested
The patch fixes the bug. As a follow up (see PR38921 audit trail)
MTP_AFTER_MOVE and MTP_UNALIGNED
--- Comment #1 from m4341 at abc dot se 2009-02-03 15:46 ---
Created an attachment (id=17234)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17234&action=view)
Test cases for demonstrating performance impact.
The attached file contains code that is in it's current state requiring
X
--- Comment #8 from pinskia at gmail dot com 2009-02-03 15:44 ---
Subject: Re: [4.3/4.4 Regression] Incorrect type diagnostic on substracting
casted char pointers
Sent from my iPhone
On Feb 3, 2009, at 5:56 AM, "bonzini at gnu dot org" wrote:
>
>
> --- Comment #7 from bonzini
Sent from my iPhone
On Feb 3, 2009, at 5:56 AM, "bonzini at gnu dot org" > wrote:
--- Comment #7 from bonzini at gnu dot org 2009-02-03 13:56
---
ping?
The patch was just approved last night and I will be applying it when
I get into work today.
--
bonzini at gnu dot
I have noticed that in some cases - especially calculating Mandelbrot Fractals
there is a severe performance penalty if the COMPLEX data type is used instead
of plain variables.
It's nothing wrong with the calculation, but it shall be noted that it can mean
a severe performance penalty if the COMP
--- Comment #3 from tony_eckert at umsl dot edu 2009-02-03 15:38 ---
Created an attachment (id=17233)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17233&action=view)
autoconf log of failed stage 3 build
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||error-recovery
Priority|P3 |P4
h
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-03 15:30 ---
Not too useful, that preprocessed source includes PCHs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
--- Comment #12 from bonzini at gnu dot org 2009-02-03 15:19 ---
But at least it gets cc1 to call rtx_addr_can_trap_p_1. Mine
--
bonzini at gnu dot org changed:
What|Removed |Added
---
1 - 100 of 154 matches
Mail list logo
