--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-23 06:19
---
Created an attachment (id=12477)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12477action=view)
Example patch
I don't know if it's giving correct results in all cases, or if it works even
on platforms
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-23 06:39 ---
(gdb) p debug_rtx(x)
(unspec:DI [
(symbol_ref:DI (_ZN6string20_S_empty_rep_storageE) [flags 0x40]
var_decl 0xb7d9c060 _S_empty_rep_storage)
] 2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29443
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-23 06:47 ---
Reduced testcase:
struct string
{
struct _Rep{}; static _Rep _S_empty_rep_storage[];
void *_M_rep () const{} void _M_destroy () throw ();
~string ()
{
_Rep *a = (_Rep *)((void
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-23 06:48 ---
Note this looks like a latent bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29443
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-10-23 07:15
---
Subject: Bug 21032
Author: rguenth
Date: Mon Oct 23 07:15:45 2006
New Revision: 117968
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117968
Log:
2006-10-23 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-10-23 07:16
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-23 07:19 ---
Subject: Bug 29548
Author: rguenth
Date: Mon Oct 23 07:19:34 2006
New Revision: 117969
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117969
Log:
2006-10-24 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-23 07:19
---
Subject: Bug 23295
Author: rguenth
Date: Mon Oct 23 07:19:34 2006
New Revision: 117969
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117969
Log:
2006-10-24 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-23 07:19 ---
Subject: Bug 27132
Author: rguenth
Date: Mon Oct 23 07:19:34 2006
New Revision: 117969
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117969
Log:
2006-10-24 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-10-23 07:20
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-23 07:20 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-23 07:20 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29548
--- Comment #2 from keinstein_junior at gmx dot net 2006-10-23 07:28
---
(In reply to comment #1)
Can you provide some details on the out of date .mod files? Were they
compiled
with a different compiler version or on a different architecture? Or are they
just not up-to-date with
--- Comment #16 from nathan at gcc dot gnu dot org 2006-10-23 07:42 ---
Subject: Bug 20647
Author: nathan
Date: Mon Oct 23 07:42:02 2006
New Revision: 117970
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117970
Log:
cp/
PR c++/20647
* rtti.c (tinfo_base_init):
--- Comment #16 from pluto at agmk dot net 2006-10-23 08:11 ---
Subject: Re: cross build's libgcc picks up CFLAGS
lianghua xu napisaÅ(a):
did you save this bug? I am failled in this trouble 2 weeks since I
making the
cross tools for arm-elf-tools under CYGWIN on XP os. any
(...)
Adding multilib support to Makefile in ../../zlib
multidirs=32
with_multisubdir=
Running configure in multilib subdirs 32
pwd: /home/users/pluto/rpm/BUILD/gcc-4_2-branch/builddir/zlib
Running configure in multilib subdir 32
pwd: /home/users/pluto/rpm/BUILD/gcc-4_2-branch/builddir
mkdir 32
We ICE there with the following testcase compiled with -g -O:
void stpi_unpack_16_1(int length,const unsigned char *in,unsigned char
*out0,unsigned char *out1,unsigned char *out2,unsigned char *out3,
unsigned char *out4,unsigned char *out5,unsigned char *out6,
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-10-23 09:23 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01156.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-23 09:49 ---
Created an attachment (id=12478)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12478action=view)
Provisional fix for the PR
This not only fixes the PR but the modification to trans-types allows a data
statement
--- Comment #3 from pault at gcc dot gnu dot org 2006-10-23 10:02 ---
Created an attachment (id=12479)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12479action=view)
Provisional general fix for the PR
This patch fixes the the following:
real, parameter :: a(2,2) = reshape
--- Comment #4 from bonzini at gnu dot org 2006-10-23 10:11 ---
Like this?
Index: /Users/bonzinip/cvs/gcc/Makefile.def
===
--- /Users/bonzinip/cvs/gcc/Makefile.def(revision 116745)
+++
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-23 10:14 ---
Slightly more reduced:
void stpi_unpack_16_1(int length, unsigned char *out, unsigned char bit)
{
unsigned char tempin;
unsigned char temp[16];
for (bit = 128; length 0; length--) {
if (tempin 128)
with '-O1 -ftree-vrp -fwrapv' the armencrypt.test from
gnupg-1.4.5 release producing an output until ENOSPC.
with '-O1 -fno-tree-vrp' test passes.
$ cd gnupg-1.4.5/checks/
$ srcdir=. ./armencrypt.test
$ ls -l x
-rw--- 1 builder2 users 108946 Oct 23 10:32 x
this bug is specific for
--- Comment #1 from pluto at agmk dot net 2006-10-23 10:35 ---
(In reply to comment #0)
with '-O1 -ftree-vrp -fwrapv' the armencrypt.test from
gnupg-1.4.5 release producing an output until ENOSPC.
with '-O1 -fno-tree-vrp' test passes.
^ fix: -O1
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-23 11:29 ---
Fails on the 4.2.0 branch. On the 4.1 branch it might be due to packports of
2006-05-23 Alexandre Oliva [EMAIL PROTECTED]
* simplify-rtx.c (simplify_subreg): Adjust REG_OFFSET for
big-endian
For setting individual bits of a register, the construct
unsigned char BitLocation = Whatever;
REG |= (1BitLocation);
is commonly used. avr-gcc fails to realize that the target register
is only 8 bits wide and performs an unnecessary 16-Bit shift of 1.
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-23 11:45 ---
Testcase? ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from pluto at agmk dot net 2006-10-23 11:51 ---
(In reply to comment #2)
Testcase? ;)
ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.5.tar.bz2 ;)
working on reduced version...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29559
this error:
gfortran -o testhex TestHex.F90
In file TestHex.F90:8
integer(i4_), parameter :: b = zFF81
1
Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1)
for the gfortran version downloaded today (20061023) from
http://quatramaran.ens.fr
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-23 11:58 ---
Note this is a regression on the 4.1 branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kloedej at knmi dot nl 2006-10-23 12:03 ---
Sorry, variable names should differ of course, the sample code should be:
program testhexconstant
integer, parameter :: i4_ = Selected_Int_Kind( 9)
! works fine
integer(i4_), parameter :: a = z7F81
!
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-10-23 12:10 ---
(In reply to comment #3)
Can you provide a testcase where something goes wrong?
I was merely documenting a problem that I found while reading the code;
I don't have time to write a testcase now.
--
The program
program gftest
write(*,'(a)') 'Hello World'
end program gftest
generates the erroneous error report
At line 3 of file gftest.f90
Fortran runtime error: Missing initial left parenthesis in format
Äø
when compiled with the -malign-double flag. In a larger
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-23 13:02 ---
Keith,
You do not report your hardware/OS/gfortran version - your testcase works for
me on amd64/SUSE10.1 or Cygwin_NT/gcc-4.3
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29562
--- Comment #2 from refson dot temp at ntlworld dot com 2006-10-23 13:46
---
Sorry. This is on a 32-bit AMD Athlon 1800+ processor. I assume the issue
doesn't
arise on 64-bit hardware.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29562
/gfortran_nightbuild/irun-20061023
--enable-languages=c,fortran
--with-gmp=/home/fxcoudert/gfortran_nightbuild/software
Thread model: posix
gcc version 4.3.0 20061023 (experimental)
The O/S is Mandriva 2006.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29562
gcc version 4.3.0 20061023 (experimental)
Mandriva 2006.0
The program
program gfbread
character(len=256), dimension(3) :: block_data = (/'1 2 3','4 5 6','7 8
9'/)
real(kind=8), dimension(3,3) :: tmp_box
read(block_data,*,iostat=iostat)((tmp_box(i,j),j=1,3),i=1,3)
write
I want to build gfortran with --disable-shared so that I can give fortran
programs created with gfortran to people who need to use the programs, but do
not have gfortran installed. I configured with -
../gcc/configure --disable-shared --prefix=/usr/local/gfortran
--enable-languages=c,fortran
--- Comment #9 from drow at gcc dot gnu dot org 2006-10-23 14:15 ---
I haven't had another chance to work on this; update assigned to reflect
reality. Hopefully the analysis will be useful to someone.
--
drow at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from arno at heho dot snv dot jussieu dot fr 2006-10-23
14:58 ---
Created an attachment (id=12480)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12480action=view)
Take III
Most of the original patch probably has been commited when
adding support for GNU/kFreeBSD.
--- Comment #8 from daney at gcc dot gnu dot org 2006-10-23 15:00 ---
The patch is here:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01149.html
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-23 15:19 ---
This is not a bug, -malign-double changes the ABI.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-23 15:22 ---
*** This bug has been marked as a duplicate of 26510 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-23 15:22 ---
*** Bug 29564 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 15:24 ---
Caused by:
2005-09-28 Geoffrey Keating [EMAIL PROTECTED]
* config/rs6000/t-darwin8: Uncomment contents, allow -m64
multilib to be built.
* Makefile.in: Export LIPO_FOR_TARGET,
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 15:26 ---
Caused by:
2004-11-03 Andrew Pinski [EMAIL PROTECTED]
* config/darwin.h (REAL_LIBGCC_SPEC): Define to use shared
libgcc for shared libraries.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 15:44 ---
(In reply to comment #4)
Like this?
Actually thinking about it some more, that will cause stage1 not to be build
with the more checking if the user wanted it to be, ie
--enable-checking=yes,rtl,gcac when
Fortran 95 (GCC) 4.3.0 20061023 (experimental)
--
Summary: ICE in gimplify_var_or_parm_decl, at gimplify.c
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: fortran
--- Comment #1 from william dot mitchell at nist dot gov 2006-10-23 15:47
---
Created an attachment (id=12481)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12481action=view)
this is the program that demonstrates the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29565
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from william dot mitchell at nist dot gov 2006-10-23 15:49
---
This is on Linux Fedora Core 1 with a Linux binary download of gfortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29565
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29565
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-23 15:54 ---
program gfbread
character(len=256), dimension(3) :: block_data = (/' 1 2 3',' 4 5 6',' 7 8
9'/)
real(kind=8), dimension(3,3) :: tmp_box
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-23 15:58 ---
Confirmed, reduced testcase:
module hash_mod
type element_t
integer :: gid
end type element_t
type grid_type
type(element_t), pointer :: element(:)
end type grid_type
contains
subroutine hash_read_key(key)
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-23 16:06 ---
It works for me with 4.1.2 20061017 but fails with 4.2.0 20061015 so this only
fails on the 4.2 branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pcarlini at suse dot de 2006-10-23 16:26 ---
The issue seems more tricky, even for TLS platforms, see:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00333.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24025
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-23 17:10 ---
Please the audit trail for Pr 18026. It gives the details.
Also, the difference in the earlier version of gfortran to
the newer version is due to this patch.
2006-09-07 Steven G. Kargl [EMAIL PROTECTED]
--- Comment #11 from kargl at gcc dot gnu dot org 2006-10-23 17:10 ---
*** Bug 29561 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-23 17:11
---
Further reduced testcase, confirmed on ppc-darwin:
type element_t
integer :: gid
end type element_t
type(element_t) :: element(1)
call hash_read_key(element%gid)
call hash_read_key(element%gid)
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-10-23 17:30 ---
(In reply to comment #6)
A regression hunt identified the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=116424
r116424 | amylaar | 2006-08-25 18:51:57 + (Fri, 25 Aug 2006)
When I
version 4.3.0 20061023 (experimental)
/home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951
test.f90 -quiet -dumpbase test.f90 -mtune=generic -auxbase test -O2 -version -I
/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/finclude -o
/tmp/ccsOQohf.s
GNU F95
--
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 2006-10-23 18:13 ---
Can you try the patch in:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01168.html
?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
There's an on-off discussion on the gfortran mailing
list on making 4-byte record markers the default for gfortran.
This would only be acceptable if large (2 GB) records could
be written that way.
I'm taking a shot at this.
--
Summary: implement unformatted files with subrecords
--- Comment #12 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-23 18:52 ---
Cf. also bug 29471.
In the Intel Fortran Compiler
real :: r
data r/some BOZ/
gives the same result as using the Fortran 2003 statement in ifort:
real :: r
r = real(some boz)
(At least with
(stevenhu) / [159] cat a.c
void func(){}
main(){
int a,b;
/*asm( %ecx %eax);*/
asm(add %0,%1,%2:=r(a):m(func),m(b));
}
(stevenhu) / [160] gcc -S a.c
a.c: In function `main':
a.c:6: Internal compiler error in instantiate_virtual_regs_1, at
function.c:3972
Please submit a full bug report,
with
--- Comment #6 from dir at lanl dot gov 2006-10-23 19:02 ---
I tried to disable the multilib with -
../gcc/configure --disable-shared --disable-multilib
--prefix=/usr/local/gfortran --enable-languages=c,fortran
but I still about the save errors -
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-23 19:05
---
(In reply to comment #4)
Can this PR be closed?
I'd say yes.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-23 19:07
---
Fixed on 4.2 branch and probably earlier:
In file a.f90:1
integer*1 :: i1 = 255_1
1
Error: Integer too big for its kind at (1)
In file a.f90:2
integer*2 :: i2 = 65535_2
--- Comment #4 from batt at develer dot com 2006-10-23 19:09 ---
I have 3 projects involving gcc and avr, and all of these have an increased RAM
usage due to __clz_tab linking after switching from gcc 4.1.1 to 4.2.
I will try as soon as possible to find a suitable testcase.
--
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-10-23 19:11
---
As Andrew already noted, this is not fixed on the 4.1 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janis at gcc dot gnu dot org 2006-10-23 19:16 ---
A regression hunt using the testcase from comment #2 with -O2 using an
alpha-linux cross compiler identified this patch which fixed the ICE on
mainline:
http://gcc.gnu.org/viewcvs?view=revrev=110556
r110556
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-23 19:27 ---
This works for me in 3.0.4 to 3.4.0 and now errors out in 4.0.0 and above with:
t.c:5: error: memory input 1 is not directly addressable
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-23 19:28
---
We now reject the reporter's code as we should. We could still reject the code
in comment #1, but none of the other compilers I tried reject it. Marking this
as low priority (I think it will be fixed by Paul
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-10-23 19:32
---
Mark, you accidentally committed the fix in parser.c with your patch
for PR 28506 (rev. 117695) to the 4.1 branch:
http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00361.html
So this is now fixed on the 4.1 branch, too.
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu
2006-10-23 19:39 ---
Subject: Re: boz initialization of REALs fails
On Mon, Oct 23, 2006 at 06:52:06PM -, tobias dot burnus at physik dot
fu-berlin dot de wrote:
In the Intel Fortran Compiler
real :: r
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-23 19:49 ---
Thomas,
Have you written Adrain about his plans concerning his patch?
BTW, I think the Intel subrecord approach is probably the best
solution to the large record problem.
--
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-10-23 19:50
---
(In reply to comment #1)
Can you try the patch in:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01168.html
?
Yes, this patch fixes the problem. Thanks for the prompt reply!
--
The following valid code snippet triggers a segfault on mainline,
4.1 branch, and 4.0 branch. The regression is recent, since GCC 4.1.1
is not affected.
templateint struct A
{
static const int i;
};
templateint N const int AN::i = { AN::i
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
==
struct A
{
static const int i = 0/0 + ;
static const int j = int(i);
};
==
bug.cc:3: warning: division by zero in '0 / 0'
bug.cc:3: error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29571
The following invalid code snippet triggers a segfault since GCC 3.4.0:
==
templateint struct A {};
templatetypename struct B : A sizeof(=) {};
templatetypename struct C : A sizeof(=) {};
==
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29573
--- Comment #13 from ghazi at gcc dot gnu dot org 2006-10-23 20:25 ---
Subject: Bug 29335
Author: ghazi
Date: Mon Oct 23 20:24:55 2006
New Revision: 117983
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117983
Log:
PR middle-end/29335
* builtins.c
Compile Linux 2.6.18 kernel. Warns that idx may be uninitialized in
fs/bio.c:bio_alloc_bioset(), but it clearly *is* being initialized
by bvec_alloc_bs.
The kernel team will not allow us to pre-initialize these, as it is
a gcc bug. On the other hand, we're drowned in invalid warnings, so
can't
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-10-23 20:41
---
Just a minor nit: The second error message still contains the - token
which should not have been generated. But that's probably tolerable.
bug.c:2:1: error: pasting - and does not give a valid preprocessing
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-23 20:57 ---
How is unlikely defined?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29574
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-23 20:59 ---
If it is defined using __builtin_expect, then this is most likely PR 21513
which was fixed for 4.2.0, it is hard to fix correctly for 4.1.0 and 4.0.0
without removing all of loop.c.
Can you attach the preprocessed
--- Comment #3 from mbligh at mbligh dot org 2006-10-23 21:08 ---
Yeah, is builtin_expect ;-(
#define likely(x) __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect(!!(x), 0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29574
--- Comment #4 from mbligh at mbligh dot org 2006-10-23 21:19 ---
And indeed, if I remove that unlikely(), it does work.
There's another set of these where the called initializer is not inlined,
ie:
int x;
initializer(x);
Which it seems totally blind to, even if the initializer does
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-23 21:30 ---
*** Bug 29574 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 21:30 ---
(In reply to comment #4)
And indeed, if I remove that unlikely(), it does work.
There's another set of these where the called initializer is not inlined,
ie:
int x;
initializer(x);
If initializer is not
--- Comment #8 from pinskia at gmail dot com 2006-10-23 21:37 ---
Subject: Re: [4.2 Regression] optmization generates warning for casts
On 23 Oct 2006 17:30:22 -, amylaar at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
I think it is wrong that we are optimizing the expression
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #6 from mbligh at mbligh dot org 2006-10-23 21:42 ---
Re the non-inlined functions ...
Have been discussing this with Andrew Morton.
what do we do then? Adding dead code to fix the fact that gcc can't see into
other functions is incorrect and inefficient.
Having lots of
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-23 21:45 ---
(In reply to comment #6)
Re the non-inlined functions ...
Have been discussing this with Andrew Morton.
what do we do then? Adding dead code to fix the fact that gcc can't see into
other functions is incorrect
--- Comment #8 from mbligh at mbligh dot org 2006-10-23 21:50 ---
Initialize the variable and forget about inefficiency. Again this is fixed
for
4.2.0, the warning is only because __builtin_expect gets in the way of
figuring
out if the variable is used uninitialized, nothing
--- Comment #8 from mbligh at mbligh dot org 2006-10-23 21:50 ---
Initialize the variable and forget about inefficiency. Again this is fixed
for
4.2.0, the warning is only because __builtin_expect gets in the way of
figuring
out if the variable is used uninitialized,
1 - 100 of 119 matches
Mail list logo
