[Bug fortran/31299] getlog returns blanks when not run from the command prompt
--- Comment #8 from burnus at gcc dot gnu dot org 2007-03-22 07:42 --- Close as Won't Fix -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug fortran/30876] Array valued recursive function rejected
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-22 07:41 --- (In reply to comment #5) > Then, the following should be invalid and rejected, shouldn't it? > recursive function f(i) > integer :: f, i > f = 0 > if (i > 0) f = f(i-1) + 1 > end function NAG f95: line 4: Recursive invocation of F which has no RESULT clause (gfortran and ifort allow this) > recursive function f(i) result(g) > integer :: g, i > g = 0 > if (i > 0) g = g(i-1) + 1 > end function NAG f95: Inconsistent usage of G ifort: This name has not been declared as an array or a function gfortran: Cannot assign to a named constant -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30876
[Bug fortran/29941] [4.1 only] gfortran reports error with len of assumed size character array
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-22 06:39 --- *** Bug 31308 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||van dot snyder at jpl dot ||nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29941
[Bug fortran/31308] character(len=len(a)) :: B fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-22 06:39 --- *** This bug has been marked as a duplicate of 29941 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31308
[Bug fortran/29941] [4.1 only] gfortran reports error with len of assumed size character array
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29941
Bug in g++ 4.1.2 when using inline function definied in cpp file but declared in h file
hi
i found bug in g++ 4.1.2 - version included with new kubuntu fiesty.
to reproduce this bug i've created 3 simple files a.h, a.cpp and main.cpp
//a.h
#ifndef A_H
#define A_H
class A{
public:
void b(int c);
private:
int d;
};
#endif
//a.cpp
#include "a.h"
inline void A::b(int c)
{
d = c;
}
//main.cpp
#include "a.h"
int main()
{
A *a = new A;
a->b(1);
return 0;
}
then when i'm compiling them :
g++ -c -o a.o a.cpp - everything is ok
g++ -o A a.o main.o - i get:
main.o: In function `main':
main.cpp:(.text+0x2f): undefined reference to `A::b(int)'
collect2: ld returned 1 exit status
when i add those 2 lines to a.cpp:
#pragma implementation
#pragma interface
so it looks like this:
//a.cpp
#include "a.h"
#pragma implementation
#pragma interface
inline void A::b(int c)
{
d = c;
}
everything is ok. i tried every possible combination of those pragmas and
inline kayword, but only this one seams to work.
bartosz wadolowski
[Bug fortran/31299] getlog returns blanks when not run from the command prompt
--- Comment #7 from ebb9 at byu dot net 2007-03-22 04:46 --- According to POSIX, "The getlogin() function shall return a pointer to a string containing the user name associated by the login activity with the controlling terminal of the current process." The behavior of nohup was intentionally changed in 5.90, as permitted by POSIX: "If stdin is a terminal, nohup now redirects it from /dev/null to prevent the command from tying up an OpenSSH session after you logout." The difference in behavior, then, is explainable by the fact that the child app no longer has a controlling terminal, therefore there is no login user to be found. In my mind, this is considered a feature of coreutils' nohup and not a bug. And since POSIX permits either behavior (preserving stdin and keeping a controlling terminal, vs. redirecting stdin and thereby disassociating from a terminal), it means that getlogin() is not portable in a nohup environment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug c++/31309] g++ 4.2.0 amd64 codegen issue with -O0. 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
--- Comment #1 from peeterj at ca dot ibm dot com 2007-03-22 04:28 --- Created an attachment (id=13251) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13251&action=view) source code that demonstrates the code generation issue described. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug c++/31309] New: g++ 4.2.0 amd64 codegen issue with -O0. 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
Description:
Code includes two structures, a 6 byte struct of the following form:
struct 6bytes { char [2] ; char [4] }
and another that embeds this at the very end in the following form:
struct { bool ; bool ; 6bytes } ;f
compiler is generating code for assignment to the trailing 6byte struct using
an 8 byte read from that address, then merging in the value to be assigned, and
finally writing back 8 bytes.
If this structure is allocated from memory where this 8 byte sequence is not
accessable (ie: at the end of a shmat memory region for example), this results
in a trap. When the memory is accessable the compiler generated code does
happen to retain the value that follows the structure being accessed, but even
if the 2 bytes of memory trailing the structure is accessable, this generated
code that modified memory outside of the structure is not thread safe.
This has been observed with GCC 4.2 prerelease compilers, but not GCC 3.3.3. I
don't know if the issue applies to 4.1 or 4.0 compilers too.
host/target/build triplets provided above. Other info:
>Release: gcc (GCC) 4.2.0 20070317 (prerelease)
>Environment:
System: Linux hotel09 2.6.5-7.191-smp #1 SMP Tue Jun 28 14:58:56 UTC 2005
x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64
configured with: ../gcc-4.2.0-20070316/configure
--prefix=/vbs/bldsupp.linux1/linuxamd64/gcc-4.2.0-20070316
--enable-threads=posix --enable-languages=c,c++ --enable-shared
--enable-__cxa_atexit
>How-To-Repeat:
Sample code will be attached. This forces the memory following the structure
to be unreadable by calling mprotect.
Build command of the form:
/view/peeterj_gcc-4.2.0-20070316-decfloat/vbs/bldsupp/linuxamd64/gcc-4.2.0/bin/g++
-O0 x.C
-Wl,-rpath,/view/peeterj_gcc-4.2.0-20070316-decfloat/vbs/bldsupp/linuxamd64/gcc-4.2.0/lib64
-o ./xx
(-rpath gunk is because I don't have the runtime locally installed)
The following gdb session demonstrates the issue (but will make more sense when
looking at the code).
hotel09:/vbs/engn/squ> gdb x
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...Using host libthread_db
library "/lib64/tls/libthread_db.so.1".
(gdb) run
Starting program: /vbs/engn/squ/x
[Thread debugging using libthread_db enabled]
[New Thread 183048206464 (LWP 18902)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 183048206464 (LWP 18902)]
0x00400edf in XXX::Initialize (this=0x7fbfff8ff8, iIndex=0) at x.C:51
51 pDictRidderInfo->dRID = INIT_6_BYTES_ZERO();
(gdb) disassemble $rip $rip+30
Dump of assembler code from 0x400edf to 0x400efd:
0x00400edf <_ZN3XXX10InitializeEi+71>: mov0xa(%rbx),%rcx
0x00400ee3 <_ZN3XXX10InitializeEi+75>: mov
%rcx,0xffd0(%rbp)
0x00400ee7 <_ZN3XXX10InitializeEi+79>: movzbq %dl,%rcx
0x00400eeb <_ZN3XXX10InitializeEi+83>: mov
0xffd0(%rbp),%rdx
0x00400eef <_ZN3XXX10InitializeEi+87>: mov$0x0,%dl
0x00400ef1 <_ZN3XXX10InitializeEi+89>: or %rcx,%rdx
0x00400ef4 <_ZN3XXX10InitializeEi+92>: mov
%rdx,0xffd0(%rbp)
0x00400ef8 <_ZN3XXX10InitializeEi+96>: mov
0xffd0(%rbp),%rdx
0x00400efc <_ZN3XXX10InitializeEi+100>: mov%rdx,0xa(%rbx)
End of assembler dump.
(gdb) p $rbx
$1 = 548682059760
(gdb) p (void*)$rbx+0xa+6
$2 = (void *) 0x7fbfffd000
>Fix:
Enabling optimization -O2 works around the issue, but the builds that we want
to do with gcc-4.2 are development (-g) builds so -O isn't a natural fit.
--
Summary: g++ 4.2.0 amd64 codegen issue with -O0. 6 byte
assignment at end of structure reads/writes past end of
structure causing SEGV when that memory is not
accessable.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peeterj at ca dot ibm dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug fortran/31308] New: character(len=len(a)) :: B fails
subroutine X (A ) character(len=*), intent(inout) :: A(*) character(len=len(a)) :: B end subroutine X fails: In file test.f90:3 character(len=len(a)) :: B 1 Error: The upper bound in the last dimension must appear in the reference to the assumed size array 'a' at (1). "len" has nothing to do with bounds; it refers to the length of each element if its argument is an array. -- Summary: character(len=len(a)) :: B fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: van dot snyder at jpl dot nasa dot gov GCC build triplet: 4.1.0 GCC host triplet: 4.1.0 GCC target triplet: 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31308
[Bug middle-end/31307] Interaction between x86_64 builtin function and inline functions causes poor code
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-22 01:38 --- Inline version: r.dst[0].i = MEM[base: d]; D.6423 = r.dst[0].i; D.6449 = __builtin_ia32_paddusb128 (VIEW_CONVERT_EXPR<__v16qi>(D.6423), VIEW_CONVERT_EXPR<__v16qi>(D.6423)); r.dst[0].i = VIEW_CONVERT_EXPR<__m128i>(D.6449); __builtin_ia32_movntdq ((__m128i *) d, r.dst[0].i); d = d + 16B; macro: D.6414 = MEM[base: d]; D.6435 = __builtin_ia32_paddusb128 (VIEW_CONVERT_EXPR<__v16qi>(D.6414), VIEW_CONVERT_EXPR<__v16qi>(D.6414)); __builtin_ia32_movntdq ((__m128i *) d, VIEW_CONVERT_EXPR<__m128i>(D.6435)); d = d + 16B; So somehow r.dst[0].i is not being optimized correctly, I did not look into why really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|x86_64-redhat-linux | GCC host triplet|x86_64-redhat-linux | Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31307
[Bug c++/31307] Interaction between x86_64 builtin function and inline functions causes poor code
--- Comment #3 from michael dot meissner at amd dot com 2007-03-22 00:40 --- Created an attachment (id=13250) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13250&action=view) This is the good source compiled with -DUSE_MACRO -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31307
[Bug c++/31307] Interaction between x86_64 builtin function and inline functions causes poor code
--- Comment #2 from michael dot meissner at amd dot com 2007-03-22 00:39 --- Created an attachment (id=13249) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13249&action=view) This is the assembly language with the extra store in it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31307
[Bug c++/31307] Interaction between x86_64 builtin function and inline functions causes poor code
--- Comment #1 from michael dot meissner at amd dot com 2007-03-22 00:38 --- Created an attachment (id=13248) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13248&action=view) C++ source that shows the bug This is the source that shows the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31307
[Bug c++/31307] New: Interaction between x86_64 builtin function and inline functions causes poor code
If you compile the attached code with optimization on a 4.1.x system it will generate a store into a stack temporary in the middle of the loop that is never used. If you compile the code with -DUSE_MACRO where it uses macros instead of inline functions, it will generate the correct code without the extra store. It is still a bug in the 4.3 mainline with a compiler built on March 30th. -- Summary: Interaction between x86_64 builtin function and inline functions causes poor code Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot meissner at amd dot com GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31307
[Bug fortran/30876] Array valued recursive function rejected
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-22 00:22 --- (In reply to comment #3) > "12.5.2.1 Function subprogram" > "If RESULT is not specified, the result variable is and all > occurrences of the function name in execution-part statements are references > to > the result variable." Then, the following should be invalid and rejected, shouldn't it? recursive function f(i) integer :: f, i f = 0 if (i > 0) f = f(i-1) + 1 end function If every occurence of f is a reference to the variable result, it's strictly equivalent to the following, clearly invalid code: recursive function f(i) result(g) integer :: g, i g = 0 if (i > 0) g = g(i-1) + 1 end function -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30876
[Bug fortran/31203] [4.1/4.2 only] Character length should never be negative
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-03-22 00:13 --- Not a regression, so won't backport to 4.2. Closing as fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.2.1 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31203
[Bug fortran/31120] [4.1/4.2 only] ICE with integer_exponentiation_1.f90 and -ffast-math
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-03-22 00:10 --- I tried to see if it was a regression against g77, but it is not. Will not backport to 4.2, and closing. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31120
[Bug fortran/31306] New: ICE with implicit character variables
No time to reduce this one, filing it so it doesn't get lost:
module cyclic
implicit none
contains
function ouch(x,y)
implicit character(len(ouch)) (x)
implicit character(len(x)+1) (y)
implicit character(len(y)-1) (o)
intent(in) x,y
character(len(y)-1) ouch
integer i
do i = 1, len(ouch)
ouch(i:i) = achar(ieor(iachar(x(i:i)),iachar(y(i:i
end do
end function ouch
end module cyclic
program test
use cyclic
implicit none
write(*,*) ouch('YOW!',' ')
end program test
--
Summary: ICE with implicit character variables
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
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=31306
[Bug fortran/31304] REPEAT argument NCOPIES is not converted as it should
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-21 23:55:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31304
[Bug fortran/31304] New: REPEAT argument NCOPIES is not converted as it should
The NCOPIES argument of REPEAT is not converted to the integer king the library expects (kind=4), which can lead to segfaults. I changed that code recently, so I'll fix it. I'll probably take this opportunity to have the front-end actually emit an error if the NCOPIES argument is larger than a fixed value. $ cat repeat.f90 implicit none integer(kind=1) i real(kind=8) r character(len=2) s1, s2 i = 1 r = 1 s1 = '42' r = nearest(r,r) s2 = repeat(s1,i) end $ gfortran repeat.f90 && ./a.out Segmentation fault -- Summary: REPEAT argument NCOPIES is not converted as it should Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: fxcoudert at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31304
[Bug fortran/30940] Fortran 2003: Scalar CHARACTER supplied to array dummy
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-21 22:31 --- Richard Main wrote in http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5e91eb94c1ea71ec/ See Notes 15.29 and 15.23 for a (bried) explanation and example of exactly this. I knoew this was an mportant issue; that's why I wrote (the first draft of) Note 15.23. See also pg 170, lines 25:26. The mention of the C character kind there is specifically to guarantee that this will work even if the C character kind doesn't happen to be the default kind. That was a special rule for default character, but it was extended to also apply to the C character kind. In essence, the rule amounts to a requirement that characters of length greater than 1 be represented the same way as an array. It is possible for there to be character kinds that aren't represented that way (not that I know of any actual examples in existance). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30940
[Bug fortran/20923] Compile time is high for the following code
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-21 21:56 --- *** Bug 31301 has been marked as a duplicate of this bug. *** -- 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=20923
[Bug fortran/31301] Extremely long compilation time
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-21 21:56 --- *** This bug has been marked as a duplicate of 20923 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31301
[Bug fortran/31301] Extremely long compilation time
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-21 21:45 --- I bet this is a duplicate of another bug like say PR 20923. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31301
[Bug other/23572] No warning for assigning a value to a 'float' variable that overflows with option -Wextra
--- Comment #10 from patchapp at dberlin dot org 2007-03-21 21:05 --- Subject: Bug number PR 23572 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-03/msg01437.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23572
[Bug c++/31289] gcc412 elides code in operator delete() override method
--- Comment #8 from jima at cadence dot com 2007-03-21 20:58 ---
I tried using placement-new and explicit destructor calls to
delineate the lifetime of the allocator's internal class objects explicitly,
such that their lifetimes do not overlap with any references to the
same storage via pointers of other types (that is, during the lifetime of the
high-level object being allocated).
Can someone point out why this doesn't work? See the following program ...
#include
#include
#include
struct Block {
Block * next;
char rest_of_storage[128-sizeof(Block *)]; // max obj sizeof is 128
};
static Block * free_head = 0;
class C {
public:
void * operator new(size_t bytes_needed) {
if (free_head == 0) { abort(); }
Block * storage = free_head;
free_head = storage->next;
// Explicitly call the destructor for Block 'storage' to end its lifetime.
// (cf C++ 06 draft @12.4-13). C++ says the lifetime of the new 'C' being
// allocated begins when its constructor is called, which has not yet
// happened. Therefore the lifetimes of the Block and the C it is
// aliased to do not overlap, so the compiler should not re-order
// references to pass this barrier point.
storage->~Block();
return storage;
}
void operator delete(void * ptr_to_free, size_t how_big_it_is) {
// The lifetime of the C ended at start of its destructor, which occurred
// before we get here. So references to the C should not be re-ordered
// to pass that previous point (the start of its destructor).
// The following placement-new begins the lifetime of Block 'storage'.
// Therefore accesses to the old C and the new Block should not mix up.
Block * storage = new(ptr_to_free) Block;
storage->next = free_head;
free_head = storage;
// The lifetime of the Block 'storage' continues until it is ended
// in a later call to operator new.
}
C() {}
virtual ~C() {} // virtual dtor required for problem to appear (why?)
};
int main() {
setbuf(stdout,NULL); setbuf(stderr,NULL); // disable buffering
free_head = new Block; // Put one object on the free-list
free_head->next = 0;
C *obj = new C;
delete obj;
if (free_head->next != 0) {
printf("ERROR: Expected only one block on free list\n");
return 1;
}
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31289
[Bug fortran/31301] New: Extremely long compilation time
The following program compiles with g95 and f95 in less than a second. gfortran needs more than several minutes (until I lost patience). I think gfortran does not enter an endless loop but tries to solve the h1 assignment explicitly. (At least is seems to do this with a much stripped down version.) Full example: http://home.comcast.net/~kmbtib/fft64t.i90 http://home.comcast.net/~kmbtib/fft64t.f90 The slow-down line is: h1 = (/(sum((/(exp(-2*pi*(0,1)*mod(k*L,N)/N)*h2(L),L=0,N-1)/)),k=0,N-1)/) -- Summary: Extremely long compilation time Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: compile-time-hog 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=31301
[Bug fortran/30146] Redefining do-variable in excecution cycle
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-21 19:07 ---
(In reply to comment #3)
> The following program causes an infinite loop in gfortran, but not in other
> fortrans.
The program is plainly invalid as one redefines the DO thus your Fortran
compiler is free to do what ever it wants. In addition, your standard violation
cannot be detected at compile time.
gfortran implements it as:
while(1) {
if(i == 1) break;
}
This of cause fails if you change i. As the program is invalid and as I don't
see any possibility to fix this in gfortran, I regard the problem of comment 3
as INVALID/WONTFIX.
For the original example, comment 0, I still think outputting a warning or an
error would be ok. (difference: the original example uses "INTENT(OUT)", the
comment 3 example uses no INTENT - besides, an interface or a host/use
association would be needed too.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146
[Bug c++/31300] undetected class name clash
--- Comment #6 from thierry dot galas at med dot ge dot com 2007-03-21 18:33 --- Subject: Re: undetected class name clash Thanks for the anonymous namespace suggestion (I didn't know about it before) , it is efficient and could be systematized at the scale of a large team. pinskia at gcc dot gnu dot org wrote: > --- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-21 18:26 > --- > The only way to get a diagnostic is to output the class definition and even > then sometimes the detection could be wrong. ODR reporting is a hard problem > with most code. > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31300
[Bug tree-optimization/31261] Missed tree optimizations: (8 - (x & 7)) & 7
--- Comment #4 from trt at acm dot org 2007-03-21 18:28 --- I think this could be generalized to more operators, e.g. (y | (x & 7)) & 7 ^ (bitwise or, xor, multiply, ...) This optimization could be for "e & M" where e contains a subexpression of the form "t & N" which can (sometimes) be simplified to "t". I suppose that would require walking the tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31261
[Bug c++/31300] undetected class name clash
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-21 18:26 --- The only way to get a diagnostic is to output the class definition and even then sometimes the detection could be wrong. ODR reporting is a hard problem with most code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31300
[Bug c++/31300] undetected class name clash
--- Comment #4 from thierry dot galas at med dot ge dot com 2007-03-21 18:16 --- Subject: Re: undetected class name clash I agree , sure it is invalid ,(no mine at the root) but a diagnostic would be nice very difficult to decide people to use c++ , if this kind of issue is not detected whereas symbol (variable function) name clash are detected at link time in "C" pinskia at gcc dot gnu dot org wrote: > --- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-21 17:53 > --- > They are not local, if you want to declare local classes to a file use an > anonymous namespace. > > This code is invalid but no diagnostic is required by the C++ standard (it > violates the One definition rule). > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31300
[Bug fortran/31299] getlog returns blanks when not run from the command prompt
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-21 18:02 --- (In reply to comment #5) > Anyways this is a bug with coreutils. > coreutils 5.2.1's nohup works > coreutils 5.93's nohup does not. > You should report this bug to them. I reported it now, cf. http://lists.gnu.org/archive/html/bug-coreutils/2007-03/index.html (archive refreshed every 12h) As gfortran (ifort,sunf95) correctly call the POSIX function getlogin(), I think one can close this bug. Or does anyone think that we should work around this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug c++/31300] undetected class name clash
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-21 17:53 --- They are not local, if you want to declare local classes to a file use an anonymous namespace. This code is invalid but no diagnostic is required by the C++ standard (it violates the One definition rule). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31300
[Bug c++/31300] undetected class name clash
--- Comment #2 from thierry dot galas at med dot ge dot com 2007-03-21 17:52 --- samething with gcc : version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31300
[Bug c++/31300] undetected class name clash
--- Comment #1 from thierry dot galas at med dot ge dot com 2007-03-21 17:50 --- Created an attachment (id=13245) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13245&action=view) very short code showing the issue in a tar file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31300
[Bug c++/31300] New: undetected class name clash
2 local classes with same name and sharing methods with same signature
mismatch in calling methods depending on link order
fangorn:thierry% g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/thierry/gcc-4.0.4/configure
Thread model: posix
gcc version 4.0.4
fangorn:thierry% g++ t1.cxx t2.cxx main.cxx
fangorn:thierry% ./a.out
X1
X1
fangorn:thierry% g++ t2.cxx t1.cxx main.cxx
fangorn:thierry% ./a.out
X2
X2
fangorn:thierry% more x.h
struct X {
virtual void print()=0;
};
X* getX1();
X* getX2();
fangorn:thierry% more t1.cxx
#include "x.h"
#include
struct X1 : public X {
virtual void print () { std::cerr << " X1\n"; };
};
struct T : public X1 {
};
static X* x=new T();
X* getX1() { return x; };
fangorn:thierry% more t2.cxx
#include "x.h"
#include
struct X2 : public X {
virtual void print () { std::cerr<< " X2\n"; };
};
struct T : public X2 {
};
static X* x=new T();
X* getX2() { return x; };
fangorn:thierry% more main.cxx
#include "x.h"
int main(int argc, char** argv) {
X* x1=getX1();
X* x2=getX2();
x1->print();
x2->print();
}
--
Summary: undetected class name clash
Product: gcc
Version: 4.0.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thierry dot galas at med dot ge dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31300
[Bug fortran/31299] getlog returns blanks when not run from the command prompt
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-21 17:34 --- This is not a shell issue either, it is just csh/tcsh has nohup as a builtin :). Anyways this is a bug with coreutils. coreutils 5.2.1's nohup works coreutils 5.93's nohup does not. You should report this bug to them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug fortran/31299] getlog returns blanks when not run from the command prompt
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-21 17:31 --- The only thing I can think of this is really a glibc issue and/or a shell issue as it works for me with debian. Ok, I can reproduce it with bash on FC5 (I think it is FC5) but it works with csh as the shell. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug fortran/31299] getlog returns blanks when not run from the command prompt
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-21 17:27 --- I can reproduce this. With g95 it shows also with nohup the login, whereas with gfortran, sunf95 and ifort it does not. gfortran calls: char *getlogin(void) g95 calls: getpwuid(getuid())->pw_name -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug fortran/31213] ICE on valid code with gfortran
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-21 17:15 --- aad.f90: In function 'tricky': aad.f90:24: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:877 Compiles with NAG f95 and g95, ICEs with ifort and sunf95. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-03-21 17:15:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31213
[Bug fortran/31211] wrong code generated for pointer returning function as actual argument
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-21 17:13 --- The following code is wrong, if cp_get_default_logger returns NULL. struct cp_logger_type D.1364; D.1364 = *cp_get_default_logger (); cp_logger_log (&&D.1364); *** This bug has been marked as a duplicate of 31200 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||wrong-code Resolution||DUPLICATE Summary|wrong code generated with |wrong code generated for |gfortran|pointer returning function ||as actual argument http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31211
[Bug fortran/31200] wrong code: procedure call with pointer-returning-function as argument
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-21 17:13 --- *** Bug 31211 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31200
[Bug fortran/31210] wrong code generated: character MERGE(...) with MASK=.false.
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-21 17:05 --- "new" seems to be ok (should_write_tags=.true.) but new2 contains only garbage. -- 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 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-03-21 17:05:21 date|| Summary|wrong code generated with |wrong code generated: |gfortran|character MERGE(...) with ||MASK=.false. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31210
[Bug fortran/31299] getlog returns blanks when not run from the command prompt
--- Comment #2 from michael dot a dot richmond at nasa dot gov 2007-03-21 16:59 --- Subject: Re: getlog returns blanks when not run from the command prompt I am running SuSE Linux 10.2 At 12:49 PM 3/21/2007, you wrote: >--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-21 >16:49 --- >This works for me: >[EMAIL PROTECTED]:~$ nohup ./a.out >nohup: appending output to `nohup.out' >[EMAIL PROTECTED]:~$ !c >cat nohup.out > Hello > apinski > > >What OS are you running with? > > >-- > > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299 > >--- You are receiving this mail because: --- >You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug fortran/31299] getlog returns blanks when not run from the command prompt
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-21 16:49 --- This works for me: [EMAIL PROTECTED]:~$ nohup ./a.out nohup: appending output to `nohup.out' [EMAIL PROTECTED]:~$ !c cat nohup.out Hello apinski What OS are you running with? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug fortran/31299] New: getlog returns blanks when not run from the command prompt
The following program prints my login name when I run it with the command: ./a.out but it prints only blanks when I run it with nohup: nohup ./a.out cat nohup.out PROGRAM test_getlog CHARACTER(LEN=8) :: cname CALL GETLOG(cname) PRINT *, cname END -- Summary: getlog returns blanks when not run from the command prompt 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=31299
[Bug c++/25874] [gomp] ICE in calc_dfs_tree()
--- Comment #11 from jakub at gcc dot gnu dot org 2007-03-21 16:16 --- Richard, in http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00972.html you said you'll look into it. The above mentioned patch (updated so that it applies) is what I'm using in Fedora Core and RHEL gccs for almost a year now. Could you please look at this and either approve the updated version of that patch (can repost), or come up with something else? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25874
[Bug fortran/30146] Redefining do-variable in excecution cycle
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2007-03-21 16:15 --- The following program causes an infinite loop in gfortran, but not in other fortrans. PROGRAM do_index_in_call DO i = 1, 1 CALL SUB(i) ENDDO END PROGRAM do_index_in_call SUBROUTINE sub(i) i = 2 END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146
[Bug c++/31289] gcc412 elides code in operator delete() override method
--- Comment #7 from jima at cadence dot com 2007-03-21 16:13 --- (In reply to comment #6) > ... the proper way is to start a new object lifetime using placement new. Are you referring only to internal operations in MyHeap::Malloc (in the demo program), or do you mean that the overall scheme can be re-coded somehow to use placement new without any casts? If the latter, I don't understand how that is possible, because the type of the object being allocated is not known -- the API of override operator new is (void *, size_t). Note that the interface we are trying to preserve (in use for many years) is that application programmers simply derive from a special base class when declaring their own classes, and then objects will use the special allocator. We can not require application coders to explicitly write placement-new (or call any kind of special allocator interface); that would be unworkable for human reasons, and also would prevent using generic template functions which must use ordinary "new" to allocate objects of template-parameter type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31289
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #18 from dominiq at lps dot ens dot fr 2007-03-21 16:09 --- > It would be nice to know whether darwin does not implement cexp in an optimal > way ... I have forgotten to mention that I did some (quick) profiling: cexp seens trivially implemented. It calls sin, cos and exp + the ABI problem mentionned by Andrew. It seems that any inplementation of cexp calling sin and cos would at best lead to a draw and more likely to a regression in timing. Now I cannot rule out that on some platforms cexp is implemented in a clever way, using some kind of sincos alrgorithm (this is what I would like to know). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug fortran/31265] Rejects valid with -std=f95: Error with RESHAPE on REAL initialization
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-03-21 16:01:54 date|| Summary|Error with RESHAPE on REAL |Rejects valid with -std=f95: |initialization |Error with RESHAPE on REAL ||initialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31265
[Bug fortran/31266] Spurious(?) warning about character truncation
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-03-21 15:59:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31266
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-03-21 15:57 --- It would be nice to know whether darwin does not implement cexp in an optimal way (special casing zero real part and dispatching to a sincos equivalent for the imaginary part) or if the issue is only a bad ABI for complex values. Otherwise the proposal looks ok, those other targets are mostly embedded ones and as such don't care too much about optimized sincos probably. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug target/31245] SSE2 generation bug with 4.1.2 and -O3
--- Comment #9 from rth at gcc dot gnu dot org 2007-03-21 15:52 --- Subject: Bug 31245 Author: rth Date: Wed Mar 21 15:52:23 2007 New Revision: 123112 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123112 Log: PR target/31245 * config/i386/emmintrin.h (__m128i, __m128d): Mark may_alias. * config/i386/mmintrin.h (__m64): Likewise. * config/i386/xmmintrin.h (__m128): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/emmintrin.h trunk/gcc/config/i386/mmintrin.h trunk/gcc/config/i386/xmmintrin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
[Bug target/31245] SSE2 generation bug with 4.1.2 and -O3
--- Comment #8 from rth at gcc dot gnu dot org 2007-03-21 15:50 --- Subject: Bug 31245 Author: rth Date: Wed Mar 21 15:50:01 2007 New Revision: 123111 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123111 Log: PR target/31245 * config/i386/emmintrin.h (__m128i, __m128d): Mark may_alias. * config/i386/mmintrin.h (__m64): Likewise. * config/i386/xmmintrin.h (__m128): Likewise. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/emmintrin.h branches/gcc-4_2-branch/gcc/config/i386/mmintrin.h branches/gcc-4_2-branch/gcc/config/i386/xmmintrin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
[Bug other/31033] Collect2 will not allow shared gcc with cross compiler
--- Comment #8 from dje at gcc dot gnu dot org 2007-03-21 15:49 --- This is not a GCC bug. Binutils was updated to support AIX 4.3.3, but has not been maintained, improved, or updated for AIX 5. It can do simple things, but does not fully support more advanced features. For instance, some aspects of shared object creation are not complete. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31033
[Bug target/31245] SSE2 generation bug with 4.1.2 and -O3
--- Comment #7 from rth at gcc dot gnu dot org 2007-03-21 15:47 --- Subject: Bug 31245 Author: rth Date: Wed Mar 21 15:46:46 2007 New Revision: 123110 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123110 Log: PR target/31245 * config/i386/emmintrin.h (__m128i, __m128d): Mark may_alias. * config/i386/mmintrin.h (__m64): Likewise. * config/i386/xmmintrin.h (__m128): Likewise. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/emmintrin.h branches/gcc-4_1-branch/gcc/config/i386/mmintrin.h branches/gcc-4_1-branch/gcc/config/i386/xmmintrin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
[Bug c++/26943] [gomp] firstprivate + lastprivate uses inefficient barrier
--- Comment #13 from rth at gcc dot gnu dot org 2007-03-21 15:43 --- We've fixed the wrong-code part. Re-tagging the PR to reflect the optimization possibility. -- rth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords|wrong-code |missed-optimization Summary|[gomp] firstprivate not |[gomp] firstprivate + |working properly with non- |lastprivate uses inefficient |POD |barrier http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #16 from dominiq at lps dot ens dot fr 2007-03-21 15:36 ---
> The recommended way is to post a message to gcc@gcc.gnu.org or
> [EMAIL PROTECTED]
I'll follow your advice, but before I'ld like some feedback about what follows.
I have applied the following patch
--- gcc-4.3-20070316/gcc/tree-ssa-math-opts.c Thu Mar 8 20:02:51 2007
+++ gcc-4.3-20070317/gcc/tree-ssa-math-opts.c Tue Mar 20 17:21:16 2007
@@ -704,9 +704,7 @@
gate_cse_sincos (void)
{
/* Make sure we have either sincos or cexp. */
- return (TARGET_HAS_SINCOS
- || TARGET_C99_FUNCTIONS)
-&& optimize;
+ return TARGET_HAS_SINCOS && optimize;
}
struct tree_opt_pass pass_cse_sincos =
I have regtested it with no change in the reports for gcc, g++, gfortran,
and objc. The timings before and after are
before after
-O0 -O1 % -O0 -O1 %
g++-4 sincos_o.c6.2 9.6 +55 6.3 5.6 -11
gfc sincos_o.f906.3 9.6 +52 6.4 5.5 -14
for the following C and Fotran tests:
[karma] bug/timing% cat sincos_o.c
#include
#include
int main()
{
longn = 100;
longi;
double mo = -1.0;
double pi = acos(mo);
double sc = 0.0;
double ss = 0.0;
double t = 0.0;
double dt = pi/n;
printf("%.17g \n", pi);
printf("%.17g \n", dt);
for (i=0; i< 40*n; i++) {
sc += cos(t);
ss += sin(t);
t += dt;
}
printf("%.17g %.17g \n", sc, ss);
}
[karma] bug/timing% cat sincos_o.f90
integer, parameter :: n=100
integer :: i
real(8) :: pi, ss, sc, t, dt
pi = acos(-1.0d0)
dt=pi/n
sc=0
ss=0
t=0
do i= 1, 40*n
sc = sc + cos(t)
ss = ss + sin(t)
t = t+dt
end do
print *, sc, ss
end
So from the PPC Darwin point of view, everything is working as expected.
I have done a search on the regtest list based on
FAIL: gcc.dg/builtins-59.c scan-tree-dump __builtin_cexpi
assuming that platforms that do not pass it, are likely to have not
__builtin_cexpi, thus are exposed to the same bad optimization.
I have found the following list tested on a regular basis:
powerpc-apple-darwin8.5.0
hppa2.0w-hp-hpux11.11
v850-unknown-elf
sparc-unknown-elf
sh-unknown-elf
powerpc-unknown-eabisim
mips-unknown-elf
m32r-unknown-elf
m32c-unknown-elf
avr-unknown-none
frv-unknown-elf
arm-unknown-elf
cris-axis-elf
arm-none-eabi
As far as I can tell, only the first two are tested against g++ and
gfortran.
Note that the list does not include powerpc64-apple-darwin8.8.0.
So it seems that it has __builtin_cexpi.
I don't know what will be the final decision about the proposed patch,
but there is no "emergency" since I can use it for my coming weekly builds.
I would prefer to have some feedback from the listed platforms before
seeing the patch applied.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug fortran/31250] Initialization expr as constant character length rejected
--- Comment #1 from tobi at gcc dot gnu dot org 2007-03-21 15:23 --- The problem seems to be that the expression is not folded at all. Calling gfc_show_expr (e) right before the error message is printed in resolve.c:5618 prints min[((-4) (5))] -- 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=31250
[Bug fortran/31193] ICE on non-constant character tranfert
--- Comment #2 from pault at gcc dot gnu dot org 2007-03-21 15:22 ---
This fixes it
Index: gcc/fortran/trans-intrinsic.c
===
*** gcc/fortran/trans-intrinsic.c (revision 123059)
--- gcc/fortran/trans-intrinsic.c (working copy)
*** gfc_conv_intrinsic_array_transfer (gfc_s
*** 2829,2834
--- 2829,2835
tree extent;
tree source;
tree source_bytes;
+ tree mold_type;
tree dest_word_len;
tree size_words;
tree size_bytes;
*** gfc_conv_intrinsic_array_transfer (gfc_s
*** 2934,2953
if (ss == gfc_ss_terminator)
{
gfc_conv_expr_reference (&argse, arg->expr);
-
- /* Obtain the source word length. */
tmp = gfc_size_in_bytes (&argse, arg->expr);
}
else
{
gfc_init_se (&argse, NULL);
argse.want_pointer = 0;
gfc_conv_expr_descriptor (&argse, arg->expr, ss);
-
- /* Obtain the source word length. */
tmp = gfc_size_in_bytes (&argse, arg->expr);
}
!
dest_word_len = gfc_create_var (gfc_array_index_type, NULL);
gfc_add_modify_expr (&se->pre, dest_word_len, tmp);
--- 2935,2952
if (ss == gfc_ss_terminator)
{
gfc_conv_expr_reference (&argse, arg->expr);
tmp = gfc_size_in_bytes (&argse, arg->expr);
+ mold_type = TREE_TYPE (build_fold_indirect_ref (argse.expr));
}
else
{
gfc_init_se (&argse, NULL);
argse.want_pointer = 0;
gfc_conv_expr_descriptor (&argse, arg->expr, ss);
tmp = gfc_size_in_bytes (&argse, arg->expr);
+ mold_type = gfc_get_element_type (TREE_TYPE (argse.expr));
}
!
dest_word_len = gfc_create_var (gfc_array_index_type, NULL);
gfc_add_modify_expr (&se->pre, dest_word_len, tmp);
$
*** gfc_conv_intrinsic_array_transfer (gfc_s
*** 3016,3025
/* Build a destination descriptor, using the pointer, source, as the
data field. This is already allocated so set callee_alloc.
FIXME callee_alloc is not set! */
-
- tmp = gfc_typenode_for_spec (&expr->ts);
gfc_trans_create_temp_array (&se->pre, &se->post, se->loop,
! info, tmp, false, true, false);
/* Use memcpy to do the transfer. */
tmp = build_call_expr (built_in_decls[BUILT_IN_MEMCPY],
--- 3015,3022
/* Build a destination descriptor, using the pointer, source, as the
data field. This is already allocated so set callee_alloc.
FIXME callee_alloc is not set! */
gfc_trans_create_temp_array (&se->pre, &se->post, se->loop,
! info, mold_type, false, true, false);
/* Use memcpy to do the transfer. */
tmp = build_call_expr (built_in_decls[BUILT_IN_MEMCPY],
However, mold being string(1:1) gives the wrong result so I'll fix that first
before submitting the patch.
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-03-16 06:54:45 |2007-03-21 15:22:38
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31193
[Bug fortran/31298] New: Uninitialized variable in f951 (in read_module)
valgrind finds when compiling gfortran.dg/use_6.f90 the following unitinitalized variables: ==29473== Conditional jump or move depends on uninitialised value(s) ==29473==at 0x43DD76: read_module (module.c:733) ==29473==by 0x43E664: gfc_use_module (module.c:4201) ==29473==by 0x443DC7: accept_statement (parse.c:1256) ==29473==by 0x444854: parse_spec (parse.c:1902) ==29473==by 0x445C95: parse_progunit (parse.c:2901) ==29473==by 0x445F01: gfc_parse_file (parse.c:3239) ==29473==by 0x46423D: gfc_be_parse_file (f95-lang.c:307) ==29473==by 0x679573: toplev_main (toplev.c:1050) ==29473==by 0x52BE943: (below main) (in /lib64/libc-2.5.so) Analogusly for use_5.f90. -- Summary: Uninitialized variable in f951 (in read_module) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code 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=31298
[Bug fortran/31144] gfortran module symbol names are not standard compliant
--- Comment #6 from tobi at gcc dot gnu dot org 2007-03-21 15:12 --- That should work, C++ mangles names to something like _ZN9wikipedia7article8wikilinkC1ERKSs NB your regexp is missing the underscore inside the second pair of brackets :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31144
[Bug tree-optimization/31261] Missed tree optimizations: (8 - (x & 7)) & 7
--- Comment #3 from jakub at gcc dot gnu dot org 2007-03-21 15:05 --- Created an attachment (id=13244) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13244&action=view) gcc43-pr31261.patch Patch I'm testing ATM. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31261
[Bug fortran/28722] Fortran front-end produces mismatch trees
--- Comment #6 from tobi at gcc dot gnu dot org 2007-03-21 15:04 --- I don't understand why it fails in the fourth case. The comparison it seems to complain about is generated via return build2 (NE_EXPR, boolean_type_node, decl, fold_convert (TREE_TYPE (decl), null_pointer_node)); (trans-expr.c:141) which looks like it gets the types right. Replacing the call to fold_convert with an equivalent call to build_int_cst doesn't help either, BTW. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28722
[Bug testsuite/31290] gcc.c-torture/execute/920612-1.c and gcc.c-torture/execute/920711-1.c depend on signed overflow being defined
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-21 14:56 --- gcc.c-torture/execute/920711-1.c has exactly the same issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|gcc.c- |gcc.c- |torture/execute/920612-1.c |torture/execute/920612-1.c |depends on overflow being |and gcc.c- |defined |torture/execute/920711-1.c ||depend on signed overflow ||being defined http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31290
[Bug fortran/28722] Fortran front-end produces mismatch trees
--- Comment #5 from tobi at gcc dot gnu dot org 2007-03-21 14:54 --- Behavior is different with today's mainline on i386-darwin. Without optimization the first one gives an error further down the line, and the other three pass: 1.f90:3: internal compiler error: in simplify_subreg, at simplify-rtx.c:4671 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. With optimization, the first three pass, and the fourth gives the same error that FX has seen. -- 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=28722
[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations
--- Comment #5 from jakub at gcc dot gnu dot org 2007-03-21 14:53 --- obj-c++ bootstrap is actually where the warning triggered correctly, this was on trunk checkout from yesterday and some tree codes were >= 256, while an array had just 256 entries and thus e.g. tree_contains_struct[CLASS_METHOD_DECL][TS_DECL_NON_COMMON] = 1; (where CLASS_METHOD_DECL == 259 and TS_DECL_NON_COMMON == 1 and extern unsigned char tree_contains_struct[256][64];) is supposed to warn. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227
[Bug fortran/30877] Extending intrinsic operators
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-03-21 14:50 --- Created an attachment (id=13243) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13243&action=view) Patch to fix the problem reported This one is mine. Attached patch (regtested on i686-linux) fixes the failure and, as far as I see, should bring the extension of intrinsic operators completely in line with the standards. I still need to come up with a complete testcase to ensure that I haven't forgotten something along the way. -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877
[Bug c++/16370] __attribute__((deprecated)) not useful on classes, and ugly function name listed for deperecation warnings on constructor
--- Comment #4 from ian at airs dot com 2007-03-21 14:39 ---
With current mainline, I get no warning for this:
struct Foo { int i; } __attribute__ ((deprecated));
void foo() { Foo f; }
but I do get a warning for this:
struct Foo { int i; } __attribute__ ((deprecated));
void foo() { struct Foo f; }
The only different is the "struct" keyword. That is bizarre.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16370
[Bug libfortran/31297] New: Use of uninitialized variables in libgfortran's I/O
Found using valgrind: gfortran gfortran.dg/backspace_5.f valgrind ./a.out ==15340== Syscall param write(buf) points to uninitialised byte(s) ==15340==at 0x56000C0: __write_nocancel (in /lib64/libc-2.5.so) ==15340==by 0x4EBEE90: do_write (unix.c:336) ==15340==by 0x4EBEF31: fd_flush (unix.c:386) ==15340==by 0x4EBCBF6: _gfortran_st_write_done (transfer.c:2762) ==15340==by 0x400BAB: MAIN__ (in /projects/tob/gcc/gcc/testsuite/gfortran.dg/a.out) ==15340==by 0x40104B: main (fmain.c:22) Similarly for: - backspace_6.f - write_back.f - write_rewind_1.f - write_rewind_2.f - char_bounds_check_fail_1.f90 - direct_io_2.f90 - unf_io_convert_3.f90 -- Summary: Use of uninitialized variables in libgfortran's I/O Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran 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=31297
[Bug fortran/31296] New: Uninitialized variable in libgfortran's _gfortran_unpack0_char
Found by valgrind: gfortran gfortran.dg/char_unpack_2.f90 valgrind a.out ==20842== Conditional jump or move depends on uninitialised value(s) ==20842==at 0x4ECB306: unpack_internal (unpack_generic.c:99) ==20842==by 0x4ECB6AA: _gfortran_unpack0_char (unpack_generic.c:233) ==20842==by 0x400D11: MAIN__ (in /projects/tob/gcc/gcc/testsuite/gfortran.dg/a.out) ==20842==by 0x40112B: main (fmain.c:22) -- Summary: Uninitialized variable in libgfortran's _gfortran_unpack0_char Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code 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=31296
[Bug fortran/31295] New: Uninitialized variable in libgfortran's _gfortran_eoshift0_4
Found by valgrind: gfortran gfortran.dg/eoshift.f90 valgrind a.out ==20986== Conditional jump or move depends on uninitialised value(s) ==20986==at 0x4EC57D7: eoshift0 (eoshift0.c:115) ==20986==by 0x4EC5D0A: _gfortran_eoshift0_4 (eoshift0.c:251) ==20986==by 0x4009A7: MAIN__ (in /projects/tob/gcc/gcc/testsuite/gfortran.dg/a.out) ==20986==by 0x400A3B: main (fmain.c:22) Similarly for: - zero_sized_1.f90 -- Summary: Uninitialized variable in libgfortran's _gfortran_eoshift0_4 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code 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=31295
[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations
-- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227
[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations
--- Comment #4 from mueller at gcc dot gnu dot org 2007-03-21 14:16 --- Created an attachment (id=13242) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13242&action=view) patch this is the patch I'm currently testing. would be nice if you could confirm that this is also fixing your obj-c++ bootstrap problem (which I cannot reproduce). Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227
[Bug fortran/31234] Thread-safety of random_number should be documented.
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-03-21 14:11 --- Brooks, maybe not. Thread safety, in the context it was asked for, still needs to be proved. Having mutexes within the code is fine to save the states from overwriting each other (it is an unexpected serialisation point, though). Nevertheless, as RANDOM_NUMBER is expected to give uniformely distributed numbers from 0.0 to 1.0 on a single thread, this needs not to be the case if multiple threads draw from the same series as currently implemented. I'll run some tests as soon as possible and report back to the mailing list. -- 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=31234
[Bug fortran/30877] Extending intrinsic operators
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-21 14:02:12 date|| Summary|overloading "operator(*)" |Extending intrinsic |for intrinsic type (complex)|operators |fails | Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877
[Bug fortran/31144] gfortran module symbol names are not standard compliant
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-21 14:00 --- (In reply to comment #4) > FX' suggestion may fail if dots turn out to be non-portable. The GNU as documentation says: "Symbol names begin with a letter or with one of `._'. On most machines, you can also use $ in symbol names; exceptions are noted in Machine Dependencies. That character may be followed by any string of digits, letters, dollar signs (unless otherwise noted in Machine Dependencies), and underscores." So the strictest possible set of names: [a-zA-Z._][a-zA-Z0-9]* We should see if there are other requirements, e.g. when GCC is built with a system assembler that is not the GNU as. Otherwise, I think we'll have to go with uppercase. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31144
Re: Bug in GCC code generation (powerpc-eabi)
On 3/21/07, Informatica Tecnologia Dual <[EMAIL PROTECTED]> wrote:
Hi.
I'm using the GCC compiler for PPC405 as delivered with Xilinx EDK 8.1.
The exact version is: powerpc-eabi-gcc (GCC) 3.4.1 ( Xilinx EDK 8.1.1
Build EDK_I.19.3 190106 )
I found a bug in the code generation.
My code is a serial receiver and uses an uninitialized uchar nData:
uchar nBits;
uchar nData;
for (nBits=0; nBits<8; nBits++) {
nData >>= 1;// the bug is related to this statement
if (function()) nData |= 0x80;
}
Although nData is not initialized, the correct state after the first
"nData >>= 1" statement would be any value between 0x00 and 0x7f.
However, on my target board I found it to be >= 0x80.
And if nData is not initialized you are invoking undefined behavior
according to the C/C++ standards so the behavior here is ok. Yes you
are not expecting this behavor but that is not our fault you are
depening on undefined behavior.
Thanks,
Andrew Pinski
[Bug fortran/31144] gfortran module symbol names are not standard compliant
--- Comment #4 from tobi at gcc dot gnu dot org 2007-03-21 12:13 --- (In reply to comment #3) FX' suggestion may fail if dots turn out to be non-portable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31144
Bug in GCC code generation (powerpc-eabi)
Hi.
I'm using the GCC compiler for PPC405 as delivered with Xilinx EDK 8.1.
The exact version is: powerpc-eabi-gcc (GCC) 3.4.1 ( Xilinx EDK 8.1.1
Build EDK_I.19.3 190106 )
I found a bug in the code generation.
My code is a serial receiver and uses an uninitialized uchar nData:
uchar nBits;
uchar nData;
for (nBits=0; nBits<8; nBits++) {
nData >>= 1;// the bug is related to this statement
if (function()) nData |= 0x80;
}
Although nData is not initialized, the correct state after the first
"nData >>= 1" statement would be any value between 0x00 and 0x7f.
However, on my target board I found it to be >= 0x80.
Looking at the disassembler output shows that the compiler used the
following assembler instruction to implement the "nData >>= 1" statement:
rlwinm r26,r26,31,24,31 // incorrect implementation, as
generated by gcc
It is a rotate-left by 31 bits (equals a rotate-right by 1 bit), and
subsequent AND-mask with 0xFF (powerpc-eabi is a big endian machine).
This command is not a correct implementation of the statement. It is
only correct if bit 0 of R26 (which will become bit 31 after the rotate)
happens to be 0.
The correct implementation would be to use a different mask value, which
ensures that the "new" bit 31 is 0 (mask 0x7F instead of 0xFF):
rlwinm r26,r26,31,24,30 // corrected implementation
I can work around this bug by initializing nData before the first use,
because GCC will initialize all of r26 (including bit 0) . However I
still consider it a bug that should be addressed.
Keep on good work!
Regards from Spain,
Marc
[Bug fortran/31294] New: Endless loop when compiling a cyclic code
I'm not completely sure that the following code is invalid, but I think it is.
Taken from:
http://home.comcast.net/%7Ekmbtib/Fortran_stuff/cyclic_specs1.f90
g95 prints:
Error: Circular specification in variable 'ouch' at (1)
NAG f95 compiles it without any warning/error, however. Running it (using all
checks) shows either an empty line or
CHARACTER actual arg LEN=4 shorter than dummy arg LEN=1963731936
which indicates that it is indeed invalid.
Here is the source:
! File: cyclic_specs1.f90
! Public domain 2004 James Van Buskirk
! Leads to internal compiler error in g95
! Windows download of 12/18/04
module cyclic
implicit none
contains
function ouch(x,y)
implicit character(len(ouch)) (x)
implicit character(len(x)+1) (y)
implicit character(len(y)-1) (o)
intent(in) x,y
character(len(y)-1) ouch
integer i
do i = 1, len(ouch)
ouch(i:i) = achar(ieor(iachar(x(i:i)),iachar(y(i:i
end do
end function ouch
end module cyclic
program test
use cyclic
implicit none
write(*,*) ouch('YOW!',' ')
end program test
--
Summary: Endless loop when compiling a cyclic code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
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=31294
[Bug fortran/31293] Implicit character and array returning functions
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-21 10:49 --- Please also check: http://home.comcast.net/%7Ekmbtib/Fortran_stuff/interface2.f90 http://home.comcast.net/%7Ekmbtib/Fortran_stuff/interface3.f90 http://home.comcast.net/%7Ekmbtib/Fortran_stuff/interface4.f90 The latter gives an internal compiler error: interface4.f90: In function 'MAIN__': interface4.f90:70: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:877 But since they are all based on interface1.f90, I'm not sure what bug remains after the first problem has been fixed. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31293
[Bug fortran/31293] New: Implicit character and array returning functions
The following program compiles with NAG f95, g95 and ifort, but gfortran
writes:
interface1.f90:8.12:
test2(i:i) = achar(mod(i,32)+iachar('@'))
1
Error: Unclassifiable statement at (1)
This is possibly related to PR 31222. (If you mark it as duplicate, please
ensure that the full example is tested after that PR is fixed.)
Please also check the full program after you fixed it:
http://home.comcast.net/%7Ekmbtib/Fortran_stuff/interface1.f90
module test1
implicit none
contains
function test2()
implicit character (t)
integer i
do i = 1, len(test2)
test2(i:i) = achar(mod(i,32)+iachar('@'))
end do
end function test2
end module test1
--
Summary: Implicit character and array returning functions
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
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=31293
[Bug fortran/31292] New: ICE with module procedure interface in a procedure body
The following program is taken from http://home.comcast.net/%7Ekmbtib/Fortran_stuff/fire.f90 The is_g95 check returns T for g95 and NAG f95 and F for ifort 9.1 and sunf95. I believe it should return TRUE by the standard. Running the program through valgrind shows: ==317== Invalid read of size 1 ==317==at 0x41EC17: check_interface0 (interface.c:918) ==317==by 0x41F88A: gfc_check_interfaces (interface.c:1086) ... ==317== Invalid read of size 8 ==317==at 0x41EC7E: check_interface0 (interface.c:920) ==317==by 0x41F88A: gfc_check_interfaces (interface.c:1086) .. fire2.f90:12.37: module procedure assign_t 1 Error: Procedure 'assign_t' in intrinsic assignment operator at (1) is neither function nor subroutine. (Without using valgrind this crashes and gives an ICE -> ice-on-valid-code.) If one changes the order of "is_g95" and "assign_t", no invalid read occurs but the same error message is printed. (-> rejects-valid) If one moves the interface from the subroutine to before the contains line, it compiles and prints T. (-> good code; ifort still prints "F") Please check afterwards whether also the big program "fire.f90" compiles and runs. ! Based on: ! http://home.comcast.net/%7Ekmbtib/Fortran_stuff/fire.f90 module chk_g95 implicit none type t integer x end type t contains function is_g95() logical is_g95 interface assignment(=) module procedure assign_t end interface assignment(=) type(t) y(3) y%x = (/1,2,3/) y = y((/2,3,1/)) is_g95 = y(3)%x == 1 end function is_g95 elemental subroutine assign_t(lhs,rhs) type(t), intent(in) :: rhs type(t), intent(out) :: lhs lhs%x = rhs%x end subroutine assign_t end module chk_g95 program fire use chk_g95 implicit none print *, is_g95() if(.not. is_g95()) call abort() end program fire -- Summary: ICE with module procedure interface in a procedure body Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, rejects-valid 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=31292
[Bug c/31291] Different (wrong?) behaviour using ffps when enabling optimizing
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-21 09:59 --- You are violating C aliasing rules. Use a union or memcpy to access the fp value. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|Different (wrong?) behaviour|Different (wrong?) behaviour |using ffps when enabling|using ffps when enabling |optimizing |optimizing http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31291
[Bug c++/31289] gcc412 elides code in operator delete() override method
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-21 09:58 --- This is related to PR29286, the C++ aliasing rules are disputedly different from the C ones. So at the moment you cannot implement an allocator in C++ (and in C in general). That said, the proper way is to start a new object lifetime using placement new. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31289
[Bug tree-optimization/30927] tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-03-21 09:31
---
> If I understand right the two patches do different things. Consider
> the following example:
>
> void X(void) {
>void D(void) { D(); };
>D();
> }
>
> The nested function is reachable, so presumably your patch doesn't
> change the behaviour of tree-nested in this case, i.e. D gets a
> static chain even though it doesn't need one. My patch makes sure
> that D doesn't get a static chain.
Indeed, we still unnecessarily build a static chain for D.
Your solution seems to be somewhat complex though. Can't we get away with
an iterative propagation algorithm for the DECL_NO_STATIC_CHAIN flag?
> By the way, I see that you added a hash table for going from the
> context to the nesting_info. I was too lazy to do that, instead
> I do a linear list walk to find it. Do you think it matters?
No real idea in practice, but we try to avoid potentially quadratic stuff
in the compiler as a general policy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-03-21 09:13 --- Yet another wrinkle found (with -fno-range-check and crazily large integers), yet another patch: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01398.html This one looks final to me, though :) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||03/msg01398.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations
--- Comment #3 from mueller at gcc dot gnu dot org 2007-03-21 09:05 --- both are caused by our well known offender -fivopts. the problem why the existing workarounds don't work is because the adress is first converted to unsigned int before +/- modification is done. the traversal stops at the type conversion. I'm currently working on fixing that. -- mueller at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mueller at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227
[Bug target/31070] [4.1/4.2/4.3] internal compiler error: in function_arg_slotno, at config/sparc/sparc.c:4562 (for 4.1.2), at config/sparc/sparc.c:4605 (for 4.2 RC1), and at config/sparc/sparc.c:461
--- Comment #2 from christian dot joensson at gmail dot com 2007-03-21 08:37 --- same thing on 4.2 RC1: Executing on host: /usr/local/src/branch/objdir/gcc/testsuite/g++/../../g++ -B/\ usr/local/src/branch/objdir/gcc/testsuite/g++/../../ -nostdinc++ -I/usr/local/\ src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include/sparc64-unk\ nown-linux-gnu -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libs\ tdc++-v3/include -I/usr/local/src/branch/gcc/libstdc++-v3/libsupc++ -I/usr/loca\ l/src/branch/gcc/libstdc++-v3/include/backward -I/usr/local/src/branch/gcc/libs\ tdc++-v3/testsuite/util -fmessage-length=0 -w -I/usr/local/src/branch/gcc/gcc/t\ estsuite/g++.dg/compat -c -m64 -o cp_compat_x_tst.o /usr/local/src/branch/ob\ jdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_x.C(timeout = 1200) In file included from /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-str\ uct-layout-1/t026_x.C:7:^M /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_test\ .h: In function 'void checkx2400(S2400)':^M /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_test\ .h:1: internal compiler error: in function_arg_slotno, at config/sparc/sparc.c:\ 4605^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html> for instructions.^M compiler exited with status 1 output is: In file included from /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-str\ uct-layout-1/t026_x.C:7:^M /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_test\ .h: In function 'void checkx2400(S2400)':^M /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_test\ .h:1: internal compiler error: in function_arg_slotno, at config/sparc/sparc.c:\ 4605^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html> for instructions.^M FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o compile, (internal \ compiler error) Executing on host: /usr/local/src/branch/objdir/gcc/testsuite/g++/../../g++ -B/\ usr/local/src/branch/objdir/gcc/testsuite/g++/../../ -nostdinc++ -I/usr/local/\ src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include/sparc64-unk\ nown-linux-gnu -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libs\ tdc++-v3/include -I/usr/local/src/branch/gcc/libstdc++-v3/libsupc++ -I/usr/loca\ l/src/branch/gcc/libstdc++-v3/include/backward -I/usr/local/src/branch/gcc/libs\ tdc++-v3/testsuite/util -fmessage-length=0 -w -I/usr/local/src/branch/gcc/gcc/t\ estsuite/g++.dg/compat -c -m64 -o cp_compat_y_tst.o /usr/local/src/branch/ob\ jdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_y.C(timeout = 1200) In file included from /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-str\ uct-layout-1/t026_y.C:5:^M /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_test\ .h: In function 'S2400 check2400(S2400, S2400*, S2400)':^M /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_test\ .h:1: internal compiler error: in function_arg_slotno, at config/sparc/sparc.c:\ 4605^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html> for instructions.^M compiler exited with status 1 output is: In file included from /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-str\ uct-layout-1/t026_y.C:5:^M /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_test\ .h: In function 'S2400 check2400(S2400, S2400*, S2400)':^M /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_test\ .h:1: internal compiler error: in function_arg_slotno, at config/sparc/sparc.c:\ 4605^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html> for instructions.^M FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_y_tst.o compile, (internal \ compiler error) -- christian dot joensson at gmail dot com changed: What|Removed |Added Summary|[4.1/4.3] internal compiler |[4.1/4.2/4.3] internal |error: in |compiler error: in |function_arg_slotno, at |function_arg_slotno, at |config/sparc/sparc.c:4562 |config/sparc/sparc.c:4562 |(for 4.1.2) and at |(for 4.1.2), at |config/sparc/sparc.c:4619 |config/sparc/sparc.c:4605 |(for 4.3 revision 122655) |(for 4.2 RC1), and at ||config/sparc/sparc.c:4619 ||(for 4.3 revision 122655) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31070
