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/linu
--- 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
-
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'
--- 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 increme
--- 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, l
--- 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
--- 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/
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 co
--- 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
--- 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
--- 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
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 t
--- 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
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 dire
--- 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
--- 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 { st
>
>
>
> --- 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.
--- 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__((n
--- 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): Remov
--- 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): Remov
--- 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
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 c
--- 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/specific
--- 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
--- 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
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
--- 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
--- 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/
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. rebuildi
--- 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 dif
--- 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
--- 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
--- 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.or
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
|
(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)
-
--- 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
---
--- 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(v
--- 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
--- 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:
--- 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.
--
--- 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 |
--- 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
BugsThisDepen
--- 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
---
--- 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 (
--- 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 yo
$ 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
--- 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
--- 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
exp
--- 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 leas
--- 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, l
--- 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
-
--- 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
--- 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|
--- 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
--- 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
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
--- 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=292
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();
--- 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
-
--- 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
--
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
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154
--- 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
--
--- 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)
--- 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
--- 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
--- 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 |Adde
$ 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()
EN
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 h
69 matches
Mail list logo
