--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-09 06:53
---
My patch at http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00364.html fixes this
problem (I noted it during while designing the patch, but didn't fill a PR
because I knew it would be fixed soon :)
Thanks Tobias for
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-06-09 06:43
---
I'm reopening the PR because the bug is not fixed yet on the 4.1 branch. The
current policy is to allow a week before comitting your patch to 4.1 (after
bootstrap & regtesting), and then close the bugzilla PR.
(i
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-09 06:20 ---
Here is the RTL we get on PPC:
(insn 6 9 7 2 (set (reg/v:SI 120 [ x ])
(reg:SI 3 r3 [ x ])) 327 {*movsi_internal1} (nil)
(expr_list:REG_DEAD (reg:SI 3 r3 [ x ])
(expr_list:REG_EQUIV (mem/c/i:SI (p
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-09 06:18 ---
This works correctly on powerpc. The rtl we get on x86_64 is:
(insn 10 7 11 2 (parallel [
(set (reg:DI 61)
(lshiftrt:DI (reg/v:DI 59 [ x ])
(const_int 2 [0x2])))
array[(x>>2)&3] can be arranged to avoid the right shift.
consider:
% cat shift-and-fold.c
unsigned array[4];
unsigned foo(unsigned long x)
{
return array[(x>>2)&3ul];
}
% /home/odo/gcc/bin/gcc -g -O3 -Wall -c -o shift-and-fold.o shift-and-fold.c
% objdump -dr shift-and-fold.o
shift
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-09 05:52 ---
../../Sources/API/Display/Collision/../../GL/opengl_wrap.h:2533: error:
'' has incomplete type
../../Sources/API/Display/Collision/../../GL/opengl_wrap.h:2533: error: invalid
use of 'CLvoid'
setupdisplay.cpp:120: in
--- Comment #6 from patchapp at dberlin dot org 2006-06-09 05:50 ---
Subject: Bug number PR19310
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00435.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from thomasda at heronet dot ne dot jp 2006-06-09 05:47
---
Created an attachment (id=11643)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11643&action=view)
compile output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27970
tried to make ClanLib:
here's the last lines of the compile that generated the error:
1 -DUSE_GETADDR=1 -I. -I. -I/usr/X11R6/include -g -O2 -I../../Sources -MT
surface_generic.lo -MD -MP -MF .deps/surface_generic.Tpo -c surface_generic.cpp
-fPIC -DPIC -o .libs/surface_generic.o
g++ -DPACKAGE_NA
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-09 05:37 ---
First off this instruction has been in x87 since at least 287, see
http://www.sandpile.org/post/msgs/2234.htm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27968
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-09 05:15 ---
technically i386-solaris is a multilib target in that -m64 is also built which
means if you don't have a 64bit userland (and in the solaris case GNU as then
you are out of luck as building 64bit requires GNU as). So
[EMAIL PROTECTED]:/export/emil/gcc/objdir> uname -a
SunOS cicada 5.10 Generic_Patch i86pc i386 i86pc
[EMAIL PROTECTED]:/export/emil/gcc/objdir> /export/emil/gcc/gcc-4.1.1/configure
--enable-languages=c --prefix=/usr/local/stow/gcc-4.1.1/pkg/gcc-4.1.1
[EMAIL PROTECTED]:/export/emil/gcc/objdir> gmake
--- Comment #7 from echristo at apple dot com 2006-06-09 01:12 ---
Confirmed. Patch appears to work. I'll submit it a bit later. Short, one liner.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
DEAR Sir : GNU
I am writing to you regarding bug report
It resulted based on the last point when having experimented ..the
following...
#include
#include
void subroutine(int n)
{
int buf[n];
fprintf(stderr, "%d (%d)\n", (int)sizeof(buf), (unsigned long)buf);
}
int main( int argc, cha
--- Comment #5 from wilson at specifix dot com 2006-06-09 00:17 ---
Subject: Re: Problem: gcc 4.0.3 on Unix_SV
mirko dot bruzzone at primeur dot com wrote:
> gt-c-pragma.h:46: parse error before `__attribute__'
gt-c-pragma.h uses attribute unused in a parameter list, before the
param
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-09 00:05 ---
One thing is to use GNU binutil's as instead. The other thing to do is to file
a bug with Sun (which is better anyways).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #14 from jbwaters at gmail dot com 2006-06-09 00:01 ---
I have not been able to find that configure option so far, do you happen to
know what it is off hand?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20737
--- Comment #6 from echristo at apple dot com 2006-06-09 00:00 ---
Think I've got a patch. testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
GCC emits the (undefined) instruction ffreep when TARGET_USE_FFREEP is set
(which happens when -mtune opteron or -mtune athlon is passed on the command
line.
As of the latest available build, Solaris' /usr/ccs/bin/as doesn't understand
this opcode and barfs.
The use of ffreep seems to have been i
--- Comment #5 from echristo at apple dot com 2006-06-08 23:57 ---
FWIW btw, the edge case only occurs when the bitfield is the full length of the
array size.
Guh.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-08 23:47 ---
Can I also recommend that gcc.dg/bf-ms-layout.c (and all the ms struct layout
tests if there is another one) be changed to run on PPC-darwin and x86 with the
pragam's for ms_struct?
--
http://gcc.gnu.org/bugzill
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-06-08 23:45
---
Configure with an abosulte path instead of a relative one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20737
--- Comment #12 from jbwaters at gmail dot com 2006-06-08 23:43 ---
Ok, with just configure and no options I get
$ gmake bootstrap
mkdir build-i386-unknown-netbsdelf3.0.0.
$ gmake bootstrap3
mkdir build-i386-unknown-netbsdelf3.0.0./libiberty
Configuring in build-i386-unknown-netbsdelf3.
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-06-08 23:32
---
(In reply to comment #10)
> Just tried to build 4.1.1 on NetBSD 3.0 , and this error is still present
You are using --enable-boostrap, that is what is wrong. Don't use it as it is
known to be broken before 4.2.0.
--- Comment #10 from jbwaters at gmail dot com 2006-06-08 23:25 ---
Just tried to build 4.1.1 on NetBSD 3.0 , and this error is still present
gmake[3]: Leaving directory `/home/jbw/dl/gnu/gcc-4.1.1/obj/stage1-libiberty'
gmake[3]: Entering directory `/home/jbw/dl/gnu/gcc-4.1.1/obj/stage
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-06-08 23:05
---
*** Bug 27967 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-08 23:05 ---
*** This bug has been marked as a duplicate of 16185 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Here is the result.
./configure --prefix=/home/user --disable-gcc-check
> cc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-language
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-06-08 22:45
---
(In reply to comment #18)
> The regression was introduced by:
Exposed by and not introduced. If you look at my patch which you approved, I
had mentioned this failure when I fixed most of -fsection-anchors for Darw
--- Comment #18 from mrs at apple dot com 2006-06-08 22:40 ---
The regression was introduced by:
2006-04-30 David Edelsohn <[EMAIL PROTECTED]>
* config/rs6000/rs6000.c (rs6000_override_options): Enable
TARGET_NO_FP_IN_TOC for section anchors.
(optimization_opt
--- Comment #3 from echristo at apple dot com 2006-06-08 22:39 ---
Verified. Investigating. The alignment should be 8 from what I can see:
a -> 1st byte
int :0 -> align to 4th byte
b -> 5th byte
c -> 6th byte
align structure to 8th byte because of int :0.
--
echristo at apple dot co
--- Comment #2 from dannysmith at users dot sourceforge dot net 2006-06-08
22:32 ---
(In reply to comment #1)
> Can you get me the size of that structure according to MS VC?
With version 12.00.8804 of MS cl.exe, sizeof (struct six) == 8, as tested in
the testcase.
Danny
--
http
--- Comment #17 from mrs at apple dot com 2006-06-08 22:26 ---
This should be fixed now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
--- Comment #5 from sje at cup dot hp dot com 2006-06-08 22:25 ---
I think using configure to detect whether or not _Unwind_GetIPInfo exists may
be difficult. The libstdc++ configure script seems to go out of its way to not
link programs or to use and/or look at libgcc in anyway.
Anyon
--- Comment #6 from echristo at apple dot com 2006-06-08 22:23 ---
Sure. Sounds good. As I said, the ABI stuff I've seen (and helped write) don't
take packed into account anywhere :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27942
--- Comment #16 from mrs at gcc dot gnu dot org 2006-06-08 22:23 ---
Subject: Bug 26427
Author: mrs
Date: Thu Jun 8 22:23:17 2006
New Revision: 114498
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114498
Log:
PR target/26427
* config/darwin.c (darwin_asm_output
--- Comment #5 from kkojima at gcc dot gnu dot org 2006-06-08 22:17 ---
I also couldn't find any document refering to it. My patch is just
a guess from the behavior for nonzero-size bitfield with the packed
attribute appeared in the last 3 lines of my patch. I'd like to
send my patch t
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-06-08 21:48
---
Subject: Bug 27958
Author: fxcoudert
Date: Thu Jun 8 21:48:05 2006
New Revision: 114496
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114496
Log:
PR fortran/27958
* trans-expr.c (gfc_co
--- Comment #2 from echristo at apple dot com 2006-06-08 21:40 ---
Submitted patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27542
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-08 21:26
---
No, go ahead if you have time (I'm buried deep into bounds-checking). I confirm
this bug on MinGW, I think the problem might not appear on cygwin.
--
fxcoudert at gcc dot gnu dot org changed:
What
Hayashi Eisuke wrote:
> 100: 400 (-1077752048)
> 2092728: Segmentatioin error (core dumped)
The process is dying because you are exceeding unix process stack space
limits. You probably have an 8MB per process limit, and the number you
are using is a tad less than 2MB.
If you are using ba
--- Comment #8 from sje at cup dot hp dot com 2006-06-08 21:12 ---
I do not think my patch is correct. The variable causing the problem is
created in gimplify_parameters by a call to create_tmp_var. This local
variable is only created on systems that pass structures by pointers and whi
--- Comment #35 from echristo at apple dot com 2006-06-08 21:06 ---
I'm unlikely to work on this...
--
echristo at apple dot com changed:
What|Removed |Added
Assi
--- Comment #4 from langton at gcc dot gnu dot org 2006-06-08 21:03 ---
I've committed a patch that should fix this bug.
--
langton at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from langton at gcc dot gnu dot org 2006-06-08 21:01 ---
Subject: Bug 27786
Author: langton
Date: Thu Jun 8 21:00:26 2006
New Revision: 114495
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114495
Log:
* cray_pointers_2.f90: Add -fbounds-check compile fla
--- Comment #15 from reichelt at gcc dot gnu dot org 2006-06-08 20:53
---
The problem with unions is now also fixed on mainline.
Will commit to 4.1 and 4.0 branch in a couple of days.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
--- Comment #14 from reichelt at gcc dot gnu dot org 2006-06-08 20:50
---
Subject: Bug 27421
Author: reichelt
Date: Thu Jun 8 20:50:24 2006
New Revision: 114494
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114494
Log:
PR target/27421
* config/i386/i386.c (cla
--- Comment #7 from sje at cup dot hp dot com 2006-06-08 20:34 ---
Created an attachment (id=11642)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11642&action=view)
Proposed patch
I am going to test the attached patch and will submit it to gcc-patches if
there are no regressions.
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2006-06-08
20:23 ---
Subject: Re: [4.2 Regression] libjava fails to build if it isn't built by
default
ayers at gcc dot gnu dot org writes:
> I followed the advice given here:
>
> http://gcc.gnu.org/ml/gcc-patches/2006-05/ms
--- Comment #4 from ayers at gcc dot gnu dot org 2006-06-08 20:18 ---
Hello,
I followed the advice given here:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00886.html
I believe "noconfigdir" is supposed to mean "not supported" so in this case the
correct "patch" would be to remove tart
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-08 19:53 ---
This could be the same as gfortran.fortran-torture/execute/assumed_size.f90,
I'm not completely sure, though.
--
tobias dot burnus at physik dot fu-berlin dot de changed:
What|R
GNU Fortran 95 (GCC) 4.2.0 20060608 (experimental).
-
program test
implicit none
real(8) :: rftp(4)
rftp = 42.0_8
call xcifc(n=4,rho=rftp)
contains
subroutine xcifc(n,rho)
implicit none
integer, optional, intent(in) :: n
real(8), optional, intent(in) :: rho
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2006-06-08
19:15 ---
Subject: Re: [4.2 Regression] libjava fails to build if it isn't built by
default
pinskia at gcc dot gnu dot org writes:
> Maybe it is better to not to disable libjava completely for IRIX. It seems
But
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-06-08 19:14
---
FX, if you want this one, let me know, otherwise I will look into it.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-08 19:11 ---
Maybe it is better to not to disable libjava completely for IRIX. It seems
like --disable-libjava is out of date and wrong in general now (maybe even has
been for a long time).
--
pinskia at gcc dot gnu dot org
Output lines on Windows are incorrectly terminated.
Example:
program le
integer i
do i = 1,6
print *, 'Line ', i
end do
end
The output looks ok on the windows console. However, if you redirect output to
a file, and examine with a hexadecimal viewer, you will see that each line is
t
--- Comment #1 from ro at gcc dot gnu dot org 2006-06-08 18:59 ---
David, your patch caused this regression, so please have a look.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--
Trying to bootstrap mainline on IRIX 6.5 with java included failed since
boehm-gc (which is required for libjava) isn't built:
In file included from /vol/gcc/src/gcc-dist/libjava/include/jvm.h:25,
from /vol/gcc/src/gcc-dist/libjava/include/java-interp.h:14,
from
--- Comment #4 from echristo at apple dot com 2006-06-08 18:14 ---
Well, I suppose the question is whether or not I'm doing something wrong here.
The alignment should be added unilaterally (as far as I can tell from the
documents that I included in the documentation). Part of the questio
--- Comment #1 from echristo at apple dot com 2006-06-08 18:11 ---
Can you get me the size of that structure according to MS VC?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
--- Comment #6 from sje at cup dot hp dot com 2006-06-08 17:47 ---
Created an attachment (id=11639)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11639&action=view)
Cut-down test case
Here is a cutdown test case that fails on hppa1.1-hp-hpux11.11. It does not
fail on hppa64-hp-hp
--- Comment #11 from bangerth at dealii dot org 2006-06-08 17:26 ---
(In reply to comment #8)
> Bangerth, why did you change the Priority? That is the job of the Release
> manager.
Actually, as a remark, I believe this isn't true. Bugmasters have always
adjusted initial priorities of P
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2006-06-08
17:24 ---
Subject: Re: [4.2 Regression] gnatbind fails to link on Tru64 UNIX
charlet at adacore dot com writes:
> Subject: Re: New: gnatbind fails to link on Tru64 UNIX
>
> > Add ada/s-purexc.o to ada/Make-lang.
--- Comment #12 from law at redhat dot com 2006-06-08 16:38 ---
Subject: Re: bootstrap failure building libdecnumber,
ICE in compare_values, tree-vrp.c:432
On Thu, 2006-06-08 at 09:47 +, rguenth at gcc dot gnu dot org wrote:
>
> --- Comment #11 from rguenth at gcc dot
--- Comment #16 from sje at cup dot hp dot com 2006-06-08 15:50 ---
Bizarre, I could swear that when I first tried your fix I got a call to
__muldi3, but I just updated expmed.c, reran the test case and I got the same
inlined sequence that I got before the patch. I think in the first ca
--- Comment #40 from mueller at gcc dot gnu dot org 2006-06-08 15:50
---
I've a patch, which is currently blocked by -fivopts bug
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from bonzini at gnu dot org 2006-06-08 15:40 ---
Subject: Bug 27733
Author: bonzini
Date: Thu Jun 8 15:40:48 2006
New Revision: 114488
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114488
Log:
2006-06-08 Paolo Bonzini <[EMAIL PROTECTED]>
PR middle-en
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Target Milestone|--- |4.1.2
http://
--- Comment #14 from bonzini at gnu dot org 2006-06-08 15:37 ---
Well, it shouldn't. My guess could be that we are hitting the case where the
logic is flawed. The we fill the cache with the algorithm for say 0x10085
(but then we only write 0x84 in the cache), and then use it for 0x
The following testcase causes an ICE on the 4.1 branch and mainline:
template struct A
{
template void foo();
};
template<> template void A<0>::foo() {}
bug.cc:6: error: 'struct
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-06-08 15:32 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-08 15:31 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
The following testcase causes an ICE on the 4.1 branch and mainline:
struct A
{
template void foo(X);
};
bug.cc:7: error: 'X' was not declared in this scope
bug.cc:7: error: variable or field 'foo' declared void
bug.cc:
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-06-08 15:24 ---
(In reply to comment #5)
> As extended regions by default are disabled now, can, please, someone
> reconfirm
> this bug.
Yes this is fixed now.
--
pinskia at gcc dot gnu dot org changed:
What|Re
--- Comment #13 from sje at cup dot hp dot com 2006-06-08 15:11 ---
The proposed patch does fix the compilation time problem on hppa64-hp-hpux11.11
but I am confused about how the cache works. Without the patch, the compile
takes 15 to 20 minutes but I do wind up generating a sequence o
--- Comment #39 from falk at debian dot org 2006-06-08 15:02 ---
I'm not actually working on this at the moment
--
falk at debian dot org changed:
What|Removed |Added
--
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
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-08 14:42 ---
Related to PR 27657, though this is not an unused variable as far as I can
tell.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-06-08 14:36 ---
Don't know how I got assigned, anyways this is fixed by the patch for PR 27793.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-08 14:32 ---
Works in 4.2.0 20060507 and 4.1.0 20060208 and 4.1.2 20060529.
And works as of today in 4.1.2 20060608 so this is still invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27935
--- Comment #99 from pinskia at gcc dot gnu dot org 2006-06-08 14:23
---
*** Bug 27955 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-08 14:23 ---
reinterpret_cast(t) = 1077936128; //binary float
reinterpret_cast(t) = 1077936128; //binary float value
You are violating C/C++ aliasing rules as you are accessing a float as int.
*** This
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-06-08 14:17
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFI
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Keywords||ABI, wrong
--- Comment #17 from tbm at cyrius dot com 2006-06-08 13:54 ---
This segfault also shows up when compiling the Linux kernel (compiling file
net/tipc/net.c).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27882
--- Comment #1 from jakub at gcc dot gnu dot org 2006-06-08 13:33 ---
Created an attachment (id=11638)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11638&action=view)
pr27959.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27959
The testcase I'll attach is miscompiled on s390x with -m64 -O2 -mtune=z990
or -m64 -O2 -mtune=z9-109.
The test function needs a base reg (so %r13 is loaded early and during flow2
the %r13 references actually make it into the assembler). But, during reload
a TImode pseudo is reloaded into TI %r12 (
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
The following code is legal, but segfaults at runtime when compiled with
gfortran:
$ cat a.f90
character(len=10) :: s
s = "abcdefghij"
s(6:5) = s(7:5)
print *, s
end
$ ifort a.f90 -check all && ./a.out
abcdefghij
$ gfortran a.f90 && ./a.out
zsh: segmentation fault ./a.out
--
--- Comment #7 from charles at kde dot org 2006-06-08 13:04 ---
Created an attachment (id=11635)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11635&action=view)
compiles on 4.0
just #include
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27935
--- Comment #12 from bonzini at gnu dot org 2006-06-08 12:26 ---
Created an attachment (id=11634)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11634&action=view)
proposed patch
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from bonzini at gnu dot org 2006-06-08 12:24 ---
OUCH! The number is stored as a unsigned int in the cache, which means that
numbers > 2^32 never hit the cache!
Besides that, it's wise to enlarge the cache for 64-bit hosts, because there
every EXACT_DIV_EXPR will call sy
--- Comment #10 from bonzini at gnu dot org 2006-06-08 12:08 ---
Reduced testcase:
long foo(long zz)
{
return zz * 15238614669586151335;
}
takes "ridiculously long" with -O2 -mdisable-fpregs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
--- Comment #15 from mkuvyrkov at gcc dot gnu dot org 2006-06-08 11:49
---
haifa_sched.c: check_cfg () ICEs because a block with the conditional jump at
the end has only 1 successor (the jump is to the next instruction). I thought
that this is invalid, but now I see that verify_flow_in
I've encoutered a problem with a friend function embedded into a class
declaration AND with the optimisation flag -O2. I have discovered that two
successive identical call to cout<
class A{
friend void load (A* a, float& t){
reinterpret_cast(t) = 1077936128; //binary float
--- Comment #1 from gcc at pdoerfler dot com 2006-06-08 11:00 ---
Created an attachment (id=11633)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11633&action=view)
preprocessed source
Preprocessed source of the file that contains declaration of hacky_auxmaps.
Probably, this is not
The following invalid code snippet causes an ICE since GCC 4.0.0:
==
subroutine FOO
character*20 X 0
data X /'A'/0
end subroutine FOO
==
In file bug.f:4
data X /'A'/0
The following invalid code snippet triggers an ICE in the C frontend since
at least GCC 2.95.3:
=
void foo(struct A a) {}
void foo() {}
=
bug.c:1: warning: 'struct A' declared inside parameter list
bug.c:1: warning: its scope is only this de
1 - 100 of 128 matches
Mail list logo
