--- Comment #4 from hjl at lucon dot org 2006-05-21 06:58 ---
It is the same as PR 27449.
*** This bug has been marked as a duplicate of 27449 ***
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #3 from hjl at lucon dot org 2006-05-21 06:58 ---
*** Bug 27633 has been marked as a duplicate of this bug. ***
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #4 from hjl at lucon dot org 2006-05-21 06:59 ---
It also happens on Linux/ia64.
--
hjl at lucon dot org changed:
What|Removed |Added
GCC host
--- Comment #5 from pault at gcc dot gnu dot org 2006-05-21 07:35 ---
Subject: Bug 25090
Author: pault
Date: Sun May 21 07:35:05 2006
New Revision: 113949
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113949
Log:
2006-05-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #7 from pault at gcc dot gnu dot org 2006-05-21 07:35 ---
Subject: Bug 25746
Author: pault
Date: Sun May 21 07:35:05 2006
New Revision: 113949
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113949
Log:
2006-05-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #8 from pault at gcc dot gnu dot org 2006-05-21 07:35 ---
Subject: Bug 19015
Author: pault
Date: Sun May 21 07:35:05 2006
New Revision: 113949
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113949
Log:
2006-05-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #4 from pault at gcc dot gnu dot org 2006-05-21 07:35 ---
Subject: Bug 27584
Author: pault
Date: Sun May 21 07:35:05 2006
New Revision: 113949
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113949
Log:
2006-05-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 08:08 ---
Confirmed based on the patch here and the dup bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-21 08:05 ---
This has been fixed already. The problem was in the demangler of ld.
This is not a GCC bug so closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pault at gcc dot gnu dot org 2006-05-21 08:21 ---
I have just realised that there is a simple fix for this.
It is my use of the scalarizer to perform the actual transfer that is the
source of the problem. One of you or Bo suggested using memcpy. That is what
I
--- Comment #6 from pault at gcc dot gnu dot org 2006-05-21 08:24 ---
HJ
Would you also be prepared to try a patch, in a day or two?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-05-21 08:39
---
Subject: Bug 27398
Author: reichelt
Date: Sun May 21 08:39:14 2006
New Revision: 113950
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113950
Log:
PR c++/27398
* decl.c (grokdeclarator):
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-21 08:41
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
/home/pinskia/src/gcc/checkin/gcc/objdir/gcc/testsuite/g++/../../include/pmmintrin.h:
In function 'void _mm_monitor(const void*, unsigned int, unsigned int)':^M
/home/pinskia/src/gcc/checkin/gcc/objdir/gcc/testsuite/g++/../../include/pmmintrin.h:116:
internal compiler error: in copy_to_mode_reg,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 08:45 ---
Confirmed based on:
http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01139.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
In this snippet of code:
struct foo {
int x[2][10];
};
void f(void)
{
const struct foo bar;
const int (*baz)[10] = bar.x; /* should be ok */
int (*qoox)[10] = bar.x; /* should warn */
bar.x[0][1] = 23; /* error: asignment to const */
(*qoox)[1] = 23;
}
bar is const, so bar.x is
--- Comment #1 from fischer at td dot mw dot tum dot de 2006-05-21 09:31
---
In the function above:
bar.x[0][0] = 23; // gcc 4.1 gives error
*bar.x[0] = 23; // gcc 4.1 gives NO error
both lines do the same
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27697
--- Comment #7 from kazu at gcc dot gnu dot org 2006-05-21 09:39 ---
Posted a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #11 from kazu at gcc dot gnu dot org 2006-05-21 09:51 ---
Unassignining myself.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from kazu at gcc dot gnu dot org 2006-05-21 09:53 ---
Unassigning myself.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
subroutine _foo
end
draws the following error:
In file bhatt.f:1
subroutine _foo
1
Error: Unclassifiable statement at (1)
whereas the compiler would be far more helpful pointing out that _foo is
against the Standard (Rule
--- Comment #17 from laurent at guerby dot net 2006-05-21 10:24 ---
This is fixed with:
gcc version 4.2.0 20060518 (experimental)
gcc version 4.1.1 20060517 (prerelease)
--
laurent at guerby dot net changed:
What|Removed |Added
PR 27251 was closed as a duplicate of PR 18058. I was
on the CC: list of PR 27251 and had to add myself to
the CC: list of PR 18058 manually (as the bug activity
will show).
--
Summary: [bugzilla] CC should be transferred when closing a bug
as duplicate
--- Comment #1 from aldot at gcc dot gnu dot org 2006-05-21 11:50 ---
Created an attachment (id=11490)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11490action=view)
print error invalid form for SUBROUTINE at
Not tested.
2006-05-21 Bernhard Fischer [EMAIL PROTECTED]
--- Comment #6 from pault at gcc dot gnu dot org 2006-05-21 11:53 ---
Subject: Bug 27613
Author: pault
Date: Sun May 21 11:53:02 2006
New Revision: 113951
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113951
Log:
2006-05-21 Paul Thomas [EMAIL PROTECTED]
PR
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #5 from aldot at gcc dot gnu dot org 2006-05-21 12:16 ---
Setting Target Milestone to 4.1.1.
Ok for trunk and the 4.1 branch?
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from aldot at gcc dot gnu dot org 2006-05-21 13:10 ---
Subject: Bug 25776
Author: aldot
Date: Sun May 21 13:10:37 2006
New Revision: 113952
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113952
Log:
ACKed by Jan Hubicka in
--- Comment #1 from pault at gcc dot gnu dot org 2006-05-21 13:49 ---
Dale,
This looks like a library problem. Jerry committed a change that might have
required a completely clean tree to build.
I had no trouble with the trunk of two hours ago on FC5/Athlon.
Paul
--
--- Comment #7 from pault at gcc dot gnu dot org 2006-05-21 13:59 ---
Created an attachment (id=11491)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11491action=view)
Patch for this PR and PR27155
This is a belt-and-braces fix that uses memcpy to effect the transfer. I will
look
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:02
---
Unless we have some more information about this one, I'd like to close it
because it's most likely to be a timeout error than a real problem in the code.
Especially if it only fails at -O0, while being a library
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:03
---
Confirmed. I don't understand why, though. I'll try it harder when I have some
leisure time.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:05
---
Confirmed. I think that having a io/io.h file instead of having all prototypes
in libgfortran.h is fundamentally a bad idea, especially since things are now
spread all around the libgfortran directory.
--
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:11
---
Yes, this is confirmed. I'm not sure what is the less dirty way to make the
warnings disappear (and not fix the code, which is, as Andrew said, expected
not to work well on 64bits platforms).
--
fxcoudert at
The source code:
module aha
contains
subroutine aa
write(*,*) 'AA'
end subroutine aa
subroutine aa
write(*,*) 'BB'
end subroutine aa
end module
causes an internal error:
Driving: gfortran -v -save-temps double_routine.f90 -lgfortranbegin -lgfortran
Using built-in specs.
Target:
As discussed in this thread:
URL:http://gcc.gnu.org/ml/gcc-help/2005-12/msg00173.html
Many GNU/Linux distributions (such as Debian, Ubuntu and RedHat) are planning
to prohibit executable stacks completely, regardless of the presence of the
executable stack flag. At the moment, GCC produces
Unfortunately I have not succeeded in reproducing this error in a small
program.
The error messages are:
/bin/sh ../../libtool --tag=F77 --mode=link gfortran -I../../include -g -O2
-o x01f.exe x01f.o ../../src/libplplotd.la
../../bindings/f77/libplplotf77cd.la
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-21 15:13 ---
Subject: Bug 27671
Author: kazu
Date: Sun May 21 15:13:36 2006
New Revision: 113955
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113955
Log:
gcc/
PR rtl-optimization/27671
* simplify-rtx.c
--- Comment #8 from kazu at gcc dot gnu dot org 2006-05-21 15:16 ---
Subject: Bug 26622
Author: kazu
Date: Sun May 21 15:16:19 2006
New Revision: 113956
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113956
Log:
gcc/
PR tree-optimization/26622.
* fold-const.c
--- Comment #5 from kazu at gcc dot gnu dot org 2006-05-21 15:17 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from kazu at gcc dot gnu dot org 2006-05-21 15:17 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 15:53 ---
Actually this is done already when closing as a dup.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27699
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-21
15:57 ---
Subject: Re: FAIL: gfortran.dg/secnds.f -O0 execution test
I now think that this comment was likely correct.
This test can sometimes fail if you have a lot of background tasks running.
I found
--- Comment #1 from kargl at gcc dot gnu dot org 2006-05-21 16:01 ---
Arjen,
There appears to be something strange with your report. The Reported Against
field in bugzilla shows 4.2.0. But, the verbose output shows that you are
linking against a 4.1.0-20050522 libgfortran. Can you
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 16:01 ---
There is a bug in the Redhat's kernel for FC5 that causes the trampoline to
fail, someone should report this to them.
This is not a bug in GCC but with your distro changing the rules that are
always used.
--
--- Comment #1 from kargl at gcc dot gnu dot org 2006-05-21 16:03 ---
The problem occurs on i386-*-freebsd
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-21 16:09
---
Only fixed on the trunk so reopening as this is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
Known to work|3.4.3 |3.4.3 4.2.0
--- Comment #2 from kargl at gcc dot gnu dot org 2006-05-21 16:14 ---
Bernhard,
Your patch only addresses one aspect of the problem.
Consider
function _foo
entry _bar
end function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27698
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 16:15 ---
This is also rejects valid with -pedantic-errors.
I don't understand what is correct here so I am not going to confirm it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-21 16:18 ---
This is interesting, I cannot reproduce this with a cross compiler to
alphaev68-unknown-linux-gnu from powerpc-darwin.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 16:22 ---
Oh, it works the other way in that the CC on the bug which is still opened are
transfered over to the bug which is closed now.
Anyways this should be reported upstream so closing as will not fix.
--
pinskia at
The following should not produce a runtime error.
OPEN(8, FORM = 'unformatted', STATUS = 'scratch')
OPEN(8, FORM = 'unformatted', STATUS = 'scratch')
end
There may be other combinations of arguments to open that should not error,
See the following thread:
FAIL: gcc.dg/sibcall-7.c execution test
appeared on ia64-hp-hpux11.23 (both ilp32 and lp64) when the test was added on
both mainline and 4.1 branch; gcc-testresults shows it also on ia64-linux. I
don't know whether this is a target bug (i.e. the test should pass) or a
testsuite bug (i.e. it
--- Comment #8 from falk at debian dot org 2006-05-21 16:34 ---
(In reply to comment #7)
This is interesting, I cannot reproduce this with a cross compiler to
alphaev68-unknown-linux-gnu from powerpc-darwin.
Hrm :-(. Can anybody try a cross-compiler on i386 with valgrind?
--
FAIL: gcc.dg/pr27095.c scan-assembler-not (?n)strlen(.*\n)+.*strlen
appeared on HP-UX targets when the test was added. These targets explicitly
import external symbols used, so on such targets the test should test for
exactly two appearances of strlen instead of one.
--
Summary:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 16:36 ---
Confirmed. Darwin has the same issue. It was xfailed there.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from schwab at suse dot de 2006-05-21 16:40 ---
It is a testsuite bug. The problem is that on ia64 the call frame is allocated
on the register stack, not on the normal stack. Thus the recursive call to
recurser_void does not change the stack pointer.
--
schwab at
FAIL: g++.dg/tree-ssa/ivopts-1.C scan-tree-dump-not x\[5\]
FAIL: g++.dg/tree-ssa/ivopts-1.C scan-tree-dump-not offset: -4B
appeared on mainline on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11 when the
test was added.
--
Summary: g++.dg/tree-ssa/ivopts-1.C fails
Product:
FAIL: gcc.dg/tree-ssa/ssa-fre-4.c scan-tree-dump Replaced \(int\) f_.*with D
appeared on mainline on ia64-hp-hpux11.23 when the test was added.
gcc-testresults shows it also failing on several other targets (e.g.
ia64-linux, PowerPC, ARM).
--
Summary: gcc.dg/tree-ssa/ssa-fre-4.c
--- Comment #8 from hjl at lucon dot org 2006-05-21 16:57 ---
The proposed patch works Linux/ia64:
http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01188.html
The visual inspection shows memcpy is used instead of ld8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-05-21 16:58 ---
Formerly passed (PASS in revision 113624, FAIL in revision 113643), so a
regression.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mark at codesourcery dot com 2006-05-21 17:07 ---
Subject: Re: install failure due to unconditional invocation
of makeinfo for treelang.texi
aldot at gcc dot gnu dot org wrote:
--- Comment #5 from aldot at gcc dot gnu dot org 2006-05-21 12:16 ---
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-05-21 17:24
---
Subject: Bug 27210
Author: mmitchel
Date: Sun May 21 17:23:59 2006
New Revision: 113958
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113958
Log:
PR c++/27210
* cp-tree.h (cp_save_expr):
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-05-21 17:27
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hjl at lucon dot org 2006-05-21 17:42 ---
I have verified that the proposed patch fixes the C++ run-time problem on
Linux/x86, Linux/x86-64 and Linux/ia64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
--- Comment #7 from aldot at gcc dot gnu dot org 2006-05-21 17:46 ---
Wouldn't it be better just to modify gcc/Makefile.in to do:
ifneq($(BUILD_INFO),)
info: $(INFOFILES) lang.info @GENINSRC@ srcinfo lang.srcinfo
else
info:
fi
Then, in the subdirectory Makefiles we can avoid
--- Comment #8 from mark at codesourcery dot com 2006-05-21 17:58 ---
Subject: Re: install failure due to unconditional invocation
of makeinfo for treelang.texi
aldot at gcc dot gnu dot org wrote:
--- Comment #7 from aldot at gcc dot gnu dot org 2006-05-21 17:46 ---
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-21 18:02
---
I actually got time to test it last night.
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01065.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from patchapp at dberlin dot org 2006-05-21 18:03 ---
Subject: Bug number PR C++/27592
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/2006-05/msg01065.html
--
--
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
The code below causes gfortran to internal error when compiled as follows:
gfortran -c Elements.F90
gfortran -c Global_Numbering.F90
In file Global_Numbering.F90:9
end module global_numbering
1
Internal Error at (1):
find_array_spec(): Component not found
This is
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #9 from aldot at gcc dot gnu dot org 2006-05-21 20:11 ---
Your original patch is OK for 4.1 -- but I would like the fix I
suggested for 4.2. Also, we don't like to fix a problem on a release
branch without also having a fix in mainline.
Therefore, would you please
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-05-21 20:13
---
(In reply to comment #10)
Evaluation of Steven's patch should occur after 4.1 is branched.
Any progress on this, it has been over 3 months since that was written.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-05-21 20:14
---
Any news on this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 20:19 ---
Any news on this one? Shouldn't we have better autoconf for libgomp to dect
the case where SYS_futex does not exist?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26175
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-05-21 20:21
---
Any news on this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 20:22 ---
Any thoughts on this one? It seems like someone connected with the OpenMP
project should document these.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26237
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 20:23 ---
Jeff any thoughts about this bug since it was caused by your patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26251
--- Comment #2 from subdino2004 at yahoo dot fr 2006-05-21 20:25 ---
(In reply to comment #1)
This is not a bug in GCC but with your distro changing the rules that are
always used.
Why should being unable to use local functions be an acceptable side-effect of
prohibiting executable
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 20:27 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 20:27 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from pcarlini at suse dot de 2006-05-21 20:28 ---
Yes, the audit trail doesn't say that in private mail with Loren we agreed that
for now we only want to minimally take into account --enable-threads, that is
exploit the __GTHREADS macro, consistently with other parts of
--- Comment #13 from pcarlini at suse dot de 2006-05-21 20:30 ---
No news about this one. Frankly, since x86-* would not benefit in any way, I
consider the work low priority.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-21 20:32 ---
yes but you should report the bug to the distros that change the rules and let
them work out a solution instead of having the FSF GCC fix their bug.
Anyways Ada needs trampolines. Also it is harder to use mmap and
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-05-21 20:33
---
(In reply to comment #13)
No news about this one. Frankly, since x86-* would not benefit in any way, I
consider the work low priority.
What about x86_64 or even PowerPC64 both of which are becoming more popular
--- Comment #15 from pcarlini at suse dot de 2006-05-21 20:36 ---
(In reply to comment #14)
(In reply to comment #13)
No news about this one. Frankly, since x86-* would not benefit in any way, I
consider the work low priority.
What about x86_64
Of course by x86-* I meant to
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-21 20:37
---
Why is this code invalid? (the keywork ice-on-invalid-code is set)
No error is reported with Sun, Intel and g95.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-21 20:48 ---
Fixed by:
http://gcc.gnu.org/ml/gcc-cvs/2006-05/msg00519.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-21 20:49
---
Proposed patch (wording from the g95 error message). With that patch, compiling
the testcase is a bit noisy (additional errors after the first error message),
I'll try to find a cleaner solution.
Index:
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-05-21 20:49
---
Subject: Bug 26855
Author: pinskia
Date: Sun May 21 20:48:30 2006
New Revision: 113960
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113960
Log:
Add forgot changelog:
+2006-05-19 Daniel Berlin [EMAIL
--- Comment #50 from pinskia at gcc dot gnu dot org 2006-05-21 20:51
---
Any news on this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-21 20:53 ---
Any news on this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 21:11 ---
Janis, could you do a regression hunt on this bug, using the testcase in
comment #1?
Thanks,
Andrew Pinski
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 21:24 ---
Janis, could you regression hunt on this bug?
Thanks,
Andrew Pinski
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 21:26 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from patchapp at dberlin dot org 2006-05-21 21:35 ---
Subject: Bug number PR27613
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/2006-05/msg01044.html
--
--- Comment #19 from patchapp at dberlin dot org 2006-05-21 21:35 ---
Subject: Bug number PR27155
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/2006-05/msg01055.html
--
1 - 100 of 113 matches
Mail list logo
