[Bug fortran/37605] Remarks on user manual for Gfortran
--- Comment #4 from domob at gcc dot gnu dot org 2008-10-04 06:45 --- Created an attachment (id=16461) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16461action=view) Patch addressing most of the specific remarks This patch (posted to the list some time ago) addresses most of the specific remarks; I'm not sure what we should do about it, but in my opinion at least most of them are really improvements nice to have. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37605
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #31 from nickc at redhat dot com 2008-10-04 08:27 --- Subject: Re: [cygming] Invalid alignment for SSE store to .comm data generated with -O3 the patch looks ok but unfortunately does not always solves the problem, something in the chain misalignes the symbol This does not happen always but in some circumstances :( Possibly a linker bug. Could you investigate some more ? For example what alignment does the .bss section have in the object file and in the executable ? Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug tree-optimization/21485] [4.2/4.3/4.4 Regression] missed load PRE, PRE makes i?86 suck
--- Comment #33 from wbrana at gmail dot com 2008-10-04 09:22 --- results with -fno-tree-pre 1749 - 4.4.0 20080926 (experimental) 1701 - 4.3.2 2476 - 4.2.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #4 from domob at gcc dot gnu dot org 2008-10-04 10:16 --- The problem is clearly that because of the error the type-bound procedure remains in a somewhat dubious state (its pass_arg_num is invalid) and this causes the ICE when resolving an actual call to it afterwards. This is of course easy to fix. But I wonder about what a subsequent call to the procedure should do, as the PASS could not be resolved... This will then probably generate errors about actual/formal arglist mismatch for correct calls where only the name inside PASS(x) is wrong. Is this ok? The easiest would probably be to take PASS(invalid) as NOPASS or interpret it as PASS without argument name for that matter. Another solution would be to simply ignore calls to such an erraneous procedure in the resolver (and set them to EXEC_NOP for instance to avoid later confusion of gfortran?) which would mean that there is no error checking at all for them; but as this is not possible anyway, maybe that should be the way to go? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #5 from sfilippone at uniroma2 dot it 2008-10-04 10:29 --- (In reply to comment #4) The problem is clearly that because of the error the type-bound procedure remains in a somewhat dubious state (its pass_arg_num is invalid) and this causes the ICE when resolving an actual call to it afterwards. This is of course easy to fix. But I wonder about what a subsequent call to the procedure should do, as the PASS could not be resolved... This will then probably generate errors about actual/formal arglist mismatch for correct calls where only the name inside PASS(x) is wrong. Is this ok? The easiest would probably be to take PASS(invalid) as NOPASS or interpret it as PASS without argument name for that matter. Another solution would be to simply ignore calls to such an erraneous procedure in the resolver (and set them to EXEC_NOP for instance to avoid later confusion of gfortran?) which would mean that there is no error checking at all for them; but as this is not possible anyway, maybe that should be the way to go? Hmm. I see that in my previous comment #3 I said the wrong thing: the attached sample code should be correct, once the name in the PASS argument is fixed. The reasoning behind #3 is that in my original code I have types derived from base_foo_type, which means that for *those* types an argument mismatch must be issued if I try to invoke makenull, until the CLASS() declaration is implemented, so that the makenull() body can be written in the proper way. So, I was still thinking of my code and not of the cut-down test case. Sorry for the confusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #6 from domob at gcc dot gnu dot org 2008-10-04 10:40 --- (In reply to comment #5) Hmm. I see that in my previous comment #3 I said the wrong thing: the attached sample code should be correct, once the name in the PASS argument is fixed. The reasoning behind #3 is that in my original code I have types derived from base_foo_type, which means that for *those* types an argument mismatch must be issued if I try to invoke makenull, until the CLASS() declaration is implemented, so that the makenull() body can be written in the proper way. So, I was still thinking of my code and not of the cut-down test case. Sorry for the confusion. No problem, in fact I was generally wondering how to handle this situation; I'm now going to write up a patch where there would simply be an error for the PROCEDURE declaration (of course), no ICE (also of course) and the call would not print an error for any mismatched or not mismatched arglist, as this would be problematic. Well, we'll see what the final patch will look like :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration
--- Comment #14 from pault at gcc dot gnu dot org 2008-10-04 11:56 --- (In reply to comment #13) In fact the ICE is precisely due to the argument not being a restricted expression, since the size of x and its kind are unavailable to the caller and the interfacing cannot be made to work. This is why restricted expressions only permit dummy, host- or use-associated or common variables and why my attempts to evaluate the transfer are failing. However I disagree with this part of the analysis: size(transfer(real(1.0,kind(x)), [1_1])) is a restricted expression (happily accepted by gfortran) that uses exactly the same information as The real transfer(real(1.0,kind(x)) simplifies to a constant, which is why it can be evaluated. size(transfer(x, [1])) needs the variable, 'x'; even though the inquiry function does not need the value. My attempts to bypass this produced all manner of regressions. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680
[Bug middle-end/37731] [4.2/4.3/4.4 Regression] unsigned long long may not work correctly on 32bit host
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Priority|P3 |P1 Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37731
[Bug target/35574] [4.4 regression] unrecognizable insn generated for vector move
--- Comment #3 from kazu at gcc dot gnu dot org 2008-10-04 14:44 --- Added a pach URL above. -- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00114.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35574
[Bug tree-optimization/21485] [4.2/4.3/4.4 Regression] missed load PRE, PRE makes i?86 suck
--- Comment #34 from rguenth at gcc dot gnu dot org 2008-10-04 15:11 --- Fastest result on a Intel Core Duo with gcc-4.1 -O3 -fomit-frame-pointer -fno-tree-pre -fno-inline -fschedule-insns: 1273 the interesting thing is that with the above we if-convert if (array[k] array[k + 1L]) ++k; using setl which reduces the burden of the branch predictor which in the worst case (trunk) has quite a number of mispredicts. The following is branches retired vs. mispredicted branches retired for trunk (with PRE enabled) * CPU: Core Solo / Duo, speed 1833 MHz (estimated) * Counted BR_INST_RETIRED events (number of branch instructions retired) with a unit mask of 0x00 (No unit mask) count 1 * Counted BR_MISS_PRED_RETIRED events (number of mispredicted branches retired) with a unit mask of 0x00 (No unit mask) count 1 080486d0 NumSift: /* NumSift total: 188708 95.2681 21424 99.9953 */ 752 0.3796 0 0 : 80486d0: push %ebp : 80486d1: push %edi : 80486d2: push %esi 824 0.4160 0 0 : 80486d3: push %ebx 5 0.0025 0 0 : 80486d4: sub$0xc,%esp : 80486d7: mov%ecx,(%esp) 1541 0.7780 0 0 : 80486da: add$0x1,%ecx : 80486dd: mov%ecx,0x8(%esp) : 80486e1: lea0x0(%esi),%esi 709 0.3579 2 0.0093 : 80486e8: lea(%edx,%edx,1),%ecx 1706 0.8613 1 0.0047 : 80486eb: cmp(%esp),%ecx 3083 1.5564 924 4.3127 : 80486ee: mov%ecx,%edi 92 0.0464 0 0 : 80486f0: lea(%eax,%edx,8),%ebp : 80486f3: mov%ebp,%ebx 868 0.438213 0.0607 : 80486f5: ja 804871d NumSift+0x4d 5732 2.8938 0 0 : 80486f7: jb 8048728 NumSift+0x58 2 0.0010 0 0 : 80486f9: mov(%ebx),%esi 7789 3.9322 162 0.7561 : 80486fb: lea(%eax,%edx,4),%ecx 34575 17.4550 6534 30.4971 : 80486fe: mov0x8(%esp),%edx 3070 1.5499 2103 9.8156 : 8048702: mov(%ecx),%ebp 8244 4.1619 134 0.6254 : 8048704: cmp%esi,%ebp 2322 1.1722 155 0.7235 : 8048706: jge80486e8 NumSift+0x18 1363 0.6881 236 1.1015 : 8048708: mov%edi,%edx 3578 1.8063 0 0 : 804870a: mov%ebp,(%ebx) 450 0.2272 367 1.7130 : 804870c: lea(%eax,%edx,8),%ebp 3797 1.9169 0 0 : 804870f: mov%esi,(%ecx) 5035 2.541922 0.1027 : 8048711: lea(%edx,%edx,1),%ecx : 8048714: mov%ebp,%ebx 389 0.1964 0 0 : 8048716: cmp(%esp),%ecx 5885 2.971015 0.0700 : 8048719: mov%ecx,%edi 7 0.0035 0 0 : 804871b: jbe80486f7 NumSift+0x27 416 0.210024 0.1120 : 804871d: add$0xc,%esp 5419 2.7357 1431 6.6791 : 8048720: pop%ebx 568 0.2868 275 1.2835 : 8048721: pop%esi 710 0.358424 0.1120 : 8048722: pop%edi 334 0.168612 0.0560 : 8048723: pop%ebp 146 0.073791 0.4247 : 8048724: ret : 8048725: lea0x0(%esi),%esi 8706 4.3952 0 0 : 8048728: mov0x0(%ebp),%ebx 1536 0.7754 379 1.7690 : 804872b: lea0x1(%ecx),%edi : 804872e: mov%ebx,0x4(%esp) 14484 7.3122 9 0.0420 : 8048732: lea(%eax,%edi,4),%ebx : 8048735: mov(%ebx),%esi 2165 1.0930 6 0.0280 : 8048737: cmp%esi,0x4(%esp) 19814 10.0030 1 0.0047 : 804873b: jl 80486fb NumSift+0x2b 2585 1.3050 0 0 : 804873d: mov0x4(%esp),%esi 37728 19.0468 8504 39.6919 : 8048741: mov%ebp,%ebx 1511 0.7628 0 0 : 8048743: mov%ecx,%edi 768 0.3877 0 0 : 8048745: jmp80486fb NumSift+0x2b : 8048747: mov%esi,%esi : 8048749: lea0x0(%edi),%edi while the following is what we get for the gcc 4.1 code w/o PRE: 08048670 NumSift: /* NumSift total: 200781 92.9938 4738 99.9156 */ 1196 0.5539 0 0 : 8048670: push %ebp 1 4.6e-04 0 0 : 8048671: push %edi 2 9.3e-04 0 0 : 8048672: mov%eax,%edi 2084 0.9652 0 0 : 8048674: push %esi 9 0.0042 0 0 : 8048675: push %ebx 1 4.6e-04 0 0 : 8048676: mov%edx,%ebx 1162 0.5382 0 0 : 8048678: sub$0x4,%esp 6 0.0028 0 0 : 804867b:
[Bug tree-optimization/21485] [4.2/4.3/4.4 Regression] missed load PRE, PRE makes i?86 suck
--- Comment #35 from rguenth at gcc dot gnu dot org 2008-10-04 15:58 --- Another missed optimization on the tree level is hoisting of the load of array[k*4] before the k j condition which is possible after the PRE insertion: bb 3: if (k_4 j_5(D)) goto bb 4; else goto bb 12; bb 12: pretmp.12_31 = k_4 * 4; pretmp.13_30 = array_8(D) + pretmp.12_31; pretmp.14_25 = *pretmp.13_30; goto bb 6; bb 4: D.1242_7 = k_4 * 4; D.1243_9 = array_8(D) + D.1242_7; D.1244_10 = *D.1243_9; maybe PRE could somehow even insert on BB3 entry instead of BB3 exit edges in this case. This would re-enable if-conversion of the second branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug tree-optimization/21485] [4.2/4.3/4.4 Regression] missed load PRE, PRE makes i?86 suck
--- Comment #36 from rguenth at gcc dot gnu dot org 2008-10-04 16:16
---
Testcase for that:
/* { dg-do compile } */
/* { dg-options -O2 -fdump-tree-pre } */
long
NumSift (long *array, int b, unsigned long k)
{
if (b)
if (array[k] array[k + 1L])
++k;
return array[k];
}
/* There should be two loads left. */
/* { dg-final { scan-tree-dump-times = \\\* 2 pre } } */
/* { dg-final { cleanup-tree-dump pre } } */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug target/37603] [4.3/4.4 Regression] FAIL: gcc.c-torture/compile/pr36141.c at -O1 and above
--- Comment #5 from danglin at gcc dot gnu dot org 2008-10-04 18:22 --- Fixed -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37603
[Bug middle-end/37731] [4.2/4.3/4.4 Regression] unsigned long long may not work correctly on 32bit host
--- Comment #9 from hjl dot tools at gmail dot com 2008-10-04 18:25 ---
When we multiple a DImode constant in CONST_DOUBLE, if
CONST_DOUBLE_HIGH (op1) == 0, the constant must be
positive. In this case, we can't just check coeff != 0.
Does this patch make senses?
--- ./expmed.c.ll 2008-09-29 08:37:56.0 -0700
+++ ./expmed.c 2008-10-04 11:20:29.0 -0700
@@ -3092,7 +3092,7 @@ expand_mult (enum machine_mode mode, rtx
produce a smaller program when -O is not used. But this causes
such a terrible slowdown sometimes that it seems better to always
use synth_mult. */
- if (coeff != 0)
+ if (coeff 0 || (coeff 0 GET_CODE (op1) == CONST_INT))
{
/* Special case powers of two. */
if (EXACT_POWER_OF_2_OR_ZERO_P (coeff))
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Priority|P1 |P3
Target Milestone|4.2.5 |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37731
[Bug target/37603] [4.3/4.4 Regression] FAIL: gcc.c-torture/compile/pr36141.c at -O1 and above
--- Comment #4 from danglin at gcc dot gnu dot org 2008-10-04 18:08 --- Subject: Bug 37603 Author: danglin Date: Sat Oct 4 18:06:46 2008 New Revision: 140871 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140871 Log: PR target/37603 * pa.c (legitimize_pic_address): Force function labels to memory in word mode. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37603
[Bug target/37603] [4.3/4.4 Regression] FAIL: gcc.c-torture/compile/pr36141.c at -O1 and above
--- Comment #3 from danglin at gcc dot gnu dot org 2008-10-04 18:04 --- Subject: Bug 37603 Author: danglin Date: Sat Oct 4 18:03:07 2008 New Revision: 140870 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140870 Log: PR target/37603 * pa.c (legitimize_pic_address): Force function labels to memory in word mode. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37603
[Bug fortran/37706] [4.3, 4.4 Regression] ICE with use only and equivalent
--- Comment #5 from pault at gcc dot gnu dot org 2008-10-04 20:26 --- Created an attachment (id=16462) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16462action=view) The fix I just tried to commit this as obvious but authentication failed for some reason. One way or another, it will be committed tomorrow:-) Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37706
[Bug middle-end/37731] [4.2/4.3/4.4 Regression] long long may not work correctly on 32bit host
--- Comment #10 from hjl dot tools at gmail dot com 2008-10-04 20:43 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00128.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00128.html Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3/4.4 Regression] |unsigned long long may not |long long may not work |work correctly on 32bit host|correctly on 32bit host http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37731
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #32 from sherpya at netfarm dot it 2008-10-04 21:40 --- this archive: http://people.netfarm.it/~sherpya/gcc/info.7z contains ffmpeg_g.exe - non stripped final executable fft.c/o/s - source, object file and asm generated related vars are: ff_cos_16, ff_cos_32 etc $ nm ffmpeg_g.exe |grep ff_cos_16 00e62d14 B _ff_cos_16 00e25654 B _ff_cos_16384 $ nm libavcodec/fft.o |grep ff_cos_16 0020 C _ff_cos_16 8000 C _ff_cos_16384 gcc version 4.3.3 20081004 (prerelease) (Sherpya) (plain svn with the patch) GNU ld (GNU Binutils) 2.18.91.20080917 I can also provide all my build env as 7z Regards -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2
--- Comment #12 from ubizjak at gmail dot com 2008-10-04 21:47 --- (In reply to comment #10) Must be darwin specific then, can't reproduce on x86_64-linux and from quick skim of gcc-testresults nobody else that supplied test summary recently managed to reproduced it. i586-pc-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg00245.html i686-apple-darwin9: http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg00105.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
[Bug fortran/37735] New: Allocatable components in vectors of derived types cause ICE on assignment
$ gfortran-4.exe -v -save-temps -c PrettyPix.f95 Using built-in specs. Target: i686-pc-cygwin Configured with: /gnu/gcc/release/gcc4-4.3.2-1/src/gcc-4.3.2/configure --srcdir=/gnu/gcc/release/gcc4-4.3.2-1/src/gcc-4.3.2 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/sbin --localstatedir=/var --sysconfdir=/etc --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --with-slibdir=/usr/bin --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --enable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --disable-symvers --enable-libjava --program-suffix=-4 Thread model: single gcc version 4.3.2 20080827 (alpha-testing) 1 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic' /usr/lib/gcc/i686-pc-cygwin/4.3.2/f951.exe PrettyPix.f95 -quiet -dumpbase PrettyPix.f95 -mtune=generic -auxbase PrettyPix -version -fintrinsic-modules-path finclude -o PrettyPix.s GNU F95 (GCC) version 4.3.2 20080827 (alpha-testing) 1 (i686-pc-cygwin) compiled by GNU C version 4.3.2 20080827 (alpha-testing) 1, GMP version 4.2.3, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 PrettyPix.f95: In function 'scene_set_look_at_path': PrettyPix.f95:19: internal compiler error: in gfc_conv_descriptor_data_set_internal, at fortran/trans-array.c:174 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. PrettyPix.f95: == module PrettyPix_module implicit none type Spline real, allocatable, dimension(:) ::y2 end type Spline type Path type(Spline) :: r(3) end type Path type Scene type(path) :: look_at_path end type Scene contains subroutine scene_set_look_at_path(this,p) type(scene), intent(inout) :: this type(path), intent(in):: p this%look_at_path = p end subroutine scene_set_look_at_path end module PrettyPix_module === The problem seems to disappear if r(3) - r -- Summary: Allocatable components in vectors of derived types cause ICE on assignment Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: saw44 at cam dot ac dot uk GCC build triplet: 4.3.2 20080827 (alpha-testing) 1 (GCC) GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37735
[Bug c++/35497] Compiling error with template part. spec. involving function call and in c++0x
--- Comment #2 from fang at csl dot cornell dot edu 2008-10-05 01:16 --- dupe PR 36460 (fixed in 4.4)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35497
[Bug libstdc++/34419] Weirdness with numeric_limits in special functions
--- Comment #3 from 3dw4rd at verizon dot net 2008-10-05 01:33 --- Subject: Re: Weirdness with numeric_limits in special functions paolo dot carlini at oracle dot com wrote: --- Comment #2 from paolo dot carlini at oracle dot com 2008-10-03 10:54 --- Any news Ed? Yes. Regarding the problem with being called with integral arguments, the promote tool which enforces the srd:: requirement that calling a math function with integral argument should trigger the double call. Ints get promoted to double, then all the floating point numbers are promoted up to the biggest float type. I verified that even calling the template versions with explicit template arguments cannot cause an int to go through. 1. Maybe this should be a test? Probably, as it is a requirement. I should probably test a lot of promotion. Actually, I'm not sure how I would make a test case off the top of my head. 2. The ability to call the template versions is not standard. It sure does make things cleaner though. REgarding the sqrt of numeric_limits::epsilon() I tested this on x86 Linux and MacOSX PPC and it works. The square root of an number less than one is larger than the original number. The answers are pretty accurate but int the interest of lack of scary lookingness I have a patch that does things like sqrt(100*epsilon)/10. I'll fix up the patch. Ed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34419
[Bug fortran/37706] [4.3, 4.4 Regression] ICE with use only and equivalent
--- Comment #6 from pault at gcc dot gnu dot org 2008-10-05 05:51 --- Subject: Bug 37706 Author: pault Date: Sun Oct 5 05:50:00 2008 New Revision: 140879 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140879 Log: 2008-10-04 Paul Thomas [EMAIL PROTECTED] PR fortran/37706 * module.c (load_equiv): Check the module before negating the unused flag. 2008-10-04 Paul Thomas [EMAIL PROTECTED] PR fortran/37706 * gfortran.dg/module_equivalence_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/module_equivalence_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37706
