Andreas Jaeger [EMAIL PROTECTED] writes:
make proto on gcc trunk fails on Linux/x86_64 with:
Do you actually need protoize and unprotoize? I think it would be
nice to deprecate them. Prototypes have been available for at least
15 years now.
The trivial workaround is to add to
Dear colleagues,
Many thanks for the development of GCC!
I built GCC 4.1.1 on 32 and 64 bit computers; the pertinent data is
given below:
32 bit (Intel Pentium4 1.5 GHz):
---
i686-pc-linux-gnu
Using built-in specs.
Target: i686-pc-linux-gnu
Configured
Hi,
as the subjects states I try to find information about the .debug and
.line section in elf files. My elf files are build with gcc for ARC. The
elf man page is quite sparse about these sections. Can anyone give me a
hint where to find more information? Or where to look within the gcc
source
Joe Buck wrote:
On Thu, Jun 22, 2006 at 11:49:45AM +0200, Roberto COSTA wrote:
By the way, is there any news about the status of the CIL issue?
I'm sorry to bother the list readers about this, but whom could I
directly ask?
Sorry for the delay in answering, Robert. I was out of town, and
Hello Olivier,
I would suggest looking at ELF and DWARF specifications [1] for the
standards documentation, and gcc/dwarf2out.c for the implementation.
HTH
Best regards
saurabh
Links:
~
1. http://refspecs.freestandards.org/
On Wed, 2006-06-28 at 09:01 +0200, Oliver Eichler wrote:
The SC discussed it with Richard Stallman, and he agrees that it is not
dangerous (the FSF had raised objections to byte-code systems in the
past, so many of us assumed there would be a problem). So there is no
political/legal objection to including a CIL back end. If it passes
technical
Laurynas Biveinis [EMAIL PROTECTED] writes:
Hi,
combine.c: top mem usage: 52180k (13915k). GC execution time 0.66
(0.61) 4% (4%). User running time: 0m16 (0m14).
Are these with checking on or off? Normally checking is on, you have
to go out of your way to turn it off. If it were
Jason Merrill [EMAIL PROTECTED] writes:
Gabriel Dos Reis wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
| I'm just not comfortable with the idea of #pragmas affecting
| instantiations. (I'm OK with them affecting specializations, though; in
| that case, the original template has
Andrew Pinski [EMAIL PROTECTED] writes:
| On Jun 27, 2006, at 7:58 AM, Gabriel Dos Reis wrote:
|
| We we do have numbers that support that claim for real programs, then
| we have a bug in the optimizers :-)
|
| Huh?
Yes.
| Stupid example where a const argument can change:
| tree a;
| int
On 6/27/06, David McCullough [EMAIL PROTECTED] wrote:
AFAIK, you need to drop the -FPIC in favour of -fpic everywhere.
From the GCC manual, -fpic vs. -fPIC `makes a difference on the m68k,
PowerPC and SPARC.' For my purposes, it makes no difference on the
ARM.
You could try some
Oliver Eichler wrote:
Hi,
as the subjects states I try to find information about the .debug and
.line section in elf files. My elf files are build with gcc for ARC. The
elf man page is quite sparse about these sections. Can anyone give me a
hint where to find more information? Or where to look
On 6/28/06, Shaun Jackman [EMAIL PROTECTED] wrote:
I have experimented with GCC 4.0.3, 4.1.0, and 4.1.1. I found that
4.1.x behave the same; however, GCC 4.0.3 does not emit GOTOFF32
relocations. Apparently these are a new feature and preferable in some
instances since they do reduce the number
Geoffrey Keating wrote:
In the traditional declaration/definition model, if you try to change
the linkage of something you get an error...
Indeed, if you consider visibility to be an intrinsic property of the
template (like its type, say), you could argue:
(1) the template gets to specify the
Brian Dessent wrote:
is a good thing: replace an ISO standard-conformant and perfectly
adequate atexit function already supplied by OS vendor with a new
version, perhaps with some licensing strings attached.
As a MinGW user, I would prefer not to see __cxa_atexit added to MinGW.
I really
On Wed, Jun 28, 2006 at 12:40:00PM -0400, Mark Mitchell wrote:
As a MinGW user, I would prefer not to see __cxa_atexit added to MinGW.
I really want MinGW to provide the ability to link to MSVCRT: nothing
more, nothing less. Cygwin is an excellent solution if I want a more
UNIX-like
Hi,
I currently hit an issue that I would like to use a function
statically linked to a shared library but my program use the same
function from another shared library. Here is what I do:
1. I have toto.cxx that has one function called: toto() {cout
static toto endl;}
Hello Richard, Dan,
I'm trying to track down which part of the GCC source tree makes the
decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation.
A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a
reference to a static function. I thought there was a good chance one
of
I am using gcc 3.3.1 (20030804-1) (C/C++ only) inside MinGw in a project. I
have some double data out of range, so it returned
1.#INF,-1.#INF,1.#IND,-1.#IND.
I don't know what's difference between IND and INF?
The INF can use isinf( ) to judge it, how to judge IND?
Also INF can use if(data0.0)
Shaun Jackman writes:
Hello Richard, Dan,
I'm trying to track down which part of the GCC source tree makes the
decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation.
A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a
reference to a static function. I
On Wed, Jun 28, 2006 at 11:20:00AM -0600, Shaun Jackman wrote:
Hello Richard, Dan,
I'm trying to track down which part of the GCC source tree makes the
decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation.
A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a
On Thu, Jun 22, 2006 at 11:49:45AM +0200, Roberto COSTA wrote:
By the way, is there any news about the status of the CIL issue?
I'm sorry to bother the list readers about this, but whom could I
directly ask?
I wrote:
Sorry for the delay in answering, Robert. I was out of town, and
Joe Buck wrote:
As I understand it, Microsoft has patented aspects of their C++ class
layout.
That might be, and we should investigate that before actually trying to
implement a compatible layout, but it doesn't change my opinion about
the original question regarding __cxa_atexit -- unless
Geoffrey Keating wrote:
[#pragma visibility affecting explicit instantiations]
A consequence of this is that if a user instantiates a template that
they don't 'own' (that is, a template from a different module), they
must make sure that no #pragma is in effect, because the other module
may
On Wed, Jun 28, 2006 at 02:21:55PM -0400, Mark Mitchell wrote:
Joe Buck wrote:
As I understand it, Microsoft has patented aspects of their C++ class
layout.
That might be, and we should investigate that before actually trying to
implement a compatible layout, but it doesn't change my
Mark Mitchell writes:
As a MinGW user, I would prefer not to see __cxa_atexit added to MinGW.
I really want MinGW to provide the ability to link to MSVCRT: nothing
more, nothing less.
Well, even Microsoft's compiler doesn't just to link MSVCRT.DLL (or it's
successors) a certain part of C runtime
hello:
I am a PhD student working on optimal instruction scheduling problems. I want
to
integrate my scheduler into the GCC. Can you tell me where to start? and
important links which can be helpful for the integration work?
Thanks
Abid Malik
This mail
On 6/28/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
GOTOFF support has been there for a long while. Only use of it for
static functions is recent. It should be easy to find. But this is
not at all the only problem. GCC's PIC model assumes a fixed
displacement between segments.
Even if a
On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote:
I'm not terribly familiar with the GCC source tree. I scanned
config/arm/arm.c and its SVN log for changes that might affect
GOTOFF32, but came up empty. Do you know where the decision of GOT or
GOTOFF would be handled?
Sorry, it
On 6/28/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote:
I'm not terribly familiar with the GCC source tree. I scanned
config/arm/arm.c and its SVN log for changes that might affect
GOTOFF32, but came up empty. Do you know where the
On Jun 28, 2006, at 1:59 PM, [EMAIL PROTECTED] wrote:
I am a PhD student working on optimal instruction scheduling
problems. I want to
integrate my scheduler into the GCC. Can you tell me where to
start? and
important links which can be helpful for the integration work?
I'd start by
At http://gcc.gnu.org/ml/gcc/2006-06/msg00911.html
Mark Mitchell wrote:
I think it would be better to adopt [mingw-targetted] G++ to use
whatever method Microsoft uses to handle static destructions.
Ultimately, I would like to see G++ support the Microsoft C++ ABI --
unless we can convince
Notice that the value of the parameter b is never changed in the
function body. Consequently, if the current optimizers cannot figure
that simple cases out (where b is not annotated const), then the
optimizers in deficient in that respect. That is the point.
-- Gaby
I agree that the
On Jun 28, 2006, at 7:14 PM, Kaveh R. Ghazi wrote:
Notice that the value of the parameter b is never changed in the
function body. Consequently, if the current optimizers cannot figure
that simple cases out (where b is not annotated const), then the
optimizers in deficient in that respect.
Hongbo Li [EMAIL PROTECTED] writes:
This question would be more appropriate for the gcc-help mailing list
rather than the gcc mailing list.
I currently hit an issue that I would like to use a function
statically linked to a shared library but my program use the same
function from
On 28/06/2006, at 2:21 PM, Jason Merrill wrote:
Geoffrey Keating wrote:
[#pragma visibility affecting explicit instantiations]
A consequence of this is that if a user instantiates a template that
they don't 'own' (that is, a template from a different module), they
must make sure that no
Danny Smith wrote:
I have a patch that allows use of atexit for destructors in the same way
as
__cxa_atexit in cp/decl.c and decl2.c and will submit in Stage1 next.
That sounds great.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Wed, Jun 28, 2006 at 03:54:29PM -0600, Shaun Jackman wrote:
On 6/28/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote:
I'm not terribly familiar with the GCC source tree. I scanned
config/arm/arm.c and its SVN log for changes that
On Wed, Jun 28, 2006 at 10:24:27PM -0400, Geoffrey Keating wrote:
Suppose a library template has (my syntax may not be quite right):
template struct foo class T __attribute__((visibility(default))) {
static T my_var;
T inc (T x) { return my_var += x; }
};
The intention is that all
Kaveh R. Ghazi [EMAIL PROTECTED] writes:
[...]
| I'd like to do for tree and rtx what I did for const char *, namely
| constify those tree/rtx functions that aren't supposed to modify their
| arguments. This would require introducing the const_tree and
| const_rtx typedefs Tristan suggested.
test.c:
#include stdio.h
#include sys/types.h
#include sys/shm.h
int main()
{
int i = 0;
int shmid[3];
void *addr[3];
for (i=0; i3; i++) {
shmid[i] = shmget(IPC_PRIVATE, 256*1024*1024ULL,
SHM_HUGETLB|IPC_CREAT|SHM_R|SHM_W);
if (shmid[i] 0) {
perror(shmget);
--- Comment #2 from pluto at agmk dot net 2006-06-28 08:56 ---
following testcase doesn't generate warning in 4.1.2svn.
3.3.6 works fine.
#include string
std::string const foo()
{
std::string tab[ 1 ] = { std::string( text ) };
int const idx = 0;
return tab[ idx
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-06-28
09:52 ---
The mingw runtime library now has a gettimeofday function which should give
resolution to usec. When libgfortran is configured with the latest mingw
runtime package, gettimeofday is found and used.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-28 11:13 ---
Can you try 4.0.3 or 4.1.1 as 3.4.x is no longer being maintained?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28185
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-28 11:15 ---
(In reply to comment #2)
That would almost mean as is being miscompiled on m68k.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-28 11:21 ---
(In reply to comment #0)
Sorry if it is ill-built bugreport, this is my first one.
This bug report was reported correctly and actually it is very useful.
Anyways confirmed, still a bug in 4.0.x, 4.1.x and the
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-28 12:11
---
On my system, I have the lastest mingw runtime (from the www.mingw.org download
page):
mingw-runtime-3.9.tar.gz341 kb Oct 27, 200517:10
and libgfortran configury does not find
[ i486 ]
gcc -O2 -fno-strict-aliasing -fwrapv -march=i486 -ggdb -DHAVE_POSIX_REGCOMP
-c -o fetch.o fetch.c
cc1: out of memory allocating 4064 bytes after a total of 1292098548 bytes
[ powerpc ]
gcc -O2 -fno-strict-aliasing -fwrapv -fsigned-char -ggdb -DHAVE_POSIX_REGCOMP
-c -o fetch.o
--- Comment #1 from pluto at agmk dot net 2006-06-28 12:46 ---
Created an attachment (id=11768)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11768action=view)
i486 precompiled testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28187
--- Comment #2 from pault at gcc dot gnu dot org 2006-06-28 13:22 ---
(In reply to comment #1)
John,
Have all these errors just appeared or do they go back to the era of
actual_array_constructor_1.f90; ie 04/04/06?
The reason that I ask is that I am wondering if this is an incipient
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-06-28 14:32
---
(In reply to comment #2)
mingw-runtime-3.9.tar.gz341 kb Oct 27, 200517:10
There was in fact a mingw-runtime-3.10 release, but it's not yet on the
appropriate mingw.org page (it's on
I'm building a shared library with libpthread and libmudflapth support.
Flags used to compile are: -fstack-protector -fmudflapth
Flags used to link are: -lmudflapth
When trying to dlopen the shared lib at runtime I get:
symbol lookup error: /home/melfar/gcc4/lib/libmudflapth.so.0: undefined
Between 20050805 and 20060208, many libjava execution tests started to time
out on Tru64 UNIX (both V4.0F and V5.1B), as can be seen comparing the
following test results:
http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00708.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00899.html
Compiling crtstuff.c with arm-elf-gcc 4.0.3 for -mthumb -fPIC
-msingle-pic-base fails. I had no trouble compiling GCC 4.1.1.
Cheers,
Shaun
make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc'
make GCC_FOR_TARGET=/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc
Since at least 20060503, libjava fails to bootstrap on IRIX 6.5.28:
/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/./gcc/xgcc -shared-libgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/mips-sgi-irix6.5/32/libstdc++-v3/src
Hi,
This looks like floating point rounding problem but it's not. Please review the
following testcase:
#include stdio.h
double func(double p) {
return 1.097986768 * 7654 / 4.5678913 + 1/p;
}
int main()
{
double PARAM = 3.0001;
double aVal = func(PARAM);
double bVal =
--- Comment #1 from rozenman at gmail dot com 2006-06-28 15:46 ---
Created an attachment (id=11769)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11769action=view)
Testcase program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28191
Compiling crtstuff.c with arm-elf-gcc 4.0.3 for -mthumb -fPIC
-msingle-pic-base fails. I had no trouble compiling GCC 4.1.1.
Cheers,
Shaun
make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc'
make GCC_FOR_TARGET=/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc
Execute-in-place (XIP) code, commonly used with uClinux, places the .text
section in flash and the .data section in RAM. GCC 4.1 emits R_ARM_GOTOFF32
relocations for symbols in the .text segment relative to the GOT, which is in
the .data segment. This new behaviours breaks XIP. See the following
--- Comment #25 from steven at gcc dot gnu dot org 2006-06-28 17:30 ---
Pure luck or not, this is a regression.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from sjackman at gmail dot com 2006-06-28 17:36 ---
Created an attachment (id=11772)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11772action=view)
Backport thumb_find_work_register from 4.1.1
2005-03-01 Nick Clifton [EMAIL PROTECTED]
* config/arm/arm.c
When shift count is the same as the length of a variable (eg, l 32 where
long int l;), this doesn't return 0, instead it returns a rotated value.
Below is assumed to return 0, but actually returns 2468.
---t2.c---(test case)
#include stdio.h
long long ll;
long l;
int
main(){
l = 1234;
ll
--- Comment #1 from falk at debian dot org 2006-06-28 17:57 ---
Shifting by an amount larger than the size of a type is undefined behavior,
so anything might happen. Gcc even warns about this.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #14 from jjcogliati-r1 at yahoo dot com 2006-06-28 18:02
---
This works in 4.1.0, so only 4.1.1 has this bug so far as I can tell.
--
jjcogliati-r1 at yahoo dot com changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-28 18:49 ---
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #82 from pinskia at gcc dot gnu dot org 2006-06-28 18:49
---
*** Bug 28191 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jason at gcc dot gnu dot org 2006-06-28 19:12 ---
Turns out to be a bug in alias grouping. Patch in testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27768
--- Comment #26 from whaley at cs dot utsa dot edu 2006-06-28 19:57 ---
Created an attachment (id=11773)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11773action=view)
raw runs table is generated from
As promised, here is the raw data I built the table out of, including a new run
--- Comment #2 from sjackman at gmail dot com 2006-06-28 20:18 ---
This proposed patch does help. At the very least, it prevents the ICE on
compiling crtstuff.c while compiling the toolchain. However, with this patch
applied, I saw the same bug later while compiling newlib. As the
The following code is miscompiled when using -m64 (=ppc64) target:
const static double a = 1.0;
const static double *b = (double*)a - 1;
b[1] should be a, but it's not - there is an additional offset of 0x1
--
Summary: miscompiled initialization of a constant pointer
--- Comment #1 from inbox at b-q-c dot com 2006-06-28 20:44 ---
Created an attachment (id=11774)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11774action=view)
test case - returns 0 on success or 1 when miscompiled
gcc -m64 -o gcc64bug gcc64bug.c
Inspection of the a and b will
--- Comment #2 from inbox at b-q-c dot com 2006-06-28 20:47 ---
The original description should state that there is an additional offset of
0x1 (it said 0x1 instead).
Also this bug is reproducible with earlier version of gcc such as 4.0.1 as
supplied by Apple.
--
--- Comment #3 from inbox at b-q-c dot com 2006-06-28 20:50 ---
Created an attachment (id=11775)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11775action=view)
output of gcc -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28196
--- Comment #3 from sjackman at gmail dot com 2006-06-28 20:51 ---
I tried backporting thumb_compute_save_reg_mask from GCC 4.1.1 to GCC 4.0.3
without success. I'll try backporting this entire patch from svn.
2005-03-01 Nick Clifton [EMAIL PROTECTED]
* config/arm/arm.c
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-28 21:05 ---
.quad _a-8
Not a GCC bug, a bug in the cctools assembler/linker, report this to Apple.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-28 21:14 ---
I can reproduce this on the mainline with a cross to powerpc64-linux-gnu with
-m32 -O2 -fwrapv.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-28 21:16 ---
Actually this is a dup of bug 25035.
*** This bug has been marked as a duplicate of 25035 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-06-28 21:16
---
*** Bug 28133 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-28 21:18 ---
Confirmed, we don't record in the preprocessor which keyword is used, _Complex
is treated the same as __complex__. There is another bug about a similar issue
with or and |.
--
pinskia at gcc dot gnu dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-28 21:21 ---
PR 14875 is the related bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-28 22:00 ---
Created an attachment (id=11776)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11776action=view)
Fixes the problem and some
The attached patch fixes the PR and fixes character valued functions in array
--- Comment #4 from sjackman at gmail dot com 2006-06-28 22:30 ---
I tried applying r95736 (2005-03-01 Nick Clifton) and r103151 (2005-08-16
Richard Earnshaw) against GCC 4.0.3. Both these patches apply cleanly (with
offsets), but don't fix the problem compiling newlib.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-28 23:31 ---
Is this a regression?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Summary|4.1.1 misses constant
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-28 23:34 ---
Is this a regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28158
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-28 23:35 ---
I think it was caused by:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01526.html
Which means this is a 4.2 Regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
I got a bus error by following program which use longjmp and __builtin_alloca
with -O0.
% cat z.c
#include setjmp.h
jmp_buf env;
void f(int a1, int a2, int a3, int a4, int a5, int a6, int a7, int a8)
{
longjmp(env, 1);
}
int main()
{
if (setjmp(env) == 0) {
void *p =
--- Comment #6 from sjackman at gmail dot com 2006-06-29 00:01 ---
Applying the patch from r103277 fixes this bug. I also had r95736 and r103151
applied against my 4.0.3 tree at the time. So, I don't know if r103277 alone is
sufficient. r103277 was meant to close PR target/23473, so
--- Comment #7 from sjackman at gmail dot com 2006-06-29 00:10 ---
Subject: Re: [4.0 only] config/arm/arm.c:3140 ICE
On 28 Jun 2006 23:31:22 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-28 23:31
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-29 00:30 ---
(In reply to comment #4)
FAIL: gcc.dg/visibility-11.c scan-assembler [EMAIL PROTECTED]
Yes this one is known.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28137
--- Comment #12 from jason at gcc dot gnu dot org 2006-06-29 01:12 ---
Subject: Bug 27768
Author: jason
Date: Thu Jun 29 01:12:20 2006
New Revision: 115062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115062
Log:
PR c++/27768
* tree-ssa-alias.c
--- Comment #2 from jason at gcc dot gnu dot org 2006-06-29 01:27 ---
Subject: Bug 27424
Author: jason
Date: Thu Jun 29 01:27:17 2006
New Revision: 115063
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115063
Log:
PR c++/27424
* pt.c (convert_template_argument):
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #1 from akr at m17n dot org 2006-06-29 01:49 ---
I found a way to reproduce the bus error with -O2 as well as -O0.
% cat z.c
#include setjmp.h
jmp_buf env;
int i;
int main()
{
if (setjmp(env) == 0) {
char *p = __builtin_alloca(1024);
for (i = 0; i 1024; i++) {
--- Comment #27 from hjl at lucon dot org 2006-06-29 02:32 ---
Created an attachment (id=11777)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11777action=view)
An integer loop
I changed the loop from double to long long. The 64bit code generated by gcc
4.0
is 10% slower than gcc
--- Comment #28 from whaley at cs dot utsa dot edu 2006-06-29 04:17 ---
Guys,
If you are looking for the reason that the new code might be slower, my feeling
from the benchmark data is that involves hiding the cost of the loads. Notice
that, except for the cases where the double
95 matches
Mail list logo
