--- Comment #32 from gdr at cs dot tamu dot edu 2008-01-07 08:00 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| --- Comment #31 from mark at codesourcery dot com
--- Comment #33 from gdr at cs dot tamu dot edu 2008-01-07 08:10 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Subject: Re: [4.2/4.3 regression] ICE with incompatible
--- Comment #18 from pault at gcc dot gnu dot org 2008-01-07 08:15 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
The following testcase fails for me when run with -fipa-struct-reorg:
#include stdlib.h
typedef struct baba
{
int a;
int b[10];
} type_struct;
type_struct *str1;
int main()
{
int i;
str1 = malloc (10 * sizeof (type_struct));
for (i=0; i=9; i++)
str1[i].a = str1[i].b[0];
--- Comment #1 from alond at il dot ibm dot com 2008-01-07 09:47 ---
(In reply to comment #0)
When looking into try2.c.051i.ipa_struct_reorg, there is something strange like
10=40 there:
bb 2:
D.1885_2 = malloc (440);
str1.0_3 = (struct type_struct *) D.1885_2;
10 = 40;
--- Comment #7 from jakub at gcc dot gnu dot org 2008-01-07 09:47 ---
Can anyone who can reproduce this please post assembly of 2801-4.c at -O1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34622
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-07 10:04 ---
Update your gmp, this was fixed in 4.2.2.
Well, if you were right, then gnu99 and gnu89 would have the same behavior,
but
they don't:
gnu99 behaves like c99.
--
--- Comment #8 from dominiq at lps dot ens dot fr 2008-01-07 10:06 ---
.cstring
LC0:
.ascii \0
.space 1
.text
.globl _foo
_foo:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
call___i686.get_pc_thunk.cx
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-07 10:14 ---
You should be more specific regarding the options you used. Confirmed with
-O -fipa-struct-reorg -fipa-type-escape -fwhole-program.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from manu at gcc dot gnu dot org 2008-01-07 10:40 ---
@Andrew,
I would like to fix this before GCC 4.3 is released but I just don't know how.
Any hints?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34389
--- Comment #16 from paolo at gcc dot gnu dot org 2008-01-07 11:11 ---
Subject: Bug 34680
Author: paolo
Date: Mon Jan 7 11:11:02 2008
New Revision: 131372
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131372
Log:
2008-01-07 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #17 from pcarlini at suse dot de 2008-01-07 11:12 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|---
--- Comment #18 from pcarlini at suse dot de 2008-01-07 11:14 ---
.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-07 12:11 ---
Created an attachment (id=14893)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14893action=view)
patch for copyprop in the simple case
Produced while working on PR34683 (though doesn't help that
--- Comment #5 from ubizjak at gmail dot com 2008-01-07 12:19 ---
Confirmed by following testcase:
--cut here--
#include stdio.h
void __attribute__((noinline))
dtime (void)
{
__asm__ __volatile__ ( : : : memory);
}
double sa, sb, sc, sd;
double one, two, four, five;
double piref,
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from alond at il dot ibm dot com 2008-01-07 13:01 ---
I have tested the following patch. It fixes the problem. All struct-reorg tests
has also passed on my machine.
It looks like the input to malloc was not calculated correctly in case the size
of the structure is not
--- Comment #3 from pault at gcc dot gnu dot org 2008-01-07 13:06 ---
Since I have submitted the patch, I should take it on!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from olga at gcc dot gnu dot org 2008-01-07 13:11 ---
(In reply to comment #3)
Ok to submit this patch?
It looks good. Please bootstrap and submit along with the testcase.
Olga
Alon
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34701
--- Comment #10 from asteinarson at gmail dot com 2008-01-07 13:24 ---
(In reply to comment #9)
(In reply to comment #8)
Subject: Bug 34152
* libsupc++/eh_personality.cc (PERSONALITY_FUNCTION): Check
_GLIBCXX_HAVE_GETIPINFO instead of HAVE_GETIPINFO.
I've
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-01-07 13:25
---
Most of the operand scanner time is caused by cfg_cleanup:
tree CFG cleanup : 93.71 (79%) usr 1.16 (54%) sys 95.03 (78%) wall
474427 kB (28%) ggc
globbing CFG cleanup (and operand scanner) time to the
--- Comment #28 from olga at gcc dot gnu dot org 2008-01-07 13:38 ---
(In reply to comment #27)
Would you please try the Alon's patch for PR 34701.
I am not sure but maybe it's related.
Thank you,
Olga
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
--- Comment #9 from olga at gcc dot gnu dot org 2008-01-07 13:48 ---
(In reply to comment #8)
Would you please try the Alon's patch from PR 34701?
I am not sure but may be it's related.
Thank you,
Olga
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
--- Comment #6 from ubizjak at gmail dot com 2008-01-07 14:02 ---
Patch in testing.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu dot
|
--- Comment #7 from ubizjak at gmail dot com 2008-01-07 14:09 ---
Patched gcc:
387:
FLOPS C Program (Double Precision), V2.0 18 Dec 1992
Module ErrorRunTime MFLOPS
(usec)
1 -8.1208e-11 0.0128 1094.6170
2
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-01-07 14:32
---
-fno-tree-loop-optimize reduces compile-time of this testcase from 117s to 35s
with -O -fstrict-aliasing. try_unroll_loop_completely calls update_ssa, for
every loop unrolled, added by r98599, which seems to be
The following test
integer :: i, n
real :: x, y(10)
x =1.0
n = 10
do i = 1, n
y(i) = 1.0/x
x = 2.0*x
end do
print *, y
end
when compiled with -O -ffast-math -mrecip, gives
0.9994 0.4997 0.2499 0.1249
6.2463E-02 3.12499981E-02 1.56249991E-02
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-01-07 14:50
---
Subject: Bug 34683
Author: rguenth
Date: Mon Jan 7 14:49:36 2008
New Revision: 131375
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131375
Log:
2008-01-07 Richard Guenther [EMAIL PROTECTED]
PR
As reported on PR34702 I stumbled over expressions such as
IF ( FLOAT(NNP/NP).EQ.FLOAT(NNP)/XNP ) THEN
or
IF (RADIUS=X(N)/100.0 .AND. RADIUS=X(N+1)/100.0) EXIT
which can obviously be rearranged as
IF (XNP* FLOAT(NNP).EQ.FLOAT(NP*NNP) ) THEN
or
--- Comment #9 from jakub at gcc dot gnu dot org 2008-01-07 14:59 ---
Guess you want something like:
2008-01-07 Jakub Jelinek [EMAIL PROTECTED]
PR target/34622
* config/darwin.c (darwin_mergeable_string_section): Don't use
.cstring if int_size_in_bytes !=
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-01-07 15:08
---
Without the loop optimizer the profile looks like:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls s/call s/call name
It looks like a derived-type variable, containing an allocatable array and
a variable set to an initial value, picks some random number instead of the
initial value, unless it has the save attribute. The following piece of
code demonstrates the problem: the only difference between the first and
--- Comment #22 from rguenth at gcc dot gnu dot org 2008-01-07 15:56
---
A histogram over the number of VUSEs/VDEFs that are being sorted by sort_vuses
reveals:
180 2
281964 256
1498 4
that is, we call qsort 281964 times with 256 virtual operands in the VEC. Now,
--- Comment #11 from jakub at gcc dot gnu dot org 2008-01-07 16:06 ---
Subject: Bug 34152
Author: jakub
Date: Mon Jan 7 16:05:27 2008
New Revision: 131376
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131376
Log:
PR c++/34152
* libsupc++/eh_personality.cc
--- Comment #34 from mark at codesourcery dot com 2008-01-07 16:17 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with complex type conversion
gdr at cs dot tamu dot edu wrote:
| What's the likely change?
Ban implicit narrowing conversions, in the sense
--- Comment #10 from jakub at gcc dot gnu dot org 2008-01-07 16:18 ---
On the 2801-4.c testcase with this patch .cstring is no longer used,
instead
.const is, which is desirable, at least if Darwin mergeable string sections
work at least roughly similarly to ELF, and I've checked
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
--- Comment #1 from pault at gcc dot gnu dot org 2008-01-07 16:44 ---
I have a fix for this and PR34681. I was hoping to submit tonight but it now
looks like it will be tomorrow.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-07 16:45 ---
Subject: Bug 34672
Author: pault
Date: Mon Jan 7 16:44:43 2008
New Revision: 131377
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131377
Log:
2008-01-07 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-07 16:57 ---
-ffinite-math-only is not enoug - that only assumes input operands are never
Inf or Nan and results of operations in the source are not Inf or Nan. But
as you say you cannot guarantee that RADIUS * 100.0 does not
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-07 16:46 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-01-07 17:08
---
Zdenek, can you have a look if there is sth low-hanging with the tree level
loop unroller?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Based on PR 34683.
Richard writes there (text below slightly edited by me):
So, to sum up, the situation could be significantly improved by improving
the FE. Like I noticed for I/O statements, where I provided a patch -
that was not accepted - to share temporary variables created for the I/O
--- Comment #6 from tromey at gcc dot gnu dot org 2008-01-07 17:24 ---
Subject: Bug 30363
Author: tromey
Date: Mon Jan 7 17:23:40 2008
New Revision: 131379
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131379
Log:
libcpp
2008-01-07 Fred Fish [EMAIL PROTECTED]
PR
--- Comment #7 from tromey at gcc dot gnu dot org 2008-01-07 17:25 ---
Slightly modified version of this patch checked in on trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Based on PR 34683 and related to PR 34705.
Richard writes there (text is slightly edited by me):
The problem is we have loads of unpartitionable SFTs. The FE generated IL
causes the first alias pass to emit too conservative
alias info as well:
# VUSE MPT.5965_208230
D.6049_4652 =
--- Comment #10 from steven at gcc dot gnu dot org 2008-01-07 17:29 ---
Though the patch from the patch URL probably does not apply anymore to the
current trunk, it looks entirely reasonable IMHO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868
--- Comment #44 from steven at gcc dot gnu dot org 2008-01-07 17:34 ---
Hello world. Please, a status update.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2008-01-07 17:34 ---
(In reply to comment #0)
o arg;
This line calls the global operator
ostream operator (ostream, char*)
whereas this one
std::ostringstream::operator(arg);
clearly needs a member
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2007-04-30 11:52:08 |2008-01-07
--- Comment #10 from tom dot culliton at oracle dot com 2008-01-07 17:42
---
We've run afoul of this issue as well attempting to use gcc 4.1.1 and 4.1.2 on
this platform, and it means that G++ is essentially unusable for us. Not
following the IA64 ABI/Runtime Standard is a pretty
--- Comment #5 from krebbel at gcc dot gnu dot org 2008-01-07 17:28 ---
The (const_int 3148725999 [0xbbadbeef]) is accepted by legitimate_constant_p
since it is expected to end up in the literal pool. But in this case the
constant becomes part of a REG_EQUIV note of an insn moving the
I've been trying to build GNU compilers on
Mac OS X Version 10.4.11,
800MHz PowerPC G4
Memory 768 MB
This fails. I think this is due to the make/config thinking I've got
texinfo/gettext when I don't.
gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple
--- Comment #4 from mmitchel at gcc dot gnu dot org 2008-01-07 18:13
---
I still agree that we should fix this -- but it is worth noting that
value-initialization did not exist in C++98. I believe that the current G++
behavior conforms to the original C++98 specification.
Does anyone
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-07 18:24 ---
This is related to some work done in the past for auto-increment addressing
modes (even though there are no auto-inc/dec modes in the reporter's assembly).
See one of Joern's old patches:
--- Comment #11 from dominiq at lps dot ens dot fr 2008-01-07 18:31 ---
Subject: Re: [4.3 Regression]
gcc.c-torture/execute/2801-4.c fails at -O1 and above
Could somebody please bootstrap/regtest this on darwin native?
Seems to work on a quick test, but I have to regtest ~1
--- Comment #5 from crowl at google dot com 2008-01-07 18:58 ---
Subject: Re: [4.2/4.3 Regression] Default constructor fails to initialize
array members
Value initialization was in C++98 TC1 (2003) as a result of core issue 178.
--
--- Comment #5 from bagnara at cs dot unipr dot it 2008-01-07 19:20 ---
Indeed the testcase does not compile with GCC 4.3 (while compiling perfectly
with GCC 4.0, 4.1 and 4.2). For some reason, GCC 4.3 dislikes the
implementation of the STL that is shipped with previous versions. I
--- Comment #6 from bagnara at cs dot unipr dot it 2008-01-07 19:30 ---
Please, forget comment #5. Let me try again.
Indeed the testcase does not compile with GCC 4.3 (while compiling perfectly
with GCC 4.0, 4.1 and 4.2). For some reason, GCC 4.3 dislikes the
implementation of the
--- Comment #7 from bagnara at cs dot unipr dot it 2008-01-07 19:32 ---
Created an attachment (id=14894)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14894action=view)
New testcase showing the problem with GCC 4.3.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
--- Comment #8 from rootkit85 at yahoo dot it 2008-01-07 19:47 ---
Created an attachment (id=14895)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14895action=view)
minimal testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
--- Comment #9 from rootkit85 at yahoo dot it 2008-01-07 19:47 ---
Created an attachment (id=14896)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14896action=view)
minimal testcase, compiled with -mfpmath=387
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
--- Comment #10 from rootkit85 at yahoo dot it 2008-01-07 19:47 ---
Created an attachment (id=14897)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14897action=view)
minimal testcase, compiled with -mfpmath=sse
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
--- Comment #11 from rootkit85 at yahoo dot it 2008-01-07 19:49 ---
very very minimal testcase added
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-01-07 19:59 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-01-07 19:59 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from dominiq at lps dot ens dot fr 2008-01-07 20:03 ---
Subject: Re: [4.3 Regression]
gcc.c-torture/execute/2801-4.c fails at -O1 and above
The patch fix the problem on i686-apple-darwin9 32 and 64 bit modes without
regression on gcc testsuite.
BTW I never said
--- Comment #29 from dominiq at lps dot ens dot fr 2008-01-07 20:04 ---
Subject: Re: wo_prof_two_strs.c:56: internal compiler
error: in find_new_var_of_type, at ipa-struct-reorg.c:605
Would you please try the Alon's patch for PR 34701.
I did but the reported failures are still
--- Comment #12 from uros at gcc dot gnu dot org 2008-01-07 20:07 ---
Subject: Bug 34682
Author: uros
Date: Mon Jan 7 20:06:34 2008
New Revision: 131381
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131381
Log:
PR target/34682
* config/i386/i386.md (negmode2):
--- Comment #2 from tromey at gcc dot gnu dot org 2008-01-07 20:08 ---
I agree this is a bug.
I think this patch is insufficient. For best results I think that
libcpp and diagnostic.c should agree on whether the warnins being treated
as errors message has been emitted.
One way to do
--- Comment #13 from ubizjak at gmail dot com 2008-01-07 20:10 ---
Fixed in SVN.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2008-01-07 20:18 ---
Confirmed.
4.1 seems to have silently accepted this.
I will try to read the standard to figure out what is correct.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from v dot haisman at sh dot cvut dot cz 2008-01-07 20:47
---
This still fails in 4.3.0. Know to fail sorted and without duplicates should
read: 2.95.3 3.0.4 3.2.3 3.3.3 4.0.0 4.1.0 4.2.0 4.3.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5458
--- Comment #19 from paolo at gcc dot gnu dot org 2008-01-07 20:55 ---
Subject: Bug 34680
Author: paolo
Date: Mon Jan 7 20:54:49 2008
New Revision: 131382
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131382
Log:
2008-01-06 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from janis at gcc dot gnu dot org 2008-01-07 21:03 ---
Subject: Bug 34575
Author: janis
Date: Mon Jan 7 21:02:24 2008
New Revision: 131383
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131383
Log:
2008-01-07 Jack Howarth [EMAIL PROTECTED]
PR
openbabel doesn't build on ppc64-linux with 4.3 (works with 4.1), with
-mminimal-toc -O2 -fPIC .toc1 section overflows (is bigger than 64KB).
About 2/3 of .toc1 entries are as with 4.1 various pointers to .rodata.str1.8
(i.e. string literals), but newly there are over 3600 pointers into .text.
This patch
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00191.html
miscompiled 481.wrf in SPEC CPU 2006 on Linux/Intel64 with -O2 -ffast-math.
The resulting 481.wrf segfaulted.
--
Summary: [4.3 regression]: revision 131342 miscompiled 481.wrf on
Linux/Intel64
--- Comment #13 from jakub at gcc dot gnu dot org 2008-01-07 21:50 ---
Subject: Bug 34622
Author: jakub
Date: Mon Jan 7 21:49:27 2008
New Revision: 131386
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131386
Log:
PR target/34622
* config/darwin.c
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|i686-apple-darwin9 |
GCC host triplet|i686-apple-darwin9 |
GCC target
--- Comment #4 from jv244 at cam dot ac dot uk 2008-01-07 22:00 ---
timings have improved a lot with a recent gfortran, at least on an opteron, I
have now for ifort 3.7s for gfortran 4.5s (20% slower only) for the following
code:
SUBROUTINE collocate_core_2_2_0_0(jg,cmax)
IMPLICIT
--- Comment #14 from jakub at gcc dot gnu dot org 2008-01-07 22:07 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hubicka at gcc dot gnu dot org 2008-01-07 22:09 ---
mine.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hubicka at ucw dot cz 2008-01-07 22:38 ---
Subject: Re: New: Inlining heuristics issue
I should also add that this is one of examples where Martin's switch
optimization pass would do miracles. If organized before inlining we
would end up with one static array.
--- Comment #9 from hjl at lucon dot org 2008-01-07 22:57 ---
We are processing common block symbols which we have rejected/freed before.
This patch works for me:
Index: symbol.c
===
--- symbol.c(revision 131352)
+++
The following is a short code fragment similar to code to be found in the open
source Argyll CMS (http://www.argyllcms.com/)
---
#include stdio.h
struct _iFile {
int (*fprintf)(struct _iFile *p, const char *format, ...);
};
typedef struct _iFile iFile;
static int testprint(iFile *p,
There are already two other problem reports for failures of this test: PR
target/26726 for i?86 and x86_64, and PR target/27707 for hppa. Those are not
regressions. The test started failing for powerpc64-linux-gnu, both -m32 and
-m64, with this patch:
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-07 23:46 ---
Two things, fprintf is valid as being done as a macro and second thing is that
this is a glibc issue and not a GCC issue as you are using a define and GCC
just includes the header file.
--
pinskia at gcc dot gnu
--- Comment #3 from hubicka at ucw dot cz 2008-01-07 23:46 ---
Subject: Re: New: Inlining heuristics issue
Hi,
I am testing the attached patch. It simply accounts two instructions
for each case label, I guess it does not make much sense to try to do
something smarter until we move
This is target specific:
program bug
double precision x
x=7.0
print *, x
end
gfortran.exe bug.f
$ ./a.exe
**
This acts like field width is being miscalculated in output_float. It works
fine with Cygwin binary.
--
Summary:
--- Comment #35 from gdr at cs dot tamu dot edu 2008-01-08 02:52 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| --- Comment #34 from mark at codesourcery dot com
--- Comment #36 from mark at codesourcery dot com 2008-01-08 03:39 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with complex type conversion
gdr at cs dot tamu dot edu wrote:
| (Both have
| values unrepresentable in the other, of course.) Would you
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-01-08 04:16
---
No longer segfaults on x86-64
Valgrind reports with common_6.f90
==10016== 1,160 bytes in 5 blocks are definitely lost in loss record 2 of 6
==10016==at 0x4A059F6: malloc (vg_replace_malloc.c:149)
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-01-08 04:56
---
Adding FX to cc. FX do you see this failure on your mingw binaries?
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
94 matches
Mail list logo
