It's BCK
Here is the first draft of the bug fix list for 4.0.1. Please let me
know about any errors and omissions; suggestions for improved descriptions
of bugs are also welcome.
The list will be converted to HTML (I have a Perl script to do most of the
work, but it then requires a bit
On Sun, 2005-07-03 at 09:13, Steve Ellcey wrote:
> I believe that, if MEMBER_TYPE_FORCES_BLK is not defined, this code will
> change the mode of a structure containing a single field from BLKmode
> into the mode of the field.
This is why we should be checking types in ia64_function_arg instead of
Snapshot gcc-3.4-20050705 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050705/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050705
You'll
On Jul 5, 2005, at 5:02 PM, Daniel Kegel wrote:
Jan Hubicka <[EMAIL PROTECTED]> wrote:
I get this error compiling linux-2.6.11.3 with gcc-4.1-20050702 on
many targets:
drivers/char/random.c:1813: internal compiler error: in
cgraph_early_inlining, at ipa-inline.c:990
I don't have the preproce
On Jul 5, 2005, at 7:42 AM, Julio Garvia Honrado wrote:
I am trying to compile a C++ program (with cxx - Compaq compiler)
that uses a C++ shared library (compiled with g++), but several
'unresolved' messages are reported.
Is there any way to solve this incidence?
Yes, have cxx ported to ma
On Tue, 2005-07-05 at 23:18 +0800, alert7 wrote:
> hi,all
>
>
> I don't know how to get the Nth argument stmt from CALL_EXPR stmt tree?
assuming TREE_CODE (call) == CALL_EXPR:
GetCallArgOperand(tree call, int i)
{
int j = 0;
tree arg;
for (arg = TREE_OPERAND (
Michael Veksler <[EMAIL PROTECTED]> writes:
| There is one more thing to consider: the ABI.
| By changing the code in the header file will break the ABI
| of tr1::unordered_set. Code compiled with older gcc and
| newer and fixed-gcc will not interoperate.
tr1 is very experimental and we don't gua
Paolo Carlini <[EMAIL PROTECTED]> wrote on 05/07/2005 23:48:03:
> Paolo Carlini wrote:
>
> >Michael Veksler wrote:
> >
> >>There is one more thing to consider: the ABI.
> >>By changing the code in the header file will break the ABI
> >>of tr1::unordered_set. Code compiled with older gcc and
> >
Jan Hubicka <[EMAIL PROTECTED]> wrote:
I get this error compiling linux-2.6.11.3 with gcc-4.1-20050702 on many
targets:
drivers/char/random.c:1813: internal compiler error: in cgraph_early_inlining,
at ipa-inline.c:990
I don't have the preprocessed source handy, but I can provide it if
this h
Gareth The Great wrote:
> The problem is i am not that used to the GCC internals and could benefit a
> lot from hacking on some sample code. Is there a simple guide anywhere on
> how to produce a new target other than "using and porting gcc"?
http://gcc.gnu.org/readings.html lists Porting GCC for
Paolo Carlini wrote:
>Michael Veksler wrote:
>
>>There is one more thing to consider: the ABI.
>>By changing the code in the header file will break the ABI
>>of tr1::unordered_set. Code compiled with older gcc and
>>newer and fixed-gcc will not interoperate.
>>
It occurs to me that by "ABI" you me
Michael Veksler wrote:
>There is one more thing to consider: the ABI.
>By changing the code in the header file will break the ABI
>of tr1::unordered_set. Code compiled with older gcc and
>newer and fixed-gcc will not interoperate.
>
>
No, no, there are no problems. First, I don't see how changin
There is one more thing to consider: the ABI.
By changing the code in the header file will break the ABI
of tr1::unordered_set. Code compiled with older gcc and
newer and fixed-gcc will not interoperate.
I don't see an easy path to avoid ABI breakage this time,
however how about preparing for
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >If you regard the object representation as an array of bytes, does it
| >take long realize it is not much different from hashing a character
| >string?
| >
| It takes less if your proposal comes together with a specific one
Michael Veksler wrote:
>Paolo Carlini <[EMAIL PROTECTED]> wrote on 05/07/2005 19:05:40:
>
>
>>However, sorry, as a matter of politeness, in my opinion expressions
>>like "absurdity" or "very bad way" are much better accepted if
>>accompanied by corresponding constructive contributions. Or,
>>al
Paolo Carlini <[EMAIL PROTECTED]> wrote on 05/07/2005 19:05:40:
>
> However, sorry, as a matter of politeness, in my opinion expressions
> like "absurdity" or "very bad way" are much better accepted if
> accompanied by corresponding constructive contributions. Or,
> alternately, just avoid suc
Joe Buck wrote:
>If I were you I'd be tempted to crib from Python. Because of the
>centrality of good hashing for Python performance, I'm sure that they've
>done a good job.
>
I agree Joe, probably that's a good empirically tested solution.
Paolo.
On Tue, Jul 05, 2005 at 08:13:41PM +0200, Paolo Carlini wrote:
> Hi Joe and Gaby and thanks for your messages,
>
> >Close, but not quite.
> >
> >Hash functions are, by nature, many-to-one. A good hash function has
> >few collisions for values that frequently appear; the program will preform
> >ve
Gabriel Dos Reis wrote:
>If you regard the object representation as an array of bytes, does it
>take long realize it is not much different from hashing a character
>string?
>
It takes less if your proposal comes together with a specific one for
character string hashing: not, trivially, because in
Michael Veksler <[EMAIL PROTECTED]> writes:
| Joe Buck <[EMAIL PROTECTED]> wrote on 05/07/2005 21:10:25:
|
| > On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
| > > It is definitely a good thing to use the full bits of value
| > > representation if we ever want to make all "inte
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >Joe Buck <[EMAIL PROTECTED]> writes:
| >
| >| On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
| >| > It is definitely a good thing to use the full bits of value
| >| > representation if we ever want to make
The problem is i am not that used to the GCC internals and could benefit a
lot from hacking on some sample code. Is there a simple guide anywhere on
how to produce a new target other than "using and porting gcc"?
On Tue, 5 Jul 2005, Nathan Sidwell wrote:
> [EMAIL PROTECTED] wrote:
> > I am curr
> We are just testing if the c compiler can compile. Nothing more at this
> point. I should point out other target libraries have the same problem.
> I pointed Kazu to those bugs last night (I cannot find them right now).
GCC_NO_EXECUTABLES ?
Joe Buck <[EMAIL PROTECTED]> wrote on 05/07/2005 21:10:25:
> On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
> > It is definitely a good thing to use the full bits of value
> > representation if we ever want to make all "interesting" bits part of
> > the hash value. For reas
On Tuesday 05 July 2005 20:30, Vladimir Makarov wrote:
> Andrey Belevantsev wrote:
> > Vladimir Makarov wrote:
> >> I'll look at this PR today.
> >
> > We've looked today at this issue. We think the problem is that
> > proposed patch of sched_get_condition() treats conditional jumps
> > likely to C
Gabriel Dos Reis wrote:
>Joe Buck <[EMAIL PROTECTED]> writes:
>
>| On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
>| > It is definitely a good thing to use the full bits of value
>| > representation if we ever want to make all "interesting" bits part of
>| > the hash value. For
On Jul 5, 2005, at 2:31 PM, DJ Delorie wrote:
DJ, can this be solved by toplevel Makefile.in's dependencies or
lang_env_dependencies?
The usual solution is to test $with_newlib and hard-code known results
if it's set.
You CANNOT rely on being able to link target programs in all cases.
It's
> DJ, can this be solved by toplevel Makefile.in's dependencies or
> lang_env_dependencies?
The usual solution is to test $with_newlib and hard-code known results
if it's set.
You CANNOT rely on being able to link target programs in all cases.
It's better if you can figure out a non-linking test
Joe Buck <[EMAIL PROTECTED]> writes:
| On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
| > It is definitely a good thing to use the full bits of value
| > representation if we ever want to make all "interesting" bits part of
| > the hash value. For reasonable or sane representat
Andrey Belevantsev wrote:
Vladimir Makarov wrote:
I'll look at this PR today.
We've looked today at this issue. We think the problem is that
proposed patch of sched_get_condition() treats conditional jumps
likely to COND_EXECs, but it doesn't fix other places in sched-deps,
where COND_EX
Hi Joe and Gaby and thanks for your messages,
>Close, but not quite.
>
>Hash functions are, by nature, many-to-one. A good hash function has
>few collisions for values that frequently appear; the program will preform
>very poorly if many inputs hash to the same value. The existing function
>will
On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
> It is definitely a good thing to use the full bits of value
> representation if we ever want to make all "interesting" bits part of
> the hash value. For reasonable or sane representations it suffices to
> get your hand on the obj
On Tue, Jul 05, 2005 at 07:05:16PM +0200, Paolo Carlini wrote:
> Michael Veksler wrote:
>
> > std::tr1::hash is implemented in a very bad way.
> > it casts double to size_t, which of course does a very poor job on big
> > values (is the result of 1.0e100 cast to size_t defined ?).
> >
> >
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Michael Veksler wrote:
|
| > std::tr1::hash is implemented in a very bad way.
| > it casts double to size_t, which of course does a very poor job on big
| > values (is the result of 1.0e100 cast to size_t defined ?).
| >
| >
| A possible solutio
Hi Michael,
PJP agreed on my forwarding his answers to the issue you raised.
--- Begin Message ---
To: C++ libraries mailing list
Message c++std-lib-15219
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Gabriel Dos Reis
> Sent: Tuesday, 05 Jul
> I get this error compiling linux-2.6.11.3 with gcc-4.1-20050702 on many
> targets:
>
> drivers/char/random.c: In function 'extract_entropy':
> drivers/char/random.c:634: sorry, unimplemented: inlining failed in call to
> 'add_entropy_words': function not considered for inlining
> drivers/char/
Balaji S <[EMAIL PROTECTED]> writes:
> >>So you have a few instructions bundled into a VLIW instruction, and
> >>one of the instructions in the bundle is moved into the delay slot,
> >>thus breaking your VLIW bundle. Right?
> > I think there are two natural approaches.
> > 1) Do the VLIW bundling
Michael Veksler wrote:
> std::tr1::hash is implemented in a very bad way.
> it casts double to size_t, which of course does a very poor job on big
> values (is the result of 1.0e100 cast to size_t defined ?).
>
>
A possible solution would be using frexp & co to extract the mantissa
and the
On Mon, Jul 04, 2005 at 01:55:52PM -0400, Andrew Pinski wrote:
>
> On Jul 4, 2005, at 1:48 PM, H. J. Lu wrote:
>
> >On Sun, Jul 03, 2005 at 11:21:15AM -0700, Mark Mitchell wrote:
> >>GCC 4.0.1 RC3 is now available here:
> >>
> >> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/
> >>
> >>With
[EMAIL PROTECTED] wrote:
I am currently working on a VM and would like to port gcc to it in order to
simplify the creation of software.
The VM simulates a processor with a stack pointer (SP), 16 General Purpose
Registers, Accumulator and built-in multitasking.
The instruction set is turing comp
Andreas Tobler wrote:
Darwin here:
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00221.html
Thanks.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Paul Brook wrote:
On Sunday 03 July 2005 19:21, Mark Mitchell wrote:
GCC 4.0.1 RC3 is now available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/
With luck, this will be the last 4.0.1 release candidate.
Please do download tarballs from the above URL and confirm that they
work
On Sunday 03 July 2005 19:21, Mark Mitchell wrote:
> GCC 4.0.1 RC3 is now available here:
>
>ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/
>
> With luck, this will be the last 4.0.1 release candidate.
>
> Please do download tarballs from the above URL and confirm that they
> work OK on y
I get this error compiling linux-2.6.11.3 with gcc-4.1-20050702 on many targets:
drivers/char/random.c: In function 'extract_entropy':
drivers/char/random.c:634: sorry, unimplemented: inlining failed in call to
'add_entropy_words': function not considered for inlining
drivers/char/random.c:1325:
On Tue, 2005-07-05 at 08:35 -0700, Mark Mitchell wrote:
> Daniel Berlin wrote:
>
> > 3. Not call layout_decl on the template types until they are completed.
>
> In the abstract, this is the best choice. Although we need to know that
> types are complete (which means (in the current implementati
The patch I am committing that makes the RTL passes be sequenced with
the pass manager, will also move init_tree_optimization_passes to
passes.c from tree-optimize.c. It is advisable that, before doing the
next merge to mainline on a tree that touches tree-optimize.c, you do
a diff between you
"Julio Garvia Honrado" <[EMAIL PROTECTED]> writes:
> I am trying to compile a C++ program (with cxx - Compaq compiler)
> that uses a C++ shared library (compiled with g++), but several
> 'unresolved' messages are reported.
>
> Is there any way to solve this incidence?
No, the two compilers are in
Gabriel Dos Reis wrote:
>| Sorry, I am not on the gcc team (I am working on constraint solvers rather
>| than compilers). I performed this review purely voluntarily.
>
>And it is clearly welcome! I hope more will follow :-)
>
>
Indeed.
However, sorry, as a matter of politeness, in my opinion e
Michael Veksler <[EMAIL PROTECTED]> writes:
[...]
| > 2. You don't know the answer. In that case you are supposed to file
| > a PR and trust bug-masters and maintainers about the issue.
| >
| > > std::tr1::hash is implemented in a very bad way.
| > > it casts double to size_t, which of co
> At the very least, we need a
> --disable-libssp option, if that doesn't already exist.
This also is needed for targets that do not support libssp. I
have had to disable building libssp on AIX using noconfigdirs because it
crashes the linker when building other libraries, I think becaus
Paolo Carlini <[EMAIL PROTECTED]> wrote on 05/07/2005 16:33:12:
> Michael Veksler wrote:
>
> >The behavior of the second run does not look right. What does it mean?
> >1. Is it forbidden by tr1 to define unordered_set ?
> >2. Is it a bug in the tr1 document (which should have forbidden this).
>
Daniel Berlin wrote:
3. Not call layout_decl on the template types until they are completed.
In the abstract, this is the best choice. Although we need to know that
types are complete (which means (in the current implementation) that
TYPE_SIZE != NULL_TREE), but the C++ front end should not
Daniel Jacobowitz wrote:
On Tue, Jul 05, 2005 at 03:27:23AM -0400, Jakub Jelinek wrote:
The problem is that libssp/configure contains a link test, but we may
not have crt0.o built yet (assuming targets like h8300-elf,
arm-none-eabi, etc).
DJ, can this be solved by toplevel Makefile.in's depen
Hi!
I'm facing a problem, that with code like
double sin(double);
double __attribute__((sseregparm)) (*mysin)(double) = sin;
double bar(double x)
{
return mysin(x);
}
we fail to recognize that mysin returns in %mm0 because ix86_value_regno
is only ever called with NULL func argument. We corre
hi,all
I don't know how to get the Nth argument stmt from CALL_EXPR stmt tree?
the GetCallArgOperands implement this function that i code ,but it
isn't working :(
thanks any advice or piece of example code .
//
[1st try appearantly did not get through - sorry if you get this twice]
Hi!
I'm facing a problem, that with code like
double sin(double);
double __attribute__((sseregparm)) (*mysin)(double) = sin;
double bar(double x)
{
return mysin(x);
}
we fail to recognize that mysin returns in %mm0 becaus
Hello,
I am trying to compile a C++ program (with cxx - Compaq compiler) that uses a
C++ shared
library (compiled with g++), but several 'unresolved' messages are reported.
Is there any way to solve this incidence?
Thanks in advanced,
Julio Garvía Honrado
-
I am currently working on a VM and would like to port gcc to it in order to
simplify the creation of software.
The VM simulates a processor with a stack pointer (SP), 16 General Purpose
Registers, Accumulator and built-in multitasking.
The instruction set is turing complete and implements stack,
Michael Veksler <[EMAIL PROTECTED]> writes:
| Hello,
|
| In previous discussions on rounding of double on x86 I wanted
| to find an example that points to the absurdity of current
| gcc behavior.
| At last I found such an example:
Thanks for investing time in this and reporting.
| t.cpp st
Michael Veksler wrote:
>The behavior of the second run does not look right. What does it mean?
>1. Is it forbidden by tr1 to define unordered_set ?
>2. Is it a bug in the tr1 document (which should have forbidden this).
>3. Is it OK to have repetitions in unordered_set?
>4. Is it a bug in gcc, for
On Tue, Jul 05, 2005 at 03:27:23AM -0400, Jakub Jelinek wrote:
> > The problem is that libssp/configure contains a link test, but we may
> > not have crt0.o built yet (assuming targets like h8300-elf,
> > arm-none-eabi, etc).
>
> DJ, can this be solved by toplevel Makefile.in's dependencies or
> l
Hello,
In previous discussions on rounding of double on x86 I wanted
to find an example that points to the absurdity of current
gcc behavior.
At last I found such an example:
t.cpp start ---
#include
#include
double x=3.0;
int main()
{
std::tr1::unordered_set myset;
myset.inser
Hello,
dwarf2out.c reads:
[...]
case CHAR_TYPE:
/* GNU Pascal/Ada CHAR type. Not used in C. */
if (TREE_UNSIGNED (type))
encoding = DW_ATE_unsigned_char;
else
encoding = DW_ATE_signed_char;
break;
[...]
The comment is wrong. In Ada, the tree code for
How difficult do you think this will be with the new toplevel
bootstrap?
Make gcjx depend on libstdc++-v3, and add "bootstrap=true" to both in
Makefile.def. In cp/Make-lang.in, set boot_language=yes. It should
just work.
Paolo
Original Message
>From: Ian Lance Taylor
>Sent: 04 July 2005 20:29
> "Sung-Gu" <[EMAIL PROTECTED]> writes:
>
>> I thought I might find a specfic directory in gcc sources whether it
>> supports the files. I don't want to compile the whole source files. :(
>
> gcc is just the compiler. He
This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22212
and is the problem blocking Ada bootstrap on x86_64-linux,
it would be great to move forward on this.
Laurent
On Thu, 2005-06-30 at 18:18 -0400, Richard Kenner wrote:
> This function generates RTL from an expression to see how many RTL ins
On Mon, Jul 04, 2005 at 09:50:08PM -0700, Kazu Hirata wrote:
> I am having a trouble with libssp in one-tree builds. That is, if I
> try to build binutils and gcc at the same time, libssp/configure
> complains while compiling (and linking) the following program and the
> build process stops.
>
>
Thanks for the info.
Any one knows a pubic or a private porting of GCC to MIPS-X??? Any
help would be greatly appeciated.
Thanks in advance.
IM
On 7/5/05, Richard Sandiford <[EMAIL PROTECTED]> wrote:
> "IM.Nobody" <[EMAIL PROTECTED]> writes:
> > I am wondering if MIPS-X has been supported.
>
>
68 matches
Mail list logo
