--- Comment #16 from ktietz at gcc dot gnu dot org 2010-02-04 08:47 ---
(In reply to comment #15)
Any further word on this?
As I said in comment #14, we fixed a strict-aliasing bug in our C runtime
related to POSIX printf. As I tested it with current runtime, result looks ok
to me. It
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-04 09:55 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-04 10:03 ---
Confirmed. Fails with -O -fno-tree-pta as well.
extern void abort (void);
static int g[1];
static int *p = g[0];
static int *q = g[0];
int main(void)
{
g[0] = 1;
*p = 0;
*p = *q;
if (g[0] != 0)
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-04 10:33 ---
Well, dse puts
(mem/u/f/c/i:DI (symbol_ref:DI (q) [flags 0x2] var_decl 0x75ae7140 q)
[0 q+0 S8 A64])
(mem/u/f/c/i:DI (symbol_ref:DI (p) [flags 0x2] var_decl 0x75ae70a0 p)
[0 p+0 S8 A64])
into different
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-04 10:36 ---
The only addresses treated as the dse constant kind should be symbol-refs.
Or we need to lookup the constant initializer the constant mem refers to
and use that (but I have no idea if that's easily possible on RTL).
--- Comment #8 from rearnsha at gcc dot gnu dot org 2010-02-04 10:48
---
Created an attachment (id=19803)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19803action=view)
Possible patch
I've been testing the attached patch on ARM (well, thumb) where there's a
similar issue. It's
--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-02-04 11:11
---
(In reply to comment #8)
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
--- Comment #10 from steven at gcc dot gnu dot org 2010-02-04 11:21 ---
I'm going to crack this bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from manu at gcc dot gnu dot org 2010-02-04 11:26 ---
(In reply to comment #7)
I can't reproduce this issue in current trunk (r156468)
Closing then as FIXED, the warning was caused by bug 42508.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-02-04 11:47
---
Also try the patches from PR42617 to see if they improve the pre-regalloc
scheduling.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
gcc/fortran/cpp.c contains:
/* FIXME: Pandora's Box
Using the macros below results in multiple breakages:
- mingw will fail to compile this file as dependent macros
assume to be used in c-cppbuiltin.c only. Further, they use
flags only valid/defined in C (same as noted
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-04 12:31 ---
Regarding (2): gcc/fortran/cpp.c contains the following, see PR 42954
/* FIXME: Pandora's Box
Using the macros below results in multiple breakages:
- mingw will fail to compile this file as dependent
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-02-04 13:03 ---
*** This bug has been marked as a duplicate of 42954 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-02-04 13:03 ---
*** Bug 36380 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954
I upgrade from gcc 4.1.2 to 4.4.3 and discovered that the gcc in
/usr/$(target_noncanonical)/bin no longer is functional. Using it results in:
gcc: error trying to exec 'cc1': execvp: No such file or directory
Digging around, it turns out that the internal paths are screwed up:
$
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-04 14:06 ---
Daniel: Wouldn't it be enough to duplicate c-cppbuiltin.c's
builtin_define_with_value and builtin_define_with_int_value for fortran/cpp.c?
Regarding builtin_define_std: Couldn't one simply define __TXT and __TXT__
When building Cuba-1.6 (http://www.feynarts.de/cuba/Cuba-1.6.tar.gz)
via configure make, there is an internal compiler error (segmentation fault)
in the compilation of Divonne.c. This may or may not be related to #41155.
gcc says:
gcc-4.4.3 -O3 -fomit-frame-pointer -ffast-math -DHAVE_CONFIG_H
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-04 14:26
---
Please follow the instructions here
http://gcc.gnu.org/bugs/#report
provide a preprocessed file. Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #2 from peb at mppmu dot mpg dot de 2010-02-04 14:27 ---
Created an attachment (id=19804)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19804action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from vda dot linux at googlemail dot com 2010-02-04 14:33
---
I was bitten by this whet I was trying to get rid of
warning: dereferencing type-punned pointer will break strict-aliasing rules
on this fairly normal networking-related code:
if (cmsgptr-cmsg_level ==
r2, [r1, #24]
add r1, r1, #32
cmp r1, r8
str r3, [r1, #-4]
bne .L2
ldmfd sp!, {r4, r5, r6, r7, r8}
bx lr
.size Unroll, .-Unroll
.ident GCC: (GNU) 4.5.0 20100204 (experimental) [trunk revision
156492]
(flags
--- Comment #13 from steven at gcc dot gnu dot org 2010-02-04 14:56 ---
With -fno-web, the patches from bug 42617 do not help and the output is the
same as that of comment #8 (second asm dump).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
--- Comment #5 from zadeck at naturalbridge dot com 2010-02-04 14:57
---
Richi, you are, of course, correct.
kenny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42952
--- Comment #6 from matz at gcc dot gnu dot org 2010-02-04 15:03 ---
Re comment #4, there are two possibilities to fix this:
1) as you say, don't regard MEM addresses (i.e. used in double indirection)
as const_or_frame_p, because that would put different (but runtime-same)
bases
--- Comment #14 from steven at gcc dot gnu dot org 2010-02-04 15:19 ---
Part of the problem comes from the way IVOPTS optimizes the memory access:
;; Generating RTL for gimple basic block 3
;; D.1814_10 = MEM[base: D.1846_29];
(insn 52 51 0 tst.c:6 (set (reg:SI 172 [ D.1814 ])
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-02-04 15:22 ---
Also fails with 4.3.4 and 4.4.2 if you do -fno-tree-ccp -fno-tree-fre
(I have a fix for the CCP optimization regression as well).
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-04 15:38 ---
The easiest way would be to expose the middle-end ref-all pointer annotation
so you could do typedef struct T *my_ptr __attribute__((ref_all)).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34156
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-04 15:44 ---
Confirmed at -O2. Reducing.
../Cuba-1.6/src/divonne/Split.c: In function 'Split':
../Cuba-1.6/src/divonne/Split.c:275:13: error: expected an SSA_NAME object
../Cuba-1.6/src/divonne/Split.c:275:13: error: in
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-04 15:54 ---
typedef const int cint;
typedef struct {
} Bounds;
int ndim_, ncomp_, selectedcomp_, nregions_;
void *voidregion_;
typedef struct {
double diff, err, spread;
} Errors;
typedef const Errors cErrors;
void
--- Comment #50 from steven at gcc dot gnu dot org 2010-02-04 16:04 ---
Bernd Schmidt has worked on this, see here:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01788.html
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00268.html
It is hard to tell whether this has actually addresses the
--- Comment #15 from steven at gcc dot gnu dot org 2010-02-04 16:06 ---
The patches for bug 31849 have been commited, it seems, and it doesn't help for
this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
Thread model: posix
gcc version 4.5.0 20100204 (experimental) [trunk revision 156492] (GCC)
r...@zoidberg:~/gnu/gcc/trunk/build/gcc$ touch t.c
r...@zoidberg:~/gnu/gcc/trunk/build/gcc$ ./cc1plus -quiet t.c -mfpu=foo
t.c:1:0: error
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-02-04 16:14 ---
Subject: Bug 42952
Author: rguenth
Date: Thu Feb 4 16:14:17 2010
New Revision: 156494
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156494
Log:
2010-02-04 Richard Guenther rguent...@suse.de
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-02-04 16:18 ---
Subject: Bug 42952
Author: rguenth
Date: Thu Feb 4 16:18:01 2010
New Revision: 156495
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156495
Log:
2010-02-04 Richard Guenther rguent...@suse.de
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-02-04 16:22
---
Subject: Bug 42952
Author: rguenth
Date: Thu Feb 4 16:21:47 2010
New Revision: 156496
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156496
Log:
2010-02-04 Richard Guenther rguent...@suse.de
PR
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-02-04 16:22
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Sent from my iPhone
On Feb 4, 2010, at 2:48 AM, rearnsha at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #8 from rearnsha at gcc dot gnu dot org 2010-02-04
10:48 ---
Created an attachment (id=19803)
--
--- Comment #9 from pinskia at gmail dot com 2010-02-04 16:36 ---
Subject: Re: Optimization flag -O1 -fschedule-insns2 cause red zone to be used
when there is none
Sent from my iPhone
On Feb 4, 2010, at 2:48 AM, rearnsha at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
I see
D.1631 = izz.dim[0].lbound;
D.1632 = izz.dim[0].ubound;
D.1643 = D.1632 - D.1631;
D.1647 = D.1643 0;
D.1648 = D.1643 + 1;
--- Comment #19 from davek at gcc dot gnu dot org 2010-02-04 17:12 ---
Created an attachment (id=19805)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19805action=view)
Further bugfix
fixed silly cut'n'pasto in the endianness layer which was truncating 4-byte
fields to 2 bytes.
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-04 17:17 ---
How did you configure the cross compiler?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from paolo dot carlini at oracle dot com 2010-02-04 18:02
---
It seems to me that if DR887 is indeed resolved per the discussion in Santa
Cruz, thus the wait_for functions removed, the wait_until functions use
system_clock, then this issue could be immediately resolved.
--- Comment #16 from bkoz at gcc dot gnu dot org 2010-02-04 18:20 ---
Subject: Bug 42460
Author: bkoz
Date: Thu Feb 4 18:20:34 2010
New Revision: 156502
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156502
Log:
2010-02-04 Benjamin Kosnik b...@redhat.com
PR
--- Comment #17 from bkoz at gcc dot gnu dot org 2010-02-04 18:27 ---
Hey. Can you re-check trunk now? I should have most of the quoting issues
fixed.
I've uploaded man pages with the new markup here:
ftp://gcc.gnu.org/pub/libstdc++/doxygen/libstdc++-man.20100204.tar.bz2
Can you
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-04 18:36
---
Reopen...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2010-02-04 18:36
---
... to close as duplicate.
*** This bug has been marked as a duplicate of 22634 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #22 from paolo dot carlini at oracle dot com 2010-02-04 18:36
---
*** Bug 42943 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #18 from debian-gcc at lists dot debian dot org 2010-02-04
18:39 ---
this is a check run by the lintian tool to check .deb packages after they are
built. for this check, lintian calls 'man --warnings -E UTF-8 -l file' for
every generated manpage. Afaik Debian/Ubuntu do use
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-04 19:32 ---
so, we check if the array-size is empty, ubound - lbound 0. In that
case we set size to zero. Otherwise we compute it
as (ubound - lbound + 1) *8.
Then we check whether size is negative and error out.
Then we
--- Comment #9 from bredelin at ucla dot edu 2010-02-04 20:29 ---
In reply to comment #8
So in the end all this boils down to the Frontend / middle-end issue of
weak handling of aligned types.
Would you mind giving a general idea of what the outlook for improvement on
this front is?
Currently, g++ does not emit the DW_AT_default_value attribute for
formal parameters that have default values.
I think it should; this is a prerequisite to letting gdb work with
default arguments.
--
Summary: g++ does not emit DW_AT_default_value
Product: gcc
--- Comment #19 from debian-gcc at lists dot debian dot org 2010-02-04
21:00 ---
std::basic_fstream.3cxx.gz 1213: warning: macro `)).' not defined
std::basic_ifstream.3cxx.gz 1037: warning: macro `)).' not defined
std::basic_iostream.3cxx.gz 1172: warning: macro `)).' not defined
--- Comment #20 from debian-gcc at lists dot debian dot org 2010-02-04
21:02 ---
Created an attachment (id=19806)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19806action=view)
fix \n quoting
fixes the manual page, didn't check the html output
--
I am having a hard time compiling the latest stable linux kernel on Fedora 12,
gcc 4.4.2
I get random `internal compiler error` like the one bellow (in different
sections of the kernel code):
/home/raduv/work/linux-2.6.32.7/drivers/hid/hid-apple.c:274: internal compiler
error: in
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-04 21:16 ---
See http://bugzilla.redhat.com/bugzilla for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
First it says to see redhat's bugzilla file this bug report. Second since this
--- Comment #2 from rvoicilas at gmail dot com 2010-02-04 21:24 ---
(In reply to comment #1)
See http://bugzilla.redhat.com/bugzilla for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
First it says to see redhat's bugzilla file this bug
For following testcase:
int e,f;
float
main(float d,float c)
{
float a;
float e;
if (e)
a=d, e=c;
else
a=c, c=e;
if (f)
e=a;
return e;
}
(it looks artifical, but all the moves are there just to make a to be only
source or destination of reg-reg move that is not
GCC is inefficient when loading constant strings.
The sample code is:
printf( \nMCF SPEC CPU2006 version 1.10\n );
GCC places the constant string a a read-only data section. If compiled with
-fpic, gcc places the string's offset(relative to GOT entry) in GOT table.
To address the string, gcc
--- Comment #4 from dodji at gcc dot gnu dot org 2010-02-04 22:06 ---
A candidate patch was posted to
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00204.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42915
--- Comment #10 from wilson at tuliptree dot org 2010-02-04 22:16 ---
Subject: Re: Optimization flag -O1 -fschedule-insns2
cause red zone to be used when there is none
On Thu, 2010-02-04 at 16:36 +, pinskia at gmail dot com wrote:
Well powerpc64 it is valid to move across the
--- Comment #31 from kkojima at gcc dot gnu dot org 2010-02-04 22:42
---
Looks smart and clean! One minor nit, I guess that the occurence of
gbr and GBR in ChangeLog and comments should be replaced with GOT to
avoid confusion with GBR register of SH CPU.
When you propose it to the
--- Comment #14 from steven at gcc dot gnu dot org 2010-02-04 22:52 ---
Still not fixed. Still the major source of RTL jump threads.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Test case is taken from bug 18046:
-
extern void foo (void);
extern int i;
void
bar (void)
{
switch (i)
{
case 0:
foo ();
break;
case 1:
break;
}
switch (i)
{
case 0:
foo ();
break;
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-02-04
23:35 ---
The new g++.dg/ext/label13.C testcase fails on *-apple-darwin*. On
x86_64-apple-darwin10, the error message is...
/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/gcc/testsuite/g++/../../g++
--target=mips64-none-elf
--prefix=/scratch/baremetal/mips64-none-elf/tools --enable-multilib
--disable-werror --enable-languages=c,c++ --with-newlib
Thread model: single
gcc version 4.5.0 20100204 (experimental) (GCC)
I tried same test with gcc 4.1(mips64-elf) and it took about 48 seconds
We do not currently give the message: warnings being treated as errors for
individual -Werror=x options.
See http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01197.html
Also, it would be good to print the message near the end of the compilation
rather than at the start.
--
Summary: no
See http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01197.html
Currently, warnings enabled by flags are indicated by the flag when using
-fdiagnostics-show-option. However, warnings enabled by default do not show
anything. Two possible fixes:
1) Give the flag that enables the warning (like now).
--- Comment #1 from manu at gcc dot gnu dot org 2010-02-05 01:20 ---
@Simon,
I think this solution would be accepted more readily by everybody, since anyway
we already have the [-W*] markers for most warnings except default ones. What
do you think?
I specially like showing the flag
--- Comment #1 from manu at gcc dot gnu dot org 2010-02-05 01:23 ---
Adding Simon Baldwin to CC list (although it seems he doesn't read bugzilla
mail).
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jason at gcc dot gnu dot org 2010-02-05 01:41 ---
Ah, I guess we don't support the same body alias optimization on darwin, so the
testcase should be restricted to targets that do support it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090
+++ This bug was initially created as a clone of Bug #35923 +++
I get the following error on a clean 4.3.0 build when trying (eg) gcj
foo.java:
gcj: error trying to exec 'ecj1': execvp: No such file or directory
I also have the same bug.
--
Summary: gcj: error trying to exec
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2010-02-05 03:04
---
Closing. Not a gcc/gfortran bug.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from jvdelisle at gcc dot gnu dot org 2010-02-05 03:13
---
I think this is fixed and looks like it has dried up.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2010-02-05 03:25
---
1 year has gone by again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-02-05 04:47
---
Subject: Bug 42901
Author: jvdelisle
Date: Fri Feb 5 04:47:12 2010
New Revision: 156507
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156507
Log:
2010-02-04 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-02-05 04:51
---
Subject: Bug 42901
Author: jvdelisle
Date: Fri Feb 5 04:50:53 2010
New Revision: 156508
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156508
Log:
2010-02-04 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-02-05 04:58
---
Subject: Bug 42901
Author: jvdelisle
Date: Fri Feb 5 04:58:30 2010
New Revision: 156509
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156509
Log:
2010-02-04 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-02-05 05:00
---
Subject: Bug 42901
Author: jvdelisle
Date: Fri Feb 5 05:00:15 2010
New Revision: 156510
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156510
Log:
2010-02-04 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #5 from pault at gcc dot gnu dot org 2010-02-05 05:28 ---
Subject: Bug 42309
Author: pault
Date: Fri Feb 5 05:28:37 2010
New Revision: 156512
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156512
Log:
2010-02-05 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #2 from pault at gcc dot gnu dot org 2010-02-05 05:36 ---
(In reply to comment #1)
Why there is a negative check? Well, I do not know. I also can speculate about
a poor man's overflow check, which sometimes indeed works, but often fails.
I suspect that you are being
--- Comment #32 from chrbr at gcc dot gnu dot org 2010-02-05 07:05 ---
Looks smart and clean! One minor nit, I guess that the occurence of
gbr and GBR in ChangeLog and comments should be replaced with GOT to
avoid confusion with GBR register of SH CPU.
Thanks for catching up this
--- Comment #33 from kkojima at gcc dot gnu dot org 2010-02-05 07:42
---
Your fix of the middle end looks plausible but I think the target
shouldn't generate a CP at the eh landing pad anyway. I'll commit
the hunk below anyway after your patch for pic problem is installed.
@@ -4654,6
84 matches
Mail list logo
