Adam Nemet ane...@caviumnetworks.com writes:
I am not exactly sure what has exposed this but the bug seems to be old.
can_throw_external in except.c does not look at the branch delay slot (second
entry in a SEQUENCE) to determine whether the insn may throw or not.
In gcc.dg/cleanup-8.c for
Ben Elliston wrote:
Try using -ftime-report.
thanks, that was what I had in mind.
The largest difference seems to be in tree STMT verifier (36% runtime
increase), a few others increased slightly, most seem to be nearly
identical. (This distribution could be an artifact of my example code, of
Paolo,
bootstrap finished OK on alpha, regression test results are at [1].
There are unrelated errors with random libc++ tests and HJ's PR39323
testcase. Do not mind the timeouts.
Great -- my testsuite comparison also finished with not a single
difference, which is good.
Paolo
I wonder what this exception in VRP looks like?
I wasn't specifically referring to an exception in VRP. I think that, when
checks are off, it would be sufficient for gigi to emit sort of assertions
for arguments on function entry (like your VRP patch did) and for return
values on function
Curious. I ran both g++ variants in oprofile, and then compared the
generated assembler code for the most critical functions.
The top 1 function in both cases is pointer_set_insert, and there the
assembler code is 100% identical (module one choice between r14 and r15).
The second most critical
On Sun, Apr 12, 2009 at 9:37 AM, Eric Botcazou ebotca...@adacore.com wrote:
I wonder what this exception in VRP looks like?
I wasn't specifically referring to an exception in VRP. I think that, when
checks are off, it would be sufficient for gigi to emit sort of assertions
for arguments on
On Sun, Apr 12, 2009 at 9:56 AM, Thomas Neumann
tneum...@users.sourceforge.net wrote:
Curious. I ran both g++ variants in oprofile, and then compared the
generated assembler code for the most critical functions.
The top 1 function in both cases is pointer_set_insert, and there the
assembler
Picking up an old thread,
http://gcc.gnu.org/ml/gcc/2003-03/msg00281.html
On Tue, 4 Mar 2003, Geert Bosch bosch at gnat dot com wrote:
[...]
Best would be to first post a design overview,
before doing a lot of work in order to prevent spending time
on implementing something that may turn out
The same tests now fail on hppa. This is PR 39651. I'm fairly certain
this was introduced by the following change:
2009-03-28 Jan Hubicka j...@suse.cz
Merge from pretty-ipa:
2009-03-27 Jan Hubicka j...@suse.cz
* cgraph.c (dump_cgraph_node): Add replace output flag
John David Anglin writes:
The same tests now fail on hppa. This is PR 39651. I'm fairly certain
this was introduced by the following change:
I put this PR in the checkin that was just approved on gcc-patc...@. Please
close the bug if it fixes the failures on hppa too.
Adam
Yes, we could do that. Though a simpler form may be preferable, like
directly specifying a constant range/anti-range instead of encoding these
in (multiple) ASSERT_EXPRs.
I will think of something.
Thanks.
As for Ada - both function entry and exit constraints will be checked by
the
Snapshot gcc-4.3-20090412 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090412/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
--- Comment #4 from dominiq at lps dot ens dot fr 2009-04-12 08:14 ---
Since this PR did not received any attention and seems fixed at least on 4.4
and trunk, if nobody complains in the coming days I'll close it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35012
--- Comment #13 from dominiq at lps dot ens dot fr 2009-04-12 08:17 ---
Is comment #11 still true?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34780
--- Comment #4 from css20 at mail dot ru 2009-04-12 08:50 ---
First tests of Win64 compiler.. simple source file test.c was created:
#include windows.h
int main(int argc, char **argv)
{
MessageBox(NULL, test, test, MB_OK);
}
E:\temp\testgcc test.c
gcc: CreateProcess: No such file
--- Comment #2 from mikpe at it dot uu dot se 2009-04-12 09:11 ---
(In reply to comment #1)
There is no undefined behavior here (increment of a short value converts
to int, increments then converts back to short, none of which are
undefined), so at least the wrong code issue would
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-04-12 09:31
---
Because it overruns the stack (ulimit -s).
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from edwintorok at gmail dot com 2009-04-12 09:32 ---
(In reply to comment #2)
(In reply to comment #1)
There is no undefined behavior here (increment of a short value converts
to int, increments then converts back to short, none of which are
undefined), so at
Compile the following code without any optimizations:
#include stdio.h
int main(int argc, char *argv[])
{
char a[900];
printf(gcc is wonderful\n);
}
like gcc test.c -o test.o
./test
Segmentation fault
Is it a bug? Can anyone give an insight why such a code segfaults?
--
I just tried to compile the following code
void f( int, ...);
struct S
{
};
void
g()
{
void f( int, ...);
S t;
f( 1, t);
}
void
f( int i, ...)
{
}
with GNU C compiler version 4.5 snapshot 20090409
and the compiler said
jul17c.cc: In function 'void g()':
--- Comment #6 from kurt at roeckx dot be 2009-04-12 13:42 ---
Comparing the results between Debian version 4.3.3-5 and 4.3.3-7+patch, I see:
=== g++ tests ===
Running target unix
+FAIL: g++.dg/ext/cleanup-10.C execution test
+FAIL: g++.dg/ext/cleanup-11.C execution
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-12 15:41 ---
This is caused by revision 145709:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00331.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #2 from schwab at linux-m68k dot org 2009-04-12 16:22 ---
No answer in 5 months, assuming fixed.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #7 from ubizjak at gmail dot com 2009-04-12 18:22 ---
(In reply to comment #6)
Comparing the results between Debian version 4.3.3-5 and 4.3.3-7+patch, I see:
=== g++ tests ===
Running target unix
+FAIL: g++.dg/ext/cleanup-10.C execution test
+FAIL:
VIEW_CONVERT_EXPR T(a.b.c.d).e.f.g.h
should be canonicalized to strip zero-offset and same size as T component
references off the VIEW_CONVERT_EXPR argument. The same should be applied
to component references of the VIEW_CONVERT_EXPR result by adjusting the
type T the VIEW_CONVERT_EXPR converts
--- Comment #6 from danglin at gcc dot gnu dot org 2009-04-12 18:43 ---
This is fixed in my builds. Steve, if this is still a problem,
you can reopen.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from uros at gcc dot gnu dot org 2009-04-12 18:55 ---
Subject: Bug 39740
Author: uros
Date: Sun Apr 12 18:55:25 2009
New Revision: 145985
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145985
Log:
2009-04-12 Uros Bizjak ubiz...@gmail.com
PR target/39740
--- Comment #9 from ubizjak at gmail dot com 2009-04-12 19:00 ---
Fixed on mainline for now.
--
ubizjak at gmail dot com changed:
What|Removed |Added
GCC target triplet|
This test case comes from the gdtoa library. The problem is reduced to a simple
test-case. Wrong code is produced for optimization levels higher or equal to 2.
--
Summary: Wrong code by = -O2 for pre-initialized variable and
casted access
Product: gcc
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-04-12 19:20 ---
Created an attachment (id=17623)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17623action=view)
testcase
Reduced testcase for showing the issue
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39745
--- Comment #5 from css20 at mail dot ru 2009-04-12 19:35 ---
I see this bug in compiler driver is already known
(http://sourceforge.net/forum/forum.php?thread_id=3091795forum_id=723797), it
works only with -O0. I can't found report about this bug in database.. does
it exists ?
Well,
--- Comment #1 from nemet at gcc dot gnu dot org 2009-04-12 19:37 ---
Subject: Bug 39651
Author: nemet
Date: Sun Apr 12 19:36:50 2009
New Revision: 145986
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145986
Log:
PR middle-end/39651
* except.c
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/libgomp/testsuite/libgomp.c++/pr34513.C
-B/test/gnu/gcc/objdir/h
ppa64-hp-hpux11.11/./libgomp/
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgo
mp -I/test/gnu/gcc/gcc/libgomp/testsuite/..
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-12 19:45 ---
You are violating C aliasing rules.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-04-12 19:49 ---
(In reply to comment #5)
I see this bug in compiler driver is already known
(http://sourceforge.net/forum/forum.php?thread_id=3091795forum_id=723797), it
works only with -O0. I can't found report about this bug in
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-12 20:01 ---
More to the point:
double d = 0.0; /* Reasons the issue. */
((U*)d)-iv[1] = b[1];
((U*)d)-iv[0] = b[0];
You are accessing a double as an int which violates C/C++ aliasing rules.
--
pinskia at gcc dot
--- Comment #4 from mikpe at it dot uu dot se 2009-04-12 21:33 ---
(In reply to comment #3)
(In reply to comment #2)
(In reply to comment #1)
There is no undefined behavior here (increment of a short value converts
to int, increments then converts back to short, none of which
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-04-12 22:20 ---
Subject: Bug 31869
Author: jsm28
Date: Sun Apr 12 22:20:02 2009
New Revision: 145989
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145989
Log:
libcpp:
PR preprocessor/31869
* macro.c
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-04-12 22:23 ---
Fixed for 4.5.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #13 from steven at gcc dot gnu dot org 2009-04-12 23:46 ---
The real bug is that somehow MEM_ATTRS are not shared anymore. We have lots
and lots of exactly the same expression in the table, e.g.:
Index 3 (hash value 4232)
(mem/s/f/c:SI (plus:SI (reg/f:SI 20 frame)
--- Comment #14 from steven at gcc dot gnu dot org 2009-04-12 23:52 ---
Ah, how subtle.
(gdb) p MEM_ATTRS(x)
$25 = (mem_attrs *) 0x7f20d1ad0440
(gdb) p MEM_ATTRS(y)
$26 = (mem_attrs *) 0x7f20d1ad71a0
(gdb) p MEM_ATTRS(*x)
$27 = (mem_attrs *) 0x7f20d1ad0440
(gdb) p MEM_ATTRS(*y)
$28 =
--- Comment #2 from jason at gcc dot gnu dot org 2009-04-13 04:05 ---
Subject: Bug 39742
Author: jason
Date: Mon Apr 13 04:04:58 2009
New Revision: 145994
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145994
Log:
PR c++/39742
* call.c (joust): Don't crash on
--- Comment #3 from jason at gcc dot gnu dot org 2009-04-13 04:20 ---
Subject: Bug 39742
Author: jason
Date: Mon Apr 13 04:20:32 2009
New Revision: 145995
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145995
Log:
PR c++/39742
* call.c (joust): Don't crash on
--- Comment #4 from jason at gcc dot gnu dot org 2009-04-13 04:28 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from MR dot Swami dot Reddy at nsc dot com 2009-04-13 05:09
---
NOTE-1: This problem seen with gcc-4.4 and gcc-4.5 (ie trunk) sources
built crx-elf-gcc compiler.
NOTE-2: With -O2 -funroll-all-loops options also reproduce this problem.
--
I compiled GMP as a static library only on darwin.
So when compiling the trunk or the 4.4 branch on powerpc-darwin, I get:
/usr/bin/ld: /usr/local/lib/libgmp.a(popcount.o) has local relocation entries
in non-writable section (__TEXT,__text)
This started to happen between 134948 and 144367.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-13 05:34 ---
So it looks like GMP is needed now as a target library for libgcj to work and
this is not documented anywhere I think.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
48 matches
Mail list logo
