Look at :
[~/test]> ls
mul.c
[~/test]> cat mul.c
long long mul (long long a, long long b) {
return a * b;
}
[~/test]> gcc -c -save-temps mul.c
[~/test]> ls
mul.c mul.o
No assembly or preprocessed file produced.
If I use -o :
[~/test]> gcc -o mul -save-temps mul.c
/usr/lib/gcc/i686-pc-li
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-11-25 08:41
---
By Olivier.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hainque at adacore dot com
|dot org
--- Comment #3 from hainque at adacore dot com 2007-11-25 08:43 ---
Subject: Re: [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution
test
> ebotcazou at gcc dot gnu dot org changed:
>
>What|Removed |Added
>
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-11-25 08:51
---
> Thanks. I tried to do that yesterday and was refused the privilege.
I guess you need to ask Daniel what's going on exactly here.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
Hello there,
I just tried to compile the Suse Linux package celestia-1.4.1-16
with the GNU C++ compiler version 4.3 snapshot 20071123
The compiler said
3dsread.cpp: In function 'Mat4f readMeshMatrix(std::ifstream&, int)':
3dsread.cpp:275: error: missing definition
for SSA_NAME: SMT.659_346 in st
--- Comment #1 from dcb314 at hotmail dot com 2007-11-25 09:27 ---
Created an attachment (id=14633)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14633&action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34222
--- Comment #10 from pault at gcc dot gnu dot org 2007-11-25 09:59 ---
Subject: Bug 33499
Author: pault
Date: Sun Nov 25 09:59:42 2007
New Revision: 130403
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130403
Log:
2007-11-25 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
Consider the following test compiled with r130351 on ppc64-linux:
#define M 10
#define N 3
void
foo (int n, int *ub, int *uc)
{
int i, j, tmp1;
for (i = 0; i < n; i++)
{
tmp1 = 0;
for (j = 0; j < M; j++)
{
tmp1 += uc[i] * ((int)(j << N) / M);
}
--- Comment #12 from pault at gcc dot gnu dot org 2007-11-25 10:40 ---
(In reply to comment #11)
> I think the failures in test3 are ok. Example program:
Yes, you are right. You and Dominique are correct about test2. The odd thing
is that there is a test for this in the testsuite alre
--- Comment #2 from eres at il dot ibm dot com 2007-11-25 11:21 ---
I have been testing Zdenek's initial lim patch on SPEC2006 and tramp3d but saw
no effect on the preformance. We had an example which is similar to the
testcase shown in (http://gcc.gnu.org/ml/gcc-patches/2007-03/txt0006
--- Comment #5 from pinskia at gmail dot com 2007-11-25 11:54 ---
Subject: Re: [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution
test
On 25 Nov 2007 08:51:45 -, ebotcazou at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> I guess you need to ask Daniel what's going
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-25 12:43 ---
Works for me with r130405.
(Please try to reduce the number of optimization options yourself
if you can reproduce the bug -- a lot of them are completely redundant and
already enabled by -O3)
--
rguenth at gcc do
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-25 12:50 ---
Related to PR18754 - but vectorizer folks say early complete unrolling defeats
the vectorizer. So possibly a compromise is to do early complete unrolling
only
for nested loops.
--
rguenth at gcc dot gnu dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-25 13:00 ---
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-25 13:19 ---
Created an attachment (id=14634)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14634&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34222
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-25 13:20 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
[...]
make[2]: Entering directory `/tmp/gcc-4.2.2'
make[3]: Entering directory `/tmp/gcc-4.2.2/host-i686-pc-linux-gnu/libiberty'
if [ x"" != x ]; then \
/tmp/gcc-4.2.2/host-i686-pc-linux-gnu/prev-gcc/xgcc
-B/tmp/gcc-4.2.2/host-i686-pc-linux-gnu/prev-gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -c -DH
--- Comment #2 from steven at gcc dot gnu dot org 2007-11-25 13:36 ---
Why is this a shift not supported:
not vectorized: relevant stmt not supported: D.1652_13 = j_29 << 3
Is j_29*8 supported (i.e. if you hack this expression to turn it into a
MULT_EXPR), does the vectorizer work then?
./cc1 -fpreprocessed main.7.min.i -quiet -O2 -fstack-protector
-fno-strict-aliasing
main.7.min.i: In function 'main':
main.7.min.i:42: warning: incompatible implicit declaration of built-in
function 'strlen'
main.7.min.i:58: warning: incompatible implicit declaration of built-in
function 'sscanf'
m
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-25 13:41 ---
Created an attachment (id=14635)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14635&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34225
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-25 13:57 ---
A cross to ppc64 shows
Program received signal SIGSEGV, Segmentation fault.
0x00b7ff6a in adjacent_mem_locations (insn1=0x2b2889d519b0,
insn2=0x2b2889ce50f0)
at /space/rguenther/src/svn/trunk/gcc/co
--- Comment #3 from eres at il dot ibm dot com 2007-11-25 14:13 ---
(In reply to comment #2)
> Why is this a shift not supported:
> not vectorized: relevant stmt not supported: D.1652_13 = j_29 << 3
> Is j_29*8 supported (i.e. if you hack this expression to turn it into a
> MULT_EXPR), d
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
$ echo 'int main (int argc, char *argv[]) { return 0; }' >/tmp/test.c
$ ./xgcc -B./ /tmp/test.c -S -o /dev/null
/tmp/test.c:1: internal compiler error: in default_secondary_reload, at
targhooks.c:612
Please submit a full bug report,
...
This happens with revision 130402. Revision 129967 worked. Con
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
CC|sam at rfc1149 dot net |
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot o
--- Comment #3 from sam at gcc dot gnu dot org 2007-11-25 14:15 ---
Bug is fixed in current sources
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-11-25 15:58
---
Subject: Bug 33152
Author: jvdelisle
Date: Sun Nov 25 15:57:55 2007
New Revision: 130409
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130409
Log:
2007-11-25 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-11-25 17:22
---
oops, I had the wrong PR number in the ChangeLog. Should have been for PR34175.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33152
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-11-25 17:25
---
Subject: Bug 34175
Author: jvdelisle
Date: Sun Nov 25 17:25:22 2007
New Revision: 130411
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130411
Log:
2007-11-25 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-25 17:27 ---
Looks like a possible bug in the .md:
gcc_assert (insn_data[(int) icode].n_operands == 3);
but more information would be appreciated here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-25 18:50 ---
18191 return ((REGNO (reg0) == REGNO (reg1))
18192 && (val_diff == INTVAL (MEM_SIZE (a))
18193 || val_diff == -INTVAL (MEM_SIZE (b;
18194 }
18195
(gdb) p a
$1 = (
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-25 18:51 ---
(insn:TI 448 79 76 2 t.c:18 (set (mem/c:BLK (reg/f:DI 1 1) [0 A8])
(unspec:BLK [
(mem/c:BLK (reg/f:DI 1 1) [0 A8])
] 5)) 542 {stack_tie} (nil))
--
http://gcc.gnu.org/bugzilla/
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-25 18:52 ---
#1 0x00828329 in rs6000_emit_stack_tie () at
../../gcc/config/rs6000/rs6000.c:14974
14974 emit_insn (gen_stack_tie (mem));
(gdb) l
14969 rs6000_emit_stack_tie (void)
14970 {
14971 rtx mem = gen_frame_mem
--- Comment #5 from tbm at cyrius dot com 2007-11-25 19:01 ---
I wonder if this is related to PR33869 (which now works).
--
tbm at cyrius dot com changed:
What|Removed |Added
-
--- Comment #11 from pault at gcc dot gnu dot org 2007-11-25 19:05 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
character(len=3) :: emname(nmin)=(/'bar','baz'/)
common/nmstr/emname
end
currently gfortran prints:
Error: Previously initialized symbol 'emname' in COMMON block 'nmstr' at (1)
If find the error message of NAG f95 better, which mentions that BLOCK DATA can
be used:
Error: EMNAME has been
The following is frequently used and accepted by many compilers; thus it should
continue to work in -std=gnu, but - if feasible - one should reject it with
-std=f95/f2003.
subroutine y
data emname/'bar'/
character(len=3) :: emname
end subroutine y
Accepted by most compilers including the
--- Comment #6 from dje at gcc dot gnu dot org 2007-11-25 20:26 ---
It is not clear that the scheduling code should be considering stack_tie for
this particular conflict. But the stack_tie MEM probably should have some
basic attributes using set_mem_attrs_from_reg.
--
http://gcc.gn
/vol1/tmp/rwgk/gcc_trunk_130411_x86_64_fc7
--enable-languages=c,c++,fortran --with-mpfr=/usr
Thread model: posix
gcc version 4.3.0 20071125 (experimental) (GCC)
I'll attach a small reproducer.
% g++ -c -fpermissive -I/usr/include/python2.5 used_but_not_defined.cpp
/usr/include/boost/type_t
--- Comment #1 from rwgk at yahoo dot com 2007-11-25 20:30 ---
Created an attachment (id=14636)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14636&action=view)
reproducer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34229
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-11-25 20:46 ---
Here is a testcase which shows this is not a complete fix, it does not fix the
case where the static const was initialized inside the class.
namespace {
struct c
{
static const bool t = 0;
};
}
const bool &f()
{
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-25 20:46 ---
I don't think this is valid code. There is no definition for the is_const part
for the template where bind_return is in the anonymous namespace. The code was
diagnose before that date but it was not rejected becaus
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-25 20:47 ---
Also please attach the preprocessed source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34229
--- Comment #5 from tromey at gcc dot gnu dot org 2007-11-25 21:11 ---
Given that this is a constraint, my first inclination is to close the bug
report.
Richard, what motivated this PR?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tromey at gcc dot gnu dot org 2007-11-25 21:18 ---
Confirming; still happens with svn trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-25 21:20 ---
That error message disappears with the patch to PR 33152.
>From "5.5.2.4 Differences between named common and blank common":
"A data object in a named common block may be initially defined by means of a
DATA stateme
--- Comment #1 from tromey at gcc dot gnu dot org 2007-11-25 21:20 ---
Not a preprocessor bug; refiling to 'other'.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from rguenther at suse dot de 2007-11-25 21:34 ---
Subject: Re: Empty macro definitions not considered
equal
On Sun, 25 Nov 2007, tromey at gcc dot gnu dot org wrote:
> --- Comment #5 from tromey at gcc dot gnu dot org 2007-11-25 21:11
> ---
> Given that this
--- Comment #19 from mdorey at bluearc dot com 2007-11-25 21:41 ---
(We finally got round to throwing the switch on our next release from gcc-3.3
to gcc-4.2. It works great - the compiled code gets us significantly higher
benchmark numbers and we're appreciating improved error reporting
Found by FX. See
http://gcc.gnu.org/ml/fortran/2007-11/msg00208.html
$ cat a.f90
real, parameter :: y = exp(log(huge(y))+20)
real, parameter :: x = log(y)
print *, x, y
end
$ gfortran a.f90 -fno-range-check && ./a.out
108.72284 +Infinity
The problem is the following: g
--- Comment #12 from burnus at gcc dot gnu dot org 2007-11-25 22:03 ---
Subject: Bug 34079
Author: burnus
Date: Sun Nov 25 22:02:53 2007
New Revision: 130414
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130414
Log:
2007-11-25 Tobias Burnus <[EMAIL PROTECTED]>
PR for
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-11-25 22:12
---
Subject: Bug 33152
Author: jvdelisle
Date: Sun Nov 25 22:12:19 2007
New Revision: 130415
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130415
Log:
2007-11-25 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-11-25 22:15
---
Subject: Bug 33152
Author: jvdelisle
Date: Sun Nov 25 22:14:57 2007
New Revision: 130416
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130416
Log:
2007-11-25 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #13 from burnus at gcc dot gnu dot org 2007-11-25 22:15 ---
Subject: Bug 34079
Author: burnus
Date: Sun Nov 25 22:15:47 2007
New Revision: 130417
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130417
Log:
Forgot trans-expr.c in previous commit:
2007-11-25 Tobias Bu
--- Comment #14 from burnus at gcc dot gnu dot org 2007-11-25 22:18 ---
FIXED on the trunk (4.3.0) [there is no bind(C) support in 4.2.x].
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from manu at gcc dot gnu dot org 2007-11-25 22:23 ---
(In reply to comment #6)
>
> But yes, there's probably nothing else than to close this bug.
>
Well you could make the error depend on the pedantic flag. This is a recurrent
confusion: C++ does not enable pedantic-err
--- Comment #8 from rguenther at suse dot de 2007-11-25 22:29 ---
Subject: Re: Empty macro definitions not considered
equal
On Sun, 25 Nov 2007, manu at gcc dot gnu dot org wrote:
> --- Comment #7 from manu at gcc dot gnu dot org 2007-11-25 22:23 ---
> (In reply to comment #
The following test program calls the wrong routine :
[EMAIL PROTECTED] test]$ gfortran test3.f90
[EMAIL PROTECTED] test]$ a.out
odfamilycnames
With ifort (or g95, lf95, SUN f90) the result is :
[EMAIL PROTECTED] test]$ ifort test3.f90
[EMAIL PROTECTED] test]$ a.out
odfamilycname
File test3.f9
--- Comment #9 from manu at gcc dot gnu dot org 2007-11-25 22:56 ---
(In reply to comment #8)
>
> But C++ has -pedantic as default as well ;)
>
How you reached to that conclusion?
>
> Tom can probably do this. But I belive the patch will not work,
> as CPP_PEDANTIC is set to true b
--- Comment #10 from manu at gcc dot gnu dot org 2007-11-25 22:59 ---
(In reply to comment #8)
>
> Tom can probably do this. But I belive the patch will not work,
> as CPP_PEDANTIC is set to true by the C++ frontend now.
BTW, the patch works for the revision I diffed against. The test
libgcj build in bootstrap fails on i686-pc-cygwin due to undefined reference
error in boehm-gc library.
libtool: link: /home/LarryR/Build/gcc-4.3.0/gcc/gcj
-B/home/LarryR/Build/gcc-4.3.0/i686-pc-cygwin/libjava/
-B/home/LarryR/Build/gcc-4.3.0/gcc/ -ffloat-store -fomit-frame-pointer -Usun
-march=pre
--- Comment #1 from ismail at pardus dot org dot tr 2007-11-25 23:21
---
Looks like a ccache bug instead.
--
ismail at pardus dot org dot tr changed:
What|Removed |Added
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-11-25 23:51
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2007-11-26 00:12 ---
There is no bug here. You have explicitly disabled
range checking. This means that you no longer have
a limitation on range in constant folding. It may
be help to look at -fdump-parse-tree. YOu don't
have an Inf un
--- Comment #25 from rakdver at gcc dot gnu dot org 2007-11-26 00:48
---
Created an attachment (id=14637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14637&action=view)
Patch to make ivopts take autoincrement addressing modes into account
Ivopts take autoincrement addressing mo
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|rakdver at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #26 from mmitchel at gcc dot gnu dot org 2007-11-26 00:53
---
Zdenek, do you have the ability to get code-size measurements on ARM? (You
don't need to actually run the code to find out if this improves code density.)
If you don't, I'll ask someone at CodeSourcery to measur
--- Comment #27 from rakdver at kam dot mff dot cuni dot cz 2007-11-26
01:12 ---
Subject: Re: [4.3 Regression] Code size regression caused by fix to PR 31360
> Zdenek, do you have the ability to get code-size measurements on ARM? (You
> don't need to actually run the code to find out
--- Comment #28 from pinskia at gcc dot gnu dot org 2007-11-26 01:24
---
A couple of comments about the patch.
+ #define CP_AUTOINC_OFFSET(CP) ((int) (size_t) (CP)->value)
I don't like this idea at all.
The patch should support pre increment also (this shows up on PPC) and pre/post
de
--- Comment #29 from rakdver at kam dot mff dot cuni dot cz 2007-11-26
01:42 ---
Subject: Re: [4.3 Regression] Code size regression caused by fix to PR 31360
> --- Comment #28 from pinskia at gcc dot gnu dot org 2007-11-26 01:24
> ---
> A couple of comments about the patch.
--- Comment #4 from rwgk at yahoo dot com 2007-11-26 01:52 ---
Created an attachment (id=14638)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14638&action=view)
reproducer preprocessed gzip'ed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34229
--- Comment #5 from rwgk at yahoo dot com 2007-11-26 02:11 ---
cc'ing David Abrahams since the original code is his.
--
rwgk at yahoo dot com changed:
What|Removed |Added
--- Comment #6 from rwgk at yahoo dot com 2007-11-26 02:17 ---
The patch below makes the Boost.Python compilation work again with
gcc svn trunk revision 130411. This solves my problem. :-)
The g++ change could be tough for people who have to keep using older
boost versions for one reaso
/vol1/tmp/rwgk/gcc_trunk_130411_x86_64_fc7
--enable-languages=c,c++,fortran --with-mpfr=/usr
Thread model: posix
gcc version 4.3.0 20071125 (experimental) (GCC)
% g++ -c -fno-strict-aliasing -Wall -O2 -ffast-math -ftrapping-math
ice_get_callee_fndecl.cpp
ice_get_callee_fndecl.cpp:1: warning
--- Comment #1 from rwgk at yahoo dot com 2007-11-26 03:33 ---
Created an attachment (id=14639)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14639&action=view)
reproducer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34233
--- Comment #2 from rwgk at yahoo dot com 2007-11-26 03:34 ---
Created an attachment (id=14640)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14640&action=view)
reproducer preprocessed gzip'ed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34233
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-11-26 04:50
---
I have been studying this more in some debug sessions. We actually
successfully match the iterator multiple times. However, by the time we get
through several attempted matchings, I think we get left with the l
--- Comment #30 from rakdver at gcc dot gnu dot org 2007-11-26 05:08
---
The patch improves size of adler32 (and several other files in zlib) by about
2%. However, overall on the whole csibe it is neutral (the sum of the sizes of
all the files increases by 0.02%) -- the changes in size
--- Comment #4 from aoliva at gcc dot gnu dot org 2007-11-26 06:26 ---
Subject: Bug 27898
Author: aoliva
Date: Mon Nov 26 06:26:18 2007
New Revision: 130425
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130425
Log:
PR c/27898
* c-typeck.c (tagged_types_tu_compatible_p): Enable
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-11-26 06:28
---
OK, tracing this farther, the correct iterator makes it to translation at
gfc_conv_array_initializer. Here we simply have not implemented code to handle
it and we have this:
if (c->iterator)
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-11-26 06:52
---
Food for thought:
I wonder if this is best solved by creating a general purpose iterator function
that we call at run time whenever needed. A function for each Basic Type.
Seems this would be fine for initiali
86 matches
Mail list logo
