--- Comment #5 from krebbel1 at de dot ibm dot com 2005-11-04 08:02 ---
The problem occurs when a landing pad is optimized away but
the special code in s390_regs_ever_clobbered insists on saving all eh
registers. The special code in that function exists because the eh regs
may be read
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:29
---
Subject: Bug 18452
Author: fxcoudert
Date: Fri Nov 4 08:29:16 2005
New Revision: 106483
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106483
Log:
PR fortran/18452
*
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:31
---
Hurray, hurray, this bug is fixed! Now, could we get libgfortran building with
-Werror? :)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:44
---
Subject: Bug 22298
Author: fxcoudert
Date: Fri Nov 4 08:44:29 2005
New Revision: 106484
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106484
Log:
PR libfortran/22298
* runtime/main.c
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:49
---
Subject: Bug 22298
Author: fxcoudert
Date: Fri Nov 4 08:49:18 2005
New Revision: 106485
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106485
Log:
PR libfortran/22298
* runtime/main.c
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:50
---
Fixed on both 4.0 and 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from mlynarik at decef dot elf dot stuba dot sk 2005-11-04
09:03 ---
Created an attachment (id=10141)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10141action=view)
Assembler source of comiled example2-32.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24634
--- Comment #6 from mlynarik at decef dot elf dot stuba dot sk 2005-11-04
09:04 ---
Created an attachment (id=10142)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10142action=view)
Assembler source from compilation of example2-64.c
--
A simple loop:
void foo (int *a, int *b)
{
int i;
for (i = 0; i 4; i++)
b[i] = a[i];
}
gets compiled to (gcc -O2 -fomit-frame-pointer):
pushl %ebx
movl$1, %edx index starts with 1
movl8(%esp), %ebx
movl12(%esp), %ecx
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-04 09:11
---
Patch proposed: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00244.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from mlynarik at decef dot elf dot stuba dot sk 2005-11-04
09:12 ---
We have created the assembler sources with the parameters -dA. You can see that
there are no differences between the 32bit and 64bit versions except the length
of the fields (4bytes and 8bytes). So I
--- Comment #9 from dannysmith at users dot sourceforge dot net 2005-11-04
09:15 ---
Hello,
mingw has an implementation of _IO_ldtoa() and _IO_ldtostr(), based on Stephen
Moshier's ioldoubl package, that could be used. Currently, the ldtoa function
is not exposed, but there is no
--- Comment #1 from uros at kss-loka dot si 2005-11-04 09:20 ---
-fno-ivopts produces:
movl16(%esp), %edi
movl20(%esp), %esi
xorl%ebx, %ebx
movl$4, %ecx index starts with 1
.L2:
leal(%ebx,%ebx), %edx
movl
--- Comment #4 from rsandifo at gcc dot gnu dot org 2005-11-04 09:22
---
I think TImode has to be a workable mode for IRIX 6. Long double is TFmode,
and it would certainly seem odd to support TImode and not TFmode. (I seem to
remember the s390 folks having to add TImode support
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2005-11-04 09:27
---
(In reply to comment #9)
Would a ldtoa alternative to sprintf be acceptable?
Yes, it would be very nice to have and we could use it in gfortran. Please keep
us (bugzilla) posted of new developments on this.
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-11-04 09:46 ---
Subject: Bug 22487
Author: rguenth
Date: Fri Nov 4 09:46:43 2005
New Revision: 106487
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106487
Log:
2005-11-04 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-11-04 09:47 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #20 from rakdver at gcc dot gnu dot org 2005-11-04 10:04
---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00246.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rakdver at gcc dot gnu dot org 2005-11-04 10:35 ---
There are two reasons we do not produce the code as in the comment #1:
1) This would require reversing the loop, which is currently implemented in
mainline only in old loop optimizer, in a very weak fashion. More
--- Comment #8 from jakub at gcc dot gnu dot org 2005-11-04 10:52 ---
Sorry, haven't touched this for a while.
Testing a new patch, there have been other problems in noce_process_if_block.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23567
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
This ICE occured during a compile of libfloat with mainline.
Attached is a delta reduced test that produces the ICE when compiled with -O2.
softfloat/bits64/softfloat.c: In function float128_rem:
softfloat/bits64/softfloat.c:4483: internal compiler error: in
compare_name_with_value, at
--- Comment #1 from pluto at agmk dot net 2005-11-04 11:06 ---
what about PR21764 (linked in PR19664)?
duplication?
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #8 from christian dot joensson at gmail dot com 2005-11-04
11:24 ---
Just a ping here... are there any progress on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20753
The following testcase causes an ICE:
==
templatetypename struct A
{
typedef int X;
static const int i = 0;
};
templatetypename struct B
{
typedef typename Achar[AB::i]::X Y;
templatetypename T B(T, Y);
};
Bint b(0,0);
The following invalid code snippet (which is similar to PR 22257)
causes an ICE on x86-64:
=
struct A
{
int i, j;
A : i(), j() {}
};
=
bug.cc:4: error: 'A::i' cannot appear in a constant-expression
bug.cc:4: error: a function call
--- Comment #3 from worm at arrakis dot es 2005-11-04 12:13 ---
Created an attachment (id=10143)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10143action=view)
This one triggers the bug
The new file definitely triggers the problem with statement reordering if
compiled with (-O2),
--- Comment #3 from uros at kss-loka dot si 2005-11-04 12:19 ---
Following patch to ix86_address_cost:
--- i386.c (revision 106482)
+++ i386.c (working copy)
@@ -5396,8 +5396,12 @@
if (parts.index GET_CODE (parts.index) == SUBREG)
parts.index = SUBREG_REG
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-04 13:05 ---
This is a dup of bug 21764 as far as I can see.
*** This bug has been marked as a duplicate of 21764 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-04 13:05 ---
*** Bug 24668 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-04 13:10 ---
What you are seing is either an assmebler bug or just dwarfdump not supporting
relocations for 64bit. I want to say the latter. This is not a GCC bug.
--
pinskia at gcc dot gnu dot org changed:
What
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Keywords|
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 13:16 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 13:19 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-04 13:25 ---
I still cannot reproduce it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
CC|dnovillo at redhat dot com |
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 13:28 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from worm at arrakis dot es 2005-11-04 13:35 ---
Sorry for my stupidity -- the jet-lag after a long trip
seems to affect me --.
Remove the volatile statement from the arguments list
of L1foo.
Then the assignments to the variable V1 are moved after
the call to cl_throw()
--- Comment #4 from rakdver at gcc dot gnu dot org 2005-11-04 13:39 ---
Nevertheless, the fact that boolean_true_node has overflow flag set is wrong,
this should not happen -- shared constants should not be modified.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-04 14:02 ---
This happens in c-typeck.c:build_c_cast:
value = convert (type, value);
/* Ignore any integer overflow caused by the cast. */
if (TREE_CODE (value) == INTEGER_CST)
{
/* If
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-04 14:05 ---
Removing volatile will change the semantics of the program and therefor not a
bug. GCC docs mention with (I cannot find right now as I am at a Kiosk and it
is hard to find anything) longjmp, volatile is required.
Hi,
This bug seems not very different from bug #20244 but happens at a different
line in the same function.
during compilation of my code I get the following error mesage:
[EMAIL PROTECTED] 5common]$ /usr/local/bin/gfortran -c
../../../src/5common/funcofrho_tfw.F90
--- Comment #2 from dnovillo at gcc dot gnu dot org 2005-11-04 14:19
---
testing fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 14:26 ---
It is the same as PR 20244, the line number changed because fold-const.c has
changed and addded code.
*** This bug has been marked as a duplicate of 20244 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-04 14:26 ---
*** Bug 24673 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-04
14:27 ---
Subject: Re: ACATS ce3810b segfaults at runtime
--- Comment #8 from christian dot joensson at gmail dot com 2005-11-04
11:24 ---
Just a ping here... are there any progress on this?
No, I
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-04 14:33 ---
Hmm, old (C) style casts are weird, IIRC they act as either a static_cast, a
reinterpret_cast, or a const_cast. In this case they are acting like a
const_cast which is what is normally goes and gets rid of a
--- Comment #5 from matz at suse dot de 2005-11-04 14:45 ---
While 4.0 had this fixed, trunk still uses the 'mt' allocator by default
on linux, and hence is incompatible with 3.4 and 4.0 by default. Is that
really intended, or shouldn't also trunk default back to the 'new' allocator?
2005/11/3, Daniel Jacobowitz [EMAIL PROTECTED]:
On Thu, Nov 03, 2005 at 02:15:27PM -0700, Shaun Jackman wrote:
When an object file is compiled by arm-elf-gcc 4.0.2, nm -S 2.16.*
isn't printing the size of static variables. I'd very much appreciate
a fix or workaround, if one is out there.
--- Comment #4 from anglade at gmail dot com 2005-11-04 14:54 ---
Hi all,
Looking at the examples of failure due to this bug, I've observed that they are
due to user defined datatype. The function fold_convert seems to handle only
intrinsic datatypes while the examples were using user
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-04 14:58 ---
(In reply to comment #4)
Unfortunately I'm not a gcc expert and really don't know how this should be
bug-fixed.
The way this bug needs to be fixed is one of the following:
1. the types generated need to be in the
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-04 14:59 ---
(In reply to comment #5)
Oh and one more thing, the use of fold_convert is not the incorrect thing to do
here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
Reproducable: Very easy to reproduce with the sample code
application provided. PLEASE COMPILE the code with -O2 option.
Product: GCC for ARMV5L
Component: C
Version: 3.2.1. (Reported also in ARM Linux community to
be see with gcc 3.3.4, gcc 3.4.2)
Host Platform: x86 Linux 2.4.x
Target
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 15:08 ---
3.2.1 is an old compiler and the 3.2 series is no longer being updated, can you
try either a 3.3.6 (note the 3.3 series is not being updated either) or a 3.4.4
or a 4.0.2 GCC?
--
pinskia at gcc dot gnu dot org
--- Comment #5 from tromey at gcc dot gnu dot org 2005-11-04 15:08 ---
Subject: Bug 14358
Author: tromey
Date: Fri Nov 4 15:08:18 2005
New Revision: 106490
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106490
Log:
PR libgcj/14358, libgcj/24552:
*
--- Comment #6 from tromey at gcc dot gnu dot org 2005-11-04 15:09 ---
Fix is on 4.0 branch and trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tromey at gcc dot gnu dot org 2005-11-04 15:09 ---
Fix is on 4.0 branch and trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-04 15:24 ---
Woops, that should have been ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-04 15:24 ---
Woops, that should have been ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-04 15:25 ---
Closed as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-04 15:28 ---
Here is a testcase which is better representive of the issue (compile with
-std=c99 -pedantic-errors):
#include stdbool.h
int
main (int argc, char **argv)
{
if ((bool)((1527719483 + 1477819644))) {
}
return
--- Comment #7 from anglade at gmail dot com 2005-11-04 15:31 ---
I've simplified to it's (almost) simplest expression the test case:
module mtyp
type t1
integer::a
end type t1
end module mtyp
module atest
use mtyp
type(t1)::ze
contains
subroutine test(ze_in )
use
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-04 15:32 ---
Fails on the mainline for me.
t.c: In function g:
t.c:23: internal compiler error: in move_for_stack_reg, at reg-stack.c:1062
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #5 from manfred99 at gmx dot ch 2005-11-04 15:32 ---
1) There is an easy way to circumvent the ICE:
if you add an explicit type conversion for IMAX, such as in
REAL:: AUX1(25000+INT(0.82*float(IMAX)))
the ICE goes away and gfortran compiles it successfully and
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-11-04 15:33
---
Still fails on the mainline:
t.c: In function main:
t.c:15: internal compiler error: in assign_stack_temp_for_type, at
function.c:595
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-04 15:36 ---
Since this is only a missed optimization, closing as fixed for 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-11-04 15:37
---
Since this is only a missed optimization (and this was my bug) closing as fixed
for 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from anlauf at gmx dot de 2005-11-04 15:56 ---
(In reply to comment #2)
This is invalid code, INT is not allowed in a specification expression.
I'm not a language lawyer, but if I read it correctly, then
INT is a standard intrinsic function and thus allowed in a
--- Comment #14 from ian at airs dot com 2005-11-04 16:09 ---
gcc is free to copy non-volatile variables. It does this in many places and
for many reasons, particularly in the new SSA optimizers in 4.0 and later. I
don't know the details of where it decided to copy the register in
--- Comment #5 from bkoz at gcc dot gnu dot org 2005-11-04 17:05 ---
In addition to the current ability to put visibility attributes on file and
class scope, the ability to put visibility attributes on namespace scope is
desired.
The syntax is straight forward extension of existing
--- Comment #3 from bkoz at gcc dot gnu dot org 2005-11-04 17:06 ---
Agh. Sorry, I had not realized that I'd filed this six months ago.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24668
--- Comment #4 from mesmith dot 15507218 at bloglines dot com 2005-11-04
17:22 ---
Created an attachment (id=10145)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10145action=view)
Source in gcc/fortran from FC4 4.0.1 with patches
--
--- Comment #5 from mesmith dot 15507218 at bloglines dot com 2005-11-04
17:24 ---
Created an attachment (id=10146)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10146action=view)
Source in gcc/libgfortran from FC4 gcc 4.0.1 with patches
--
--- Comment #6 from mesmith dot 15507218 at bloglines dot com 2005-11-04
17:30 ---
The two attached files will change the behavior so that included files are
processed as described in comment #2. I have not checked the results
extensively.
--
mesmith dot 15507218 at bloglines dot
--- Comment #15 from bergner at vnet dot ibm dot com 2005-11-04 17:38
---
For completeness, here is a minimal test case that shows the problem we are
having:
[EMAIL PROTECTED]:~/olaf/PR24644-4 cat bar.c
register struct paca_struct * local_paca asm(r13);
struct paca_struct { volatile
--- Comment #6 from bkoz at gcc dot gnu dot org 2005-11-04 17:41 ---
In general, we make no claims as to ABI compliance wrt development/trunk
versions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-04 17:55
---
This was never confirmed with this exact error, and I've done quite some
testing/debuging and did not experience that particular bug. I think this bug
was superseded by PR21547, which I am currently fixing.
--- Comment #3 from fang at csl dot cornell dot edu 2005-11-04 17:56
---
Am I correct in expecting that const_cast... should pass -Wcast-qual without
warning? That's the way I use it (in the few and rare cases that demand it)
and it's met my expectations thus far. I'm kind of
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-04 18:00
---
(In reply to comment #15)
This looks like gcc thinks r13 will be trashed by the call to foo() so it
copies it to a non volatile register for use after the call. Strange that
this
didn't happen before the
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-04 18:06
---
Variable: local_paca, UID 1270, struct paca_struct *, is global, call
clobbered, default def: local_paca_1
But we get:
# TMT.6_8 = V_MAY_DEF TMT.6_7;
# VUSE local_paca_1;
foo ();
I don't understand
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-11-04 18:07
---
That testcase shows that we have a big problem, as local_paca (aka r13) should
be marked as call clobbered.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-04 18:21
---
The problem is that ipa-static is looking at the variable because the front-end
marked it as a static variable. Daniel Berlin has sugggested a fix, and I will
test it with the reduced test case and then if you
--- Comment #20 from pinskia at gcc dot gnu dot org 2005-11-04 18:33
---
Created an attachment (id=10147)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10147action=view)
Patch to try
This patch should fix the issue in the reduced testcase but I don't know if it
fixes it fully,
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #21 from olh at suse dot de 2005-11-04 19:15 ---
yes, this patch helps. tested with r106499.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
--- Comment #23 from laurent at guerby dot net 2005-11-04 19:29 ---
Add mips and mips64, for reference, workaround patch from Andreas Schwab here:
http://gcc.gnu.org/ml/gcc/2005-11/msg00239.html
Index: ipa-utils.c
===
---
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-11-04 19:50
---
With array size=2000, timings are:
g77: 2.30 s
gfortran-4.0 (without commited patch): 17.0
gfortran-mainline: 2.66 s
intel: 3.15 s
I think we can close this PR.
--
fxcoudert at gcc dot gnu dot org
--- Comment #17 from dnovillo at gcc dot gnu dot org 2005-11-04 19:56
---
Subject: Bug 24627
Author: dnovillo
Date: Fri Nov 4 19:56:28 2005
New Revision: 106502
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106502
Log:
PR 24627
* tree-ssa-dce.c (pass_dce,
--- Comment #18 from dnovillo at gcc dot gnu dot org 2005-11-04 19:57
---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00239.html
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from law at redhat dot com 2005-11-04 20:10 ---
Subject: Re: [4.1 Regression] jump threading
causing excessive code duplication
On Mon, 2005-10-31 at 18:56 -0700, Jeffrey A Law wrote:
On Mon, 2005-10-31 at 03:43 +, mmitchel at gcc dot gnu dot org
wrote:
--- Comment #10 from law at redhat dot com 2005-11-04 20:11 ---
Band-aid applied for 4.1; Steven's prototype patch may be a better solution as
it only simulates those statements which affect the conditional and doesn't
count those statements (they're likely going to disappear in
--- Comment #2 from janis at gcc dot gnu dot org 2005-11-04 20:19 ---
A regression hunt identified the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=89280
r89280 | rth | 2004-10-19 17:24:46 + (Tue, 19 Oct 2004) | 4 lines
PR middle-end/17885
* tree.c
--- Comment #4 from janis at gcc dot gnu dot org 2005-11-04 21:18 ---
A regression test identified the following patch to change handling of
C-style casts for PR c++/14035:
http://gcc.gnu.org/viewcvs?view=revrev=89300
r89300 | mmitchel | 2004-10-19 23:24:20 + (Tue, 19 Oct 2004) |
--- Comment #5 from hp at gcc dot gnu dot org 2005-11-04 21:20 ---
Subject: Bug 23424
Author: hp
Date: Fri Nov 4 21:20:24 2005
New Revision: 106506
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106506
Log:
PR target/23424
* config/cris/predicates.md
--- Comment #22 from pinskia at gcc dot gnu dot org 2005-11-04 21:21
---
Hmm, my patch is not fully correct but the C++ front-end gets this correct.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hp at gcc dot gnu dot org 2005-11-04 21:24 ---
Subject: Bug 23424
Author: hp
Date: Fri Nov 4 21:24:20 2005
New Revision: 106507
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106507
Log:
PR target/23424
* gcc.dg/torture/pr23424-1.c: New test.
--- Comment #3 from kargl at gcc dot gnu dot org 2005-11-04 22:18 ---
Subject: Bug 24636
Author: kargl
Date: Fri Nov 4 22:18:22 2005
New Revision: 106509
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106509
Log:
PR fortran/24636
* match.c (gfc_match_stopcode):
The following on screen description happened:
jacin04 PHITS/src gcc -v -save-temps -O4 -c mars00.f
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.1/configure --prefix=/usr/common/usg/gcc/4.0.1
--with-mpfr-dir=/usr/common/usg/gmp/src/gmp-4.1.4/mpfr/
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-04 22:56 ---
For the record, Jakub has apparently dropped this bug from his list to put this
bug back into unassigned state.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 22:58 ---
Fixed in 4.0.2 and above at least. Most likely a dup of bug 15966.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 128 matches
Mail list logo
