--- Comment #4 from iains at gcc dot gnu dot org 2010-05-28 07:05 ---
fixed by r159952
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from borntraeger at de dot ibm dot com 2010-05-28 07:24
---
Created an attachment (id=20767)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20767action=view)
Patch that makes loop invariant prefetches backend specfic
Three observations:
1. the patch had a bug which
--
amodra at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at gmail dot com
|dot org |
The following code segfaults GCC 4.5 (and GCC trunk 159536) when compiled with
:
$ gcc -O1 -floop-parallelize-all test-17.c
Program received signal SIGSEGV, Segmentation fault.
0x77bce389 in cloog_domain_stride (domain=value optimized out,
strided_level=value optimized out, nb_par=value
--- Comment #5 from borntraeger at de dot ibm dot com 2010-05-28 07:41
---
An alternative approach might be have different values for
prefetch-min-insn-to-mem-ratio and min-insn-to-prefetch-ratio
depending on constant/non-constant step size.
--
OS : Mac OS x 10.6.2 (Snow Leopard)
IDE tools : Xcode 3.2.2
Processor : Intel Core 2 Duo
Memory : 1 GB
Problem :
the make step operates well until teh comparison phase between stages 2 and 3.
Bootstrap matter ...
I have saved the files you need but how to send them to you ?
Yours sincerely,
--- Comment #20 from paolo dot carlini at oracle dot com 2010-05-28 08:56
---
I don't think anybody is seriously interested in looking into this, it doesn't
affect any other actively maintained target.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #4 from amodra at gcc dot gnu dot org 2010-05-28 08:57 ---
Subject: Bug 44266
Author: amodra
Date: Fri May 28 08:57:16 2010
New Revision: 159963
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159963
Log:
PR target/44266
* config/rs6000/rs6000.c
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-28 09:13 ---
first can you give the output from the failure:
i.e. which files have differences?
...the configuration line you are using.
the output of
autoconf --version
automake --version
m4 --version
I should remind you of
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-28 10:22 ---
Also you need to put the libraries into your LD_LIBRARY_PATH.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44296
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-28 10:24 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2010-05-28 10:24 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-28 10:26 ---
No regression patches pending, so the remaining pending patches will not be
committed to the GCC 4.5 release branch.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-28 10:29 ---
This is not FIXED at all, just papered over.
See http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02193.html
Please don't close bugs as FIXED if they have not been actually fixed.
--
steven at gcc dot gnu dot org
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-28 10:30 ---
GCC sees at the point of the warning
if (b a b[0] a[10])
b[-1] = 0;
and it cannot statically determine those comparisons.
So it warns (IMHO correctly). This is very unlikely going to be fixed.
--
warning: cast discards qualifiers from pointer target type
There are at lot of these building gcc.
Including but not limited to:
../../gcc-4.5/gcc/gimple.h: In function gimple_op:
../../gcc-4.5/gcc/gimple.h:1635: warning: cast discards qualifiers from pointer
target type
The ifcvt changes cause 464.h264ref to fail to build exhausting virtual memory.
This is appearantly because of shared trees in
#71 0x00a1abe3 in add_to_dst_predicate_list (loop=0x77edf3f0,
e=0x759a2d40, prev_cond=0x7fffc8c0b0e0, cond=0x7fffc8c0b118)
at
warning: may be used uninitialized in this function
Including but not necessarily limited to:
ebitmap.c: In function ebitmap_ior_into:
ebitmap.c:554: warning: i may be used uninitialized in this function
ebitmap.c: In function ebitmap_ior:
ebitmap.c:678: warning: i may be used
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-28 10:45 ---
What is your host compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44307
--- Comment #2 from jay dot krell at cornell dot edu 2010-05-28 10:48
---
Here is another:
tree-chrec.h:131: warning: 'val' may be used uninitialized in this function
I'm using -disable-bootstrap.
I'm not sure that matters here but maybe.
There isn't -Werror, compilation does
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-28 10:58 ---
Reduced testcase:
extern const int quant_coef8[6][8][8];
extern const int dequant_coef8[6][8][8];
int LevelScale8x8Luma_Intra[6][8][8];
int LevelScale8x8Luma_Inter[6][8][8];
int InvLevelScale8x8Luma_Intra[6][8][8];
There are a number of these unsightly warnings (not errors) building gcc on
MacOSX:
ranlib: file: libbackend.a(insn-peep.o) has no symbols
ranlib: file: libbackend.a(graphite-blocking.o) has no symbols
ranlib: file: libbackend.a(graphite-clast-to-gimple.o) has no symbols
ranlib: file:
Might be nice to prevent these, if easy/possible.
../../gcc-4.5/gcc/config/t-darwin:25: warning: overriding commands for target
`darwin.o'
../../gcc-4.5/gcc/config/t-darwin:25: warning: ignoring old commands for target
`darwin.o'
../../gcc-4.5/gcc/config/t-darwin:31: warning: overriding commands
--- Comment #4 from ktietz at gcc dot gnu dot org 2010-05-28 11:19 ---
Subject: Bug 44299
Author: ktietz
Date: Fri May 28 11:19:41 2010
New Revision: 159965
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159965
Log:
2010-05-28 Kai Tietz kai.ti...@onevision.com
PR
--- Comment #3 from jsm28 at gcc dot gnu dot org 2010-05-28 11:35 ---
Stop using c as the component for bugs that are obviously not front-end bugs.
In this case, you can see that none of the files mentioned are front-end files.
--
jsm28 at gcc dot gnu dot org changed:
--- Comment #6 from mikpe at it dot uu dot se 2010-05-28 11:49 ---
Confirmed. A linux-2.6.34 kernel configured for ARM and compiled with
gcc-4.5-20100520 crashes during boot with a NULL pointer dereference in its
copy_user_highpage() exactly at the point where it tries to start
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-05-28
11:56 ---
MacPorts has accumulated a number of users who seem to run into this issue with
gcc 4.5.0 (apparently always with libgomp)...
https://svn.macports.org/ticket/24664
Peter O'Gorman also has a problem
--- Comment #3 from dominiq at lps dot ens dot fr 2010-05-28 12:16 ---
If the comparison failure is for libgomp, this pr is a duplicate of pr43170.
The origin of the problem can be seen with the following test:
[macbook] f90/bug% grep -i tls
--- Comment #30 from dominiq at lps dot ens dot fr 2010-05-28 12:16 ---
pr44304 may a duplicate of this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
gcc shouldn't use utf8 backticks for quotes.
Often I paste gcc output into email or cvs commit comments or bug reports, and
the backticks in like:
'foo' might used uninitialized
shows up with some garbage
!...@#foo!@#$ might be used uninitialized
Imho this code should be removed:
gcc/intl.c
$ cat t.cc
enum class A { Val0, Val1 };
void foo( A a )
{
switch( a )
{
case A::Val0: break;
case 1: break;
}
}
$ g++ -std=c++0x -c template.cc
works
I think there should be a compile error in line 8.
--
Summary: no error with switch over enum class and integer case
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-28 12:39 ---
Don't use UTF-8 locale if your terminal or applications aren't UTF-8 ready.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
lto-streamer-in.c: In function lto_read_tree: warning: fv.mode is used
uninitialized in this function
--
Summary: lto-streamer-in.c: In function lto_read_tree: warning:
fv.mode is used uninitialized in this function
Product: gcc
--- Comment #2 from jay dot krell at cornell dot edu 2010-05-28 12:42
---
This is just whatever defaults I'm given. I haven't set anything.
I often get garbled output.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44310
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-28 13:06 ---
This is OK, those files have only content for certain configurations (with
CLOOG, doloop pattern in the backend, etc.). You should look for a way to
suppress the warning without adding new symbols at random.
--
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-28 13:10 ---
svn revision number? target triplet?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44312
--- Comment #15 from amodra at gmail dot com 2010-05-28 13:16 ---
Created an attachment (id=20768)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20768action=view)
gcc-4.4 patch
The underlying problem is that the load_toc_v4_PIC_1b rtl doesn't properly
describe that its output
--- Comment #12 from iains at gcc dot gnu dot org 2010-05-28 13:17 ---
Subject: Bug 23616
Author: iains
Date: Fri May 28 13:16:44 2010
New Revision: 159971
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159971
Log:
PR ObjC++/23616
* obj-c++.dg/try-catch-2.mm:
--- Comment #2 from jay dot krell at cornell dot edu 2010-05-28 13:22
---
I assume it is talking about this, but I'm not certain:
static void
unpack_ts_fixed_cst_value_fields (struct bitpack_d *bp, tree expr)
{
struct fixed_value fv;
fv.data.low = (HOST_WIDE_INT) bp_unpack_value
--- Comment #3 from jay dot krell at cornell dot edu 2010-05-28 13:26
---
gcc-4.5/gcc/lto-streamer-in.c: In function lto_read_tree:
gcc-4.5/gcc/lto-streamer-in.c:1634: warning: fv.mode is used uninitialized in
this function
static void
unpack_ts_fixed_cst_value_fields (struct
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-28 13:36 ---
Subject: Bug 43636
Author: jakub
Date: Fri May 28 13:35:56 2010
New Revision: 159972
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159972
Log:
PR target/43636
* builtins.c (expand_movstr): Use
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-28 13:38 ---
Subject: Bug 43636
Author: jakub
Date: Fri May 28 13:38:26 2010
New Revision: 159973
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159973
Log:
PR target/43636
* builtins.c (expand_movstr): Use
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-28 13:47 ---
Subject: Bug 41048
Author: jakub
Date: Fri May 28 13:46:46 2010
New Revision: 159975
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159975
Log:
PR debug/41048
* dwarf2out.c
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-28 14:04 ---
It is caused by revision 159886:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00942.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-28 14:04 ---
(In reply to comment #1)
It is caused by revision 159886:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00942.html
Oops. Wrong comments.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-28 14:05 ---
It is caused by revision 159886:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00942.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Our very own web page has a C++ FAQ about requires that a copy constructor be
visible when initializing a const reference:
http://gcc.gnu.org/bugs/#cxx_rvalbind
However, current versions of gcc do not give an error for that code, even when
using -pedantic -std=c++98. The last version of gcc
I was preparing to submit some patches, so I did a sync up to mainline, and it
now fails to bootstrap on powerpc64-unknown-linux-gnu. It appears to be due to
the android changes that ma...@codesourcery.com did.
$ make c-common.o CFLAGS='-g -O2 -save-temps -H'
gcc64 -c -DIN_GCC_FRONTEND -g -O2
--- Comment #1 from ian at airs dot com 2010-05-28 14:30 ---
This was addressed as a DR by the C++ committee:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#391 . And of
course the proposed C++0x standard removes this error. So gcc should only give
an error with
--- Comment #5 from jmattson at vmware dot com 2010-05-28 14:39 ---
Can you recommend an elegant way to rewrite this code to avoid the warning?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-28 14:44 ---
Not really. Comparing pointers that point to different objects invokes
undefined behavior anyway.
You could try
--p;
if (p = a p a + 10) {
*p = 0;
}
--
--- Comment #3 from spop at gcc dot gnu dot org 2010-05-28 14:46 ---
Confirmed.
I think that this one is a bug in CLooG-PPL. I will have a look at it.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from spop at gcc dot gnu dot org 2010-05-28 14:46 ---
Mine.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #4 from steven at gcc dot gnu dot org 2010-05-28 14:51 ---
It looks like the mode field of struct fixed_value has to be streamed in/out
for LTO.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2010-05-28 15:03
---
Subject: Bug 44314
Author: mkuvyrkov
Date: Fri May 28 15:03:23 2010
New Revision: 159978
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159978
Log:
PR bootstrap/44314
*
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2010-05-28 15:04
---
Fixed in rev. 159978.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from dodji at gcc dot gnu dot org 2010-05-28 15:34 ---
Created an attachment (id=20769)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20769action=view)
Tom's Initial patch ported to 4.6
This is just the initial patch I ported to 4.6. It should apply cleanly to
--- Comment #24 from dodji at gcc dot gnu dot org 2010-05-28 15:42 ---
Created an attachment (id=20770)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20770action=view)
First version of an updated patch
So I thought I'd post the current state of the patch I am working on.
This
Revision 159959 gave
[...@gnu-6 gcc]$ make
make: Circular build/gencondmd.o - insn-flags.h dependency dropped.
make: Circular build/gencondmd.o - insn-flags.h dependency dropped.
[...@gnu-6 gcc]$
--
Summary: [4.6 Regression] Circular build/gencondmd.o - insn-
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-28 15:53 ---
Comes from dependency of FUNCTION_H on TM_H.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jmattson at vmware dot com 2010-05-28 15:55 ---
So, you are saying that given an arbitrary pointer p, it is impossible to
determine whether or not p points to an element of array a[], because comparing
pointers to different objects is undefined? I find that hard to
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44315
--- Comment #13 from mikpe at it dot uu dot se 2010-05-28 16:02 ---
Jakub's patch fixed 4.6 bootstrap on my sparc64 machine. My ARM is testing
other branches currently, but I should have 4.6 bootstrap results for it on
Sunday or Monday, at which time I'll close this PR if things went
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-28 16:32 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rwild at gcc dot gnu dot org 2010-05-28 16:35 ---
I'll bite.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-05-28 16:40 ---
(In reply to comment #7)
So, you are saying that given an arbitrary pointer p, it is impossible to
determine whether or not p points to an element of array a[], because
comparing
pointers to different objects
--- Comment #6 from changpeng dot fang at amd dot com 2010-05-28 16:46
---
(In reply to comment #4)
Created an attachment (id=20767)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20767action=view) [edit]
Patch that makes loop invariant prefetches backend specfic
Actually, I
This test case demonstrates what i mean:
struct my_struct {
int x;
int (*hook_a)( void );
};
int func_a( void )
{
return 1;
}
void func_b( void )
{
func_a( );
}
int main( void )
{
struct my_struct a = { 1, func_a };
struct my_struct b = { 2, func_b };
return 0;
}
When
--- Comment #9 from jmattson at vmware dot com 2010-05-28 16:53 ---
Okay. What if we stick with equality operators, then?
static inline void
foo(int *p)
{
if (p == a + 1 || p == a + 2) {
p[-1] = 0;
}
}
This code results in the same warning.
--
--- Comment #7 from changpeng dot fang at amd dot com 2010-05-28 16:56
---
(In reply to comment #5)
An alternative approach might be have different values for
prefetch-min-insn-to-mem-ratio and min-insn-to-prefetch-ratio
depending on constant/non-constant step size.
It may be a
--- Comment #1 from tromey at gcc dot gnu dot org 2010-05-28 16:58 ---
Here is what gcc trunk says:
opsy. gcc --syntax-only pr.c
pr.c: In function main:
pr.c:20:10: warning: initialization from incompatible pointer type [enabled by
default]
The particular case motivating this PR was
--- Comment #2 from joseph at codesourcery dot com 2010-05-28 17:12 ---
Subject: Re: initialization from incompatible pointer type
struct initilization error handling
You could probably make WARN_FOR_ASSIGNMENT use pedwarn_init.
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-05-28 17:15 ---
*** Bug 44316 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Consider code:
--- test.cpp -
class SomeClass {};
#define ASSERT( cnd, ... ) SomeClass(),##__VA_ARGS__
#define FAIL( ... )SomeClass(),##__VA_ARGS__
void test()
{
ASSERT( false );
FAIL();
}
--
$ cpp test.cpp
SomeClass();
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-05-28 17:15 ---
*** This bug has been marked as a duplicate of 37724 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jsm28 at gcc dot gnu dot org 2010-05-28 17:29 ---
Subject: Bug 15303
Author: jsm28
Date: Fri May 28 17:28:57 2010
New Revision: 159986
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159986
Log:
PR driver/15303
* gcc.c (inform, warning, inform):
--- Comment #8 from jsm28 at gcc dot gnu dot org 2010-05-28 17:29 ---
Fixed for 4.6.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-05-28 17:51
---
(In reply to comment #9)
Okay. What if we stick with equality operators, then?
static inline void
foo(int *p)
{
if (p == a + 1 || p == a + 2) {
p[-1] = 0;
}
}
This code results in the
--- Comment #4 from mrs at gcc dot gnu dot org 2010-05-28 17:56 ---
I checked in a fix for this in r159988. I'm skeptical of the abi doc, so I'd
prefer just the first part, as I know it is needed. Thanks.
--
mrs at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from changpeng dot fang at amd dot com 2010-05-28 18:30
---
(In reply to comment #4)
Created an attachment (id=20767)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20767action=view) [edit]
Patch that makes loop invariant prefetches backend specfic
Three
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-05-28 18:30 ---
(In reply to comment #2)
This is just whatever defaults I'm given.
Then complain to your distro since they are the ones where the bug is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44310
--- Comment #4 from mrs at gcc dot gnu dot org 2010-05-28 18:34 ---
Subject: Bug 44125
Author: mrs
Date: Fri May 28 18:33:45 2010
New Revision: 159989
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159989
Log:
PR objc/44125
* objc.dg/const-str-9.m: Remove static.
--- Comment #5 from mrs at gcc dot gnu dot org 2010-05-28 18:35 ---
static isn't part of the test case, it just wasn't reduced.
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from changpeng dot fang at amd dot com 2010-05-28 18:36
---
(In reply to comment #8)
Looks like this is a fix to the regressions. That is, the regressions are
actually caused by the wrong calculation. This bug could be considered fixed,
even though performance tuning
--- Comment #3 from spop at gcc dot gnu dot org 2010-05-28 18:38 ---
Subject: Bug 44293
Author: spop
Date: Fri May 28 18:38:06 2010
New Revision: 159990
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159990
Log:
Check the if-convertibility of phi nodes in non predicated BBs.
--- Comment #4 from spop at gcc dot gnu dot org 2010-05-28 18:46 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-28 18:50 ---
Subject: Bug 44312
Author: rguenth
Date: Fri May 28 18:49:51 2010
New Revision: 159993
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159993
Log:
2010-05-28 Richard Guenther rguent...@suse.de
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-05-28 19:02 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-05-28 19:02 ---
Subject: Bug 44312
Author: rguenth
Date: Fri May 28 19:02:24 2010
New Revision: 159994
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159994
Log:
2010-05-28 Richard Guenther rguent...@suse.de
PR
there is no gcc-4.3.5 tree here:
http://ftp.gnu.org/gnu/gcc/
instead, it looks like someone put all the gcc-4.3.5 files into the 4.5.0 dir:
http://ftp.gnu.org/gnu/gcc/gcc-4.5.0/
[ ] gcc-4.3.5.tar.bz2 22-May-2010 16:56 57M
[ ] gcc-4.3.5.tar.bz2.sig
optimization_options in i386.c has
/* For -O2 and beyond, turn on -fzee for x86_64 target. */
if (level 1 TARGET_64BIT)
flag_zee = 1;
But TARGET_64BIT is set/clear later in override_options. As
the result, flag_zee may be set incorrectly for -m32/-m64.
--
Summary: -fzee
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot com
Target Milestone|---
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-28 21:14 ---
Bah ...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from mikpe at it dot uu dot se 2010-05-28 22:02 ---
Bisection identified r148981 as the cause of this regression:
Author: rth
Date: Fri Jun 26 18:23:32 2009
New Revision: 148981
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148981
Log:
* function.h (struct
--- Comment #4 from spop at gcc dot gnu dot org 2010-05-28 23:38 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02294.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44306
--- Comment #11 from segher at kernel dot crashing dot org 2010-05-29
00:34 ---
(In reply to comment #5)
Can you recommend an elegant way to rewrite this code to avoid the warning?
static inline void
foo(int *p)
{
if ((uintptr_t)p - (uintptr_t)(a + 1) sizeof a - sizeof a[0]) {
--- Comment #2 from hp at gcc dot gnu dot org 2010-05-29 03:21 ---
Fixed after 159920 but before or including 159930. At closer inspection, it
has to be r159929. :) On the other hand, from the patch message it seems it's
just intended to be a stop-gap measure, so I'll leave it to Iain
97 matches
Mail list logo
