--- Comment #8 from ro at gcc dot gnu dot org 2010-05-17 20:29 ---
Subject: Bug 44074
Author: ro
Date: Mon May 17 20:28:56 2010
New Revision: 159512
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159512
Log:
PR target/44074
* configure.ac
--- Comment #1 from kargl at gcc dot gnu dot org 2010-05-17 20:29 ---
Given this code
real foo(2) /2*0.0/
data foo/0.0, 0.0/
print *, foo
end
Trunk compiles the code. Gfortran 4.5 has the ICE.
troutmask:sgk[211] gfc4x -o z -Wall t.f90
troutmask:sgk[212] ./z
0.000
--- Comment #2 from kargl at gcc dot gnu dot org 2010-05-17 20:31 ---
BTW, one should consider elimination of the ...
troutmask:sgk[210] gfc4x -o z -Wall -std=f95 t.f90
t.f90:1.13:
real foo(2) /2*0.0/
1
Error: Extension: Old-style initialization at (1)
t.f90:2.4:
from
--- Comment #15 from iains at gcc dot gnu dot org 2010-05-17 20:31 ---
the libgomp fails with comment #14 are pretty much:
/i686-apple-darwin9/./libgomp/.libs:/Volumes/ScratchCS/gcc-4-6-trunk-build/gcc
atomic-4.exe(94763) malloc: *** error for object 0x800180: pointer being
reallocated
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-17 20:35 ---
(In reply to comment #7)
If one adds b = ALLOCATED(x) one finds:
Where do you add this? I don't see a test case where this fits into. Can you
give a complete example?
Btw, after the recent patch for PR43969, this
--- Comment #3 from burnus at gcc dot gnu dot org 2010-05-17 20:39 ---
I can confirm the issue with GCC 4.3.4, 4.4.4, and 4.5.0; however, using 4.6 it
works. I think the ICE has been fixed by the recent constructor work by Daniel.
Thus, one solution is to close the bug as WONTFIX;
--- Comment #4 from potswa at mac dot com 2010-05-17 20:44 ---
The crash may have something to do with using a dependent type in a particular
context. This shorter code still crashes despite resolution failing — no
recursionÂ…
#include type_traits
template int x
typename
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-05-17 20:51
---
We have complete control of whether to print the negative sign with
-fno-sign-zero. I am tempted to say this is a no-never-mind situation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44156
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-17 21:02 ---
Another slight variation:
module module_myclass
implicit none
type :: inner
contains
procedure :: set
end type
type :: myclass
type(inner) :: slice
end type
contains
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-17 21:10 ---
The PR(In reply to comment #3)
I think the ICE has been fixed by the recent constructor work by Daniel.
That was PR24978. Given that this PR was opened against 4.1 in 2005 and a
simple workaround exists (fix your
Compiler flags:
$ g++ -O1 -fsched-pressure -funroll-loops -fschedule-insns -fcompare-debug
testcase.C
Tested revisions:
r159305 - fail
r159045 - fail
r158095 - fail
r153685 - OK
--
Summary: -fcompare-debug failure with -O1 -fgcse -fsched-pressure
-funroll-loops
--- Comment #5 from kargl at gcc dot gnu dot org 2010-05-17 21:46 ---
Pull the trigger for Daniel and mark this as a duplicate.
Harry, thanks for the report. The bug is fixed in gcc
trunk, which will become 4.6.0 someday. If you can't
fix the code (which is recommended), then you'll
--- Comment #37 from kargl at gcc dot gnu dot org 2010-05-17 21:46 ---
*** Bug 44177 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from zsojka at seznam dot cz 2010-05-17 21:47 ---
Created an attachment (id=20689)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20689action=view)
reduced testcase
$ /mnt/svn/gcc-trunk/binary-159305-lto-fortran/bin/g++ -O1 -fgcse
-fsched-pressure -funroll-loops
sizeof(char) is defined to be 1, and is therefore almost always unnecessary.
It would be nice if the C and C++ front ends could complain about it.
--
Summary: warn about sizeof(char)
Product: gcc
Version: unknown
Status: UNCONFIRMED
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-17 22:10 ---
I can see a case involving templates or macros where the warning does not make
sense and involving the new C1x/C++0x static_assert too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-17 22:23 ---
(In reply to comment #4)
We have complete control of whether to print the negative sign with
-fno-sign-zero. I am tempted to say this is a no-never-mind situation.
Using the testcase shown in comment #3:
$
--- Comment #5 from potswa at mac dot com 2010-05-17 22:56 ---
Created an attachment (id=20690)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20690action=view)
regression test using G++ typeof
Here is a version that doesn't require C++0x. It uses the typeof extension.
It compiles
[...@gnu-6 gcc]$ cat z.c
#define N 16
float b[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
float c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
float a[N];
void
test (void)
{
int i;
for (i = 0; i N/2; i++)
a[i] = b[2*i+1] * c[2*i+1];
}
[...@gnu-6 gcc]$ ./xgcc -B./ -O2 -ftree-vectorize
--- Comment #6 from kargl at gcc dot gnu dot org 2010-05-17 23:18 ---
(In reply to comment #5)
(In reply to comment #4)
We have complete control of whether to print the negative sign with
-fno-sign-zero. I am tempted to say this is a no-never-mind situation.
Using the testcase
Compiler flags:
g++ -Os -fgraphite-identity -fcompare-debug testcase.c
Tested revisions:
r159511 - fail
r159045 - fail
r158095 - fail
--
Summary: -fcompare-debug failure (length) with -Os -fgraphite-
identity
Product: gcc
Version: 4.6.0
--- Comment #1 from zsojka at seznam dot cz 2010-05-17 23:45 ---
Created an attachment (id=20691)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20691action=view)
reduced testcase (from gcc.c-torture/compile/pr43415.c)
$ /mnt/svn/gcc-trunk/binary-158095-lto-fortran/bin/g++ -Os
--- Comment #1 from hjl at gcc dot gnu dot org 2010-05-17 23:48 ---
Subject: Bug 44180
Author: hjl
Date: Mon May 17 23:47:44 2010
New Revision: 159519
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159519
Log:
Properly implement extract even/odd elements for V8SF.
gcc/
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-17 23:49 ---
(In reply to comment #6)
I already explained what dot_product is doing in comment #2.
dot_product(a,b) is equivalent to
s = 0
do n = 1, m
s = s + a(n) * b(n)
end do
(return s)
For
--- Comment #2 from zackw at panix dot com 2010-05-17 23:59 ---
So it has to be a little smarter than the obvious, so what else is new.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179
Command line:
g++ -O[123] -fcompare-debug testcase.C
Tested revisions:
r159511 - fail
--
Summary: -fcompare-debug failure (length) with -O1
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #1 from zsojka at seznam dot cz 2010-05-18 00:41 ---
Created an attachment (id=20692)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20692action=view)
reduced testcase
$ g++ -O1 -fcompare-debug pr44182.C
g++: pr44182.C: -fcompare-debug failure (length)
--
For
---
#define N 16
float b[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
float c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
float a[N];
void
test (void)
{
int i;
for (i = 0; i N/2; i++)
a[i] = b[2*i+1] * c[2*i+1];
}
---
vectorizer generates:
test ()
{
unsigned int ivtmp.30;
--- Comment #16 from iains at gcc dot gnu dot org 2010-05-18 01:40 ---
the patch below helps...
I also suspect we might have to check for emutls vars twice - because they can
be introduced by profiling code
just for the sake of a trial - I've put the emutls_final into toplev.c twice:
Consider this file:
#include stdio.h
int x = 1;
int main ()
{
asm goto (decl %0; jnz %l[a] :: m(x) : memory : a);
printf (Hello world\n);
a:
return 0;
}
It compiles and links correctly without LTO.
But with LTO, gcc-4.5.0 -flto a.c, there is an error:
In file included from :0:0:
On Linux/ia32, revision 159516 gave:
FAIL: gcc.dg/tree-ssa/prefetch-6.c scan-assembler-times prefetcht 5
FAIL: gcc.dg/tree-ssa/prefetch-6.c scan-tree-dump-times aprefetch Issued
prefetch 5
FAIL: gcc.dg/tree-ssa/prefetch-7.c scan-assembler-times mfence 2
FAIL: gcc.dg/tree-ssa/prefetch-7.c
This is a stripped down code from proposed Boost.Move library. Asserts don't
fire with -O0 and -O1 but do with -O2 and -O3
#include assert.h
template class T
class rv : public T
{
rv();
~rv();
rv(rv const);
void operator=(rv const);
};
template class T
rvT move(T x)
{
return
This is a stripped down code from proposed Boost.Move library. Asserts don't
fire with -O0 and -O1 but do with -O2 and -O3
#include assert.h
template class T
class rv : public T
{
rv();
~rv();
rv(rv const);
void operator=(rv const);
};
template class T
rvT move(T x)
{
return
Sent from my iPhone
On May 17, 2010, at 8:37 PM, eyakubovich at gmail dot com gcc-bugzi...@gcc.gnu.org
wrote:
This is a stripped down code from proposed Boost.Move library.
Asserts don't
fire with -O0 and -O1 but do with -O2 and -O3
#include assert.h
template class T
class rv : public
--- Comment #1 from pinskia at gmail dot com 2010-05-18 03:50 ---
Subject: Re: New: Wrong code generated with -O2 and above
Sent from my iPhone
On May 17, 2010, at 8:37 PM, eyakubovich at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
This is a stripped down code from proposed
101 - 135 of 135 matches
Mail list logo
