[Bug middle-end/32711] Regression: ICE when using inline asm constraint "X"
--- Comment #3 from ubizjak at gmail dot com 2007-07-10 06:46 ---
(In reply to comment #1)
> "X" constraint means anything matches. Now why we are ICEing is a bit weird
We hit:
/* We have patterns that allow zero sets of memory, for instance.
In 64-bit mode, we should probably support all 8-byte vectors,
since we can in fact encode that into an immediate. */
if (GET_CODE (x) == CONST_VECTOR)
{
gcc_assert (x == CONST0_RTX (GET_MODE (x)));
x = const0_rtx;
}
It is true that a message would be nice there, but it is also true that X is an
invalid constraint for most (all?) of the instructions.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32711
[Bug fortran/20520] allocatable arrays used uninitialized without a warning
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-07-10 06:37 --- *** Bug 32709 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
[Bug fortran/32709] Diagnose: ALLOCATABLE array used but never ALLOCATEd
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-10 06:37 --- *** This bug has been marked as a duplicate of 20520 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32709
[Bug fortran/32673] Wrongly allowed: Statement function with subobject of constant
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-10 06:23 --- I think this is indeed no bug. I contacted NAG f95 and if they found something in the standard which we overlooked, I will reopen this PR. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32673
[Bug libfortran/32702] [4.3 Regression] crash when printing big character variable
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-07-10 05:59 --- Closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32702
[Bug libfortran/32702] [4.3 Regression] crash when printing big character variable
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-07-10 05:37 --- Subject: Bug 32702 Author: jvdelisle Date: Tue Jul 10 05:37:29 2007 New Revision: 126510 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126510 Log: 2007-07-09 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/32702 * io/unix.c (unix_stream): Restore buffer pointer and small_buffer. (fd_alloc): If the number of bytes needed is greater than the default BUFFER_SIZE, allocate a new buffer large enough. Free the old buffer if necessary. (fd_sfree): Restore use of buffer pointer. (fd_close): Likewise. (fd_open): Likewise. (init_error_stream): Likewise. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32702
[Bug fortran/32157] intrinsic function name conflicts with subroutine if present in the same file
--- Comment #7 from pault at gcc dot gnu dot org 2007-07-10 05:15 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32157
[Bug fortran/32634] renamed, use associated generic interface rejected
--- Comment #4 from pault at gcc dot gnu dot org 2007-07-10 05:13 --- Fixed on trunk. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32634
[Bug fortran/32689] [4.3 regression] TRANSFER returns scalar, even if MOLD is an array
--- Comment #4 from pault at gcc dot gnu dot org 2007-07-10 05:12 --- Fixed Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32689
[Bug fortran/32689] [4.3 regression] TRANSFER returns scalar, even if MOLD is an array
--- Comment #3 from pault at gcc dot gnu dot org 2007-07-10 05:11 --- Subject: Bug 32689 Author: pault Date: Tue Jul 10 05:11:00 2007 New Revision: 126509 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126509 Log: 2007-07-10 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32157 * resolve.c (is_external_proc): New function. Adds test that the symbol is not an intrinsic procedure. * (resolve_function, resolve_call): Replace logical statements with call to is_external_proc. PR fortran/32689 * simplify.c (gfc_simplify_transfer): If mold has rank, the result is an array. PR fortran/32634 * module.c (write_generic): Write the local name of the interface. 2007-07-10 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32157 * gfortran.dg/overload_2.f90: New test. PR fortran/32689 * gfortran.dg/transfer_simplify_5.f90 PR fortran/32634 * gfortran.dg/interface_15.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/interface_16.f90 trunk/gcc/testsuite/gfortran.dg/overload_2.f90 trunk/gcc/testsuite/gfortran.dg/transfer_simplify_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32689
[Bug fortran/32634] renamed, use associated generic interface rejected
--- Comment #3 from pault at gcc dot gnu dot org 2007-07-10 05:11 --- Subject: Bug 32634 Author: pault Date: Tue Jul 10 05:11:00 2007 New Revision: 126509 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126509 Log: 2007-07-10 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32157 * resolve.c (is_external_proc): New function. Adds test that the symbol is not an intrinsic procedure. * (resolve_function, resolve_call): Replace logical statements with call to is_external_proc. PR fortran/32689 * simplify.c (gfc_simplify_transfer): If mold has rank, the result is an array. PR fortran/32634 * module.c (write_generic): Write the local name of the interface. 2007-07-10 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32157 * gfortran.dg/overload_2.f90: New test. PR fortran/32689 * gfortran.dg/transfer_simplify_5.f90 PR fortran/32634 * gfortran.dg/interface_15.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/interface_16.f90 trunk/gcc/testsuite/gfortran.dg/overload_2.f90 trunk/gcc/testsuite/gfortran.dg/transfer_simplify_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32634
[Bug fortran/32157] intrinsic function name conflicts with subroutine if present in the same file
--- Comment #6 from pault at gcc dot gnu dot org 2007-07-10 05:11 --- Subject: Bug 32157 Author: pault Date: Tue Jul 10 05:11:00 2007 New Revision: 126509 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126509 Log: 2007-07-10 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32157 * resolve.c (is_external_proc): New function. Adds test that the symbol is not an intrinsic procedure. * (resolve_function, resolve_call): Replace logical statements with call to is_external_proc. PR fortran/32689 * simplify.c (gfc_simplify_transfer): If mold has rank, the result is an array. PR fortran/32634 * module.c (write_generic): Write the local name of the interface. 2007-07-10 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32157 * gfortran.dg/overload_2.f90: New test. PR fortran/32689 * gfortran.dg/transfer_simplify_5.f90 PR fortran/32634 * gfortran.dg/interface_15.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/interface_16.f90 trunk/gcc/testsuite/gfortran.dg/overload_2.f90 trunk/gcc/testsuite/gfortran.dg/transfer_simplify_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32157
[Bug libstdc++/32683] Compiling HPCToolkit causes many errors and warnings using GCC 4.3 (but not prior versions)
--- Comment #7 from rob1weld at aol dot com 2007-07-10 04:55 --- >--- Comment #3 From Paolo Carlini 2007-07-09 08:43 [reply] --- >Note that in 4.3 the header dependencies have been streamlined and it's well >possible that some projects around are failing to include required headers. >Please double check in this light, thanks. In _some_ cases that is true "some projects around are failing to include required headers". In _other_ cases the problem is that GCC 4.3 has re-ordered the resulting inclusion sequence by not "polluting" (if that is how you feel about it) some files with _assumed_ excess header files. The lack of these _assumed_ excess header files early in the resulting ".ii" file is causing the undefined errors. Since the "new" GCC 4.3 headers are 'light' (no extra baggage) the include _may_ get used later (in _some_ cases a 'popular' include (like types.h) is _bound_ to be included, in many cases). Since all correctly written .h (or .hpp) files use [ "#ifndef X_H" "#define X_H" "Eendif" ] to surround themselves (and avoid being included twice) in the case of removing "sys/types.h" (and likely a couple of others) we have a situation that causes breakage rather than actually lightening the resulting .h (or .hpp) file. It would make the resulting object file no smaller either. Here is an example: I compiled the files using -save-temps and renamed the ".ii" files by GCC version. Here is a comparison of the files produced by GCC 4.1 and GCC 4.3: In file OAInterface_4.1.ii we have this: /* Line 5955 */ # 1 "/usr/include/sys/types.h" 1 3 4 /* Line 6022 */ typedef unsigned short int ushort; /* Line 39661 */ ushort insnSize; In file OAInterface_4.3.ii we have this: /* Line 28636 */ ushort insnSize; /* Line 33996 */ # 1 "/usr/include/sys/types.h" 1 3 4 /* Line 34063 */ typedef unsigned short int ushort; Notice that the file "/usr/include/sys/types.h" has it's line number ONE on line number 5955 using version 4.1, but it is on line 33996 using 4.3 ! The omission of "/usr/include/sys/types.h" from one of the includes in 4.3 (where it was present in 4.1) means that it eventually gets picked up by a later include file (in 4.3) and appears too late (after it is neccesary). This means that source code that worked previously with 4.1 (or older) will need their local source include files line numbers permutated to occur after the inclusion of what GCC 4.3 _might_ define in a particular include file and prior to what any later includes _might_ need defined by that particular local include. Simply placing the local includes last in the list of all included files (at the top of the source file, assuming that "#include" does not occur later in the file (like it sometimes does in GCC)) will not always work since the include files sometimes use defines that activate features used in later includes. That is a "travelling salesman" problem _BUT_ in addition you need to know how to alter each "salesman's" wares (not part of the clasical "TS" problem). That means it is very time consuming; in case what I am saying is unclear. I don't use C++ much (and know how to fix this) so one of you is welcome to "Reopen bug" or "Leave as RESOLVED INVALID" - since I did not change the setting. I thank you both and appreciate your expert advice on this matter. If this is how C++ is "really supposed to be" then it is technically correct to leave this and let the world deal with it's problem. I'm not working the tech support lines. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32683
[Bug libstdc++/32683] Compiling HPCToolkit causes many errors and warnings using GCC 4.3 (but not prior versions)
--- Comment #6 from rob1weld at aol dot com 2007-07-10 04:31 --- >Comment #5 From Paolo Carlini 2007-07-09 21:19 [reply] --- >The last issue simply doesn't make sense. On page http://gcc.gnu.org/bugs.html#need it says: "the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command, or, in the case of a bug report for the GNAT front end, a complete set of source files (see below)." What part of number two is confusing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32683
[Bug c++/32676] [cxx0x branch] incorrect member address when using delegate constructors and virtual inheritance
--- Comment #1 from pedro dot lamarao at mndfck dot org 2007-07-10 01:33 --- Just to note I'm aware of the bug. I'll take a look at it soon but unfortunately not too soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32676
[Bug rtl-optimization/32664] [sh] ICE in create_pre_exit, at mode-switching.c:373
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-07-10 01:02 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32664
[Bug rtl-optimization/32664] [sh] ICE in create_pre_exit, at mode-switching.c:373
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-07-10 01:01 --- Subject: Bug 32664 Author: kkojima Date: Tue Jul 10 01:01:11 2007 New Revision: 126507 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126507 Log: PR rtl-optimization/32664 * mode-switching.c (create_pre_exit): Skip barrier insns. Modified: trunk/gcc/ChangeLog trunk/gcc/mode-switching.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32664
[Bug libfortran/32702] [4.3 Regression] crash when printing big character variable
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-07-10 00:39 --- Got it. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-09 15:10:11 |2007-07-10 00:39:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32702
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-10 00:04 --- Subject: Re: [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f obje > The problem that i have is it the argument pointer does not have a fixed > value. it is assigned to a hard register sometimes during reload. Function.c generates an insn to copy it to a pseudo during rtl expansion. This is the so called internal argument pointer. It is assigned a hard register during reload. A copy is needed because the incoming argument pointer is a call clobbered register. The register used for the incoming argument pointer never changes. After the copy is made, the compiler is free to make whatever use it wants of the argument pointer register. If the internal argument pointer was removed, we would have to copy the incoming argument pointer to a fixed register in the prologue, or save and restore the argument pointer register across calls. I'm not sure either of these approaches is an improvement over what we have now. When a call is made, the pa call expander emits insns to load the argument pointer suitably for the call using virtual_outgoing_args_rtx. We don't restore the argument pointer after a call. However, we do this for the PIC register. The thinking behind the current approach is that accesses to the argument block are much less frequent than accesses using the PIC register. Typically, the argument pointer is only needed for calls which have more than eight arguments or for va_args. The generic copy method has always worked reasonably well although there are some tail call optimizations that don't occur when it is used. It probably would be possible to handle the argument pointer in a manner similar to the way we handle the PIC register. This is a bit tricky. The details of regarding the handling of the argument pointer would have to be hidden until after reload. We have some ugly post-reload splitters to handle this for the PIC register. The downside is we lose the use of a register when we don't need an argument pointer. I have the impression that you are confused about the reason the argument pointer isn't fixed. Reload doesn't modify its incoming value. Reload also can't eliminate it because it there isn't a fixed relationship to the stack pointer (or the frame pointer). So, reload doesn't affect its liveness. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug middle-end/32711] Regression: ICE when using inline asm constraint "X"
--- Comment #2 from scovich at gmail dot com 2007-07-09 23:27 --- (In reply to comment #1) > "X" constraint means anything matches. Now why we are ICEing is a bit weird. I started using it because "g" doesn't seem to allow xmm references. Fortunately, "xm" seems to have the desired effect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32711
[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s
--- Comment #11 from appfault at hotmail dot com 2007-07-09 23:21 --- I've been unable to reproduce any issues in 3.4.6, even with tests that do not rely on the empty string. I suspect there is something more specific that was fixed somewhere between 3.3.x and 3.4.6. It doesn't seem appropriate to have marked this as a dupe of bug 21334, since bug 21334 has had no code changes made, but clearly a code change was made at some point to fix the comment 0 report. I recommend the comment 0 test be added to the gcc regression test suite, after which this zilla could be reclassified as 'fixed'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261
[Bug middle-end/32711] Regression: ICE when using inline asm constraint "X"
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 22:59 --- "X" constraint means anything matches. Now why we are ICEing is a bit weird. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32711
[Bug middle-end/32711] New: Regression: ICE when using inline asm constraint "X"
Compiling the following functions with gcc-4.{1,2,3} results in an ICE.
gcc-3.4.4 does not ICE:
#include
static inline
__m128i my_asm(__m128i a, __m128i b) {
__m128i result;
asm("pshufb\t%1,%0" : "=x"(result) : "X"(b), "0"(a));
return result;
}
__m128i foo(__m128i src) {
return my_asm(src, _mm_set1_epi32(1));
}
If the inline asm is called directly (not through an inline function) or if the
"X" constraint changes to "mx" everything works fine.
--
Summary: Regression: ICE when using inline asm constraint "X"
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32711
[Bug fortran/32665] allocatable array on lhs deleted while still in use on rhs
--- Comment #1 from pault at gcc dot gnu dot org 2007-07-09 22:42 --- Oh dear - that's right. I feel a temporary coming on! Paul -- pault 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-07-09 22:42:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32665
[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- Comment #3 from pault at gcc dot gnu dot org 2007-07-09 22:40 ---
(In reply to comment #2)
Whilst I agree that this is a regession, it is so because an underlying bug is
exposed - in other words, r124541 is perfectly correct.
The following also fails:
program matrix
implicit none
real,dimension(2,2),parameter::c=reshape((/1,2,3,4/),(/2,2/))
real,dimension(2,2)::m
m=f()+c
m=c+f()
call sub(m+f())
call sub(c+m)
call sub(f()+c)
call sub(c+f())
contains
function f()
implicit none
real, dimension(2,2)::f
f=0
end function f
subroutine sub(a)
implicit none
real, dimension(2,2)::a
print *, a
end subroutine sub
end program matrix
which was not affected by the above patch.
This fixes both versions of the bug:
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (revision 126461)
--- gcc/fortran/trans-array.c (working copy)
*** gfc_trans_array_constructor (gfc_loopinf
*** 1656,1661
--- 1656,1673
/* See if the constructor determines the loop bounds. */
dynamic = false;
+
+ if (ss->expr->shape && loop->to[0] == NULL_TREE)
+ {
+ int n;
+ for (n = 0; n < ss->expr->rank; n++)
+ {
+ loop->to[n] = gfc_conv_mpz_to_tree (ss->expr->shape [n],
+ gfc_index_integer_kind);
+ loop->from[n] = gfc_index_zero_node;
+ }
+ }
+
if (loop->to[0] == NULL_TREE)
{
mpz_t size;
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
Last reconfirmed|2007-07-09 06:01:16 |2007-07-09 22:40:38
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug libfortran/32336] matmul: flag runtime- instead of assertation error
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-07-09 22:35 --- Fixed on trunk. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32336
[Bug libfortran/32336] matmul: flag runtime- instead of assertation error
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-07-09 22:35 --- Subject: Bug 32336 Author: tkoenig Date: Mon Jul 9 22:34:43 2007 New Revision: 126498 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126498 Log: 2007-07-09 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/32336 * m4/matmul.m4: When the dimension of b is incorrect, raise a runtime error instead of a failed assertion. * generated/matmul_i1.c: Regenerated. * generated/matmul_i2.c: Regenerated. * generated/matmul_i4.c: Regenerated. * generated/matmul_i8.c: Regenerated. * generated/matmul_i16.c: Regenerated. * generated/matmul_r4.c: Regenerated. * generated/matmul_r8.c: Regenerated. * generated/matmul_r10.c: Regenerated. * generated/matmul_r16.c: Regenerated. 2007-07-09 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/32336 * gfortran.dg/matmul_5.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/matmul_5.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i1.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i2.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32336
[Bug fortran/32710] ICE: namelist and subroutine with the same name
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-09 22:34 --- If one moves "subroutine name()" before "readinput", valgrind shows no problems. (And no ICE occurs with 4.2 and 4.1.) This occures for dt->namelist->name, which is "name" (len 4) ==18422==at 0x4A3FB2: build_dt (trans-io.c:1592) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32710
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #18 from zadeck at naturalbridge dot com 2007-07-09 22:28 --- Subject: Re: [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-09 > 22:01 --- > Subject: Re: [4.3 Regression] checking for suffix of object files... > configure: error: cannot compute suffix of f obje > > >> --- Comment #16 from bonzini at gnu dot org 2007-07-09 21:04 --- >> Looking out of the box, why can't we add it always, the same as we do with >> the >> frame and stack pointer?? I wonder if the fixed/variable thing is a red >> herring. >> > > From an ABI standpoint, the stack and argument pointers are equivalent. > They are both passed in hardware registers and they both point to places > on the stack on function entry. The argument pointer is *always* live > when a function is entered and this never changes, even if it isn't used. > So, from my standpoint, it seems reasonable to add it always (at least > for hppa64). > > However, I believe Kenny would like a solution that avoids having to > set the register as live in the entry defs (i.e., he would like to move > away from having entry defs, etc). > > Dave > > The problem that i have is it the argument pointer does not have a fixed value. it is assigned to a hard register sometimes during reload. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug fortran/29459] Spurious warning about uninitialized optional arguments
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-07-09 22:03 --- With the initial testcase: module foo_mod implicit none contains subroutine print_sub(fmt_acf,iu,labels) character (len=*), intent(in), optional :: fmt_acf integer , intent(in), optional :: iu character (len=*), intent(in), optional :: labels(:) if (present(iu)) then print*,iu end if if (present(fmt_acf)) then print*,fmt_acf end if if (present(labels)) then write (*,*) labels end if end subroutine print_sub ! end module foo_mod we still have the following warning with -O1 -Wall: u.f90: In function print_sub: u.f90:4: warning: may be used uninitialized in this function -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29459
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-09 22:01 --- Subject: Re: [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f obje > --- Comment #16 from bonzini at gnu dot org 2007-07-09 21:04 --- > Looking out of the box, why can't we add it always, the same as we do with the > frame and stack pointer?? I wonder if the fixed/variable thing is a red > herring. >From an ABI standpoint, the stack and argument pointers are equivalent. They are both passed in hardware registers and they both point to places on the stack on function entry. The argument pointer is *always* live when a function is entered and this never changes, even if it isn't used. So, from my standpoint, it seems reasonable to add it always (at least for hppa64). However, I believe Kenny would like a solution that avoids having to set the register as live in the entry defs (i.e., he would like to move away from having entry defs, etc). Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug fortran/29459] Spurious warning about uninitialized optional arguments
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-07-09 22:01 --- Subject: Bug 29459 Author: fxcoudert Date: Mon Jul 9 22:00:52 2007 New Revision: 126496 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126496 Log: PR fortran/29459 * trans-array.c (gfc_trans_array_constructor): Mark offset field with TREE_NO_WARNING. * trans-decl.c (gfc_build_qualified_array): Mark lbound, ubound, stride and size variables with TREE_NO_WARNING. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29459
[Bug fortran/32710] ICE: namelist and subroutine with the same name
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-09 21:57 --- Works for me with 4.3.0; I can reproduce the ICE with 4.2 and 4.1. valgrind with 4.3.0 shows: ==18422== Invalid read of size 8 ==18422==at 0x4A3FB2: build_dt (trans-io.c:1592) ==18422==by 0x47819E: gfc_trans_code (trans.c:670) ==18422==by 0x48CCFE: gfc_generate_function_code (trans-decl.c:3224) ==18422==by 0x48CF84: gfc_generate_function_code (trans-decl.c:2838) ==18422==by 0x44E0C3: gfc_parse_file (parse.c:3279) ==18422==by 0x47279D: gfc_be_parse_file (f95-lang.c:301) ==18422==by 0x6B3733: toplev_main (toplev.c:1051) ==18422==by 0x52BEB43: (below main) (in /lib64/libc-2.6.so) ==18422== Address 0x40E1F50 is 0 bytes inside a block of size 392 free'd ==18422==at 0x4C2291B: free (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==18422==by 0x44BBBA: gfc_fixup_sibling_symbols (parse.c:2774) ==18422==by 0x44DAD4: parse_contained (parse.c:2858) ==18422==by 0x44DDEC: parse_progunit (parse.c:2980) ==18422==by 0x44E094: gfc_parse_file (parse.c:3217) ==18422==by 0x47279D: gfc_be_parse_file (f95-lang.c:301) ==18422==by 0x6B3733: toplev_main (toplev.c:1051) ==18422==by 0x52BEB43: (below main) (in /lib64/libc-2.6.so) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-09 21:57:56 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32710
[Bug fortran/32710] New: ICE: namelist and subroutine with the same name
program samename contains subroutine readInput implicit none integer:: a,b,c NAMELIST /name/ a,b,c read(5,nml=name) end subroutine readInput subroutine name() end subroutine name end program this code fails with the following error (gfortran 4.3 and 4.1.3): samename.f90: In function readinput: samename.f90:6: internal compiler error: Segmentation fault for gfortran 4.2 the error message is: samename.f90: In function readinput: samename.f90:6: internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:693 just defining the namelist works fine, only the read statement triggers the ICE -- Summary: ICE: namelist and subroutine with the same name Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jaydub66 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32710
[Bug fortran/32689] [4.3 regression] TRANSFER returns scalar, even if MOLD is an array
--- Comment #2 from pault at gcc dot gnu dot org 2007-07-09 21:33 ---
(In reply to comment #1)
How wierd and wonderful - whilst it is a regression, it is only just; given the
timing of gfc_array_transfer and gfc_simplify_transfer, the latter undid the
former by only a few months or so:)
Really galling is that Brooks and I missed this case and that the fix is so
very easy *sigh*
Index: gcc/fortran/simplify.c
===
*** gcc/fortran/simplify.c (revision 126461)
--- gcc/fortran/simplify.c (working copy)
*** gfc_simplify_transfer (gfc_expr *source,
*** 3924,3930
/* Set the number of elements in the result, and determine its size. */
result_elt_size = gfc_target_expr_size (mold_element);
! if (mold->expr_type == EXPR_ARRAY || size)
{
int result_length;
--- 3924,3930
/* Set the number of elements in the result, and determine its size. */
result_elt_size = gfc_target_expr_size (mold_element);
! if (mold->expr_type == EXPR_ARRAY || mold->rank || size)
{
int result_length;
I will commit this tomorrow morning, with two other "obvious" patches, after
regtesting.
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
Last reconfirmed|2007-07-09 09:10:41 |2007-07-09 21:33:26
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32689
[Bug libstdc++/32683] Compiling HPCToolkit causes many errors and warnings using GCC 4.3 (but not prior versions)
--- Comment #5 from pcarlini at suse dot de 2007-07-09 21:19 --- (In reply to comment #4) > >Comment #2 From Andrew Pinski 2007-07-09 02:53 [reply] --- > >No include for or . > > Andrew, I'm not an expert at C++ but I did my best to attempt to make a couple > of reduced testcases where I felt I was able. BOTH those testcases _do_ use > "#include ". That header has *nothing* to do with and > There exists TWO issues not dealt with in your replies (see above): > > 1): "There is something about the way GCC 4.3 builds "gij" that does not let > it > run .jar files that work perfectly on the WinXP platform with Internet > Explorer." > > 2): The ".ii" files that GCC produces are not 'all inclusive' - you can't move > them and then simply compile them in a different directory (like ".i" files). > How are we supposed to create an ".ii" file and attach it for an expert to > study? (as is suggested we do for "C" errors and ".i" files). Maybe the > streamlining has caused this The last issue simply doesn't make sense. The former at best is a separate Java issue. -- pcarlini at suse dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32683
[Bug fortran/32709] New: Diagnose: ALLOCATABLE array used but never ALLOCATEd
NAG f95 does: Error: foo.f90, line 45: ALLOCATABLE array NCOSET used but never ALLOCATEd gfortran does not detect this. Testcase, see PR 31683. -- Summary: Diagnose: ALLOCATABLE array used but never ALLOCATEd 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=32709
[Bug middle-end/32708] New: _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x() inefficient
Consider the following functions (compiled with "g++-4.1.2 -msse3 -O3"):
#include
__m128i int2vector(int i) { return _mm_cvtsi32_si128(i); }
int vector2int(__m128i i) { return _mm_cvtsi128_32(i); }
__m128i long2vector(long long i) { return _mm_cvtsi64x_si128(i); }
long long vector2long(__m128i) { return _mm_cvtsi128_si64x(i); }
They become:
_Z10int2vectori:
movd%edi, %xmm0
ret
_Z10vector2intU8__vectorx:
movd%xmm0, %rax
movq%xmm0, -16(%rsp)
ret
_Z11long2vectorx:
movd%rdi, %mm0
movq%rdi, -8(%rsp)
movq2dq %mm0, %xmm0
ret
_Z11vector2longU8__vectorx:
movd%xmm0, %rax
movq%xmm0, -16(%rsp)
ret
long2vector() should use a simple MOVQ instruction the way int2vector() uses
MOVD. It appears that the reason for the stack access is that the original code
used a reg64->mem->mm->xmm path, which the optimizer partly noticed;
gcc-4.3-20070617 leaves the full path in place.
Also, do the vector2() functions really need to access the stack?
Finally, I've noticed several places where instructions involving 64-bit values
use the "d/l" suffix (e.g. "long i = 0" ==> "xorl %eax, %eax"), or 32-bit
operations that use 64-bit registers (e.g. "movd %xmm0, %rax" above). Are those
generally features, bugs, or a "who cares?"
--
Summary: _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x()
inefficient
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32708
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #16 from bonzini at gnu dot org 2007-07-09 21:04 --- Looking out of the box, why can't we add it always, the same as we do with the frame and stack pointer?? I wonder if the fixed/variable thing is a red herring. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug libstdc++/32683] Compiling HPCToolkit causes many errors and warnings using GCC 4.3 (but not prior versions)
--- Comment #4 from rob1weld at aol dot com 2007-07-09 21:01 --- >Comment #2 From Andrew Pinski 2007-07-09 02:53 [reply] --- >No include for or . Andrew, I'm not an expert at C++ but I did my best to attempt to make a couple of reduced testcases where I felt I was able. BOTH those testcases _do_ use "#include ". In addition both my testcases (and HPCToolkit) compile with versions of GCC < 4.3 . > All of these look like missing includes in the source No. (my testcases are not.) (see answer to Paolo below). > and nothing wrong with GCC 4.3.0. Maybe. Either GCC 4.3 is incorrect and all the prior versions are OK, _or_ the other way around. Between the people at Rice and you, you know more about C++ than me. >Comment #3 From Paolo Carlini 2007-07-09 08:43 [reply] --- >Note that in 4.3 the header dependencies have been streamlined and it's well >possible that some projects around are failing to include required headers. >Please double check in this light, thanks. I'm building 4.2.1 (with concept checking off) so I can build HPCToolkit without any trouble. While that is running I'll open another window and go back and play with HPCToolkit some more (using 4.3). >dependencies have been streamlined That will break a lot of code. Asuming that 4.3 is adhearing to _all_ C++ standards correctly and that HPCToolkit (and many other programs) are poorly written it would be kind to have a "-fuse-old-headers" switch. Fixing versions of GCC < 4.3 to have correct header dependancies would only cause more programs to fail to compile. That's not 'our' fault but sometimes we need to be accomidating (Look at all the switches in gcc.info 'C++ Dialect Options' we have just to be compatible with old code - may need one more). There exists TWO issues not dealt with in your replies (see above): 1): "There is something about the way GCC 4.3 builds "gij" that does not let it run .jar files that work perfectly on the WinXP platform with Internet Explorer." 2): The ".ii" files that GCC produces are not 'all inclusive' - you can't move them and then simply compile them in a different directory (like ".i" files). How are we supposed to create an ".ii" file and attach it for an expert to study? (as is suggested we do for "C" errors and ".i" files). Maybe the streamlining has caused this. Paolo, I'm doing that now. Back before tommorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32683
[Bug bootstrap/32690] 4.2.1 Bootstrap fails - gcc-4_2-branch/boehm-gc/ltconfig: No such file or directory
--- Comment #1 from rob1weld at aol dot com 2007-07-09 20:27 --- A few hours later and it failed for want of ltcf-c.sh and ltcf-cxx.sh. I ran gcc_update again and that fixed the configure / makefile problem of not copying those files over. There is still the annoyance of the build re-starting too far back and using "rm -f stage_current" / "rm -rf stagefeedback-*" - even if you only type just "make" (instead of "make profiledbootstrap"). It would be better if the build made it as far as the libraries then it would not try to remake the 'use feedback' stages and simply continue the libraries where it left off. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32690
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-07-09 19:42 --- Subject: Bug 32698 Author: rguenth Date: Mon Jul 9 19:41:54 2007 New Revision: 126494 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126494 Log: 2007-07-09 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/32698 * fold-const.c (fold_plusminus_mult_expr): Move constant arguments second to allow decomposing. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug c/32692] Inconsistent warning/error with static and non-static declarations
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-07-09 19:34 --- 'external linkage' is not the same thing as 'the declaration contains the keyword "extern"'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32692
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Comment #18 from aoliva at gcc dot gnu dot org 2007-07-09 19:24 --- Subject: Bug 23551 Author: aoliva Date: Mon Jul 9 19:24:23 2007 New Revision: 126492 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126492 Log: Revert: 2007-07-06 Alexandre Oliva <[EMAIL PROTECTED]> PR debug/23551 * tree-ssa-copyrename.c (copy_rename_partition_coalesce): Disregard DECL_FROM_INLINE. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-copyrename.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code
--- Comment #16 from uros at gcc dot gnu dot org 2007-07-09 19:22 --- Subject: Bug 27855 Author: uros Date: Mon Jul 9 19:22:03 2007 New Revision: 126491 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126491 Log: PR target/27855 * doc/extend.texi: Add ftree-reassoc flag. * common.opt (ftree-reassoc): New flag. * tree-ssa-reassoc.c (gate_tree_ssa_reassoc): New static function. (struct tree_opt_pass pass_reassoc): Use gate_tree_ssa_reassoc. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/tree-ssa-reassoc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- Comment #2 from jaydub66 at gmail dot com 2007-07-09 19:17 --- I checked it: The ICE is really introduced by rev. 124541. > r124541 | pault | 2007-05-08 13:58:25 +0200 (Tue, 08 May 2007) | 18 lines > PR 29397, PR 29400 > * decl.c (add_init_expr_to_sym): Expand a scalar initializer > for a parameter array into an array expression with the right > shape. > * array.c (spec_dimen_size): Remove static attribute. > * gfortran.h : Prototype for spec_dimen_size. >http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00406.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug fortran/32707] mismatched character lengths in array
--- Comment #1 from vivekrao4 at yahoo dot com 2007-07-09 19:05 --- Gfortran also does not warn about the simpler code program xtrim_array ! check if compiler catches character array constructor with elements of different sizes implicit none character (len=4) :: xx(2) xx = ["boy","girl"] print*,"xx = '" // xx(1) // "' '" // xx(2) // "'" end program xtrim_array -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32707
[Bug fortran/32707] New: mismatched character lengths in array
For the following invalid code
program xtrim_array
implicit none
character (len=4) :: xx(2)
xx = [trim("boy "),trim("girl")] ! invalid -- elements have different lengths
print*,"xx = '" // xx(1) // "' '" // xx(2) // "'"
end program xtrim_array
compiling and running with gfortran gives
gfortran -v -O0 -Wall -fbounds-check -static -g xtrim_array.f90
Driving: gfortran -v -O0 -Wall -fbounds-check -static -g xtrim_array.f90
-lgfortranbegin -lgfortran
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20070706 (experimental)
c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe
xtrim_array.f90 -quiet -dumpbase xtrim_array.f90 -mtune=i386 -auxbase
xtrim_array -g -O0 -Wall -version -fbounds-check -fintrinsic-modules-path
c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o
C:\DOCUME~1\vrao\LOCALS~1\Temp/ccaETULf.s
GNU F95 version 4.3.0 20070706 (experimental) (i386-pc-mingw32)
compiled by GNU C version 4.3.0 20070706 (experimental), GMP version
4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
as -o C:\DOCUME~1\vrao\LOCALS~1\Temp/ccg74eom.o
C:\DOCUME~1\vrao\LOCALS~1\Temp/ccaETULf.s
c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/collect2.exe
-Bstatic c:/programs/g95/lib/crt2.o
c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/crtbegin.o
-Lc:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0
-Lc:/programs/gfortran/bin/../lib/gcc -Lc:/programs/g95/lib
-Lc:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/../../..
C:\DOCUME~1\vrao\LOCALS~1\Temp/ccg74eom.o -lgfortranbegin -lgfortran -lmingw32
-lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32
-lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/crtend.o
U:\vrao\fortran>a
xx = 'boy ' 'girl'
It would be nice if gfortran gave a compile-time or run-time error.
Mingw G95 Jun 30 2007 with the default options says
In file xtrim_array.f90:4
xx = [trim("boy "),trim("girl")] ! invalid -- elements have different lengths
1
Error: Element in character array constructor at (1) has length 4 instead of 3
--
Summary: mismatched character lengths in array
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32707
[Bug libfortran/32702] [4.3 Regression] crash when printing big character variable
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Known to fail||4.3.0 Known to work||4.2.1 Summary|crash when printing big |[4.3 Regression] crash when |character variable |printing big character ||variable Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32702
[Bug fortran/32703] ICE with [trim(character_variable)]
-- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19276 nThis|| Keywords||ice-on-valid-code Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32703
[Bug fortran/32703] ICE with [trim(character_variable)]
--- Comment #1 from langton at gcc dot gnu dot org 2007-07-09 18:32 --- Confirmed. The segfault occurs on trans-array.c:1380 because e->ts->cl is null. -- langton 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-07-09 18:32:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32703
[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #14 from hp at gcc dot gnu dot org 2007-07-09 18:30 --- >From revision 126479 (in the range 126472..126429), the bug is again hidden. There's a libstdc++-v3/include/bits/stl_algo.h tweak in that range that apparently sufficiently changed the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code
--- Comment #15 from ubizjak at gmail dot com 2007-07-09 18:16 --- New timings on x86_64 core2 (from [1]) The tests were performed on core2 in 64bit mode, using '-DREPS=1 -O3 -msse3 -march=core2 -ffast-math' flags, with and without newly introduced -fno-tree-reassoc flag. The results were _interesting_, showing extreme differences in the run times: w/o -fno-tree-reassoc: ALGORITHM NB REPSTIME MFLOPS = = = == == -DTYPE=float: atlasmm 60 1 2.000 2159.87 -DTYPE=double:atlasmm 60 1 2.500 1727.89 w/ -fno-tree-reassoc: ALGORITHM NB REPSTIME MFLOPS = = = == == -DTYPE=float: atlasmm 60 1 0.932 4634.90 -DTYPE=double:atlasmm 60 1 1.520 2841.93 [1] http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00849.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug java/32706] New: gcj -M's dependency list is empty
GCJ -M is producing an empty dependency list vis:
package frysk4742;
class Referee
{
static int i;
int j;
Referee() {
j = i++;
}
}
package frysk4742;
class Referer {
static public void main(String[] args) {
new Referee();
}
}
gcj -M frysk4742/Referer.java
gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51):
imports/tests/frysk4742/Referer.java
../../../frysk/frysk-imports/tests/frysk4742/Referer.o: \
../../../frysk/frysk-imports/tests/frysk4742/Referer.java \
/usr/share/java/libgcj-4.1.1.jar \
../../../frysk/frysk-imports/tests/frysk4742/Referee.java
gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12):
/tmp/ccSF6vYl.o:
--
Summary: gcj -M's dependency list is empty
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cagney at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32706
[Bug tree-optimization/32705] [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-07-09 18:12 --- Subject: Re: New: [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022 Oh, this assert, sorry, i removed the other assert int his function. This means we have discovered some very very very strange value that an ssa name value numbers to. Can someone paste the output of debug_generic_stmt (to) and debug_tree(to) at the point of failure? On 9 Jul 2007 16:50:55 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > === acats Summary === > # of expected passes2269 > # of unexpected failures46 > > *** FAILURES: ae2113a ae2113b c38202a c85014b c87b26b c910001 c930001 c93008b > c94002b c94002d c94002e c94002f c94002g c94008c c95012a c95085a c954015 > c954019 > c954022 c954026 c954a03 c97113a c97201g c97201h c97201x c97202a c97205a > c97205b > c97305a c97305b c97305c c97305d c974002 c974003 c974008 c974009 c974010 > c974011 > cc1207b cc3019c cd92001 ce2103a ce2201l ce2202a ce3815a cxh1001 > > nearly all of them are of the form > > +===GNAT BUG DETECTED==+ > | 4.3.0 20070709 (experimental) (x86_64-unknown-linux-gnu) GCC error: | > | in set_ssa_val_to, at tree-ssa-sccvn.c:1022 | > | Error detected around ae2113b.adb:33 | > | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| > | Use a subject line meaningful to you and us to track the bug.| > | Include the entire contents of this bug box in the report. | > | Include the exact gcc or gnatmake command that you entered. | > | Also include sources listed below in gnatchop format | > | (concatenated together with no headers between files). | > +==+ > > > -- >Summary: [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa- > sccvn.c:1022 >Product: gcc >Version: 4.3.0 > Status: UNCONFIRMED > Keywords: ice-on-valid-code > Severity: normal > Priority: P3 > Component: tree-optimization > AssignedTo: unassigned at gcc dot gnu dot org > ReportedBy: rguenth at gcc dot gnu dot org > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug tree-optimization/32705] [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-07-09 18:11 --- Subject: Re: [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022 Uh, this assert was removed, so i don't know how it could still trigger ;) On 9 Jul 2007 17:36:22 -, ebotcazou at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-07-09 17:36 > --- > Confirmed on platforms where the Ada compiler bootstraps at all. :-) > > I plan to look at them once I've found something plausible for PR 32589. > > > -- > > ebotcazou at gcc dot gnu dot org changed: > >What|Removed |Added > > CC||ebotcazou at gcc dot gnu dot >||org > Status|UNCONFIRMED |NEW > Ever Confirmed|0 |1 >Last reconfirmed|-00-00 00:00:00 |2007-07-09 17:36:22 >date|| > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug fortran/32704] -static-libgfortran is undocumented
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 18:10 --- I asked for it, seems to be me who is going to document it :) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-09 18:10:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32704
[Bug c++/32560] [4.3 regression] ICE on invalid declaration in template
--- Comment #1 from pcarlini at suse dot de 2007-07-09 17:52 --- I can fix this... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-09 17:52:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32560
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2007-07-09 17:48 --- Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86 aph at gcc dot gnu dot org writes: > So, the question is why the linker is complaining that "a GOT relative > relocation must reference a local symbol" since it is defined locally and it > should be possible to calculate its offset from the GOT. I've looked up the message in the OpenSolaris ld sources: they are from http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sgs/libld/common/relocate.c (ld_process_sym_reloc), l. 1187 - 1198 (the message is MSG_REL_BADGOTBASED). On l. 1116.. there's a description of which symbols are considered local. I must confess that I don't fully understand what is going on there ;-) Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #8 from zippel at gcc dot gnu dot org 2007-07-09 17:42 --- (In reply to comment #7) > On the backend side we have the fwprop pass which is supposed to do > addressing mode selection and the backend which is supposed to provide > accurate costs for them. Let's take your proposed form: return (*(p + (i + 2) * 4) + *(p + (i + 1) * 4)) + *(p + (i + 3) * 4); After initial RTL expansion something like this is generated: t1 = i + 2; r = *(p + t1 * 4); t2 = i + 1; r += *(p + t2 * 4); t3 = i + 3; r += *(p + t3 * 4); The problem is now that it takes until combine until this is generated: r = *(p + i * 4 + 8); r += *(p + i * 4 + 4); r += *(p + i * 4 + 12); and at this point it's too late. It's easy to blame the back end, but at this point it's IMHO unrealistic to undo this mess at RTL level. The proper address form should be generated as early as possible, so that at the time RTL is generated, it's as close as possible to the final form. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug tree-optimization/32705] [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-07-09 17:36 --- Confirmed on platforms where the Ada compiler bootstraps at all. :-) I plan to look at them once I've found something plausible for PR 32589. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-09 17:36:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug c++/32106] [4.3 regression] ICE after name-clash between struct and namespace
--- Comment #1 from pcarlini at suse dot de 2007-07-09 17:07 --- Cannot be reproduced anymore. If people want me to add the testcase to be safe, just let me know. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32106
[Bug tree-optimization/32705] New: [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
=== acats Summary === # of expected passes2269 # of unexpected failures46 *** FAILURES: ae2113a ae2113b c38202a c85014b c87b26b c910001 c930001 c93008b c94002b c94002d c94002e c94002f c94002g c94008c c95012a c95085a c954015 c954019 c954022 c954026 c954a03 c97113a c97201g c97201h c97201x c97202a c97205a c97205b c97305a c97305b c97305c c97305d c974002 c974003 c974008 c974009 c974010 c974011 cc1207b cc3019c cd92001 ce2103a ce2201l ce2202a ce3815a cxh1001 nearly all of them are of the form +===GNAT BUG DETECTED==+ | 4.3.0 20070709 (experimental) (x86_64-unknown-linux-gnu) GCC error: | | in set_ssa_val_to, at tree-ssa-sccvn.c:1022 | | Error detected around ae2113b.adb:33 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ -- Summary: [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa- sccvn.c:1022 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #15 from bonzini at gnu dot org 2007-07-09 16:31 --- Note that this: > Before the dataflow merge, the argument pointer was always included > in "Registers live at start". ... was because uninitialized registers always showed up as live at start before DF merge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug fortran/32704] New: -static-libgfortran is undocumented
PR 31400 added -static-libgfortran, but a documentation is missing. (One should probably also update http://gcc.gnu.org/wiki/GFortranGettingStarted) -- Summary: -static-libgfortran is undocumented Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32704
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #32 from bonzini at gnu dot org 2007-07-09 15:38 --- additional fix committed. -- bonzini at gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #31 from bonzini at gnu dot org 2007-07-09 15:38 --- Subject: Bug 32004 Author: bonzini Date: Mon Jul 9 15:37:56 2007 New Revision: 126488 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126488 Log: 2007-07-09 Paolo Bonzini <[EMAIL PROTECTED]> PR middle-end/32004 * function.c (rest_of_match_asm_constraints): Pass PROP_REG_INFO. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/function.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #30 from bonzini at gnu dot org 2007-07-09 15:37 --- Subject: Bug 32004 Author: bonzini Date: Mon Jul 9 15:37:32 2007 New Revision: 126487 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126487 Log: 2007-07-09 Paolo Bonzini <[EMAIL PROTECTED]> PR middle-end/32004 * function.c (rest_of_match_asm_constraints): Pass PROP_REG_INFO. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/function.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #7 from rguenther at suse dot de 2007-07-09 15:37 --- Subject: Re: [4.3 regression] inefficient pointer expression On Mon, 9 Jul 2007, zippel at gcc dot gnu dot org wrote: > (In reply to comment #5) > > as you suggest creates worse assembly (look at the extra shift) > > > > foo: > > pushl %ebp > > movl%esp, %ebp > > movl12(%ebp), %ecx > > movl8(%ebp), %edx > > popl%ebp > > sall$2, %ecx > > movl8(%ecx,%edx), %eax > > addl4(%ecx,%edx), %eax > > addl12(%ecx,%edx), %eax > > ret > > The cost of this is dependent on the target, so IMO the shift could be > propagated back into the address at RTL level. Or the other way around. > > so there is no form that is clearly better to canonicalize to. > > Your example is rather artificial and depends on that (i + x) * y is > completely > eliminated. My main point is still that such expression are far more difficult > to translate into proper address operations. > To generate addresses targeting a form of (i * x) + y is clearly better. My example is not artificial. It is quite common to have loops that stream data from one type to another. Also it's not 'clearly' better to me. Anyway, fold () is certainly not able to decide this and both value numbering and re-association can improve the IL by taking into account context. On the backend side we have the fwprop pass which is supposed to do addressing mode selection and the backend which is supposed to provide accurate costs for them. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug fortran/32703] New: ICE with [trim(character_variable)]
For the program program array_char implicit none character (len=1) :: x x = "a" print*,[trim(x)] end program array_char compiling on Windows XP with gfortran -v xconcat.f90 produces an ICE: Driving: gfortran -v xconcat.f90 -lgfortranbegin -lgfortran Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20070706 (experimental) c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe xconcat.f90 -quiet -dumpbase xconcat.f90 -mtune=i386 -auxbase xconcat -version -fintrinsic-modules-path c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o C:\DOCUME~1\vrao\LOCALS~1\Temp/cc8grzTr.s GNU F95 version 4.3.0 20070706 (experimental) (i386-pc-mingw32) compiled by GNU C version 4.3.0 20070706 (experimental), GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 xconcat.f90: In function 'MAIN__': xconcat.f90:4: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. The program works if the line print*,[trim(x)] is replaced with print*,[x] or print*,trim(x) -- Summary: ICE with [trim(character_variable)] Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32703
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #6 from zippel at gcc dot gnu dot org 2007-07-09 15:27 --- (In reply to comment #5) > as you suggest creates worse assembly (look at the extra shift) > > foo: > pushl %ebp > movl%esp, %ebp > movl12(%ebp), %ecx > movl8(%ebp), %edx > popl%ebp > sall$2, %ecx > movl8(%ecx,%edx), %eax > addl4(%ecx,%edx), %eax > addl12(%ecx,%edx), %eax > ret The cost of this is dependent on the target, so IMO the shift could be propagated back into the address at RTL level. > so there is no form that is clearly better to canonicalize to. Your example is rather artificial and depends on that (i + x) * y is completely eliminated. My main point is still that such expression are far more difficult to translate into proper address operations. To generate addresses targeting a form of (i * x) + y is clearly better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug libfortran/32702] crash when printing big character variable
-- dfranke 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-07-09 15:10:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32702
[Bug libfortran/32702] crash when printing big character variable
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 15:08 --- Confirmed. Presumely a buffer overflow in the library. If len==8192, valgrind does not report any errors. If len > 8192: ===30988== Invalid write of size 1 ==30988==at 0x4022D8E: memcpy (mc_replace_strmem.c:406) ==30988==by 0x40A26C3: write_character (write.c:1412) ==30988==by 0x40A462B: _gfortrani_list_formatted_write (write.c:1533) ==30988==by 0x409A885: _gfortran_transfer_character (transfer.c:1416) ==30988==by 0x80486FB: MAIN__ (pr32702.f90:4) ==30988==by 0x8048748: main (fmain.c:22) ==30988== Address 0x4229340 is 0 bytes after a block of size 8,296 alloc'd ==30988==at 0x40213D0: malloc (vg_replace_malloc.c:149) ==30988==by 0x40342CC: _gfortrani_get_mem (memory.c:53) ==30988==by 0x40A0BE4: fd_to_stream (unix.c:1048) ==30988==by 0x409F509: _gfortrani_init_units (unit.c:525) ==30988==by 0x4033F73: init (main.c:152) ==30988==by 0x40307DC: (within /h/franke/packages/i686-pc-linux-gnu/gcc/lib/gcc/i686-pc-linux-gnu/4.3.0/libgfortran.so.3.0.0) ==30988==by 0x400D762: call_init (in /lib/ld-2.4.so) ==30988==by 0x400D872: _dl_init (in /lib/ld-2.4.so) ==30988==by 0x400087E: (within /lib/ld-2.4.so) Moving to libfortran, adding Jerry to CC. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org, jvdelisle at gcc dot ||gnu dot org Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32702
[Bug fortran/31129] No warning on unused parameters
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-09 15:00 --- Closing again. This time, I mean it. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31129
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-09 15:00 ---
Note that we don't hoist the i*4 or the addition to p to help addressing mode
selection which likes to see the "whole" address.
Of course it shouldn't matter in which form we see the addresses and the same
code should be generated for all, still canonicalization to the same form
makes a difference.
In fact, canonicalizing to
unsigned int D.1656;
:
D.1656 = i * 4;
return (*(p + (D.1656 + 8)) + *(p + (D.1656 + 4))) + *(p + (D.1656 + 12));
as you suggest creates worse assembly (look at the extra shift)
foo:
pushl %ebp
movl%esp, %ebp
movl12(%ebp), %ecx
movl8(%ebp), %edx
popl%ebp
sall$2, %ecx
movl8(%ecx,%edx), %eax
addl4(%ecx,%edx), %eax
addl12(%ecx,%edx), %eax
ret
in fact the above shows that the proper fix would be in the backend (if
there is anything to fix) and making sure we consistently canonicalize
is good enough. Consider the related testcase
int foo(int *p, short *q, char *r, unsigned int i)
{
return p[i + 1] + q[i + 1] + r[i + 1];
}
which in one case is canonicalized to
unsigned int D.1658;
:
D.1658 = i + 1;
return ((int) *(r + D.1658) + *(p + D.1658 * 4)) + (int) *(q + D.1658 * 2);
in the other to
return ((int) *(r + (i + 1)) + *(p + (i * 4 + 4))) + (int) *(q + (i * 2 +
2));
so there is no form that is clearly better to canonicalize to. But the
correct "form" depends on the context (whether it is profitable to either
CSE i * 4 or i + 1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug fortran/31129] No warning on unused parameters
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-09 14:58 --- Fixed in trunk. Not a regression, no backport. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31129
[Bug fortran/31129] No warning on unused parameters
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-09 14:57 --- Subject: Bug 31129 Author: dfranke Date: Mon Jul 9 14:56:49 2007 New Revision: 126486 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126486 Log: gcc/fortran: 2007-07-09 Daniel Franke <[EMAIL PROTECTED]> PR fortran/31129 * trans-decl.c (generate_local_decl) Emit a warning if an unused parameter is found. gcc/testsuite: 2007-07-09 Daniel Franke <[EMAIL PROTECTED]> PR fortran/31129 * gfortran.dg/parameter_unused.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parameter_unused.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=31129
[Bug fortran/32702] New: crash when printing big character variable
For the code program main character (len=1) :: word word = "dog" print*,"word =",word end program main compiled with U:\vrao\fortran>gfortran -v xbug.f90 Driving: gfortran -v xbug.f90 -lgfortranbegin -lgfortran Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20070706 (experimental) c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe xbug.f90 -quiet -dumpbase xbug.f90 -mtune=i386 -auxbase xbug -version -fintrinsic-modules-path c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o C:\DOCUME~1\vrao\LOCALS~1\Temp/ccfHwMra.s GNU F95 version 4.3.0 20070706 (experimental) (i386-pc-mingw32) compiled by GNU C version 4.3.0 20070706 (experimental), GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 as -o C:\DOCUME~1\vrao\LOCALS~1\Temp/cc1pIAXq.o C:\DOCUME~1\vrao\LOCALS~1\Temp/ccfHwMra.s c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/collect2.exe -Bdynamic c:/programs/g95/lib/crt2.o c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/crtbegin.o -Lc:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0 -Lc:/programs/gfortran/bin/../lib/gcc -Lc:/programs/g95/lib -Lc:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/../../.. C:\DOCUME~1\vrao\LOCALS~1\Temp/cc1pIAXq.o -lgfortranbegin -lgfortran -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/crtend.o the program on Windows XP prints "word =dog" but then crashes with a pop-up message "a.exe has encountered a problem and needs to close". The program runs fine with the LEN is reduced to 8000. -- Summary: crash when printing big character variable Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32702
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #4 from zippel at gcc dot gnu dot org 2007-07-09 14:40 --- IMHO something like this should be generated: p2 = p + (i * 4); return (*(p2 + 4) + *(p2 + 8) + *(p2 + 12)); Right now not even the (i*4) expression is removed from the last instruction anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug fortran/32699] Global name 'len' at (1) is already being used as a FUNCTION at (2)
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 14:25 --- *** This bug has been marked as a duplicate of 32157 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32699
[Bug fortran/32157] intrinsic function name conflicts with subroutine if present in the same file
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-09 14:25 --- *** Bug 32699 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32157
[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)
--- Comment #15 from sebpop at gmail dot com 2007-07-09 14:19 --- Subject: Re: can't determine dependence (source/destination overlap without more than size) > I was going to submit the attached patch, but now the analysis fails with > "affine-affine test failed: missing iteration counts" and distance vector is > not built (so the loop in this PR cannot be vectorized even with the addition > of DDR_REVERSED_P). This was caused by your patch to PR 32457 > http://gcc.gnu.org/viewcvs?view=rev&revision=126305. Is there any way to > restore the previous behaviour for this case? > I'll try to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug c++/32697] O2 optimizes away assignment
--- Comment #3 from Dries dot Decock at excentis dot com 2007-07-09 14:07 --- Thanks for the reply. I will use the -fno-strict-aliasing for now, and hope that the SWIG maintainers will fix this problem in the near future. Thanks again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32697
[Bug c++/32700] O2 optimizes away assignment
--- Comment #1 from Dries dot Decock at excentis dot com 2007-07-09 14:06 --- Sorry, dup -- Dries dot Decock at excentis dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32700
[Bug c++/32700] New: O2 optimizes away assignment
Hi,
I'm using SWIG to combine Java and C++ code. At some point, SWIG generates a
method like this :
1SWIGEXPORT jlong JNICALL Java_com_excentis_products_X_XUpcast(JNIEnv *jenv,
jclass jcls, jlong jarg1) {
jlong baseptr = 0;
(void)jenv;
(void)jcls;
*(Flow **)&baseptr = *(TcpFlow **)&jarg1;
return baseptr;
}
The problem is that the assignment is not executed and the return value is
always zero, when using -O2 optimization. When I disable O2, or add a debug
statement, the value is ok.
I don't like the generated code, but it should work fine.
--
Summary: O2 optimizes away assignment
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Dries dot Decock at excentis dot com
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32700
[Bug c++/32697] O2 optimizes away assignment
--- Comment #2 from sorenj at us dot ibm dot com 2007-07-09 13:55 --- Please refer to https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1560993&group_id=1645 Long story short - as it stands today: C++ standards team won't change the spec to allow type punning, gcc team won't "fix" code generation if it involves type punning, swig team won't rewrite the code generators to generate ANSI spec compliant code. (The only way to do this by current ANSI spec rules is to memcpy the contents of the pointers themselves from a pointer of one type to a pointer of another type.) Your only solution at this time is to use -fno-strict-aliasing when compiling swig wrapper code. This has been a major headache mainly for package maintainers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32697
[Bug fortran/32699] New: Global name 'len' at (1) is already being used as a FUNCTION at (2)
When I compile the program listed below I get the message:
al1.f90:4.17:
SUBROUTINE len(i)
1
al1.f90:2.4:
i = len(" ")
2
Error: Global name 'len' at (1) is already being used as a FUNCTION at (2)
For what it's worth:
1. g95, Compaq, and Lahey Fortran do not consider it an error.
2. Declaring len to be INTRINSIC has no effect.
PROGRAM VAL
i = len(" ")
END
SUBROUTINE len(i)
END
--
Summary: Global name 'len' at (1) is already being used as a
FUNCTION at (2)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32699
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-09 13:42 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-09 13:39:51 |2007-07-09 13:42:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-09 13:41 --- Created an attachment (id=13875) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13875&action=view) patch With the proposed patch mainline generates again foo: pushl %ebp movl%esp, %ebp movl8(%ebp), %ecx movl12(%ebp), %edx popl%ebp movl8(%ecx,%edx,4), %eax addl4(%ecx,%edx,4), %eax addl12(%ecx,%edx,4), %eax ret and return (*(p + (i + 2) * 4) + *(p + (i + 1) * 4)) + *(p + (i + 3) * 4); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-09 13:39 --- With 2.95, 3.3.6 and 3.4.6 I get (for 32bit): foo: pushl %ebp movl %esp,%ebp movl 8(%ebp),%edx movl 12(%ebp),%eax movl %ebp,%esp popl %ebp movl 8(%edx,%eax,4),%ecx addl 4(%edx,%eax,4),%ecx addl 12(%edx,%eax,4),%ecx movl %ecx,%eax ret 4.0.3 and 4.1.2 generate: foo: pushl %ebp movl%esp, %ebp movl12(%ebp), %edx sall$2, %edx addl8(%ebp), %edx movl8(%edx), %eax addl4(%edx), %eax addl12(%edx), %eax leave ret 4.2.0 generates foo: pushl %ebp movl%esp, %ebp movl12(%ebp), %ecx movl8(%ebp), %edx popl%ebp sall$2, %ecx movl4(%ecx,%edx), %eax addl8(%ecx,%edx), %eax addl12(%ecx,%edx), %eax ret while mainline generates foo: pushl %ebp movl%esp, %ebp movl12(%ebp), %ecx movl8(%ebp), %edx pushl %ebx leal0(,%ecx,4), %ebx movl8(%ebx,%edx), %eax addl4(%edx,%ecx,4), %eax addl12(%ebx,%edx), %eax popl%ebx popl%ebp ret 64bit variants of all of the above create foo: .LFB2: leal1(%rsi), %edx leal2(%rsi), %eax addl$3, %esi movl(%rdi,%rax,4), %eax addl(%rdi,%rdx,4), %eax addl(%rdi,%rsi,4), %eax ret Tree dumps (of mainline) 64bit vs. 32bit are: return (*(p + (long unsigned int) (i + 2) * 4) + *(p + (long unsigned int) (i + 1) * 4)) + *(p + (long unsigned int) (i + 3) * 4); unsigned int D.1660; D.1660 = i * 4; return (*(p + (D.1660 + 8)) + *(p + (i + 1) * 4)) + *(p + (D.1660 + 12)); -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | GCC target triplet||i686-*-* Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-07-09 13:39:51 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug tree-optimization/32681] ice for legal C code with flags -ffast-math -O3 -ftree-vectorize
--- Comment #9 from ubizjak at gmail dot com 2007-07-09 13:36 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32681
[Bug c/21920] aliasing violations
--- Comment #117 from schwab at suse dot de 2007-07-09 13:35 --- *** Bug 32697 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added CC||Dries dot Decock at excentis ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c++/32697] O2 optimizes away assignment
--- Comment #1 from schwab at suse dot de 2007-07-09 13:35 --- Report this to the SWIG maintainers. This is violating the C/C++ aliasing rules. *** This bug has been marked as a duplicate of 21920 *** -- schwab at suse dot de changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32697
[Bug tree-optimization/32681] ice for legal C code with flags -ffast-math -O3 -ftree-vectorize
--- Comment #8 from uros at gcc dot gnu dot org 2007-07-09 13:32 --- Subject: Bug 32681 Author: uros Date: Mon Jul 9 13:31:46 2007 New Revision: 126484 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126484 Log: PR tree-optimization/32681 * tree-if-conv.c (find_phi_replacement_condition): Use the condition saved in second_edge->aux when first_bb is a loop header. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32681
[Bug tree-optimization/32698] New: [4.3 regression] inefficient pointer expression
Taking this example:
int foo(int *p, unsigned int i)
{
return p[i + 1] + p[i + 2] + p[i + 3];
}
produces inefficient code. The problem already starts at tree level, where for
"p[i+1]" an expression like *(p + (i + 1) * 4)) is generated, which is not a
common pointer expression.
Also since this is different from the other generated pointer expression, the
common index expression isn't completely replaced.
An initial discussion about this can be found here:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00418.html
--
Summary: [4.3 regression] inefficient pointer expression
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zippel at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug c++/32697] New: O2 optimizes away assignment
Hi,
I'm using SWIG to combine Java and C++ code. At some point, SWIG generates a
method like this :
1SWIGEXPORT jlong JNICALL Java_com_excentis_products_X_XUpcast(JNIEnv *jenv,
jclass jcls, jlong jarg1) {
jlong baseptr = 0;
(void)jenv;
(void)jcls;
*(Flow **)&baseptr = *(TcpFlow **)&jarg1;
return baseptr;
}
The problem is that the assignment is not executed and the return value is
always zero, when using -O2 optimization. When I disable O2, or add a debug
statement, the value is ok.
I don't like the generated code, but it should work fine.
--
Summary: O2 optimizes away assignment
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Dries dot Decock at excentis dot com
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32697
[Bug c/32692] Inconsistent warning/error with static and non-static declarations
--- Comment #3 from sirl at gcc dot gnu dot org 2007-07-09 13:15 --- Sorry, apparently I forgot to search 'All' bugs instead of just the 'Open' ones yesterday. One question though, how does the func6() part of the testcase relate to all this? For this one there is no 'extern' specifier anywhere, so shouldn't sub-clause 7 of 6.2.2 apply here and thus a warning is justified? 7 If, within a translation unit, the same identifier appears with both internal and external linkage, the behavior is undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32692
[Bug tree-optimization/32681] ice for legal C code with flags -ffast-math -O3 -ftree-vectorize
--- Comment #7 from uros at gcc dot gnu dot org 2007-07-09 13:11 --- Subject: Bug 32681 Author: uros Date: Mon Jul 9 13:11:22 2007 New Revision: 126483 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126483 Log: PR tree-optimization/32681 * tree-if-conv.c (find_phi_replacement_condition): Use the condition saved in second_edge->aux when first_bb is a loop header. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32681
[Bug tree-optimization/32681] ice for legal C code with flags -ffast-math -O3 -ftree-vectorize
--- Comment #6 from uros at gcc dot gnu dot org 2007-07-09 13:00 --- Subject: Bug 32681 Author: uros Date: Mon Jul 9 13:00:19 2007 New Revision: 126482 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126482 Log: PR tree-optimization/32681 * tree-if-conv.c (find_phi_replacement_condition): Use the condition saved in second_edge->aux when first_bb is a loop header. testsuite/ChangeLog: PR tree-optimization/32681 * gcc.dg/tree-ssa/pr32681.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr32681.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32681
[Bug fortran/31447] set intent(out) arguments to uninitialized
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 12:56 --- Related: PR28004 - "Warn if intent(out) dummy variable is used before being defined" -- 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=31447
