[Bug c/10719] invalid code generated (x86, int $5) with __builtin_va_arg(va, char);
--- Comment #26 from ebotcazou at gcc dot gnu dot org 2005-11-06 08:42 --- How does stopping violate the standard? If the standard says behavior is undefined, then you can do anything you want, including stopping. You're confusing compile time and run time. Please read the whole audit trail, in particular comment #3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
[Bug target/19520] protected function pointer doesn't work right
--- Comment #21 from simon dot strandman at telia dot com 2005-11-06 09:50 --- (In reply to comment #18) I posted an updated patch http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00196.html I hope it will work better. Sorry to bother but where is the updated patch? That link leads to something else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug other/24692] New: Atomic builtins for v3
This is to track this issue: http://gcc.gnu.org/ml/gcc/2005-11/msg00285.html In a nutshell, we need an easy way to exploit the new atomic builtins in the library, irrespective of the actual target. -- Summary: Atomic builtins for v3 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug libstdc++/24693] New: Deque improvements
This is to track this issue: http://gcc.gnu.org/ml/libstdc++/2005-11/msg00031.html A first part, about _M_erase_at_end/_M_erase_at_begin, should be doable relatively quickly. -- Summary: Deque improvements Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24693
[Bug other/24692] Atomic builtins for v3
-- pcarlini at suse dot de changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug fortran/24096] huge() returns infinity for long doubles
--- Comment #1 from amodra at bigpond dot net dot au 2005-11-06 11:09 --- Revised patch http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00388.html -- amodra at bigpond dot net dot au changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg00388.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24096
[Bug rtl-optimization/23837] [4.0/4.1 regression] Wrong code with -fschedule-insns
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-06 11:50 --- Folks, what's up with this bug? Is it HPPA-only now? Can someone comment on the status of this bug please? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org, steven at gcc dot gnu ||dot org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug rtl-optimization/24497] [3.4/4.0/4.1 Regression] internal compiler error: in apply_opt_in_copies, at loop-unroll.c:2122
--- Comment #4 from pbrook at gcc dot gnu dot org 2005-11-06 12:23 --- Both still fail for me Target: m68k-elf Configured with: ../gcc/configure --prefix=/home/paul/arm --target=m68k-elf --with-newlib --disable-shared --disable-threads --enable-languages=c,c++ Thread model: single gcc version 4.1.0 20051106 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24497
[Bug libstdc++/18174] documentation example for std::priority_queue usage
--- Comment #4 from paolo at gcc dot gnu dot org 2005-11-06 13:07 --- Subject: Bug 18174 Author: paolo Date: Sun Nov 6 13:07:11 2005 New Revision: 106560 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106560 Log: 2005-11-06 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/18174 * include/bits/stl_queue.h (priority_queue): Tweak a bit the comment describing the container. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_queue.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18174
[Bug libstdc++/18174] documentation example for std::priority_queue usage
--- Comment #5 from paolo at gcc dot gnu dot org 2005-11-06 13:09 --- Subject: Bug 18174 Author: paolo Date: Sun Nov 6 13:09:50 2005 New Revision: 106561 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106561 Log: 2005-11-06 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/18174 * include/bits/stl_queue.h (priority_queue): Tweak a bit the comment describing the container. Modified: branches/gcc-4_0-branch/libstdc++-v3/ChangeLog branches/gcc-4_0-branch/libstdc++-v3/include/bits/stl_queue.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18174
[Bug libstdc++/18174] documentation example for std::priority_queue usage
--- Comment #6 from pcarlini at suse dot de 2005-11-06 13:10 --- Fixed for 4.0.3. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18174
[Bug other/24692] Atomic builtins for v3
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-06 14:10 --- Maybe the easy way to fix this is just have the distro change their policy of compiling with i386 to compile always with i686. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug other/24692] Atomic builtins for v3
--- Comment #2 from pcarlini at suse dot de 2005-11-06 14:13 --- (In reply to comment #1) Maybe the easy way to fix this is just have the distro change their policy of compiling with i386 to compile always with i686. Indeed, that's one point. However, there isn't only i386 to cause problems, also old Sparc. And targets which *may* have builtins but are simply not implemented, for one reason or another. And situations at the border, e.g., hppa. Really, we want a *uniform* way to call the builtins from the library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug other/24692] Atomic builtins for v3
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-06 14:25 --- (In reply to comment #2) Let first point out i486 is more than 15 years old. Second why do you really need an uniform way? This seems like a way to make everything in the compiler. Maybe next you will be asking for the template string to be part of the compiler and not the library (maybe I am going over board here)? Oh, for libobjc I need a way to describe the alignment and sizes of a struct can that be built into the compiler too please (Really I don't think it should). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug other/24692] Atomic builtins for v3
--- Comment #4 from pcarlini at suse dot de 2005-11-06 14:28 --- (In reply to comment #3) Let first point out i486 is more than 15 years old. Sure, but it's not up to me and you to decide what is on the market, in embedded form or otherwise. And it's not only about i386, again, please read my previous message. .(maybe I am going over board here)? Definitely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug tree-optimization/24670] [4.1 Regression] VRP ICE in compare_name_with_value
--- Comment #3 from dnovillo at gcc dot gnu dot org 2005-11-06 14:51 --- Subject: Bug 24670 Author: dnovillo Date: Sun Nov 6 14:51:16 2005 New Revision: 106562 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106562 Log: PR 24670 * tree-vrp.c (fix_equivalence_set): New. (extract_range_from_assert): Call it. testsuite/ PR 24670 * gcc.dg/tree-ssa/pr24670.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr24670.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
[Bug tree-optimization/24670] [4.1 Regression] VRP ICE in compare_name_with_value
--- Comment #4 from dnovillo at gcc dot gnu dot org 2005-11-06 14:56 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00405.html -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
[Bug fortran/22495] Different ideas about .true. and .false.
--- Comment #11 from tkoenig at gcc dot gnu dot org 2005-11-06 15:01 --- (In reply to comment #10) Thomas, can you point to the text in the standard that prohibits the equivalence of integer and logical. AFAICT, the 4th constraint in 5.5.1, contradicts your assertation. I was wrong there. What actually happens is that the integer value becomes undefined on assignment of the equivalenced logical, and vice versa. This still means that the program is illegal, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495
[Bug java/24441] [4.1 regression] ICE's when building the ecj compiler 3.1.1
--- Comment #2 from bero at arklinux dot org 2005-11-06 15:32 --- An alternative way of building that doesn't trigger this error: cd build/bin find -name '*.java' filelist gcj -C @filelist That compiles all classes without complaining, but I suspect it of generating broken code (will open a new bug for that) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24441
[Bug tree-optimization/24694] New: Address taken and addressable variables and call clobber
Take the following code:
int f(int);
int g(void)
{
int i;
int *iptr = i;
int **ipp = iptr;
**ipp = 1;
f(i);
return **ipp;
}
--
Here we consider i being call clobber because we lose the fact that iptr is
addressable but we don't look to see if its address escapes at all (which in
this case it does not).
--
Summary: Address taken and addressable variables and call clobber
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24694
[Bug tree-optimization/24694] Address taken and addressable variables and call clobber
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-06 15:47 --- Found this while looking a little into PR 24689. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24694
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #4 from pcarlini at suse dot de 2005-11-06 15:58 --- FWIW, is also KO with ICC 9.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug tree-optimization/24694] Address taken and addressable variables and call clobber
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-06 16:08 --- Note this is not fixed on the iab. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24694
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #6 from aph at gcc dot gnu dot org 2005-11-06 16:15 --- You can get the class by generating a special-purpose thunk using the libffi invocation interface and pointing the vector at the thunk. Virtual methods are easy to do by adding a suitable NoClassDefFoundError method to class Object; this method will then be inherited by every class. Instance variables are tricky, but can be done either by adding an inline check or changing the ABI so that virtual accessor methods are generated for all public instance variables. There aren't very many such variables so this might not be much of a problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #5 from pcarlini at suse dot de 2005-11-06 16:19 --- Nathan, can you have a look to this PR? (Googling reveals a lot of hits for nathan typeid ;) Thanks in advance. -- pcarlini at suse dot de changed: What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #6 from frederic dot riss at gmail dot com 2005-11-06 16:33 --- I nearly forgot that I submitted this bug report... I got myself a version of the C++ standard since I submitted that, and I just had a look at the part describing typeid : 5.2.8.4 reads : When typeid is applied to a itype-id/i, [...]. If the type of the type-id is a class type or a reference to a class type, the class shall be completely-defined. I believe A* in 2.C qualifies a a reference to a not-completely defined class type, and thus shouldn't be passed to std::typeid. I'm not an expert in standard reading, but it seems to me that the current behaviour isn't really a bug. If possible, I would be glad to see a warning emited by GCC in that case, because I hit that problem in real-world code (generic callback system using boost::any behind the scenes) and I spent hours finding out what was happening. Maybe I should suggest adding a concept check to the boost code if it is possible to detect it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug target/21715] [4.0/4.1 regression] code-generation performance regression
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-06 16:35 --- I am starting to think what 3.4.x did was just an accident that it got it right in the first place. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.0 4.1.0 3.3.5 |4.0.0 4.1.0 3.3.5 3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
[Bug treelang/23072] multiple runs of treelang testsuite does not work...
--- Comment #18 from phython at gcc dot gnu dot org 2005-11-06 16:51 --- Fixed on the 4.0 branch as well. -- phython at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23072
[Bug bootstrap/24695] New: [csl-arm-branch] Bootstrap failure with current csl-arm-branch
Trying to generate an i686 - armv5te EABI crosscompiler using both binutils and gcc csl-arm-branch checkouts from today fails with /home/oe/tmp/work/gcc-cross-initial-3.4.4+csl-arm-20051105-r0/csl-arm-branch/b uild.i686-linux.arm-linuxeabi/gcc/xgcc -B/home/oe/tmp/work/gcc-cross-initial-3.4 .4+csl-arm-20051105-r0/csl-arm-branch/build.i686-linux.arm-linuxeabi/gcc/ -B/hom e/oe/tmp/cross/arm-linuxeabi/bin/ -B/home/oe/tmp/cross/arm-linuxeabi/lib/ -isyst em /home/oe/tmp/cross/arm-linuxeabi/include -isystem /home/oe/tmp/cross/arm-linu xeabi/sys-include -O2 -g -Os -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./inc lude -I. -I. -I/home/oe/tmp/work/gcc-cross-initial-3.4.4+csl-arm-20051105-r0/cs l-arm-branch/gcc -I/home/oe/tmp/work/gcc-cross-initial-3.4.4+csl-arm-20051105-r0 /csl-arm-branch/gcc/. -I/home/oe/tmp/work/gcc-cross-initial-3.4.4+csl-arm-200511 05-r0/csl-arm-branch/gcc/../include -g0 -finhibit-size-directive -fno-inline-f unctions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -Dinhi bit_libc \ | -c /home/oe/tmp/work/gcc-cross-initial-3.4.4+csl-arm-20051105-r0/csl-a rm-branch/gcc/crtstuff.c -DCRT_BEGIN \ | -o crtbegin.o | /tmp/ccvFKdr5.s: Assembler messages: | /tmp/ccvFKdr5.s:1: Error: unknown pseudo-op: `.cpu' | /tmp/ccvFKdr5.s:2: Error: unknown pseudo-op: `.fpu' -- Summary: [csl-arm-branch] Bootstrap failure with current csl-arm- branch Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-ark-linuxeabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24695
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #7 from pcarlini at suse dot de 2005-11-06 17:03 --- (In reply to comment #6) I nearly forgot that I submitted this bug report... [...] At first, I was under the same impression - not a bug - however, I'm not sure anymore... Have also a look to the ABI: http://www.codesourcery.com/cxx-abi/abi.html section 2.9.3, and then the last sentence of 2.9.5/7... In your example the NTBS addresses (returned by type_info::name()) seem equal... ?!? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug bootstrap/24695] [csl-arm-branch] Bootstrap failure with current csl-arm-branch
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-06 17:05 --- Are you sure that it is using the newest binutils? .cpu and .fpu was added 10-08. http://sourceware.org/ml/binutils-cvs/2005-10/msg00032.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24695
[Bug tree-optimization/24696] New: missing optimization in comparison of results of bit operations
Take this little program:
int
f (unsigned long a, unsigned long b, unsigned long c)
{
return (a (c - 1)) != 0 || (b (c - 1)) != 0;
}
Compiled on x86-64 with gcc 4.0.2 (but I think also with the current mainline)
yields with -O2 the following code:
f:
0: 48 ff cadec%rdx
3: 48 85 d7test %rdx,%rdi
6: 75 07 jnef f+0xf
8: 31 c0 xor%eax,%eax
a: 48 85 d6test %rdx,%rsi
d: 74 05 je 14 f+0x14
f: b8 01 00 00 00 mov$0x1,%eax
14: f3 c3 repz retq
As can be seen, both comparisons are executed individually. This is
unnecessarily slow. Since the right operand for is the same and this is a
pure bit-test it is perfectly fine to compile the code to the equivalent of
int
f (unsigned long a, unsigned long b, unsigned long c)
{
return ((a | b) (c - 1)) != 0;
}
This would be significantly faster. On archs like x86-64 no conditional jump
(just a setne) would be needed.
--
Summary: missing optimization in comparison of results of bit
operations
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drepper at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24696
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #8 from pcarlini at suse dot de 2005-11-06 17:10 --- (In reply to comment #7) section 2.9.3, and then the last sentence of 2.9.5/7... In your example the NTBS addresses (returned by type_info::name()) seem equal... Sorry, I was wrong! The names, the strings, are equal, but the *addresses* are not! Yes, it seems invalid... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug tree-optimization/24696] missing optimization in comparison of results of bit operations
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-06 17:14 --- The mainline gives: f: .LFB2: decq%rdx movl$1, %eax testq %rdi, %rdx jne .L4 xorl%eax, %eax testq %rsi, %rdx setne %al .L4: rep ; ret This is because of the improved PHI-OPT which I added but this is still not fully optimized. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-11-06 17:14:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24696
[Bug rtl-optimization/23837] [4.0/4.1 regression] Wrong code with -fschedule-insns
--- Comment #13 from danglin at gcc dot gnu dot org 2005-11-06 17:32 --- Fails on hppa2.0w-hp-hpux11.11 with 4.0.0, 4.0.1 and 4.0.2. However, it doesn't fail using 3.4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #9 from pcarlini at suse dot de 2005-11-06 17:36 --- Ok, I'm closing this, because the ABI, if not the standard, seems really unequivocal. About the warning, I don't know, probably it's not that easy to implement, I also looked for it, but no other compiler I have at hand apparently is able to emit it... -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug rtl-optimization/23837] [4.0/4.1 regression] Wrong code with -fschedule-insns
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2005-09-20 19:06:43 |2005-11-06 17:47:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug libffi/21229] LibFFI can't handle Longs
--- Comment #7 from green at redhat dot com 2005-11-06 17:51 --- I'm unable to reproduce this with GCC 4.0.1 (x86 Linux). Could you please try a more recent compiler? If you are able to reproduce, could you please submit your example in the form of a test case for the libffi testsuite? -- green at redhat dot com changed: What|Removed |Added CC||green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21229
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #10 from nathan at gcc dot gnu dot org 2005-11-06 17:54 --- A * is not a reference to an incomplete type, but a pointer to one, so 5.2.8.4 does not apply. I'm fairly certain the correct output should be 'OK'. The two type id objects should have different addresses (one should be weak, one should be local static). The typeid strings should have the same address (and be emitted weak) -- nathan at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug libstdc++/20647] Wrong typeid for incomplete types
-- nathan at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-06 17:54:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #11 from pcarlini at suse dot de 2005-11-06 17:57 --- Ah, ah, the addresses should be equal in the first place! Ok, thanks for looking into this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21308
[Bug libfortran/24174] real(10) array output broken
--- Comment #11 from jb at gcc dot gnu dot org 2005-11-06 18:28 --- Subject: Bug 24174 Author: jb Date: Sun Nov 6 18:28:22 2005 New Revision: 106563 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106563 Log: gfortran ChangeLog 2005-11-06 Janne Blomqvist [EMAIL PROTECTED] PR fortran/24174 PR fortran/24305 * fortran/trans-io.c (gfc_build_io_library_fndecls): Add kind argument to transfer_array. (transfer_array_desc): Add kind argument. testsuite ChangeLog: 2005-11-06 Janne Blomqvist [EMAIL PROTECTED] PR fortran/24174 PR fortran/24305 * testsuite/gfortran.dg/large_real_kind_form_io_1.f90: New file. libgfortran Changelog: 2005-11-06 Janne Blomqvist [EMAIL PROTECTED] PR fortran/24174 PR fortran/24305 * io/io.h: Add argument to prototypes, add prototypes for size_from_*_kind functions. * io/list_read.c (read_complex): Add size argument, use it. (list_formatted_read): Add size argument, cleanup. (list_formatted_read_scalar): Add size argument. (nml_read_obj): Fix for padding. * io/transfer.c: Add argument to transfer function pointer. (unformatted_read): Add size argument. (unformatted_write): Likewise. (formatted_transfer_scalar): Fix for padding with complex(10). (formatted_transfer): Add size argument, cleanup. (transfer_integer): Add size argument to transfer call. (transfer_real): Likewise. (transfer_logical): Likewise. (transfer_character): Likewise. (transfer_complex): Likewise. (transfer_array): New kind argument, use it. (data_transfer_init): Add size argument to formatted_transfer call. (iolength_transfer): Add size argument, cleanup. * io/write.c (write_complex): Add size argument, fix for padding with complex(10). (list_formatted_write): Add size argument, cleanup. (list_formatted_write_scalar): Add size argument, use it. (nml_write_obj): Fix for size vs. kind issue. * io/size_from_kind.c: New file. * Makefile.am: Add io/size_from_kind.c. * configure: Regenerate. * Makefile.in: Regenerate. Added: trunk/gcc/testsuite/gfortran.dg/large_real_kind_form_io_1.f90 trunk/libgfortran/io/size_from_kind.c Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/configure trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug libfortran/24305] Complex(10) formatted IO is broken.
--- Comment #3 from jb at gcc dot gnu dot org 2005-11-06 18:28 --- Subject: Bug 24305 Author: jb Date: Sun Nov 6 18:28:22 2005 New Revision: 106563 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106563 Log: gfortran ChangeLog 2005-11-06 Janne Blomqvist [EMAIL PROTECTED] PR fortran/24174 PR fortran/24305 * fortran/trans-io.c (gfc_build_io_library_fndecls): Add kind argument to transfer_array. (transfer_array_desc): Add kind argument. testsuite ChangeLog: 2005-11-06 Janne Blomqvist [EMAIL PROTECTED] PR fortran/24174 PR fortran/24305 * testsuite/gfortran.dg/large_real_kind_form_io_1.f90: New file. libgfortran Changelog: 2005-11-06 Janne Blomqvist [EMAIL PROTECTED] PR fortran/24174 PR fortran/24305 * io/io.h: Add argument to prototypes, add prototypes for size_from_*_kind functions. * io/list_read.c (read_complex): Add size argument, use it. (list_formatted_read): Add size argument, cleanup. (list_formatted_read_scalar): Add size argument. (nml_read_obj): Fix for padding. * io/transfer.c: Add argument to transfer function pointer. (unformatted_read): Add size argument. (unformatted_write): Likewise. (formatted_transfer_scalar): Fix for padding with complex(10). (formatted_transfer): Add size argument, cleanup. (transfer_integer): Add size argument to transfer call. (transfer_real): Likewise. (transfer_logical): Likewise. (transfer_character): Likewise. (transfer_complex): Likewise. (transfer_array): New kind argument, use it. (data_transfer_init): Add size argument to formatted_transfer call. (iolength_transfer): Add size argument, cleanup. * io/write.c (write_complex): Add size argument, fix for padding with complex(10). (list_formatted_write): Add size argument, cleanup. (list_formatted_write_scalar): Add size argument, use it. (nml_write_obj): Fix for size vs. kind issue. * io/size_from_kind.c: New file. * Makefile.am: Add io/size_from_kind.c. * configure: Regenerate. * Makefile.in: Regenerate. Added: trunk/gcc/testsuite/gfortran.dg/large_real_kind_form_io_1.f90 trunk/libgfortran/io/size_from_kind.c Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/configure trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24305
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #12 from frederic dot riss at gmail dot com 2005-11-06 18:35 --- When I read the standard, I thought that 'reference to a class type' was used in a sort of general way covering pointers and C++ references. I interpreted this that way because I don't see what difference it could make to a compiler and/or a developper that typeid(A*) is valid while typeid(A) isn't. So just for my personal knowledge, what could be the rationale behind this special casing ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug libffi/12782] ffi.h #defines ffi_type_[us]long wrong on 32bit arches
--- Comment #6 from green at redhat dot com 2005-11-06 18:41 --- Created an attachment (id=10159) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10159action=view) A patch I think the attached patch will fix. -- green at redhat dot com changed: What|Removed |Added Attachment #5005 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12782
[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-11-06 19:41 --- Subject: Bug 21308 Author: mmitchel Date: Sun Nov 6 19:41:18 2005 New Revision: 106566 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106566 Log: PR c++/21308 * class.c (sizeof_biggest_empty_class): New variable. (record_subobject_offsets): Don't record offsets past biggest empty class for data members. Replace vbases_p parameter with is_data_member parameter. (build_base_field): Adjust call. (layout_class_type): Likewise. Maintain sizeof_biggest_empty_class. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21308
[Bug java/24698] New: [4.1 regression] Apparent problem getting non-.class files out of jars
Sorry for the vague description and huge test case - I don't speak Java beyond
the it looks a lot like C++ level.
Trying to use a gcj 4.1 SVN rev 106562-compiled ecj (built using the workaround
from bug 24441) results in a SIGABRT when trying to translate any .java file
(even a simple helloworld.java).
strace-ing the output indicates it can't locate the compiler messages, which
are in messages.properties, which is definitely included in the .jar and the
.jar is in the classpath. Looks like gcj/gij look for a messages.class file
instead.
Relevant parts of strace output:
* open(/usr/lib/libeclipse-ecj.so, O_RDONLY) = 3
--- It finds the precompiled version [the problem doesn't go away if I delete
that and use the .jar only]
* stat64(/usr/share/java/eclipse-ecj.jar, {st_mode=S_IFREG|0644,
st_size=905576, ...}) = 0
* open(/usr/share/java/eclipse-ecj.jar, O_RDONLY|O_LARGEFILE) = 9
--- It finds and reads the jar file nevertheless
* open(/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.la,
O_RDONLY) = -1 ENOENT (No such file or directory)
*
open(/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.la,
O_RDONLY) = -1 ENOENT (No such file or directory)
* open(lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.la,
O_RDONLY) = -1 ENOENT (No such file or directory)
* access(/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.so,
R_OK) = -1 ENOENT (No such file or directory)
*
access(/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.so,
R_OK) = -1 ENOENT (No such file or directory)
* open(/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.so,
O_RDONLY) = -1 ENOENT (No such file or directory)
*
open(/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.so,
O_RDONLY) = -1 ENOENT (No such file or directory)
*
access(/home/arklinux/./org/eclipse/jdt/internal/compiler/batch/messages_en.properties,
F_OK) = -1 ENOENT (No such file or directory)
* open(/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.la,
O_RDONLY) = -1 ENOENT (No such file or directory)
* open(/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.la,
O_RDONLY) = -1 ENOENT (No such file or directory)
* open(lib-org-eclipse-jdt-internal-compiler-batch-messages.la, O_RDONLY) =
-1 ENOENT (No such file or directory)
* access(/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.so, R_OK)
= -1 ENOENT (No such file or directory)
* access(/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.so,
R_OK) = -1 ENOENT (No such file or directory)
* open(/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.so,
O_RDONLY) = -1 ENOENT (No such file or directory)
* open(/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.so,
O_RDONLY) = -1 ENOENT (No such file or directory)
access(/home/arklinux/./org/eclipse/jdt/internal/compiler/batch/messages.class,
F_OK) = -1 ENOENT (No such file or directory)
--- It looks for org.eclipse.jdt.internal.compiler.batch.messages* in various
places without finding anything, insisting it's supposed to be a .class when
it's in fact looking for messages.properties
[strace-ing the 4.0.x generated version confirms messages.properties is what
it's looking for].
$ jar tfv eclipse-ecj.jar |grep compiler/util/messages
2764 Wed Jan 12 00:13:34 CET 2005
org/eclipse/jdt/internal/compiler/util/messages.properties
The same code (and build process) works nicely if gcj/gij 4.0.x is used.
--
Summary: [4.1 regression] Apparent problem getting non-.class
files out of jars
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698
[Bug c++/18462] [3.4 Regression] Segfault on declaration of large array member
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-11-06 19:53 --- *** This bug has been marked as a duplicate of 21308 *** -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18462
[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-11-06 19:53 --- *** Bug 18462 has been marked as a duplicate of this bug. *** -- Bug 21308 depends on bug 18462, which changed state. Bug 18462 Summary: [3.4 Regression] Segfault on declaration of large array member http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18462 What|Old Value |New Value Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21308
[Bug c++/21308] [3.4/4.0 Regression] Very high compile time
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-11-06 19:56 --- Fixed in 4.1.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[3.4/4.0/4.1 Regression]|[3.4/4.0 Regression] Very |Very high compile time |high compile time http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21308
[Bug c++/24686] [4.0/4.1 Regression] ICE when building a variation of NMSTL
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-11-06 19:59 --- Showstopper; crash on valid code. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug fortran/20838] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:3606
--- Comment #3 from pault at gcc dot gnu dot org 2005-11-06 20:05 ---
Subject: Bug 20838
Author: pault
Date: Sun Nov 6 20:05:12 2005
New Revision: 106567
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106567
Log:
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
* resolve.c (resolve_symbol): Exclude case of PRIVATE declared
within derived type from error associated with PRIVATE type
components within derived type.
PR fortran/20838
PR fortran/20840
* gfortran.h: Add prototype for gfc_has_vector_index.
* io.c (gfc_resolve_dt): Error if internal unit has a vector index.
* expr.c (gfc_has_vector_index): New function to check if any of
the array references of an expression have vector inidices.
(gfc_check_pointer_assign): Error if internal unit has a vector index.
PR fortran/17737
* data.c (gfc_assign_data_value): Remove gcc_assert that caused the ICE
and replace by a standard dependent warning/error if overwriting an
existing initialization.
* decl.c (gfc_data_variable): Remove old error for already initialized
variable and the unused error check for common block variables. Add
error for hots associated variable and standard dependent error for
common block variables, outside of blockdata.
* symbol.c (check_conflict): Add constraints for DATA statement.
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
gfortran.dg/private_type_2.f90: Modified to check that case with
PRIVATE declaration within derived type is accepted.
PR fortran/20838
gfortran.dg/pointer_assign_1.f90: New test.
PR fortran/20840
* gfortran.dg/arrayio_0.f90: New test.
PR fortran/17737
gfortran.dg/data_initialized.f90: New test.
gfortran.dg/data_constraints_1.f90: New test.
gfortran.dg/data_constraints_2.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/data_constraints_1.f90
trunk/gcc/testsuite/gfortran.dg/data_constraints_2.f90
trunk/gcc/testsuite/gfortran.dg/data_initialized.f90
trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 (with props)
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/data.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/io.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/private_type_2.f90
Added: trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90?root=gccview=autorev=106567
==
--- trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90 Sun Nov 6 20:05:12 2005
@@ -1,0 +1,19 @@
+! { dg-do compile }
+! Tests fix for PR20840 - would ICE with vector subscript in
+! internal unit.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ character(len=12), dimension(4) :: iu, buff
+ character(len=48), dimension(2) :: iue
+ equivalence (iu, iue)
+ integer, dimension(4) :: v = (/2,1,4,3/)
+ iu = (/Vector,subscripts,not,allowed!/)
+ read (iu, '(a12/)') buff
+ read (iue(1), '(4a12)') buff
+ read (iu(4:1:-1), '(a12/)') buff
+ read (iu(v), '(a12/)') buff ! { dg-error with vector subscript }
+ read (iu((/2,4,3,1/)), '(a12/)') buff ! { dg-error with vector subscript }
+ print *, buff
+ end
+
Propchange: trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90
('svn:executable' added)
Added: trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90?root=gccview=autorev=106567
==
--- trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 Sun Nov 6 20:05:12
2005
@@ -1,0 +1,17 @@
+! { dg-do compile }
+! Tests fix for PR20838 - would ICE with vector subscript in
+! pointer assignment.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ integer, parameter, dimension(3) :: i = (/2,1,3/)
+ integer, dimension(3), target :: tar
+ integer, dimension(2, 3), target :: tar2
+ integer, dimension(:), pointer :: ptr
+ ptr = tar
+ ptr = tar(3:1:-1)
+ ptr = tar(i) ! { dg-error with vector subscript }
+ ptr = tar2(1, :)
+ ptr = tar2(2, i) ! { dg-error with vector subscript }
+ end
+
Propchange: trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
('svn:executable' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20838
[Bug fortran/17737] ICE when variable appears in two data statements
--- Comment #11 from pault at gcc dot gnu dot org 2005-11-06 20:05 ---
Subject: Bug 17737
Author: pault
Date: Sun Nov 6 20:05:12 2005
New Revision: 106567
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106567
Log:
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
* resolve.c (resolve_symbol): Exclude case of PRIVATE declared
within derived type from error associated with PRIVATE type
components within derived type.
PR fortran/20838
PR fortran/20840
* gfortran.h: Add prototype for gfc_has_vector_index.
* io.c (gfc_resolve_dt): Error if internal unit has a vector index.
* expr.c (gfc_has_vector_index): New function to check if any of
the array references of an expression have vector inidices.
(gfc_check_pointer_assign): Error if internal unit has a vector index.
PR fortran/17737
* data.c (gfc_assign_data_value): Remove gcc_assert that caused the ICE
and replace by a standard dependent warning/error if overwriting an
existing initialization.
* decl.c (gfc_data_variable): Remove old error for already initialized
variable and the unused error check for common block variables. Add
error for hots associated variable and standard dependent error for
common block variables, outside of blockdata.
* symbol.c (check_conflict): Add constraints for DATA statement.
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
gfortran.dg/private_type_2.f90: Modified to check that case with
PRIVATE declaration within derived type is accepted.
PR fortran/20838
gfortran.dg/pointer_assign_1.f90: New test.
PR fortran/20840
* gfortran.dg/arrayio_0.f90: New test.
PR fortran/17737
gfortran.dg/data_initialized.f90: New test.
gfortran.dg/data_constraints_1.f90: New test.
gfortran.dg/data_constraints_2.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/data_constraints_1.f90
trunk/gcc/testsuite/gfortran.dg/data_constraints_2.f90
trunk/gcc/testsuite/gfortran.dg/data_initialized.f90
trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 (with props)
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/data.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/io.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/private_type_2.f90
Added: trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90?root=gccview=autorev=106567
==
--- trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90 Sun Nov 6 20:05:12 2005
@@ -1,0 +1,19 @@
+! { dg-do compile }
+! Tests fix for PR20840 - would ICE with vector subscript in
+! internal unit.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ character(len=12), dimension(4) :: iu, buff
+ character(len=48), dimension(2) :: iue
+ equivalence (iu, iue)
+ integer, dimension(4) :: v = (/2,1,4,3/)
+ iu = (/Vector,subscripts,not,allowed!/)
+ read (iu, '(a12/)') buff
+ read (iue(1), '(4a12)') buff
+ read (iu(4:1:-1), '(a12/)') buff
+ read (iu(v), '(a12/)') buff ! { dg-error with vector subscript }
+ read (iu((/2,4,3,1/)), '(a12/)') buff ! { dg-error with vector subscript }
+ print *, buff
+ end
+
Propchange: trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90
('svn:executable' added)
Added: trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90?root=gccview=autorev=106567
==
--- trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 Sun Nov 6 20:05:12
2005
@@ -1,0 +1,17 @@
+! { dg-do compile }
+! Tests fix for PR20838 - would ICE with vector subscript in
+! pointer assignment.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ integer, parameter, dimension(3) :: i = (/2,1,3/)
+ integer, dimension(3), target :: tar
+ integer, dimension(2, 3), target :: tar2
+ integer, dimension(:), pointer :: ptr
+ ptr = tar
+ ptr = tar(3:1:-1)
+ ptr = tar(i) ! { dg-error with vector subscript }
+ ptr = tar2(1, :)
+ ptr = tar2(2, i) ! { dg-error with vector subscript }
+ end
+
Propchange: trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
('svn:executable' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17737
[Bug fortran/20840] accepts vector subscript on internal file
--- Comment #3 from pault at gcc dot gnu dot org 2005-11-06 20:05 ---
Subject: Bug 20840
Author: pault
Date: Sun Nov 6 20:05:12 2005
New Revision: 106567
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106567
Log:
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
* resolve.c (resolve_symbol): Exclude case of PRIVATE declared
within derived type from error associated with PRIVATE type
components within derived type.
PR fortran/20838
PR fortran/20840
* gfortran.h: Add prototype for gfc_has_vector_index.
* io.c (gfc_resolve_dt): Error if internal unit has a vector index.
* expr.c (gfc_has_vector_index): New function to check if any of
the array references of an expression have vector inidices.
(gfc_check_pointer_assign): Error if internal unit has a vector index.
PR fortran/17737
* data.c (gfc_assign_data_value): Remove gcc_assert that caused the ICE
and replace by a standard dependent warning/error if overwriting an
existing initialization.
* decl.c (gfc_data_variable): Remove old error for already initialized
variable and the unused error check for common block variables. Add
error for hots associated variable and standard dependent error for
common block variables, outside of blockdata.
* symbol.c (check_conflict): Add constraints for DATA statement.
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
gfortran.dg/private_type_2.f90: Modified to check that case with
PRIVATE declaration within derived type is accepted.
PR fortran/20838
gfortran.dg/pointer_assign_1.f90: New test.
PR fortran/20840
* gfortran.dg/arrayio_0.f90: New test.
PR fortran/17737
gfortran.dg/data_initialized.f90: New test.
gfortran.dg/data_constraints_1.f90: New test.
gfortran.dg/data_constraints_2.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/data_constraints_1.f90
trunk/gcc/testsuite/gfortran.dg/data_constraints_2.f90
trunk/gcc/testsuite/gfortran.dg/data_initialized.f90
trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 (with props)
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/data.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/io.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/private_type_2.f90
Added: trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90?root=gccview=autorev=106567
==
--- trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90 Sun Nov 6 20:05:12 2005
@@ -1,0 +1,19 @@
+! { dg-do compile }
+! Tests fix for PR20840 - would ICE with vector subscript in
+! internal unit.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ character(len=12), dimension(4) :: iu, buff
+ character(len=48), dimension(2) :: iue
+ equivalence (iu, iue)
+ integer, dimension(4) :: v = (/2,1,4,3/)
+ iu = (/Vector,subscripts,not,allowed!/)
+ read (iu, '(a12/)') buff
+ read (iue(1), '(4a12)') buff
+ read (iu(4:1:-1), '(a12/)') buff
+ read (iu(v), '(a12/)') buff ! { dg-error with vector subscript }
+ read (iu((/2,4,3,1/)), '(a12/)') buff ! { dg-error with vector subscript }
+ print *, buff
+ end
+
Propchange: trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90
('svn:executable' added)
Added: trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90?root=gccview=autorev=106567
==
--- trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 Sun Nov 6 20:05:12
2005
@@ -1,0 +1,17 @@
+! { dg-do compile }
+! Tests fix for PR20838 - would ICE with vector subscript in
+! pointer assignment.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ integer, parameter, dimension(3) :: i = (/2,1,3/)
+ integer, dimension(3), target :: tar
+ integer, dimension(2, 3), target :: tar2
+ integer, dimension(:), pointer :: ptr
+ ptr = tar
+ ptr = tar(3:1:-1)
+ ptr = tar(i) ! { dg-error with vector subscript }
+ ptr = tar2(1, :)
+ ptr = tar2(2, i) ! { dg-error with vector subscript }
+ end
+
Propchange: trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
('svn:executable' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20840
[Bug fortran/24534] [4.0/4.1 Regression] PUBLIC derived types with private components
--- Comment #9 from pault at gcc dot gnu dot org 2005-11-06 20:05 ---
Subject: Bug 24534
Author: pault
Date: Sun Nov 6 20:05:12 2005
New Revision: 106567
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106567
Log:
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
* resolve.c (resolve_symbol): Exclude case of PRIVATE declared
within derived type from error associated with PRIVATE type
components within derived type.
PR fortran/20838
PR fortran/20840
* gfortran.h: Add prototype for gfc_has_vector_index.
* io.c (gfc_resolve_dt): Error if internal unit has a vector index.
* expr.c (gfc_has_vector_index): New function to check if any of
the array references of an expression have vector inidices.
(gfc_check_pointer_assign): Error if internal unit has a vector index.
PR fortran/17737
* data.c (gfc_assign_data_value): Remove gcc_assert that caused the ICE
and replace by a standard dependent warning/error if overwriting an
existing initialization.
* decl.c (gfc_data_variable): Remove old error for already initialized
variable and the unused error check for common block variables. Add
error for hots associated variable and standard dependent error for
common block variables, outside of blockdata.
* symbol.c (check_conflict): Add constraints for DATA statement.
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
gfortran.dg/private_type_2.f90: Modified to check that case with
PRIVATE declaration within derived type is accepted.
PR fortran/20838
gfortran.dg/pointer_assign_1.f90: New test.
PR fortran/20840
* gfortran.dg/arrayio_0.f90: New test.
PR fortran/17737
gfortran.dg/data_initialized.f90: New test.
gfortran.dg/data_constraints_1.f90: New test.
gfortran.dg/data_constraints_2.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/data_constraints_1.f90
trunk/gcc/testsuite/gfortran.dg/data_constraints_2.f90
trunk/gcc/testsuite/gfortran.dg/data_initialized.f90
trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 (with props)
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/data.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/io.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/private_type_2.f90
Added: trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90?root=gccview=autorev=106567
==
--- trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90 Sun Nov 6 20:05:12 2005
@@ -1,0 +1,19 @@
+! { dg-do compile }
+! Tests fix for PR20840 - would ICE with vector subscript in
+! internal unit.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ character(len=12), dimension(4) :: iu, buff
+ character(len=48), dimension(2) :: iue
+ equivalence (iu, iue)
+ integer, dimension(4) :: v = (/2,1,4,3/)
+ iu = (/Vector,subscripts,not,allowed!/)
+ read (iu, '(a12/)') buff
+ read (iue(1), '(4a12)') buff
+ read (iu(4:1:-1), '(a12/)') buff
+ read (iu(v), '(a12/)') buff ! { dg-error with vector subscript }
+ read (iu((/2,4,3,1/)), '(a12/)') buff ! { dg-error with vector subscript }
+ print *, buff
+ end
+
Propchange: trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90
('svn:executable' added)
Added: trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90?root=gccview=autorev=106567
==
--- trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 Sun Nov 6 20:05:12
2005
@@ -1,0 +1,17 @@
+! { dg-do compile }
+! Tests fix for PR20838 - would ICE with vector subscript in
+! pointer assignment.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ integer, parameter, dimension(3) :: i = (/2,1,3/)
+ integer, dimension(3), target :: tar
+ integer, dimension(2, 3), target :: tar2
+ integer, dimension(:), pointer :: ptr
+ ptr = tar
+ ptr = tar(3:1:-1)
+ ptr = tar(i) ! { dg-error with vector subscript }
+ ptr = tar2(1, :)
+ ptr = tar2(2, i) ! { dg-error with vector subscript }
+ end
+
Propchange: trunk/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
('svn:executable' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24534
[Bug debug/22313] [4.1 Regression] gcc HEAD as of 2005/07/05 fails to profiledbootstrap
--- Comment #11 from halcy0n at gentoo dot org 2005-11-06 20:29 ---
This is reproducable on gcc mainline on amd64:
{standard input}: Assembler messages:
{standard input}:510: Error: can't resolve `.text.unlikely' {.text.unlikely
section} - `.LFB96' {.text section}
Building gcc-4.1.0_beta20051105 with gcc-4.0.2, with binutils 2.16.91.0.3.
Same error with binutils-2.16.1 as well.
--
halcy0n at gentoo dot org changed:
What|Removed |Added
CC||halcy0n at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug fortran/20838] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:3606
--- Comment #4 from pault at gcc dot gnu dot org 2005-11-06 22:50 ---
Subject: Bug 20838
Author: pault
Date: Sun Nov 6 22:50:38 2005
New Revision: 106572
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106572
Log:
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
* resolve.c (resolve_symbol): Exclude case of PRIVATE declared
within derived type from error associated with PRIVATE type
components within derived type.
PR fortran/20838
PR fortran/20840
* gfortran.h: Add prototype for gfc_has_vector_index.
* io.c (gfc_resolve_dt): Error if internal unit has a vector index.
* expr.c (gfc_has_vector_index): New function to check if any of
the array references of an expression have vector inidices.
(gfc_check_pointer_assign): Error if internal unit has a vector index.
PR fortran/17737
* data.c (gfc_assign_data_value): Remove gcc_assert that caused the ICE
and replace by a standard dependent warning/error if overwriting an
existing initialization.
* decl.c (gfc_data_variable): Remove old error for already initialized
variable and the unused error check for common block variables. Add
error for host associated variable and standard dependent error for
common block variables, outside of blockdata.
* symbol.c (check_conflict): Add constraints for DATA statement.
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
gfortran.dg/private_type_2.f90: Modified to check that case with
PRIVATE declaration within derived type is accepted.
PR fortran/20838
gfortran.dg/pointer_assign_1.f90: New test.
PR fortran/20840
* gfortran.dg/arrayio_0.f90: New test.
PR fortran/17737
gfortran.dg/data_initialized.f90: New test.
gfortran.dg/data_constraints_1.f90: New test.
gfortran.dg/data_constraints_2.f90: New test.
Added:
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90 (with
props)
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/data_constraints_1.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/data_constraints_2.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/data_initialized.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
(with props)
Modified:
branches/gcc-4_0-branch/gcc/fortran/ChangeLog
branches/gcc-4_0-branch/gcc/fortran/data.c
branches/gcc-4_0-branch/gcc/fortran/decl.c
branches/gcc-4_0-branch/gcc/fortran/expr.c
branches/gcc-4_0-branch/gcc/fortran/gfortran.h
branches/gcc-4_0-branch/gcc/fortran/io.c
branches/gcc-4_0-branch/gcc/fortran/resolve.c
branches/gcc-4_0-branch/gcc/fortran/symbol.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/private_type_2.f90
Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90
URL:
http://gcc.gnu.org/viewcvs/branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90?root=gccview=autorev=106572
==
--- branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90 (added)
+++ branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90 Sun Nov 6
22:50:38 2005
@@ -1,0 +1,19 @@
+! { dg-do compile }
+! Tests fix for PR20840 - would ICE with vector subscript in
+! internal unit.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ character(len=12), dimension(4) :: iu, buff
+ character(len=48), dimension(2) :: iue
+ equivalence (iu, iue)
+ integer, dimension(4) :: v = (/2,1,4,3/)
+ iu = (/Vector,subscripts,not,allowed!/)
+ read (iu, '(a12/)') buff
+ read (iue(1), '(4a12)') buff
+ read (iu(4:1:-1), '(a12/)') buff
+ read (iu(v), '(a12/)') buff ! { dg-error with vector subscript }
+ read (iu((/2,4,3,1/)), '(a12/)') buff ! { dg-error with vector subscript }
+ print *, buff
+ end
+
Propchange: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90
('svn:executable' added)
Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
URL:
http://gcc.gnu.org/viewcvs/branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90?root=gccview=autorev=106572
==
--- branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
(added)
+++ branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 Sun
Nov 6 22:50:38 2005
@@ -1,0 +1,17 @@
+! { dg-do compile }
+! Tests fix for PR20838 - would ICE with vector subscript in
+! pointer assignment.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ integer, parameter, dimension(3) :: i = (/2,1,3/)
+ integer, dimension(3), target :: tar
+ integer, dimension(2, 3), target :: tar2
+ integer, dimension(:), pointer :: ptr
+ ptr = tar
+
[Bug fortran/24534] [4.0/4.1 Regression] PUBLIC derived types with private components
--- Comment #10 from pault at gcc dot gnu dot org 2005-11-06 22:50 ---
Subject: Bug 24534
Author: pault
Date: Sun Nov 6 22:50:38 2005
New Revision: 106572
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106572
Log:
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
* resolve.c (resolve_symbol): Exclude case of PRIVATE declared
within derived type from error associated with PRIVATE type
components within derived type.
PR fortran/20838
PR fortran/20840
* gfortran.h: Add prototype for gfc_has_vector_index.
* io.c (gfc_resolve_dt): Error if internal unit has a vector index.
* expr.c (gfc_has_vector_index): New function to check if any of
the array references of an expression have vector inidices.
(gfc_check_pointer_assign): Error if internal unit has a vector index.
PR fortran/17737
* data.c (gfc_assign_data_value): Remove gcc_assert that caused the ICE
and replace by a standard dependent warning/error if overwriting an
existing initialization.
* decl.c (gfc_data_variable): Remove old error for already initialized
variable and the unused error check for common block variables. Add
error for host associated variable and standard dependent error for
common block variables, outside of blockdata.
* symbol.c (check_conflict): Add constraints for DATA statement.
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
gfortran.dg/private_type_2.f90: Modified to check that case with
PRIVATE declaration within derived type is accepted.
PR fortran/20838
gfortran.dg/pointer_assign_1.f90: New test.
PR fortran/20840
* gfortran.dg/arrayio_0.f90: New test.
PR fortran/17737
gfortran.dg/data_initialized.f90: New test.
gfortran.dg/data_constraints_1.f90: New test.
gfortran.dg/data_constraints_2.f90: New test.
Added:
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90 (with
props)
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/data_constraints_1.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/data_constraints_2.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/data_initialized.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
(with props)
Modified:
branches/gcc-4_0-branch/gcc/fortran/ChangeLog
branches/gcc-4_0-branch/gcc/fortran/data.c
branches/gcc-4_0-branch/gcc/fortran/decl.c
branches/gcc-4_0-branch/gcc/fortran/expr.c
branches/gcc-4_0-branch/gcc/fortran/gfortran.h
branches/gcc-4_0-branch/gcc/fortran/io.c
branches/gcc-4_0-branch/gcc/fortran/resolve.c
branches/gcc-4_0-branch/gcc/fortran/symbol.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/private_type_2.f90
Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90
URL:
http://gcc.gnu.org/viewcvs/branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90?root=gccview=autorev=106572
==
--- branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90 (added)
+++ branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90 Sun Nov 6
22:50:38 2005
@@ -1,0 +1,19 @@
+! { dg-do compile }
+! Tests fix for PR20840 - would ICE with vector subscript in
+! internal unit.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ character(len=12), dimension(4) :: iu, buff
+ character(len=48), dimension(2) :: iue
+ equivalence (iu, iue)
+ integer, dimension(4) :: v = (/2,1,4,3/)
+ iu = (/Vector,subscripts,not,allowed!/)
+ read (iu, '(a12/)') buff
+ read (iue(1), '(4a12)') buff
+ read (iu(4:1:-1), '(a12/)') buff
+ read (iu(v), '(a12/)') buff ! { dg-error with vector subscript }
+ read (iu((/2,4,3,1/)), '(a12/)') buff ! { dg-error with vector subscript }
+ print *, buff
+ end
+
Propchange: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90
('svn:executable' added)
Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
URL:
http://gcc.gnu.org/viewcvs/branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90?root=gccview=autorev=106572
==
--- branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
(added)
+++ branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 Sun
Nov 6 22:50:38 2005
@@ -1,0 +1,17 @@
+! { dg-do compile }
+! Tests fix for PR20838 - would ICE with vector subscript in
+! pointer assignment.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ integer, parameter, dimension(3) :: i = (/2,1,3/)
+ integer, dimension(3), target :: tar
+ integer, dimension(2, 3), target :: tar2
+ integer, dimension(:), pointer :: ptr
+ ptr = tar
+
[Bug fortran/17737] ICE when variable appears in two data statements
--- Comment #12 from pault at gcc dot gnu dot org 2005-11-06 22:50 ---
Subject: Bug 17737
Author: pault
Date: Sun Nov 6 22:50:38 2005
New Revision: 106572
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106572
Log:
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
* resolve.c (resolve_symbol): Exclude case of PRIVATE declared
within derived type from error associated with PRIVATE type
components within derived type.
PR fortran/20838
PR fortran/20840
* gfortran.h: Add prototype for gfc_has_vector_index.
* io.c (gfc_resolve_dt): Error if internal unit has a vector index.
* expr.c (gfc_has_vector_index): New function to check if any of
the array references of an expression have vector inidices.
(gfc_check_pointer_assign): Error if internal unit has a vector index.
PR fortran/17737
* data.c (gfc_assign_data_value): Remove gcc_assert that caused the ICE
and replace by a standard dependent warning/error if overwriting an
existing initialization.
* decl.c (gfc_data_variable): Remove old error for already initialized
variable and the unused error check for common block variables. Add
error for host associated variable and standard dependent error for
common block variables, outside of blockdata.
* symbol.c (check_conflict): Add constraints for DATA statement.
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
gfortran.dg/private_type_2.f90: Modified to check that case with
PRIVATE declaration within derived type is accepted.
PR fortran/20838
gfortran.dg/pointer_assign_1.f90: New test.
PR fortran/20840
* gfortran.dg/arrayio_0.f90: New test.
PR fortran/17737
gfortran.dg/data_initialized.f90: New test.
gfortran.dg/data_constraints_1.f90: New test.
gfortran.dg/data_constraints_2.f90: New test.
Added:
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90 (with
props)
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/data_constraints_1.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/data_constraints_2.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/data_initialized.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
(with props)
Modified:
branches/gcc-4_0-branch/gcc/fortran/ChangeLog
branches/gcc-4_0-branch/gcc/fortran/data.c
branches/gcc-4_0-branch/gcc/fortran/decl.c
branches/gcc-4_0-branch/gcc/fortran/expr.c
branches/gcc-4_0-branch/gcc/fortran/gfortran.h
branches/gcc-4_0-branch/gcc/fortran/io.c
branches/gcc-4_0-branch/gcc/fortran/resolve.c
branches/gcc-4_0-branch/gcc/fortran/symbol.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/private_type_2.f90
Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90
URL:
http://gcc.gnu.org/viewcvs/branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90?root=gccview=autorev=106572
==
--- branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90 (added)
+++ branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90 Sun Nov 6
22:50:38 2005
@@ -1,0 +1,19 @@
+! { dg-do compile }
+! Tests fix for PR20840 - would ICE with vector subscript in
+! internal unit.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ character(len=12), dimension(4) :: iu, buff
+ character(len=48), dimension(2) :: iue
+ equivalence (iu, iue)
+ integer, dimension(4) :: v = (/2,1,4,3/)
+ iu = (/Vector,subscripts,not,allowed!/)
+ read (iu, '(a12/)') buff
+ read (iue(1), '(4a12)') buff
+ read (iu(4:1:-1), '(a12/)') buff
+ read (iu(v), '(a12/)') buff ! { dg-error with vector subscript }
+ read (iu((/2,4,3,1/)), '(a12/)') buff ! { dg-error with vector subscript }
+ print *, buff
+ end
+
Propchange: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90
('svn:executable' added)
Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
URL:
http://gcc.gnu.org/viewcvs/branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90?root=gccview=autorev=106572
==
--- branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
(added)
+++ branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 Sun
Nov 6 22:50:38 2005
@@ -1,0 +1,17 @@
+! { dg-do compile }
+! Tests fix for PR20838 - would ICE with vector subscript in
+! pointer assignment.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ integer, parameter, dimension(3) :: i = (/2,1,3/)
+ integer, dimension(3), target :: tar
+ integer, dimension(2, 3), target :: tar2
+ integer, dimension(:), pointer :: ptr
+ ptr = tar
+
[Bug fortran/20840] accepts vector subscript on internal file
--- Comment #4 from pault at gcc dot gnu dot org 2005-11-06 22:50 ---
Subject: Bug 20840
Author: pault
Date: Sun Nov 6 22:50:38 2005
New Revision: 106572
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106572
Log:
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
* resolve.c (resolve_symbol): Exclude case of PRIVATE declared
within derived type from error associated with PRIVATE type
components within derived type.
PR fortran/20838
PR fortran/20840
* gfortran.h: Add prototype for gfc_has_vector_index.
* io.c (gfc_resolve_dt): Error if internal unit has a vector index.
* expr.c (gfc_has_vector_index): New function to check if any of
the array references of an expression have vector inidices.
(gfc_check_pointer_assign): Error if internal unit has a vector index.
PR fortran/17737
* data.c (gfc_assign_data_value): Remove gcc_assert that caused the ICE
and replace by a standard dependent warning/error if overwriting an
existing initialization.
* decl.c (gfc_data_variable): Remove old error for already initialized
variable and the unused error check for common block variables. Add
error for host associated variable and standard dependent error for
common block variables, outside of blockdata.
* symbol.c (check_conflict): Add constraints for DATA statement.
2005-11-06 Paul Thomas [EMAIL PROTECTED]
PR fortran/24534
gfortran.dg/private_type_2.f90: Modified to check that case with
PRIVATE declaration within derived type is accepted.
PR fortran/20838
gfortran.dg/pointer_assign_1.f90: New test.
PR fortran/20840
* gfortran.dg/arrayio_0.f90: New test.
PR fortran/17737
gfortran.dg/data_initialized.f90: New test.
gfortran.dg/data_constraints_1.f90: New test.
gfortran.dg/data_constraints_2.f90: New test.
Added:
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90 (with
props)
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/data_constraints_1.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/data_constraints_2.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/data_initialized.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
(with props)
Modified:
branches/gcc-4_0-branch/gcc/fortran/ChangeLog
branches/gcc-4_0-branch/gcc/fortran/data.c
branches/gcc-4_0-branch/gcc/fortran/decl.c
branches/gcc-4_0-branch/gcc/fortran/expr.c
branches/gcc-4_0-branch/gcc/fortran/gfortran.h
branches/gcc-4_0-branch/gcc/fortran/io.c
branches/gcc-4_0-branch/gcc/fortran/resolve.c
branches/gcc-4_0-branch/gcc/fortran/symbol.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/private_type_2.f90
Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90
URL:
http://gcc.gnu.org/viewcvs/branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90?root=gccview=autorev=106572
==
--- branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90 (added)
+++ branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90 Sun Nov 6
22:50:38 2005
@@ -1,0 +1,19 @@
+! { dg-do compile }
+! Tests fix for PR20840 - would ICE with vector subscript in
+! internal unit.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ character(len=12), dimension(4) :: iu, buff
+ character(len=48), dimension(2) :: iue
+ equivalence (iu, iue)
+ integer, dimension(4) :: v = (/2,1,4,3/)
+ iu = (/Vector,subscripts,not,allowed!/)
+ read (iu, '(a12/)') buff
+ read (iue(1), '(4a12)') buff
+ read (iu(4:1:-1), '(a12/)') buff
+ read (iu(v), '(a12/)') buff ! { dg-error with vector subscript }
+ read (iu((/2,4,3,1/)), '(a12/)') buff ! { dg-error with vector subscript }
+ print *, buff
+ end
+
Propchange: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/arrayio_0.f90
('svn:executable' added)
Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
URL:
http://gcc.gnu.org/viewcvs/branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90?root=gccview=autorev=106572
==
--- branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90
(added)
+++ branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pointer_assign_1.f90 Sun
Nov 6 22:50:38 2005
@@ -1,0 +1,17 @@
+! { dg-do compile }
+! Tests fix for PR20838 - would ICE with vector subscript in
+! pointer assignment.
+!
+! Contributed by Paul Thomas [EMAIL PROTECTED]
+!
+ integer, parameter, dimension(3) :: i = (/2,1,3/)
+ integer, dimension(3), target :: tar
+ integer, dimension(2, 3), target :: tar2
+ integer, dimension(:), pointer :: ptr
+ ptr = tar
+
[Bug fortran/24534] [4.0/4.1 Regression] PUBLIC derived types with private components
--- Comment #11 from pault at gcc dot gnu dot org 2005-11-06 22:51 --- Fixed on mainline and 4.0. -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24534
[Bug fortran/20838] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:3606
--- Comment #5 from pault at gcc dot gnu dot org 2005-11-06 22:53 --- Fixed on mainline and 4.0 -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20838
[Bug fortran/20840] accepts vector subscript on internal file
--- Comment #5 from pault at gcc dot gnu dot org 2005-11-06 22:54 --- Fixed on mainline and 4.0 -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20840
[Bug fortran/17737] ICE when variable appears in two data statements
--- Comment #13 from pault at gcc dot gnu dot org 2005-11-06 22:55 --- Fixed on mainline and 4.0 -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17737
[Bug c++/24687] [4.1 Regression] ICE after error
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-06 23:21 --- The CONST_DECL's type is null. Seems like it should be error_mark_node instead. Looking more into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24687
[Bug c++/24687] [4.1 Regression] ICE after error
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-06 23:23 --- Actually it should be NULL as it is in a template. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24687
[Bug c++/24687] [4.1 Regression] ICE after error
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-06 23:27 --- I have a patch. Caused by: 2005-07-14 Daniel Berlin [EMAIL PROTECTED] Fix PR c++/22452 * tree.c (decl_linkage): Don't check DECL_COMDAT on CONST_DECL. -- 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 |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-06 23:27:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24687
[Bug other/24692] Atomic builtins for v3
--- Comment #5 from rth at gcc dot gnu dot org 2005-11-06 23:40 --- http://gcc.gnu.org/ml/gcc/2005-11/msg00326.html In short, you'll never get a completely unified way to implement these routines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug libfortran/24699] New: READ with T format specifier fails on end-of-record condition
The following reduced test case fails to correctly read the same line twice from the input file. This was derived from the new Polyhedron test aermod.f90 which fails. character*132 :: rdfrm, runst1, foost character*1 :: runst(132) inunit = 11 open (inunit, file = AERMODTEST.INP) RDFRM = (A080,T1,080A) ! read the same line twice READ (INUNIT, '(A080,T1,080A)', end = 999) RUNST1 , foost write (*,'(a80)') runst1 write (*,'(a80)') foost READ (INUNIT, '(A080,T1,080A)', end = 999) RUNST1 , foost write (*,'(a80)') runst1 write (*,'(a80)') foost READ (INUNIT, '(A080,T1,080A)', end = 999) RUNST1 , foost write (*,'(a80)') runst1 write (*,'(a80)') foost goto 1000 999 call exit () 1000 continue end The input file is: $ cat AERMODTEST.INP CO STARTING TITLEONE A Simple Example Problem for the AERMOD Model with PRIME MODELOPT CONC FLAT AVERTIME 3 24 PERIOD POLLUTID SO2 RUNORNOT RUN CO FINISHED -- Summary: READ with T format specifier fails on end-of-record condition Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: jvdelisle at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24699
[Bug libfortran/24700] New: Bad write after backing up from end of file
The following program from http://gcc.gnu.org/ml/fortran/2005-11/msg00084.html
incorrectly writesthe 'TEST' file. Thanks to Georgy Salnikov for finding and
submitting this bug.
PROGRAM TEST
CHARACTER*8 TXT
DATA TXT/'**TEST**'/
OPEN (1, FILE='TEST', STATUS='UNKNOWN', FORM='UNFORMATTED')
WRITE (1) TXT
REWIND 1
READ (1, END=1) TXT
READ (1, END=1) TXT
1CONTINUE
BACKSPACE 1
WRITE (1) TXT
CLOSE (1, STATUS='KEEP')
END
Georgy also submitted a patch which is considered obvious:
diff -Naur gcc-4.0.2.orig/libgfortran/io/transfer.c
gcc-4.0.2/libgfortran/io/transfer.c
--- gcc-4.0.2.orig/libgfortran/io/transfer.c2005-09-12 01:55:16.0
+0700
+++ gcc-4.0.2/libgfortran/io/transfer.c 2005-10-15 12:29:13.0 +0700
@@ -1641,11 +1641,13 @@
{
generate_error (ERROR_END, NULL);
current_unit-endfile = AFTER_ENDFILE;
+ current_unit-current_record = 0;
}
break;
case AFTER_ENDFILE:
generate_error (ERROR_ENDFILE, NULL);
+ current_unit-current_record = 0;
break;
}
}
Test results to follow:
--
Summary: Bad write after backing up from end of file
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: jvdelisle at gcc dot gnu dot org
ReportedBy: jvdelisle at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24700
[Bug libfortran/24700] Bad write after backing up from end of file
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-11-06 23:58 --- Testing that patch gives the following results. I will put together a test case and commit this as obvious unless there are objections. hex dump of TEST file created using gfortran 4.0.1 gives, with no patch: $ xxd TEST 000: 0800 2a2a 5445 5354 2a2a **TEST** 010: 0800 0800 020: 2a2a 5445 5354 2a2a 0800 **TEST** With gfortran 4.1 we get: $ xxd TEST 000: 0800 2a2a 5445 5354 2a2a **TEST** 010: 0800 2a2a 5445 5354 2a2a **TEST** 020: ff7f With Georgy's patch on 4.0.3: $ xxd TEST 000: 0800 2a2a 5445 5354 2a2a **TEST** 010: 0800 0800 020: 2a2a 5445 5354 2a2a 0800 **TEST** With Georgy's patch on 4.1: $ xxd TEST 000: 0800 2a2a 5445 5354 2a2a **TEST** 010: 0800 0800 020: 2a2a 5445 5354 2a2a 0800 **TEST** So it appears we had a regression from 4.0.1 in there somehow and did not catch it. Regards Jerry -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-06 23:58:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24700
Re: [Bug tree-optimization/24694] New: Address taken and addressable variables and call clobber
On Sun, 2005-11-06 at 15:46 +, pinskia at gcc dot gnu dot org wrote:
Take the following code:
int f(int);
int g(void)
{
int i;
int *iptr = i;
int **ipp = iptr;
**ipp = 1;
f(i);
return **ipp;
}
--
Here we consider i being call clobber because we lose the fact that iptr is
addressable
but we don't look to see if its address escapes at all (which in
this case it does not).
No, we don't actually.
In fact, that's not even close to what happens.
iptr isn't renamed, and thus, we assume the address taking of i and storage
into iptr is the same as a global store,
because we know nothing about unrenamed variables.
[Bug tree-optimization/24694] Address taken and addressable variables and call clobber
--- Comment #3 from dberlin at gcc dot gnu dot org 2005-11-06 23:59 ---
Subject: Re: New: Address taken and
addressable variables and call clobber
On Sun, 2005-11-06 at 15:46 +, pinskia at gcc dot gnu dot org wrote:
Take the following code:
int f(int);
int g(void)
{
int i;
int *iptr = i;
int **ipp = iptr;
**ipp = 1;
f(i);
return **ipp;
}
--
Here we consider i being call clobber because we lose the fact that iptr is
addressable
but we don't look to see if its address escapes at all (which in
this case it does not).
No, we don't actually.
In fact, that's not even close to what happens.
iptr isn't renamed, and thus, we assume the address taking of i and storage
into iptr is the same as a global store,
because we know nothing about unrenamed variables.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24694
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #19 from ian at airs dot com 2005-11-07 02:26 --- Created an attachment (id=10160) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10160action=view) Patch I'm testing this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug other/24692] Atomic builtins for v3
--- Comment #6 from pcarlini at suse dot de 2005-11-07 02:49 --- (In reply to comment #5) http://gcc.gnu.org/ml/gcc/2005-11/msg00326.html In short, you'll never get a completely unified way to implement these routines. Disagree, see: http://gcc.gnu.org/ml/gcc/2005-11/msg00332.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug c++/17256] [3.4/4.0/4.1 Regression] undefined but used static or inline functions should be diagnosed
--- Comment #14 from jason at gcc dot gnu dot org 2005-11-07 06:17 --- Subject: Bug 17256 Author: jason Date: Mon Nov 7 06:17:47 2005 New Revision: 106581 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106581 Log: PR c++/17256 * decl2.c (cp_finish_file): Fix conditions for undefined warning. Set TREE_NO_WARNING instead of TREE_PUBLIC. * pt.c (instantiate_pending_templates): Set DECL_INITIAL to avoid a warning on a function we didn't instantiate because of excessive recursion. Added: trunk/gcc/testsuite/g++.dg/warn/undefined1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17256
[Bug ada/21952] Many attribute directive ignored warnings during Tru64 UNIX Ada bootstrap
--- Comment #5 from phython at gcc dot gnu dot org 2005-11-07 06:55 --- Subject: Bug 21952 Author: phython Date: Mon Nov 7 06:54:52 2005 New Revision: 106582 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106582 Log: 2005-11-07 James A. Morrison [EMAIL PROTECTED] PR treelang/21952 * treetree.c (LANG_HOOKS_ATTRIBUTE_TABLE): Set to treelang_attribute_table. (handle_attribute): New function. (treelang_attribute_table): New attribute table. Modified: trunk/gcc/treelang/ChangeLog trunk/gcc/treelang/treetree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug ada/21952] Many attribute directive ignored warnings during Tru64 UNIX Ada bootstrap
--- Comment #6 from phython at gcc dot gnu dot org 2005-11-07 07:02 --- The last commit was meant for PR24066 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug treelang/24066] almost all treelang testsuite fails with -maltivec as an option
--- Comment #3 from phython at gcc dot gnu dot org 2005-11-07 07:03 --- Fixed in the commit message that shows up in PR21952. -- phython at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24066
[Bug treelang/24066] almost all treelang testsuite fails with -maltivec as an option
-- phython at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24066
[Bug c++/24702] New: Koenig found functoid ref, but cannot be used as a function
The problem relates to functoid objects (function like objects, ie
ones with an operator() defined) and references to them within a
namespace. When Koenig lookup is used to find such a
reference-to-functoid, g++ seems to find it okay, but then states
cannot be used as a function. If I use an actual functoid object
instead of a reference to one, it works fine.
Here is an example:
#include iostream
namespace dummyx {
struct Dummy {
Dummy() {}
};
struct DummyFunct {
int operator()(Dummy d) const {return 5;}
static DummyFunct full() {static DummyFunct f; return f;}
};
static DummyFunct dummyFunct=DummyFunct::full();
DummyFunct myDummyFunct;
DummyFunct mymyDummyFunct=myDummyFunct;
}
int main() {
::dummyx::Dummy const d;
std::coutdummyx::dummyFunct(d) = dummyx::dummyFunct(d)std::endl;
std::coutdummyFunct(d) = dummyFunct(d)std::endl; // fails with 3.4
and 4.0
std::coutmyDummyFunct(d) = myDummyFunct(d)std::endl;
std::coutmymyDummyFunct(d) = mymyDummyFunct(d)std::endl; // fails
with 3.4 and 4.0
}
When I try to compile this code using g++ version 4.0.2 I get the
following errors:
testit.cc: In function int main():
testit.cc:26: error: dummyx::dummyFunct cannot be used as a function
testit.cc:28: error: dummyx::mymyDummyFunct cannot be used as a function
I see no reason why such references should not be able to be used
as a function. As you see, if it is explicitly namespace-qualified
it can be. And according to Koenig rules, the unqualified name should
indeed be found and, as operator() is applicable for the found reference,
it should be usable as a function. Indeed, this is what version 3.2.3
of g++ does.
The above test code compiles fine with g++ version 3.2.3. The errors
seem only to occur in versions 3.4 and later (certainly they occur for
versions 3.4.5 and 4.0.2.)
Additional version information:
g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20)
g++-3.4 (GCC) 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)
g++-4.0 (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
--
Summary: Koenig found functoid ref, but cannot be used as a
function
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pierhyth at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24702
