test.c:
#include stdio.h
#include sys/types.h
#include sys/shm.h
int main()
{
int i = 0;
int shmid[3];
void *addr[3];
for (i=0; i3; i++) {
shmid[i] = shmget(IPC_PRIVATE, 256*1024*1024ULL,
SHM_HUGETLB|IPC_CREAT|SHM_R|SHM_W);
if (shmid[i] 0) {
perror(shmget);
--- Comment #2 from pluto at agmk dot net 2006-06-28 08:56 ---
following testcase doesn't generate warning in 4.1.2svn.
3.3.6 works fine.
#include string
std::string const foo()
{
std::string tab[ 1 ] = { std::string( text ) };
int const idx = 0;
return tab[ idx
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-06-28
09:52 ---
The mingw runtime library now has a gettimeofday function which should give
resolution to usec. When libgfortran is configured with the latest mingw
runtime package, gettimeofday is found and used.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-28 11:13 ---
Can you try 4.0.3 or 4.1.1 as 3.4.x is no longer being maintained?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28185
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-28 11:15 ---
(In reply to comment #2)
That would almost mean as is being miscompiled on m68k.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-28 11:21 ---
(In reply to comment #0)
Sorry if it is ill-built bugreport, this is my first one.
This bug report was reported correctly and actually it is very useful.
Anyways confirmed, still a bug in 4.0.x, 4.1.x and the
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-28 12:11
---
On my system, I have the lastest mingw runtime (from the www.mingw.org download
page):
mingw-runtime-3.9.tar.gz341 kb Oct 27, 200517:10
and libgfortran configury does not find
[ i486 ]
gcc -O2 -fno-strict-aliasing -fwrapv -march=i486 -ggdb -DHAVE_POSIX_REGCOMP
-c -o fetch.o fetch.c
cc1: out of memory allocating 4064 bytes after a total of 1292098548 bytes
[ powerpc ]
gcc -O2 -fno-strict-aliasing -fwrapv -fsigned-char -ggdb -DHAVE_POSIX_REGCOMP
-c -o fetch.o
--- Comment #1 from pluto at agmk dot net 2006-06-28 12:46 ---
Created an attachment (id=11768)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11768action=view)
i486 precompiled testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28187
--- Comment #2 from pault at gcc dot gnu dot org 2006-06-28 13:22 ---
(In reply to comment #1)
John,
Have all these errors just appeared or do they go back to the era of
actual_array_constructor_1.f90; ie 04/04/06?
The reason that I ask is that I am wondering if this is an incipient
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-06-28 14:32
---
(In reply to comment #2)
mingw-runtime-3.9.tar.gz341 kb Oct 27, 200517:10
There was in fact a mingw-runtime-3.10 release, but it's not yet on the
appropriate mingw.org page (it's on
I'm building a shared library with libpthread and libmudflapth support.
Flags used to compile are: -fstack-protector -fmudflapth
Flags used to link are: -lmudflapth
When trying to dlopen the shared lib at runtime I get:
symbol lookup error: /home/melfar/gcc4/lib/libmudflapth.so.0: undefined
Between 20050805 and 20060208, many libjava execution tests started to time
out on Tru64 UNIX (both V4.0F and V5.1B), as can be seen comparing the
following test results:
http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00708.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00899.html
Compiling crtstuff.c with arm-elf-gcc 4.0.3 for -mthumb -fPIC
-msingle-pic-base fails. I had no trouble compiling GCC 4.1.1.
Cheers,
Shaun
make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc'
make GCC_FOR_TARGET=/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc
Since at least 20060503, libjava fails to bootstrap on IRIX 6.5.28:
/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/./gcc/xgcc -shared-libgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/mips-sgi-irix6.5/32/libstdc++-v3/src
Hi,
This looks like floating point rounding problem but it's not. Please review the
following testcase:
#include stdio.h
double func(double p) {
return 1.097986768 * 7654 / 4.5678913 + 1/p;
}
int main()
{
double PARAM = 3.0001;
double aVal = func(PARAM);
double bVal =
--- Comment #1 from rozenman at gmail dot com 2006-06-28 15:46 ---
Created an attachment (id=11769)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11769action=view)
Testcase program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28191
Compiling crtstuff.c with arm-elf-gcc 4.0.3 for -mthumb -fPIC
-msingle-pic-base fails. I had no trouble compiling GCC 4.1.1.
Cheers,
Shaun
make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc'
make GCC_FOR_TARGET=/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc
Execute-in-place (XIP) code, commonly used with uClinux, places the .text
section in flash and the .data section in RAM. GCC 4.1 emits R_ARM_GOTOFF32
relocations for symbols in the .text segment relative to the GOT, which is in
the .data segment. This new behaviours breaks XIP. See the following
--- Comment #25 from steven at gcc dot gnu dot org 2006-06-28 17:30 ---
Pure luck or not, this is a regression.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from sjackman at gmail dot com 2006-06-28 17:36 ---
Created an attachment (id=11772)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11772action=view)
Backport thumb_find_work_register from 4.1.1
2005-03-01 Nick Clifton [EMAIL PROTECTED]
* config/arm/arm.c
When shift count is the same as the length of a variable (eg, l 32 where
long int l;), this doesn't return 0, instead it returns a rotated value.
Below is assumed to return 0, but actually returns 2468.
---t2.c---(test case)
#include stdio.h
long long ll;
long l;
int
main(){
l = 1234;
ll
--- Comment #1 from falk at debian dot org 2006-06-28 17:57 ---
Shifting by an amount larger than the size of a type is undefined behavior,
so anything might happen. Gcc even warns about this.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #14 from jjcogliati-r1 at yahoo dot com 2006-06-28 18:02
---
This works in 4.1.0, so only 4.1.1 has this bug so far as I can tell.
--
jjcogliati-r1 at yahoo dot com changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-28 18:49 ---
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #82 from pinskia at gcc dot gnu dot org 2006-06-28 18:49
---
*** Bug 28191 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jason at gcc dot gnu dot org 2006-06-28 19:12 ---
Turns out to be a bug in alias grouping. Patch in testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27768
--- Comment #26 from whaley at cs dot utsa dot edu 2006-06-28 19:57 ---
Created an attachment (id=11773)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11773action=view)
raw runs table is generated from
As promised, here is the raw data I built the table out of, including a new run
--- Comment #2 from sjackman at gmail dot com 2006-06-28 20:18 ---
This proposed patch does help. At the very least, it prevents the ICE on
compiling crtstuff.c while compiling the toolchain. However, with this patch
applied, I saw the same bug later while compiling newlib. As the
The following code is miscompiled when using -m64 (=ppc64) target:
const static double a = 1.0;
const static double *b = (double*)a - 1;
b[1] should be a, but it's not - there is an additional offset of 0x1
--
Summary: miscompiled initialization of a constant pointer
--- Comment #1 from inbox at b-q-c dot com 2006-06-28 20:44 ---
Created an attachment (id=11774)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11774action=view)
test case - returns 0 on success or 1 when miscompiled
gcc -m64 -o gcc64bug gcc64bug.c
Inspection of the a and b will
--- Comment #2 from inbox at b-q-c dot com 2006-06-28 20:47 ---
The original description should state that there is an additional offset of
0x1 (it said 0x1 instead).
Also this bug is reproducible with earlier version of gcc such as 4.0.1 as
supplied by Apple.
--
--- Comment #3 from inbox at b-q-c dot com 2006-06-28 20:50 ---
Created an attachment (id=11775)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11775action=view)
output of gcc -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28196
--- Comment #3 from sjackman at gmail dot com 2006-06-28 20:51 ---
I tried backporting thumb_compute_save_reg_mask from GCC 4.1.1 to GCC 4.0.3
without success. I'll try backporting this entire patch from svn.
2005-03-01 Nick Clifton [EMAIL PROTECTED]
* config/arm/arm.c
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-28 21:05 ---
.quad _a-8
Not a GCC bug, a bug in the cctools assembler/linker, report this to Apple.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-28 21:14 ---
I can reproduce this on the mainline with a cross to powerpc64-linux-gnu with
-m32 -O2 -fwrapv.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-28 21:16 ---
Actually this is a dup of bug 25035.
*** This bug has been marked as a duplicate of 25035 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-06-28 21:16
---
*** Bug 28133 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-28 21:18 ---
Confirmed, we don't record in the preprocessor which keyword is used, _Complex
is treated the same as __complex__. There is another bug about a similar issue
with or and |.
--
pinskia at gcc dot gnu dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-28 21:21 ---
PR 14875 is the related bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-28 22:00 ---
Created an attachment (id=11776)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11776action=view)
Fixes the problem and some
The attached patch fixes the PR and fixes character valued functions in array
--- Comment #4 from sjackman at gmail dot com 2006-06-28 22:30 ---
I tried applying r95736 (2005-03-01 Nick Clifton) and r103151 (2005-08-16
Richard Earnshaw) against GCC 4.0.3. Both these patches apply cleanly (with
offsets), but don't fix the problem compiling newlib.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-28 23:31 ---
Is this a regression?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Summary|4.1.1 misses constant
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-28 23:34 ---
Is this a regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28158
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-28 23:35 ---
I think it was caused by:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01526.html
Which means this is a 4.2 Regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
I got a bus error by following program which use longjmp and __builtin_alloca
with -O0.
% cat z.c
#include setjmp.h
jmp_buf env;
void f(int a1, int a2, int a3, int a4, int a5, int a6, int a7, int a8)
{
longjmp(env, 1);
}
int main()
{
if (setjmp(env) == 0) {
void *p =
--- Comment #6 from sjackman at gmail dot com 2006-06-29 00:01 ---
Applying the patch from r103277 fixes this bug. I also had r95736 and r103151
applied against my 4.0.3 tree at the time. So, I don't know if r103277 alone is
sufficient. r103277 was meant to close PR target/23473, so
--- Comment #7 from sjackman at gmail dot com 2006-06-29 00:10 ---
Subject: Re: [4.0 only] config/arm/arm.c:3140 ICE
On 28 Jun 2006 23:31:22 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-28 23:31
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-29 00:30 ---
(In reply to comment #4)
FAIL: gcc.dg/visibility-11.c scan-assembler [EMAIL PROTECTED]
Yes this one is known.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28137
--- Comment #12 from jason at gcc dot gnu dot org 2006-06-29 01:12 ---
Subject: Bug 27768
Author: jason
Date: Thu Jun 29 01:12:20 2006
New Revision: 115062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115062
Log:
PR c++/27768
* tree-ssa-alias.c
--- Comment #2 from jason at gcc dot gnu dot org 2006-06-29 01:27 ---
Subject: Bug 27424
Author: jason
Date: Thu Jun 29 01:27:17 2006
New Revision: 115063
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115063
Log:
PR c++/27424
* pt.c (convert_template_argument):
--
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 #1 from akr at m17n dot org 2006-06-29 01:49 ---
I found a way to reproduce the bus error with -O2 as well as -O0.
% cat z.c
#include setjmp.h
jmp_buf env;
int i;
int main()
{
if (setjmp(env) == 0) {
char *p = __builtin_alloca(1024);
for (i = 0; i 1024; i++) {
--- Comment #27 from hjl at lucon dot org 2006-06-29 02:32 ---
Created an attachment (id=11777)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11777action=view)
An integer loop
I changed the loop from double to long long. The 64bit code generated by gcc
4.0
is 10% slower than gcc
--- Comment #28 from whaley at cs dot utsa dot edu 2006-06-29 04:17 ---
Guys,
If you are looking for the reason that the new code might be slower, my feeling
from the benchmark data is that involves hiding the cost of the loads. Notice
that, except for the cases where the double
56 matches
Mail list logo
