[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- 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 isn't an alignment issue, and neiter it was a gcc-bug. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug target/42951] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- 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 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-04 09:55:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42951
[Bug rtl-optimization/42952] [4.5 Regression] possible integer wrong code bug
--- 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)
abort ();
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |rtl-optimization
Ever Confirmed|0 |1
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
GCC target triplet|i686-pc-linux-gnu |i?86-*-* x86_64-*-*
Priority|P3 |P1
Last reconfirmed|-00-00 00:00:00 |2010-02-04 10:03:02
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42952
[Bug rtl-optimization/42952] [4.5 Regression] possible integer wrong code bug
--- 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 groups:
**scanning insn=9
cselib value 2 0x10f8e58 (reg/f:DI 63 [ q ])
cselib lookup (reg/f:DI 63 [ q ]) = 2
mem: (reg/f:DI 63 [ q ])
after canon_rtx address: (mem/u/f/c/i:DI (symbol_ref:DI (q) [flags 0x2]
var_decl 0x75ae7140 q) [0 q+0 S8 A64])
gid=2 offset=0
processing const load gid=2[0..4)
mems_found = 0, cannot_delete = true
cselib lookup (mem:SI (reg/f:DI 63 [ q ]) [0 S4 A32]) = 0
**scanning insn=10
cselib lookup (reg/f:DI 58 [ p.0 ]) = 1
mem: (reg/f:DI 58 [ p.0 ])
after canon_rtx address: (mem/u/f/c/i:DI (symbol_ref:DI (p) [flags 0x2]
var_decl 0x75ae70a0 p) [0 p+0 S8 A64])
gid=1 offset=0
processing const base store gid=1[0..4)
trying store in insn=7 gid=1[0..4)
just because the addresses are MEM_READONLY_P. But that obviously does not
mean they do not point to the same thing - no idea what implementor had
in mind here. Kenny?
The following fixes this for me:
Index: dse.c
===
--- dse.c (revision 156468)
+++ dse.c (working copy)
@@ -1015,9 +1015,6 @@ const_or_frame_p (rtx x)
{
switch (GET_CODE (x))
{
-case MEM:
- return MEM_READONLY_P (x);
-
case CONST:
case CONST_INT:
case CONST_DOUBLE:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||zadeck at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42952
[Bug rtl-optimization/42952] [4.5 Regression] possible integer wrong code bug
--- 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). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42952
[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none
--- 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 perhaps a bit more aggressive than it needs to be, but it should solve the problem generically rather than requiring each back-end to implement hacks for what is really a MI issue. Could someone test this on PPC? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- 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 ldr r2, [r1, #0] [...] Ug, on a dual-issue core with load delay slots that code will REALLY suck. there's almost nothing that can be dual issued and the loaded values are used in the instruction immediately after the load. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- 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 AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-05-20 13:19:56 |2010-02-04 11:21:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug middle-end/42290] strange 'warning: ISRA.2 may be used uninitialized in this function'
--- 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 |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42290
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- 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
[Bug fortran/42954] New: gfortran with libcpp: TARGET_*_CPP_BUILDINS issues (MinGW, FreeBSD, MIPS, Fry)
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 above). [config/i386/mingw32.h, config/i386/cygming.h] - other platforms (not as popular) break similarly [grep for 'builtin_define_with_int_value' in gcc/config/] TARGET_CPU_CPP_BUILTINS (); TARGET_OS_CPP_BUILTINS (); TARGET_OBJFMT_CPP_BUILTINS (); */ Grepping for builtin_define_with_int_value shows: gcc/config/frv/frv.h gcc/config/i386/mingw32.h gcc/config/mips/mips.h gcc/config/freebsd-spec.h Expected: The macros which make only sense for C are only used for C, e.g. many of the __attribute__(()) ones. -- Summary: gfortran with libcpp: TARGET_*_CPP_BUILDINS issues (MinGW, FreeBSD, MIPS, Fry) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954
[Bug fortran/42950] gfortran testsuite failures on mingw64
--- 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 macros assume to be used in c-cppbuiltin.c only. Further, they use flags only valid/defined in C (same as noted above). [config/i386/mingw32.h, config/i386/cygming.h] - other platforms (not as popular) break similarly [grep for 'builtin_define_with_int_value' in gcc/config/] TARGET_CPU_CPP_BUILTINS (); TARGET_OS_CPP_BUILTINS (); TARGET_OBJFMT_CPP_BUILTINS (); */ Regarding (4)/(5): The NaN problems might be because we do not use __USE_MINGW_ANSI_STDIO=1 or _POSIX which is needed for POSIX compatible printf routines. Cf. http://sourceforge.net/project/shownotes.php?release_id=24832 Even if it is not the issue, it presumably makes sense to define it. -- burnus at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||42954 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42950
[Bug fortran/36380] preprocessing: define built-in target-related macros
--- 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 Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36380
[Bug fortran/42954] gfortran with libcpp: TARGET_*_CPP_BUILDINS issues (MinGW, FreeBSD, MIPS, Fry)
--- 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
[Bug regression/42955] New: undecorated cross-compiler gcc fails to find cc1
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: $ /usr/sparc-sun-solaris2.10/bin/gcc -print-prog-name=cc1 cc1 $ /usr/sparc-sun-solaris2.10/bin/gcc -print-search-dirs install: /usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/ programs: =/usr/sparc-sun-solaris2.10/bin/../libexec/gcc/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/bin/../libexec/gcc/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/bin/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/bin/ libraries: =/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/lib/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/lib/:/usr/sparc-sun-solaris2.10/sys-root/lib/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/sys-root/lib/:/usr/sparc-sun-solaris2.10/sys-root/usr/lib/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/sys-root/usr/lib/ (quick summary: the required path /usr/libexec/gcc/sparc-sun-solaris2.10/4.4.3/ is not in there) The decorated compiler works just fine though: $ /usr/bin/sparc-sun-solaris2.10-gcc -print-prog-name=cc1 /usr/libexec/gcc/sparc-sun-solaris2.10/4.4.3/cc1 Further digging seems to indicate that this was caused by r118765, where the configured in paths only are added if the binary is in $(bindir). I'm hoping this is only an oversight and someone forgot about this extra bindir for cross-compilers as this regression is causing quite a bit of pain here. -- Summary: undecorated cross-compiler gcc fails to find cc1 Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ossman at cendio dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
[Bug fortran/42954] gfortran with libcpp: TARGET_*_CPP_BUILDINS issues (MinGW, FreeBSD, MIPS, Fry)
--- 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__ (after stripping leading _) ignoring the unmodified version? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954
[Bug c/42956] New: internal compiler error: Segmentation fault with -O1
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 -I../Cuba-1.6/src/common -I. -I../Cuba-1.6 -I../Cuba-1.6/src/divonne -c -o Divonne.o ../Cuba-1.6/src/divonne/Divonne.c In file included from ../Cuba-1.6/src/divonne/common.c:19, from ../Cuba-1.6/src/divonne/Divonne.c:41: ../Cuba-1.6/src/divonne/Split.c: In function 'Split': ../Cuba-1.6/src/divonne/Split.c:275: internal compiler error: Segmentation fault This error occurs for gcc-4.4.3 with -O3, -O2, and -O1 but neither with -O0 nor for gcc-4.4.2 -- Summary: internal compiler error: Segmentation fault with -O1 Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peb at mppmu dot mpg dot de GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956
[Bug c/42956] internal compiler error: Segmentation fault with -O1
--- 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 |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956
[Bug c/42956] internal compiler error: Segmentation fault with -O1
--- 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
[Bug c/42956] internal compiler error: Segmentation fault with -O1
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-04 14:30:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956
[Bug c/34156] gcc ignores the __may_alias__ attribute on a struct typedef
--- 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 == IPPROTO_IP cmsgptr-cmsg_type == IP_PKTINFO) {
# define pktinfo(cmsgptr) ((struct in_pktinfo*)(CMSG_DATA(cmsgptr)))
to-sa_family = AF_INET;
memcpy(to4-sin_addr, pktinfo(cmsgptr)-ipi_addr, sizeof(to4-sin_addr));
I can't modify struct in_pktinfo declaration, it's in system header, so I
wanted to create a aliasing version of it, but this doesn't work for structs.
Distilled, the problem is that this works:
typedef int aliased_int __attribute__((__may_alias__));
but the same thing on structs does not, even if struct is hidden behind an
intermediate typedef:
struct s { int i; };
typedef struct s t;
typedef struct s aliased_s __attribute__((__may_alias__));
typedef t aliased_t __attribute__((__may_alias__));
last two typedefs both throw:
warning: ignoring attributes applied to 'struct s' after definition
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34156
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #12 from steven at gcc dot gnu dot org 2010-02-04 14:54 ---
With the patches from bug 42617 applied, I get the following:
.file tst.c
.text
.align 2
.global Unroll
.type Unroll, %function
Unroll:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r0, r0, asl #16
stmfd sp!, {r4, r5, r6, r7, r8}
mov r0, r0, asr #16
add r8, r1, #256
.L2:
ldr ip, [r1, #0]
mov r7, r1
mul r2, ip, r0
str r2, [r7], #4
ldr r3, [r1, #4]
ldr r5, [r7, #4]
mul r6, r3, r0
str r6, [r7, #0]
ldr r4, [r1, #12]
ldr ip, [r1, #16]
add r2, r1, #20
ldmia r2, {r2, r3, r7}@ phole ldm
mul r6, r5, r0
mul r5, r4, r0
mul r4, ip, r0
mul ip, r2, r0
mul r2, r3, r0
mul r3, r7, r0
str r6, [r1, #8]
str r5, [r1, #12]
str r4, [r1, #16]
str ip, [r1, #20]
str 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: -std=c99 -mcpu=arm9 -O2 -funroll-loops)
This is good but not perfect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- 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
[Bug rtl-optimization/42952] [4.5 Regression] possible integer wrong code bug
--- 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
[Bug rtl-optimization/42952] [4.5 Regression] possible integer wrong code bug
--- 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 into different groups, or 2) fix this marvel in check_mem_read_rtx: if (group_id == store_info-group_id) ... /* else The else case that is missing here is that the bases are constant but different. There is nothing to do here because there is no overlap. */ Clearly the comment is wrong, base addresses can be constant, different for rtx_equal purposes, but still be the same at runtime. When going the (2) way we would need to ask the oracle, which most of the time would probably say don't know anyway, and be slow. Hence not regarding such base addresses as interesting for the global problem seems to be the better fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42952
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- 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 ]) (mem:SI (reg:SI 179 [ ivtmp.20 ]) [2 *D.1846_29 S4 A32])) -1 (nil)) ;; ivtmp.20_24 = ivtmp.20_25 + 4; (insn 53 52 0 tst.c:6 (set (reg:SI 179 [ ivtmp.20 ]) (plus:SI (reg:SI 179 [ ivtmp.20 ]) (const_int 4 [0x4]))) -1 (nil)) ;; MEM[base: D.1847_30, offset: 4294967292] = D.1816_13; (insn 54 53 55 tst.c:6 (set (reg:SI 189) (mult:SI (reg:SI 172 [ D.1814 ]) (reg:SI 180 [ pretmp.11 ]))) -1 (nil)) (insn 55 54 0 tst.c:6 (set (mem:SI (plus:SI (reg:SI 179 [ ivtmp.20 ]) (const_int -4 [0xfffc])) [2 *D.1847_30 S4 A32]) (reg:SI 189)) -1 (nil)) ;; if (ivtmp.20_24 != D.1849_32) (insn 57 55 58 tst.c:4 (set (reg:CC 24 cc) (compare:CC (reg:SI 179 [ ivtmp.20 ]) (reg:SI 183 [ D.1849 ]))) -1 (nil)) (jump_insn 58 57 0 tst.c:4 (set (pc) (if_then_else (ne (reg:CC 24 cc) (const_int 0 [0x0])) (label_ref 56) (pc))) -1 (expr_list:REG_BR_PROB (const_int 9844 [0x2674]) (nil))) This yields the sequence: 52 r172:SI=[r179:SI] 53 r179:SI=r179:SI+0x4 54 r189:SI=r172:SI*r180:SI 55 [r179:SI-0x4]=r189:SI and we never get rid of this again. There is another bug related to this one: bug 31849. The patch there probably needs dusting off, and then I'll see if it improves things for this bug as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug rtl-optimization/42952] [4.3/4.4/4.5 Regression] possible integer wrong code bug
--- 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 |Added Priority|P1 |P2 Summary|[4.5 Regression] possible |[4.3/4.4/4.5 Regression] |integer wrong code bug |possible integer wrong code ||bug Target Milestone|4.5.0 |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42952
[Bug c/34156] gcc ignores the __may_alias__ attribute on a struct typedef
--- 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
[Bug tree-optimization/42956] [4.4/4.5 Regression] internal compiler error: Segmentation fault with -O1
--- 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 statement D.15203_353 = D.8489 /[ex] 8; ../Cuba-1.6/src/divonne/Split.c:275:13: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization Keywords||ice-on-valid-code Known to fail||4.4.3 4.5.0 Known to work||4.3.5 4.4.2 Summary|internal compiler error:|[4.4/4.5 Regression] |Segmentation fault with -O1 |internal compiler error: ||Segmentation fault with -O1 Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956
[Bug tree-optimization/42956] [4.4/4.5 Regression] internal compiler error: Segmentation fault with -O1
--- 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 Split(int iregion, int depth, int xregion)
{
typedef struct {
double avg, err, spread, chisq;
double xmin[ndim_], xmax[ndim_];
} Result;
typedef struct region {
Result result[ncomp_];
} Region;
Errors errors[ncomp_];
int comp, ireg, xreg;
double tmp;
for( ireg = iregion, xreg = xregion; ireg nregions_; ireg = xreg++ )
{
Result *result = ((Region *)voidregion_)[ireg].result;
for( comp = 0; comp ncomp_; ++comp )
{
Result *r = result[comp];
cErrors *e = errors[comp];
double c = tmp*e-diff;
if( r-err 0 ) r-err = r-err*e-err + c;
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956
[Bug tree-optimization/31849] [4.3/4.4/4.5 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)
--- 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 issues raised in this bug report, because it is unclear what code the OP is expecting from the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- 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
[Bug target/42957] New: ARM: Segfault when invalid -mfpu argument is specified.
r...@zoidberg:~/gnu/gcc/trunk/build/gcc$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnueabi
Configured with: ../configure --target=arm-unknown-linux-gnueabi
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi
--with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root
--enable-languages=c,c++ --disable-multilib --with-float=soft
--disable-sjlj-exceptions --enable-__cxa_atexit
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
--disable-nls --enable-threads=posix --enable-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: invalid floating point option: -mfpu=foo
t.c:1:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
(gdb) bt
#0 0x08a06fd6 in arm_override_options () at ../../gcc/config/arm/arm.c:1645
#1 0x087b7a6c in process_options () at ../../gcc/toplev.c:1810
#2 0x087b8528 in do_compile () at ../../gcc/toplev.c:2389
#3 0x087b8624 in toplev_main (argc=4, argv=0xb364)
at ../../gcc/toplev.c:2447
#4 0x083cd2ab in main (argc=4, argv=0xb364) at ../../gcc/main.c:35
Patch:
2010-02-04 Ryan Mansfield rmansfi...@qnx.com
PR target/x
* config/arm/arm.c (arm_override_options): Handle invalid arguments to
-mfpu.
Index: arm.c
===
--- arm.c (revision 156492)
+++ arm.c (working copy)
@@ -1292,6 +1292,7 @@
unsigned i;
enum processor_type target_arch_cpu = arm_none;
enum processor_type selected_cpu = arm_none;
+ const char *default_fpu_name;
/* Set up the flags based on the cpu/architecture selected by the user. */
for (i = ARRAY_SIZE (arm_select); i--;)
@@ -1618,29 +1619,31 @@
target_fpe_name);
}
- if (target_fpu_name == NULL)
-{
#ifdef FPUTYPE_DEFAULT
- target_fpu_name = FPUTYPE_DEFAULT;
+ default_fpu_name = FPUTYPE_DEFAULT;
#else
- if (arm_arch_cirrus)
- target_fpu_name = maverick;
- else
- target_fpu_name = fpe2;
+ if (arm_arch_cirrus)
+default_fpu_name = maverick;
+ else
+default_fpu_name = fpe2;
#endif
-}
arm_fpu_desc = NULL;
for (i = 0; i ARRAY_SIZE (all_fpus); i++)
{
- if (streq (all_fpus[i].name, target_fpu_name))
- {
- arm_fpu_desc = all_fpus[i];
- break;
- }
-}
- if (!arm_fpu_desc)
-error (invalid floating point option: -mfpu=%s, target_fpu_name);
+ if (streq (all_fpus[i].name, default_fpu_name))
+ arm_fpu_desc = all_fpus[i];
+ if (target_fpu_name)
+{
+ if (streq (all_fpus[i].name, target_fpu_name))
+ {
+ arm_fpu_desc = all_fpus[i];
+ break;
+ }
+ if (i == ARRAY_SIZE (all_fpus) - 1)
+ error (invalid floating point option: -mfpu=%s, target_fpu_name);
+}
+}
switch (arm_fpu_desc-model)
{
--
Summary: ARM: Segfault when invalid -mfpu argument is specified.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42957
[Bug rtl-optimization/42952] [4.3/4.4/4.5 Regression] possible integer wrong code bug
--- 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 rtl-optimization/42952 * dse.c (const_or_frame_p): Remove MEM handling. * gcc.dg/torture/pr42952.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr42952.c Modified: trunk/gcc/ChangeLog trunk/gcc/dse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42952
[Bug rtl-optimization/42952] [4.3/4.4/4.5 Regression] possible integer wrong code bug
--- 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 rtl-optimization/42952 * dse.c (const_or_frame_p): Remove MEM handling. * gcc.dg/torture/pr42952.c: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr42952.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/dse.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42952
[Bug rtl-optimization/42952] [4.3/4.4/4.5 Regression] possible integer wrong code bug
--- 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 rtl-optimization/42952 * dse.c (const_or_frame_p): Remove MEM handling. * gcc.dg/torture/pr42952.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr42952.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/dse.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42952
[Bug rtl-optimization/42952] [4.3/4.4/4.5 Regression] possible integer wrong code bug
--- 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 Status|ASSIGNED|RESOLVED Known to fail||4.3.4 4.4.3 Known to work||4.3.5 4.4.4 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42952
Re: [Bug target/30282] 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: --- 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 perhaps a bit more aggressive than it needs to be, but it should solve the problem generically rather than requiring each back- end to implement hacks for what is really a MI issue. Could someone test this on PPC? Well powerpc64 it is valid to move across the stack pointer if the stack is less than a specific size so this can cause regressions there. And will also cause a performance regressions on x86_64 also for the same reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none
--- 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: --- 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) -- (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 perhaps a bit more aggressive than it needs to be, but it should solve the problem generically rather than requiring each back- end to implement hacks for what is really a MI issue. Could someone test this on PPC? Well powerpc64 it is valid to move across the stack pointer if the stack is less than a specific size so this can cause regressions there. And will also cause a performance regressions on x86_64 also for the same reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
[Bug fortran/42958] New: Weird temporary array allocation
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;
D.1649 = D.1647 ? 0 : D.1648 * 8;
if (D.1649 0)
{
_gfortran_runtime_error (Attempt to allocate
a negative amount of memory.[1]{lb: 1 sz: 1});
}
D.1650 = (void * restrict) __builtin_malloc
(MAX_EXPR D.1649, 1);
if (D.1650 == 0B)
{
_gfortran_os_error (Memory allocation
failed[1]{lb: 1 sz: 1});
}
D.1651 = D.1650;
atmp.5.data = D.1651;
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 actually allocate max(1,size).
Why do we at all check for this negative amount allocation? Are you
trying to detect overflow here? (which won't work, you do the
computation with signed arithmetic so VRP will screw you anyway)
Why not simply do
size = (ubound - lbound + 1) * 8;
malloc (size);
which surely fails very quickly on you for negative size and the allocation
fails.
?
Surely for compiler-generated temporary allocations nothing more fancy
should be required (even the check of the allocation could be removed
when optimizing).
--
Summary: Weird temporary array allocation
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
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=42958
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- 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. -- davek at gcc dot gnu dot org changed: What|Removed |Added Attachment #19797|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug driver/42955] undecorated cross-compiler gcc fails to find cc1
--- 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 Component|regression |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
[Bug libstdc++/41861] [C++0x] condition_variable does not use monotonic_clock
--- 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. In other terms, I would add [DR 887] to the Subject and suspend. Agreed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861
[Bug libstdc++/42460] man page errors for generated libstdc++ man pages
--- 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 libstdc++/42460 * doc/doxygen/user.cfg.in: Update file list. * include/debug/safe_sequence.h: Doxygen markup fixes for '' and . * include/debug/safe_base.h: Same. * include/debug/macros.h: Same. * include/tr1_impl/regex: Same. * include/std/iostream: Same. * include/std/streambuf: Same. * include/std/bitset: Same. * include/std/iosfwd: Same. * include/std/limits: Same. * include/std/fstream: Same. * include/std/istream: Same. * include/std/ostream: Same. * include/std/sstream: Same. * include/parallel/multiway_merge.h: Same. * include/parallel/for_each.h: Same. * include/parallel/workstealing.h: Same. * include/parallel/omp_loop_static.h: Same. * include/parallel/omp_loop.h: Same. * include/c_std/csignal: Same. * include/c_std/cstdlib: Same. * include/c_std/cstdio: Same. * include/c_std/cstdarg: Same. * include/c_std/cctype: Same. * include/c_std/cerrno: Same. * include/c_std/cmath: Same. * include/c_std/ciso646: Same. * include/c_std/ctime: Same. * include/c_std/clocale: Same. * include/c_std/climits: Same. * include/c_std/cassert: Same. * include/c_std/csetjmp: Same. * include/c_std/cwchar: Same. * include/c_std/cfloat: Same. * include/c_std/cstring: Same. * include/c_std/cstddef: Same. * include/c_std/cwctype: Same. * include/profile/iterator_tracker.h: Same. * include/profile/impl/profiler_trace.h: Same. * include/ext/vstring.h: Same. * include/ext/algorithm: Same. * include/ext/pb_ds/detail/pat_trie_/pat_trie_.h.pp: Same. * include/ext/pb_ds/detail/bin_search_tree_/bin_search_tree_.h.pp: Same. * include/ext/pb_ds/detail/type_utils.hpp: Same. * include/ext/pb_ds/detail/splay_tree_/splay_tree_.hpp: Same * include/ext/pb_ds/detail/rb_tree_map_/rb_tree_.hpp: Same. * include/ext/rc_string_base.h: Same. * include/ext/stdio_sync_filebuf.h: Same. * include/ext/functional: Same. * include/ext/mt_allocator.h: Same. * include/bits/basic_ios.h: Same. * include/bits/stl_map.h: Same. * include/bits/stl_algobase.h: Same. * include/bits/stl_queue.h: Same. * include/bits/locale_classes.h: Same. * include/bits/stl_set.h: Same. * include/bits/locale_facets.h: Same. * include/bits/stl_stack.h: Same. * include/bits/stl_iterator_base_types.h: Same. * include/bits/basic_string.h: Same. * include/bits/stl_multimap.h: Same. * include/bits/ios_base.h: Same. * include/bits/stl_deque.h: Same. * include/bits/stl_multiset.h: Same. * include/bits/stl_iterator_base_funcs.h: Same. * include/bits/char_traits.h: Same. * include/bits/stl_algo.h: Same. * include/bits/stl_iterator.h: Same. * include/bits/stl_tempbuf.h: Same. * include/bits/random.tcc: Same. * include/bits/stl_function.h: Same. * include/bits/cpp_type_traits.h: Same. * include/bits/random.h: Same. * include/bits/allocator.h: Same. * include/bits/locale_facets_nonio.h: Same. * include/c_global/csignal: Same. * include/c_global/cstdlib: Same. * include/c_global/cstdio: Same. * include/c_global/cstdarg: Same. * include/c_global/cctype: Same. * include/c_global/cerrno: Same. * include/c_global/cmath: Same. * include/c_global/ciso646: Same. * include/c_global/ctime: Same. * include/c_global/clocale: Same. * include/c_global/climits: Same. * include/c_global/cassert: Same. * include/c_global/csetjmp: Same. * include/c_global/cwchar: Same. * include/c_global/cfloat: Same. * include/c_global/cstring: Same. * include/c_global/cstddef: Same. * include/c_global/cwctype: Same. * include/tr1/hypergeometric.tcc: Same. * include/tr1/random.tcc: Same. * include/tr1/functional: Same. * include/tr1/random.h: Same. * include/backward/auto_ptr.h: Same. * include/backward/binders.h: Same. * testsuite/23_containers/deque/requirements/dr438/assign_neg.cc: Adjust line numbers. * testsuite/23_containers/deque/requirements/dr438/insert_neg.cc: Same. * testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc: Same. *
[Bug libstdc++/42460] man page errors for generated libstdc++ man pages
--- 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 check these (or equivalent from trunk) please? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
[Bug libstdc++/42460] man page errors for generated libstdc++ man pages
-- 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 | Status|REOPENED|ASSIGNED Last reconfirmed|2010-01-07 18:40:02 |2010-02-04 18:28:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
[Bug libstdc++/42943] std::partial_sum performs improper casts
--- 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 Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42943
[Bug libstdc++/42943] std::partial_sum performs improper casts
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42943
[Bug libstdc++/22634] [DR 539] partial_sum is too constrained
--- 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 CC||potswa at mac dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
[Bug libstdc++/42460] man page errors for generated libstdc++ man pages
--- 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 another man implementation than Fedora, so I don't know if this option is available there as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
[Bug fortran/42958] Weird temporary array allocation
--- 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 actually allocate max(1,size).
The reason for the setting it to zero is that Fortran allows one to allocate a
zero-sized array: ALLOCATE ( Array(0:-2) )
The reason for MAX(1, size) is to make ALLOCATE(A(1:0)); if(ALLOCATED(A))
work. (This was added later than size 0 ? 0 : size.)
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.
* * *
Why not simply do
size = (ubound - lbound + 1) * 8;
malloc (size);
I think that would be the future: With the array descriptor (dope vector)
reform, we will have an allocated field and thus one can do:
descriptor.allocated = true
descriptor.data = malloc (max (0,size))
Where if(allocated(A)) translates into if(A.allocated).
Actually, maybe one should better use:
size = (ubound - lbound + 1)
if (size 0)
{
descriptor.data = malloc(size)
if (descriptor.data == NULL)
error (allocate failed);
}
descriptor.allocated = true
The allocated member of the descriptor is also needed in order to make the
following work properly:
integer, target :: int
integer, pointer :: ptr
ptr = int
deallocate(ptr, stat=i) ! shall return i != 0 but not crash
Thus, from my side: The negative check should be removed and the simplified
version should be applied after the descriptor update. Before the descriptor
update (planned for 4.6, breaks ABI) one can use:
size = (ubound - lbound + 1) * 8;
malloc (max(1,size));
Paul, what do you think?
(PS: POSIX Allows ptr = malloc(0); free(ptr), where malloc(0) returns
either NULL or a unique pointer.)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||pault at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug tree-optimization/41464] vector loads are unnecessarily split into high and low loads
--- 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? Also, this is interesting: http://eigen.tuxfamily.org/index.php?title=Benchmark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41464
[Bug debug/42959] New: g++ does not emit DW_AT_default_value
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 Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42959
[Bug libstdc++/42460] man page errors for generated libstdc++ man pages
--- 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
std::basic_istream.3cxx.gz 1002: warning: macro `)).' not defined
std::basic_istringstream.3cxx.gz 1025: warning: macro `)).' not defined
std::basic_stringstream.3cxx.gz 1202: warning: macro `)).' not defined
std::exponential_distribution.3cxx.gz 66: warning: numeric expression expected
(got `m')
std::gamma_distribution.3cxx.gz 79: normal or special character expected (got a
space)
std::linear_congruential_engine.3cxx.gz 82: warning: numeric expression
expected (got `f')
std::lognormal_distribution.3cxx.gz 79: warning: numeric expression expected
(got `r')
std::normal_distribution.3cxx.gz 79: warning: numeric expression expected (got
`g')
std::regex_constants.3cxx.gz 200: warning: macro `,' not defined
std::student_t_distribution.3cxx.gz 76: warning: numeric expression expected
(got `r')
std::weibull_distribution.3cxx.gz 69: normal or special character expected (got
a space)
The one class of quoting problems seems to be fixed.
remaining:
include/std/istream:403: Returns @c getline(s,n,widen(apos;\napos;))
include/std/istream:363: Returns @c getline(s,n,widen(apos;\napos;))
include/std/istream:330: Returns @c get(s,n,widen(apos;\napos;))
which translates to:
.PP
Returns \fCget\fP(sb,widen('
.br
')).
.PP
quoting the backslash, I get this output (man not complaining anymore)
templatetypename _CharT, typename _Traits __istream_type
std::basic_istream _CharT, _Traits ::get
(char_type * __s, streamsize __n) [inline, inherited]
Simple multiple-character extraction. Parameters:
s Pointer to an array.
n Maximum number of characters to store in s.
Returns:
*this
Returns get(s,n,widen('\n')).
Definition at line 333 of file istream.
the other errors in the *distribution man pages are from using latex macros.
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
[Bug libstdc++/42460] man page errors for generated libstdc++ man pages
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
[Bug c/42960] New: segfault internal compiler error when trying to compile latest linux kernel
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 set_lattice_value, at tree-ssa-ccp.c:471 Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. The bug is not reproducible, so it is likely a hardware or OS problem. make[3]: *** [drivers/hid/hid-apple.o] Error 1 make[2]: *** [drivers/hid] Error 2 make[1]: *** [drivers] Error 2 make: *** [sub-make] Error 2 GCC Version: $ gcc -v Using built-in specs. Target: i686-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i686 --build=i686-redhat-linux Thread model: posix gcc version 4.4.2 20091222 (Red Hat 4.4.2-20) (GCC) -- Summary: segfault internal compiler error when trying to compile latest linux kernel Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rvoicilas at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42960
[Bug c/42960] segfault internal compiler error when trying to compile latest linux kernel
--- 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 version of gcc has been modified to try compile it again and it cannot reproduce it on the second run through, it says it might be a hardware or OS issue so you might want to try testing your hardware first. Try memtest to see if your memory is bad. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42960
[Bug c/42960] segfault internal compiler error when trying to compile latest linux kernel
--- 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 report. Second since this version of gcc has been modified to try compile it again and it cannot reproduce it on the second run through, it says it might be a hardware or OS issue so you might want to try testing your hardware first. Try memtest to see if your memory is bad. I already did the memory test and my memories are just fine. And I have filled a fedora bug as well, but I hoped that I get more ideas here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42960
[Bug middle-end/42961] New: [4.5 regression] IRA register preferencing 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 that uncommon in real world
code)
we generate completely bogus:
main:
.LFB0:
.cfi_startproc
xorps %xmm2, %xmm2
movss %xmm1, -4(%rsp)
movl-4(%rsp), %eax
ucomiss %xmm2, %xmm2
jp .L7
je .L3
.L7:
movss %xmm0, -4(%rsp)
movl-4(%rsp), %eax
movaps %xmm1, %xmm2
.L3:
movlf(%rip), %edx
testl %edx, %edx
je .L4
movl%eax, -4(%rsp)
movss -4(%rsp), %xmm2
.L4:
movaps %xmm2, %xmm0
ret
instead of
main:
.LFB2:
movaps %xmm0, %xmm3
xorps %xmm0, %xmm0
movaps %xmm1, %xmm2
ucomiss %xmm0, %xmm0
jp .L2
je .L3
.L2:
movaps %xmm3, %xmm2
movaps %xmm1, %xmm0
.L3:
movlf(%rip), %eax
testl %eax, %eax
je .L4
movaps %xmm2, %xmm0
.L4:
rep
ret
.LFE2:
generated by GCC 4.3.2.
The problem is that IRA concludes wrong register preferencing:
a3 (r62,l0) best SSE_REGS, cover SSE_REGS
a2 (r61,l0) best SSE_FIRST_REG, cover SSE_REGS
a1 (r59,l0) best GENERAL_REGS, cover GENERAL_REGS
a0 (r58,l0) best SSE_FIRST_REG, cover SSE_REGS
this is because of movdf pattern having alternative for general regs.
This alternative is however useful primarily when the value is temporary for
mem-mem moves, and IRA should be able to work this out.
--
Summary: [4.5 regression] IRA register preferencing bug
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hubicka at gcc dot gnu dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42961
[Bug rtl-optimization/42962] New: Place constant strings in local constant pool
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 needs to load the GOT relative base address Compute GOT absolute base address load the string's GOT offset compute the string's absolute address gcc emits 4 instructions to get the address of the first string, and 2 instructions for following strings (because the GOT absolute address is the same for them). ARM RVCT is more efficient. RVCT places constant string right after the function in the code section. It only uses one instruction ADR to get the string address. 98 a03c ADR r0,|L1.396| 9a f7fe BL printf ... |L1.396| string constant \nMCF SPEC CPU2006 version 1.10\n Placing constant strings in global data section enables sharing the strings. But usually, there is little sharing for long strings. For short strings, the overhead of loading the short strings through GOT table almost overcome the savings of sharing the short strings. Shall we change the placement of constant strings? We can use an option to choose where to put constant strings. For ARM with -fpic, I think the benefit of placing constant strings in local constant pool is bigger than the cost. Any suggestion? -- Summary: Place constant strings in local constant pool Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jingyu at google dot com GCC build triplet: i686-linux-gnu, x86_64-pc-linux-gnu GCC host triplet: i686-linux-gnu, x86_64-pc-linux-gnu GCC target triplet: arm-unknown-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42962
[Bug c++/42915] [4.5 Regression] ICE: same canonical type node for different types in recent builds
--- 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
[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none
--- 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 stack pointer if the stack is less than a specific size so this can cause regressions there. And will also cause a performance regressions on x86_64 also for the same reason. We could perhaps make it a target hook. For powerpc, the hook returns true if this is the sysv ABI, and returns false if this is the AIX ABI. That might also be useful for ARM, if you need it to be true for thumb and false for the arm port. I'm not sure at the moment if this is necessary though. The testcase in this bug report is a little different than the one I have. First thing I notice is that the powerpc port is not emitting the stack_tie insn here because there is no frame pointer. But I think it is always necessary for the sysv ABI. If I modify rs6000_emit_stack_reset to check DEFAULT_ABI == ABI_V4 in the rs6000_emit_stack_tie check, then I get correct code for this testcase. I still need to modify the stack_tie pattern to use (MEM:BLK (scratch)) to get correct code for my testcase. These are two fairly simple powerpc backend changes though. I'll have to look at the arm/thumb port next to see what is going on there. Jim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- 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 list, could you please separate the third hunk which is for the original PR42841 as an independant patch. Also don't forget to update the copyright years in the first one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug tree-optimization/18046] Missed jump threading optimization
--- 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 Last reconfirmed|2008-09-21 13:59:00 |2010-02-04 22:52:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18046
[Bug tree-optimization/42963] New: [4,5 Regression] Redundant switch labels not cleaned up anymore
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;
case 1:
break;
}
}
-
the .012t.cfg dump with trunk (r156492) today looks like this:
bar ()
{
int i.0;
bb 2:
i.0 = i;
switch (i.0) default: L2, case 0: L0, case 1: L2
L0:
foo ();
L2:
i.0 = i;
switch (i.0) default: L6, case 0: L4, case 1: L6
L4:
foo ();
L6:
return;
}
The dump with gcc (Debian 4.3.4-5) 4.3.4 looks better:
bar ()
{
int i.0;
# BLOCK 2
# PRED: ENTRY (fallthru)
i.0 = i;
switch (i.0)
{
case 0: goto L0;
default : goto L1;
}
# SUCC: 3 4
# BLOCK 3
# PRED: 2
L0:;
foo ();
# SUCC: 4 (fallthru)
# BLOCK 4
# PRED: 2 3 (fallthru)
L1:;
i.0 = i;
switch (i.0)
{
case 0: goto L4;
default : goto L5;
}
# SUCC: 5 6
# BLOCK 5
# PRED: 4
L4:;
foo ();
# SUCC: 6 (fallthru)
# BLOCK 6
# PRED: 4 5 (fallthru)
L5:;
return;
# SUCC: EXIT
}
Note how GCC 4.5 fails to clean up the case 1 label. The label is retained
all the way through the .137t.nrv dump (at -O2) and only disappears in the
.139t.optimized dump.
This confuses things in a couple of places and costs memory for no reason.
--
Summary: [4,5 Regression] Redundant switch labels not cleaned up
anymore
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42963
[Bug c++/41090] [4.3/4.4/4.5 Regression] Using static label reference in c++ class constructor produces wrong code
--- 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++ -B/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc45-4.4.999-20100203/gcc-4.5-20100203/gcc/testsuite/g++.dg/ext/label13.C -nostdinc++ -I/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/x86_64-apple-darwin10.3.0/libstdc++-v3/include/x86_64-apple-darwin10.3.0 -I/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/x86_64-apple-darwin10.3.0/libstdc++-v3/include -I/sw/src/fink.build/gcc45-4.4.999-20100203/gcc-4.5-20100203/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc45-4.4.999-20100203/gcc-4.5-20100203/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc45-4.4.999-20100203/gcc-4.5-20100203/libstdc++-v3/testsuite/util -fmessage-length=0 -L/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/x86_64-apple-darwin10.3.0/./libstdc++-v3/src/.libs -B/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/x86_64-apple-darwin10.3.0/./libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/x86_64-apple-darwin10.3.0/./libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/x86_64-apple-darwin10.3.0/./libiberty -multiply_defined suppress -lm -o ./label13.exe /sw/src/fink.build/gcc45-4.4.999-20100203/gcc-4.5-20100203/gcc/testsuite/g++.dg/ext/label13.C: In constructor C::C(): /sw/src/fink.build/gcc45-4.4.999-20100203/gcc-4.5-20100203/gcc/testsuite/g++.dg/ext/label13.C:8:3: sorry, unimplemented: function C::C() can never be copied because it saves address of local label in a static variable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090
[Bug target/42964] New: gcc.c-torture/compile/20001226-1.c takes too long to compile
This testcase takes too long to compile at -O3. It freezes my box. I really did not get it to completion but I will try. Same compiles fine when gcc is configured for native build. So it seems like mips specific issue. here is how gcc is configured Configured with: /sources/gcc-trunk/configure --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 and about 11s for native compile. -- Summary: gcc.c-torture/compile/20001226-1.c takes too long to compile Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: mips64-none-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42964
[Bug other/42965] New: no warnings being treated as errors for individual -Werror=x options
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 warnings being treated as errors for individual - Werror=x options Product: gcc Version: unknown Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42965
[Bug other/42966] New: add some indication that a warning has been converted to an error
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). For default warnings, say [default warning]. 2) Give the flag that disables the warning. For default warnings, say [-w]. Also, it would be good to move this info after warning: (or error: if -Werror=) to make it easier to see/parse. Of course, anything that does not have a [something] is a hard error that cannot be disabled. -- Summary: add some indication that a warning has been converted to an error Product: gcc Version: unknown Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42966
[Bug other/42966] add some indication that a warning has been converted to an error
--- 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 for disabling but that would be perhaps more transgressive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42966
[Bug other/42965] no warnings being treated as errors for individual -Werror=x options
--- 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 CC||simonb at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42965
[Bug c++/41090] [4.3/4.4/4.5 Regression] Using static label reference in c++ class constructor produces wrong code
--- 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
[Bug java/42967] New: gcj: error trying to exec 'ecj1': execvp: No such file or directory
+++ 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 'ecj1': execvp: No such file or directory Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dan_1997 at mail dot ru GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42967
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- 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 Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug libfortran/21185] Improve testsuite results on newlib targets
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug fortran/22210] gfc_conv_array_initializer weirdness
--- 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
[Bug fortran/42901] [4.3/4.4/4.5 Regression] reading array of structures from namelist fails
--- 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 PR libfortran/42901 * io/list_read.c (nml_get_obj_data): Add new qualifier flag, clean up code, and adjust logic to set namelist info pointer correctly for array qualifiers of derived type components. Modified: branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42901
[Bug fortran/42901] [4.3/4.4/4.5 Regression] reading array of structures from namelist fails
--- 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 PR libfortran/42901 *gfortran.dg/namelist_60.f90: New test. *gfortran.dg/namelist_59.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/namelist_59.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/namelist_60.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42901
[Bug fortran/42901] [4.3/4.4/4.5 Regression] reading array of structures from namelist fails
--- 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 PR libfortran/42901 * io/list_read.c (nml_get_obj_data): Add new qualifier flag, clean up code, and adjust logic to set namelist info pointer correctly for array qualifiers of derived type components. Modified: branches/gcc-4_3-branch/libgfortran/ChangeLog branches/gcc-4_3-branch/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42901
[Bug fortran/42901] [4.3/4.4/4.5 Regression] reading array of structures from namelist fails
--- 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 PR libfortran/42901 * gfortran.dg/namelist_60.f90: New test. * gfortran.dg/namelist_59.f90: New test. * gcc/testsuite/gfortran.dg/namelist_47.f90: Update test. * gcc/testsuite/gfortran.dg/namelist_40.f90: Update test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_59.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_60.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_40.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_47.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42901
[Bug fortran/42309] Problem with a pointer array passed to a subroutine
--- 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 fortran/42309 * trans-expr.c (gfc_conv_subref_array_arg): Add new argument 'formal_ptr'. If this is true, give returned descriptor unity lbounds, in all dimensions, and the appropriate offset. (gfc_conv_procedure_call); If formal is a pointer, set the last argument of gfc_conv_subref_array_arg to true. * trans.h : Add last argument for gfc_conv_subref_array_arg. * trans-io.c (set_internal_unit, gfc_trans_transfer): Set the new arg of gfc_conv_subref_array_arg to false. * trans-stmt.c (forall_make_variable_temp): The same. 2010-02-05 Paul Thomas pa...@gcc.gnu.org PR fortran/42309 * gfortran.dg/subref_array_pointer_4.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/subref_array_pointer_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42309
[Bug fortran/42958] Weird temporary array allocation
--- 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 generous and that this is rather a sin of omission rather than commission. Paul, what do you think? I think that your arguments are correct. (PS: POSIX Allows ptr = malloc(0); free(ptr), where malloc(0) returns either NULL or a unique pointer.) Indeed. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- 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 error in the comment. I meant GP of course, which is even more preferable that GOT (which is what we load, not what we compute). (In reply to comment #31) When you propose it to the list, could you please separate the third hunk which is for the original PR42841 as an independant patch. Also don't forget to update the copyright years in the first one. OK, that was also my intention to submit the 3rd hunk (the one that fixes the jump to the landing pad around the constant table right ?) as a separate patch as it will require the approval of a middle end maintainer. If it cannot go in the trunk before the 4.5 freeze I can propose you to commit your workaround (comment #23) so not to block the regression. Then we can revert when the proper patch is discussed/accepted. (I'm a little bit late for that sorry). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- 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 +4654,13 @@ find_barrier (int num_mova, rtx mova, rt if (last_got) from = PREV_INSN (last_got); + /* Don't insert the constant pool table at the position which +may be the landing pad. */ + if (flag_exceptions + CALL_P (from) + find_reg_note (from, REG_EH_REGION, NULL_RTX)) + from = PREV_INSN (from); + /* Walk back to be just before any jump or label. Putting it before a label reduces the number of times the branch around the constant pool table will be hit. Putting it before -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
