--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-24 07:28 ---
This is correct behavior, a string literal is constant data so you are
returning a pointer to a constant data which then you are trying to copy into.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #4 from bugzilla-gcc at thewrittenword dot com 2008-02-24
07:09 ---
(In reply to comment #3)
> Created an attachment (id=15208)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15208&action=view) [edit]
> patch to include string.h and strings.h (stolen from libcpp)
>
> P
Apologies if this has been reported before. I've encountered this behavior in
a test script.
System info (output of uname -a):
Linux opti1 2.6.18-5-686 #1 SMP Mon Dec 24 16:41:07 UTC 2007 i686 GNU/Linux
Output of gcc -v --save-temps...
[EMAIL PROTECTED]:~$ gcc -v -save-temps static-strcpy-bug.c
// David Li:
Conditional generator is not handled, missing redundancy elimination for a[i]
and a[i-1]
int a[1000];
int b[1000];
void foo(int n)
{
int i = 1;
for(; i < n; i++)
{
if (b[i] > 0)
a[i+1] = a[i-1];
b[i] = a[i];
}
}
==> should be (similar to PRE)
// David Li
Gcc's scalar replacement and predictive commoning implementation is very good.
There are some missing cases. Handling output dependence is one of them.
Handling of output dependence. In this case, the store at (1) is dead except
for the last iteration -- it should be sinked out of the
GCC loop unswitching is very good -- handles most of the cases I tried. The
only only thing I notice is that the nested for loops in C in the example below
is not converted into a perfect loop nest:
int** p;
int** q;
void foo(int m, int n)
{
int i, j;
for (i = 0; i < m; i++)
{
f
It is beneficial to unroll reduction loop (and split the reduction target) to
reduce dependence height due to recurrence, but GCC does not perform such
optimization (-O3 -fno-tree-vectorize)
int a[1000];
int b[1000];
int foo(int n)
{
int s = 0;
int i = 0;
for (i = 0; i < 1000 ; i++)
Short trip counted loop nest (perfect or not) is not fully unrolled, only the
innnermost loop:
(-O3 -fno-tree-vectorize)
#ifndef TC
#define TC 3
#endif
int a[100][100];
int foo(void)
{
int i, j;
for (i = 0; i < TC; i ++)
{
for (j = 0; j < TC; j++)
a[2*i][j] += a[i
Gcc fully unrolls short trip counted (known) loop if the unrolled loop body
size d oes not exceed a threshold. However, if the loop has early exit, this
is not done -- leading to missing scalar opt later on.
Example:
int a[100];
int b[100];
int foo(void)
{
int i, j;
for (i = 0; i < 5;
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-24 04:15 ---
I don't think this is a bug. How are you invoking GCC?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from nightstrike at gmail dot com 2008-02-24 03:31 ---
This is a very simple fix. Can someone add it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35250
Hi,
I am trying to compile bootrom on power PC (8360) for vxWorks (version 5.4).
When compiling romInit.S I am getting following errors
./romInit.s:437: Error: too many positional arguments
../romInit.s:453: Error: too many positional arguments
../romInit.s:453: Error: too many positional argumen
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35297
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-24
01:41 ---
Subject: Re: [4.2 Regression] ICE in delete_output_reload, at reload1.c:7926
> --- Comment #16 from eager at eagercon dot com 2008-02-23 21:18 ---
> Attached is a patch to reload.c which addresse
Currently we create a looping structure which is executed to traverse an array
and transfer it one element at a time. This works, but is not too efficient.
We could improve this by converting the implied do loops into the appropriate
array descriptor and call transfer_array.
The two cases are:
--- Comment #2 from xinliangli at gmail dot com 2008-02-24 00:36 ---
(In reply to comment #1)
> (In reply to comment #0)
> > The following rule is not handled by GCC
> >
> > (a & x) || (a & y) ===> a & (x | y)
>
> Perhaps that is because those two expressions aren't equivalent?
>
> B
--- Comment #6 from hjl dot tools at gmail dot com 2008-02-23 23:12 ---
Weak and hidden aren't really compatible. Linker should enforce it.
I opened a linker bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=5789
As for gcc, I think it is OK since it is a user error and linker
should
--- Comment #10 from eager at eagercon dot com 2008-02-23 21:24 ---
Created an attachment (id=15216)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15216&action=view)
More complete fix for reload.c
This is a more complete patch to reload.c.
Duplicate of fix for bug 32889.
--
h
--- Comment #17 from eager at eagercon dot com 2008-02-23 21:21 ---
Created an attachment (id=15215)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15215&action=view)
Fix to reload.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32889
--- Comment #16 from eager at eagercon dot com 2008-02-23 21:18 ---
Attached is a patch to reload.c which addresses the root cause.
--
eager at eagercon dot com changed:
What|Removed |Added
--
--- Comment #5 from pluto at agmk dot net 2008-02-23 21:09 ---
(In reply to comment #3)
> (In reply to comment #2)
>
> > Also you should be using -PIE when linking.
>
> hmm, it doesn't work with int main();
>
> $ gcc -s main.c -fpie -Wl,-pie
> /usr/bin/ld: /usr/lib64/crt1.o: relocatio
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-02-23 20:35 ---
(In reply to comment #7)
> ping^2
I am just finally getting back to my assigned bugs after so long, this is lower
down on the list than some other ones.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34212
--- Comment #7 from pluto at agmk dot net 2008-02-23 20:33 ---
ping^2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34212
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-02-23 20:22 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #7 from galtgendo at o2 dot pl 2008-02-23 20:17 ---
Well, shortly after I reported this bug hardware got upgraded (it was
Christmas).
Now it's 512MB and gcc 4.2.3.
It still fails.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34572
Hi All,
I have a very subtly problem when linking a shared object that includes the
gcc-runtime to support c++ exceptions, type info, ...
The problem is that the following crashes:
try {
throw cCoreException();
}
// catch(const cUnUsedObjectThatWillNeverBeT
--- Comment #31 from fxcoudert at gcc dot gnu dot org 2008-02-23 20:11
---
Subject: Bug 24685
Author: fxcoudert
Date: Sat Feb 23 20:10:29 2008
New Revision: 132577
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132577
Log:
PR libfortran/24685
* gfortran.dg/large
--- Comment #30 from fxcoudert at gcc dot gnu dot org 2008-02-23 20:10
---
On powerpc-apple-darwin9.2, gfortran.dg/large_real_kind_form_io_2.f90 fails for
that reason:
$ cat a.f90
real(kind=16) :: a,b
character(len=180) :: tmp
b = 8.9884656743115795386465259539450128766966288724
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 20:00 ---
(In reply to comment #1)
> Not equivalent in the presence of overflow.
You mean defined overflow :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from segher at kernel dot crashing dot org 2008-02-23 19:57
---
Not equivalent in the presence of overflow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35307
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35338
Broken diagnostics are issued for the following invalid code snippet
on mainline and 4.3 branch:
int i = 1r;
bool b = !1r;
bug.cc:1: error: cannot convert '#'fixed_point_type' not supported b
A broken diagnostic is issued for the following invalid code snippet since
GCC 4.2.0:
struct A {};
void foo()
{
#pragma omp parallel firstprivate(A)
;
}
bug.cc: In function 'void foo()
--- Comment #1 from segher at kernel dot crashing dot org 2008-02-23 19:51
---
(In reply to comment #0)
> The following rule is not handled by GCC
>
> (a & x) || (a & y) ===> a & (x | y)
Perhaps that is because those two expressions aren't equivalent?
But, confirmed, assuming you me
A broken diagnostic is issued for the following invalid code snippet since
at least GCC 2.95.3:
struct A
{
int i : 2;
};
void foo(bool b)
{
A a;
(a.i || b)();
}
bug.cc: In function 'vo
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35335
A broken diagnostic is issued for the following invalid code snippet since
GCC 4.0.0:
struct A {};
void foo()
{
A a;
a = ({ { 1; } });
}
bug.cc: In function 'void foo()':
bug.cc:6: error
A broken diagnostic is issued for the following invalid code snippet since
at least GCC 2.95.3:
void foo(__complex__ unsigned int i)
{
((__complex__ int)i)();
}
bug.cc: In function 'void fo
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35333
A broken diagnostic is issued for the following invalid code snippet since
GCC 4.0.0:
void foo(__complex__ double x)
{
__builtin_conj(x)();
}
bug.cc: In function 'void foo(double __complex_
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35332
Broken diagnostics are issued for the following invalid code snippet since
GCC 3.0:
void foo(double x)
{
__builtin_isgreater(x, 0.0)();
__builtin_isless(x, 0.0)();
__builtin_isunordered(x, 0.0)();
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35331
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
template struct A;
template struct A
{
friend void foo();
};
bug.cc:3: error: parameter packs not expanded wi
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330
The following invalid code snippet triggers an ICE since GCC 3.1.1:
#pragma weak int = foo
:0: error: weak declaration of 'int' must be public
bug.c:1: internal compiler error: in make_decl_r
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35329
The following invalid code snippet triggers an ICE since GCC 4.2.0:
#pragma implementation
#pragma interface
template struct A
{
A() {}
};
bug.cc:4: error: 'void' is not a valid type for a
The following invalid code snippet triggers an ICE since GCC 4.2.0 when
compiled with "-fopenmp":
struct A
{
~A()();
};
void foo()
{
A a;
#pragma omp parallel firstprivate(a)
;
}
b
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35327
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
struct A
{
A(int)();
};
template void foo(bool b, A a) { b ? a : 0; }
bug.cc:3: error: 'A' declared as functi
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35326
The following invalid code snippet triggers an ICE since GCC 4.2.0:
%:%:;
bug.cc:1: error: stray '%:%:' in program
bug.cc:1: internal compiler error: vector VEC(fs_p,base) index domain error,
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35325
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
template struct A {};
template struct B : A {};
template struct C : A {};
bug.cc:5: internal compiler error: i
--- Comment #49 from fxcoudert at gcc dot gnu dot org 2008-02-23 19:00
---
To fix this completely, a little bit more work is required to check what should
be done for nanl(), which is not handled by current patch. (I don't have time
to look into it.) For more information, see
http://gcc
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35324
The following invalid code snippet is accepted since GCC 3.4.0:
=
template struct A {};
template struct B : A {};
=
Before the code was correctly rejected, although the error message
couldn't be printed:
bug.cc:3: s
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 18:51 ---
The preprocessor is the one that is crashing and the preprocessor in the case
of the #pragma is the one that errors out.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35323
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
=
void foo(int);
void bar()
{
foo(1r);
}
=
bug.cc: In function 'void bar()':
bug.cc:5: internal compiler error: in arg_assoc_type, at c
--- Comment #39 from jb at gcc dot gnu dot org 2008-02-23 18:46 ---
(In reply to comment #38)
> Janne, do you want to bring your patch from comment #35 up to date and submit
> for approval to the lists?
Sure, I hope to get it done withing a few days; assigning to myself.
--
jb at gc
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35322
The following invalid code snippet triggers an ICE since GCC 4.2.0:
=
_Pragma("GCC dependency")
=
bug.c:1: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
A correct error message i
--- Comment #48 from fxcoudert at gcc dot gnu dot org 2008-02-23 18:42
---
Subject: Bug 25477
Author: fxcoudert
Date: Sat Feb 23 18:42:04 2008
New Revision: 132576
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132576
Log:
PR target/25477
* config/darwin-protos
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35321
The following invalid code snippet triggers an ICE since GCC 4.0.0:
=
struct A
{
A operator[] (int);
};
struct B
{
A a;
};
void foo()
{
__builtin_offsetof(B, a[0]);
}
=
bug.cc: In function 'void foo()':
bug.cc
--- Comment #16 from tege-gcc at swox dot com 2008-02-23 18:27 ---
I don't know how a PLT entry looks like. They use the object format
macho, of which I know nothing.
Note that the new testcase does not have any recursive calls.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35320
The following invalid code snippet triggers an ICE since GCC 3.1:
==
typedef void (func_type)();
struct A
{
friend func_type f : 2;
};
==
bug.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Befor
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-02-23 18:17
---
The code also ICEs without "-O".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35319
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35319
The following valid code snippet triggers an ICE on mainline and 4.3 branch
when compiled with -O:
===
void foo()
{
throw 0r;
}
===
bug.cc: In function 'void foo()':
bug.cc:3: internal compiler error: in write_type, at cp/mangle.c:1695
Please submit a full bug report, [e
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 18:12 ---
this works on:
Target: i386-apple-darwin8.11.1
Configured with: /Users/apinski/src/local/gcc/configure
--prefix=/Users/apinski/local-gcc --disable-multilib
Thread model: posix
gcc version 4.4.0 20080223
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-02-23 18:10
---
Still, can I ask how does the PLT entry of Darwin look like? It seems a bit
weird that recursive call that should not trigger lazy binding will get into
code relying on the alignment.
Or are some kind of aliases i
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35318
The following valid code snippet triggers an ICE on mainline and 4.3 branch
when compiled with -O:
void foo()
{
double x = 4, y;
__asm__ volatile ("" : "=r,r" (x), "=r,r" (y) : "%0,0" (x), "m,r" (8));
}
--- Comment #14 from hubicka at gcc dot gnu dot org 2008-02-23 18:05
---
I see. It is quite pity that Darwin's dynamic linker insist on the alignment.
I guess it would be worthwhile to try to tell GCC to optimize those calls as
local: calling overhead of recursive functions is quite ex
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-23 18:02 ---
The RTL level has been fixed. The tree level needs fixing still but I am not
working on that.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35317
The following valid code snippet triggers an ICE since GCC 3.1:
struct A
{
void operator delete[] (void*, ...);
};
bug.cc:2: internal compiler error: Segmentation fault
Please submit a full bug report, [et
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 17:59 ---
Subject: Bug 33512
Author: pinskia
Date: Sat Feb 23 17:58:48 2008
New Revision: 132575
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132575
Log:
2008-02-23 Andrew Pinski <[EMAIL PROTECTED]>
PR rt
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35316
The following valid code snippet triggers an ICE since GCC 4.2.0:
==
template struct A
{
int i : 2;
void foo()
{
typeof(i) j;
}
};
==
bug.cc: In member function 'void A< >::foo()':
bug.cc:7: internal compiler error: Segmentation fault
P
--- Comment #10 from drow at gcc dot gnu dot org 2008-02-23 17:45 ---
Subject: Re: References to original ${prefix} paths in
relocated toolchain and /lib and /usr/lib search paths appear in
cross toolchain.
On Sat, Feb 23, 2008 at 08:54:56AM -, kkylheku at gmail dot
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35315
The following valid code snippet triggers an ICE on mainline:
=
typedef union { int i; } U __attribute__((transparent_union));
static void foo(U) {}
static void foo(int) {}
void bar()
{
foo(0);
}
==
--- Comment #9 from drow at gcc dot gnu dot org 2008-02-23 17:43 ---
Subject: Re: References to original ${prefix} paths in
relocated toolchain and /lib and /usr/lib search paths appear in
cross toolchain.
On Sat, Feb 23, 2008 at 08:03:34AM -, kkylheku at gmail dot
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35314
The following valid testcase triggers an ICE since GCC 4.2.0 when compiled
with "-fmudflap":
#include
jmp_buf buf;
void foo(volatile char* p)
{
if (__builtin_setjmp(buf))
*p;
}
bug.c: In function 'foo':
bug.c:6: err
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 17:16 ---
I think this is a dup of bug 22168.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35312
--- Comment #13 from tege-gcc at swox dot com 2008-02-23 17:09 ---
Created an attachment (id=15214)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15214&action=view)
This is a minimized version of the original faling code.
I understand the reasoning about local calls. The problem
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-23 17:08 ---
Subject: Bug 35027
Author: pinskia
Date: Sat Feb 23 17:08:12 2008
New Revision: 132574
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132574
Log:
2008-02-23 Andrew Pinski <[EMAIL PROTECTED]>
PR pc
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 17:08 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pcarlini at suse dot de 2008-02-23 17:00 ---
*** This bug has been marked as a duplicate of 13399 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2008-02-23 17:00 ---
*** Bug 35275 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-02-23 16:48
---
Status: local experimental trunk
Front-end has most if not all keywords compiling.
DECIMAL= is working all the way through to runtime.
WAIT compiles and executes a stub in the runtime with a new st_parameter_wa
--- Comment #38 from jvdelisle at gcc dot gnu dot org 2008-02-23 16:40
---
Janne, do you want to bring your patch from comment #35 up to date and submit
for approval to the lists?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
--- Comment #5 from kcwu at csie dot org 2008-02-23 16:21 ---
this issue is resolved in gcc 4.3 20080221 snapshot.
$ time gcc43 -O3 -c f5.c -Wall
user0m0.418s
And the memory usage is less than 10 MB.
--
kcwu at csie dot org changed:
What|Removed
1 - 100 of 123 matches
Mail list logo
