--- Comment #26 from ubizjak at gmail dot com 2008-04-25 06:29 ---
Reopened.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #25 from ubizjak at gmail dot com 2008-04-25 06:27 ---
*** Bug 36039 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #2 from ubizjak at gmail dot com 2008-04-25 06:27 ---
You need to backport http://gcc.gnu.org/viewcvs?view=rev&revision=128549
*** This bug has been marked as a duplicate of 26449 ***
--
ubizjak at gmail dot com changed:
What|Removed |
--- Comment #5 from an at atrn dot org 2008-04-25 05:27 ---
> Which glibc version do you use?
As per description it's FreeBSD 7's (aka STABLE) libc who's ld.so
implementation uses gcc's glibc-specific unwinding.
> You should probably report this as a bug to your vendor.
Done with pat
--- Comment #31 from pinskia at gcc dot gnu dot org 2008-04-25 05:09
---
*** Bug 36042 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 2008-04-25 05:09 ---
Fixed in 4.3.0 already, almost won't be fixed in 4.2.x.
*** This bug has been marked as a duplicate of 29478 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-04-25 04:36
---
I am working on this.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
I created the following test code:
int x;
inline myfun (void*m)
{
x = *(int *)m;
}
int
bar (const void *p)
{
myfun ((void *)p);
}
If I compile it as:
gcc -c test.c
I don't get a warning. However:
gcc -O -c test.c
produces the following:
test.c: In function bar:
test.c:9: warning: pass
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-04-25 01:48
---
I think this is fixed.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-04-25 01:03 ---
Fixed.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from intvnut at gmail dot com 2008-04-25 00:39 ---
When run on my Opteron 280 system, the four separate implementations give the
following run times:
popcount64_1 = 1313 clocks
popcount64_2 = 648 clocks
popcount64_3 = 374 clocks
popcount64_4 = 549 clocks
--- Comment #1 from intvnut at gmail dot com 2008-04-25 00:36 ---
Created an attachment (id=15529)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15529&action=view)
Popcount sample implementations
These implementations are derived from insights in Henry S. Warren's Hacker's
Delight
The current __builtin_popcountll (and likely __builtin_popcount) are fairly
slow as compared to a simple, short C version derived from what can be found in
Knuth's recent publications. The following short function is about 3x as fast
as the __builtin version, which runs counter to the idea that __
Hello,
Ezt a levelet azert kapod mert 'MurvaiP' nevu tagunk szeretne meghivni tagjaink
koze.
O mar minden bizonnyal ismertetett a dolgok mikentjenek a hogyanjarol, de azert
elkuldjuk mi is az adatokat.
Tehat eloszor is a lenyeg, a tartalomrol:
A site pillanatnyi tartalmat a kovetkezo 48 oraba
--- Comment #6 from bkoz at gcc dot gnu dot org 2008-04-24 23:39 ---
Can I re-classify this as an enhancement?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
--- Comment #6 from bkoz at gcc dot gnu dot org 2008-04-24 23:37 ---
Fixed.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-04-24 23:36 ---
Ack! Wrong bug. But, I accept and re-open.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-04-24 23:36 ---
Subject: Bug 35887
Author: bkoz
Date: Thu Apr 24 23:35:22 2008
New Revision: 134650
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134650
Log:
2008-04-24 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libst
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-04-24 23:35 ---
Fixed.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-04-24 23:35 ---
Fixed on trunk, gcc-4_3-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35887
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-04-24 23:31 ---
Subject: Bug 35887
Author: bkoz
Date: Thu Apr 24 23:30:10 2008
New Revision: 134649
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134649
Log:
2008-04-24 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libst
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|regression |tree-optimization
Known to fail||4.1
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-24 22:26 ---
Using %rsi some times is ok, as the 32bit instructions zero extend the values
into the extended registers.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
I've recently run into a problem with some linux KVM code that may be a bug in
gcc-4.3.0. I'm building the KVM modules on Fedora 9 x86_64, with gcc --version
reporting:
[EMAIL PROTECTED] kvm-userspace]# gcc --version
gcc (GCC) 4.3.0 20080416 (Red Hat 4.3.0-7)
Copyright (C) 2008 Free Software Foun
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-04-24 22:01 ---
Updated patch:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01871.html
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from gnu at the-meissners dot org 2008-04-24 21:49 ---
Created an attachment (id=15528)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15528&action=view)
This is the test case that fails.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36039
The attached source when compiled with -O2 and -ftree-vectorize aborts with a
gcc internal compiler error. It aborts in expand_simple_binop which is given
VEC_SELECT as the code to expand. Both GCC 4.1 and GCC 4.3 compiles this fine,
and expand_simple_binop is not called for the VEC_SELECT case i
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-04-24 21:28 ---
instead of
AC_LIBTOOL_DLOPEN
AM_PROG_LIBTOOL
AC_SUBST(enable_shared)
AC_SUBST(enable_static)
libgomp/acinclude.m4 has
sinclude(../libtool.m4)
dnl The lines below arrange for aclocal not to bring an installed
dnl lib
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-04-24 21:10 ---
Mine.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at g
--- Comment #7 from ubizjak at gmail dot com 2008-04-24 19:56 ---
Created an attachment (id=15527)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15527&action=view)
x86_64 asm dump of trisolve procedure (genereated without the patch)
All the difference is in trisolve procedure (att
--- Comment #10 from michael dot baudin at gmail dot com 2008-04-24 19:55
---
Subject: Re: Recursive function with allocatable array
Thank you for fixing the bug.
Michaël
On Sun, Apr 20, 2008 at 12:32 AM, pault at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment
--- Comment #3 from s__nakayama at infoseek dot jp 2008-04-24 19:39 ---
Sorry, my code is undefined.
By 12.1/7, member of foo is not initialized. I
--
s__nakayama at infoseek dot jp changed:
What|Removed |Added
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2008-04-24 19:10
---
Reply to comment #18. I have not had time to dig further on these memory
issues. I think after George has a revamped patch in, I will explore some more
on this. We are probably just not freeing some memory aft
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2008-04-24 19:05
---
The part that was causing the crash has been reverted. Can you try with
current latest trunk version 4.4.0 and see if it really is the silver bullet?
and report back here.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #19 from jakub at gcc dot gnu dot org 2008-04-24 18:48 ---
With the changes checked in, I believe there is no regression anymore, but
using vector_size, altivec or spu_vector attributes on template parameters will
still do bad and unexpected things.
--
jakub at gcc dot gn
--- Comment #9 from dje at gcc dot gnu dot org 2008-04-24 18:06 ---
Well, I did not receive your second ping. But I was traveling and had been
planning to check it in today.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from dje at gcc dot gnu dot org 2008-04-24 17:59 ---
Subject: Bug 35597
Author: dje
Date: Thu Apr 24 17:59:01 2008
New Revision: 134644
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134644
Log:
PR libstdc++/35597
* toplev.c (process_options): Remo
--- Comment #1 from janis at gcc dot gnu dot org 2008-04-24 17:57 ---
Created an attachment (id=15526)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15526&action=view)
test case
This testcase fails with current trunk on powerpc64-linux:
elm3b187% /opt/gcc-nightly/trunk/bin/gcc -O
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Test 253.perlbmk from SPEC CPU2000 gets wrong answers with current trunk on
powerpc64-unknown-linux-gnu when compiled with "-m64 -Os" due to wrong code
generated for this loop:
while (--count)
*dst-- = *src--;
where dst and src are of type "struct sv **". I'll attach a simplified
testcase
--- Comment #8 from bartoldeman at users dot sourceforge dot net
2008-04-24 17:41 ---
I submitted a patch to MinGW to work around the problem (in crt1.o and crt2.o):
http://sourceforge.net/tracker/index.phpfunc=detail&aid=1951037&group_id=2435&atid=302435
--
bartoldeman at users dot
--- Comment #7 from bkoz at gcc dot gnu dot org 2008-04-24 17:27 ---
The goal for warnings should be to use an attribute on the specific class or
function in question, not on a per-file basis.
Unfortunately this does not work at the moment. So, the backwards_warning.h
file has been adj
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-04-24 17:09 ---
Closing as one month without updates, problem report with pre-release compiler.
If you can reproduce this with 4.3.0 or current 4_3-branch, please re-open.
--
bkoz at gcc dot gnu dot org changed:
What
--- Comment #8 from pcarlini at suse dot de 2008-04-24 17:05 ---
Fixed for 4.4.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from bkoz at gcc dot gnu dot org 2008-04-24 17:04 ---
Since there is no 4.3.1 release, only 4.3.0, can I assume you mean 4.3.0 for
the "Reported Against" field?
libtool issues should be fixed in libtool if possible, and not hacked around in
src/Makefile.am. Editing src/M
--- Comment #7 from paolo at gcc dot gnu dot org 2008-04-24 17:03 ---
Subject: Bug 35969
Author: paolo
Date: Thu Apr 24 17:03:13 2008
New Revision: 134642
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134642
Log:
2008-04-24 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #7 from bkoz at gcc dot gnu dot org 2008-04-24 16:58 ---
Second ping. David, I'm setting the target milestone to 4.3.1 for this. Can you
please check in your patch to gcc-4_3-branch?
--
bkoz at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-04-24 16:56 ---
Fixed on trunk and gcc-4_3-branch
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sje at gcc dot gnu dot org 2008-04-24 16:37 ---
Subject: Bug 36035
Author: sje
Date: Thu Apr 24 16:37:05 2008
New Revision: 134641
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134641
Log:
PR testsuite/36035
* gcc.dg/vect/vect-vfa-slp.c: Remo
--- Comment #16 from jakub at gcc dot gnu dot org 2008-04-24 16:32 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #18 from jakub at gcc dot gnu dot org 2008-04-24 16:32 ---
Subject: Bug 35758
Author: jakub
Date: Thu Apr 24 16:31:59 2008
New Revision: 134640
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134640
Log:
PR c++/35758
* c-common.c (handle_vector_size_at
--- Comment #17 from jakub at gcc dot gnu dot org 2008-04-24 16:30 ---
Subject: Bug 35758
Author: jakub
Date: Thu Apr 24 16:29:40 2008
New Revision: 134639
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134639
Log:
PR c++/35758
* c-common.c (handle_vector_size_at
-const.c (try_move_mult_to_index): If s == NULL, divide
the original op1, rather than delta by step.
* gcc.c-torture/execute/20080424-1.c: New test.
Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/20080424-1.c
Modified:
branches/gcc-4_3-branch/gcc/C
-const.c (try_move_mult_to_index): If s == NULL, divide
the original op1, rather than delta by step.
* gcc.c-torture/execute/20080424-1.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20080424-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
t
--- Comment #19 from hubicka at gcc dot gnu dot org 2008-04-24 16:05
---
I am going to make patch that will with preserve-stack attribute in addition to
inhibitting libcall also put REG_EQUIV notes on a copy instead of argument
register itself that should be sufficient to prevent reload
--- Comment #7 from anhvofrcaus at gmail dot com 2008-04-24 15:37 ---
Samuel and Ludovic,
You both are right that GNAT has a bug, and the original test code was a good
one. In fact, Pak2.Eq(Z1, Z2) would return True if GNAT worked correctly.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-04-24 15:19 ---
Subject: Bug 36034
Author: rguenth
Date: Thu Apr 24 15:18:19 2008
New Revision: 134631
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134631
Log:
2008-04-24 Ira Rosen <[EMAIL PROTECTED]>
Richard Gu
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-24 15:18 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from vincent at vinc17 dot org 2008-04-24 15:04 ---
Is there any reason why this hasn't been fixed yet? (The trunk still has the
error. And I'm asking this because there's only one word to change.)
--
vincent at vinc17 dot org changed:
What|Removed
--- Comment #5 from roger at eyesopen dot com 2008-04-24 15:01 ---
Well, I've now had time to read the Barriato, Hofri et al. 2002 paper, and the
bad news is that such an approximate median selection algorithm can't be used
to guarantee an O(N) worst-case std::nth_element implementation.
Downloading the code at
http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz,
uncompressing it and compiling it with mainline GCC on x86_64-linux at -O2 -g
gives:
Program received signal SIGSEGV, Segmentation fault.
0x0053f99d in gt_ggc_mx_dw_loc_descr_struct (x_p=0x2aaae3061f
--- Comment #1 from pluto at agmk dot net 2008-04-24 14:37 ---
Created an attachment (id=15525)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15525&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36036
attached tarball contains small boost-1.35 based source and preprocessed file.
$ make ii
/local/devel/toolchain43/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -c \
-pthread -Wall -O2 --save-temps \
-isystem ~/dvm/trunk/buildenv/linux/gcc-4.3/64/STLport-5.1.5/include/stlport \
-isystem ~/dvm/trunk/bui
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-24 14:22 ---
Subject: Bug 36034
Author: rguenth
Date: Thu Apr 24 14:21:45 2008
New Revision: 134628
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134628
Log:
2008-04-24 Ira Rosen <[EMAIL PROTECTED]>
Richard Gu
--- Comment #7 from nightstrike at gmail dot com 2008-04-24 14:21 ---
(In reply to comment #6)
> (In reply to comment #4)
> > I am set up for running the testsuite on x86_64-pc-mingw32, however it takes
> > several days to complete. Is there a reduced set of tests that I can run?
> I ha
--- Comment #5 from rguenther at suse dot de 2008-04-24 12:55 ---
Subject: Re: [4.3/4.4 Regression] wrong code
vectorizing unrolled inner loop (SLP)
On Thu, 24 Apr 2008, irar at il dot ibm dot com wrote:
> --- Comment #4 from irar at il dot ibm dot com 2008-04-24 12:24 ---
>
--- Comment #1 from hjl dot tools at gmail dot com 2008-04-24 12:45 ---
Revision 134540 adds a new line which fails on Linux/x86:
Index: gcc.dg/vect/vect-vfa-slp.c
===
--- gcc.dg/vect/vect-vfa-slp.c (revision 134500)
+++ g
On Linux/ia32 and Linux/x86-64, revision 134542 gives
FAIL: gcc.dg/vect/vect-vfa-slp.c scan-tree-dump-times vect "Vectorizing an
unaligned access" 2
Revision 134539 is OK. It may be related to revision 134540
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01607.html
--
Summary: [4.4
--- Comment #4 from irar at il dot ibm dot com 2008-04-24 12:24 ---
(In reply to comment #2)
>
> the final increment for ivtmp.15_36 is wrong -- it should be 48.
>
Right. We are not supposed to vectorize this at all, since SLP currently
doesn't support loads with gaps.
Here is a pos
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-24 11:44 ---
Testcase with 1d arrays (like produced by fortran):
double x[50] = { 10, 11, 12, 13, 14, 15, -1, -1, -1, -1,
21, 22, 23, 24, 25, 26, -1, -1, -1, -1,
32, 33, 34, 35, 36, 37, -1, -1,
--- Comment #13 from jakub at gcc dot gnu dot org 2008-04-24 11:29 ---
Created an attachment (id=15524)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15524&action=view)
gcc43-pr36008.patch
Fix I'm bootstrapping/regtesting ATM.
--
jakub at gcc dot gnu dot org changed:
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-24 11:27 ---
:
vect_px.14_32 = (vector double *) &x;
vect_px.9_31 = vect_px.14_32;
vect_ptmp.24_42 = (vector double *) &tmp;
vect_ptmp.19_43 = vect_ptmp.24_42;
:
# SMT.20_50 = PHI
# ivtmp.26_48 = PHI
# ivtmp.25_4
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-24 11:20 ---
This blocks adding the early unrolling pass (because then
gfortran.dg/array_1.f90
fails at -O3).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||irar at il dot ibm dot com
Known to fail|
The following testcase, reduced from gfortran.dg/array_1.f90, aborts if
vectorization is enabled. The test() function is miscompiled.
double x[5][10] = { { 10, 11, 12, 13, 14, 15, -1, -1, -1, -1 },
{ 21, 22, 23, 24, 25, 26, -1, -1, -1, -1 },
{ 32, 33, 34, 3
--- Comment #6 from ubizjak at gmail dot com 2008-04-24 10:24 ---
(In reply to comment #4)
> I am set up for running the testsuite on x86_64-pc-mingw32, however it takes
> several days to complete. Is there a reduced set of tests that I can run?
I have set up a crosscompiler to x86_64
--- Comment #12 from jakub at gcc dot gnu dot org 2008-04-24 09:59 ---
This is actually a tree optimization issue. In optimized dump without -DGOOD
we have:
bar (&g[0][0] + 288, &g[0][0]);
bar (&g[0][0] + 324, &g[1][0]);
bar (&g[0][0] + 360, &g[2][0]);
bar (&g[0][0] + 396, &g[3]
--- Comment #6 from ludovic at ludovic-brenta dot org 2008-04-24 09:55
---
(In reply to comment #4)
Anh Vo, you are perfectly right up to a point: Pak1.Eq returns True and Pak2.Eq
returns False, therefore comparing the two results yields False. Where you are
wrong is where you think P
--- Comment #11 from jakub at gcc dot gnu dot org 2008-04-24 09:33 ---
extern void abort (void);
int g[48][3][3];
void __attribute__ ((noinline))
bar (int x[3][3], int y[3][3])
{
static int i;
if (x != g[i + 8] || y != g[i++])
abort ();
}
static inline void __attribute__ ((alw
--- Comment #9 from irar at il dot ibm dot com 2008-04-24 09:40 ---
Fixed.
I opened pr36033 to get rid off the redundant loads.
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
---
With the fix of pr35982, interleaved data of different types (of the same size)
can be vectorized only as a collection of single-element strided accesses,
causing redundant misaligned loads.
Better solution for such cases will be to perform all the vector loads and
extraction operations as if the
--- Comment #19 from KnowlesPJ at Cardiff dot ac dot uk 2008-04-24 09:34
---
As the originator of this report, I just wanted to add a context comment in
case it is helpful. This construction (common declared both in the module and
in subroutines (contained or external)) is horrible, but
--- Comment #8 from irar at gcc dot gnu dot org 2008-04-24 09:22 ---
Subject: Bug 35982
Author: irar
Date: Thu Apr 24 09:21:55 2008
New Revision: 134624
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134624
Log:
PR tree-optimization/35982
* tree-vect-analyze.c (v
--- Comment #41 from pinskia at gcc dot gnu dot org 2008-04-24 08:42
---
>I'd rather you work around this in objective-c or objective c++.
Well guess what, it is more than an objective-c or objective C++ issue as PR
36032 had a good example for why, it can produce wrong code:
#include
--- Comment #40 from pinskia at gcc dot gnu dot org 2008-04-24 08:40
---
*** Bug 36032 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-24 08:40 ---
*** This bug has been marked as a duplicate of 25191 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from sam at gcc dot gnu dot org 2008-04-24 08:36 ---
Ahn Vo: Pak2.Eq is *the same* as Pak1.Eq, that's the whole point. Thus both
consider only T1 aspects of the objects.
What you say would be true if the code had been:
package Pak1 is
type T1 is tagged null reco
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-24 08:33 ---
These defines are supposed to make libstdc++ work with -fno-exceptions, you
are not really supposed to use -fno-exceptions with a program that uses
exceptions ...
of course a diagnostic would be nice here, instead o
--- Comment #18 from george at gcc dot gnu dot org 2008-04-24 08:29 ---
I've investigated the PR code further. The relevant parts of the code are
structured like so:
module mod
integer aa, bb
common /oof/ aa,bb
contains
subroutine sub
i = max(0,aa-1)
print *, i, aa, bb
end
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-24 08:27 ---
This is a bug in your glibc. Current glibc has
__dl_iterate_phdr (int (*callback) (struct dl_phdr_info *info,
size_t size, void *data), void *data)
{
struct link_map *l;
stru
--- Comment #3 from s__nakayama at infoseek dot jp 2008-04-24 08:05 ---
(In reply to comment #2)
> The program has undefined semantics. By 12.1/5, the default constructor of
> B initializes the pointer as if it was default initialized as if a user
> specified constructor had an empty i
--- Comment #7 from irar at il dot ibm dot com 2008-04-24 07:30 ---
(In reply to comment #6)
> Fixed on the 4.3 branch, but not on the trunk yet.
>
Yes, I'm going to do this during the next couple of hours.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35982
--- Comment #5 from jakub at gcc dot gnu dot org 2008-04-24 07:16 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jakub at gcc dot gnu dot org 2008-04-24 07:14 ---
Fixed on the 4.3 branch, but not on the trunk yet.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from jakub at gcc dot gnu dot org 2008-04-24 07:07 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jakub at gcc dot gnu dot org 2008-04-24 07:04 ---
Subject: Bug 36015
Author: jakub
Date: Thu Apr 24 07:03:38 2008
New Revision: 134622
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134622
Log:
PR target/36015
* config/i386/i386.c (init_cumula
--- Comment #5 from jakub at gcc dot gnu dot org 2008-04-24 07:00 ---
Subject: Bug 36015
Author: jakub
Date: Thu Apr 24 06:59:55 2008
New Revision: 134621
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134621
Log:
PR target/36015
* config/i386/i386.c (init_cumula
98 matches
Mail list logo
