--- 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
36 matches
Mail list logo
