Snapshot gcc-4.0-20051006 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20051006/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20051006
You'll
On Oct 6, 2005, at 2:44 AM, Michael Veksler wrote:
This is the wrong list for linker enhancements. You should look for
binutils mailing lists. However "collect2" which is part of gcc and is
called before the linker (for C++)- could also detect this and give
the same warning. I would bet that coll
On Oct 6, 2005, at 4:22 PM, Olivier Hainque wrote:
Daniel Berlin wrote:
IOW, you are lying to the middle-end about the size of the fields.
Why is the type not a 6 bit integer?
layout_decl (tree decl, unsigned int known_align)
...
/* Usually the size and mode come from the data type
On Thu, Oct 06, 2005 at 10:22:08PM +0200, Olivier Hainque wrote:
> Because we avoid creating a different type for every possible
> bitsize...
...
> The C front-end behaves similarily, creating
...
> precision 3 min max >
^^^
Actually, we did create a different type just f
Daniel Berlin wrote:
> IOW, you are lying to the middle-end about the size of the fields.
> Why is the type not a 6 bit integer?
Because we avoid creating a different type for every possible
bitsize, which seems to be the purpose of DECL_SIZE in the
first place and is explicitly expected by the
On Oct 6, 2005, at 12:00 PM, Olivier Hainque wrote:
Hello,
The Ada testcase below, compiled with -O2 on x86-linux, triggers a
SEGV in the current mainline compiler, there:
do_simple_structure_copy
{ ...
for (; p && p->offset < last; p = p->next)
{ ...
q = first_vi_f
Hello,
The Ada testcase below, compiled with -O2 on x86-linux, triggers a
SEGV in the current mainline compiler, there:
do_simple_structure_copy
{ ...
for (; p && p->offset < last; p = p->next)
{ ...
q = first_vi_for_offset (q, q->offset + fieldoffset);
==>temprh
Hi DJ,
finally, I could try your proposal with the reset.S file. It works fine
in the KD30 debugger, but unfortunately, the program doesn't run when I
flash the srec directly.
Do you have an idea on what's going wrong?
Frank
References:
http://gcc.gnu.org/ml/gcc/2005-09/msg00067.html
http://
Michael Veksler wrote:
Why do you think that this would be a mistake?
(you in the above is dewar)
Michael has exactly stated my reasons :-)
>>> Wolfgang Roemer <[EMAIL PROTECTED]> 06.10.05 16:02:37 >>>
>On Thu Oct 06, 2005 15:54, Michael Veksler wrote:
>[..]
>>> 2. I think that it will break C. As I remember, it is sometimes
>>> legal in C (or in some dialects of C) to have conflicting
types.
>>> You may define in one transl
This branch contains the work Ken Zadeck and I have been doing
replacing the backend dataflow (such as live register analysis) with
df.c based dataflow.
It currently bootstraps on x86-linux-gnu, and powerpc-linux-gnu, and
powerpc-darwin.
Currently, reg-stack doesn't like accurate liveness
Hello Michael,
On Thu Oct 06, 2005 15:54, Michael Veksler wrote:
[..]
>> 2. I think that it will break C. As I remember, it is sometimes
>> legal in C (or in some dialects of C) to have conflicting types.
>> You may define in one translation unit:
>> char var[5];
>> and the
Wolfgang Roemer wrote on 06/10/2005 16:14:03:
> On Thu Oct 06, 2005 14:50, Robert Dewar wrote:
> >> [..]
> >>
> >> I actually disagree with this, I think attempting to make the link
fail
> >> here would be a mistake.
>
> Why do you think that this would be a mistake?
>
I agree with Robert,
I don't think this has anything to do with binutils; whether linking
succeeds exclusively depends on the mangling method used (VC does mangle
data object names, while g++ doesn't). AFAIK the standard only talks
about function signatures, meaning mangling data object names is neither
prohibited nor
Ian Lance Taylor writes:
> This kind of error generally means that the operand predicate accepts
> an operand which no constraint matches. If the predicate (e.g.,
> register_operand) accepts an operand, then there must be a constraint
> that matches it. Otherwise you will get an error in
> const
On Thu Oct 06, 2005 14:50, Robert Dewar wrote:
>> [..]
>>
>> I actually disagree with this, I think attempting to make the link fail
>> here would be a mistake.
Why do you think that this would be a mistake?
WR
Wolfgang Roemer wrote:
The main.o will perfectly link with the library although main.o needs a double
variable named maximum and the lib only offers an int variable named maximum.
Because the symbol name does in no way reflect the variable type, everything
links fine but in fact the variable n
Hello,
I encountered a subtle SEGV in a program and was able to track the problem
down to symbol names concerning global/extern variables. I discussed that
with some guys from the GCC project (see recipient list) and we came to the
conclusion it would make more sense to share our thoughts with
Wolfgang Roemer wrote:
Hello,
so it seems as if it would be best if I post that to the binutils mailing
list. Agreed?
Indeed. This is not a simple change, but it would make a nice
well defined project for someone to work on!
> It sounds as if the symbol is still "maximum" and it is annotate
Hello,
so it seems as if it would be best if I post that to the binutils mailing
list. Agreed?
WR
On Thu Oct 06, 2005 11:57, Robert Dewar wrote:
>> Michael Veksler wrote:
>> > It sounds as if the symbol is still "maximum" and it is annotated with
>> > its type (something like debug informati
Michael Veksler wrote:
It sounds as if the symbol is still "maximum" and it is annotated with
its type (something like debug information). I should be possible to
hack the linker to emit a warning for symbols with conflicting debug
information.
Nice idea!
This is the wrong list for linker en
Wolfgang Roemer wrote on 06/10/2005 12:03:39:
> Hello Michael,
>
> first of all: Thanks for the fast reply!
>
> On Thu Oct 06, 2005 10:33, you wrote:
> >> [..]
> >>
> >> It's a feature. It is undefined behavior to have conflicting
declarations
> >> in different translation units.
> >> [...]
Hello Michael,
first of all: Thanks for the fast reply!
On Thu Oct 06, 2005 10:33, you wrote:
>> [..]
>>
>> It's a feature. It is undefined behavior to have conflicting declarations
>> in different translation units.
>> [...]
Well, but shouldn't there at least be a warning during linking!?
>
Wolfgang Roemer wrote on 06/10/2005 10:52:35:
>
> I don't know whether it is a bug or feature and I searched through the
mailing
> lists without success therefor I write my question this way:
>
> If you have a global variable inside a cpp file and create a library out
of
> that, the symbol name
Hello,
I don't know whether it is a bug or feature and I searched through the mailing
lists without success therefor I write my question this way:
If you have a global variable inside a cpp file and create a library out of
that, the symbol name for that global variable does in no way take the
25 matches
Mail list logo
