Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
If gcc supports plugins, then all we've eliminated is the need to
plug that code into passes.c. But that is the easiest part of the
job. Adding plugins is not going to require us to support a stable
tree
I have a different fear: that gcc will become increasing irrelevant,
as more and more new programmers learn to work on alternative free
compilers instead. That is neutral with regard to freedom, but it
will tend to lose the many years of experience which have been put
into gcc. In my view,
Andrew Haley [EMAIL PROTECTED] writes:
Most new gcc back-ends are private, so I don't buy that part of the
argument. And in any case nobody is talking about plug-ins for gcc
backends. We're talking about plugins at the tree/GIMPLE level.
Yeah, I know. I'm thinking about proprietary
Thanks to Jim Wilson's help, I eliminated a non-standard file,
/usr/bin/true, which was interfering with gcc scripts.
Now everything is fine with gcc building.
-Tom
Tom Browder
Niceville, Florida
USA
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
Most new gcc back-ends are private, so I don't buy that part of the
argument. And in any case nobody is talking about plug-ins for gcc
backends. We're talking about plugins at the tree/GIMPLE level.
Yeah,
Ian Lance Taylor wrote:
But as you know, most gcc ports are never contributed anyhow.
Naively, I didn't know that!
I thought most ports were contributed, but some rejected because of code
quality, lack of reviewers, etc
But does these ports are published elsewhere, in the spirit of GPL,
On Fri, Nov 16, 2007 at 12:02:44PM -0500, Richard Kenner wrote:
As was said before, the difficultly in people working with GCC is
primarily lack of adequate documentation. Creating a plugin interface
is certainly much more fun than writing documentation, but doesn't help
this issue nearly as
Hello,
I have recently reported GCC bug #34030
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34030)
As it might have been fixed in 4.2.3, and as my concern is primarily for
the 4.1.1 branch (we don't want to upgrade now), I am ready to fix it in
my own sources.
However, I am not familiar
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
David Edelsohn
Sent: 16 November 2007 16:58
To: Andrew Haley
Cc: Ian Lance Taylor; Richard Kenner; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; gcc@gcc.gnu.org
Subject: Re: Progress on GCC
On Fri, Nov 16, 2007 at 12:05:06AM +0100, Michael_fogel wrote:
tcp_in.c:1133: internal compiler error: in gen_reg_rtx, at emit-rtl.c:771
Please submit a full bug report,
This means you're calling gen_reg_rtx() when you're not allowed to.
Olders version of GCC had a life1 pass, after which
Andrew Haley wrote:
Well, that's where we differ. I don't at all understand how adding
plugins won't make it very much easier. It seems obvious to me that
if there is a reasonably well-defined plugin architecture it will be
vastly easier to export data from gcc's front-ends to a proprietary
On Fri, Nov 16, 2007 at 06:13:32PM +0100, Bernd Schmidt wrote:
I must admit I don't understand the upside. I've always thought of
plugins as something proprietary programs need because their source
isn't open.
On the contrary, many successful free programs have plugins.
Consider Emacs. The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Diego Novillo wrote:
Before plug-ins: put your gimple-to-myIR converter in passes.c
After plug-ins: dlopen gimple-to-myIR.so
Both represent the same effort. Both require your converter to be kept
up-to-date with GCC's ever shifting ABI/API.
Diego Novillo wrote:
Richard Kenner wrote:
I don't see that. Why is it that much harder to link in with GCC
than doing
it as a plugin?
Limited time and steep learning curves. Typically, researchers are
interested in rapid-prototyping to keep the paper mill going. Plug-ins
offers
Andrew Haley wrote:
Well, that's where we differ. I don't at all understand how adding
plugins won't make it very much easier. It seems obvious to me that
if there is a reasonably well-defined plugin architecture it will be
vastly easier to export data from gcc's front-ends to a proprietary
On 16 November 2007 10:56, Li Wang wrote:
Dave Korn 写道:
Various CPU backends (but IIRC not i386) implement a naked function
attribute, which suppresses function epilogue and prologue generation. You
could implement something like that.
It seems to be what I want. Could you please
* Ian Lance Taylor [EMAIL PROTECTED] [2007-11-16 07:49]:
But as you know, most gcc ports are never contributed anyhow. Ports
that people hire Red Hat to do are contributed, but I can easily
count six gcc ports I've seen myself that were never contributed.
Can you list those six ports? Has
Bernd Schmidt wrote:
I must admit I don't understand the upside. I've always thought of
plugins as something proprietary programs need because their source
isn't open.
On the contrary, the plug-in model is used in several large and complex
open source projects (firefox, thunderbird, gimp,
Bernd Schmidt wrote:
Ian Lance Taylor wrote:
I think it's quite important for gcc's long-term health to permit and
even encourage academic researchers and students to use it. And I see
plugins as directly supporting that goal. Note that I don't see any
problem with requiring (or attempting
On 16 November 2007 17:25, Richard Kenner wrote:
If I want to test some piece of code in the compiler, I don't have to
bootstrap with or without plugins (unless I need to for testing purposes).
The only difference is how I link, which seems a completely trivial
distinction to me.
That
Andrew Haley [EMAIL PROTECTED] writes:
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
Most new gcc back-ends are private, so I don't buy that part of the
argument. And in any case nobody is talking about plug-ins for gcc
backends. We're talking about
Andrew Haley wrote:
But as you know, most gcc ports are never contributed anyhow.
Sure, but they are still free software: if the compiler gets
distributed, so does its source code. Of couse, assigning copyright
to FSF is nice, but freedom is much more important.
Oh I fully understand
On Fri, Nov 16, 2007 at 06:15:50PM +0100, Basile STARYNKEVITCH wrote:
I even don't believe that competitor proprietary compilers are much more
documented than GCC.
Depends. Vendors of compiler front ends (those sold for extension by
others) provide very good documentation, much better than
Ian Lance Taylor wrote:
I have a different fear: that gcc will become increasing irrelevant,
as more and more new programmers learn to work on alternative free
compilers instead. That is neutral with regard to freedom, but it
will tend to lose the many years of experience which have been put
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
Most new gcc back-ends are private, so I don't buy that part of the
argument. And in any case nobody is talking about plug-ins for gcc
Richard Kenner wrote:
As was said before, the difficultly in people working with GCC is
primarily lack of adequate documentation.
I am not sure of that.
GCC is a huge piece of software. This is the major difficulty: grasping
a 3MLOC software whose source is available, rather well
On 16 November 2007 00:01, Jim Wilson wrote:
Michael_fogel wrote:
(ior:SI (subreg:SI (mem/s:QI (reg/f:SI 1250) [0
variable.flags+0 S1 A32]) 0)
See register_operand and general_operand in recog.c. (SUBREG (MEM)) is
accepted by register_operand if INSN_SCHEDULING is not defined, for
Diego Novillo writes:
Diego I'm not sure if it's intended, but I don't think it's desirable. The
Diego information needed to do LTO optimizations should be independent from
Diego the debugging information.
Diego We could have a --strip-lto option for strip, but I don't think
Diego
Andrew Haley writes:
I have a different fear: that gcc will become increasing
irrelevant, as more and more new programmers learn to work on
alternative free compilers instead. That is neutral with regard to
freedom, but it will tend to lose the many years of experience
which have been put
Hi,
On Nov 16, 2007 6:45 PM, Diego Novillo [EMAIL PROTECTED] wrote:
Richard Kenner wrote:
As was said before, the difficultly in people working with GCC is
primarily lack of adequate documentation. Creating a plugin interface
is certainly much more fun than writing documentation, but
== Dep, Khushil (GE Money) [EMAIL PROTECTED] writes:
I believe efforts to clarify and expand documentation is much more
likely to entice new researchers and developers rather than a
plugin system which no doubt would be poorly documented!
This idea comes up a lot.
I'm sympathetic to it --
Martin Michlmayr [EMAIL PROTECTED] writes:
* Ian Lance Taylor [EMAIL PROTECTED] [2007-11-16 07:49]:
But as you know, most gcc ports are never contributed anyhow. Ports
that people hire Red Hat to do are contributed, but I can easily
count six gcc ports I've seen myself that were never
On Fri, Nov 16, 2007 at 09:54:25PM +0300, [EMAIL PROTECTED] wrote:
I have an invention which makes possible to brake through the barriers of
common software development.
Nothing new here: add a level of indirection (or use C++ virtual
functions), and dynamically load code. In the Ptolemy
Basile STARYNKEVITCH [EMAIL PROTECTED] writes:
Ian Lance Taylor wrote:
But as you know, most gcc ports are never contributed anyhow.
Naively, I didn't know that!
I thought most ports were contributed, but some rejected because of
code quality, lack of reviewers, etc
But does these
Dear Sirs.
In respect of your time I will straight to the matter.
It is absolutely obvious that in today's world in order to be on the top it
is required to be innovative. Without that you can not brake through the
competitors. It is just impossible.
I have an invention which makes possible
Joe Buck wrote:
RMS believes that people who extend GCC, hoping to take their
extensions
proprietary, and then finding that they can't, will then just decide
to
contribute the code, if it is useful, since otherwise they can't
distribute and have to support it by themselves forever, or else
On 16 November 2007 05:56, Li Wang wrote:
As you said, the coprocessor has no ABI to describe a stack and a
function interface, then inline applies. But how could I inline 'main'?
And I am sorry for I misuse the word 'elf assembly', what exactly I mean
by that is how to omit the section or
Much as I hate prolonging a probably-pointless discussion...
I hope we aren't thinking about keeping things difficult for
everybody simply because everybody includes some people who
may want to take advantage of GCC in a proprietary way. In
the long term, this only benefits the folks you'd be
Richard Kenner wrote:
I have a different fear: that gcc will become increasing irrelevant,
as more and more new programmers learn to work on alternative free
compilers instead. That is neutral with regard to freedom, but it
will tend to lose the many years of experience which have been put
into
William Maddox wrote:
It appears that portions of the LTO information are emitted in the usual
debugging sections, rather, information that would already be present there
is shared. This is great for reducing the size of object files that
contain both
LTO info and debugging info, but means
Ian Lance Taylor wrote:
I think it's quite important for gcc's long-term health to permit and
even encourage academic researchers and students to use it. And I see
plugins as directly supporting that goal. Note that I don't see any
problem with requiring (or attempting to require) that any
On 11/15/07, Rob Quill [EMAIL PROTECTED] wrote:
Hi,
I was wondering if anyone could help me make sense of the
more_specialized_fn() function in pt.c (line 13281).
Specifically, I am trying to understand what each of the are:
tree decl1 = DECL_TEMPLATE_RESULT (pat1);
This is the actual
I must admit I don't understand the upside. I've always thought of
plugins as something proprietary programs need because their source
isn't open.
In my view, plugins will bitrot quickly as GCC's interface changes; and
they won't even help with the learning curve - does anyone believe for
On Fri, Nov 16, 2007 at 03:03:15PM -0500, Diego Novillo wrote:
I'm not sure if it's intended, but I don't think it's desirable. The
information needed to do LTO optimizations should be independent from the
debugging information.
FWIW, I disagree - not least because this makes GCC much more
Dave Korn wrote:
First places to look would be GO_IF_LEGITIMATE_ADDRESS and
REG_OK_FOR_BASE_P, wouldn't they? Particularly in conjunction with
REG_OK_STRICT.
This could be a REG_OK_STRICT issue, but it isn't the usual case of
accepting an unallocated pseudo in reload, as we have a SUBREG
Sharing beteen the debug info and the LTO info is a very a good thing, and
I feel that we should not adopt a solution that breaks that. I'd really rather
leave 'strip --strip-debug' broken than bloat up the object files. The sort of
solution I would favor would be to make 'strip' smarter so
Thomas Koenig wrote:
On Thu, 2007-11-15 at 17:42 -0800, Jim Wilson wrote:
Thomas Koenig wrote:
build/genmodes -h tmp-modes.h
/bin/sh: build/genmodes: No such file or directory
Your problem is that you accidentally ran ../gcc/gcc/configure instead
of ../gcc/configure. However, why it fails
On Friday 16 November 2007, Dave Korn wrote:
On 16 November 2007 05:56, Li Wang wrote:
As you said, the coprocessor has no ABI to describe a stack and a
function interface, then inline applies. But how could I inline 'main'?
And I am sorry for I misuse the word 'elf assembly', what exactly
Bernd == Bernd Schmidt [EMAIL PROTECTED] writes:
Bernd I must admit I don't understand the upside. I've always thought of
Bernd plugins as something proprietary programs need because their source
Bernd isn't open.
Everybody explained about the existing free software that has plugins.
But, I
Hello,
The amount of duplicate work done on RTL is sometimes really amazing,
especially since the merge of the dataflow branch. Some of the people
who have worked on the dataflow branch had hoped that other developers
would help with the follow-up actions to actually *use* all the
information
On Nov 16, 2007 11:43 PM, Steven Bosscher [EMAIL PROTECTED] wrote:
Hello,
The amount of duplicate work done on RTL is sometimes really amazing,
especially since the merge of the dataflow branch. Some of the people
who have worked on the dataflow branch had hoped that other developers
would
On Nov 14, 2007, at 05:27, Vincent Lefevre wrote:
Initially, float could simply use double and cast the result.
For double-float the results will remain correctly rounded.
Yes, very probably, but this needs to be proven for each supported
function, due to the double rounding problem (this
Dep, Khushil (GE Money) [EMAIL PROTECTED] writes:
| I'm not sure that a plugin system will encourage more research and
| development. Anyone who even contemplates getting into the this field
| isn't going to be someone who is easily disuaded by challenges and
| obstacles.
I beg to disagree --
Geert Bosch wrote:
On Nov 14, 2007, at 05:27, Vincent Lefevre wrote:
Initially, float could simply use double and cast the result.
For double-float the results will remain correctly rounded.
Yes, very probably, but this needs to be proven for each supported
function, due to the double
--- Comment #61 from pault at gcc dot gnu dot org 2007-11-16 09:23 ---
Richard,
I believe that this is the right outcome for achar_4?
(*(char[0:][1:1] *) atmp.4.data)[S.5][1]{lb: 1 sz: 1} =
*(_gfortran_
compare_string (D.529, (*(char[0:][1:1] *) atmp.2.data)[S.5][1]{lb: 1
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-16 11:03 ---
We have wrong types in the IL before forwprop3:
struct sockaddr_in * saddr.3;
struct in_addr * D.1627;
unsigned char * addr;
unsigned char D.1580;
...
L13:;
saddr.3_22 = (struct sockaddr_in *) D.1577_5;
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-11-16 10:36
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenther at suse dot de 2007-11-16 09:45 ---
Subject: Re: [4.3 Regression] Confusing error message
with missing #include algorithm
On Thu, 15 Nov 2007, pcarlini at suse dot de wrote:
--- Comment #8 from pcarlini at suse dot de 2007-11-15 19:07 ---
--- Comment #62 from rguenther at suse dot de 2007-11-16 09:50 ---
Subject: Re: wrong types in character array/scalar binop
On Fri, 16 Nov 2007, pault at gcc dot gnu dot org wrote:
--- Comment #61 from pault at gcc dot gnu dot org 2007-11-16 09:23
---
Richard,
I
--- Comment #25 from rguenth at gcc dot gnu dot org 2007-11-16 12:28
---
Re-opening to not forget about the follow-up patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-11-16 10:10
---
Subject: Bug 34099
Author: rguenth
Date: Fri Nov 16 10:10:05 2007
New Revision: 130222
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130222
Log:
2007-11-16 Richard Guenther [EMAIL PROTECTED]
PR
When compiling with -O3 everything is fine.
When compiling with -g this pointer passed to constructors and destructors
don't line up.
I guess the this pointer passed to the constructor is bogus.
--
Summary: wrong this pointer passed to constructor of temporary
--- Comment #27 from rguenth at gcc dot gnu dot org 2007-11-16 14:40
---
Subject: Bug 33870
Author: rguenth
Date: Fri Nov 16 14:40:04 2007
New Revision: 130231
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130231
Log:
2007-11-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-16 15:42 ---
I am tempted to close this since it is almost impossible to debug. We would
need an exact copy of your setup (for example, which files you touched and
which ones you didn't since last built). And still this may be due
--- Comment #1 from manu at gcc dot gnu dot org 2007-11-16 15:53 ---
Andrew, is this still valid?
There is a simplify_replace_tree in gcc/tree-ssa-loop-niter.c. Is that what you
want?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from tbm at cyrius dot com 2007-11-16 13:48 ---
Dorit, can you please take a look again?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-11-16 14:41
---
Fixed. Again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
gcc.gnu.org/bugs/reghunt.html
has instructions on how to obtain gcc via CVS. This should be updated to
reflect the move to subversion.
--
Summary: bugs/reghunt.html should be updated to mention svn
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #1 from rob dot quill at gmail dot com 2007-11-16 15:03 ---
Hey,
I can confirm this and am trying to investigate the problem. It seems that
more_specialized_fn() loops over the arguments to the first overloaded
function, where in this case there are two, but the tree chain
--- Comment #1 from jeff at thecreems dot com 2007-11-16 14:27 ---
Seems like a good idea. Since we often say that correctness should come before
performance when it comes to optimization, it has always seemed odd to me that
performance was the default mode of operation.
We can
--- Comment #5 from pault at gcc dot gnu dot org 2007-11-16 13:46 ---
Subject: Bug 33986
Author: pault
Date: Fri Nov 16 13:46:04 2007
New Revision: 130228
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130228
Log:
2007-11-16 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-16 13:14 ---
Subject: Bug 34113
Author: rguenth
Date: Fri Nov 16 13:14:03 2007
New Revision: 130223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130223
Log:
2007-11-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from joseph at codesourcery dot com 2007-11-16 16:53 ---
Subject: Re: [4.1/4.2/4.3 Regression] spurious exceptions
with -ffloat-store
The failure still appears with a compiler from revision 130227, after the
patch for PR 34099 was committed.
--
--- Comment #2 from mueller at gcc dot gnu dot org 2007-11-16 11:37 ---
workaround:
--- reg-stack.c (revision 130198)
+++ reg-stack.c (working copy)
@@ -925,7 +925,7 @@ swap_to_top (rtx insn, stack regstack, r
/* Place operand 1 at the top of stack. */
regno = get_hard_regnum
--- Comment #26 from rguenth at gcc dot gnu dot org 2007-11-16 12:29
---
Which I have.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
By default, GCC is not an Ada compiler and has not been one for years, because
range checks are disabled by default and require an explicit switch (-gnato).
The rationale, as I understand it, was that range checks were expensive in
terms of CPU usage.
However, the rationale is much less valid
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-11-16 11:51
---
You shouldn't configure the compiler with --disable-checking, this eliminates
the internal assertions which are desirable.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from eres at il dot ibm dot com 2007-11-16 06:52 ---
Created an attachment (id=14563)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14563action=view)
gcno (with the correct filename)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-16 16:58 ---
Introduced by
http://gcc.gnu.org/viewcvs?root=gccview=revrev=129596
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from manu at gcc dot gnu dot org 2007-11-16 16:17 ---
Is there any difference in the standard behaviour between printf(%s, NULL)
and puts(NULL)? I mean, why printf(%s, NULL) receives special consideration
but neither puts(NULL) nor fprintf(stdout, %s, NULL) do?
Anyway,
--- Comment #1 from peter_foelsche at agilent dot com 2007-11-16 16:38
---
Created an attachment (id=14564)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14564action=view)
test.cpp
contains a main function at the end which calls printf() with some temporary
objects. I put
--- Comment #3 from manu at gcc dot gnu dot org 2007-11-16 15:59 ---
Is this still valid?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
By default, GCC is not an Ada compiler and has not been one for years, because
stack overflow checks are disabled by default and require an explicit switch
(-fstack-check). The rationale, as I understand it, was that stack overflow
checks were expensive in terms of CPU usage.
However, the
--- Comment #1 from manu at gcc dot gnu dot org 2007-11-16 15:25 ---
Confirmed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #14 from manu at gcc dot gnu dot org 2007-11-16 13:58 ---
(In reply to comment #13)
Even the text of the warning is misleading. Why should it be explicitly
initialised, when the standard says it will be implicitly initialised if a
suitable default constructor exists?
--- Comment #6 from pault at gcc dot gnu dot org 2007-11-16 14:48 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
const int foo[] = {};
should be an error according to the ISO:ANSI standard:
An array of unknown size initialized with a brace-enclosed initializer-list
containing n initializers, where n shall be greater than zero, is defined
as having n elements
--- Comment #2 from laurent at ient dot rwth-aachen dot de 2007-11-16
17:46 ---
(In reply to comment #1)
What does -Winline say?
Have you tried with always_inline? Example:
/* Prototype. */
inline void foo (const char) __attribute__((always_inline));
Whaow, I have
--- Comment #63 from pault at gcc dot gnu dot org 2007-11-16 17:01 ---
I suppose that, after all, I should reassign myself.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-16 18:00 ---
Note that for completely inlining kernels you can use the
__attribute__((flatten))
on the *calling* function. Usually with expression templates that is the
function
containing the loops, like
void
--- Comment #1 from pcarlini at suse dot de 2007-11-16 15:12 ---
3.4.x is not maintained anymore. Otherwise, -pedantic is enough.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-16 18:17 ---
Confirmed. Still broken on the 4.1 and 4.2 branches. Wrong types on the
comparison:
D.1530_7 == 0B
(gdb) call debug_tree (expr)
eq_expr 0xb7c0f1d4
type boolean_type 0xb7c1a4ac _Bool public unsigned QI
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|new overload resolution |[4.3 Regression] new
|error
--- Comment #2 from peter_foelsche at agilent dot com 2007-11-16 16:42
---
the attached piece of source code does exhibit the compiler problem with the
new compiler.
When compiling using -O3 the code works fine. When compiling using -g the bug
happens.
Some temporary objects are being
--- Comment #3 from peter_foelsche at agilent dot com 2007-11-16 16:45
---
We tested this only for the 64bit version.
I don't know if this happens for the 32bit version.
The operating system is LINUX:
Linux bonfire 2.4.21-47.0.1.EL #1 SMP Fri Oct 13 17:51:36 EDT 2006 x86_64
x86_64
--- Comment #4 from us15 at os dot inf dot tu-dresden dot de 2007-11-16
18:58 ---
The workaround fixes my build problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34110
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-16 18:20 ---
Or rather a frontend bug if it doesn't promote either the integer to a pointer
or the pointer to an integer:
./cc1 -quiet -O2 t.i -quiet
t.i: In function foo:
t.i:9: warning: comparison between pointer and
--- Comment #12 from jakub at gcc dot gnu dot org 2007-11-16 12:15 ---
Posted patch: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00895.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Hi,
Running the following code:
#include memory
using namespace std;
class CBase {};
class CDerived : public CBase {};
void Set(auto_ptrCBase base)
{
}
int main(int argc, char *argv[])
{
auto_ptrCDerived derived(new CDerived);
Set(derived); // error: conversion from
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-16 19:57 ---
This is not a GCC bug. There are no computed gotos in your function so the
label can be moved anywhere around. The scheduler moves around the label in
this case.
*** This bug has been marked as a duplicate of
1 - 100 of 182 matches
Mail list logo
