--- Comment #5 from bonzini at gnu dot org 2007-08-20 07:11 ---
Richard, is this the issue you had a patch for?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #16 from pault at gcc dot gnu dot org 2007-08-20 07:16 ---
comment #10 from Roger-Sayle is being kept "live" by this PR. Whilst I am
interested, I have to give priority to other PRs to make best use of my limited
time. I may yet come back to it
Paul
--
pault at gcc
--- Comment #2 from Axel dot Thimm at ATrpms dot net 2007-08-20 07:36
---
(In reply to comment #1)
> Considering how old 3.4.3 is, I doubt we can do anything to help you here
> except to suggest to try 4.2.1, the latest release.
We would need to stay at 3.4.x. If we can reproduce this
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-20 07:40 ---
(In reply to comment #2)
> We would need to stay at 3.4.x. If we can reproduce this for the latest 3.4.x
> release (3.4.6) would there be interest in fixing it? Thanks!
None as 3.4.x is no longer supported. Why do
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-08-20 07:43
---
Subject: Bug 30564
Author: pinskia
Date: Mon Aug 20 07:42:55 2007
New Revision: 127638
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127638
Log:
2007-08-20 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-08-20 07:43
---
Fixed, sorry it took me this long to test/submit/commit this patch, I had been
busy with other patches and other work.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from jakub at gcc dot gnu dot org 2007-08-20 07:54 ---
Subject: Bug 33025
Author: jakub
Date: Mon Aug 20 07:53:58 2007
New Revision: 127639
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127639
Log:
PR c++/33025
* init.c (build_new_1): Rename place
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-08-20 07:58
---
Honza, can you look into this pls?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31886
mf-runtime.h won't be installed with "make -j2 install" under x86_64 target.
>From the log file apparantly it is installed at first and then removed when
installing rest of gcc headers files. Can be caused by incorrect dependence
between mudflap and other target.
--
Summary: Missing
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-20 08:11 ---
Nobody does "make install" with -j.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33119
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-20 08:11 ---
Subject: Bug 32992
Author: jakub
Date: Mon Aug 20 08:10:54 2007
New Revision: 127640
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127640
Log:
PR c++/32992
* typeck.c (check_return_expr): Don'
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-20 08:12 ---
With - 1, we get:
(plus:DI (symbol_ref:DI ("a") [flags 0x1402] )
(const_int -1 [0x]))
While with +1, we get:
(const:SI (plus:SI (symbol_ref:SI ("a") [flags 0x1402] )
(const_int 1 [0x1])))
--- Comment #5 from jakub at gcc dot gnu dot org 2007-08-20 08:17 ---
Subject: Bug 32992
Author: jakub
Date: Mon Aug 20 08:17:21 2007
New Revision: 127641
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127641
Log:
PR c++/32992
* typeck.c (check_return_expr): Don'
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-20 08:19 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-20 08:19 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Hi Guys,
I ran a x86 hosted bootstrap of the mainline gcc and binutils
sources over the weekend and it failed with this error report:
bfd/elflink.c: In function 'elf_fixup_link_order':
bfd/elflink.c:9893: error: type mismatch in unary expression
long unsigned int
int
D.167
On 8/20/07, Nick Clifton <[EMAIL PROTECTED]> wrote:
> bfd/ChangeLog
> 2007-08-20 Nick Clifton <[EMAIL PROTECTED]>
>
> * elflink.c (elf_fixup_link_order): Rewrite conversion of
> s->alignment_power into an offset mask in order to avoid a gcc
> error message.
This is wrong,
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-20 08:35 ---
Hmm, the difference between +/- 1 is that get_inner_reference returns bitpos of
8 and offset of 0 for +1, while -1 it returns bitpos of 0 and offset of -1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32563
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-08-20 08:37
---
Confirmed. (use -m32 on x86_64)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-20 08:38 ---
The difference comes from:
/* If OFFSET is constant, see if we can return the whole thing as a
constant bit position. Otherwise, split it up. */
if (host_integerp (offset, 0)
&& 0 != (tem = size_bino
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-20 08:45 ---
Fixed, most likely by:
2007-08-19 Daniel Berlin <[EMAIL PROTECTED]>
Fix PR 32772
Fix PR 32716
Fix PR 32328
Fix PR 32303
--
pinskia at gcc dot gnu dot org changed:
Wh
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-20 08:48 ---
Fixed on the mainline now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-20 08:49 ---
Fixed on the trunk, most likely by:
2007-08-19 Daniel Berlin <[EMAIL PROTECTED]>
Fix PR 32772
Fix PR 32716
Fix PR 32328
Fix PR 32303
--
pinskia at gcc dot gnu dot org changed:
--- Comment #10 from ht990332 at gmail dot com 2007-08-20 08:51 ---
Will 4.2.2 get this fix or only trunk?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-20 08:52 ---
I get the original ICE now.
(gdb) p debug_generic_expr (stmt)
return
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32305
--- Comment #2 from Joey dot ye at intel dot com 2007-08-20 08:53 ---
(In reply to comment #1)
> Nobody does "make install" with -j.
I guess so, that's why I set it "minor". But does that mean error is expected
with -j? My script had -j by accident and it costed me hours to identify the
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-20 09:13 ---
Even the non reduced testcase works now, so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-20 09:13 ---
Any news on this?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirme
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-20 09:18 ---
This testcase needs a rereduction, the two reductions here work now.
Reducing now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30840
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-20 09:23 ---
offset is not host_integerp because it has the overflow flag set because
-1 in a.c[-1] has the overflow flag set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32563
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-08-20 09:27
---
Re-opening, 4.2 is still affected.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from richard at codesourcery dot com 2007-08-20 09:40
---
Subject: Re: [4.3 Regression] internal compiler error: RTL check: expected
code 'reg', have 'subreg' in rhs_regno, at rtl.h:956
"bonzini at gnu dot org" <[EMAIL PROTECTED]> writes:
> --- Comment #5 from bonzi
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-20 09:44 ---
Which is because...
TREE_OPERAND (pos, 1) = fold_build2 (PLUS_EXPR, itype,
fold_convert (itype,
TREE_OPERAND (pos, 1)),
Hi Guys,
I tried bootstrapping the mainline gcc sources over the weekend,
using the current mainline binutils sources in an integrated source
tree. The bootstrap failed with a problem in bfd/elflink.c which I
have already reported and worked around. The build then failed
later on with
On 8/20/07, Nick Clifton <[EMAIL PROTECTED]> wrote:
> But before I check such a patch in I would like to know if the gcc
> error message is really correct, or if I have run across a
> gimplification bug.
As mentioned before this error message is really an internal error, we
really should be
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-20 10:20
---
(In reply to comment #7)
> 1) The actual cause of the ICE.
That point is unfortunately beyond my understanding.
> 2) The difference between precision and type bitsize in this situation.
>
> We have to decide if
--- Comment #6 from manu at gcc dot gnu dot org 2007-08-20 10:26 ---
Is this still valid?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-20 10:31 ---
Fixed by:
2006-12-11 Aldy Hernandez <[EMAIL PROTECTED]>
Diego Novillo <[EMAIL PROTECTED]>
* gcc.dg/tree-ssa/pr26421.c: Likewise
--
pinskia at gcc dot gnu dot org changed:
What
--
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
When gfortran compiles a module on OSX which declares defined size arrays the
resulting module object file contains the array's allocated memory making the
files potentially enourmous. e.g.
module test_module
real, dimension(1000) :: a
end module test_module
gfortran -c test_module.f90
If
--- Comment #4 from mueller at gcc dot gnu dot org 2007-08-20 11:13 ---
ping.. any results?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32756
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-20 11:47
---
I wasn't even aware of their existence! I'll do it (unless you want to?),
thanks for the doc patch.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-20 11:55
---
Here is a new reduced testcase (compile at -O3 -fno-strict-aliasing):
struct rxvt_salloc {
char *firstblock;
unsigned int firstfree;
};
struct line_t {
unsigned int *t;
unsigned int f;
};
struct rxvt_sall
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-20 11:57
---
> Here is a new reduced testcase (compile at -O3 -fno-strict-aliasing):
One more note, this testcase ICEs with the C front-end now :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30840
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-08-20 12:00
---
You can also now invoke it just with "-O1 -ftree-store-ccp" :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30840
--- Comment #3 from rakdver at kam dot mff dot cuni dot cz 2007-08-20
12:10 ---
Subject: Re: Failing to represent the stride (with array) of a dataref when it
is not a constant
> --- Comment #2 from dorit at gcc dot gnu dot org 2007-08-20 05:55 ---
> > Making us return symbol
--- Comment #5 from nathan at gcc dot gnu dot org 2007-08-20 12:21 ---
I have a patch, which needs fuller testing. (I've been on vacation :))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32756
--- Comment #9 from arnaud02 at users dot sourceforge dot net 2007-08-20
12:28 ---
Adding -finit-real=nan (http://gcc.gnu.org/ml/fortran/2007-08/msg00408.html) is
a real bonus for gfortran.
Any chance to add "-finit-real=snan" to set "Signalling NaN" ?
A SNaN cannot be the result of an
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-08-20 12:32 ---
Subject: Bug 22451
Author: rguenth
Date: Mon Aug 20 12:31:44 2007
New Revision: 127647
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127647
Log:
2007-08-20 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-20 12:32 ---
Subject: Bug 22369
Author: rguenth
Date: Mon Aug 20 12:31:44 2007
New Revision: 127647
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127647
Log:
2007-08-20 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #6 from mueller at gcc dot gnu dot org 2007-08-20 12:43 ---
I`d be happy to help with testing :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32756
Hello,
I have the classes A and B where B is derived from A. The following methods are
given:
bool A::method();
virtual bool A::method(int arg);
bool B::method(int);
Now when I want to call method() on an object of type B I get the compiler
error that there is no method() in class B and the onl
--
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 #6 from rguenth at gcc dot gnu dot org 2007-08-20 13:24 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-08-20 13:25 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Bootstrapping gcc from the 19 Aug 2008 mainline sources (and possibly earlier
and/or later) with an integrated source tree containing the binutils mainline
sources fails with:
gcc/current/opcodes/i386-dis.c: In function 'dofloat':
gcc/current/opcodes/i386-dis.c:4193: error: type mismatch in po
--- Comment #1 from nickc at redhat dot com 2007-08-20 13:46 ---
Created an attachment (id=14080)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14080&action=view)
Compressed, pre-processed source file used to reproduce the problem
This source file was compiled with this command li
--- Comment #5 from nickc at redhat dot com 2007-08-20 13:48 ---
Bug report #33122 may be a duplicate of this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
Hi Andrew,
As mentioned before this error message is really an internal error, we
really should be fixing GCC and not changing binutils. And I already
mentioned this is most likely PR 22371 and that you should be filing
bug reports about these two errors/ICEs.
I have filed PR 33122 to cover th
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-20 13:54 ---
struct A
{
virtual int method(int);
int method();
};
struct B: A
{
int method(int);
};
That is the example. You need to add:
using A::method;
to get exposed in B, A::method.
--
pinskia at gcc dot gnu do
--- Comment #7 from manu at gcc dot gnu dot org 2007-08-20 14:18 ---
Even simpler testcase:
int foo ()
{
int i = 0;
int j;
if (1 == i)
return j;
return 0;
}
This will only be reliably fixed by building a better SSA representation.
Moving the passes around will
--- Comment #5 from manu at gcc dot gnu dot org 2007-08-20 14:47 ---
Andrew, what about functions marked with attribute "pure" ?
int atoi(const char *) __attribute__ ((pure));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33086
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-20 14:47
---
Confirmed. The same thing is true for external procedures, like:
program test
real x
external x
print *, x(2)
end program test
real function x(i)
integer i
x = i + 1
end function x
Two decls are gene
--- Comment #10 from manu at gcc dot gnu dot org 2007-08-20 14:49 ---
I now think that Andrew is right and that PR33086 and this one are INVALID.
'const' does not mean read-only in C++ at all, and much less in C. atoi(const
char *) could always initialize buf[]. However, perhaps it can a
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Status|UNCONFIRMED |NEW
Ever
--- Comment #11 from bangerth at dealii dot org 2007-08-20 14:56 ---
(In reply to comment #10)
> I now think that Andrew is right and that PR33086 and this one are INVALID.
> 'const' does not mean read-only in C++ at all, and much less in C. atoi(const
> char *) could always initialize b
--- Comment #12 from manu at gcc dot gnu dot org 2007-08-20 15:03 ---
(In reply to comment #11)
> (In reply to comment #10)
> > I now think that Andrew is right and that PR33086 and this one are INVALID.
> > 'const' does not mean read-only in C++ at all, and much less in C.
> > atoi(con
--- Comment #10 from langton at gcc dot gnu dot org 2007-08-20 15:07
---
(In reply to comment #9)
> Adding -finit-real=nan (http://gcc.gnu.org/ml/fortran/2007-08/msg00408.html)
> is
> a real bonus for gfortran.
> Any chance to add "-finit-real=snan" to set "Signalling NaN" ?
> A SNaN
--- Comment #13 from manu at gcc dot gnu dot org 2007-08-20 15:08 ---
(In reply to comment #12)
>
> This testcase has nothing to do with uninitialized variables. If the variable
> is 'const' already, then there will never be a warning. Will it produce
> segmentation fault for a local au
--- Comment #24 from jason at gcc dot gnu dot org 2007-08-20 15:08 ---
Subject: Bug 7302
Author: jason
Date: Mon Aug 20 15:08:24 2007
New Revision: 127649
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127649
Log:
PR c++/7302
* cp/class.c (finish_struct_1): Warn
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-20 15:30 ---
Reduced testcase:
struct dis386 {
const char *x;
};
static const struct dis386 float_reg[][2] = {
{ { "fadd" }, { "fadd" } },
};
void foo(int i, int j)
{
const struct dis386 *dp;
dp = &float_reg[i - 1][j]
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-08-20 15:39 ---
Ah no, this is a bug in fold-const introduced by the pplus merge. Fix:
@@ -9541,7 +9547,9 @@ fold_binary (enum tree_code code, tree t
tree arg01 = fold_convert (sizetype, TREE_OPERAND (arg0, 1));
--
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
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-08-20 15:45 ---
Created an attachment (id=14081)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14081&action=view)
patch
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from bangerth at dealii dot org 2007-08-20 15:54 ---
(In reply to comment #12)
> This testcase has nothing to do with uninitialized variables.
No, of course. I only meant to reply to your assertion that there could be
cases where a function initializes an object that is
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Summary|Mistaken type mismatch error|[4.3 Regre
--- Comment #7 from rask at gcc dot gnu dot org 2007-08-20 16:06 ---
Created an attachment (id=14082)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14082&action=view)
Preprocessed testcase; compile with -O2 -g -m2a -fno-builtin
It appears to fail the same way as earlier:
(gdb) fr
--- Comment #15 from manu at gcc dot gnu dot org 2007-08-20 16:15 ---
(In reply to comment #14)
> This is meant to only counter your point that:
> > 'const' does not mean read-only in C++ at all, and much less in C.
> > atoi(const
> > char *) could always initialize buf[].
> This simply
--- Comment #16 from bangerth at dealii dot org 2007-08-20 16:21 ---
(In reply to comment #15)
> Of course, the output is '5' and not '0'. So yes, atoi() seems perfectly able
> to initialize buf. (or perhaps, I am still confused).
I think you are. This program here segfaults:
--- Comment #2 from jakub at gcc dot gnu dot org 2007-08-20 16:40 ---
This has nothing to do with dwarf2 nor unwinding.
Things break during reload which decides to reload something into the b0
register (which is live at that point and not very general purpose register
anyway).
--
ht
--- Comment #17 from manu at gcc dot gnu dot org 2007-08-20 16:44 ---
(In reply to comment #16)
> (In reply to comment #15)
>
> > Of course, the output is '5' and not '0'. So yes, atoi() seems perfectly
> > able
> > to initialize buf. (or perhaps, I am still confused).
>
> Since use(
--- Comment #4 from asl at math dot spbu dot ru 2007-08-20 16:46 ---
Ooops, attached patch is not complete. I also need:
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -1027,7 +1027,7 @@ gfc_get_nodes
--- Comment #18 from manu at gcc dot gnu dot org 2007-08-20 16:46 ---
When I say "constant are not propagated" I mean "the constant value of a
variable" such as:
int i=0;
use(&i);
foo(i);
Here, GCC does not propagate the value of i to do foo(0). Remove the call to
use and then it
--- Comment #5 from asl at math dot spbu dot ru 2007-08-20 16:47 ---
(In reply to comment #3)
> Two decls are generated for function x, the first one (inside MAIN__) doesn't
> have a proper argument list while the second one is OK. When I try to make
> gfortran emit only one decl per ext
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-20 16:51
---
(In reply to comment #5)
> How is it choking? Maybe I already seen this during preparation of quick
> patch.
Well, it's trying to reuse a decl without arglist for a function call with
arguments, and it leads to
--- Comment #19 from bangerth at dealii dot org 2007-08-20 16:58 ---
(In reply to comment #18)
> When I say "constant are not propagated" I mean "the constant value of a
> variable" such as:
>
> int i=0;
> use(&i);
> foo(i);
>
> Here, GCC does not propagate the value of i to do f
--- Comment #7 from asl at math dot spbu dot ru 2007-08-20 17:00 ---
Well, I haven't seen this. The only segfault I've seen was in trans-types.c
(patch mentioned)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
--- Comment #6 from echristo at apple dot com 2007-08-20 17:11 ---
No, I spoke to Daniel about it a while back, but he hasn't had time to look
into it. It's definitely caused by the toplevel changes to libgcc. The basic
idea is that the toplevel makefile re-installs libgcc into the gcc d
--- Comment #20 from manu at gcc dot gnu dot org 2007-08-20 17:12 ---
(In reply to comment #19)
>
> What if you had "const int i=0"? As I said before, use() may do a const-cast
> to get rid of the constness of its argument, but the result is only
> well-defined
> if the object pointed t
I am trying to cross-compile a filter driver for a printer, by adding it to
CUPS/filter directory( file name rastertostar) for arm-linux-gcc ( version
3.4.6).
This filter driver is compiling and working fine for i386 machine.But when i am
compiling it for arm-linux-gcc it gives an internal compiler
For this simplified code:
template
char* f1() { if (c == 0) return 0; else return new char[c]; }
char* f2() { return f1<0>(); }
the C++ frontend issues an unconditional warning. When compiling with no
options, I get
foo.cc: In function char* f1() [with int c = 0]:
foo.cc:3: instantiated fro
--- Comment #4 from Axel dot Thimm at ATrpms dot net 2007-08-20 18:05
---
The same thing happens with 4.2.1, only that there are additional warnings
before:
Comparing stages 2 and 3
warning: ./libgcc/_fixunssfdi.o differs
warning: ./libgcc/_udivmoddi4_s.o differs
[...]
warning: ./libgc
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-20 18:25 ---
Wow, scheduling plus reload does extremely horrible job here.
This is
b[0] = {};
b[0].a.j[0] = 0;
b[0].a.j[1] = 0;
b[0].a.j[2] = 0;
b[0].a.j[3] = 0;
b[0].a.j[4] = 0;
b[0].a.j[5] = 0;
b[0].a.j[6] = 0;
--- Comment #4 from vmakarov at redhat dot com 2007-08-20 18:46 ---
Yes, I belive my RA should manage the situation and use not only b0 register.
But in general, I think we need also register pressure heuristics in insn
scheduler before the register allocation to constrain insn movement
--- Comment #21 from gdr at cs dot tamu dot edu 2007-08-20 18:50 ---
Subject: Re: warn for uninitialized arrays passed as const* arguments
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| When I say "constant are not propagated" I mean "the constant value of a
| variable" s
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| For this simplified code:
|
| template
| char* f1() { if (c == 0) return 0; else return new char[c]; }
| char* f2() { return f1<0>(); }
|
| the C++ frontend issues an unconditional warning. When compiling with no
| options, I get
|
| foo.cc:
--- Comment #1 from gdr at cs dot tamu dot edu 2007-08-20 18:57 ---
Subject: Re: New: C++ frontend should not warn about new a[0] in template
context
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| For this simplified code:
|
| template
| char* f1() { if (c == 0) return 0; else
Thread model: posix
gcc version 4.3.0 20070820 (experimental)
/var/tmp/43/build-131/./gcc/cc1plus -E -quiet -nostdinc++ -v
-I/var/tmp/43/gcc-4.3.0/libstdc++-v3/../gcc
-I/var/tmp/43/build-131/powerpc-unknown-linux-gnu/libstdc++-v3/include/powerpc-unknown-linux-gnu
-I/var/tmp/43/build-131/powerpc
--- Comment #1 from michelin60 at gmail dot com 2007-08-20 19:07 ---
Created an attachment (id=14083)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14083&action=view)
preprocessed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33125
20070820 (experimental)
The host system is Debian unstable as of last week, but I don't think that
makes a difference :-)
Complete command line:
[EMAIL
PROTECTED]:~/rtems/gnu/powerpc-rtems/powerpc-rtems/libstdc++-v3/libsupc++$
/home/torsten/rtems/gnu/powerpc-rtems/./gcc/xgcc -shared-libgcc
-B
1 - 100 of 121 matches
Mail list logo
