--- Comment #2 from tbm at cyrius dot com 2007-10-30 07:59 ---
And on ARM too. pinskia: is PR31128 the same as this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31032
--- Comment #18 from patchapp at dberlin dot org 2007-10-30 07:25 ---
Subject: Bug number PR tree-optimization/32500
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/2007-10/msg01790.html
--
http://gcc
--- Comment #7 from patchapp at dberlin dot org 2007-10-30 07:20 ---
Subject: Bug number PR c++/8171
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/2007-10/msg01789.html
--
http://gcc.gnu.org/bugzill
--- Comment #2 from jakub at gcc dot gnu dot org 2007-10-30 07:12 ---
Looks good to me. Something like __gnu_cxx::scoped_lock is unnecessary, the
current use of #pragma omp critical to be replaced by omp_*_lock with this
patch
is always inside of some #pragma omp parallel and there is n
--- Comment #6 from victork at gcc dot gnu dot org 2007-10-30 06:51 ---
I'm not sure, but it looks like PR33319 is duplicate of this one.
(pr27549.C when compiled with -ftree-vectorize).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31081
--- Comment #11 from dorit at il dot ibm dot com 2007-10-30 05:48 ---
(In reply to comment #6)
Richard, is this related to the issue you reported in
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01127.html
(looks like the same error)?
Any idea why the fix you committed doesn't cover thi
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-10-30 05:47 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01456.html
This stuff looks pretty good to me: Jakub?
The only comment I would have is that this looks strikingly like the
scoped_lock idiom on a omp_lo
--- Comment #17 from dorit at gcc dot gnu dot org 2007-10-30 05:25 ---
Subject: Bug 32893
Author: dorit
Date: Tue Oct 30 05:25:10 2007
New Revision: 129764
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129764
Log:
PR tree-optimization/32893
* tree-vectorize.c (v
--- Comment #2 from dj at redhat dot com 2007-10-30 04:30 ---
Subject: Re: iv folding fails with pointer iterations
Yup. I did a source update, rebuilt the natives, and tried to build...
m32c-elf-gcc -B/greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/newlib/ -isystem
/greed/dj/m32c/new
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-10-30 04:19
---
I can reproduce this. Don't see the problem yet. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33863
--- Comment #13 from patchapp at dberlin dot org 2007-10-30 03:47 ---
Subject: Bug number PR33897
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/2007-10/msg01694.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #6 from patchapp at dberlin dot org 2007-10-30 03:46 ---
Subject: Bug number PR c++/5645
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/2007-10/msg01639.html
--
http://gcc.gnu.org/bugzill
--- Comment #5 from patchapp at dberlin dot org 2007-10-30 03:45 ---
Subject: Bug number PR33862
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/2007-10/msg01617.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #6 from patchapp at dberlin dot org 2007-10-30 03:45 ---
Subject: Bug number PR 33917
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/2007-10/msg01622.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #4 from patchapp at dberlin dot org 2007-10-30 03:45 ---
Subject: Bug number PR33862
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/2007-10/msg01617.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #14 from geoffk at gcc dot gnu dot org 2007-10-30 03:44 ---
I don't fully understand the linker error message. It seems to me that if
there's a reference to the typeinfo name then that just means the linker
shouldn't be discarding it.
The original problem was encountered on
--- Comment #1 from rakdver at gcc dot gnu dot org 2007-10-30 03:32 ---
I cannot reproduce it (using ./configure --enable-languages=c --target=m32c-elf
on amd64-linux). Does it still fail for you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33915
--- Comment #8 from mark at codesourcery dot com 2007-10-30 02:50 ---
Subject: Re: INIT_PRIORITY is broken
dave at hiauly1 dot hia dot nrc dot ca wrote:
>> I don't think this will be too hard to implement. In
>> cgraph_build_cdtor_fns, we need to partition/sort the static_[cd]tors by
--- Comment #7 from zadeck at naturalbridge dot com 2007-10-30 00:38
---
Subject: Re: -mstrict-align can an extra for struct agrument
passing
zadeck at naturalbridge dot com wrote:
> --- Comment #6 from zadeck at naturalbridge dot com 2007-10-29 14:09
> ---
> These stores t
testsuite gcc.c-torture/execute/multi-ix.c calls __builtin_bzero;
At -O0, this gets expanded to a libcall to non-ISO function bzero
mingw32 does not have a library function bzero.. Hence:
spawn /develop/svn/trunk/build/gcc/xgcc -B/develop/svn/trunk/build/gcc/
/develop/svn/trunk/src/gcc/testsuite
--- Comment #18 from pinskia at gmail dot com 2007-10-30 00:20 ---
Subject: Re: Gcc can't be compiled with -mregparm=3
On 30 Oct 2007 00:14:21 -, rask at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #17 from rask at gcc dot gnu dot org 2007-10-30 00:14
On 30 Oct 2007 00:14:21 -, rask at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #17 from rask at gcc dot gnu dot org 2007-10-30 00:14 ---
> Created an attachment (id=14438)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14438&action=view)
> patch v3, varargs
--- Comment #17 from rask at gcc dot gnu dot org 2007-10-30 00:14 ---
Created an attachment (id=14438)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14438&action=view)
patch v3, varargs free
In reply to comment #16:
> You can cast them at the time of calling and store them as void
--- Comment #4 from janis at gcc dot gnu dot org 2007-10-29 22:34 ---
Subject: Bug 24841
Author: janis
Date: Mon Oct 29 22:33:53 2007
New Revision: 129744
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129744
Log:
PR testsuite/24841
* doc/sourcebuild.texi (Test D
--- Comment #3 from jakub at gcc dot gnu dot org 2007-10-29 22:28 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
S
mplify.c (c_gimplify_expr): Optimize INIT_EXPR or
MODIFY_EXPR with non-addressable COMPOUND_LITERAL_EXPR as source.
* gcc.c-torture/execute/20071029-1.c: New test.
* gcc.dg/tree-ssa/pr33723.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20071029-1.c
t
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-10-29 22:12
---
This is fixed on the mainline by the middle-end type-system and the first
forwprop pass. cxx_types_compatible_p is no longer involved for pointer types.
--
rguenth at gcc dot gnu dot org changed:
W
--- Comment #4 from rsandifo at gcc dot gnu dot org 2007-10-29 22:01
---
Fixed on mainline.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #3 from rsandifo at gcc dot gnu dot org 2007-10-29 22:01
---
Subject: Bug 33614
Author: rsandifo
Date: Mon Oct 29 22:01:24 2007
New Revision: 129739
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129739
Log:
gcc/
PR tree-optimization/33614
* gimplify
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-10-29 21:47
---
Subject: Bug 33870
Author: rguenth
Date: Mon Oct 29 21:47:05 2007
New Revision: 129738
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129738
Log:
2007-10-29 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-10-29 21:44
---
Assign to Diego.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #4 from jakub at gcc dot gnu dot org 2007-10-29 21:44 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-10-29 21:44
---
Reopen.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLV
--- Comment #2 from jakub at gcc dot gnu dot org 2007-10-29 21:43 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #3 from jakub at gcc dot gnu dot org 2007-10-29 21:43 ---
Subject: Bug 33757
Author: jakub
Date: Mon Oct 29 21:42:51 2007
New Revision: 129737
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129737
Log:
PR tree-optimization/33757
* gcc.dg/tree-ssa/ssa-
--- Comment #1 from jakub at gcc dot gnu dot org 2007-10-29 21:41 ---
Subject: Bug 33841
Author: jakub
Date: Mon Oct 29 21:41:29 2007
New Revision: 129736
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129736
Log:
PR c++/33841
* class.c (check_bitfield_decl): Don
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-10-29 21:34
---
> Another testcase, from sed, unreduced. Fails with -O2 -fprofile-generate.
Do you want one in Ada too? :-)
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-10-29 21:08 ---
Created an attachment (id=14437)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14437&action=view)
unreduced testcase
Another testcase, from sed, unreduced. Fails with -O2 -fprofile-generate.
--
http://gc
--- Comment #6 from andreast at gcc dot gnu dot org 2007-10-29 20:46
---
Don't know if one can reproduce on x86_64-unknown-linux-gnu.
The tests are failing since around 123662.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31507
--- Comment #2 from BenGardiner at nanometrics dot ca 2007-10-29 20:43
---
Created an attachment (id=14436)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14436&action=view)
a patch for libjava/gnu/java/net/natPlainDatagramSocketImplPosix.cc to use the
given NetworkInterface* in th
--- Comment #1 from manu at gcc dot gnu dot org 2007-10-29 20:35 ---
Wmain is using pedwarn when it should use warning (OPT_Wmain,""). It is also an
error by default (unless -fpermissive) in C++ while it is not even enabled in
C.
--
manu at gcc dot gnu dot org changed:
Wh
--- Comment #5 from burnus at gcc dot gnu dot org 2007-10-29 20:04 ---
This gets difficult.
Using
procedure(p4) :: p6
procedure(sub) :: p4
is invalid per
"C1212 (R1215) [...] If name is declared by a procedure-declaration-stmt it
shall be previously declared."
("name" = interface-na
Compiling the following program gives the error:
procedure(sub) :: x
1
Error: Duplicate PROCEDURE attribute specified at (1)
I think the program is valid and it is also accepted by NAG f95.
module m
implicit none
interface bar
procedure x
end interface bar
proc
--- Comment #6 from manu at gcc dot gnu dot org 2007-10-29 19:48 ---
The infinite loop is still present in GCC 4.3 with
#define A(b) #b
A(\ \\)
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from kargl at gcc dot gnu dot org 2007-10-29 19:41 ---
The problem is that configure.ac is missing a check for [t]gamma[fl].
AC_CHECK_LIB([m],[tgammaf],[AC_DEFINE([HAVE_TGAMMAF],[1],[libm includes
tgammaf])])
AC_CHECK_LIB([m],[tgamma],[AC_DEFINE([HAVE_TGAMMA],[1],[libm in
--- Comment #2 from burnus at gcc dot gnu dot org 2007-10-29 19:32 ---
The example is incomplete as the module m_common_array_str is not in the
example file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33941
--- Comment #1 from burnus at gcc dot gnu dot org 2007-10-29 19:29 ---
gfortran 4.3.0 supports now the GAMMA intrinsic function. Thus
PROGRAM pgamma
y = gamma(x)
END PROGRAM pgamma
calls the intrinsic gamma function (the so-called true-gamma function
"tgamma"), which is for some reas
--
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
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #13 from gcc at magfr dot user dot lysator dot liu dot se
2007-10-29 18:52 ---
Should the typeinfo for an anonymous namespace class be local if it inherits
from a class that is outside the anonymous namespace?
If that is the case, what should typeid(reference to base of anon
ux-gnu --enable-languages=c
Thread model: posix
gcc version 4.3.0 20071029 (experimental) (GCC)
--
Summary: streaming 64-bit integer stores
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
--- Comment #6 from pcarlini at suse dot de 2007-10-29 18:26 ---
(In reply to comment #5)
> In this test case, "int" and "unsigned" are different class(thus causes
> ambiguity in my view), while in the original test case, only ONE class
> "std::string" involved---even with different type
Compiled with -std=c++0x, version g++ (GCC) 4.3.0 20070921 (experimental), the
following program causes an ICE.
{{{
template
struct foo {};
template
struct bar {};
template
struct baz;
template class T, typename... U>
struct baz< T >
{};
template class T, typename U, typename... V>
struct baz<
When I compile the program listed below using the FreeBSD version of gfortran I
get the message:
/var/tmp//ccTgf1if.o(.text+0x1f): In function `MAIN__':
: undefined reference to `tgammaf'
collect2: ld returned 1 exit status
I noticed this problem in the October 26 snapshot of gfortran. I don't re
--- Comment #5 from gzljg at hotmail dot com 2007-10-29 17:56 ---
(In reply to comment #4)
> In practice, consider this:
>
> const
> class {
> public:
> template operator T() const
> {
> return int();
> }
>
> } MYNULLOBJECT = {};
>
> void f(int);
> void f(unsigned);
>
> in
--- Comment #4 from stsp at users dot sourceforge dot net 2007-10-29 17:49
---
> Also, even if the asm code is put into
> another section, why it cannot be called
> from there?
This section does not seem to have "a",
so that's why...
But its still nasty that the current
section depends
--- Comment #4 from pcarlini at suse dot de 2007-10-29 17:39 ---
In practice, consider this:
const
class {
public:
template operator T() const
{
return int();
}
} MYNULLOBJECT = {};
void f(int);
void f(unsigned);
int main()
{
f(MYNULLOBJECT);
}
No conforming compiler ac
--- Comment #3 from pcarlini at suse dot de 2007-10-29 17:33 ---
(In reply to comment #2)
...What I was
> confused is why the compiler is ambiguious about the T()'s constructor, _even_
> I hard coded to use "std::string()" in the example?
That doesn't matter because T is deduced basing
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-10-29 17:12
---
The typeinfo for anonymous namespace classes should be local.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--- Comment #1 from tow21 at cam dot ac dot uk 2007-10-29 17:04 ---
Created an attachment (id=14435)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14435&action=view)
file causes failure on compilation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33941
The attached file is compiled fine by gfortran.
However, when the resulting module is USEd in another subprogram, then the
following message results:
Fatal Error: Reading module m_common_attrs at line 44 column 39: Bad name
This is with gfortran 4.3.0, 200710005, rev 127783 under Cygwin.
--
--- Comment #2 from gzljg at hotmail dot com 2007-10-29 17:00 ---
(In reply to comment #1)
> A couple of quick comments. First, there is nothing special about std::string,
> the same happens with std::vector, for example, because really the issue
> is about multiple constructors. Second,
--
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 #1 from pcarlini at suse dot de 2007-10-29 16:28 ---
A couple of quick comments. First, there is nothing special about std::string,
the same happens with std::vector, for example, because really the issue
is about multiple constructors. Second, I checked that at least 2 other
--- Comment #5 from jakub at gcc dot gnu dot org 2007-10-29 15:55 ---
This is because integer overflow.
try_crossjump_to_edge is called many times and in each case
redirect_to->frequency += src1->frequency;
Each src1->frequency is 0 .. BB_FREQ_MAX, but 34 * approx. (BB_FREQ_MAX / 2)
is s
#include
const
class {
public:
template operator T() const
{
return T(); // even I change this to "return std::string();", same error.
}
} MYNULLOBJECT = {};
int main()
{
const unsigned int myInt(MYNULLOBJECT);// OK, myInt is 0
const std::string myString(MYNULLOBJECT); //
This is g++ with -std=c++0x flag. The compiler version is g++ (GCC) 4.3.0
20070921 (experimental).
I believe the following code should compile. It does not:
{{{
template
struct refs_only;
template
struct refs_only
{};
template
refs_only foo( T && t)
{
return refs_only();
}
template
struct
--- Comment #5 from rask at gcc dot gnu dot org 2007-10-29 15:11 ---
Is it possible to reproduce this on x86_64-unknown-linux-gnu somehow? I've
tried to no avail with -Os and -mregparm=0 -Os on both testcases. What is a
known bad revision?
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #10 from jv244 at cam dot ac dot uk 2007-10-29 14:59 ---
Since this is the oldest F95-only bug in gfortran, I had a look if it still
exists. I'm not quite sure it does (at in the same form).
This
INTEGER, PARAMETER :: N=10
INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/)
When I compile bitswash-0.0.5 http://sourceforge.net/projects/bitswash I get
numerous errors of this nature:
`.L53295' referenced in section `.rodata' of .libs/session_impl.o: defined in
discarded section
`.gnu.linkonce.t._ZN5boost7variantINS_6detail7variant13over_sequenceINS_3mpl6v_itemINS_5blank
--- Comment #14 from burnus at gcc dot gnu dot org 2007-10-29 14:15 ---
Fixed on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-10-29 14:15 ---
FIXED on the trunk (GCC 4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2007-10-29 14:14 ---
FIXED on the trunk (GCC 4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from burnus at gcc dot gnu dot org 2007-10-29 14:14 ---
Subject: Bug 33686
Author: burnus
Date: Mon Oct 29 14:13:44 2007
New Revision: 129720
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129720
Log:
2007-10-29 Paul Thomas <[EMAIL PROTECTED]>
PR fortr
--- Comment #5 from burnus at gcc dot gnu dot org 2007-10-29 14:14 ---
Subject: Bug 31217
Author: burnus
Date: Mon Oct 29 14:13:44 2007
New Revision: 129720
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129720
Log:
2007-10-29 Paul Thomas <[EMAIL PROTECTED]>
PR fortra
--- Comment #2 from burnus at gcc dot gnu dot org 2007-10-29 14:14 ---
Subject: Bug 33811
Author: burnus
Date: Mon Oct 29 14:13:44 2007
New Revision: 129720
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129720
Log:
2007-10-29 Paul Thomas <[EMAIL PROTECTED]>
PR fortra
--- Comment #6 from zadeck at naturalbridge dot com 2007-10-29 14:09
---
These stores to the stack are not really anything that dse can handle. It is
good at removing stores addressed off the frame pointer that go dead when the
function returns, but it must be more conservative with st
.quad _ZTSN12_GLOBAL__N_13fooE
.ident "GCC: (GNU) 4.3.0 20071029 (experimental)"
.section.note.GNU-stack,"",@progbits
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--
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 #18 from ubizjak at gmail dot com 2007-10-29 13:22 ---
Perhaps this analysis will help someone...:
We start with following loop:
void bar() ()
{
unsigned int ivtmp.19;
int pretmp.14;
struct Foo * pretmp.13;
struct Foo x[4];
int D.1669;
struct Foo * D.1668;
:
:
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-10-29 13:22
---
The testcase that went in with this change still passes after reverting the
change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--
ssharma at thegoldensource dot com changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33937
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-10-29 13:17 ---
Reverting
r125721 | geoffk | 2007-06-14 22:56:25 +0200 (Thu, 14 Jun 2007) | 4 lines
PR 31093
* decl2.c (determine_visibility): Remove duplicate code for
handling type info.
fixes this.
--
--- Comment #13 from rguenther at suse dot de 2007-10-29 13:12 ---
Subject: Re: [4.3 Regression] inlining
miscompilation
On Mon, 29 Oct 2007, razya at il dot ibm dot com wrote:
> > --- Comment #11 from rguenther at suse dot de 2007-10-29 12:14
> ---
> > Subject: Re: [4.3 R
--- Comment #12 from razya at il dot ibm dot com 2007-10-29 13:00 ---
Subject: Re: [4.3 Regression] inlining miscompilation
"rguenther at suse dot de" <[EMAIL PROTECTED]> wrote on 29/10/2007
14:14:45:
>
>
> --- Comment #11 from rguenther at suse dot de 2007-10-29 12:14
--
My application crashes when shutting down on RH4. We did a lot of
investigation and found that the crash occurs when the system tries to destruct
static variables.
Our OS is Red Hat Enterprise Linux AS release 4 (Nahant Update 5). I am using
the following compiler - gcc version 3.4.6 20060404
--- Comment #1 from jakub at gcc dot gnu dot org 2007-10-29 12:42 ---
enum { M = && N };
alone is enough to trigger this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33836
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-10-29 12:36 ---
125653 works, 125829 is broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--- Comment #11 from rguenther at suse dot de 2007-10-29 12:14 ---
Subject: Re: [4.3 Regression] inlining
miscompilation
On Mon, 29 Oct 2007, razya at il dot ibm dot com wrote:
> --- Comment #10 from razya at il dot ibm dot com 2007-10-29 12:08 ---
> (In reply to comment #6)
--- Comment #10 from dominiq at lps dot ens dot fr 2007-10-29 12:09 ---
Without the part of the patch in comment #8 the warning disappears. The
comment #2 may sound as ld64 on Darwin8 overzealous, but it just detects that
"entering into a new file" is properly detected
(at least the fir
--- Comment #10 from razya at il dot ibm dot com 2007-10-29 12:08 ---
(In reply to comment #6)
> Hmm, I have a question about IPA CP, should it call cfgcleanup also? It does
> not fix the problem here but it seems like a good idea. I can test a patch
> which adds the cfgcleanup if it i
--- Comment #1 from pcarlini at suse dot de 2007-10-29 11:04 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot g
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #10 from tbm at cyrius dot com 2007-10-29 10:29 ---
(In reply to comment #8)
> I don't have access to ia64. Could you please attach vectorizer's dump
> (-fdump-tree-vect-all)?
Done
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #9 from tbm at cyrius dot com 2007-10-29 10:28 ---
Created an attachment (id=14434)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14434&action=view)
vectorizer's dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ABI, wrong-code
Summary|typeinfo name referenced in |[4.3
--- Comment #8 from irar at il dot ibm dot com 2007-10-29 10:22 ---
I don't have access to ia64. Could you please attach vectorizer's dump
(-fdump-tree-vect-all)?
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-10-29 10:05 ---
Janis, can you hunt this? Or HJ?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from bonzini at gnu dot org 2007-10-29 10:05 ---
> This issue with -4 offset is annoying because code size of offsetted load insn
> is huge:
>
>f: c7 40 fc 01 00 00 00movl $0x1,-0x4(%eax)
-0x4(%eax) is 2 bytes more than (%eax), where IIRC it would be "a3 01 0
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-10-29 09:51 ---
The difference is that gcc 4.3 compared to for example 4.2 emits
V typeinfo for s
0020 r typeinfo for (anonymous namespace)::t
V typeinfo name for s
r t
1 - 100 of 102 matches
Mail list logo
