--- Comment #14 from jakub at gcc dot gnu dot org 2007-12-04 08:11 ---
*** Bug 34329 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2007-12-04 08:11 ---
*** This bug has been marked as a duplicate of 34005 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
NaN are special in so far that
if(nan /= nan)
evaluates as TRUE (see IEEE 754 and IEEE 754r). This is the case if the
variable is not a parameter, however, for parameters the wrong thing is
returned (compile with -fno-range-check):
real,parameter :: r = 0.0/0.0
! real :: r = 0.0/0.0
! if
--- Comment #3 from burnus at gcc dot gnu dot org 2007-12-04 10:33 ---
FIXED on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from patchapp at dberlin dot org 2007-12-04 10:23 ---
Subject: Bug number PR34318
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/2007-12/msg00097.html
--
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-04 10:26 ---
http://www.mpfr.org/mpfr-2.3.0/mpfr.html#Comparison-Functions
Function: int mpfr_cmp (mpfr_t op1, mpfr_t op2)
If one of the operands is NaN, set the erange flag and return zero.
Note: These functions may be
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-04 10:32 ---
Subject: Bug 34318
Author: burnus
Date: Tue Dec 4 10:32:04 2007
New Revision: 130600
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130600
Log:
2007-12-04 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-04 11:01 ---
But fixed on the mainline and not a regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-12-04 11:00 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from michael dot olbrich at gmx dot net 2007-12-04 10:56
---
With the latest debian packages:
g++-4.2 (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
g++-4.3 (Debian 4.3-20071130-1) 4.3.0 20071130 (experimental) [trunk revision
130545]
Same speed for benchmark.cpp
--- Comment #29 from bonzini at gnu dot org 2007-12-04 11:17 ---
Could you try 4.2 vs. 4.3 on:
- http://gcc.gnu.org/bugzilla/attachment.cgi?id=14496
- http://gcc.gnu.org/bugzilla/attachment.cgi?id=14497
- http://gcc.gnu.org/bugzilla/attachment.cgi?id=14497 with the first #if 0
enabled
--- Comment #30 from rguenth at gcc dot gnu dot org 2007-12-04 11:21
---
It is likely that for the bigger testcases we run into our usual
alias-partitioning problems, so also try with --param max-aliased-vops=10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
--- Comment #32 from paolo dot bonzini at lu dot unisi dot ch 2007-12-04
12:38 ---
Subject: Re: [4.3 Regression] Revision 119502
causes significantly slower results with 4.3 compared to 4.2
The difference between 4.2 and 4.3 is not as big but is still there:
0.7s vs. 1.6s
Well,
With a x86_64 - ppc64 cross:
./cc1 ~/export/config_file.1.min.i -O2 -o /dev/null -m32 -quiet
/suse/rguenther/export/config_file.1.min.i:16: warning: unnamed struct/union
that defines no instances
/suse/rguenther/export/config_file.1.min.i:16: warning: 'struct stat64'
declared inside parameter
--- Comment #31 from michael dot olbrich at gmx dot net 2007-12-04 12:17
---
Subject: Re: [4.3 Regression] Revision 119502
causes significantly slower results with 4.3 compared to 4.2
On Tue, Dec 04, 2007 at 11:17:46AM -, bonzini at gnu dot org wrote:
-
--- Comment #6 from aldot at gcc dot gnu dot org 2007-12-04 12:28 ---
Testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31529
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-12-04 12:48 ---
Created an attachment (id=14696)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14696action=view)
reduced testcase
Appearantly the ICE is dependent on UIDs as if you remove an unused type decl
the
ICE
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-04 13:15 ---
The difference if I remove the gftp_transfer typedef from the dump after
critical edge splitting is (good vs. bad):
- D.1477_21 = 0B;
- *0B ={v} 0;
+ # VUSE SMT.32_54, SMT.33_40
+ D.1481_21 = *dest_19;
+ #
Consider the following piece of code:
module A
type A_type
real comp
end type
end module A
module B
use A
private
type(A_type) :: B_var
public:: B_var
end module B
program C
use B
use A
type(A_type):: A_var
end program C
This is rejected with the error message
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-04 14:00 ---
Created an attachment (id=14697)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14697action=view)
Test case and partial patch
Attached you find a patch for simplify.c's min/max and for the comparison of
complex
--- Comment #3 from burnus at gcc dot gnu dot org 2007-12-04 14:02 ---
Note to the attached test case: One needs to remove some superfluous !!
comments from nan_2.f90.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34333
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-12-04 14:03 ---
The issue is that the loaded_syms bitmap doesn't agree with the VUSEs:
(gdb) call debug_generic_expr (stmt)
# VUSE SMT.33_40 { SMT.32 SMT.33 }
storetmp.46_60 = *dest_19
as in create_ssa_artificial_load_stmt we
--- Comment #1 from jaydub66 at gmail dot com 2007-12-04 13:44 ---
The code above fails for recent trunk builds (rev. 130582) on
i686-pc-linux-gnu, but is known to work for 4.2.1 as well as 4.3.0 rev. 127773
(from August 24, 2007).
--
jaydub66 at gmail dot com changed:
--- Comment #15 from jakub at gcc dot gnu dot org 2007-12-04 14:19 ---
Testing a different fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-12-04 14:40 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sam at gcc dot gnu dot org 2007-12-04 14:40 ---
Confirmed on trunk.
GNAT 4.3.0 20071203 (experimental)
Copyright 1992-2007, Free Software Foundation, Inc.
Compiling: items.adb (source file time stamp: 2007-12-04 14:40:16)
11. := new Item'(Kind =
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |middle-end
Target Milestone|--- |4.3.0
--- Comment #2 from jaydub66 at gmail dot com 2007-12-04 14:55 ---
The error also appears on x86_64. It must have been introduced somewhere
between Nov. 23 and 26:
- rev. 130365 works
- rev. 130431 fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34335
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-12-04 17:20 ---
Subject: Bug 34222
Author: rguenth
Date: Tue Dec 4 17:20:34 2007
New Revision: 130602
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130602
Log:
2007-12-04 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-12-04 17:20 ---
Subject: Bug 34334
Author: rguenth
Date: Tue Dec 4 17:20:34 2007
New Revision: 130602
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130602
Log:
2007-12-04 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-12-04 17:21 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-12-04 17:21 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from h dot mth at web dot de 2007-12-04 17:43 ---
I wonder what goes wrong with building cpp at stage 3(?). :)
ana build # for f in $(find ./ -type f -name cpp); do ls -l $f; PATH=$(dirname
$f) $f -dM /dev/null | grep __DBL_MAX__; done
-rwxr-xr-x 1 root root 279196 4.
The following error occurs while compiling template code (included as
error-4.2.2.ii at the tail of this report).
$ g++ -c error-4.2.2.cc
error-4.2.2.cc: In constructor 'ClassCDATATYPE::ClassC()':
error-4.2.2.cc:35: internal compiler error: in stabilize_expr, at
cp/tree.c:2273
Please
--- Comment #1 from gschrad at ll dot mit dot edu 2007-12-04 17:59 ---
Created an attachment (id=14698)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14698action=view)
Preprocessed source of the case that causes the error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34336
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-04 18:10 ---
With checking on the trunk we get this ICE:
error-4.2.2.cc: In constructor 'ClassCDATATYPE::ClassC()':
error-4.2.2.cc:35: internal compiler error: tree check: expected target_expr,
have non_dependent_expr in
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-12-04 18:15 ---
We have:
Unknown tree: non_dependent_expr
*((struct ClassC *) this)-m_xfr
Which means we are missing a TARGET_EXPR or we are trying to stabilize the
expression too early.
--
--- Comment #5 from sam at gcc dot gnu dot org 2007-12-04 18:55 ---
Ludovic,
in RM 3.6:
(2)
array_type_definition ::=
unconstrained_array_definition | constrained_array_definition
(3)
unconstrained_array_definition ::=
array(index_subtype_definition
--- Comment #3 from burnus at gcc dot gnu dot org 2007-12-04 19:07 ---
Paul, do you have an idea? My (un)educated guess is that the fix for PR 33541
(patch to not import y when using use foo; use foo, only: x = y) caused
this.
--
burnus at gcc dot gnu dot org changed:
I got an internal error while building gtkwhiteboard.c from pidgin 2.3.0 [0] .
[0] http://downloads.sourceforge.net/pidgin/pidgin-2.3.0.tar.bz2
--
Summary: Internal error while building gtkwhiteboardc.c from
pidgin 2.3.0
Product: gcc
--- Comment #1 from ismail at pardus dot org dot tr 2007-12-04 19:18
---
Created an attachment (id=14699)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14699action=view)
Preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34337
--- Comment #6 from dgregor at gcc dot gnu dot org 2007-12-04 19:27 ---
Subject: Bug 33091
Author: dgregor
Date: Tue Dec 4 19:27:14 2007
New Revision: 130604
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130604
Log:
2007-12-04 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #2 from ismail at pardus dot org dot tr 2007-12-04 19:29
---
Forget to add used options :
-g -march=i686 -mtune=native -O2
is used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34337
--without-included-gettext --without-system-libunwind --with-system-zlib
--with-pkgversion='Pardus Linux' --with-bugurl=http://bugs.pardus.org.tr
Thread model: posix
gcc version 4.3.0 20071204 SVN-r130598 (Pardus Linux)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34337
--- Comment #6 from aldyh at gcc dot gnu dot org 2007-12-04 19:30 ---
Ok, here's the deal.
gimplify_init_constructor promotes the constructor to a static because it is a
const aggregate variable, here:
/* If a const aggregate variable is being initialized, then it
--- Comment #5 from jakub at gcc dot gnu dot org 2007-12-04 19:39 ---
Alex's patch has not been reverted and it seems it was agreed on to keep it for
4.3 and only try something different, like Richard's patches, for 4.4.
If so, this isn't a 4.3 regression, because 4.2 was AFAIK eating
--- Comment #7 from jakub at gcc dot gnu dot org 2007-12-04 19:58 ---
The problem is that we really don't have any optimization which would before
expand merge all the sets to adjacent bitfield fields into one (or few)
BITFIELD_REFs. If we are lucky and the RTL passes merge it
--- Comment #8 from jakub at gcc dot gnu dot org 2007-12-04 20:02 ---
E.g. for PR22141 it would help too (for PR32901 only if the constructor
gimplification heuristics is also adjusted).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-12-04 20:09 ---
No need to keep this bug open, the issue is fixed with Alex's patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-12-04 20:19 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-12-04 20:29 ---
We endlessly recurse folding
Breakpoint 3, fold_binary (code=BIT_IOR_EXPR, type=0xb7c9a2d8, op0=0xb700a2ac,
op1=0xb7d142f4) at /home/richard/src/trunk/gcc/fold-const.c:9397
9397 enum tree_code_class kind
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|Internal error while
--
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 #5 from rguenth at gcc dot gnu dot org 2007-12-04 20:33 ---
Testcase:
int foo(int color_rgb)
{
return ((color_rgb 8) 65535) | 255;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34337
--- Comment #6 from ludovic at ludovic-brenta dot org 2007-12-04 20:35
---
The fact that Boolean'Base is unconstrained _doesn't_ imply
that we don't have a discrete_subtype_indication. Discreteness
and constrainedness aren't the same thing, and one doesn't
imply the other.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
--- Comment #2 from myselfhimself at free dot fr 2007-12-04 20:37 ---
Hi
this is to say that my first example was not a problem so sorry for posting.
a conclusion is that c++ tolerates nameless parameter names even in function
definition.
As to the second example, Andrew Pinski, you
--- Comment #4 from patchapp at dberlin dot org 2007-12-04 20:45 ---
Subject: Bug number PR34333
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/2007-12/msg00127.html
--
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-12-04 20:49 ---
Subject: Bug 33509
Author: dgregor
Date: Tue Dec 4 20:49:08 2007
New Revision: 130605
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130605
Log:
2007-12-04 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #6 from jakub at gcc dot gnu dot org 2007-12-04 20:50 ---
It is the:
/* Minimize the number of bits set in C1, i.e. C1 := C1 ~C2. */
hi1 = mhi;
lo1 = mlo;
if ((hi1 ~hi2) != hi1 || (lo1 ~lo2) != lo1)
return fold_build2
--- Comment #4 from dgregor at gcc dot gnu dot org 2007-12-04 20:52 ---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dgregor at gcc dot gnu dot org 2007-12-04 20:53 ---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Following code does not compile, and got error messages:
g++ hello.cpp
hello.cpp: In member function 'long long int C::count(int)':
hello.cpp:10: error: no matching function for call to 'C::count()'
hello.cpp:9: note: candidates are: long long int C::count(int)
hello.cpp: In function 'int
--- Comment #1 from gray_song at yahoo dot com 2007-12-04 21:01 ---
If change C::count(int l) definition to
C::count_c(int l)
It works fine.
--
gray_song at yahoo dot com changed:
What|Removed |Added
--- Comment #4 from myselfhimself at free dot fr 2007-12-04 21:03 ---
*** Bug 34307 has been marked as a duplicate of this bug. ***
--
myselfhimself at free dot fr changed:
What|Removed |Added
--- Comment #3 from myselfhimself at free dot fr 2007-12-04 21:03 ---
I did some research
this bug has already reported in as 19808
implementation work for it is probably started as I have found this page
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
*** This bug has been
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-12-04 21:12 ---
Subject: Bug 34101
Author: dgregor
Date: Tue Dec 4 21:12:41 2007
New Revision: 130608
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130608
Log:
2007-12-04 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-12-04 21:13 ---
Fixed
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
: it occurs with version 4.3.0 20071204, but did not occur
with version 4.3.0 20071023.
--
Summary: derived type definition not found
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
--- Comment #4 from jaydub66 at gmail dot com 2007-12-04 21:16 ---
(In reply to comment #3)
Paul, do you have an idea? My (un)educated guess is that the fix for PR 33541
(patch to not import y when using use foo; use foo, only: x = y) caused
this.
I don't think your guess is
--- Comment #1 from william dot mitchell at nist dot gov 2007-12-04 21:18
---
Created an attachment (id=14700)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14700action=view)
the code that illustrates the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34339
I found another failure, this time already when compiling, not when linking. I
didn't see that when reporting bug 34178. Probably it has been introduced in
the meantime.
struct ListElem
{
const ListElem *next;
};
struct Base
{
static const ListElem Head;
};
template typename
--- Comment #6 from jakub at gcc dot gnu dot org 2007-12-04 21:55 ---
Subject: Bug 34134
Author: jakub
Date: Tue Dec 4 21:55:32 2007
New Revision: 130609
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130609
Log:
PR middle-end/34134
* stmt.c
--- Comment #12 from jakub at gcc dot gnu dot org 2007-12-04 22:01 ---
Fixed on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31128
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-04 22:04 ---
The error is correct. The count without any arguments hide the one with (the
other way is true too). You need to add using A::count in the class C and
using C::count in class D.
--
pinskia at gcc dot gnu dot
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-04 22:06 ---
The bug is a recent regression, which has been already reported today as PR
34335.
Work around:
use hash_eq_mod
use linsystype_mod
i.e. reverting the order.
Thanks for the report.
*** This bug has been marked
--- Comment #5 from burnus at gcc dot gnu dot org 2007-12-04 22:06 ---
*** Bug 34339 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-04 22:11 ---
I think this is caused by:
2007-11-22 Jakub Jelinek [EMAIL PROTECTED]
PR c++/34094
* decl2.c (cp_write_global_declarations): Issue error about static
data members in anonymous namespace
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-04 22:26 ---
*** This bug has been marked as a duplicate of 34238 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-12-04 22:26 ---
*** Bug 34340 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-04 22:29 ---
This actually is not a dup of 34238, anon ns isn't involved at all.
Will look at this tomorrow.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from gray_song at yahoo dot com 2007-12-04 23:40 ---
(In reply to comment #2)
The error is correct. The count without any arguments hide the one with (the
other way is true too). You need to add using A::count in the class C and
using C::count in class D.
Change
--- Comment #9 from aldyh at gcc dot gnu dot org 2007-12-04 23:43 ---
TER would never see the consecutive initializations because the code I pointed
out in gimplify_init_constructor() keeps the gimplifier from splitting up the
constructor into consecutive MODIFY_EXPRs.
After
--- Comment #10 from aldyh at gcc dot gnu dot org 2007-12-04 23:54 ---
(In reply to comment #8)
E.g. for PR22141 it would help too (for PR32901 only if the constructor
gimplification heuristics is also adjusted).
Ok, I see what you mean. We adjust the heuristic as I've suggested,
I am using the GCC 4.1.1 ARM build for Cygwin from GNUARM.
$ arm-elf-gcc -v
Using built-in specs.
Target: arm-elf
Configured with: ../gcc-4.1.1/configure --target=arm-elf
--prefix=/g/gnuarm-4.1.1 --enable-interwork --enable-multilib --with-float=soft
--with-newlib
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-12-05 02:09 ---
No, I mean add the following statement:
using A::count;
to the class.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-12-05 05:08
---
I am going to close this as not a gfortran bug. This could be an issue with
the terminal settings chosen by mingw as well. By mingw shell, I presume you
mean MSYS. There may be some documentation around to
--- Comment #5 from gray_song at yahoo dot com 2007-12-05 06:01 ---
(In reply to comment #4)
No, I mean add the following statement:
using A::count;
to the class.
Thank you very much for replying. I tried to add the using A::count; to class
C. But it didn't work.
--
--- Comment #5 from fang at csl dot cornell dot edu 2007-12-05 06:48
---
(I believe 4.3.0 was accidentally listed under known-to-work.)
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
real, parameter :: M2_PI = '40490FDB'X
end
uses several extensions, which are not diagnosed:
- X instead of Z
- Suffix instead of prefix
- BOZ to initialize a REAL
(the later is allowed in F2003 using REAL(Z'...').)
BOZ bugs: PR 18026 and PR 29471.
Fortran 95:
In a DATA statement
--- Comment #7 from ismail at pardus dot org dot tr 2007-12-05 07:24
---
Just a note, this seems to break kernel-2.6.24 compilation too, out of memory
and cc1 gets killed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34337
91 matches
Mail list logo
