[Bug ada/29283] New: Bug box in expand_expr_addr_expr_1, at expr.c:6393 on alpha
This bug occurs on Alpha only. While building libtexttools, I get: gcc-4.1 -c -I./ -g -O2 -gnatafno -gnatVa -I.. -I- /build/buildd/libtexttools-2.0.3/windows.adb windows.adb:273:14: warning: "x" may be referenced before it has a value windows.adb:273:17: warning: "y" may be referenced before it has a value windows.adb:1879:16: warning: "OldX" may be referenced before it has a value windows.adb:1879:22: warning: "OldY" may be referenced before it has a value windows.adb:2555:19: warning: "Relative" may be referenced before it has a value windows.adb:2574:19: warning: "Tempint" may be referenced before it has a value windows.adb:2666:03: warning: "OK" is never assigned a value windows.adb:2667:03: warning: "text" is never assigned a value +===GNAT BUG DETECTED==+ | 4.1.2 20060920 (prerelease) (Debian 4.1.1-14) (alpha-unknown-linux-gnu) GCC error:| | in expand_expr_addr_expr_1, at expr.c:6393 | | Error detected at windows.adb:3529:1 | The sources are at http://ftp.debian.org/debian/pool/main/libt/libtexttools/libtexttools_2.0.3.orig.tar.gz -- Summary: Bug box in expand_expr_addr_expr_1, at expr.c:6393 on alpha Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org GCC build triplet: alpha-unknown-linux-gnu GCC host triplet: alpha-unknown-linux-gnu GCC target triplet: alpha-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29283
[Bug fortran/29284] New: ICE for optional subroutine argument
$ gfortran --version GNU Fortran 95 (GCC) 4.2.0 20060923 (experimental) $ cat foo.f90 MODULE foo CONTAINS SUBROUTINE sub1(a) CHARACTER (LEN=*), OPTIONAL :: a WRITE(*,*) 'foo bar' END SUBROUTINE sub1 SUBROUTINE sub2 CALL sub1() END SUBROUTINE sub2 END MODULE foo $ gfortran -c foo.f90 foo.f90: In function $B!F(Bsub2$B!G(B: foo.f90:3: internal compiler error: Segmentation fault gcc-4.2-20060812 can compile the same code. -- Summary: ICE for optional subroutine argument Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rakuen_himawari at yahoo dot co dot jp GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29284
[Bug ada/29283] Bug box in expand_expr_addr_expr_1, at expr.c:6393 on alpha
--- Comment #1 from charlet at gcc dot gnu dot org 2006-09-29 08:13 --- Please post a self contained set of sources, and a self contained command line to reproduce the box, thanks. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29283
[Bug fortran/29284] [4.1/4.2 Regression] ICE for optional subroutine argument
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-29 08:20 --- 4.1.2 20060917 also fails. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.2 4.2.0 Known to work||4.1.1 Last reconfirmed|-00-00 00:00:00 |2006-09-29 08:20:03 date|| Summary|ICE for optional subroutine |[4.1/4.2 Regression] ICE for |argument|optional subroutine argument Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29284
[Bug c++/29273] error on dynamic_cast(array)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-29 08:24 --- Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||2.95 3.2.3 3.4.0 4.0.0 4.2.0 ||4.0.4 4.1.2 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-09-29 08:24:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29273
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-09-29 09:14 ---
Here's an executable testcase which is miscompiled at the tree-level.
extern void abort(void);
struct Foo {
int a;
int b;
};
struct Node;
struct Node {
struct Node *next;
};
struct Node *pool;
void grow (void)
{
char *mem = __builtin_malloc (4096);
struct Node *node = (struct Node *)mem;
struct Foo *foo;
__builtin_memcpy (&node->next, &pool, sizeof(struct Node*));
pool = node;
}
static inline void *alloc_one (void)
{
struct Node *node = pool;
__builtin_memcpy (&pool, &node->next, sizeof(struct Node*));
return node;
}
static inline void dealloc_one (void *p)
{
struct Node *node = p;
__builtin_memcpy (&node->next, &pool, sizeof(struct Node*));
pool = node;
}
int main()
{
grow();
struct Foo* foo = alloc_one();
foo->a = 0;
foo->b = -1;
dealloc_one (foo);
if (foo->b == -1)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug fortran/21435] fails to open nonexisting file with status scratch
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-09-29 09:18 --- Still present on mainline, probably not difficult to fix. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Component|libfortran |fortran Last reconfirmed|2005-12-28 06:36:31 |2006-09-29 09:18:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21435
[Bug c/26154] OpenMP extensions to the C language is not documented or doumented in the wrong spot
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154
[Bug target/29198] [4.0/4.1/4.2 Regression] Incorrect reference to __thread array with -fPIC -O2 on x86
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-09-24 05:29:30 |2006-09-29 11:29:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29198
[Bug libfortran/18791] CABS specifics declared of wrong type
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-09-29 13:21 --- Assigning this to myself, as I have a patch cooking. A testcase is (on i686-linux): $ cat cdabs.f subroutine foo(f) implicit none real*8 f complex*16 z z = (1.,1.) print *, f(z) end implicit none intrinsic cdabs call foo(cdabs) end $ gfortran cdabs.f && ./a.out NaN $ gfortran cdabs.f -O3 && ./a.out NaN zsh: segmentation fault ./a.out -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pbrook at gcc dot gnu dot |fxcoudert at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18791
[Bug libfortran/18791] CABS specifics declared of wrong type
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-09-29 13:22 --- And also: that's a regression wrt g77. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19292 nThis|| Known to fail||4.1.1 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18791
[Bug c/29285] New: Poor optimization causes unbounded code duplication
Consider the following simple function (I can reproduce the bug just saving
this code as a .c file and compiling it with -S to see the asm output and using
-O1):
extern void a( void );
extern void b( void );
extern void c( void );
int weird(int t)
{
if (t > 32768) t = 32768;
a();
b();
c();
if (t < -32768) t = -32768;
return t;
}
GCC-4.1.1 seems to duplicate the block between the two ifs no matter what code
I put between them, here's the assembler output:
weird:
pushl %ebp
movl%esp, %ebp
pushl %ebx
subl$4, %esp
movl8(%ebp), %ebx
cmpl$32768, %ebx
jg .L2
calla
callb
callc
movl%ebx, %eax
cmpl$-32768, %ebx
jge .L5
movl$-32768, %eax
jmp .L5
.L2:
calla
callb
callc
movl$32768, %eax
.L5:
addl$4, %esp
popl%ebx
popl%ebp
ret
As you can see the first conditional branch skips over the code standing for
the second if - as it should since the conditions are mutually exclusive - but
the calls in-between them have to be replicated on the other side of the
branch. Now the problem is no matter how many calls I put in between the if()s
they will be replicated on both sides instead of being factored. Considering
that -O1 shouldn't turn on optimizations which cause trade-offs between size
and speed this seems a bug to me.
--
Summary: Poor optimization causes unbounded code duplication
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gabriele dot svelto at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29285
[Bug c/29285] Poor optimization causes unbounded code duplication
--- Comment #1 from gabriele dot svelto at gmail dot com 2006-09-29 13:37 --- Created an attachment (id=12353) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12353&action=view) Code that triggers the bug when compiled with -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29285
[Bug libstdc++/29286] New: placement new does not provide required side-effects
Placement new is specified to end life-time of the object starting life-time of
a new one. The current implementation messes up with aliasing though, so
stores are re-ordered:
#include
struct Foo { long i; };
struct Bar { void *p; };
long foo(int n)
{
Foo *f = new Foo;
f->i = 1;
for (int i=0; ip = 0;
f = new (f) Foo;
f->i = i;
}
return f->i;
}
Produces .099t.optimized:
long int foo(int) (n)
{
struct Foo * f;
void * D.2530;
:
D.2530 = operator new (8);
f = (struct Foo *) D.2530;
f->i = 1;
if (n > 0) goto ; else goto ;
:;
f->i = (long int) ((unsigned int) n - 1);
((struct Bar *) f)->p = 0B;
:;
return f->i;
}
where the stores to Bar::p and Foo:i are reordered. Until .147r.bbro
everything looks like above on RTL level, too:
...
;; Start of basic block 3, registers live: 1 [dx] 3 [bx] 7 [sp]
(note:HI 21 19 22 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(note:HI 22 21 48 3 NOTE_INSN_DELETED)
(insn 48 22 24 3 (set (reg:DI 0 ax [63])
(zero_extend:DI (subreg:SI (plus:DI (reg:DI 3 bx [orig:61 n ] [61])
(const_int -1 [0x])) 0))) 195 {*lea_1_zext}
(nil)
(expr_list:REG_DEAD (reg:DI 3 bx [orig:61 n ] [61])
(nil)))
(insn:HI 24 48 25 3 (set (mem/s:DI (reg/v/f:DI 1 dx [orig:58 f ] [58]) [3
.i+0 S8 A64])
(reg:DI 0 ax [63])) 81 {*movdi_1_rex64} (insn_list:REG_DEP_TRUE 23
(nil))
(expr_list:REG_DEAD (reg:DI 0 ax [63])
(nil)))
(insn:HI 25 24 26 3 (set (mem/s/f:DI (reg/v/f:DI 1 dx [orig:58 f ] [58]) [5
.p+0 S8 A64])
(const_int 0 [0x0])) 81 {*movdi_1_rex64} (nil)
(nil))
;; End of basic block 3, registers live:
1 [dx] 7 [sp]
...
but now (unfortunately) scheduling reorders them back (on x86_64), so the
assembly looks good again:
_Z3fooi:
.LFB15:
pushq %rbx
.LCFI0:
movl%edi, %ebx
movl$8, %edi
call_Znwm
testl %ebx, %ebx
movq%rax, %rdx
movq$1, (%rax)
jle .L2
leal-1(%rbx), %eax
movq$0, (%rdx)
movq%rax, (%rdx)
.L2:
popq%rbx
movq(%rdx), %rax
ret
But with -O2 -fno-schedule-insns2 we finally get wrong-code for this:
_Z3fooi:
.LFB15:
pushq %rbx
.LCFI0:
movl%edi, %ebx
movl$8, %edi
call_Znwm
movq%rax, %rdx
movq$1, (%rax)
testl %ebx, %ebx
jle .L2
leal-1(%rbx), %eax
movq%rax, (%rdx)
movq$0, (%rdx)
.L2:
movq(%rdx), %rax
popq%rbx
ret
--
Summary: placement new does not provide required side-effects
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code, alias
Severity: normal
Priority: P3
Component: libstdc++
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=29286
[Bug libstdc++/29286] placement new does not provide required side-effects
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-29 14:15 --- The root of the problem is "wrong" alias information: : # SMT.6_27 = V_MAY_DEF ; # SMT.7_28 = V_MAY_DEF ; D.2530_3 = operator new (8); f_4 = (struct Foo *) D.2530_3; # SMT.6_29 = V_MAY_DEF ; f_4->i = 1; i_5 = 0; goto (); :; D.2542_7 = 8; __p_8 = f_1; D.2544_9 = __p_8; D.2544_10 = D.2544_9; D.2535_11 = D.2544_10; b_12 = (struct Bar *) D.2535_11; # SMT.7_30 = V_MAY_DEF ; b_12->p = 0B; D.2545_13 = 8; __p_14 = f_1; D.2547_15 = __p_14; D.2547_16 = D.2547_15; D.2536_17 = D.2547_16; f_18 = (struct Foo *) D.2536_17; D.2537_19 = (long int) i_2; # SMT.6_31 = V_MAY_DEF ; f_18->i = D.2537_19; i_20 = i_2 + 1; # SMT.7_24 = PHI ; # SMT.6_23 = PHI ; # i_2 = PHI ; # f_1 = PHI ; :; if (i_2 < n_6) goto ; else goto ; :; # VUSE ; D.2538_21 = f_1->i; return D.2538_21; the stores to b_12->p and f_18->i appear to be independent. But there is an implicit barrier between them from the std::new. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.2 Regression] placement new does not provide required side-effects
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-29 14:17 --- 4.1 get's it correct by luck. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.1.1 Summary|placement new does not |[4.2 Regression] placement |provide required side- |new does not provide |effects |required side-effects http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c++/29279] ICE
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-29 14:24 --- And with 4.0.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||3.4.6 Known to work||4.0.0 Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29279
[Bug libstdc++/29286] [4.2 Regression] placement new does not provide required side-effects
--- Comment #3 from pcarlini at suse dot de 2006-09-29 14:29 ---
Hi Richard. For sure, I'm missing many details here, having to do with alias
analysis, but I'm puzzled anyway ;) I mean, the current libsupc++
"implementation" of placement new is:
// Default placement versions of operator new.
inline void* operator new(std::size_t, void* __p) throw() { return __p; }
inline void* operator new[](std::size_t, void* __p) throw() { return __p; }
Can you explain a bit how a fix would look like?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c/29285] [4.1/4.2 Regression] Poor optimization causes unbounded code duplication
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-29 14:30 --- Confirmed. This is DOM at work. I believe we have this bug somewhere already, but I cannot find it right now. -- 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 |2006-09-29 14:30:39 date|| Summary|Poor optimization causes|[4.1/4.2 Regression] Poor |unbounded code duplication |optimization causes ||unbounded code duplication Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29285
[Bug libstdc++/29286] [4.2 Regression] placement new does not provide required side-effects
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-09-29 14:38 ---
One way to paper over the problem is to move std::new out-of-line :( Otherwise
I cannot see how we can fix this in libsupc++ without gcc help. Basically we
somehow need to insert (at least) a memory barrier here, like with
inline void* operator new(std::size_t, void* __p) throw() {
__asm__ volatile ("" : : : "memory");
return __p;
}
but that might pessimize code too much.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.2 Regression] placement new does not provide required side-effects
--- Comment #5 from pcarlini at suse dot de 2006-09-29 14:52 ---
(In reply to comment #4)
> One way to paper over the problem is to move std::new out-of-line :(
> Otherwise
> I cannot see how we can fix this in libsupc++ without gcc help. Basically we
> somehow need to insert (at least) a memory barrier here, like with
>
> inline void* operator new(std::size_t, void* __p) throw() {
> __asm__ volatile ("" : : : "memory");
> return __p;
> }
>
> but that might pessimize code too much.
In case, memory barriers are available, and already used in guard.cc, but
indeed, naively, something seems wrong with such a pure-library approach: a
memory barrier needed for single thread code?!?!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #28 from pault at gcc dot gnu dot org 2006-09-29 15:00 --- Created an attachment (id=12354) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12354&action=view) Patch that fixes Salvatore's latest This patch moves the addition of EXPR_NULL for allocatable components to expr.c(gfc_default_initializer). The consequence of this is that ALL structures with allocatable components get a default initializer, even if it only contains EXPR_NULL. Whilst this is OK for the static initialization, it is unnecessary because of the nullification that is done upon coming into scope. Thus, translation of such intitializer expressions is skipped in trans-expr.c(gfc_conv_structure). ALLOCATE now does an assignment of this potentially compound default initializer expression to each and every allocatable component. Being a variable assignment, this produces extra code that checks for non-NULL data fields to see if they should be deallocated. This ups the dealloactions counted by alloc_comp_basics_1.f90 to 38. With this modification, the patch regtests OK. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug c/29285] [4.1/4.2 Regression] Poor optimization causes unbounded code duplication
--- Comment #3 from gabriele dot svelto at gmail dot com 2006-09-29 15:19 --- (In reply to comment #2) > Confirmed. This is DOM at work. I believe we have this bug somewhere > already, > but I cannot find it right now. Bug #28364 might have something to do with it, similar behaviour in my code with both if-else and loop statements led me to nail it down to that simple example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29285
[Bug c++/29287] New: signed to unsigned in struct initializer should generate a warning
$ cat structs.C
struct foo {
int j;
unsigned i;
};
foo f = { -1, -1 };
int main() {
}
$ g++-4.1.1 -o structs structs.C -Wall -W
$ g++-3.4.6 -o structs structs.C -Wall -W
structs.C:6: warning: converting of negative value `-0x1' to `unsigned
int'
$
--
Summary: signed to unsigned in struct initializer should generate
a warning
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jaco at kroon dot co dot za
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29287
[Bug libstdc++/29286] [4.2 Regression] placement new does not provide required side-effects
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-29 15:49 ---
Actually I think it should be:
inline void* operator new(std::size_t, void* __p) throw() {
void *p1;
__asm__ ("" : "=r"(p1): "0"(__p): "memory");
return __p;
}
Which is less pessimize.
Note the reason why you need this memory barrier is because the C++ standard
says inplacement news change the dynamic type.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-09-29 15:49:15
date||
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-29 15:51 ---
Note here is a slightly better testcase as now we know that Foo and Bar are the
same size:
#include
struct Foo { void *i; };
struct Bar { void *p; };
long foo(int n, int *t)
{
Foo *f = new Foo;
f->i = t;
for (int i=0; ip = 0;
f = new (f) Foo;
f->i = t;
}
return f->i;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libfortran/27107] Make dependency on io/io.h broken
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-09-29 15:55 --- I have a patch for that, but it will have to wait until 4.3 is branched. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-21 14:05:05 |2006-09-29 15:55:19 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27107
[Bug c/29285] [4.1/4.2 Regression] Poor optimization causes unbounded code duplication
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-29 16:02 --- Related to PR 21883. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||21883 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29285
[Bug tree-optimization/29285] [4.1/4.2 Regression] Poor optimization causes unbounded code duplication
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-29 16:08 --- This is not unbounded at all, if you increase the number of function calls, we stop doing it. Two -Os works correctly. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Component|c |tree-optimization Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29285
[Bug libstdc++/29286] [4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #8 from pcarlini at suse dot de 2006-09-29 16:08 --- Let's suppose for a moment we actually try to fix this issue in the library: is adding a barrier conforming to the letter of 18.4.1.3/2-3, 5-6, that is: Returns: ptr. Notes: Intentionally performs no other action. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-29 16:19 --- (In reply to comment #8) > Let's suppose for a moment we actually try to fix this issue in the library: > is > adding a barrier conforming to the letter of 18.4.1.3/2-3, 5-6, that is: > > Returns: ptr. > Notes: Intentionally performs no other action. There has to be some communutation between the library and the compiler to tell it that the memory location is being reused as defined by 3.8 of the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #10 from pcarlini at suse dot de 2006-09-29 16:23 --- (In reply to comment #9) > There has to be some communutation between the library and the compiler to > tell > it that the memory location is being reused as defined by 3.8 of the > standard. Yes. But considering that the placement forms cannot be replaced by an user program, isn't conceptually cleaner for the C++ front-end to simply recognize those forms and do the right thing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-09-29 16:24
---
I don't really know. But for this issue I would like to introduce middle-end
no-op builtins __builtin_clobber (void*) clobber the pointer argument alias set
like we do for malloc/free (and other calls):
int foo(void)
{
int i, *p, *q;
p = malloc(4);
*p = 0;
free(p);
q = malloc(4);
*q = 1;
i = *q;
free(q);
return i;
}
:
# HEAP.4_10 = V_MAY_DEF ;
# HEAP.5_11 = V_MAY_DEF ;
D.1530_1 = malloc (4);
p_2 = (int *) D.1530_1;
# HEAP.4_12 = V_MAY_DEF ;
*p_2 = 0;
# HEAP.4_13 = V_MAY_DEF ;
# HEAP.5_14 = V_MAY_DEF ;
free (p_2);
# HEAP.4_15 = V_MAY_DEF ;
# HEAP.5_16 = V_MAY_DEF ;
D.1531_3 = malloc (4);
q_4 = (int *) D.1531_3;
# HEAP.5_17 = V_MAY_DEF ;
*q_4 = 1;
# VUSE ;
i_5 = *q_4;
# HEAP.4_18 = V_MAY_DEF ;
# HEAP.5_19 = V_MAY_DEF ;
free (q_4);
D.1532_6 = i_5;
return D.1532_6;
or even just a way to add a VUSE of the pointer alias sets, or even
void * __builtin_new_object (void *p) which would do
# VUSE
# HEAP.n = V_MAY_DEF
p = __builtin_new_object (p)
i.e. associate a new alias tag with the return value.
Can you benchmark the workaround in the library?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-09-29 16:25 --- Yes, maybe we can do something in the C++ frontend. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/29288] New: All intrinsics are allowed as actual arguments
(vaguely related to PR16580) We're currently not checking if an intrinsic is allowed to be used as an actual argument or not (and it's a regression wrt g77): $ ifort a.f fortcom: Error: a.f, line 2: This intrinsic procedure cannot be passed as an actual argument. [ICHAR] call BAR(ichar) ---^ compilation aborted for a.f (code 1) $ pgf90 a.f PGF90-S-0073-Intrinsic or predeclared, ichar, cannot be passed as an argument (a.f: 2) 0 inform, 0 warnings, 1 severes, 0 fatal for MAIN $ gfortran a.f /tmp/cckKTcIB.o(.text+0x5): In function `MAIN__': : undefined reference to `specific__ichar_1' /tmp/cckKTcIB.o(.text+0xa): In function `MAIN__': : undefined reference to `bar_' collect2: ld returned 1 exit status -- Summary: All intrinsics are allowed as actual arguments Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org OtherBugsDependingO 16580 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29288
[Bug fortran/29288] All intrinsics are allowed as actual arguments
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-29 16:41:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29288
[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-09-29 16:58
---
And here is a testcase that fails also for 4.0.0 and self contained also:
#include
int foo(int n, int *f, long *f1)
{
long t = 0;
*f = 1;
long *fp = new(f) long;
*fp = 1;
for (int i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-29 17:01
---
(In reply to comment #13)
> And here is a testcase that fails also for 4.0.0 and self contained also:
replace main with:
int main(void)
{
if (sizeof(int) != sizeof(long))
return 0;
int *a = new int;
long *b = new long;
*a = 0;
*b = 0;
if (foo(2, a, b) != 6)
abort ();
return 0;
}
This is what you get when thinking about 2 steps ahead of yourself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/29189] Error during CPP build of Mozilla
--- Comment #10 from giffordj at linkline dot com 2006-09-29 17:18 --- Is more information required, let me know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29189
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-29 17:30 --- I think we can declare this as invalid code for C and unkown for C++. For C++, inplacement new is supposed to "fix" the problem with different types as C++ defines aliasing based on the dynamic type but we get a different bug with that being PR 29286. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug c++/29289] New: [4.1/4.2] additionally weak symbols referenced/generated
seen on various linux architectures, building apt results in a library with several additional weak symbols defined. trying to build and link a program (built with the changed compiler version) to the apt library built with the older compiler version results in a link failure, shown below. rebuilding the library with the changed compiler lets the application link again. - on the 4.1 branch, the additional symbols seem to be the result of a part of the r116763 checkin; reverting the changes for PR26195 restores the old behaviour. - not yet searched on mainline; the change is between 20060815 and 20060923. is this a bug in apt's use in #pragma interface? g++ -g -O2 -o synaptic gsynaptic.o gtkpkglist.o rgaboutpanel.o rgcacheprogress.o rgpkgcdrom.o rgpreferenceswindow.o rgfetchprogress.o rgfiltermanager.o rgfindwindow.o rgiconlegend.o rglogview.o rgmisc.o rgsetoptwindow.o rgdummyinstallprogress.o rgdebinstallprogress.o rgterminstallprogress.o rginstallprogress.o rgslideshow.o rgtaskswin.o rgcdscanner.o rgmainwindow.o rgpkgdetails.o rgrepositorywin.o rgvendorswindow.o rgsummarywindow.o rgchangeswindow.o rguserdialog.o rgwindow.o rggladewindow.o ../common/libsynaptic.a -lapt-pkg -lapt-inst -lglade-2.0 -lgtk-x11-2.0 -lxml2 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lcairo -lX11 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lvte -lncurses -lXft -lgtk-x11-2.0 -lpangoxft-1.0 -lpangox-1.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lcairo -lX11 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -llaunchpad-integration -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lpango-1.0 -lcairo -lX11 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpthread rgpkgcdrom.o: In function `pkgCdromStatus': /usr/include/apt-pkg/cdrom.h:20: undefined reference to `vtable for pkgCdromStatus' rgpkgcdrom.o: In function `~pkgCdromStatus': /usr/include/apt-pkg/cdrom.h:21: undefined reference to `vtable for pkgCdromStatus' rgpkgcdrom.o: In function `pkgCdromStatus': /usr/include/apt-pkg/cdrom.h:20: undefined reference to `vtable for pkgCdromStatus' rgpkgcdrom.o: In function `~pkgCdromStatus': /usr/include/apt-pkg/cdrom.h:21: undefined reference to `vtable for pkgCdromStatus' /usr/include/apt-pkg/cdrom.h:21: undefined reference to `vtable for pkgCdromStatus' rgpkgcdrom.o:/usr/include/apt-pkg/cdrom.h:21: more undefined references to `vtable for pkgCdromStatus' follow rgpkgcdrom.o:(.rodata._ZTV11RGCDScanner[vtable for RGCDScanner]+0x10): undefined reference to `pkgCdromStatus::SetTotal(int)' rgpkgcdrom.o:(.rodata._ZTV11RGCDScanner[vtable for RGCDScanner]+0x20): undefined reference to `pkgCdromStatus::GetOpProgress()' rgpkgcdrom.o:(.rodata._ZTI11RGCDScanner[typeinfo for RGCDScanner]+0x10): undefined reference to `typeinfo for pkgCdromStatus' rgmainwindow.o: In function `~pkgCdromStatus': /usr/include/apt-pkg/cdrom.h:21: undefined reference to `vtable for pkgCdromStatus' ../common/libsynaptic.a(rpackagecache.o): In function `~RPkgPolicy': /tmp/2/synaptic-0.57.11ubuntu9/common/rpackagecache.h:40: undefined reference to `pkgPolicy::~pkgPolicy()' /tmp/2/synaptic-0.57.11ubuntu9/common/rpackagecache.h:40: undefined reference to `pkgPolicy::~pkgPolicy()' ../common/libsynaptic.a(rpackagelister.o): In function `pkgArchiveCleaner': /usr/include/apt-pkg/clean.h:20: undefined reference to `vtable for pkgArchiveCleaner' ../common/libsynaptic.a(rpackagelister.o): In function `~pkgArchiveCleaner': /usr/include/apt-pkg/clean.h:28: undefined reference to `vtable for pkgArchiveCleaner' /usr/include/apt-pkg/clean.h:28: undefined reference to `vtable for pkgArchiveCleaner' /usr/include/apt-pkg/clean.h:28: undefined reference to `vtable for pkgArchiveCleaner' collect2: ld returned 1 exit status -- Summary: [4.1/4.2] additionally weak symbols referenced/generated Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29289
[Bug c++/29289] [4.1/4.2] additionally weak symbols referenced/generated
--- Comment #1 from doko at ubuntu dot com 2006-09-29 17:46 --- Created an attachment (id=12355) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12355&action=view) difference of symbols (objdump -T) sources and binaries for the shared library at http://people.ubuntu.com/~doko/apt/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29289
[Bug c++/29289] [4.1/4.2] additionally weak symbols referenced/generated
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-29 17:59 --- This seems more like an ABI issue in older 4.1's and 4.2's rather than a bug in the newer 4.1.2 and 4.2.0. I bet we had an accidental ABI change in 4.0.0 and we have no fixed that. I am thinking we should close this as a non bug. "#pragma interface" should be killed really, all it does is bring trouble. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29289
[Bug tree-optimization/29290] New: SPEC CPU2000 178.galgel ICE using -O3 -ftree-loop-linear
The following simplified test case from galgel SEGV's when using -O3
-ftree-loop-linear with the latest gcc-4_1-branch. It compiles fine with both
mainline and the gcc_4_1_1_release branch.
vervain% cat grsyst.f
Subroutine Diffun (A, B, NS, N)
Real*8 A, B
Integer NS, N
Dimension A(NS,NS), B(NS,NS)
A(1:N,1:N) = B(1:N,1:N)
End
vervain:% gfortran -O3 -ftree-loop-linear -S grsyst.f
grsyst.f: In function diffun:
grsyst.f:1: 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.
Here's a backtrace that shows we take the SEGV due to a null pointer
dereference in exit_phi_for_loop_p() because loop->single_exit is null.
(gdb) bt
#0 exit_phi_for_loop_p (loop=0x1078ab20, stmt=0x400dfa00) at
tree-flow-inline.h:172
#1 0x10527a90 in gcc_loopnest_to_lambda_loopnest (currloops=0x10763578,
loop_nest=0x1078ab20, inductionvars=0xdb78,
invariants=0xdb7c) at /home/bergner/gcc/gcc-4.1/gcc/lambda-code.c:2242
#2 0x1050fa70 in linear_transform_loops (loops=0x10763578) at
/home/bergner/gcc/gcc-4.1/gcc/tree-loop-linear.c:338
#3 0x1046f4d0 in tree_linear_transform () at
/home/bergner/gcc/gcc-4.1/gcc/tree-ssa-loop.c:225
#4 0x1038beb4 in execute_one_pass (pass=0x106dad60) at
/home/bergner/gcc/gcc-4.1/gcc/passes.c:827
#5 0x1038bffc in execute_pass_list (pass=0x106dad60) at
/home/bergner/gcc/gcc-4.1/gcc/passes.c:859
#6 0x1038c014 in execute_pass_list (pass=0x106dae64) at
/home/bergner/gcc/gcc-4.1/gcc/passes.c:860
#7 0x1038c014 in execute_pass_list (pass=0x106d609c) at
/home/bergner/gcc/gcc-4.1/gcc/passes.c:860
#8 0x100985b4 in tree_rest_of_compilation (fndecl=0x400ec300) at
/home/bergner/gcc/gcc-4.1/gcc/tree-optimize.c:419
#9 0x10060fb8 in gfc_expand_function (fndecl=0x400ec300) at
/home/bergner/gcc/gcc-4.1/gcc/fortran/f95-lang.c:223
#10 0x103e6c8c in cgraph_expand_function (node=0x400e9850) at
/home/bergner/gcc/gcc-4.1/gcc/cgraphunit.c:1058
#11 0x103e8a08 in cgraph_optimize () at
/home/bergner/gcc/gcc-4.1/gcc/cgraphunit.c:1124
#12 0x100664cc in gfc_be_parse_file (set_yydebug=276343584) at
/home/bergner/gcc/gcc-4.1/gcc/fortran/f95-lang.c:293
#13 0x10350bb4 in toplev_main (argc=275644416, argv=0x1073a2e4) at
/home/bergner/gcc/gcc-4.1/gcc/toplev.c:991
#14 0x100943bc in main (argc=276343584, argv=0x400dfa00) at
/home/bergner/gcc/gcc-4.1/gcc/main.c:35
(gdb) list exit_phi_for_loop_p
2181
2182static bool
2183exit_phi_for_loop_p (struct loop *loop, tree stmt)
2184{
2185
2186 if (TREE_CODE (stmt) != PHI_NODE
2187 || PHI_NUM_ARGS (stmt) != 1
2188 || bb_for_stmt (stmt) != loop->single_exit->dest)
2189return false;
2190
(gdb) p loop->single_exit
$1 = 0x0
--
Summary: SPEC CPU2000 178.galgel ICE using -O3 -ftree-loop-linear
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bergner at vnet dot ibm dot com
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29290
[Bug libfortran/29121] CPU_TIME subroutine missing for REAL(kind=10) argument
--- Comment #3 from kargl at gcc dot gnu dot org 2006-09-29 20:34 --- I have a patch that adds real(10) and real(16) versions of cpu_time. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-09-20 04:47:23 |2006-09-29 20:34:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29121
[Bug rtl-optimization/28096] [4.2 regression] fdlibm/strtod.c miscompiled at -O2
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2006-09-29 20:40 --- > I don't think this bug has anything to do with excess precision. Valgrind > shows that, when compiled at -O2, we are reading from uninitialized memory. Confirmed: andl-144(%ebp), %ebx <--- bogus value in %ebx movl%eax, -144(%ebp) Swap the lines and all works fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug libfortran/18791] CABS specifics declared of wrong type
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-09-29 20:41 --- Subject: Bug 18791 Author: fxcoudert Date: Fri Sep 29 20:41:11 2006 New Revision: 117317 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117317 Log: PR fortran/18791 * gfortran.dg/specifics_1.f90: New test. * gfortran.fortran-torture/execute/specifics.f90: Add tests for complex specifics. * m4/specific.m4: Special-case cabs so that its return type is real. Special-case conjg so that their suffices are _4, _8, _10 and _16 instead of _c4, _c8, _c10 and _c16. * intrinsics/f2c_specifics.F90: Special-case conjg functions so that their suffices are _4 and _8 instead of _c4 and _c8. * generated/_conjg_c4.F90: Regenerate. * generated/_conjg_c8.F90: Regenerate. * generated/_conjg_c10.F90: Regenerate. * generated/_conjg_c16.F90: Regenerate. * generated/_abs_c4.F90: Regenerate. * generated/_abs_c8.F90: Regenerate. * generated/_abs_c10.F90: Regenerate. * generated/_abs_c16.F90: Regenerate. Added: trunk/gcc/testsuite/gfortran.dg/specifics_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.fortran-torture/execute/specifics.f90 trunk/libgfortran/generated/_abs_c10.F90 trunk/libgfortran/generated/_abs_c16.F90 trunk/libgfortran/generated/_abs_c4.F90 trunk/libgfortran/generated/_abs_c8.F90 trunk/libgfortran/generated/_conjg_c10.F90 trunk/libgfortran/generated/_conjg_c16.F90 trunk/libgfortran/generated/_conjg_c4.F90 trunk/libgfortran/generated/_conjg_c8.F90 trunk/libgfortran/m4/specific.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18791
[Bug c++/29291] New: [4.2 regression] ICE on invalid use of new
The following invalid testcase triggers an ICE on mainline:
===
template void foo()
{
new int(;
}
===
bug.cc: In function 'void foo()':
bug.cc:3: error: expected primary-expression before ';' token
bug.cc:3: internal compiler error: tree check: expected tree_list, have
error_mark in any_type_dependent_arguments_p, at cp/pt.c:13017
Please submit a full bug report, [etc.]
The problem is similar to PR28593, and so is the fix, which I'll be
posting soon.
--
Summary: [4.2 regression] ICE on invalid use of new
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: reichelt at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 28593
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29291
[Bug fortran/24828] Z and negative integers
--- Comment #4 from kargl at gcc dot gnu dot org 2006-09-29 20:52 --- Can this PR be closed? How BOZ constants are interpreted is in accordance with the F95 standard's DATA statement. The extension of BOZs in assignments does change the intrepretation. With a slightly modified program, I see troutmask:sgk[455] cat k.f90 program z integer(4) i integer(8) j i = Z'80203040' j = Z'80203040' print *, i, j if (i .ne. Z'80203040') call abort end troutmask:sgk[456] gfc -o z k.f90 In file k.f90:4 i = Z'80203040' 1 Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1) troutmask:sgk[457] gfc -o z -fno-range-check k.f90 troutmask:sgk[458] ./z -2145374144 2149593152 Abort (core dumped) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24828
[Bug other/25035] [4.1/4.2 regression] libssp causes a failure with cross compilers with unified trees
--- Comment #18 from jsm28 at gcc dot gnu dot org 2006-09-29 21:19 --- Subject: Bug 25035 Author: jsm28 Date: Fri Sep 29 21:18:51 2006 New Revision: 117318 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117318 Log: PR other/25035 * configure.ac (AC_EXEEXT): Remove. (GCC_NO_EXECUTABLES): Call. (ssp_use_symver): Default to no if unable to link. (AC_CHECK_FUNCS): Hardwire results if unable to link. * aclocal.m4, configure, Makefile.in: Regenerate. Modified: trunk/libssp/ChangeLog trunk/libssp/Makefile.in trunk/libssp/aclocal.m4 trunk/libssp/configure trunk/libssp/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
[Bug other/25035] [4.1/4.2 regression] libssp causes a failure with cross compilers with unified trees
--- Comment #19 from jsm28 at gcc dot gnu dot org 2006-09-29 21:27 --- Subject: Bug 25035 Author: jsm28 Date: Fri Sep 29 21:27:38 2006 New Revision: 117319 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117319 Log: PR other/25035 * configure.ac (AC_EXEEXT): Remove. (GCC_NO_EXECUTABLES): Call. (ssp_use_symver): Default to no if unable to link. (AC_CHECK_FUNCS): Hardwire results if unable to link. * aclocal.m4, configure, Makefile.in: Regenerate. Modified: branches/gcc-4_1-branch/libssp/ChangeLog branches/gcc-4_1-branch/libssp/Makefile.in branches/gcc-4_1-branch/libssp/aclocal.m4 branches/gcc-4_1-branch/libssp/configure branches/gcc-4_1-branch/libssp/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #6 from jakub at gcc dot gnu dot org 2006-09-29 22:04 ---
Is:
extern void abort (void);
struct S { struct S *s; } s;
struct T { struct T *t; } t;
static inline void
foo (void *s)
{
struct T *p = s;
__builtin_memcpy (&p->t, &t.t, sizeof (t.t));
}
void *
__attribute__((noinline))
bar (void *p, struct S *q)
{
q->s = &s;
foo (p);
return q->s;
}
int
main (void)
{
t.t = &t;
if (bar (&s, &s) != (void *) &t)
abort ();
return 0;
}
valid? I'd say yes, we either access s.s using its declared (== effective)
type,
or through memcpy (which is supposed tobe a char array access and therefore
ok wrt. aliasing).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
Re: [Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
>
>
>
> --- Comment #6 from jakub at gcc dot gnu dot org 2006-09-29 22:04 ---
> Is:
> extern void abort (void);
>
> struct S { struct S *s; } s;
> struct T { struct T *t; } t;
>
> static inline void
> foo (void *s)
> {
> struct T *p = s;
> __builtin_memcpy (&p->t, &t.t, sizeof (t.t));
I think the problem is really is &p->t include an access or not?
I know if p is NULL, this is undefined as &p->t is now have a NULL pointer
access but does that include using memcpy?
-- Pinski
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #7 from pinskia at physics dot uc dot edu 2006-09-29 22:13
---
Subject: Re: [4.2 Regression] memcpy optimization causes wrong-code
>
>
>
> --- Comment #6 from jakub at gcc dot gnu dot org 2006-09-29 22:04 ---
> Is:
> extern void abort (void);
>
> struct S { struct S *s; } s;
> struct T { struct T *t; } t;
>
> static inline void
> foo (void *s)
> {
> struct T *p = s;
> __builtin_memcpy (&p->t, &t.t, sizeof (t.t));
I think the problem is really is &p->t include an access or not?
I know if p is NULL, this is undefined as &p->t is now have a NULL pointer
access but does that include using memcpy?
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug libfortran/29121] CPU_TIME subroutine missing for REAL(kind=10) argument
--- Comment #4 from kargl at gcc dot gnu dot org 2006-09-29 22:23 --- Fixed on trunk. I'll commit to 4.1 after a regression test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29121
[Bug fortran/29292] New: configure produces strange gmp, mpfr lib directories.
the --with-gmp=/usr/local fails (cannot find lib/libgmp.a), including --with-gmp=/usr/local/lib produces -L/usr/local/lib/lib in the makefile. I have made the same build on OS X and Cygwin and did not have this problem... Dan -- Summary: configure produces strange gmp, mpfr lib directories. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danp57 at optonline dot net GCC build triplet: " GCC host triplet: powerpc64-ibm-aix5.3.0.0 GCC target triplet: powerpc64-ibm-aix5.3.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29292
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #8 from mrs at apple dot com 2006-09-29 23:15 --- > If it is a VAR_DECL, then I believe the optimization is always safe Not in C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug target/29293] New: Darwin PPC float to integer conversion bug
The fp-int-convert-timode testcase fails at all optimization levels using -m64 on Darwin PPC. The failures are not due to the long or long double sections of the testcase but rather the float section. I was able to reduce this to smaller testcase by reducing the fp-int-convert-timode testcase to calls to... TEST_I_F(TItype, UTItype, float, FLT_MANT_DIG) which then only calls one of the six possible failing tests... TEST_I_F_VAL (I, F, HVAL0S (P, I) + 1, P_OK (P, I)); This shortened testcase, when processed with -E in gcc, can be recasted as the expanded macros as the fp_int_convert_testcase.c testcase where I have replaced the abort() call with a printf(). This test compiled at -m64 on Darwin PPC produces the output... fv1 85070601871439417691678863831567695872.00 fv2 85070591730234615865843651857942052864.00 ivin 1 ivout 0 which compares to the correct result obtained on Linux x86_64 (with the printf() placed after the if statement) of... fv1 85070601871439417691678863831567695872.00 fv2 85070601871439417691678863831567695872.00 ivin 1 ivout 0 Interestingly, if I take the fp_int_convert_testcase.c.f testcase and compile it at -m64 with gcc 4.1.1 on x86_64, I get the same results as what we currently get in gcc trunk on Darwin PPC. This makes me think that the fix already resides in gcc trunk but has not be expanded to include Darwin PPC. -- Summary: Darwin PPC float to integer conversion bug Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29293
[Bug target/29293] Darwin PPC float to integer conversion bug
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2006-09-29 23:33 --- Created an attachment (id=12356) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12356&action=view) fp_int_convert_testcase.c testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29293
[Bug target/29293] Darwin PPC float to integer conversion bug
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2006-09-29 23:35 --- Created an attachment (id=12357) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12357&action=view) fp_int_convert_testcase.i preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29293
[Bug target/29293] Darwin PPC float to integer conversion bug
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2006-09-29 23:36 --- Created an attachment (id=12358) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12358&action=view) fp_int_convert_testcase.s assembly file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29293
[Bug tree-optimization/29294] New: 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM
The attached file benefits greatly from the ARM postincrement address mode. In 4.1.1 and 4.2 20060923, we no longer get postincrement addressing mode, but (base+4) followed by base = base+4 This leads to an increase in instruction count of 40%. While the test is of course trivial, I see real code not benefiting from postmodify quite often while using 4.1.1. I'm not quite sure if it belongs in tree-optimization, but it comes out of the expander as separate (set (reg B) (plus (reg A) (4)) (set (reg C) (plus (reg A) (4)) which is how it ends up in the assembly -- Summary: 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eplondke at gmail dot com GCC host triplet: x86_64-suse-linux GCC target triplet: arm-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294
[Bug tree-optimization/29294] 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM
--- Comment #1 from eplondke at gmail dot com 2006-09-29 23:38 --- Created an attachment (id=12359) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12359&action=view) Test for postmodify address mode simple function that benefits from postmodify selection -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294
[Bug libfortran/29121] CPU_TIME subroutine missing for REAL(kind=10) argument
--- Comment #5 from kargl at gcc dot gnu dot org 2006-09-29 23:39 --- Fixed on 4.1 branch. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29121
[Bug rtl-optimization/29294] 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM
--- Comment #2 from eplondke at gmail dot com 2006-09-29 23:42 ---
GCC 4.1/4.2 ouptut looks like:
postinc:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
ldr ip, [r1, #0]
ldr r3, [r0, #0]
stmfd sp!, {r4, lr}
mul lr, r3, ip
ldr r4, [r1, #4]
ldr r2, [r0, #4]
add r1, r1, #4
mla ip, r2, r4, lr
add r0, r0, #4
ldr r2, [r1, #4]
ldr r3, [r0, #4]
add r1, r1, #4
mla lr, r3, r2, ip
add r0, r0, #4
ldr r2, [r1, #4]
ldr r3, [r0, #4]
add r1, r1, #4
mla ip, r3, r2, lr
add r0, r0, #4
GCC 3.4.2 output looks like:
postinc:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r4, r5, lr}
ldr r4, [r1], #4
ldr r5, [r0], #4
ldr r2, [r1], #4
ldr lr, [r0], #4
mul ip, r2, lr
mla r3, r4, r5, ip
ldr lr, [r0], #4
ldr r2, [r1], #4
mla r3, r2, lr, r3
ldr ip, [r0], #4
ldr r2, [r1], #4
mla r3, r2, ip, r3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294
[Bug rtl-optimization/29294] 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-29 23:43 --- Actually this case should not be using post modify at all except how many bits does ARM have to use for an offset? I thought 16bits which means you don't need that at all and GCC should generate it without an increment. Oh and this is a RTL opt issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294
[Bug c++/29295] New: ++ operator with bool typedef increments
This program:
extern "C" void abort();
typedef bool my_bool;
int main()
{
my_bool b = false;
int i;
b++;
b++;
i = b;
if (i != 1)
abort ();
return 0;
}
calls abort(), because GCC is generating an increment for the '++' operator
rather than setting the value to true, and so 'i' becomes 2 not 1.
--
Summary: ++ operator with bool typedef increments
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29295
[Bug target/29292] configure produces strange gmp, mpfr lib directories.
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-30 01:56 --- This looks like a target problem. The 4.1 branch built fine on amd64-*-freebsd with --with-gmp=/usr/local. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29292
[Bug c/29296] New: Makeing multi libgcc Error
In gcc-3.4.6
..When the multi library is made, it becomes an error when assuming
./configure --target=sh-unknown-linux-gnu.
Cause
Reference define was wrong in gcc-3.4.6/gcc/config/sh/linux.h.
---Cut Hear---
diff -ruN gcc-3.4.6.orig/gcc/config/sh/linux.h gcc-3.4.6/gcc/config/sh/linux.h
--- gcc-3.4.6.orig/gcc/config/sh/linux.h2004-01-12 11:29:13.0
+0900
+++ gcc-3.4.6/gcc/config/sh/linux.h 2006-08-09 17:24:32.0 +0900
@@ -182,7 +182,7 @@
/* MD_FALLBACK_FRAME_STATE_FOR is not yet defined for SHMEDIA. */
#else /* defined (__SH5__) */
-#if defined (__SH3E__) || defined (__SH4__)
+#if defined (__SH4E__) || defined (__SH4__)
#define SH_FALLBACK_FRAME_FLOAT_STATE(SC, FS, CFA) \
do { \
int i_, r_;
\
---Cut Hear---
--
Summary: Makeing multi libgcc Error
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jah03127 at nifty dot com
GCC build triplet: gcc-3.4.6
GCC host triplet: debian/gnu linux Kernel-2.4.32
GCC target triplet: sh-unknown-linux-gnu-gcc 3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29296
