--- Comment #115 from pinskia at gcc dot gnu dot org 2007-06-19 07:56
---
*** Bug 32397 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-19 07:56 ---
((Cyg_libm_ieee_double_shape_type *)&x)->part is ovbiously an aliasing
violation.
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-19 08:10 ---
This is caused by two things, jump threading and inlining. If we jump thread
more, we no longer get the warning which is what you are seeing in 4.2.1.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-19 08:21 ---
This is IV-opts going funny I think as we get pointer+pointer (and yes real
pointer SSA_NAMES and no casts).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-19 08:26 ---
This code itself is very weird and I don't know if it is really defined or not.
We have basically:
char *f(char *a, char *b)
{
return a + (int)b;
}
How can that even be defined.
Anyways the following fixes the pr
--- Comment #97 from pinskia at gcc dot gnu dot org 2007-06-19 08:11
---
*** Bug 32391 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-06-19 08:11
---
So this is just a dup of bug 323 so closing as such.
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from ubizjak at gmail dot com 2007-06-19 08:27 ---
(In reply to comment #4)
> No, this one is caused by dataflow.
Dataflow uncovered generic middle-end (RTL?) problem:
We have this comment in instantiate_virutal_regs():
/* Scan through all the insns, instantiating ev
--- Comment #6 from ubizjak at gmail dot com 2007-06-19 08:58 ---
FWIW, this shoot-in-the-dark patch fixes ICE:
Index: expr.c
===
--- expr.c (revision 125789)
+++ expr.c (working copy)
@@ -5062,8 +5062,10 @@ store
--- Comment #2 from jakub at gcc dot gnu dot org 2007-06-19 09:08 ---
Subject: Bug 32353
Author: jakub
Date: Tue Jun 19 09:08:39 2007
New Revision: 125841
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125841
Log:
PR tree-optimization/32353
* tree-ssa-structalias
--- Comment #3 from jakub at gcc dot gnu dot org 2007-06-19 09:11 ---
Subject: Bug 32353
Author: jakub
Date: Tue Jun 19 09:11:22 2007
New Revision: 125842
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125842
Log:
PR tree-optimization/32353
* tree-ssa-structalias
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-19 09:15 ---
Confirmed. For 2 NR steps to reach double precision (we'd miss it by some more
ulps than the 2.5 for float precision) we would need to do at least the second
NR in double precision. Note that this would make sense
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-19 09:17 ---
The testcase indeed looks undefined (but valid).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
--- Comment #4 from jakub at gcc dot gnu dot org 2007-06-19 09:18 ---
Subject: Bug 32353
Author: jakub
Date: Tue Jun 19 09:18:13 2007
New Revision: 125843
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125843
Log:
PR tree-optimization/32353
* tree-ssa-structalias
--- Comment #5 from jakub at gcc dot gnu dot org 2007-06-19 09:19 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #43 from rguenth at gcc dot gnu dot org 2007-06-19 09:24
---
Subject: Bug 30252
Author: rguenth
Date: Tue Jun 19 09:24:35 2007
New Revision: 125844
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125844
Log:
2007-06-19 Richard Guenther <[EMAIL PROTECTED]>
M
--- Comment #4 from rearnsha at gcc dot gnu dot org 2007-06-19 09:41
---
Confirmed. This is a bug in the negscc pattern in arm.md. It's only been
there since 1994!
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #44 from rguenth at gcc dot gnu dot org 2007-06-19 09:45
---
Fixed on the 4.2 branch. Danny will fix this in a different way on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rosenfeld at grumpf dot hope-2000 dot org 2007-06-19
10:52 ---
Subject: Re: wrong instruction order generated
On Tue, Jun 19, 2007 at 07:56:01AM -, pinskia at gcc dot gnu dot org wrote:
> --- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-19 07:56
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-06-19 11:16 ---
Subject: Bug 31950
Author: rguenth
Date: Tue Jun 19 11:16:43 2007
New Revision: 125846
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125846
Log:
2007-06-19 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-06-19 11:17 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from rask at sygehus dot dk 2007-06-19 11:27 ---
You can use memcpy (&int, &float, min (sizeof (int), sizeof (float))) and vice
versa. I suppose you can also memcpy() into or out of a char array of the right
size.
If you were to use the GCC extension of using a union, it w
--- Comment #7 from ubizjak at gmail dot com 2007-06-19 11:54 ---
Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01317.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
svn snapshot from r125847
--
Summary: [4.3 Regression] ICE in expand_or_defer_fn, at
cp/semantics.c:3220
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
--- Comment #1 from jojelino at gmail dot com 2007-06-19 12:10 ---
Created an attachment (id=13735)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13735&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
--- Comment #10 from dominiq at lps dot ens dot fr 2007-06-19 12:48 ---
Even the code in comment #8 is invalid: several variables are used but not set:
at least intp and sum.
If I set them to 0, gfortran gives the same results with or without -O3. (tests
done on PPC Darwin7).
In my opin
With altivec enabled gcc prepares additional space on the stack. Unlike earlier
versions gcc 4.3 removes stack modification instructions if it isn't used. With
just -maltivec or with -mabi=altivec when altivec isn't used it works very
well. But with -mabi=altivec and altivec used gcc produces code
The compiler thinks we're allocating the actual abstract objects instead of an
array of pointers and reports the following error: "cannot allocate an object
of abstract type '...'". Since we're actual allocating an array of pointers,
this should not be an error.
The following code (reproduce.cpp)
--- Comment #1 from p dot vestjens at gmail dot com 2007-06-19 14:47
---
Created an attachment (id=13736)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13736&action=view)
Sourcefile demonstrating the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
NOTE: Defaulting component because reported component no longer exists
Environment:
System: Linux marko2 2.6.15-28-686 #1 SMP PREEMPT Thu Feb 1 16:14:07 UTC 2007
i686 GNU/Linux
Architecture: i686
host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: m68hc11-unknown-none
configured with: ../s
Spin off from PR 32236.
ftp://ftp.icess.ucsb.edu/pub/esrg/sbdart/sbdart_2.4.tar.gz (33181 lines of
code)
Unpack source and do:
- Delete in tauaero.f:1601 the line
data wlbaer/0.,0./
- Insert around drt.f:951 the lines
weq = 0.0_kr
wfull = 0.0_kr
If one compiles (-O0) the program with g
--- Comment #8 from burnus at gcc dot gnu dot org 2007-06-19 15:30 ---
Bob,
> Can you please tell me why the compiler flags "tauaero.f:1517" while
> the problem seems to be associated with the data statement at line
> 1601?
The line number shown when an internal compiler error occu
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-19 16:02 ---
blah
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from rask at gcc dot gnu dot org 2007-06-19 16:30 ---
Subject: Bug 32369
Author: rask
Date: Tue Jun 19 16:30:03 2007
New Revision: 125851
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125851
Log:
2007-06-19 Rask Ingemann Lambertsen <[EMAIL PROTECTED]>
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-19 16:30 ---
Tobias points out to me that this is not a regression - closed and out.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-19 16:32 ---
Sorry for my screw-up on the PR number - it was 20882 that was fixed.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20082
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-19 16:32 ---
This is not a regression, so that is it.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from daney at gcc dot gnu dot org 2007-06-19 16:36 ---
Subject: Bug 32313
Author: daney
Date: Tue Jun 19 16:36:42 2007
New Revision: 125852
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125852
Log:
PR target/32313
* config/mips/mips.md (cprestore
--- Comment #15 from daney at gcc dot gnu dot org 2007-06-19 16:43 ---
The second time is the charm.
There are still regressions caused by the dataflow merge, but at least we can
bootstrap now.
--
daney at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pault at gcc dot gnu dot org 2007-06-19 16:44 ---
This is not a regression so no backport.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from rob1weld at aol dot com 2007-06-19 17:11 ---
>>The goal of the tests is not to measure some time, but to check that
>>intervals are properly ordered, i.e., t1<=dat1<=t1a and t2a<=dat2-dat1<= t2.
If that is the "goal" then could we eliminate all influence of time (mi
--- Comment #26 from rth at gcc dot gnu dot org 2007-06-19 17:26 ---
(In reply to comment #10)
> Talked to Dan Berlin and Diego Novillo here at Google. They told me
> that all locals are promoted to function scope.
That *only* applies to register variables, not stack variables.
We very
--- Comment #9 from rask at gcc dot gnu dot org 2007-06-19 17:35 ---
Subject: Bug 32335
Author: rask
Date: Tue Jun 19 17:35:16 2007
New Revision: 125853
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125853
Log:
2007-06-19 Rask Ingemann Lambertsen <[EMAIL PROTECTED]>
--- Comment #27 from dnovillo at google dot com 2007-06-19 17:39 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing
causing removal of live code
On 6/19/07 1:26 PM, rth at gcc dot gnu dot org wrote:
> --- Comment #26 from rth at gcc dot gnu dot org 2007-06-19 17:26 ---
The following 2 testcases began failing for an xtensa-elf target when the
dataflow branch was merged:
gcc.c-torture/execute/920501-6.c
gcc.c-torture/execute/930921-1.c
Both tests fail at -O3 with "internal compiler error: in get_biv_step,
at loop-iv.c:792". Neither the Xtensa port nor the loop-iv
Build from svn r125825 with:
http://gcc.gnu.org/viewcvs?view=rev&revision=125852
applied.
Configured: ../trunk/configure --target=mipsel-linux
--with-sysroot=/usr/local/mipsel-linux-test
--prefix=/usr/local/mipsel-linux-test --with-arch=mips32 --with-float=soft
--disable-java-awt --without-x --dis
--- Comment #2 from jojelino at gmail dot com 2007-06-19 18:13 ---
Created an attachment (id=13737)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13737&action=view)
source file that causes ICE
reduced. just three line for ICE
--
jojelino at gmail dot com changed:
W
--- Comment #3 from jojelino at gmail dot com 2007-06-19 18:18 ---
(From update of attachment 13737)
removing static keyword at the top resolves problem.
but is it workaround?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
--- Comment #13 from spop at gcc dot gnu dot org 2007-06-19 18:35 ---
Subject: Bug 32367
Author: spop
Date: Tue Jun 19 18:35:39 2007
New Revision: 125855
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125855
Log:
PR tree-optimization/32367
* tree-chrec.h (build_p
--- Comment #28 from amacleod at redhat dot com 2007-06-19 18:57 ---
Won't solve the problem currently, but I think the long term solution is to do
stack analysis when out-of-ssa and expand have been merged into a single
entity. The live range info out-of-ssa calculates can be used to do
The detailed content of the log is shown below.
splitting
/home/voax/linux/build-4.3.0/gcc/testsuite/ada/acats/tests/cd/cd92001.a into:
cd92001.adb
BUILD cd92001.adb
gnatmake --GCC="/home/voax/linux/build-4.3.0/gcc/xgcc
-B/home/voax/linux/build-4.3.0/gcc/" -gnatws -O2
-I/home/voax/linux/build-4
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-19
19:56 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
> > We need to know that the return pointer (r2) is not used and that
> > the function is a leaf function (i.e., that the incoming va
--- Comment #15 from hjl at lucon dot org 2007-06-19 20:10 ---
(In reply to comment #14)
> The linux problem is wierd. In stage2, I get the following
> failure:
>
> /bin/sh: line 1: 4487 Segmentation fault (core dumped) ./xsinfo
> ../../sinf
> o.h
> make[3]: *** [ada/sinfo.h] E
GCC may have a defective template parsing routine which seems to mistake the
'<' token in an expression for the beginning of a template argument. The error
only seems to happen when a templated function evaluates a member of a
templated class or struct with a '<' symbol.
Here is a simple code sni
GCC may have a defective template parsing routine which seems to mistake the
'<' token in an expression for the beginning of a template argument. The error
only seems to happen when a templated function evaluates a member of a
templated class or struct with a '<' symbol.
Here is a simple code sni
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-19
20:39 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
> "make" may change stack limit.
You are right. Make bumps the soft limit to unlimited when the hard
limit is unlimited.
Dave
--
--- Comment #1 from sje at cup dot hp dot com 2007-06-19 21:12 ---
I proposed XFAIL'ing the test at one point but that patch was not accepted.
See http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02016.html
I get the same failure on IA64 HP-UX.
--
sje at cup dot hp dot com changed:
--- Comment #1 from schwab at suse dot de 2007-06-19 21:22 ---
*** Bug 32409 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32408
--- Comment #1 from schwab at suse dot de 2007-06-19 21:22 ---
*** This bug has been marked as a duplicate of 32408 ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2007-06-19 22:04 ---
Apparently you provided the wrong snippet, this one compiles just fine and
well, doesn't have 22 lines... ;)
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #1 from rakdver at kam dot mff dot cuni dot cz 2007-06-19
22:07 ---
Subject: Re: New: assertion failure in loop-iv.c; probable dataflow
regression
> The failing assertion in get_biv_step() is:
>
> gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN));
>
> Th
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
If you create a const member function to a template class, it seems to be able
to change a non-mutable member of the function by using the this pointer. The
following illegal code compiles:
template
class Class
{
unsigned int i;
public:
void foo () const
{
this->i++;
}
};
Howeve
--- Comment #3 from chsalvia at gmail dot com 2007-06-19 23:08 ---
Sorry. It seems this is actually a namespace conflict issue. If you add
include the iostream header file and add "using namespace std" the code will
not compile, due to a conflict with std::count.
#include
using names
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-19 23:10 ---
*** This bug has been marked as a duplicate of 10200 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-19 23:10
---
*** Bug 32408 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-19 23:13 ---
This is correct as "*this" is dependent so the compiler cannot resolve that
until instantation time so this is not a bug.
>This is inconsistent behavior.
Yes but i here is not depdendent. While this->i is.
--
p
--- Comment #17 from danglin at gcc dot gnu dot org 2007-06-19 23:30
---
Created an attachment (id=13738)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13738&action=view)
Patch under test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
--- Comment #18 from danglin at gcc dot gnu dot org 2007-06-19 23:32
---
The stack overflow takes some time and I was able to attach gdb:
0x402a6c58 in read_encoded_value_with_base (encoding=11 '\v', base=0,
p=0x60384 "", val=0xc019ea8c) at ../../../gcc/libgcc/../gcc/unwind-pe.h:20
--- Comment #20 from mrs at apple dot com 2007-06-19 23:36 ---
The patch was approved today on the gcc-patches list.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
--- Comment #12 from malitzke at metronets dot com 2007-06-19 23:57 ---
Why is this still unconfirmed after the corrobation by Mrs Johnson?
Personally I could not care less if it is swept under the rug, like so many
other
PR's. Without-altivec would suit me fine as altivec is, to me, ju
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-20 00:27
---
This is a target bug. Nothing can change it from being a target bug unless it
turns out to be a middle-end bug on how addressing works inside the compiler.
The main reason why it has not been confirmed, is because
--- Comment #1 from hp at gcc dot gnu dot org 2007-06-20 02:53 ---
I saw your comments on IRC at an attempt of using nonlocal_goto_receiver.
You don't want to make a new pattern with that name, just rename
exception_receiver; the obvious one-line patch. That pattern already has the
nece
--- Comment #14 from pault at gcc dot gnu dot org 2007-06-20 05:02 ---
Subject: Bug 32302
Author: pault
Date: Wed Jun 20 05:02:39 2007
New Revision: 125870
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125870
Log:
2007-06-20 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #15 from pault at gcc dot gnu dot org 2007-06-20 05:03 ---
Fixed on trunk and 4.2
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
e
some problems with including "-lm" even when it is not specified on the command
line.
GNU C version 4.3.0 20070619 (experimental), GMP version 4.2.1, MPFR version
2.3.0-dev.
GNU assembler version 2.17.50 (i686-pc-linux-gnu) using BFD version (GNU
Binutils) 2.17.50.20070426
# /opt/g
--- Comment #19 from rob1weld at aol dot com 2007-06-20 05:09 ---
Just tried MPFR version 2.3.0 - it works fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
--- Comment #9 from rob1weld at aol dot com 2007-06-20 05:15 ---
Still occurs:
gcc version 4.3.0 20070619 (experimental)
/root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c: In function '__muldi3':
/root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c:557: internal compiler
--- Comment #2 from rob1weld at aol dot com 2007-06-20 05:30 ---
Bug part 1 - FIXED
I was still getting the "undefined reference to `GC_local_malloc'" errors in
"gcc version 4.3.0 20070614" but it may be fixed in "gcc version 4.3.0
20070619".
Bug
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-06-20 05:47 ---
Subject: Bug 28011
Author: kkojima
Date: Wed Jun 20 05:47:09 2007
New Revision: 125871
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125871
Log:
PR rtl-optimization/28011
Backport from mainl
--- Comment #5 from kkojima at gcc dot gnu dot org 2007-06-20 05:52 ---
Subject: Bug 28011
Author: kkojima
Date: Wed Jun 20 05:52:05 2007
New Revision: 125872
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125872
Log:
PR rtl-optimization/28011
Backport from mainl
--- Comment #6 from kkojima at gcc dot gnu dot org 2007-06-20 05:54 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #10 from jakub at gcc dot gnu dot org 2007-06-20 06:36 ---
Subject: Bug 32285
Author: jakub
Date: Wed Jun 20 06:35:55 2007
New Revision: 125873
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125873
Log:
PR middle-end/32285
* calls.c (precompute_argume
--- Comment #2 from jakub at gcc dot gnu dot org 2007-06-20 06:37 ---
Subject: Bug 32109
Author: jakub
Date: Wed Jun 20 06:37:17 2007
New Revision: 125874
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125874
Log:
PR inline-asm/32109
* gimplify.c (gimplify_asm_ex
--- Comment #4 from jakub at gcc dot gnu dot org 2007-06-20 06:40 ---
Subject: Bug 31959
Author: jakub
Date: Wed Jun 20 06:39:53 2007
New Revision: 125875
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125875
Log:
PR middle-end/31959
* builtins.c: Include diagnos
--- Comment #11 from jakub at gcc dot gnu dot org 2007-06-20 06:44 ---
Subject: Bug 32285
Author: jakub
Date: Wed Jun 20 06:44:26 2007
New Revision: 125877
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125877
Log:
PR middle-end/32285
* calls.c (precompute_argume
--- Comment #3 from jakub at gcc dot gnu dot org 2007-06-20 06:46 ---
Subject: Bug 32109
Author: jakub
Date: Wed Jun 20 06:46:31 2007
New Revision: 125878
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125878
Log:
PR inline-asm/32109
* gimplify.c (gimplify_asm_ex
--- Comment #12 from jakub at gcc dot gnu dot org 2007-06-20 06:50 ---
Subject: Bug 32285
Author: jakub
Date: Wed Jun 20 06:50:23 2007
New Revision: 125879
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125879
Log:
PR middle-end/32285
* calls.c (precompute_argume
--- Comment #4 from jakub at gcc dot gnu dot org 2007-06-20 06:51 ---
Subject: Bug 32109
Author: jakub
Date: Wed Jun 20 06:51:47 2007
New Revision: 125880
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125880
Log:
PR inline-asm/32109
* gimplify.c (gimplify_asm_ex
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-06-20 06:56 ---
Subject: Bug 32405
Author: rakdver
Date: Wed Jun 20 06:56:26 2007
New Revision: 125881
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125881
Log:
PR rtl-optimization/32405
* loop-iv.c (iv_get
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-06-20 06:57 ---
Should be fixed now.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
St
91 matches
Mail list logo
