[Bug tree-optimization/44137] [4.6 Regression]: objc.dg/torture/tls/thr-init-2.m and thr-init.m
--- 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 to close this PR. -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-29 03:21:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44137
[Bug middle-end/44300] Spurious array subscript warning, &b[0] == &a[1] is not folded
--- 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]) {
p[-1] = 0;
}
}
--
segher at kernel dot crashing dot org changed:
What|Removed |Added
CC||segher at kernel dot
||crashing dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
[Bug tree-optimization/44306] [4.6 Regression] 464.h264ref fails to build.
--- 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
[Bug tree-optimization/44290] [4.5 Regression] arm linux kernel crahes when built with -fipa-sra
--- 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=gcc&view=rev&rev=148981 Log: * function.h (struct function): Add cannot_be_copied_reason, and cannot_be_copied_set. * tree-inline.c (has_label_address_in_static_1): Rename from inline_forbidden_p_2; don't set inline_forbidden_reason here. (cannot_copy_type_1): Rename from inline_forbidden_p_op; likewise don't set inline_forbidden_reason. (copy_forbidden): New function, split out of inline_forbidden_p. (inline_forbidden_p_stmt): Don't check for nonlocal labels here. (inline_forbidden_p): Use copy_forbidden. (tree_versionable_function_p): Likewise. (inlinable_function_p): Merge into tree_inlinable_function_p. (tree_function_versioning): Remap cfun->nonlocal_goto_save_area. * ipa-cp.c (ipcp_versionable_function_p): New function. (ipcp_cloning_candidate_p): Use it. (ipcp_node_modifiable_p): Likewise. I'll try to extract a smaller test case tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug web/44318] gcc-4.3.5 release in wrong dir
--- 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 AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-28 21:14:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44318
[Bug target/44319] -fzee is mishandled
-- hjl dot tools at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44319
[Bug target/44319] New: -fzee is mishandled
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 is mishandled Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44319
[Bug web/44318] New: gcc-4.3.5 release in wrong dir
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 22-May-2010 16:57 280 [ ] gcc-4.3.5.tar.gz 22-May-2010 16:53 74M [ ] gcc-4.3.5.tar.gz.sig 22-May-2010 16:57 280 etc... further, there was no 4.3.5 release e-mail sent out ? http://gcc.gnu.org/ml/gcc-announce/2010/ -- Summary: gcc-4.3.5 release in wrong dir Product: gcc Version: 4.3.5 Status: UNCONFIRMED Severity: major Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vapier at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44318
[Bug lto/44312] lto-streamer-in.c: In function �lto_read_tree�: warning: �fv.mode� is used uninitialized in this function
--- 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=gcc&view=rev&rev=159994 Log: 2010-05-28 Richard Guenther PR lto/44312 * lto-streamer-in.c (unpack_ts_fixed_cst_value_fields): Stream fixed-point constants mode. (unpack_ts_type_value_fields): Fix width of TYPE_MODE and TYPE_PRECISION. * lto-streamer-out.c (pack_ts_fixed_cst_value_fields): Stream fixed-point constants mode. (pack_ts_function_decl_value_fields): Fix width of TYPE_MODE and TYPE_PRECISION. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/lto-streamer-in.c branches/gcc-4_5-branch/gcc/lto-streamer-out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44312
[Bug lto/44312] lto-streamer-in.c: In function �lto_read_tree�: warning: �fv.mode� is used uninitialized in this function
--- 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|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44312
[Bug lto/44312] lto-streamer-in.c: In function �lto_read_tree�: warning: �fv.mode� is used uninitialized in this function
--- 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=gcc&view=rev&rev=159993 Log: 2010-05-28 Richard Guenther PR lto/44312 * lto-streamer-in.c (unpack_ts_fixed_cst_value_fields): Stream fixed-point constants mode. (unpack_ts_type_value_fields): Fix width of TYPE_MODE and TYPE_PRECISION. * lto-streamer-out.c (pack_ts_fixed_cst_value_fields): Stream fixed-point constants mode. (pack_ts_function_decl_value_fields): Fix width of TYPE_MODE and TYPE_PRECISION. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c trunk/gcc/lto-streamer-out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44312
[Bug middle-end/44293] [4.6 regression] FAIL: gcc.c-torture/compile/20040304-1.c
--- 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 |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44293
[Bug middle-end/44293] [4.6 regression] FAIL: gcc.c-torture/compile/20040304-1.c
--- 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=gcc&view=rev&rev=159990 Log: Check the if-convertibility of phi nodes in non predicated BBs. 2010-05-28 Sebastian Pop PR middle-end/44293 * tree-if-conv.c (if_convertible_loop_p): Check the if-convertibility of phi nodes in non predicated BBs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44293
[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86
--- 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 may be necessary for non-constant step > prefetching. Thanks. > Oh, NO! After this patch, 465.tonto has a big regression (-16%), compared to no prefetching. Note that prefetching causes 465.tonto a ~7% degradation originally (before non-constant step prefetching) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
[Bug objc/44125] [4.6 Regression] const-str-9 fails.
--- 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 CC|mrs at gcc dot gnu dot org | Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44125
[Bug objc/44125] [4.6 Regression] const-str-9 fails.
--- 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=gcc&view=rev&rev=159989 Log: PR objc/44125 * objc.dg/const-str-9.m: Remove static. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/objc.dg/const-str-9.m -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44125
[Bug c/44310] utf8 quotes in warnings make them look like garbage in many contexts
--- 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
[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86
--- 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=20767&action=view) [edit] > Patch that makes loop invariant prefetches backend specfic > > Three observations: > > 1. the patch had a bug which let to wrong calculation in some cases > This commit should be applied to improve some other testcases: > http://gcc.gnu.org/viewcvs?view=revision&revision=159816 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 may be necessary for non-constant step prefetching. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
[Bug testsuite/25766] objc.dg/stret-2.m fails on i686-darwin
--- 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 |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25766
[Bug middle-end/44300] Spurious array subscript warning, &b[0] == &a[1] is not folded
--- 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 same warning.
Yep. That's because a and b might not bind locally and thus we do not
know whether &b[0] == &a[1].
We don't warn for -fno-common, but in this case we might still
optimize the comparison.
Confirmed for the testcase in comment #9.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-05-28 17:51:52
date||
Summary|Spurious array subscript|Spurious array subscript
|warning |warning, &b[0] == &a[1] is
||not folded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
[Bug driver/15303] When gcc sees an unrecognized option, the exit status indicates success
--- 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 |RESOLVED Known to work||4.6.0 Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15303
[Bug driver/15303] When gcc sees an unrecognized option, the exit status indicates success
--- 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=gcc&view=rev&rev=159986 Log: PR driver/15303 * gcc.c (inform, warning, inform): New functions. (fatal_ice): Rename to internal_error; change cmsgid parameter to gmsgid. All callers changed. (notice): Rename to fnotice; add parameter fp. All callers changed. (fatal_error): Rename to fatal_signal. All users changed. (fatal): Rename to fatal_error; change cmsgid parameter to gmsgid. All callers changed. (process_command): Use warning instead of error for warnings. (end_going_arg): Don't use _() around argument of error. (do_spec_1): Use inform for message from %n specs. Use warning instead of error for warnings. (main): Use inform for comparison messages. Use warning for message about unused linker input. (error): Increment error_count. Print "error: ". * gcc.h (fatal): Change to fatal_error. (warning): Declare. * config/darwin-driver.c (darwin_default_min_version): Use warning instead of fprintf for warnings. * cppspec.c (lang_specific_driver): Use fatal_error instead of fatal. cp: * g++spec.c (lang_specific_driver): Use fatal_error instead of fatal. fortran: * gfortranspec.c (append_arg, lang_specific_driver): Use fatal_error instead of fatal. Use warning instead of fprintf for warnings. java: * jvspec.c (lang_specific_driver): Use fatal_error instead of fatal. Use warning instead of error for warnings. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-driver.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/g++spec.c trunk/gcc/cppspec.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortranspec.c trunk/gcc/gcc.c trunk/gcc/gcc.h trunk/gcc/java/ChangeLog trunk/gcc/java/jvspec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15303
[Bug c/44316] "initialization from incompatible pointer type" struct initilization error handling
--- 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 Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44316
[Bug preprocessor/44317] New: ,##__VA_ARGS__ comma not eaten with -std=c++0x
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();
>>> SomeClass();
$ cpp -std=c++0x test.cpp
>>> SomeClass();
>>> SomeClass(),;
^^^ extra comma !
Why would the comma not be eaten only in c++0x
and when the ellipsis is the unique parameter of
the macro ?
--
Summary: ,##__VA_ARGS__ comma not eaten with -std=c++0x
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot estievenart at free dot fr
GCC build triplet: 4.4.4 (Debian 4.4.4-1)
GCC host triplet: i686 debian GNU/Linux
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44317
[Bug c/37724] "initialization from incompatible pointer type" does not say which field is being initialized
--- 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 CC||herron dot philip at ||googlemail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37724
[Bug c/44316] "initialization from incompatible pointer type" struct initilization error handling
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44316
[Bug c/44316] "initialization from incompatible pointer type" struct initilization error handling
--- 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 getting a declaration wrong and then getting an error from LANG_HOOKS_INITIALIZER. In this case the location info is not helpful. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-28 16:58:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44316
[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86
--- 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 good idea for limit non-constant step prefetching to big loops. This is because we are not very confident that the reference will cause cache miss, and we should limit the prefetches generated. min-insn-to-prefetch-ratio may be a good parameter to work on. By the way, I am thinking that min-insn-to-prefetch-ratio should be backend dependent. In certain sense, this parameter implies how many "useless" prefetches can an architecture tolerate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
[Bug c/44300] Spurious array subscript warning
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
[Bug c/44316] New: "initialization from incompatible pointer type" struct initilization error handling
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 initializing a struct it would be nice to have an error message detailing
the field which has the incompatible pointer type.
--
Summary: "initialization from incompatible pointer type" struct
initilization error handling
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: herron dot philip at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44316
[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86
--- 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=20767&action=view) [edit] > Patch that makes loop invariant prefetches backend specfic > Actually, I am the one who would like the invariant step prefetch to be backend independent. However, the current implementation seems a bit aggressive: The fundamental assumption of the implementation is that the invariant step is big enough so that there is no spatial reuse and we don't need to unroll the loop (preprech_mod == 1). This assumption may be OK for c code (or integer code), and may not be appropriate for fortran programs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
[Bug c/44300] Spurious array subscript warning
--- 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 is undefined? I find that hard to believe, but
> I'm no standards lawyer.
6.5.8/5 says that (note it only applies to relational operators, not
equality operators).
> Your suggested rewrite results in the same error.
That's unfortunate. The following doesn't warn for me (but make
sure it's an identity transform):
if (p > a && p < a + 10) {
a[p - a - 1] = 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
[Bug other/44286] Use sentinel attributes in GCC
--- 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||rwild at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |rwild at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-28 16:35:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44286
[Bug lto/44312] lto-streamer-in.c: In function �lto_read_tree�: warning: �fv.mode� is used uninitialized in this function
--- 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 AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-05-28 14:51:03 |2010-05-28 16:32:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44312
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- 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 well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug bootstrap/44315] [4.6 Regression] Circular build/gencondmd.o <- insn-flags.h dependency dropped
-- 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
[Bug c/44300] Spurious array subscript warning
--- 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 believe, but I'm no standards lawyer. Your suggested rewrite results in the same error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
[Bug bootstrap/44315] [4.6 Regression] Circular build/gencondmd.o <- insn-flags.h dependency dropped
--- 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 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-28 15:53:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44315
[Bug bootstrap/44315] New: [4.6 Regression] Circular build/gencondmd.o <- insn-flags.h dependency dropped
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- flags.h dependency dropped Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44315
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- 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=20770&action=view) First version of an updated patch So I thought I'd post the current state of the patch I am working on. This patch fixes some issues I noticed about the initial patch, namely: - The crashes I have noticed while trying to bootstrap c and c++ - Some little issues here and there. Enough to pass bootstrap for C and C++. I haven't tried bootstrapping the other FEs yet. There are still some caveats: * I have added an -fdebug-cpp option that (very) verbosely clutters the output of -E. This is useful for me, for debugging purposes. I think the final patch should have this option removed. * There are still some regression tests that are failing because they need updating. * I still need to add an option to disable the macro token location tracking. * The patch still does not handle token pasting It's true that is still work in progress, but I'd appreciate comments especially if you notice that I am doing something wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- 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=20769&action=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 recent trunk. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #20163|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug bootstrap/44314] Powerpc64-unknown-linux-gnu bootstrap broken
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44314
[Bug bootstrap/44314] Powerpc64-unknown-linux-gnu bootstrap broken
--- 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=gcc&view=rev&rev=159978 Log: PR bootstrap/44314 * config/alpha/linux.h, config/rs6000/linux.h, config/rs6000/linux64.h (OPTION_GLIBC): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/linux.h trunk/gcc/config/rs6000/linux.h trunk/gcc/config/rs6000/linux64.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44314
[Bug lto/44312] lto-streamer-in.c: In function �lto_read_tree�: warning: �fv.mode� is used uninitialized in this function
--- 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 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-28 14:51:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44312
[Bug tree-optimization/44306] [4.6 Regression] 464.h264ref fails to build.
--- 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 gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-05-28 14:05:45 |2010-05-28 14:46:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44306
[Bug tree-optimization/44303] [graphite] Segmentation fault within CLooG
--- 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 AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-05-28 14:04:12 |2010-05-28 14:46:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44303
[Bug c/44300] Spurious array subscript warning
--- 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;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
[Bug c/44300] Spurious array subscript warning
--- 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
[Bug c++/44313] g++ no longer warns about private copy constructors
--- 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 -std=c++98 -pedantic. This is low priority. -- ian at airs dot com changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44313
[Bug bootstrap/44314] New: Powerpc64-unknown-linux-gnu bootstrap broken
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 -save-temps -H -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-vari adic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/meissner/fsf-src/trunk/gcc -I/home/meissner/fsf-src/trunk/gcc/. -I/home/meissner/fs f-src/trunk/gcc/../include -I/home/meissner/fsf-src/trunk/gcc/../libcpp/include -I/home/meissner/tools/ppc64/include -I/home/meissner/tools/ppc64/include -I/home/meissner/tools/ppc64/include -I/home/ meissner/fsf-src/trunk/gcc/../libdecnumber -I/home/meissner/fsf-src/trunk/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/meissner/tools/ppc64/include -I/home/meissner/tools/ppc64/include -DCLOOG_P PL_BACKEND -I/home/meissner/tools/ppc64/include -I/home/meissner/tools/ppc64/include/libelf /home/meissner/fsf-src/trunk/gcc/c-common.c -o c-common.o . ./config.h .. ./auto-host.h .. /home/meissner/fsf-src/trunk/gcc/../include/ansidecl.h . /home/meissner/fsf-src/trunk/gcc/system.h .. /usr/lib64/gcc/powerpc64-suse-linux/4.3/include/stdarg.h .. /usr/lib64/gcc/powerpc64-suse-linux/4.3/include/stddef.h .. /usr/include/stdio.h ... /usr/include/features.h /usr/include/sys/cdefs.h . /usr/include/bits/wordsize.h /usr/include/gnu/stubs.h . /usr/include/bits/wordsize.h . /usr/include/gnu/stubs-64.h ... /usr/lib64/gcc/powerpc64-suse-linux/4.3/include/stddef.h ... /usr/include/bits/types.h /usr/include/bits/wordsize.h /usr/include/bits/typesizes.h ... /usr/include/libio.h /usr/include/_G_config.h . /usr/lib64/gcc/powerpc64-suse-linux/4.3/include/stddef.h . /usr/include/wchar.h ... /usr/include/bits/stdio_lim.h ... /usr/include/bits/sys_errlist.h ... /usr/include/bits/stdio.h .. /home/meissner/fsf-src/trunk/gcc/../include/safe-ctype.h ... /usr/include/ctype.h /usr/include/endian.h . /usr/include/bits/endian.h . /usr/include/bits/byteswap.h /usr/include/xlocale.h .. /usr/include/sys/types.h ... /usr/include/time.h ... /usr/lib64/gcc/powerpc64-suse-linux/4.3/include/stddef.h ... /usr/include/sys/select.h /usr/include/bits/select.h /usr/include/bits/sigset.h /usr/include/time.h /usr/include/bits/time.h ... /usr/include/sys/sysmacros.h ... /usr/include/bits/pthreadtypes.h /usr/include/bits/wordsize.h .. /usr/include/errno.h ... /usr/include/bits/errno.h /usr/include/linux/errno.h . /usr/include/asm/errno.h .. /usr/include/asm-generic/errno.h ... /usr/include/asm-generic/errno-base.h .. /usr/include/string.h ... /usr/lib64/gcc/powerpc64-suse-linux/4.3/include/stddef.h ... /usr/include/bits/string.h ... /usr/include/bits/string2.h .. /usr/include/strings.h .. /usr/include/stdlib.h ... /usr/lib64/gcc/powerpc64-suse-linux/4.3/include/stddef.h ... /usr/include/bits/waitflags.h ... /usr/include/bits/waitstatus.h ... /usr/include/alloca.h /usr/lib64/gcc/powerpc64-suse-linux/4.3/include/stddef.h .. /usr/include/unistd.h ... /usr/include/bits/posix_opt.h ... /usr/include/bits/environments.h /usr/include/bits/wordsize.h ... /usr/lib64/gcc/powerpc64-suse-linux/4.3/include/stddef.h ... /usr/include/bits/confname.h ... /home/meissner/fsf-src/trunk/gcc/../include/getopt.h .. /usr/include/sys/param.h ... /usr/lib64/gcc/powerpc64-suse-linux/4.3/include-fixed/limits.h /usr/lib64/gcc/powerpc64-suse-linux/4.3/include-fixed/syslimits.h . /usr/lib64/gcc/powerpc64-suse-linux/4.3/include-fixed/limits.h .. /usr/include/limits.h ... /usr/include/bits/posix1_lim.h /usr/include/bits/local_lim.h . /usr/include/linux/limits.h ... /usr/include/bits/posix2_lim.h ... /usr/include/bits/xopen_lim.h /usr/include/bits/stdio_lim.h ... /usr/include/linux/param.h /usr/include/asm/param.h .. /usr/lib64/gcc/powerpc64-suse-linux/4.3/include-fixed/limits.h .. /home/meissner/fsf-src/trunk/gcc/hwint.h .. /usr/include/sys/time.h ... /usr/include/time.h ... /usr/include/bits/time.h .. /usr/include/time.h ... /usr/lib64/gcc/powerpc64-suse-linux/4.3/include/stddef.h ... /usr/include/bits/time.h .. /usr/include/fcntl.h ... /usr/include/bits/fcntl.h /usr/include/bits/uio.h ... /usr/include/sys/stat.h /usr/include/bits/stat.h . /usr/include/bits/wordsize.h .. /usr/include/sys/wait.h ... /usr/include/signal.h /usr/include/bits/sigset.h /usr/include/bits/signum.h /usr/include/bits/siginfo.h . /usr/include/bits/wordsize.h /usr/include/bits/sigaction.h /usr/include/bits/sigcontext.h . /usr/include/asm/sigcontext.h .. /usr/include/asm/ptrace.h .. /usr/include/asm/elf.h ... /usr/include/asm/types.h
[Bug c++/44313] New: g++ no longer warns about private copy constructors
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 to give the error was gcc 4.2. This seems ironic considering that we say "most popular compilers do not correctly implement this rule." I think we should give that error when -pedantic. -- Summary: g++ no longer warns about private copy constructors Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44313
[Bug tree-optimization/44306] [4.6 Regression] 464.h264ref fails to build.
--- 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 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-28 14:05:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44306
[Bug tree-optimization/44303] [graphite] Segmentation fault within CLooG
--- 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 |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44303
[Bug tree-optimization/44303] [graphite] Segmentation fault within CLooG
--- 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 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-28 14:04:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44303
[Bug debug/41048] bad DW_AT_data_member_location from g++
--- 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=gcc&view=rev&rev=159975 Log: PR debug/41048 * dwarf2out.c (double_int_type_size_in_bits): New function. (round_up_to_align): Change first argument and return value to double_int. (field_byte_offset): Work internally on double_ints. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41048
[Bug target/43636] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103
--- 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=gcc&view=rev&rev=159973 Log: PR target/43636 * builtins.c (expand_movstr): Use a temporary pseudo instead of target even when target is not NULL and not const0_rtx, but fails movstr predicate. * config/m32c/blkmov.md (movstr): Add predicate to first operand. * gcc.c-torture/compile/pr43636.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr43636.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/builtins.c branches/gcc-4_5-branch/gcc/config/m32c/blkmov.md branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43636
[Bug target/43636] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103
--- 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=gcc&view=rev&rev=159972 Log: PR target/43636 * builtins.c (expand_movstr): Use a temporary pseudo instead of target even when target is not NULL and not const0_rtx, but fails movstr predicate. * config/m32c/blkmov.md (movstr): Add predicate to first operand. * gcc.c-torture/compile/pr43636.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr43636.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/config/m32c/blkmov.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43636
[Bug lto/44312] lto-streamer-in.c: In function �lto_read_tree�: warning: �fv.mode� is used uninitialized in this function
--- 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 bitpack_d *bp, tree expr)
{
struct fixed_value fv;
fv.data.low = (HOST_WIDE_INT) bp_unpack_value (bp, HOST_BITS_PER_WIDE_INT);
fv.data.high = (HOST_WIDE_INT) bp_unpack_value (bp, HOST_BITS_PER_WIDE_INT);
TREE_FIXED_CST (expr) = fv; <= line 1634
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44312
[Bug lto/44312] lto-streamer-in.c: In function �lto_read_tree�: warning: �fv.mode� is used uninitialized in this function
--- 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 (bp, HOST_BITS_PER_WIDE_INT);
fv.data.high = (HOST_WIDE_INT) bp_unpack_value (bp, HOST_BITS_PER_WIDE_INT);
TREE_FIXED_CST (expr) = fv;
}
This is on x86-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44312
[Bug objc++/23616] obj-c++.dg/try-catch-[29].mm (objc exceptions are broken) fails with the GNU Runtime
--- 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=gcc&view=rev&rev=159971 Log: PR ObjC++/23616 * obj-c++.dg/try-catch-2.mm: Adjust xfail. * obj-c++.dg/try-catch-9.mm: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/obj-c++.dg/try-catch-2.mm trunk/gcc/testsuite/obj-c++.dg/try-catch-9.mm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23616
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- 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=20768&action=view) gcc-4.4 patch The underlying problem is that the load_toc_v4_PIC_1b rtl doesn't properly describe that its output depends both on the value of a symbol, _GLOBAL_OFFSET_TABLE_, and on its location. This could be fixed by using an unspec_volatile rather than unspec. I chose instead to add a label to the rtl. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug lto/44312] lto-streamer-in.c: In function �lto_read_tree�: warning: �fv.mode� is used uninitialized in this function
--- 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
[Bug middle-end/44308] ranlib: file: libbackend
--- 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. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44308
[Bug c/44310] utf8 quotes in warnings make them look like garbage in many contexts
--- 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
[Bug lto/44312] New: lto-streamer-in.c: In function �lto_read_tree�: warning: �fv.mode� is used uninitialized in this function
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 Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jay dot krell at cornell dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44312
[Bug c/44310] utf8 quotes in warnings make them look like garbage in many contexts
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44310
[Bug c++/44311] New: no error with switch over enum class and integer case
$ 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
I think there should be a compile error in line 8.
--
Summary: no error with switch over enum class and integer case
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44311
[Bug c/44310] New: utf8 quotes in warnings make them look like garbage in many contexts
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
#if defined HAVE_LANGINFO_CODESET
if (locale_utf8)
{
open_quote = "\xe2\x80\x98";
close_quote = "\xe2\x80\x99";
}
#endif
}
Perhaps I need to:
.bashrc:
export LOCALE=C
or somesuch..
Perhaps if gcc detects any characters over 127 in any of the source files or
perhaps headers, it could switch into this wierdo character set mode, but not
otherwise? (Given I don't control the headers, only my source, that may be
overly eager.)
--
Summary: utf8 quotes in warnings make them look like garbage in
many contexts
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot krell at cornell dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44310
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- 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
[Bug bootstrap/44304] Building gcc 4.5.0 under Snow Leopard : stages 2 & 3 differ
--- 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 /opt/gcc/omp_build_w_fail7/stage2-x86_64-apple-darwin10.3.0/libgomp/config.log | #define HAVE_TLS 1 | #define HAVE_TLS 1 | #define HAVE_TLS 1 | #define HAVE_TLS 1 gcc_cv_have_tls=yes #define HAVE_TLS 1 [macbook] f90/bug% grep -i tls /opt/gcc/omp_build_w_fail7/stage2-x86_64-apple-darwin10.3.0/i386/libgomp/config.log gcc_cv_have_tls=no [macbook] f90/bug% grep -i tls /opt/gcc/omp_build_w_fail7/stage3-x86_64-apple-darwin10.3.0/libgomp/config.log | #define HAVE_TLS 1 | #define HAVE_TLS 1 | #define HAVE_TLS 1 | #define HAVE_TLS 1 gcc_cv_have_tls=yes #define HAVE_TLS 1 [macbook] f90/bug% grep -i tls /opt/gcc/omp_build_w_fail7/stage3-x86_64-apple-darwin10.3.0/i386/libgomp/config.log | #define HAVE_TLS 1 | #define HAVE_TLS 1 | #define HAVE_TLS 1 | #define HAVE_TLS 1 gcc_cv_have_tls=yes #define HAVE_TLS 1 AFAICT "gcc_cv_have_tls=no" can occur at stage 2 or 3 and in the main lib or in the i386 one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44304
[Bug bootstrap/44304] Building gcc 4.5.0 under Snow Leopard : stages 2 & 3 differ
--- 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 machine as a well (a Mac Mini) which randomly fails the bootstrap comparison. Oddly I haven't seen this on my MacPro. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44304
[Bug tree-optimization/44290] [4.5 Regression] arm linux kernel crahes when built with -fipa-sra
--- 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 /sbin/init. HIGHMEM enabled or not makes no difference. The same kernel compiled with gcc-4.4.4 boots fine. Both gcc's were configured for armv5tel-unknown-linux-gnu --with-arch=armv5te --with-tune=xscale. The linux kernels were built for mach-iop32x/n2100 (XScale IOP80219). I note that copypage-xscale.c:xscale_mc_copy_user_highpage() calls a __naked function to do the bulk copy. Converting that to a plain inline function (changing 'pc' to 'lr' in the final instruction that restores the scrach regs), does not prevent the crash. So I suspect a plain C code miscompilation. I'll try to bisect it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc
--- 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: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44307
[Bug bootstrap/44299] Bootstrap broken for cygwin and mingw targets
--- 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=gcc&view=rev&rev=159965 Log: 2010-05-28 Kai Tietz PR bootstrap/44299 * config/i386/t-cygming: Adjust header dependencies for winnt-cxx.c. * config/i386/winnt-cxx.c (IN_GCC_FRONTEND): Remove undefine. * config/i386/winnt.c (IN_GCC_FRONTEND): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/t-cygming trunk/gcc/config/i386/winnt-cxx.c trunk/gcc/config/i386/winnt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44299
[Bug c/44309] New: ../../gcc-4.5/gcc/config/t-darwin:25: warning: overriding commands for target `darwin.o'
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 for target `darwin-c.o' ../../gcc-4.5/gcc/config/t-darwin:31: warning: ignoring old commands for target `darwin-c.o' ../../gcc-4.5/gcc/config/t-darwin:35: warning: overriding commands for target `darwin-f.o' ../../gcc-4.5/gcc/config/t-darwin:35: warning: ignoring old commands for target `darwin-f.o' ../../gcc-4.5/gcc/config/t-darwin:40: warning: overriding commands for target `darwin-driver.o' ../../gcc-4.5/gcc/config/t-darwin:40: warning: ignoring old commands for target `darwin-driver.o' ../../gcc-4.5/gcc/config/t-darwin:48: warning: overriding commands for target `crt3.o' ../../gcc-4.5/gcc/config/t-darwin:48: warning: ignoring old commands for target `crt3.o' -- Summary: ../../gcc-4.5/gcc/config/t-darwin:25: warning: overriding commands for target `darwin.o' Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jay dot krell at cornell dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44309
[Bug c/44308] New: ranlib: file: libbackend
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: libbackend.a(graphite-dependences.o) has no symbols ranlib: file: libbackend.a(graphite-interchange.o) has no symbols ranlib: file: libbackend.a(graphite-poly.o) has no symbols ranlib: file: libbackend.a(graphite-ppl.o) has no symbols ranlib: file: libbackend.a(graphite-scop-detection.o) has no symbols ranlib: file: libbackend.a(graphite-sese-to-poly.o) has no symbols ranlib: file: libbackend.a(loop-doloop.o) has no symbols ranlib: file: libbackend.a(vmsdbgout.o) has no symbols ranlib: file: libbackend.a(xcoffout.o) has no symbols What I've done is at the end of each of them is put: char quash_apple_ranlib_warning_foo; Where "foo" is chosen from the file's non-static symbols. I didn't see insn-peep.c, it is presumably generated, so I didn't fix it. -- Summary: ranlib: file: libbackend Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jay dot krell at cornell dot edu GCC build triplet: ranlib: file: libbackend.a(xcoffout.o) has no symbols http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44308
[Bug tree-optimization/44306] [4.6 Regression] 464.h264ref fails to build.
--- 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];
int InvLevelScale8x8Luma_Inter[6][8][8];
short UseDefaultScalingMatrix8x8Flag[2];
void CalculateQuant8Param()
{
int i, j, k, temp;
int present[2];
for(k=0; j<8; j++)
for(i=0; i<8; i++)
{
temp = (i<<3)+j;
if((!present[0]) || UseDefaultScalingMatrix8x8Flag[0])
{
LevelScale8x8Luma_Intra[k][j][i] = (quant_coef8[k][j][i]<<4);
InvLevelScale8x8Luma_Intra[k][j][i] = dequant_coef8[k][j][i];
}
if((!present[1]) || UseDefaultScalingMatrix8x8Flag[1])
{
LevelScale8x8Luma_Inter[k][j][i] = (quant_coef8[k][j][i]<<4);
InvLevelScale8x8Luma_Inter[k][j][i] = dequant_coef8[k][j][i];
}
}
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44306
[Bug c/44307] warning: may be used uninitialized in this function often building gcc
--- 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 succeed. Still, might be nice to cleanup. This the default gcc on MacOSX 10.5/x86. jay$ gcc -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5493) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44307
[Bug c/44307] warning: may be used uninitialized in this function often building gcc
--- 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
[Bug c/44307] New: warning: may be used uninitialized in this function often building gcc
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 uninitialized in this function
ebitmap.c: In function ebitmap_and_compl:
ebitmap.c:876: warning: i may be used uninitialized in this function
ebitmap.c: In function ebitmap_and_into:
ebitmap.c:425: warning: i may be used uninitialized in this function
ebitmap.c: In function ebitmap_and:
ebitmap.c:479: warning: i may be used uninitialized in this function
ebitmap.c: In function ebitmap_and_compl_into:
ebitmap.c:796: warning: i may be used uninitialized in this function
ira.c:1623: warning: a may be used uninitialized in this function
ira.c:1588: warning: a may be used uninitialized in this function
ira.c:1656: warning: a may be used uninitialized in this function
ira-build.c: In function ira_flattening:
ira-build.c:2468: warning: a may be used uninitialized in this function
ira-build.c:720: warning: a may be used uninitialized in this function
ira-build.c:2469: warning: cp may be used uninitialized in this function
ira-build.c:347: warning: a may be used uninitialized in this function
ira-build.c: In function print_copies:
ira-build.c:1233: warning: cp may be used uninitialized in this function
ira-build.c: In function ira_destroy:
ira-build.c:1294: warning: cp may be used uninitialized in this function
ira-build.c:1008: warning: a may be used uninitialized in this function
ira-build.c: In function remove_unnecessary_regions:
ira-build.c:2007: warning: a may be used uninitialized in this function
ira-build.c: In function ira_build:
ira-build.c:2119: warning: a may be used uninitialized in this function
ira-build.c:2358: warning: a may be used uninitialized in this function
ira-build.c:2170: warning: a may be used uninitialized in this function
ira-build.c:2252: warning: a may be used uninitialized in this function
ira-build.c:2797: warning: a may be used uninitialized in this function
ira-build.c:2823: warning: a may be used uninitialized in this function
ira-costs.c: In function ira_tune_allocno_costs_and_cover_classes:
ira-costs.c:1728: warning: a may be used uninitialized in this function
ira-costs.c: In function find_costs_and_classes:
ira-costs.c:1181: warning: a may be used uninitialized in this function
ira-costs.c:1062: warning: a may be used uninitialized in this function
ira-costs.c: In function ira_costs:
ira-costs.c:1537: warning: a may be used uninitialized in this function
ira-conflicts.c: In function build_allocno_conflicts:
ira-conflicts.c:566: warning: i may be used uninitialized in this function
ira-conflicts.c: In function print_conflicts:
ira-conflicts.c:698: warning: conflict_a may be used uninitialized in this
function
ira-conflicts.c:692: warning: a may be used uninitialized in this function
ira-conflicts.c: In function ira_build_conflicts:
ira-conflicts.c:73: warning: allocno may be used uninitialized in this
function
ira-conflicts.c:533: warning: cp may be used uninitialized in this function
ira-conflicts.c:763: warning: a may be used uninitialized in this function
ira-color.c: In function update_conflict_hard_regno_costs:
ira-color.c:325: warning: divisor may be used uninitialized in this function
ira-color.c:330: warning: allocno may be used uninitialized in this function
ira-color.c: In function ira_color:
ira-color.c:3334: warning: a may be used uninitialized in this function
ira-color.c:2112: warning: a may be used uninitialized in this function
ira-color.c:3265: warning: a may be used uninitialized in this function
ira-color.c: In function push_allocno_to_stack:
ira-color.c:865: warning: conflict_allocno may be used uninitialized in this
function
ira-color.c: In function assign_hard_reg:
ira-color.c:449: warning: conflict_allocno may be used uninitialized in this
function
ira-color.c: In function ira_reassign_conflict_allocnos:
ira-color.c:2281: warning: conflict_a may be used uninitialized in this
function
ira-color.c:2281: warning: a may be used uninitialized in this function
ira-color.c: In function ira_reassign_pseudos:
ira-color.c:2867: warning: conflict_a may be used uninitialized in this
function
ira-color.c: In function coalesce_allocnos:
ira-color.c:1554: warning: conflict_allocno may be used uninitialized in this
function
ira-color.c: In function ira_sort_regnos_for_alter_reg:
ira-color.c:2618: warning: a may be used uninitialized in this function
ira-color.c: In function color_pass:
ira-color.c:1397: warning: conflict_allocno may be used uninitialized in this
function
In my copy I just put " = { 0 }" after each of these.
(Ignoring which particular ones needed it and just
going by variable names alone, ignoring scope.)
I'm using -disable-bo
[Bug tree-optimization/44306] New: [4.6 Regression] 464.h264ref fails to build.
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 /space/rguenther/src/svn/trunk/gcc/tree-if-conv.c:172 172 new_cond = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, (gdb) l 167 /* Add the condition COND to the e->aux field. In case the edge 168 destination is a PHI node, this condition will be added to 169 the block predicate to construct a complete condition. */ 170 e->aux = cond; 171 172 new_cond = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, 173 unshare_expr (prev_cond), cond); so unsharing never finishes (well, or maybe we just endlessly add conds here - which is equally bad). -- Summary: [4.6 Regression] 464.h264ref fails to build. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44306
[Bug bootstrap/44305] New: warning: cast discards qualifiers from pointer target type -- -disable-bootstrap should not use -Wcast-qual
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 ../../gcc-4.5/gcc/gimple.h: In function gimple_op_ptr: ../../gcc-4.5/gcc/gimple.h:1651: warning: cast discards qualifiers from pointer target type Yes, I realize it is dependent on host compiler (Apple gcc 4.0.1 in my case) and that I'm using -disable-bootstrap. I would suggest -disable-bootstrap should not pass -Wcast-qual, and that "regular" should not pass it in the first pass. Unless there is another way, like __extension__ or _Pragma or #pragma GCC can quash it on known places. -- Summary: warning: cast discards qualifiers from pointer target type -- -disable-bootstrap should not use -Wcast-qual Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jay dot krell at cornell dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44305
[Bug c/44300] Spurious array subscript warning
--- 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. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
[Bug bootstrap/44299] Bootstrap broken for cygwin and mingw targets
--- 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 changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44299
[Bug other/37515] [meta-bug] GCC 4.5 pending patches
--- 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 |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37515
[Bug rtl-optimization/21803] [ia64] gcc produces really odd predicated code
--- 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 |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21803
[Bug bootstrap/44299] Bootstrap broken for cygwin and mingw targets
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44299
[Bug libgcj/44296] libjavamath not using just built libgmp
--- 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
[Bug bootstrap/44304] Building gcc 4.5.0 under Snow Leopard : stages 2 & 3 differ
--- 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 : http://gcc.gnu.org/install/prerequisites.html x86_64-apple-darwin10 will not build gcc properly with the auto* tools installed - you must ensure that the required versions are found. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44304
[Bug target/44266] stack frame lacks parameter save area
--- 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=gcc&view=rev&rev=159963 Log: PR target/44266 * config/rs6000/rs6000.c (rs6000_legitimize_tls_address): Use emit_library_call machinery to set up __tls_get_addr calls. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44266
[Bug libstdc++/21321] [4.3/4.4/4.5/4.6 regression] mmix-knuth-mmixware 27_io/basic_filebuf/seekpos/12790-3.cc execution test
--- 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 |Added Status|REOPENED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321
[Bug bootstrap/44304] New: Building gcc 4.5.0 under Snow Leopard : stages 2 & 3 differ
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, Laurent Delphin, Dunkerque (EU) -- Summary: Building gcc 4.5.0 under Snow Leopard : stages 2 & 3 differ Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doc0 dot delphin at voila dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44304
[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
[Bug tree-optimization/44303] New: [graphite] Segmentation fault within CLooG
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=,
strided_level=, nb_par=,
stride=, offset=) at
source/ppl/domain.c:2813
2813 cloog_vector_gcd (U->p[0], U->NbColumns, stride);
GCC built with : cloog-ppl-0.15.9 ; gmp-4.3.2 ; mpc-0.8.1 ; mpfr-2.4.2 ;
ppl-0.10.2
The crash seems to be very specific to this value of N.
#define N 4
int A[N][N][N];
void
kernel ( void )
{
unsigned int i, j, k;
for ( i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=44303
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
-- amodra at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-05-18 08:26:21 |2010-05-28 07:30:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86
--- 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=20767&action=view) Patch that makes loop invariant prefetches backend specfic Three observations: 1. the patch had a bug which let to wrong calculation in some cases This commit should be applied to improve some other testcases: http://gcc.gnu.org/viewcvs?view=revision&revision=159816 2. The first patch was written in a way to allow the backend to enable this feature or not. Feedback was given that this should not be backend specific. Here is a patch that makes this feature backend specific again. We enable this on s390 since useless prefetches are pretty cheap. 3. As a long term goal we could enhance profile directed feedback to make this decision better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
[Bug bootstrap/44229] [4.6 Regression] 1 new GCC h...@159608 regression
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229
