--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-10
08:04 ---
New patch at http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00864.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
The error message in this case is misleading:
$ cat foo.cc
#include unistd.h
namespace foo {
typedef long long offset_t;
}
using namespace std;
using namespace foo;
int main() {
offset_t fpos;
}
$
$ g++ -c foo.cc
foo.cc: In function `int main()':
foo.cc:11: error: `offset_t' undeclared
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-03-10
09:48 ---
Created an attachment (id=8371)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8371action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20401
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-03-10
09:49 ---
Created an attachment (id=8372)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8372action=view)
stripped down test case
--
What|Removed |Added
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-10
11:00 ---
While the main problem reported by the filer has now been fixed on
mainline, I think we should not close this PR just yet - not until
we check in a testcase for our testsuite for this, which is not
--- Additional Comments From uros at kss-loka dot si 2005-03-10 11:01
---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01009.html
--
What|Removed |Added
--- Additional Comments From mckinlay at redhat dot com 2005-03-10 11:30
---
Why not check in the test case and XFAIL it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20338
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-10
11:44 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Mar 9, 2005, Jakub Jelinek [EMAIL PROTECTED] wrote:
On Wed, Mar 09, 2005 at 01:02:08AM -0300, Alexandre Oliva wrote:
On Mar
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-10
12:00 ---
(In reply to comment #7)
Why not check in the test case and XFAIL it?
I feel dumb for not having thought of it myself...
I am closing this bug and will submit the testcase as
a separate patch. Thanks.
Hello!
I am NOT sure that we discovered problem the first... but this makes
GCC3.0.4-2 dump core 100%
Host ARCH i386 target ARCH i386
std::string str;
make_pair(string,(str.length() == 0?throw string:str));
/usr/include/g++-v3/bits/stl_pair.h:222: Internal error: Segmentation fault
I noticed that latest CVS (20050310) silently ICEs (reporting PASS) on testcase
gcc.dg/noncompile/920923-1.c. Reduced to:
struct *A a;
# gcc -v ./a.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++
--enable-threads=posix --enable-share
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-10
12:48 ---
Maybe there should be another combining pass after the duplication
of the indirect jumps. Should I create another PR for this?
There should not be another combining pass (you really mean constant
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
12:59 ---
This is why standard C++ classes are in namespaces.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
13:06 ---
Confirmed, caused by the new parser.
--
What|Removed |Added
CC|
* the options given when GCC was configured/built;
Configured with:
/home/niva/svnwork/gccvendorcurrent/configure
--with-headers=/home/niva/oc2000/mips/src/include
--without-libs --enable-generated-files-in-srcdir --enable-threads=posix
-with-dwarf2
--disable-shared --target=mips64-none-elf
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
13:10 ---
Closing as this is not our bug.
--
What|Removed |Added
Status|UNCONFIRMED
* the options given when GCC was configured/built;
Configured with:
/home/niva/svnwork/gccvendorcurrent/configure
--with-headers=/home/niva/oc2000/mips/src/include
--without-libs --enable-generated-files-in-srcdir --enable-threads=posix
-with-dwarf2
--disable-shared --target=mips64-none-elf
--
What|Removed |Added
Keywords||wrong-debug
Summary|dwarf2: DW_MACINFO_define - |dwarf-3: DW_MACINFO_define -
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
13:17 ---
*** This bug has been marked as a duplicate of 20253 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
13:18 ---
*** Bug 20404 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-10
13:30 ---
A patch is here:
http://gcc.gnu.org/ml/java-patches/2005-q1/msg00710.html
--
What|Removed |Added
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-10 13:37
---
The problem appears to be unrelated to the referenced patch.
Debugging shows that we have a node that has been removed from the cgraph_nodes
list. Because the node is not on the cgraph_nodes list, the
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-10 13:46
---
Subject: Re: [PR middle-end/18628] do not fold to label load from tablejump to
reg
On Wed, Mar 09, 2005 at 07:26:37AM -0300, Alexandre Oliva wrote:
+ /* If it's not a REG, the REG_EQUAL note is
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-10 13:57
---
I'll agree that modified_{in,between}_p need to check the address for changes,
since that controls the ultimate value that is accessed.
I do not agree that alias.c needs to check the address for changes. In
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-03-10
14:01 ---
This is technically correct.
In 4.0 we are still off by a single line, we claim it to be line 1 when it
should be 0.
We also will output them after the main file starts (this is because of the
order of CPP
--- Additional Comments From matthew dot whitney at gmail dot com
2005-03-10 14:10 ---
Thanks for the explanation - I understand what's happening now. Next time I'll
take it to comp.lang.c++.moderated before bothering you guys. Anyway sorry to
have wasted your time.
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10
14:18 ---
Subject: Bug 18384
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-10 14:17:11
Modified files:
gcc/cp :
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
14:20 ---
Also note peepholes should really be changed to peephole2.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10
14:20 ---
Subject: Bug 18384
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-10 14:19:51
Modified files:
gcc/cp : ChangeLog
gcc/testsuite :
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-10 14:22
---
Fixed for 3.4/4.0/4.1.
--
What|Removed |Added
Known to fail|4.0.0 3.4.3
--
What|Removed |Added
OtherBugsDependingO||20405
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20361
There are currently two equivalenced variable problems but I suspect there are
more which is why I am
creating this meta-bug.
--
Summary: [meta-bug] equivalenced variable problems
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords:
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
14:38 ---
This is an equivalenced problem so linking to 20405
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
14:39 ---
The way I came to that conclusion was the following code worked:
c { dg-do compile }
subroutine sub(a)
common /info/ m, n
real a(m,n)
a(1,1) = a(2,2)
end
--
--
What|Removed |Added
OtherBugsDependingO||20405
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18518
Dear gfortran developers,
This is not a bug, but perhaps in the class of 'unexpected, but notincorrect,
behaviour'. This is just for your attention, but not (necessarily) for action as
I'm sure there are vastly more important things to deal with.
The issue is the return value from size() when
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
15:00 ---
This is a library problem.
--
What|Removed |Added
Severity|enhancement
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10
15:04 ---
Subject: Bug 20375
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-10 15:04:39
Modified files:
gcc: ChangeLog function.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10
15:11 ---
Subject: Bug 20375
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-10 15:11:25
Modified files:
gcc:
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-10
15:11 ---
Patch submitted:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01028.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
The following code is rejects (even though it is valid C99 and Mark said we
should have the C++ front-
end accept it also):
typedef struct {
unsigned char dir;
int data[];
} AiDefaultRailBlock;
static const AiDefaultRailBlock _raildata_ai_0 = { 1, { 0, 4 } };
--
Summary: Rejects
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
15:12 ---
The ICE has been fixed on the mainline, 3.4 and 4.0 branches but we still have
a rejects valid, which I
filed as PR 20407.
--
What|Removed |Added
--
What|Removed |Added
BugsThisDependsOn||18327
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20407
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-10 15:15
---
Err, sorry, that how to reproduce snippet depended on some other changes
in my tree. You'll have to check
node-previous node-previous-next != node.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
--- Additional Comments From nathan at gcc dot gnu dot org 2005-03-10
15:23 ---
2005-03-10 Nathan Sidwell [EMAIL PROTECTED]
PR c++/20375
* function.c (struct assign_parm_data_one): Remove last_named
field.
(assign_parm_find_data_types): Don't determine
--
What|Removed |Added
Target Milestone|4.1.0 |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
Given an empty struct (ie struct X { };), even at high optimisation levels g++
will insist on always allocating and zeroing some memory for empty structs.
This actually effects C++ code, including libstdc++-v3, as empty structs are
often used as a means of passing around functions.
EXAMPLE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
15:56 ---
Note this has no effect on the generated code.
But anyways:
struct X D.1574;
struct X D.1590;
D.1574 = {};
D.1590 = 0;
That is not right 0 is an INTEREGER_CST which cannot be an aggregate, that
--
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
--- Additional Comments From joseph at codesourcery dot com 2005-03-10
15:59 ---
Subject: Re: New: Rejects valid C99 for the C++ front-end
On Thu, 10 Mar 2005, pinskia at gcc dot gnu dot org wrote:
The following code is rejects (even though it is valid C99 and Mark said we
should
--- Additional Comments From chris at bubblescope dot net 2005-03-10 16:00
---
ignore my random changing of severity..
--
What|Removed |Added
Severity|minor
--- Additional Comments From chris at bubblescope dot net 2005-03-10 16:05
---
When you say has no effect in final code, are you talking about the problem
you noticed, or the problem as a whole?
I find for each extra X I add to the type of foo I get a line much like:
movb %al,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
16:10 ---
Werid on PPC, we get the most optimal code of
__Z8call_foov:
LFB2:
b __Z3foo1X
--
What|Removed |Added
/* { dg-do compile } */
/* { dg-options -O2 -fprofile-generate } */
struct S
{
int a;
void **b;
};
void
foo (struct S *x, int y)
{
if (!x)
return;
if (y = x-a)
return;
x-a--;
for (; y x-a; y++)
x-b[y] = x-b[y + 1];
x-b[x-a] = (void *) 0;
}
ICEs on IA-64 during
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
16:21 ---
(In reply to comment #5)
Andrew, is Daniel Berlin struct aliasing work likely to help, here?
No, fixing the front-end so it no longer produces a = 0 will most likely fix
this as that is just wrong.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
16:24 ---
This is not a target bug but rather a bug in CSE.
This is a dup of bug 20249.
*** This bug has been marked as a duplicate of 20249 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
16:25 ---
*** Bug 20409 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-03-10 16:19
---
Andrew, is Daniel Berlin struct aliasing work likely to help, here?
--
What|Removed |Added
Hello,
I have problem using gcc 3.4.3. preprocessed file is attached. Gcc
3.3.x works right, several 3.4.x's checked so far crashed.
Marcin Mogielnicki, ICM, Poland
# gcc -c -Wall -std=gnu99 -mmmx -msse -D_GNU_SOURCE -ffast-math overfit.c
-fPIC -DPIC -o overfit.o
overfit.c: In function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
17:06 ---
From call.c:
/* Don't pass empty class objects by value. This is useful
for tags in STL, which are used to control overload resolution.
We don't need to handle other cases of copying empty
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
17:07 ---
From cp-gimplifier.c:
case EMPTY_CLASS_EXPR:
/* We create an INTEGER_CST with RECORD_TYPE and value zero. */
*expr_p = build_int_cst (TREE_TYPE (*expr_p), 0);
This is wrong.
--
--- Additional Comments From pcarlini at suse dot de 2005-03-10 17:13
---
Eh, I was looking at the very same code... Can't we deal with EMPTY_CLASS_EXPR
similarly to USING_STMT? ;) ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
17:15 ---
(In reply to comment #9)
Eh, I was looking at the very same code... Can't we deal with EMPTY_CLASS_EXPR
similarly to USING_STMT? ;) ;)
I think we should produce an empty CONSTRUCTOR (which I am testing
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
17:30 ---
(In reply to comment #10)
I think we should produce an empty CONSTRUCTOR (which I am testing right now).
That did not fix it, we still get code generated for the empty struct:
;; D.1594 = {}
(nil)
;; foo
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
17:35 ---
The change to cp-gimplifier.c should still happen as it makes not create a
INTEGER_CST for an
aggregate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
This is a request for enhancement. Please add platform independent UTF-16 string
syntax (platform independent means not using wchar_t). The variability of the
wchar_t type makes it unsuitable for UTF-16 strings. This request is to
implement ISO/IEC JTC1 SC22 WG14's technical report that is titled,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
18:12 ---
Confirmed, but this will most likely not going to happen until this is approved
or is decided that is
about to be approved.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
18:12 ---
Suspending until then.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
18:17 ---
The bug is in convert_to_base_statically.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19817
--- Additional Comments From joern dot rennecke at st dot com 2005-03-10
18:18 ---
Subject: Re: [3.4/4.0/4.1 Regression] Wrong code generation for the argument
of the pure function in PIC
rth at gcc dot gnu dot org wrote:
--- Additional Comments From rth at gcc dot gnu dot org
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10
18:40 ---
Subject: Bug 20312
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-10 18:40:28
Modified files:
gcc/java : ChangeLog parse.y
Log message:
I believe this is a known problem, but I couldn't find it anywhere.
The inliner at -O2 will attempt to inline any small functions. It will not
however try to inline functions will external linkage, which includes all
templated functions.
As much C++ code (including libstdc++) contains many small
/*
gcc-4.0 sparc-SunOS bug
gcc-4.0 -O0 -c foo.c // ok
gcc-4.0 -O1 -c foo.c // ICE
% gcc-4.0 -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: /home/kate/gcc-4.0-20050305/src/gcc-4.0-20050305/configure
--- Additional Comments From pluto at pld-linux dot org 2005-03-10 19:01
---
[~/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/i686-pld-linux/libjava/.libs]
drwxr-xr-x 2 pluto users 4096 2005-03-10 19:51 .
drwxr-xr-x 15 pluto users 4096 2005-03-10 19:51 ..
-rw--- 1
--- Additional Comments From pluto at pld-linux dot org 2005-03-10 19:11
---
I've recheckd the install log and found the reason of relinking error.
/home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/gcc/xgcc
-shared-libgcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
19:21 ---
Note there are two problems here, foo2/foo in the orginal example are found to
pure/const function so
they are optimizated away which is different than inlining.
This all fixed on the tree profiling
--- Additional Comments From micis at gmx dot de 2005-03-10 19:25 ---
I did a bootstrap and run the checks on x86_64-linux. No new regressions.
Then I compiled my application including QT 3.3.4, ACE 5.4.2, GSL 1.5 and all
worked well.
Many thanks for the quick fix.
Michael Cieslinski
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-10
19:40 ---
Confirmed:
pr20412.c: In function 'foo':
pr20412.c:20: internal compiler error: RTL check: expected elt 0 type 'e' or
'u', have 'i' (rtx reg) in simplify_set, at combine.c:5145
Please submit a full bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
19:41 ---
Without RTL checking we get this backtrace:
#0 0x0066027c in simplify_comparison (code=REG, pop0=0xbfffef8c,
pop1=0xbfffef90) at ../../gcc/
combine.c:9584
#1 0x00650ad4 in simplify_set (x=0x4157ab04) at
--- Additional Comments From janis at gcc dot gnu dot org 2005-03-10 19:42
---
Created an attachment (id=8373)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8373action=view)
smaller C test case
The test case provided by the submitter runs successfully if the executable is
built
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
19:48 ---
Hmm, we are simplifing the following RTL:
(compare:CC (ne:SI (reg:SI 131)
(const_int 0 [0x0]))
(const_int 0 [0x0]))
To:
(reg:SI 131)
Which is wrong (but I should note that simplify_set
--- Additional Comments From pluto at pld-linux dot org 2005-03-10 19:53
---
Created an attachment (id=8374)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8374action=view)
test patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20392
--- Additional Comments From bangerth at dealii dot org 2005-03-10 19:55
---
This is a duplicate of a good number of other PRs. I don't have the time
right now to find them, though...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20401
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
19:56 ---
I could sware I closed this as a dup of bug 100 before.
*** This bug has been marked as a duplicate of 100 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
19:56 ---
*** Bug 20401 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
BugsThisDependsOn||20413
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
Various parts of the compiler generate LABEL_REFS with VOIDmode instead of
Pmode.
This can cause some optimizations to be missed because two pieces of code
might be identical, except for the mode of their LABEL_REFS - then they still
compare as non-equal, e.g. for if-conversion or cross-jumping.
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-10
19:59 ---
Created an attachment (id=8375)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8375action=view)
patch against 3.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20413
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
20:09 ---
Found the typo.
The following patch fixes the ICE and corrects the mode problem.
I will apply this as ovbious as this was broken when
simplify_relational_operation_1 was moved out of
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-10
20:38 ---
Subject: Re: [PR middle-end/18628] do not fold to label load from tablejump to
reg
On Mar 10, 2005, Richard Henderson [EMAIL PROTECTED] wrote:
On Wed, Mar 09, 2005 at 07:26:37AM -0300, Alexandre Oliva
--- Additional Comments From joel at gcc dot gnu dot org 2005-03-10 20:50
---
Any chance of this getting committed to the 3.4, 4.0 and 4.1 branches so it
can be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
It seems that g++ is not compliant with the standard for old-style C casts -
potentially causing programs to crash.
Below is a code sample followed by an detailing of what happens in practice, and
what I think should happen. Cast#5 is the problematic cast.
CODE STARTS HERE =
--- Additional Comments From pcarlini at suse dot de 2005-03-10 21:19
---
Seems already fixed in mainline and 4_0-branch...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20414
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
21:23 ---
Fixed in 4.0.0 by:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01676.html
From that patch:
The underlying problem was that we were not handling C-style casts as
one of const_cast, static_cast, or
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10
21:26 ---
Subject: Bug 20322
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-10 21:26:12
Modified files:
gcc: ChangeLog combine.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10
21:30 ---
Subject: Bug 20322
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-10 21:29:56
Modified files:
gcc:
--- Additional Comments From ericw at evcohs dot com 2005-03-10 21:30
---
Marek, can you review this bug, the attached patches, and possibly approve
committing the fix?
Thanks
Eric
--
What|Removed |Added
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-10 21:31
---
Fixed in CVS.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
1 - 100 of 137 matches
Mail list logo
