Hi,
I found something strange I don't understand, but I
don't know if it's really a bug.
If I compile the following simple file x.cc:
class A
{
public:
A();
~A();
int a();
};
class B
{
public:
static int b();
};
int B::b()
{
A a;
return a.a();
}
I get the following assembler
Hello,
(I'm still a newbie in gcc)
I am interested in -fwhole-program analysis (flag_whole_program) and I know
that with -O3 -fwhole-program the cgraph_nodes is cleaned (in cgraphunit.c
probably by cgraph_varpool_remove_unreferenced_decls) so that only functions
callable from main are kept
For testing outside of the build directory, it would be convenient to
have $SUBJECT.
This could be used in conjunction with -dumpversion to create
on-the-fly include and library directory paths for C++ includes in a
sane manner, much like the following:
%g++ -print-install-prefix
Hi there
i'm in the process of coding a GCC backend for a certain RISC-like architecture.
Its register architecture consists of an integer register file (32 regs) and two
additional hard regs that should be programmer visible. Accesses to these hard
regs are also emitted related to certain RTL
Hi all,
I 'm making a shared object for ARM9 with -fprofile-arcs and
-ftest-coverage options.
GCC version 3.3.2
I 'm making the shared object with in 2 cases :
1) By doing an -fpic over the files to be included in the shared object.
2) By not doing an -fpic over the files to be included in the
hello all,
Sorry i am asking this kind of question.This might be weird to most of you but
i am new to GCC.
Can somebody tell me how to analyze the below instruction pattern
(insn 8 6 9 1 (parallel [
(set (reg/f:SI 32)
(symbol_ref:SI (t) var_decl 0x402270b0 t))
On Mon, Oct 16, 2006 at 05:20:44AM -0700, Mohamed Shafi wrote:
hello all,
Sorry i am asking this kind of question.This might be weird to most of you
but i am new to GCC.
Can somebody tell me how to analyze the below instruction pattern
(insn 8 6 9 1 (parallel [
(set
Hi,
Does anyone know if it is possible to view/access/print out the
control flow graphs produced by GCC, either at compilation time, or
after compilation has taken place?
Thanks for your time.
Rob
Call dump_flow_info() defined in cfg.c to output the pred and succ of
each block. You can use this output to construct the CFG.
Maybe the software graphviz can help you to visualize the CFG.
On 10/16/06, Rob Quill [EMAIL PROTECTED] wrote:
Hi,
Does anyone know if it is possible to
but in the meantime, I'm wondering if there is a much easier way to go
about this that I'm currently overlooking.
...instead I will rip off comp_base_dir from libgloss.exp.
-benjamin
On Mon, 16 Oct 2006, Jason Merrill wrote:
Mark Mitchell wrote:
Yes, I would be happy to explicitly ignore semantic attributes in typedefs
as well, with a warning (or even an error). However, I had not realized
that we ever did that; I'm surprised that the change that instituted this is
Jason Merrill wrote:
I don't think my patch changed the handling of class typedefs; certainly
my intent was only to change how we handle
class __attribute ((foo)) C
Previously we rejected it, now we apply the attributes to the class.
OK, that certainly makes sense. (That's one of the
My apologies for even bringing it up. It appears we'll most likely do
our own analysis.
Regards,
Greg
The enclosed unclassified technical data / software is being
transmitted under License Exception NLR and is to be used solely by
the individual / organization to whom it
Steven Bosscher [EMAIL PROTECTED] writes:
As far as I can tell, dwarf.h is not included anywhere in gcc/
or any of its subdirectories. Is there any reason not to remove
this file?
I think dwarf.h was orphaned when dwarfout.c was removed in 2003. I
think we should remove it.
Ian
[EMAIL PROTECTED] writes:
i'm in the process of coding a GCC backend for a certain RISC-like
architecture.
Its register architecture consists of an integer register file (32 regs) and
two
additional hard regs that should be programmer visible. Accesses to these hard
regs are also emitted
Joseph S. Myers wrote:
I was referring to the change in extend.texi
-the closing brace. It is ignored if the content of the structure, union
-or enumerated type is not defined in the specifier in which the
-attribute specifier list is used---that is, in usages such as
[EMAIL PROTECTED]
Carlos O'Donell [EMAIL PROTECTED] writes:
A relocated compiler should not look in $prefix.
I agree.
I can't approve your patches, though.
Ian
Hi all,
For Fortran 2003 standard conformance, the Fortran front-end has to
know at compile-time what integer mode corresponds to some C99 types,
like intmax_t, intN_t, int_leastN_t, int_fastN_t.
For intN_t and int_leastN_t, I can see how to get them by looking at
the width of the
Benjamin Kosnik wrote:
For testing outside of the build directory, it would be convenient to
have $SUBJECT.
This could be used in conjunction with -dumpversion to create
on-the-fly include and library directory paths for C++ includes in a
sane manner, much like the following:
Why do you
[EMAIL PROTECTED]:/e/gcc/test_pg ../gcc-4.1.1/config.guess
i686-pc-linux-gnu
[EMAIL PROTECTED]:/e/gcc/test_pg /e/gcc4.1.1_install/usr/local/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.1/configure
Thread model: posix
gcc version 4.1.1
[EMAIL
Ian Lance Taylor wrote:
Carlos O'Donell [EMAIL PROTECTED] writes:
A relocated compiler should not look in $prefix.
I agree.
I can't approve your patches, though.
This patch is OK, once we reach Stage 1.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Hi Ian
Can i disable filling/spilling for this register class?
Sure: make the registers fixed.
Or look at how the MIPS port handles HI and LO, with particular
reference to mips_secondary_reload_class.
Ian
what i'm trying to do is to code a backend for a standard DLX. Most things
work
[EMAIL PROTECTED] writes:
I'll have a look to mips_secondary_reload_class, however now i don't get
spilling/filling errors. I have a question: libgcc2.c is pretty stable, right?
I mean i shouldn't looking for something going wrong with it.
Right, libgcc2.c is quite stable.
In a normal build
FX Coudert [EMAIL PROTECTED] writes:
Hi all,
For Fortran 2003 standard conformance, the Fortran front-end has to
know at compile-time what integer mode corresponds to some C99 types,
like intmax_t, intN_t, int_leastN_t, int_fastN_t.
For intN_t and int_leastN_t, I can see how to get them
Mark Mitchell [EMAIL PROTECTED] writes:
We have a number of C++ PRs open around problems with code like this:
struct S {
void f();
virtual void g();
};
typedef __attribute__((...)) struct S T;
If the attribute makes any substantive change to S (e.g., changes its
A lot of thanks for the pointer...
Probably. Look for at pattern with movsi in the name.
In th document
http://gcc.gnu.org/onlinedocs/gccint/Insns.html#Insns
it is said that An integer that says which pattern in the machine description
matches
this insn, or −1 if the matching has not yet been
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-16 06:47 ---
PR 18553.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn|
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-16 08:36 ---
Subject: Bug 25519
Author: rguenth
Date: Mon Oct 16 08:36:03 2006
New Revision: 117774
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117774
Log:
2006-10-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-16 08:39 ---
Subject: Bug 25519
Author: rguenth
Date: Mon Oct 16 08:38:52 2006
New Revision: 117775
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117775
Log:
2006-10-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-16 08:40 ---
Subject: Bug 25519
Author: rguenth
Date: Mon Oct 16 08:40:32 2006
New Revision: 117776
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117776
Log:
2006-10-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-16 08:41 ---
SSE2 builtins are now documented, so not a regression anymore. Still a
paragraph mentioning the intrinsics could improve the situation.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-10-16 09:36
---
I'll take care of this. (Bootstrap running)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2006-10-16 09:58 ---
Subject: Bug 29091
Author: jakub
Date: Mon Oct 16 09:58:48 2006
New Revision: 117779
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117779
Log:
PR c/29091
* varasm.c (output_constant): If
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-16 10:16 ---
Differences mainline vs. 4.1.x are
@@ -8,14 +8,19 @@
test:
pushl %ebp
movl%esp, %ebp
- subl$40, %esp
- movss 12(%ebp), %xmm1
- movaps %xmm1, %xmm2
- unpcklps
--- Comment #11 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2006-10-16 10:52 ---
Subject: Re: ICE in operand_subword_force, at
emit-rtl.c:1353
franke dot daniel at gmail dot com [EMAIL PROTECTED] wrote on
Sat, 14 Oct 2006:
Don't know whether it makes any
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-10-16 11:18
---
Subject: Bug 27184
Author: rguenth
Date: Mon Oct 16 11:18:28 2006
New Revision: 117782
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117782
Log:
2006-10-16 Richard Guenther [EMAIL PROTECTED]
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-10-16 11:19
---
Fixed on the 4.1 branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-16 11:25 ---
Subject: Bug 29119
Author: rguenth
Date: Mon Oct 16 11:25:18 2006
New Revision: 117783
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117783
Log:
2006-10-16 Richard Guenther [EMAIL PROTECTED]
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-16 11:25
---
Fixed on the 4.1 branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-16 11:35 ---
Subject: Bug 28960
Author: rguenth
Date: Mon Oct 16 11:34:44 2006
New Revision: 117784
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117784
Log:
2006-10-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-16 11:35 ---
Subject: Bug 28825
Author: rguenth
Date: Mon Oct 16 11:34:44 2006
New Revision: 117784
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117784
Log:
2006-10-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-16 11:35 ---
Fixed on the 4.1 branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-16 12:07 ---
This is a bug in loop.c
bb 0:
pretmp.61 = q - 1;
outgo = 0;
L0:;
outgo.62 = outgo + 1;
outgo = MIN_EXPR pretmp.61, outgo.62;
j = tar (outgo * bcount);
if (j != -1) goto L0; else goto L4;
L4:;
--- Comment #3 from dir at lanl dot gov 2006-10-16 12:39 ---
Created an attachment (id=12442)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12442action=view)
config.log file from gfortran/ibin/powerpc-apple-darwin8.7.0/libjava
--
--- Comment #4 from dir at lanl dot gov 2006-10-16 12:42 ---
Created an attachment (id=12443)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12443action=view)
config.log file from /Users/dir/gfortran/ibin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29460
--- Comment #5 from pluto at agmk dot net 2006-10-16 12:47 ---
this is a dup of PR25026.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29460
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-16 13:07 ---
Created an attachment (id=12444)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12444action=view)
Full patch and testcase for this PR
The pigeon seems to have got lost on the way to submit this patch to GNU
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-16 13:34 ---
Note that there is a change in meaning:
BOZ-everywhere extension:
a = real(z'F')
is the same as real(int(z'F')) = 15.0
(This is what gfortran does and Intel does by default)
Fortran 2003:
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-16 13:37 ---
Happens during inlining, so I guess one of the strip-useless-type-conversion
patches caused this.
But initialize_inlined_parameters shouldn't call into the frontend again here:
/* Find the initializer. */
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-16 13:46 ---
I'm testing complete removal of the langhook.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-16 14:05 ---
Created an attachment (id=12445)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12445action=view)
Simple fix, testcase and ChangeLog entries.
I'll submit this tonight.
Paul
--
pault at gcc dot gnu dot org
--- Comment #12 from bkoz at gcc dot gnu dot org 2006-10-16 14:06 ---
Paolo you are correct, non-build testing is at issue. I'm trying to fix...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29095
--- Comment #15 from amacleod at redhat dot com 2006-10-16 14:36 ---
Or we can just backport the fix from mainline to 4.1 which changes the
immediate use iterators and eliminates this kind of problem. Bug 26854 and a
couple of small follow up patches on 4/28 and 5/2. They've been in
--- Comment #2 from mircea_lutic at yahoo dot com 2006-10-16 14:47 ---
it was indeed due to using to sco make.
Sorry for rushing.
Thank you,
Mircea.
--
mircea_lutic at yahoo dot com changed:
What|Removed |Added
Dependency creation fails for libcpp on OpenUnix 8.5.
Surprisingly enough the previous phases of the gcc bootstrap work well enough
and also seemed to do some dependency work.
The cc on Caldera OpenUnix 8.5 can generate dependencies but it's not used for
this purpose. Here is the man :
-H
--- Comment #2 from mueller at gcc dot gnu dot org 2006-10-16 15:22 ---
ehm, this is the same with any warning/error message? why would this case be
special?
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from patchapp at dberlin dot org 2006-10-16 15:25 ---
Subject: Bug number PR29392
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-10/msg00804.html
--
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mueller at gcc dot gnu dot
|dot org
--- Comment #3 from patchapp at dberlin dot org 2006-10-16 15:30 ---
Subject: Bug number PR29451
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-10/msg00805.html
--
--- Comment #4 from mueller at gcc dot gnu dot org 2006-10-16 15:34 ---
use -Woverloaded-virtual
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Severity|trivial |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24525
--- Comment #14 from mueller at gcc dot gnu dot org 2006-10-16 15:37
---
*** Bug 26298 has been marked as a duplicate of this bug. ***
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mueller at gcc dot gnu dot org 2006-10-16 15:37 ---
*** This bug has been marked as a duplicate of 26167 ***
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tbm at cyrius dot com 2006-10-16 15:38 ---
(In reply to comment #2)
ehm, this is the same with any warning/error message? why would this case be
special?
I never noticed before, but it would still be nice to get this changed.
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-16 15:40 ---
*** This bug has been marked as a duplicate of 25026 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-16 15:40 ---
*** Bug 29460 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-10-16 15:46 ---
The configure check in libcpp is based on automake's code. Do you know if they
support SCO's cc dependencies yet?
Note you should also read README.SCO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28825
The following little testcase
class Foo {
public:
void bar() const;
static const double TOL = 1e-14;
};
void Foo::bar() const
{
double tol = -TOL;
}
int main(){}
produces the error message
[EMAIL PROTECTED]:~/dune_projects/uggridtest$ g++ test.cc
/tmp/cco39MFe.o: In function
--- Comment #5 from dir at lanl dot gov 2006-10-16 15:53 ---
powerpc-apple-darwin8.7.0 does not come with 64 bit libraries for x-windows -
is there some way to turn of the 64 bit branch of the build ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-16 15:54 ---
This is not a bug, you still need to have a memory location for Foo::TOL for
this to be valid code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
static inline __attribute__((always_inline))
void bar (void)
{
addr:;
static const unsigned long b __attribute__((__used__))
__attribute__((section(btable)))
= (unsigned long) addr;
asm ( : : m (b));
}
void foo (void)
{
bar ();
}
generates at -O and higher a reference to undefined
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-16 16:06 ---
Doesn't work out. It looks like we depend on its side-effects in some
testcases:
FAIL: gcc.dg/assign-warn-3.c (test for warnings, line 9)
FAIL: gcc.dg/assign-warn-3.c (test for warnings, line 13)
FAIL:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-16 16:06 ---
Confirmed.
generates at -O and higher a reference to undefined local label
No it generates an undefined local label at all levels of optimization in 4.0.x
and above (there was a bug about not supporting used on
Hi,
this testcase fails to produce a return value missing diagnostic:
=== Cut ===
class test
{
bool fii(test* other)
{
if (!other) return false;
}
};
=== Cut ===
Interestingly, it works when declared outside the class itself, which makes me
suspect that this is caused
--- Comment #6 from pault at gcc dot gnu dot org 2006-10-16 16:51 ---
Created an attachment (id=12446)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12446action=view)
Fix for this and PR29394
As well as fixing these PRs, this patch provides an option -finitialize-null,
which does
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-16 16:51 ---
This is going to be difficult to fix. In fact, it will require a
complete rewrite on how BOZ are handled.
Fortran 2003:
a = real(z'F')
= 2.1019477E-44
Are you sure this is the only correct value? The
--- Comment #6 from smithj at rpath dot com 2006-10-16 16:53 ---
if are are using 4.2: http://people.rpath.com/~smithj/gcc-java-nomulti.patch
if 4.1.1: http://tinyurl.com/y37csd
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-16 16:58 ---
Fixed on trunk. Testing for 4.1.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-16 17:01 ---
Actually all inlined functions for C++ are missing the diagnostic:
inline int fii(int *other)
{
if(!other)return 0;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-10-16 17:02
---
Subject: Bug 28211
Author: mmitchel
Date: Mon Oct 16 17:02:07 2006
New Revision: 117787
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117787
Log:
PR c++/28211
* parser.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-16 17:02 ---
(In reply to comment #0)
Interestingly, it works when declared outside the class itself, which makes me
suspect that this is caused by some C++ parser oddity.
Are you sure because I could reproduce the missing
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-16 17:04 ---
Actually for C++, any inline disables the warning:
inline int fii(int *other)
{
if(!other)return 0;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-16 17:04 ---
*** This bug has been marked as a duplicate of 21678 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-16 17:04 ---
*** Bug 29485 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-16 17:12 ---
(In reply to comment #2)
Fortran 2003:
a = real(z'F')
= 2.1019477E-44
Are you sure this is the only correct value? The F2003 says nothing
about the other 28 bits. It also says
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-10-16 17:17
---
Fixed in 4.2.0. Will not be fixed in previous releases.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from bkoz at gcc dot gnu dot org 2006-10-16 17:22 ---
Subject: Bug 29095
Author: bkoz
Date: Mon Oct 16 17:22:38 2006
New Revision: 117788
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117788
Log:
2006-10-16 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-16 17:23 ---
Forgot to add myself to cc listing.
Tobias, the only place the handling on a BOZ (other the data-stmt handling)
is discussed in the description REAL() intrinsic procedure. It contains
the dreaded processor-dependent
While moving the definition of a friend template out of the class definition I
found this error.
Please compile the attached file and have a look at the ReleaseAll function.
The file is part of Loki.
--
Summary: call of friend template is ambiguous
Product: gcc
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #1 from syntheticpp at gmx dot net 2006-10-16 17:40 ---
Created an attachment (id=12447)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12447action=view)
demo: g++ bug.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29486
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-10-16 18:36
---
The problem here is that tsubst, for a TEMPLATE_TEMPLATE_PARM, reduces the
parameter level for the new TEMPLATE_TEMPLATE_PARM (via a call to
reduce_template_parm_level), but does not reset
--- Comment #5 from kargl at gcc dot gnu dot org 2006-10-16 18:37 ---
Subject: Bug 29403
Author: kargl
Date: Mon Oct 16 18:37:39 2006
New Revision: 117789
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117789
Log:
2006-10-15 Steven G. Kargl [EMAIL PROTECTED]
PR
--- Comment #2 from jakub at gcc dot gnu dot org 2006-10-16 18:42 ---
Actually, even C generates one static var for all the inlined functions (in C
within one object), so I'd say we just should mark functions containing
local static variables with label in their initializers as
--- Comment #7 from dir at lanl dot gov 2006-10-16 18:53 ---
I tried installing the patch (the two patch files in comment #6 were identical)
into 4.2 , but it failed -
[dranta:~/gfortran/gcc/libjava] dir% patch -p2 gcc-java-nomulti.patch
patching file configure
Hunk #1 succeeded at
--- Comment #8 from smithj at rpath dot com 2006-10-16 18:55 ---
sorry about that. http://people.rpath.com/~smithj/gcc42-java-nomulti.patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
--- Comment #9 from tromey at gcc dot gnu dot org 2006-10-16 19:00 ---
You may want to try --disable-multilib.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
--- Comment #6 from kargl at gcc dot gnu dot org 2006-10-16 19:18 ---
Fixed on 4.1, now.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 158 matches
Mail list logo
