--- Comment #3 from grosser at gcc dot gnu dot org 2009-11-21 08:32 ---
Li,
Is this bug solved with a newer cloog version?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41924
Compilation with only graphite-identity fails:
-O3 -fno-loop-interchange -fno-loop-block -fno-loop-strip-mine
--
Running 447.dealII train base amd64-m64-gcc43-nn default
/home/grosser/spec/bin/specinvoke -d
--- Comment #1 from grosser at gcc dot gnu dot org 2009-11-21 08:50 ---
Created an attachment (id=19071)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19071action=view)
Small C++ testcase showing the same behavior
-O2 -fno-tree-ch are required options
Fails on execution
--- Comment #5 from codemasterhs at yahoo dot de 2009-11-21 09:02 ---
(In reply to comment #4)
The pointer is not declared volatile.
static struct smpMsg_t * volatile freeList;
would be a volatile pointer.
Ok, this worked. So where has to be the volatile keyword, so that
--- Comment #4 from spop at gcc dot gnu dot org 2009-11-21 09:04 ---
Yes, this should be fixed now in the Graphite branch, and it will be fixed in
trunk after the merge that I am preparing.
Sebastian
--
spop at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from spop at gcc dot gnu dot org 2009-11-21 09:09 ---
My automatic testers are still failing one of the aermod tests,
see for example pb05.sum from:
http://groups.google.com/group/gcc-graphite-test/browse_thread/thread/4afb9c19aa8a10c7
--
spop at gcc dot gnu dot org
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-11-21 09:12
---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-11-21 09:13
---
Mark this as fixed for 4.5:
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended%20asm%20with%20gotoAs
of GCC version 4.5, asm goto may be used to have the assembly jump to one or
more C labels. In this
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-21 09:15 ---
*** This bug has been marked as a duplicate of 37195 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-11-21 09:15 ---
*** Bug 41294 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37195
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-11-21 10:56
---
This is a known problem, but I'm not going to fix it. The difficulty is that
it will break object compatibility for a large number of users upgrading from
older versions of the compiler (the attributes will
--- Comment #5 from ltuikov at yahoo dot com 2009-11-21 11:25 ---
Also observed with gcc 4.4.2.
--
ltuikov at yahoo dot com changed:
What|Removed |Added
--- Comment #6 from ltuikov at yahoo dot com 2009-11-21 11:31 ---
Compiling gcc 4.4.2 cross compiler for ARC gives ICE, unrecognizable insn:
[lu...@localhost libgcc]$/home/luben/ware/gcc-4.4.2-arc-build/./gcc/xgcc -v
-sav
e-temps -B/home/luben/ware/gcc-4.4.2-arc-build/./gcc/
--- Comment #7 from ltuikov at yahoo dot com 2009-11-21 11:34 ---
Created an attachment (id=19072)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19072action=view)
Preprocessed source code
ICE compiling a cross compiler for ARC with gcc 4.4.2.
--
ltuikov at yahoo dot com
--- Comment #8 from ltuikov at yahoo dot com 2009-11-21 11:35 ---
Created an attachment (id=19073)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19073action=view)
Assembly output
ICE compiling a cross compiler for ARC with gcc 4.4.2.
--
ltuikov at yahoo dot com changed:
--- Comment #12 from mexas at bristol dot ac dot uk 2009-11-21 11:47
---
I see..
So what is the way forward?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
--- Comment #9 from ltuikov at yahoo dot com 2009-11-21 12:01 ---
The ICE is generated when cross-compiling libgcc2.c at line 547.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
--- Comment #15 from toon at moene dot org 2009-11-21 12:11 ---
I don't see that the standard suggests the specific code the Frontend
generates. In fact it should be valid to increment the DO variable
by m3 and express the exit test in terms of the DO variable as well.
The Standard
--- Comment #16 from rguenther at suse dot de 2009-11-21 12:19 ---
Subject: Re: [4.4/4.5 Regression] Vectorizer
cannot deal with PAREN_EXPR gracefully, 50% performance regression
On Sat, 21 Nov 2009, toon at moene dot org wrote:
--- Comment #15 from toon at moene dot org
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se
2009-11-21 12:24 ---
Created an attachment (id=19074)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19074action=view)
Test case - g++ -Wignored-qualifiers test.C gives confusing results
In C++ it becomes even
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-11-21
13:40 ---
This maybe related to r154291 (tree-optimize.c (execute_fixup_cfg): Rescale
frequencies.) Counts are not rescaled for entry block and exit block. Then in
counts_to_freqs(), their frequencies become very
Split out from PR42108.
The loop is not unrolled because the frontend presents us with very funny
obfuscated code:
do k=i,nnd,n
temp=temp+(x(k)-x(k+jmini))**2
end do
gets translated to
{
character(kind=4) countm1.6;
integer(kind=4) D.1551;
integer(kind=4) D.1550;
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-11-21 13:58
---
I have filed PR42131 for the DO loop translation issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #4 from tlesher at digium dot com 2009-11-21 14:05 ---
(In reply to comment #3)
(In reply to comment #2)
I've also confirmed that using the 'may_alias' attribute in the 64-bit
version
suppresses the warning, although I think this qualifies as a workaround,
not a
/14/jwakely/gcc/4.x
--with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4
--enable-libstdcxx-time=rt --enable-languages=c,c++ --disable-bootstrap
Thread model: posix
gcc version 4.5.0 20091121 (experimental) (GCC)
The problem is that overload resolution for b.call() causes result_ofcv
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2009-11-21 15:06
---
Test and now passes for avr and m32 targets.
gcc.dg/utf32-1.c
gcc.dg/utf32-2.c
gcc.dg/utf32-3.c
I will remove XFAIL in cleanup patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36470
--- Comment #7 from mattst88 at gmail dot com 2009-11-21 16:15 ---
I can confirm that the attached patch fixes the issue. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
#include stdio.h
int main(int argc, char *argv[])
{
int click;
click++;
printf(click is %d \n,click);
return 0;
}
compile and execute:
test $: g++ -o gccbug gccbug.cpp
test $: ./gccbug
click is 1
In this case click is set to zero. When I found this bug in
a more complex program
--- Comment #1 from kornelix at yahoo dot de 2009-11-21 16:21 ---
Sorry, -Wall will indeed trigger a diagnostic.
Please erase this report.
Mike
--
kornelix at yahoo dot de changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2009-11-21 16:26 ---
(In reply to comment #0)
To illustrate this with a simple example:
DO I = M1, M2, M3
B(I) = A(I)
ENDDO
would be most easily, and atraightforwardly, implemented as follows:
IF (M3 0 .AND. M1 M2)
--- Comment #2 from cppljevans at suddenlink dot net 2009-11-21 16:46
---
Created an attachment (id=19075)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19075action=view)
zip archive with test case and Makefile and compile output
The recently attached .zip file contains:
M
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-21 17:29 ---
static inline void put_unaligned_uint64(void *p, uint64_t datum)
{
struct { uint64_t d; } __attribute__((packed)) *pp = p;
pp-d = datum;
}
int iax_ie_append_versioned_uint64(struct iax_ie_data
--- Comment #2 from toon at moene dot org 2009-11-21 17:33 ---
Sorry, Steve - my mistake.
The original message should have been:
To illustrate this with a simple example:
DO I = M1, M2, M3
B(I) = A(I)
ENDDO
would be most easily, and straightforwardly, implemented as follows:
--- Comment #2 from b3timmons at speedymail dot org 2009-11-21 17:37
---
(In reply to comment #0)
GCC 4.5.0 20091119 (r154346)
../../gcc-4.5/gcc/gengtype-parse.c: In function
âarray_and_function_declarators_optâ:
../../gcc-4.5/gcc/gengtype-parse.c:508:1: error:
--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-11-21 18:31 ---
(In reply to comment #2)
Sorry, Steve - my mistake.
The original message should have been:
To illustrate this with a simple example:
DO I = M1, M2, M3
B(I) = A(I)
ENDDO
would be most easily, and
--- Comment #3 from hubicka at ucw dot cz 2009-11-21 18:54 ---
Subject: Re: Verify_flow_info: Wrong frequency of block. Profiled bootstrap
failed.
--- Comment #2 from b3timmons at speedymail dot org 2009-11-21 17:37
---
(In reply to comment #0)
GCC 4.5.0 20091119
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org
--- Comment #9 from aoliva at gcc dot gnu dot org 2009-11-21 19:12 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-21 19:16
---
This works with 4.4.x and current mainline.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-21 19:24 ---
The middle-end prefers do { } while () loop style so it knows the loop is
always executed. It even tries to transform other loop forms into this by
copying the loop header. So if the FE already can cheaply produce
--- Comment #4 from dominiq at lps dot ens dot fr 2009-11-21 20:46 ---
This PR and PR42119 are fixed by the patch in comment #1 of PR42119 without
regression. It also fixes the test in comment #7 pf PR34199.
As far as I can understand the comment
/* ??? This should be considered a
Since revision 150792, the test libgomp.graphite/force-parallel-2.c (introduced
in revision 150755) fails on *-apple-darwin9. AFAICT the array x[1][1]
is allocated in stack and is too big for the 64Mb hard limit on darwin. One
solution could be to replace 1 with 4000. Also the
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-21 21:11
---
No excuses, just use --permissive! ;) Seriously, it would be nice if Jason
could confirm this is glitch in the extended SFINAE implementation, which, in
case, could be relatively easy to fix, I suspect...
--
--- Comment #5 from toon at moene dot org 2009-11-21 21:40 ---
The middle-end prefers do { } while () loop style so it knows the loop is
always executed.
And the Fortran Standard describes the loops being built (by compilers) just
so:
1. First you determine what is m1, m2, m3
2.
--- Comment #2 from jason at gcc dot gnu dot org 2009-11-21 21:41 ---
Shouldn't SFINAE cause those invalid instantiations to be ignored, silently
removing the invalid overloads from the overload set, leaving just the one I'm
trying to call?
No, SFINAE only applies to function
--- Comment #3 from jason at gcc dot gnu dot org 2009-11-21 21:51 ---
14.9.2/8:
Only invalid types and expressions in the immediate context of the function
type and its template parameter types can result in a deduction failure. [
Note: The evaluation of the substituted types and
--- Comment #7 from hjl dot tools at gmail dot com 2009-11-21 22:08 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-21 22:08 ---
Actually, the decltype variant isn't a SFINAE issue either; SFINAE only applies
to function templates because it's part of deduction. For a simpler example:
template class T
struct A
{
void f (T::type);
};
Aint
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-11-21 22:15
---
Here is a tentative patch. I removed the offending code and ran the testsuite
to see what would happen. The only failure was the test case associated with
patch that caused the regression. This failure was an
Source:
typedef union u { unsigned i; unsigned short s[2]; unsigned char c[4]; } u;
char c[4] __attribute__((aligned));
short s[2] __attribute__((aligned));
int f1()
{
return ((union u*)s)-i;
}
int f2()
{
return ((union u*)c)-i;
}
Using gcc 4.5:
gcc -O3 -fstrict-aliasing
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-21 22:56 ---
!alias_sets_conflict_p (set1, set2) should really be alias_set_subset_of
with all the added false positives from the very imprecise frontend code
that this would cause.
Thus, the cast from short[] also should warn.
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-11-21 22:57 ---
Subject: Bug 42025
Author: jamborm
Date: Sat Nov 21 22:56:36 2009
New Revision: 154413
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154413
Log:
2009-11-21 Martin Jambor mjam...@suse.cz
PR
--- Comment #5 from paolo dot carlini at oracle dot com 2009-11-21 23:05
---
Thanks for the analysis, Jason.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-11-21 23:07 ---
Created an attachment (id=19076)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19076action=view)
proposed patch
This patch generates
D.1336 = m1;
D.1337 = m2;
D.1338 = m3;
i = D.1336;
if
--- Comment #7 from rguenther at suse dot de 2009-11-21 23:23 ---
Subject: Re: Weird translation of DO loops
On Sat, 21 Nov 2009, tkoenig at gcc dot gnu dot org wrote:
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-11-21 23:07
---
Created an attachment
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-11-21 23:42 ---
Subject: Re: Weird translation of DO loops
On Sat, 2009-11-21 at 23:23 +, rguenther at suse dot de wrote:
That's better.
Not yet correct, though, this causes regressions for
program main
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-11-21 23:43 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
error: expected constructor, destructor, or type conversion before { token
when compiling attached file from ppl sources with gcc 4.5.0 rev 154407
--
Summary: error: expected constructor, destructor, or type
conversion before { token
Product: gcc
--- Comment #1 from denis dot onischenko at gmail dot com 2009-11-21 23:45
---
Created an attachment (id=19077)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19077action=view)
preprocessed c++ source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42137
--- Comment #2 from denis dot onischenko at gmail dot com 2009-11-21 23:45
---
Created an attachment (id=19078)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19078action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42137
h8300-elf-gcc -mint32 -mh -O2 -fomit-frame-pointer -g test.c
test.c: In function 'sys_pwrite64':
test.c:19: internal compiler error: in
compute_frame_pointer_to_fb_displacement, at dwarf2out.c:12228
test.c
struct foo {
int foo;
};
struct foo *fget_light(int fd);
long sys_pwrite64(unsigned int
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2009-11-22 02:05
---
Subject: Bug 41807
Author: jvdelisle
Date: Sun Nov 22 02:05:12 2009
New Revision: 154419
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154419
Log:
2009-11-21 Jerry DeLisle jvdeli...@gcc.gnu.org
### Here's the output of compilation together with -v and -save-temps:
[eh...@germany src]$ /home/ehren/gcc-4.5/dist/bin/g++ -o jsxml.o -c
-I./../../dist/system_wrappers_js -include
/home/ehren/mozilla-central/js/src/config/gcc_hidden.h
-DOSTYPE=\Linux2.6.27.21-170.2.56.fc10\ -DOSARCH=Linux
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-11-22 02:06
---
Subject: Bug 41807
Author: jvdelisle
Date: Sun Nov 22 02:06:26 2009
New Revision: 154420
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154420
Log:
2009-11-21 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2009-11-22 02:10
---
Fixed on trunk. Note I inadvertently left off the PR number in the commit.
It was:
SendingChangeLog
Sendingresolve.c
Sendingtrans-const.c
Transmitting file data ...
Committed revision
--- Comment #1 from ehren dot m at gmail dot com 2009-11-22 02:10 ---
Created an attachment (id=19079)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19079action=view)
jsxml.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42139
I'm working on a small project to create an abstraction over directories
and archives. I've managed to write some code that seems simple enough
(using tagged limited types) and even though the code appears to be valid,
it seems to either trigger bugs in the runtime (causing crashes on execution)
--- Comment #1 from gcc at coreland dot ath dot cx 2009-11-22 05:27 ---
By causes a crash above, I meant that the generated code crashes at
the highlighted line.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42140
68 matches
Mail list logo
