--- 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
Status|U
/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 13
--- 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=15624&action=view)
all files needed to reproduce and a README with the command
all files needed to reproduce and a README with the com
--- 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.
--
http://gcc.gnu.org
--- 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 9
--- 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, file=0xc2d
--- 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
com
--- 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=gcc&view=rev&rev=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?
--
fxco
--- 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 r
--- 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 debug_generic_ex
--- 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.
(instantiate_par
--- 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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=310
--- 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 0xB3
--- 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 O
--- 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=gcc&view=rev&rev=135154
Log:
PR fortran/36197
* module.c (quote_strin
--- 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
Sta
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 floatin
--- 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=gcc&view=rev&rev=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 PURE/C
--- 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 recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target t
BEGIN_TESTCASE
#include
using namespace std;
class C {
public:
template int f();
};
template<> int C::f<0>() { return 10; }
template<> int C::f<1>() { return 11; }
template
class Cx {
public:
int fx(TC*);
};
template int Cx::fx(TC* tc) { return tc->f(); }
int main()
{
C c;
Cx* c0
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-10 23:01 ---
This is not a bug:
template int Cx::fx(TC* tc) { return tc->f(); }
You frogot the template keyword. That is the above should be:
template int Cx::fx(TC* tc) { return tc->template
f(); }
as tc is dependent, you n
--- 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 revis
--
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 st
--- 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 worse
--- 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
couple
--- 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 wh
--- 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 |A
--- 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; i+
--- 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 struct B
{
void f();
};
template struct D : B
{
vo
--- 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 'f'
--- 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
comp
--- 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 -p
--- 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 programmer
--- 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 ambigui
--- Comment #11 from bangerth at dealii dot org 2008-05-11 03:32 ---
(In reply to comment #10)
> VC<6,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 m
--- 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
58 matches
Mail list logo
