[Bug target/31585] gcc.target/i386/sse-vect-types.c FAILs (also sse-13.c and sse-14.c)
--- Comment #1 from ubizjak at gmail dot com 2007-04-16 08:02 --- Proposed patch to macroize these functions in emmintrin.h (http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00096.html). Please note that some other intrinsic functions, such as _mm_shuffle_ps() are defined as macro as well because of their check for constant arguments. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||04/msg00096.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31585
[Bug bootstrap/31523] bootstrap xgcc internal compiler error (using -O3)
--- Comment #4 from anirkko at insel dot ch 2007-04-16 09:15 --- (In reply to comment #2) > Can you try without setting the CFLAGS, etc. because what might be happening > is > the base compiler miscompiling the new compiler? > Tried something slightly different: because this happened in C++, I bootstrapped gcc-4.1.2 with lang=C,ada and it worked fine, error-free, including passing the stage2 comparison passed. The resulting gcc-4.1.2 should now be enough to use as base compiler to build everything else, including c++. When doing this (same flags and options), I got exactly the same internal compiler error again. Thus, both the base compiler gcc-3.4.3 and gcc-4.1.2 lead to the same error. Will try next without -O3 and other flags to see if one of these generate the error. -- anirkko at insel dot ch changed: What|Removed |Added CC||anirkko at insel dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31523
[Bug bootstrap/31523] bootstrap xgcc internal compiler error (using -O3)
--- Comment #5 from anirkko at insel dot ch 2007-04-16 09:21 --- (In reply to comment #3) > Do really have a SuperSPARC? If no, remove the -mcpu=supersparc option, it is > totally untested these days. If so, I'd suggest to stick with a 3.x compiler > on this presumably old machine. > Several machines from SuperSPARC 110 MHz to multi-CPU UltraSPARC-III 1.3 GHz, and even the SuperSPARCs still work better than the average PC. Some old SBUS hardware only works with the old machines. I like to have the same gcc binary running on all machines, which will also produce binaries that will run on all machines from Solaris 2.6 to Solaris 10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31523
[Bug bootstrap/31523] bootstrap xgcc internal compiler error (using -O3)
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-04-16 09:59 --- > Will try next without -O3 and other flags to see if one of these generate the > error. Most likely I'd say. I happen to regularly bootstrap GCC 4.1.x with GCC 3.4.3 and the default options on Solaris 2.5.1 and 2.6 UltraSPARC machines and this works flawlessly: http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00700.html http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00578.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31523
[Bug preprocessor/31586] New: -falign-X and -fno-align-X flags have reversed meaning
The documentation mentions: -falign-functions=n "-fno-align-functions and -falign-functions=1 are equivalent and mean that functions will not be aligned." and "If n is not specified or is zero, use a machine-dependent default." But, it seems the semantics are reversed when using -fno-align-functions and -falign-functions. In gcc/opts.c:handle_option, the value variable is set to 1 by default (for -f flags), and to 0 for -fno- flags. Sadly, this should be reversed for falign-X flags: 1 should be used for -fno-align-X and 0 for -falign-X . This affects -falign-functions, -falign-jumps, -falign-labels and -falign-loops, and should be fairly easy to solve to flip the value of 'value' in handle_option for the -falign-X flags. -- Summary: -falign-X and -fno-align-X flags have reversed meaning Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kenneth dot hoste at elis dot ugent dot be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31586
[Bug fortran/31587] New: Module files shouldn't be updated if their content doesn't change
If we recompile a file that outputs the same .mod files, they shouldn't get updated: it makes dependency analysis useless and probably makes parallel compiling (make -jN) less efficient. $ cat a.f90 module foo integer, parameter :: bar = 42 end module foo $ gfortran -c a.f90 $ stat foo.mod | grep Modify Modify: 2007-04-16 11:15:54.0 +0200 $ gfortran -c a.f90 $ stat foo.mod | grep Modify Modify: 2007-04-16 11:15:58.0 +0200 -- Summary: Module files shouldn't be updated if their content doesn't change Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
[Bug fortran/31588] New: gfortran should be able to output Makefile dependencies with -M* options
gcc has various -M options to create Makefile dependencies for automatic dependency tracking, which is very nice for compilation of large projects. gfortran should be able to do the same. Here are examples with g95: $ cat a.f90 module foo integer, parameter :: bar = 42 end module foo $ g95 -M a.f90 a.o foo.mod: a.f90 $ cat a.F90 include "foo.inc" module foo integer, parameter :: bar = 42 end module foo $ g95 -M a.F90 a.o foo.mod: a.F90 foo.inc -- Summary: gfortran should be able to output Makefile dependencies with -M* options Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-16 10:21:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-16 10:21:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-04-16 10:21:45 |2007-04-16 10:22:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug c++/31584] ICE on probably invalid code
--- Comment #2 from numerical dot simulation at web dot de 2007-04-16 10:31 --- The compiler at http://www.comeaucomputing.com/tryitout/ has absolutely no problems with the code. M$-VC8 says: error C2754: 'C::Dispatcher' : a partial specialization cannot have a dependent non-type template parameter which somehow is an error message that clearly states what might be wrong. The "incomplete type" statement is somehow misleading - IMHO Could you change the error message in this case? Of course I disagree with gcc and VC8 here. Any pointer to a TR on this subject? Best Regards, Markus -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31584
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-16 11:02 --- FX, +5 karma for this proposal :) How about USE association? For example $> cat a.f90 module a [...] end module $> cat b.f90 [...] USE a [...] $> gfortran -M a.f90 a.o a.mod: a.f90 $> gfortran -M b.f90 b.o: a.mod b.f90 (Don't have g95 to check its output) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-16 11:06 --- (In reply to comment #1) > How about USE association? That's also part of the plan. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug ada/31576] [regression] Ada bootstrap error
--- Comment #1 from krebbel at gcc dot gnu dot org 2007-04-16 12:38 --- The same happens on s390 and s390x. The constant Default_Bit_Order is definded in system.ads: -- Other System-Dependent Declarations type Bit_Order is (High_Order_First, Low_Order_First); Default_Bit_Order : constant Bit_Order := High_Order_First; With the -gnupg option gnat compains about all checks like: if Default_Bit_Order = High_Order_First then ... with warning: condition is always True I'm by far not an Ada expert but I would say that warning isn't very helpful and in that case and should simply be omitted. -- krebbel at gcc dot gnu dot org changed: What|Removed |Added CC||krebbel at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet||sparc-linux-gnu, s390-ibm- ||linux GCC target triplet|sparc-linux-gnu |sparc-linux-gnu, s390-ibm- ||linux Keywords||build Last reconfirmed|-00-00 00:00:00 |2007-04-16 12:38:14 date|| Summary|[regression] bootstrap error|[regression] Ada bootstrap |on sparc-linux-gnu |error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31576
[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change
--- Comment #1 from tobi at gcc dot gnu dot org 2007-04-16 13:28 --- An easy solution that I thought about implementing in the past would be to put a checksum into the file header. First the module file would be written to a temporary file. This file would be checksummed and only moved to the final location if the checksum is different from that of the extant file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change
--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-16 13:31 --- Given your other PR, another solution that comes to mind is to include the filename and modification date of the source file in the module file, and to compare these before writing a module file. This would be more prone to inconsistencies than the approach from comment #1, as it wouldn't actually be verified that the .mod file remains unchanged. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-16 13:33 --- Better than my current idea for that, which was to compare line after line the old and new files. What cheap hash function should we use? MD5? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-04-16 13:34 --- (In reply to comment #2) > include the > filename and modification date of the source file in the module file, and to > compare these before writing a module file I think that defeats the purpose: if the source file changed but the module file didn't change (ie the module interface is the same), we don't need to recompile the files that depend on the module, and the module file shouldn't be rewritten. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change
--- Comment #5 from tobi at gcc dot gnu dot org 2007-04-16 13:35 --- (In reply to comment #3) > Better than my current idea for that, which was to compare line after line the > old and new files. What cheap hash function should we use? MD5? Probably, as it is included in libiberty, and is good enough for our purposes. And please disregard my second idea as it wouldn't help in any way :-) -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
[Bug fortran/31580] Better error message for not-found operator
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-16 13:37:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31580
[Bug fortran/31580] Better error message for not-found operator
--- Comment #1 from tobi at gcc dot gnu dot org 2007-04-16 13:39 --- I think the simplest fix is rewording the error message to, say, "No interface found for operator .notfound. with operand types REAL(4)/REAL(4)" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31580
[Bug fortran/31243] truncating strings longer than 2**32 characters
--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-16 13:52 --- Issuing a warning would be a good thing, "INTEGER*8 value may be greater than longest possible CHARACTER on your architecture", maybe even a runtime error in the second case. I hope you're not suggesting that we devise ways of addressing 2**64 bytes on 32bit machines :-) -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31243
[Bug c/31589] New: gcc.dg/vect failures due to missing target specifiers
Dorit Nuzman supplied a patch to correct failures reported when running testsuite. These failures have been reported in all results posted to gcc-testsuite. The patch adds target specifiers, correcting the associated FAIL reports on my system, for the cases pr30771.c vect-iv-4.c vect-iv-9.c vect-reduc-dot-s16b.c vect-reduc-dot-u16b.c vect-reduc-pattern-1a.c vect-reduc-pattern-1c.c vect-reduc-pattern-2a.c vect-widen-mult-u16.c wrapv-vect-reduc-pattern-2c.c 2 more are under investigation: no-section-anchors-vect-69.c vect-reduc-dot-u16a.c -- Summary: gcc.dg/vect failures due to missing target specifiers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: ia64-unknown-linux-gnu GCC host triplet: ia64-unknown-linux-gnu GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31589
[Bug fortran/31218] ICE on valid code with gfortran
--- Comment #3 from tobi at gcc dot gnu dot org 2007-04-16 14:14 --- Reduced testcase: real, dimension(1), parameter :: r=1.0 real, dimension(1) :: s=RESHAPE(r,(/1/)) IF (ANY(s.NE.1.0)) CALL ABORT() END -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31218
[Bug other/31536] sparc64 build fails with `unknown endianness' error.
--- Comment #3 from pluto at agmk dot net 2007-04-16 14:16 --- /home/pawels/toolchain41-src/gcc-4.1.2/builddir/gcc/xgcc -v Using built-in specs. Target: sparc64-sun-solaris2.9 Configured with: ../configure --target=sparc64-sun-solaris2.9 --prefix=/local/devel/toolchain41/sparc64-sun-solaris2.9 --libdir=/local/devel/toolchain41/sparc64-sun-solaris2.9/lib --libexecdir=/local/devel/toolchain41/sparc64-sun-solaris2.9/lib --with-slibdir=/local/devel/toolchain41/sparc64-sun-solaris2.9/lib --with-gnu-as --with-gnu-ld --disable-multilib --disable-nls --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-languages=c,c++ make all (...) checking whether byte ordering is bigendian... unknown configure: error: unknown endianness presetting ac_cv_c_bigendian=no (or yes) will help make[1]: *** [configure-target-libiberty] Error 1 make[1]: Leaving directory `/home/pawels/toolchain41-src/gcc-4.1.2/builddir' all logs attached. see builddir/sparc64-sun-solaris2.9/libiberty/config.log for details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31536
[Bug other/31536] sparc64 build fails with `unknown endianness' error.
--- Comment #4 from pluto at agmk dot net 2007-04-16 14:16 --- Created an attachment (id=13370) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13370&action=view) config.logs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31536
[Bug c/31589] gcc.dg/vect failures due to missing target specifiers
--- Comment #1 from tprince at computer dot org 2007-04-16 14:18 --- Created an attachment (id=13371) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13371&action=view) adds target qualifiers to files in gcc.dg/vect/ patch supplied to me by Dorit Nuzman. It changes ia64 reports from FAIL to UNSUPPORTED. I tested it successfully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31589
[Bug fortran/30871] Pointer to substring rejected with "Different character lengths in pointer assignment"
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|tobi at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30871
[Bug target/31582] ix86_expand_vec_set_builtin modifies source
--- Comment #2 from hjl at gcc dot gnu dot org 2007-04-16 14:49 --- Subject: Bug 31582 Author: hjl Date: Mon Apr 16 14:49:14 2007 New Revision: 123866 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123866 Log: 2007-04-16 H.J. Lu <[EMAIL PROTECTED]> PR target/31582 * config/i386/i386.c (ix86_expand_vec_set_builtin): Make a copy of source, pass it to ix86_expand_vector_set and return it as target. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31582
[Bug target/31582] ix86_expand_vec_set_builtin modifies source
--- Comment #3 from hjl at gcc dot gnu dot org 2007-04-16 14:58 --- Subject: Bug 31582 Author: hjl Date: Mon Apr 16 14:57:37 2007 New Revision: 123868 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123868 Log: 2007-04-16 H.J. Lu <[EMAIL PROTECTED]> * Backport from mainline: 2007-04-16 H.J. Lu <[EMAIL PROTECTED]> PR target/31582 * config/i386/i386.c (ix86_expand_vec_set_builtin): Make a copy of source, pass it to ix86_expand_vector_set and return it as target. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31582
[Bug fortran/31144] gfortran module symbol names are not standard compliant
--- Comment #7 from patchapp at dberlin dot org 2007-04-16 15:00 --- Subject: Bug number PR 31144 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00985.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31144
[Bug target/31582] ix86_expand_vec_set_builtin modifies source
--- Comment #4 from hjl at gcc dot gnu dot org 2007-04-16 15:04 --- Subject: Bug 31582 Author: hjl Date: Mon Apr 16 15:04:30 2007 New Revision: 123872 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123872 Log: 2007-04-16 H.J. Lu <[EMAIL PROTECTED]> * Backport from mainline: 2007-04-16 H.J. Lu <[EMAIL PROTECTED]> PR target/31582 * config/i386/i386.c (ix86_expand_vec_set_builtin): Make a copy of source, pass it to ix86_expand_vector_set and return it as target. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31582
[Bug target/31582] ix86_expand_vec_set_builtin modifies source
--- Comment #5 from hjl at lucon dot org 2007-04-16 15:06 --- I checked the patch into 4.1/4.2/4.3. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 Version|4.3.0 |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31582
[Bug fortran/31144] gfortran module symbol names are not standard compliant
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-16 16:27:41 |2007-04-16 15:12:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31144
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-16 15:28 --- What about include "foo.f90" and #include "bar.f90" (g95 handles both) And what about include "z.f90" where "z.f90" is foo/z.f90 and is found via gfortran -Jfoo ? (g95 does not handle this and writes: b.o b.mod: b.F90 z.f90) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug fortran/31487] Character array initialization in derived type: bad zero padding
--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-16 15:37 --- I'll have a look. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31487
[Bug fortran/31487] Character array initialization in derived type: bad zero padding
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-08 11:41:37 |2007-04-16 15:38:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31487
[Bug middle-end/28071] [4.1 regression] A file that can not be compiled in reasonable time/space
--- Comment #63 from mkuvyrkov at gcc dot gnu dot org 2007-04-16 16:04 --- Subject: Bug 28071 Author: mkuvyrkov Date: Mon Apr 16 16:04:18 2007 New Revision: 123874 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123874 Log: PR middle-end/28071 * sched-int.h (struct deps): Split field 'pending_lists_length' into 'pending_read_list_length' and 'pending_write_list_length'. Update comment. * sched-deps.c (add_insn_mem_dependence): Change signature. Update to handle two length counters instead of one. Update all uses. (flush_pending_lists, sched_analyze_1, init_deps): Update to handle two length counters instead of one. * sched-rgn.c (propagate_deps): Update to handle two length counters instead of one. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c trunk/gcc/sched-int.h trunk/gcc/sched-rgn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug middle-end/28071] [4.1 regression] A file that can not be compiled in reasonable time/space
--- Comment #64 from mkuvyrkov at gcc dot gnu dot org 2007-04-16 16:07 --- (In reply to comment #63) Scheduler memory hungryness should be fixed by the above commit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug middle-end/31068] ICE at -O1 -fipa-pta
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-04-16 16:55 --- Subject: Re: ICE at -O1 -fipa-pta On 16 Apr 2007 06:03:45 -, fxcoudert at gmail dot com <[EMAIL PROTECTED]> wrote: > > > --- Comment #3 from fxcoudert at gmail dot com 2007-04-16 07:03 --- > Subject: Re: ICE at -O1 -fipa-pta > > > PS, I will fix this sometime after we have LTO. > > Until then, -fipa-pta is not worth it. > > Can it be made an undocumented option, then, for the time being? > Because it's still an ICE on valid code using a documented option :) This is what i originally wanted, but people don't want options that aren't documented :( I'll make the trivial fix for it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31068
[Bug target/27869] "-O -fregmove" handles SSE scalar instructions incorrectly
--- Comment #16 from hubicka at gcc dot gnu dot org 2007-04-16 17:07 --- Subject: Bug 27869 Author: hubicka Date: Mon Apr 16 17:07:19 2007 New Revision: 123876 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123876 Log: PR target/27869 * config/i386/sse.md (sse_vmaddv4sf3, sse_vmmulv4sf3): Remove '%' modifier. (sse_vmsmaxv4sf3_finite, sse_vmsminv4sf3_finite): Remove. (sse2_vmaddv2df3, sse2_vmmulv2df3): Remove '%' modifier. (sse2_vmsmaxv2df3_finite, sse2_vmsminv2df3_finite): Remove. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27869
[Bug other/31536] sparc64 build fails with `unknown endianness' error.
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-04-16 17:47 --- Can you unset CFLAGS and try again? I bet 4.1.2 is being miss compiled at least looking at the logs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31536
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #13 from spark at gcc dot gnu dot org 2007-04-16 17:49 --- Subject: Bug 29365 Author: spark Date: Mon Apr 16 17:49:02 2007 New Revision: 123879 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123879 Log: gcc/ChangeLog: 2007-04-16 Seongbae Park <[EMAIL PROTECTED]> PR c++/29365 * cp/decl2.c (constrain_class_visibility): Do not warn about the use of anonymous namespace in the main input file. gcc/testsuite/ChangeLog: 2007-04-16 Seongbae Park <[EMAIL PROTECTED]> PR c++/29365 Testcase for c++ anonymous namespace warning * g++.dg/warn/anonymous-namespace-1.C: New test * g++.dg/warn/anonymous-namespace-1.h: New test Added: trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-1.C trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-1.h Modified: trunk/gcc/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug rtl-optimization/31360] [4.2/4.3 Regression] rtl loop invariant is broken
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-26 22:11:48 |2007-04-16 17:53:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug c++/2204] G++ doesn't check (member) function parameter for abstract-ness.
--- Comment #15 from bangerth at dealii dot org 2007-04-16 19:02 --- True. This has been fixed since 4.0.x. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2204
[Bug tree-optimization/25809] missed PRE optimization - move "invariant casts" out of loops
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-04-16 19:14 --- Doing cast motion actually causes about 25 *more* failures in the vectorizer testsuite. I'm closing this as won't fix since it seems there was no other reason to do this. -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25809
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-04-16 19:24 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug ada/31576] [4.3 regression] Ada bootstrap error
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31576
[Bug fortran/31591] New: internal compiler error on array initialization statement using 'ubound'
See the bit of code below dealing with the initialization of array contents with the "ubound" results called on another array. If the "module" statements plus the write(*,*) statements are both commented out, then this bit of code compiles. However, if either (a) this code is made into a module, or (b) it remains as a program but the 'write(*,*)' statement is put back in, then the compilation fails with an "internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:3460" !MODULE TEST_CERES PROGRAM Test_ceres implicit none real, dimension(10, 10, 10, 3, 4) :: TCg_coef integer, parameter, dimension(5) :: & TCg_bband_coef_ranks = ubound(TCg_coef) !write(*,*) 'array_ranks = ',TCg_bband_coef_ranks end program Test_ceres !end module Test_ceres -- Summary: internal compiler error on array initialization statement using 'ubound' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Catherine dot M dot Moroney at jpl dot nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31591
[Bug tree-optimization/16157] gcc fails to optimize redundant expression (reassocation)
--- Comment #4 from steven at gcc dot gnu dot org 2007-04-16 19:40 --- This is not yet fixed. -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-12-09 04:24:11 |2007-04-16 19:40:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16157
[Bug fortran/31591] internal compiler error on array initialization statement using 'ubound'
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-16 20:05 --- Tested gfortran v4.1.1, v4.2 and a recent svn checkout, none of them reported an ICE. Which version do you use? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31591
[Bug fortran/31591] internal compiler error on array initialization statement using 'ubound'
--- Comment #2 from Catherine dot M dot Moroney at jpl dot nasa dot gov 2007-04-16 20:07 --- Subject: Re: internal compiler error on array initialization statement using 'ubound' [EMAIL PROTECTED]:/data/svn_workspace/cmm/sieglind/PGE/L2TC/ StandardProcessing/AZM/make [69]>gfortran -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) Catherine On Apr 16, 2007, at 12:05 PM, dfranke at gcc dot gnu dot org wrote: > > > --- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-16 > 20:05 --- > Tested gfortran v4.1.1, v4.2 and a recent svn checkout, none of them > reported > an ICE. Which version do you use? > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31591 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31591
[Bug preprocessor/30805] [4.1/4.2/4.3 Regression] Internal compiler error when using "x##,##__VA_ARGS__" in macro
--- Comment #5 from bonzini at gnu dot org 2007-04-16 20:10 ---
What about a patch like this?
Index: macro.c
===
--- macro.c (revision 123691)
+++ macro.c (working copy)
@@ -499,9 +499,15 @@ paste_all_tokens (cpp_reader *pfile, con
rhs = *FIRST (context).ptoken++;
if (rhs->type == CPP_PADDING)
- abort ();
+ {
+ /* In obscure cases where the GNU extension ,##__VA_ARGS__ is
+used, we can get a CPP_PADDING token here. Assert that we
+can safely ignore it. */
+ if (rhs->flags & PASTE_LEFT)
+ abort ();
+ }
- if (!paste_tokens (pfile, &lhs, rhs))
+ else if (!paste_tokens (pfile, &lhs, rhs))
break;
}
while (rhs->flags & PASTE_LEFT);
--
bonzini at gnu dot org changed:
What|Removed |Added
CC||bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30805
[Bug preprocessor/30786] [4.1/4.2/4.3 Regression] ICE on _Pragma at end of file
--- Comment #2 from bonzini at gnu dot org 2007-04-16 20:11 --- Created an attachment (id=13372) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13372&action=view) patch to fix part of the bug This patch seems to fix the preprocessor side of the bug. However there are problems later in the C parser. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30786
[Bug preprocessor/30786] [4.1/4.2/4.3 Regression] ICE on _Pragma at end of file
--- Comment #3 from bonzini at gnu dot org 2007-04-16 20:24 --- Created an attachment (id=13373) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13373&action=view) patch to fix part of the bug By fixing the preprocessor part better, we can fix the bug completely. However, I don't have time now to prepare a proper patch (and test it properly). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30786
[Bug fortran/31591] ICE: on array initialization statement using 'ubound' (fortran/trans-array.c:3693)
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-04-16 20:42 ---
Ups, misread your report. After uncommenting the WRITE, all tested compilers
crash.
$> gfortran -v
gcc version 4.3.0 20070331
Backtrace:
Breakpoint 1, fancy_abort (file=0x86e4fec
"../../../gcc/gcc/fortran/trans-array.c", line=3693, function=0x86e55a0
"gfc_conv_array_initializer")
at ../../../gcc/gcc/diagnostic.c:656
656 internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) bt
#0 fancy_abort (file=0x86e4fec "../../../gcc/gcc/fortran/trans-array.c",
line=3693, function=0x86e55a0 "gfc_conv_array_initializer")
at ../../../gcc/gcc/diagnostic.c:656
#1 0x080b7183 in gfc_conv_array_initializer (type=0xb7ce4ec4, expr=0x8894d38)
at ../../../gcc/gcc/fortran/trans-array.c:3693
#2 0x080d093c in gfc_conv_initializer (expr=0x8894d38, ts=0x8894720,
type=0xb7ce4ec4, array=160 ' ', pointer=109 'm')
at ../../../gcc/gcc/fortran/trans-expr.c:2740
#3 0x080c5f86 in gfc_get_symbol_decl (sym=0x8894710) at
../../../gcc/gcc/fortran/trans-decl.c:1018
#4 0x080ccb9d in gfc_conv_expr (se=0xbfea9304, expr=0x8894fd8) at
../../../gcc/gcc/fortran/trans-expr.c:391
#5 0x080cfa9e in gfc_conv_expr_lhs (se=0xbfea9304, expr=0x8894fd8) at
../../../gcc/gcc/fortran/trans-expr.c:3167
#6 0x080b77e6 in gfc_conv_ss_descriptor (block=0xbfea95e4, ss=0x8895220,
base=0) at ../../../gcc/gcc/fortran/trans-array.c:1838
#7 0x080ba62c in gfc_conv_expr_descriptor (se=0xbfea95e4, expr=0x8894fd8,
ss=0x8895220) at ../../../gcc/gcc/fortran/trans-array.c:4316
#8 0x080dac5e in gfc_trans_transfer (code=0x8895100) at
../../../gcc/gcc/fortran/trans-io.c:1838
#9 0x080b075d in gfc_trans_code (code=0x8895100) at
../../../gcc/gcc/fortran/trans.c:605
#10 0x080dd05d in build_dt (function=0xb7cdce0c, code=0x88951c0) at
../../../gcc/gcc/fortran/trans-io.c:1507
#11 0x080b073d in gfc_trans_code (code=0x88951c0) at
../../../gcc/gcc/fortran/trans.c:581
#12 0x080c7d06 in gfc_generate_function_code (ns=0x885a1e8) at
../../../gcc/gcc/fortran/trans-decl.c:3217
#13 0x0808c2b4 in gfc_parse_file () at ../../../gcc/gcc/fortran/parse.c:3261
#14 0x080ab660 in gfc_be_parse_file (set_yydebug=0) at
../../../gcc/gcc/fortran/f95-lang.c:305
#15 0x0830042d in toplev_main (argc=3, argv=0xbfea9954) at
../../../gcc/gcc/toplev.c:1050
#16 0x080ed162 in main (argc=1600349799, argv=0x766e6f63) at
../../../gcc/gcc/main.c:35
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-04-16 20:42:01
date||
Summary|internal compiler error on |ICE: on array initialization
|array initialization|statement using 'ubound'
|statement using 'ubound'|(fortran/trans-array.c:3693)
Version|unknown |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31591
[Bug fortran/31592] New: Better message if using non-intrinsic initialization expression
The following is invalid and detected as such, however, the error message needs improvement PROGRAM Test_ceres implicit none real, dimension(10) :: TCg_coef integer, parameter, dimension(1) :: & TCg_bband_coef_ranks = X() contains function X() integer, dimension(1) :: X X = -4 end function X end program Test_ceres gfortran: Function 'x' at (1) has no IMPLICIT type Which is very odd because X is defined. NAG f95 is better: Reference to non-intrinsic function X in initialisation expression If one removes "implicit none", gfortran correctly prints: Function 'x' in initialization expression at (1) must be an intrinsic function -- Summary: Better message if using non-intrinsic initialization expression Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31592
[Bug fortran/31591] ICE: on array initialization statement using 'ubound' (fortran/trans-array.c:3693)
--- Comment #4 from burnus at gcc dot gnu dot org 2007-04-16 21:14 ---
The assert is trans-array.c's gfc_conv_array_initializer
switch (expr->expr_type)
{
...
default:
gcc_unreachable ();
Here, expr->expr_type is EXPR_FUNCTION.
By the way, the scalar version, i.e. removing "dimension" and using
"ubound(TCg_coef,1)", works.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31591
[Bug fortran/31593] New: Invariant DO loop variables (and I/O)
Compare this:
$ cat count.f90
program main
implicit none
integer, parameter :: value = 747
integer :: p1, p2, p3, p4
integer :: i
do i=1, 10
do p1 = 1, value-2
do p2 = p1 + 1, value - p1
do p3 = p2 + 1, value - p1 - p2
p4 = value - p1 - p2 - p3
if (p1 * p2 * p3 * p4 == value * 100) &
print '(4(I0,:" "))',p1,p2,p3,p4
end do
end do
end do
end do
end program main
$ gfortran -O3 count.f90
$ time ./a.out > /dev/null
real0m0.634s
user0m0.620s
sys 0m0.004s
with the equivalent
$ cat count.c
#include
const int value = 747;
int main()
{
int i, p1, p2, p3, p4;
for (i=1; i<=10; i++)
{
for (p1 = 1; p1 <= value - 2 ; p1++)
{
for (p2 = p1 + 1; p2 <= value - p1; p2++)
{
for (p3 = p2 + 1; p3 <= value - p1 - p2; p3++)
{
p4 = value - p1 - p2 - p3;
if (p1 * p2 * p3 * p4 == value * 100)
printf("%d %d %d %d\n", p1, p2, p3, p4);
}
}
}
}
}
$ gcc -O3 count.c
$ time ./a.out > /dev/null
real0m0.396s
user0m0.380s
sys 0m0.000s
We don't
- take advantage of the fact that p1, p2, p3 and p4 cannot
be legally changed in the do loop
- take advantage of the fact that the I/O statemetns don't change
the values
so we miss out on common subexpression elimination. Here's a
part from the *.optimized file:
:;
p2.3 = p2;
p3.5 = p2.3 + 1;
D.1014 = (747 - p1) - p2.3;
p3 = p3.5;
if (p3.5 <= D.1014) goto ; else goto ;
:;
p1.58 = p1;
p2.60 = p2;
p3.61 = p3;
p4.7 = ((747 - p1.58) - p2.60) - p3.61;
p4 = p4.7;
if (((p2.60 * p1.58) * p3.61) * p4.7 == 74700) goto ; else goto ;
--
Summary: Invariant DO loop variables (and I/O)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
[Bug tree-optimization/20165] Pointer does not really escape with write
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-16 22:54 --- *** Bug 31593 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20165
[Bug fortran/31593] Invariant DO loop variables (and I/O)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-16 22:54 --- This is not suprising as it is a dup of bug 20165 anyways. *** This bug has been marked as a duplicate of 20165 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
[Bug fortran/31593] Invariant DO loop variables and subroutines
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-04-16 23:03 --- (In reply to comment #1) > This is not suprising as it is a dup of bug 20165 anyways. > > *** This bug has been marked as a duplicate of 20165 *** Only one part. The other part is that we don't mark the variables in a do statement as unchanging. Consider the following: $ cat count-3.f90 program main implicit none integer, parameter :: value = 747 integer :: p1, p2, p3, p4 integer :: i do i=1, 10 do p1 = 1, value-2 do p2 = p1 + 1, value - p1 do p3 = p2 + 1, value - p1 - p2 p4 = value - p1 - p2 - p3 if (p1 * p2 * p3 * p4 == value * 100) & call output (p1, p2, p3, p4) end do end do end do end do end program main This produces the (partial) dump :; p2.2 = p2; p3.4 = p2.2 + 1; D.1014 = (747 - p1) - p2.2; p3 = p3.4; if (p3.4 <= D.1014) goto ; else goto ; :; p1.57 = p1; p2.59 = p2; p3.60 = p3; p4.6 = ((747 - p1.57) - p2.59) - p3.60; p4 = p4.6; if (((p2.59 * p1.57) * p3.60) * p4.6 == 74700) goto ; else goto ; Reopening, adjusting subject. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | Summary|Invariant DO loop variables |Invariant DO loop variables |(and I/O) |and subroutines http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
[Bug fortran/31594] New: gfortran failed to compiled a 'valid' code
The attached fortran code (a smaller section cut and paste from original) was generated by a custom preprocessor. The code very much seems to be valid fortran 77, though its has some weird tab spacings; It compiles (and executes) fine with pgf90 and ifort-8.x. The compile time error is as below (same with gfortran-4.1.2, 4.2 and 4.3.0 trunck build); [EMAIL PROTECTED] ~]$ gfortran -c -fcray-pointer adw_test.f adw_test.f:61.9: a(m,1) = p(m,1) * F_in (o1(m,1)-1) + p(m,2) * F_in (o1(m,1)) 1 Error: Unclassifiable statement at (1) adw_test.f:90.8: %(m,3) * F_in (o1(m,3)+1) + p(m,4) * F_in (o1(m,3)+2) 1 Error: Expected PARAMETER symbol in complex constant at (1) adw_test.f:94.8: %(m,3) * F_in (o3(m,3)+1) + p(m,4) * F_in (o3(m,3)+2) 1 Error: Expected PARAMETER symbol in complex constant at (1) -- Summary: gfortran failed to compiled a 'valid' code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: deji_aking at yahoo dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31594
[Bug fortran/31594] gfortran failed to compiled a 'valid' code
--- Comment #1 from deji_aking at yahoo dot ca 2007-04-16 23:07 --- Created an attachment (id=13374) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13374&action=view) testcase (cut and paste from original) I can provide the whole file if necessary -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31594
[Bug fortran/31593] Invariant DO loop variables and subroutines
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-16 23:12 --- call output (p1, p2, p3, p4) That still clobbers p1, p2, p3, and p4 as they are passed by reference so is it really undefined code if output changes the values for the do loop? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-04-16 23:15
---
OK, I've researched the libiberty md5.c interface a bit and here's the first
half of a patch :) It computes the MD5 sum of the module file (except the
first 3 lines) and it writes it at the top, like this:
GFORTRAN module created from test_mod.f90 on Tue Apr 17 00:12:12 2007
MD5:18a257e13c90e3872b7b9400c2fc6e4b -- If you edit this, you'll get what you
deserve.
I checked that it gives the same result as the md5sum command on my linux box
:)
Index: module.c
===
--- module.c(revision 123388)
+++ module.c(working copy)
@@ -72,6 +72,7 @@
#include "arith.h"
#include "match.h"
#include "parse.h" /* FIXME */
+#include "md5.h"
#define MODULE_EXTENSION ".mod"
@@ -170,6 +171,9 @@
/* The FILE for the module we're reading or writing. */
static FILE *module_fp;
+/* MD5 context structure. */
+static struct md5_ctx ctx;
+
/* The name of the module we're reading (USE'ing) or writing. */
static char module_name[GFC_MAX_SYMBOL_LEN + 1];
@@ -1275,6 +1279,9 @@
if (fputc (out, module_fp) == EOF)
gfc_fatal_error ("Error writing modules file: %s", strerror (errno));
+ /* Add this to our MD5. */
+ md5_process_bytes (&out, sizeof (out), &ctx);
+
if (out != '\n')
module_column++;
else
@@ -3926,7 +3933,10 @@
int n;
char *filename, *p;
time_t now;
+ fpos_t md5_pos;
+ unsigned char md5_new[16]; /*, md5_old[16]; */
+
n = strlen (name) + strlen (MODULE_EXTENSION) + 1;
if (gfc_option.module_dir != NULL)
{
@@ -3959,8 +3969,14 @@
fprintf (module_fp, "GFORTRAN module created from %s on %s\n",
gfc_source_file, p);
- fputs ("If you edit this, you'll get what you deserve.\n\n", module_fp);
+ fputs ("MD5:", module_fp);
+ fgetpos (module_fp, &md5_pos);
+ fputs (" -- "
+"If you edit this, you'll get what you deserve.\n\n", module_fp);
+ /* Initialize the MD5 context that will be used for output. */
+ md5_init_ctx (&ctx);
+
iomode = IO_OUTPUT;
strcpy (module_name, name);
@@ -3973,6 +3989,11 @@
write_char ('\n');
+ md5_finish_ctx (&ctx, md5_new);
+ fsetpos (module_fp, &md5_pos);
+ for (n = 0; n < 16; n++)
+fprintf (module_fp, "%02x", md5_new[n]);
+
if (fclose (module_fp))
gfc_fatal_error ("Error writing module file '%s' for writing: %s",
filename, strerror (errno));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
[Bug c++/31517] [4.1/4.2/4.3 Regression] ICE on invalid initialization of static member of a template class
--- Comment #1 from patchapp at dberlin dot org 2007-04-16 23:30 --- Subject: Bug number PR c++/31517 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01041.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31517
[Bug c++/31513] [4.2/4.3 Regression] Miscompilation of Function Passing Bit Field Value to Function
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-04-17 00:28 --- Subject: Bug 31513 Author: mmitchel Date: Tue Apr 17 00:28:21 2007 New Revision: 123902 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123902 Log: PR c++/31513 * call.c (convert_for_arg_passing): Convert bitfields to their declared types. PR c++/31513 * g++.dg/expr/bitfield8.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/expr/bitfield8.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/call.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31513
[Bug c++/31513] [4.3 Regression] Miscompilation of Function Passing Bit Field Value to Function
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-04-17 00:34 --- Fixed in 4.2.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3 Regression]|[4.3 Regression] |Miscompilation of Function |Miscompilation of Function |Passing Bit Field Value to |Passing Bit Field Value to |Function|Function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31513
[Bug fortran/31144] gfortran module symbol names are not standard compliant
--- Comment #8 from tobi at gcc dot gnu dot org 2007-04-17 01:09 --- Subject: Bug 31144 Author: tobi Date: Tue Apr 17 01:09:34 2007 New Revision: 123904 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123904 Log: PR fortran/31144 fortran/ * decl.c (gfc_sym_mangled_identifier): Use capital letters in name mangling. (gfc_sym_mangled_function_id): Likewise. testsuite/ * gfortran.dg/module_naming_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/module_naming_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31144
[Bug fortran/31144] gfortran module symbol names are not standard compliant
--- Comment #9 from tobi at gcc dot gnu dot org 2007-04-17 01:12 --- Fixed. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31144
[Bug fortran/31593] Invariant DO loop variables and subroutines
--- Comment #4 from tobi at gcc dot gnu dot org 2007-04-17 01:14 --- (In reply to comment #3) > call output (p1, p2, p3, p4) > > That still clobbers p1, p2, p3, and p4 as they are passed by reference so is > it > really undefined code if output changes the values for the do loop? Yes. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-17 01:14:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
[Bug fortran/31594] gfortran failed to compiled a 'valid' code
--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-17 01:20 --- Your lines are too wide, hoping that bugzilla will not mess up the formatting I'll quote an example: 1 2 3 4 5 6 7 123456789012345678901234567890123456789012345678901234567890123456789012345 a(m,1) = p(m,1) * F_in (o1(m,1)-1) + p(m,2) * F_in (o1(m,1)) + %p(m,3) * F_in (o1(m,1)+1) + p(m,4) * F_in (o1(m,1)+2) ^^ Per the standard, fixed form lines are 72 characters and everything beyond is ignored, so the plus is not read. The -ffixed-line-length option should solve your problem. Closing as INVALID. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31594
[Bug target/15095] [3.4/4.0 Regression] gcc-3.4.0 fails to compile gmp-4.1.2
--- Comment #8 from vingocheng at 126 dot com 2007-04-17 06:16 --- The problem still exist. My working environment is : GCC : gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) GMP : the latest release version (gmp4.1) During compiling, the error will occur. But I fount if I remove the code "static void __gmpz_aorsmul _PROTO ((REGPARM_3_1 (mpz_ptr w, mpz_srcptr x, mpz_srcptr y, mp_size_t sub))) REGPARM_ATTR (1);" , it can be passed. So to solve the problem, you can remove the static declaration for the functions that have conflicting type. But I am not sure whether is correct or not. It only make the process of compiling passed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15095
[Bug tree-optimization/31522] False overflow warning with phi nodes
--- Comment #10 from ian at gcc dot gnu dot org 2007-04-17 06:33 --- Subject: Bug 31522 Author: ian Date: Tue Apr 17 06:33:38 2007 New Revision: 123908 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123908 Log: ./: PR tree-optimization/31522 * tree-vrp.c (vr_phi_edge_counts): New static variable. (vrp_initialize): Allocate vr_phi_edge_counts. (vrp_visit_phi_node): Don't push to infinity if we saw a new executable edge. Drop test for all constants. (vrp_finalize): Free vrp_phi_edge_counts. testsuite/: PR tree-optimization/31522 * gcc.dg/Wstrict-overflow-16.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wstrict-overflow-16.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31522
[Bug rtl-optimization/19580] [4.0/4.1/4.2/4.3 Regression] missed load/store motion
--- Comment #30 from dberlin at gcc dot gnu dot org 2007-04-17 06:53 --- Is this really still broken in mainline? At least as of Richard's last update, it wasn't -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug fortran/31594] gfortran failed to compiled a 'valid' code
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-17 07:12 --- To the reporter: Even though this is already (correctly) closed as INVALID, please let us know if your code does compile and run correctly if you compile with the suggested extra command line option, -ffixed-line-length. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31594
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #15 from gcc at magfr dot user dot lysator dot liu dot se 2007-04-17 07:15 --- I think there are still some kind of problem. If I try to compile bar.C using g++ -c bar.C then where g++ is g++ (GCC) 4.3.0 20070416 (experimental) (Hm, I'd wish for a revision number in there somewhere) then I get an ICE: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #16 from gcc at magfr dot user dot lysator dot liu dot se 2007-04-17 07:18 --- Created an attachment (id=13375) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13375&action=view) Test showing that the current fix causes an ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug tree-optimization/25809] missed PRE optimization - move "invariant casts" out of loops
--- Comment #5 from dorit at il dot ibm dot com 2007-04-17 07:22 --- > Doing cast motion actually causes about 25 *more* failures in the vectorizer > testsuite. > I'm closing this as won't fix since it seems there was no other reason to do > this. can you please send me the patch so that I could look at this failures before you close this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25809
[Bug tree-optimization/25809] missed PRE optimization - move "invariant casts" out of loops
--- Comment #6 from dorit at il dot ibm dot com 2007-04-17 07:38 --- > can you please send me the patch so that I could look at this failures before > you close this PR? I'm going over my inbox top down, so I just saw that you had laready sent the patch... so I will look into it. (thanks!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25809
[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-04-17 07:52 --- Created an attachment (id=13376) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13376&action=view) Patch that allows for module to be overwritten only if they changed This is the complete patch. Have fun! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
[Bug libgcj/30071] make install fails for libjava
--- Comment #4 from r dot emrich at de dot tecosim dot com 2007-04-17 07:54 --- Created an attachment (id=13377) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13377&action=view) Patch Proposed patch. I added a new target (install-exec-am) to Makefile.am to enforce the right installation sequence. Tested on hppa2.0w-hp-hpux11.00 and i686-pc-linux-gnu. I hope somebody is able to verify and submit the patch. In general there is the question, if we need a regular testing of 'make install, to detect these kind of problems, which only give warnings on linux but prevend successful installation on different targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30071
