--- Comment #15 from hp at gcc dot gnu dot org 2008-05-10 06:59 ---
(In reply to comment #14)
If there is no CONST wrapping the difference of symbols, does the CRIS port
continue to believe the address is legitimate?
As I said, for the failure on CRIS, it's not passed as an
--- Comment #8 from aurelien at aurel32 dot net 2008-05-10 08:28 ---
I confirm that those patches actually fix the problem on ARM oldabi, so the
problem is *not* fixed in the gcc 4.3 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
--- Comment #9 from tbm at gcc dot gnu dot org 2008-05-10 08:34 ---
Seems like we should reopen this bug then.
Aurelien, how big are those patches you're talking about? Are they aimed at
4.3 or only or 4.4?
--
tbm at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from tbm at gcc dot gnu dot org 2008-05-10 08:35 ---
Also confirm the bug.
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
/data03/vondele/clean/cp2k/src/../src/d3_poly.F: In function
init_d3_poly_module:
/data03/vondele/clean/cp2k/src/../src/d3_poly.F:68: internal compiler error:
tree check: expected integer_cst, have mult_expr in int_cst_value, at
tree.c:8002
after the fix for PR36129, gfortran ([trunk revision
--- Comment #1 from jv244 at cam dot ac dot uk 2008-05-10 08:44 ---
Created an attachment (id=15624)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15624action=view)
all files needed to reproduce and a README with the command
all files needed to reproduce and a README with the
--- Comment #14 from jv244 at cam dot ac dot uk 2008-05-10 08:46 ---
(In reply to comment #13)
Fixed for 4.4, patch needs to be backported to 4.3 branch.
thanks for the patch, testing it, I ran into another ICE (PR36198) before
reaching the crucial point.
--
--- Comment #11 from aurelien at aurel32 dot net 2008-05-10 09:09 ---
About 20kB in total:
-rw-r--r-- 1 aurel32 aurel32 3975 May 9 15:15 armel-hilo-union-class.dpatch
-rw-r--r-- 1 aurel32 aurel32 15153 May 9 15:15 gfortran-armel-updates.dpatch
-rw-r--r-- 1 aurel32 aurel32 11092 May
--- Comment #2 from jv244 at cam dot ac dot uk 2008-05-10 10:03 ---
backtrace
#0 internal_error (gmsgid=0xc2d800 tree check: %s, have %s in %s, at %s:%d)
at /data03/vondele/gcc_trunk/gcc/gcc/diagnostic.c:594
#1 0x008a284e in tree_check_failed (node=0x2b6a9f6ec4c0,
--- Comment #9 from ubizjak at gmail dot com 2008-05-10 11:21 ---
Current 4.3.1 branch doesn't generate memset with zero length anymore.
Closed as WORKSFORME, but if still fails, please reopen and attach new *.i,
*.gcda and *.gcno files, produced with latest SVN HEAD versions of the
--- Comment #23 from rsandifo at gcc dot gnu dot org 2008-05-10 12:01
---
Subject: Bug 33642
Author: rsandifo
Date: Sat May 10 12:00:37 2008
New Revision: 135142
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135142
Log:
gcc/testsuite/
PR rtl-optimization/33642
*
--- Comment #24 from rsandifo at gcc dot gnu dot org 2008-05-10 12:03
---
As per the last message, I've skipped these tests for MIPS
until the PR is fixed.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-05-10 12:16
---
With current trunk, I see current mainline gfortran being 5% faster than Intel
10.0 on a Dual-Core AMD Opteron(tm) Processor 2212 at 2GHz. Joost, on your
particular setup, does this still run too slow?
--
--- Comment #7 from jv244 at cam dot ac dot uk 2008-05-10 12:30 ---
(In reply to comment #6)
With current trunk, I see current mainline gfortran being 5% faster than Intel
10.0 on a Dual-Core AMD Opteron(tm) Processor 2212 at 2GHz. Joost, on your
particular setup, does this still run
--- Comment #3 from ubizjak at gmail dot com 2008-05-10 12:36 ---
This is what goes into int_cst_value:
#2 0x008a60c8 in int_cst_value (x=0x2e72a4c0) at
../../gcc-svn/trunk/gcc/tree.c:8002
8002 unsigned HOST_WIDE_INT val = TREE_INT_CST_LOW (x);
(gdb) p
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-10 12:58 ---
That looks more like a fallout from:
2008-05-09 Jan Sjodin [EMAIL PROTECTED]
Sebastian Pop [EMAIL PROTECTED]
* tree-scalar-evolution.c: Document instantiate_scev.
--- Comment #8 from jv244 at cam dot ac dot uk 2008-05-10 13:43 ---
(In reply to comment #7)
This is, however, with gfortran 4.3.0.
Trunk is marginally faster than 4.3.0, still about 20% slower than ifort
Kernel time 4.5042820
--
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-05-10 15:03
---
Though I do not get segfault, I can confirm valgrind errors.
==3660== 158 bytes in 1 blocks are definitely lost in loss record 3 of 9
==3660==at 0x4A04D1F: calloc (vg_replace_malloc.c:279)
==3660==by
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-05-10 15:12
---
Passes with -m32 and -m64 on x86-64-linux. May be i686 specific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36197
--- Comment #2 from hjl dot tools at gmail dot com 2008-05-10 15:31 ---
Can you run valgrind on f951?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36197
--- Comment #3 from hjl dot tools at gmail dot com 2008-05-10 15:36 ---
The bug is in quote_string:
/* Calculate the length we'll need: a backslash takes two (\\),
non-printable characters take 10 (\U) and others take 1. */
for (p = s, i = 0; i slength; p++, i++)
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-05-10 16:02
---
(In reply to comment #3)
else if (!gfc_wide_is_printable (*p))
{
sprintf (q, \\U%08 HOST_WIDE_INT_PRINT ux,
(unsigned HOST_WIDE_INT) *p);
q += 10;
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-05-10 16:18
---
(In reply to comment #4)
Now, there is a another problem in that we shouldn't have this wide char in
the
first place.
I take that back, the wide char (a non-breaking space) is in the source file,
so it's OK
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-05-10 16:40
---
Subject: Bug 36197
Author: fxcoudert
Date: Sat May 10 16:39:27 2008
New Revision: 135154
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135154
Log:
PR fortran/36197
* module.c
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2008-05-10 16:41
---
Fixed my mess.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
The following short testcase (reduced from gfortran.dg/fmt_zero_precision.f90):
write(*,200) 37.9
200 format(es8.0,)
end
ouputs 3.E+01 instead of 4.E+01. This happens on both i686-pc-mingw32
and x86_64-pc-mingw32.
--
Summary: [mingw] Wrong rounding in floating-point
--- Comment #1 from dominiq at lps dot ens dot fr 2008-05-10 19:32 ---
get 4.E+01 on darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36200
Testcase:
#define SIZE 1024
While looking into why manually SRA'd testcase worked better. I found this
interesting problem.
Take:
struct a
{
long long b;
a();
};
a f(a g, a h)
{
int i;
a res = g;
for (i = 0; i SIZE; i++)
res.b += h.b;
return res;
}
at -O2 we change res here to
--- Comment #4 from zadeck at gcc dot gnu dot org 2008-05-10 20:29 ---
Subject: Bug 36185
Author: zadeck
Date: Sat May 10 20:28:19 2008
New Revision: 135159
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135159
Log:
2008-05-10 Kenneth Zadeck [EMAIL PROTECTED]
* gcse.c
--- Comment #5 from zadeck at naturalbridge dot com 2008-05-10 20:29
---
Subject: Re: [4.4 Regression] wrong code with -O2 -fgcse-sm
rguenth at gcc dot gnu dot org wrote:
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-09 15:04
---
Kenny, that's your
--- Comment #6 from zadeck at naturalbridge dot com 2008-05-10 21:27
---
fixed with commit of patch.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
gfortran.dg/namelist_44.f90 fails on mingw (both 32-bit and 64-bit) due to a
bug in namelist reading, which can be reduced to:
program gfcbug77
implicit none
character(len=128) :: file =
logical:: default
namelist /BLACKLIST/ file, default
integer, parameter :: nnml = 10
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target
BEGIN_TESTCASE
#include iostream
using namespace std;
class C {
public:
templateint V int f();
};
template int C::f0() { return 10; }
template int C::f1() { return 11; }
templateclass TC, int V
class Cx {
public:
int fx(TC*);
};
templateclass TC, int V int CxTC, V::fx(TC* tc) { return
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-10 23:01 ---
This is not a bug:
templateclass TC, int V int CxTC, V::fx(TC* tc) { return tc-fV(); }
You frogot the template keyword. That is the above should be:
templateclass TC, int V int CxTC, V::fx(TC* tc) { return
--- Comment #2 from starlight at binnacle dot cx 2008-05-10 23:41 ---
This was more of a learning experience than a forgetting and
remembering one. Thank you for the help.
Several template behaviors required by a strict ISO standard
reading are miles distant from intuition. This
;
for (i = 0; i 1024*1024; i++)
{
p[0] = 1;
}
if (p[0] != 1)
link_error ();
return 0;
}
GNU C (GCC) version 4.4.0 20080304 (experimental) [trunk revision 132852]
(i386-apple-darwin8.10.1)
Worked but:
GNU C (GCC) version 4.4.0 20080510 (experimental) [trunk revision
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36204
--- Comment #3 from starlight at binnacle dot cx 2008-05-10 23:54 ---
Now that I'm fixing the -template f() member references in
the code it's obvious this one is just a much of a hemorrhoidal
pain as the scope rule resolution. It deserves a command switch
for turning off the strict
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-10 23:57 ---
-fdisable-non-intuitive-template-behavior-that-serves-no-real-purpose
It is hard to figure out just from the context of the sources that it is going
to be a template or not in some cases. Guessing makes it
--- Comment #5 from starlight at binnacle dot cx 2008-05-11 00:08 ---
Yet Sun, IBM and Microsoft all somehow manage it.
Now what was once a clean, elegant and easy to read
function is a hideous hairball template function.
I've become so frustrated with C++ generics over the last
--- Comment #1 from kkojima at gcc dot gnu dot org 2008-05-11 00:10 ---
Kenny made me notice that julian proposed a patch for ARM which
had similar failures for foward-1.m. Although it turned out
that the cause of failure on SH is different from that on ARM,
his analysis helps to see
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-11 00:17 ---
Lim is no longer doing this which means this is most likely caused by the LIM
aliasing oracle patch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-11 00:53 ---
Note if we have the following source:
void link_error();
int foo(int n, int * p)
{
int i = 0;
p[0] = 0;
for (i = 0; i 1024*1024; i++)
{
p[0]++;
}
if (p[0] != 1024*1024)
link_error ();
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-11 00:54 ---
I think this bit did it:
(movement_possibility): Do not allow moving statements
that store to memory.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-11 01:06 ---
(In reply to comment #3)
I think this bit did it:
(movement_possibility): Do not allow moving statements
that store to memory.
Yes reverting this part of the patch fixes the regression.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-11 01:35 ---
Reverting that part of the patch causes an ICE with the following code:
struct BUF1
{
int b1;
int b12;
};
void link_error();
int foo(int n, struct BUF1 * p)
{
int i = 0;
for (i = 0; i 1024*1024;
--- Comment #6 from bangerth at dealii dot org 2008-05-11 02:17 ---
(In reply to comment #5)
Yet Sun, IBM and Microsoft all somehow manage it.
But which function do they take in this case:
--
void f();
template typename T struct B
{
void f();
};
template typename T
--- Comment #7 from starlight at binnacle dot cx 2008-05-11 02:42 ---
That little bit of ambiguity bothers me a lot less that writing
55,000 freaking 'using' statements, which is what I've had to do
for several years now.
In the real world nobody except idiots name their functions
--- Comment #8 from bangerth at dealii dot org 2008-05-11 02:59 ---
(In reply to comment #7)
That little bit of ambiguity bothers me a lot less that [...]
If that's your opinion, then you've never worked with large
software systems. Writing a few this- here and there because the
--- Comment #13 from aaronavay62 at aaronwl dot com 2008-05-11 03:04
---
What would be an acceptable solution other than having bootstrap perpetually
broken, and other than --disable-werror?
1) We could only enable this warning when in strict mode, eg -std=c99
-pedantic. -std=gnu99
--- Comment #9 from starlight at binnacle dot cx 2008-05-11 03:14 ---
You're speaking of large systems of code written by bad
programmers, who by definition should never be let anywhere near
C++. Let them write Java and C#, languages that were designed
specifically for bad
--- Comment #10 from starlight at binnacle dot cx 2008-05-11 03:29 ---
Oh, and let's not forget about the millions of lines of C++ code
written for the Windows platform that will *never* be ported to
Linux. How's that for a domain of large software systems? If
that scary old
--- Comment #11 from bangerth at dealii dot org 2008-05-11 03:32 ---
(In reply to comment #10)
VC6,7,8,9
I suppose that's the compiler you should use then.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
--- Comment #12 from starlight at binnacle dot cx 2008-05-11 03:36 ---
It could happen. All of our new customers for the
last two years run Windows, not Linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
--- Comment #14 from aaronavay62 at aaronwl dot com 2008-05-11 04:48
---
Another question: why does lld not cause warnings on linux here? I don't see
what the difference is. Whatever the situation is, I don't see any reason that
I64d should behave differently from lld in gnu89 mode.
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-05-11 05:19
---
Works OK on Cygwin
4.E+01
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36200
-version-specific-runtime-libs --enable-nls
--disable-libmudflap --disable-shared --disable-win32-registry
--with-system-zlib --enable-checking=release --enable-werror
--without-included-gettext --without-x --enable-libgomp
Thread model: posix
gcc version 4.4.0 20080510 (experimental) [trunk revision
59 matches
Mail list logo
