At the outset I would like to thank you all for the
excellent work that you are rendering to the UNIX
community.
I am getting some error while I am building GCC 4.0.2
on AIX 5.3 ML-03
I have tried to bootstrap GCC 4.0.2 with
a) gcc 3.4.5 successfully built on AIX 5. 3 ML-03
Note:
Hi Dan,
On Wed, 7 Dec 2005, Daniel Berlin wrote:
> This is *already* wrong, AFAICT, because reg:QI 58 is uninitialized, and
> we are trying to use it's value. Why do we do this?
This may have been a rhetorical question, but the middle-end's RTL
expanders are generating uses of uninitialized reg
This case looks like this:
typedef struct
{
unsigned char a : 2;
unsigned char b : 3;
unsigned char c : 1;
unsigned char d : 1;
unsigned char e : 1;
} a_struct;
foo (flags)
a_struct *flags;
{
return (flags->c != 0
|| flags->d != 1
|| flags->e != 1
unsubscribe
unsubscribe
Volker Reichelt wrote:
> Shouldn't we fold cp_parser_declarator_id into the caller and call
> cp_parser_id_expression directly?
Originally, I was trying to have a function for each non-terminal. I'm
not going to be dogmatic about that, but is there a good reason to
remove the function? As Gaby
On Thursday 08 December 2005 00:52, DJ Delorie wrote:
> > > The "-1" sentinal used for CTOR_LIST is not a representable address,
> > > and the code gcc ends up using compares 0x (the -1) with
> > > 0x00ff (what ends up in $a0) and it doesn't match.
> > >
> > > Suggestions?
> >
> > Use E
You don't need to also send email to [EMAIL PROTECTED]
On Dec 7, 2005, at 2:54 PM, JongMin Han wrote:
1. Process :
How does new Project about target or optimization create?
Roughly speaking,
You do up the legal paper work to assign copyright,
You write the code,
then you contribute it (mai
> > The "-1" sentinal used for CTOR_LIST is not a representable address,
> > and the code gcc ends up using compares 0x (the -1) with
> > 0x00ff (what ends up in $a0) and it doesn't match.
> >
> > Suggestions?
>
> Use ELF .init_array/.fini_array
I got distracted trying to support thi
Morten Welinder wrote:
>>>This is a joke, you are kidding, right ?
>>
>>No, we're not kidding. RTFM: Section, 5.12 Arrays of Length Zero
>
>
> He is kind of right, though. Outside struct (or perhaps union),
> zero-sized arrays
> make little sense and could be rejected. Or else I am missing som
> "Florian" == Florian Weimer <[EMAIL PROTECTED]> writes:
Florian> Java implementations needs to solve pretty much the same
Florian> problem. How is it done in GCJ?
When printing a stack trace we exec addr2line if it is available.
This is optional though, there is a system property you can s
Hi, My name is JongMin Han.
I have been concerned about GCC. So, I hope to study about GCC.
By good luck, I have a chance to study about gcc. Currently My Lab
is carrying out a feasibility study on gcc.
So, I want to know the following
1. Process :
How does new Project about target or optimiz
* Andrew Haley:
> > Java implementations needs to solve pretty much the same problem. How
> > is it done in GCJ?
>
> Every Java class has full reflection data for all of its methods.
> Given the address of a method, therefore, it's a straightforward
> reverse lookup to get the name.
It seems t
On Wed, Dec 07, 2005 at 11:43:31PM +0200, Michael Veksler wrote:
> Quoting Richard Guenther <[EMAIL PROTECTED]>:
>
> > On 12/7/05, Morten Welinder <[EMAIL PROTECTED]> wrote:
> > > He is kind of right, though. Outside struct (or perhaps union),
> > > zero-sized arrays
> > > make little sense and c
Quoting Richard Guenther <[EMAIL PROTECTED]>:
> On 12/7/05, Morten Welinder <[EMAIL PROTECTED]> wrote:
> > He is kind of right, though. Outside struct (or perhaps union),
> > zero-sized arrays
> > make little sense and could be rejected. Or else I am missing something
> too.
>
> Well, as nearly
In gcc-3.3, the -finline-limit had little effect. You could turn
that knob all you wanted, and code size didn't change much. In
gcc-4.0, the inliner's both better, and (I think) the meaning of the
number with -finline-limit changed. As a result, the -finline-limit
has a much bigger effec
On 12/7/05, Morten Welinder <[EMAIL PROTECTED]> wrote:
> >> This is a joke, you are kidding, right ?
> > No, we're not kidding. RTFM: Section, 5.12 Arrays of Length Zero
>
> He is kind of right, though. Outside struct (or perhaps union),
> zero-sized arrays
> make little sense and could be reject
>> This is a joke, you are kidding, right ?
> No, we're not kidding. RTFM: Section, 5.12 Arrays of Length Zero
He is kind of right, though. Outside struct (or perhaps union),
zero-sized arrays
make little sense and could be rejected. Or else I am missing something too.
M.
libaddr2line used to be a proprietary library distributed by AdaCore
only. (I'm not sure if it was intentionally proprietary.)
As far as I know, it's just the binutils addr2line with a tiny patch/wrapper.
Certainly covered the by GPL, not proprietary.
Florian Weimer writes:
> * David Gressett:
>
> > It does work with the GNAT GPL 2005 that I have on my XP box at home. A
> > search of the gcc mailing list archive didn't turn up much, but there
> > was one message which indicated that there was a license problem with
> > the addr2line so
* David Gressett:
> It does work with the GNAT GPL 2005 that I have on my XP box at home. A
> search of the gcc mailing list archive didn't turn up much, but there
> was one message which indicated that there was a license problem with
> the addr2line source code that the Ada Core people were
Tommy Vercetti writes:
>
> On 2005-12-07, at 16:26, Richard Guenther wrote:
>
> > On 12/7/05, Tommy Vercetti <[EMAIL PROTECTED]> wrote:
> >> Hi there
> >>
> >> We had funny issue here lately. Someone wanted to create table that
> >> had 0 elements in C++, for instance this code:
> >
> >
On 2005-12-07, at 16:26, Richard Guenther wrote:
On 12/7/05, Tommy Vercetti <[EMAIL PROTECTED]> wrote:
Hi there
We had funny issue here lately. Someone wanted to create table that
had 0 elements in C++, for instance this code:
This is a gcc extension. Try g++ -pedantic
This is a joke, yo
This is an update to
http://gcc.gnu.org/ml/gcc/2005-12/msg7.html
As in the previous round, please consider every weekly snapshot from
gcc-3_4-branch as a release candidate for testing.
Schedule:
The tentative release date is end of February 2006.
I'll make official prerelease tarb
What is the status of GNAT.Traceback.Symbolic? I have gcc 4.0.1 20050727
(Red Hat 4.0.1-5) on my Fedora C4 system, and gcc 3.4.2 (mingw-special)
and gcc 3.4.5 on my Windows 2000 system. In all 3 of these, the source
code comments in g-trasym.ads indicate that symbolic traceback doesn't
work on
I'm pleased to announce that GCC 3.4.5 has been released.
This version is a minor release, from the 3.4.x series, fixing
regressions with respect to previous versions of GCC. It can be
downloaded from the FTP servers listed here
http://www.gnu.org/order/ftp.html
A list of known fixed b
Steven L. Zook wrote:
I guess what I don't understand is why struct A isn't POD. A reference
to something is basically just a pointer. It has no alignment
restrictions that a pointer wouldn't.
a reference type is not a pod type because the language says so.
nathan
--
Nathan Sidwell:: ht
Jan Beulich wrote:
Why? It's broken. You just cannot embed something that requires
alignment into something that doesn't guarantee alignment, except that
for built-in types, the compiler can synthesize the necessary splitting,
but Foo's assignment operator, in your example, may be totally unawa
On 7 Dec, Nathan Sidwell wrote:
> Gabriel Dos Reis wrote:
>
>> If we make it "static inline", would not we gain the same efficiency
>> and preserve the comments and all that? In general, the methodoly
>> seems to have a function for each non-terminal -- following a long
>> tradition of recursive
>Just for the record (in case someone else has the same thoughts)
>and because I'd already written most of the reply, I also
>replied to your first email. See last for your follow-up.
>
>> What has the alignment of type 'long long' to do with structure
>> packing?
>
>Only the obvious(?): if long l
I bootstrapped and regtested 4.1 on powerpc-apple-darwin8.3.0 and
there were so many errors with -mcpu=970 -m64 that the gcc mail
daemon wouldn't accept the summary. So I put it at
http://www.math.purdue.edu/~lucier/gcc/test-results/4_1-12-06-2005.gz
The most serious problems seem to be in
> Date: Wed, 07 Dec 2005 09:18:53 +0100
> From: "Jan Beulich" <[EMAIL PROTECTED]>
Just for the record (in case someone else has the same thoughts)
and because I'd already written most of the reply, I also
replied to your first email. See last for your follow-up.
> What has the alignment of type
I guess what I don't understand is why struct A isn't POD. A reference
to something is basically just a pointer. It has no alignment
restrictions that a pointer wouldn't.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Nathan Sidwell
Sent: Wednesday, Decem
>>> Nathan Sidwell <[EMAIL PROTECTED]> 07.12.05 17:22:10 >>>
>Jan Beulich wrote:
>
>> And that is precisely the reason why I think binding a reference to
the
>> whole object or any of its members, when the object itself is a
member
>> of a packed object, is illegal, hence requiring a diagnostic
(un
Jan Beulich wrote:
And that is precisely the reason why I think binding a reference to the
whole object or any of its members, when the object itself is a member
of a packed object, is illegal, hence requiring a diagnostic (unless,
like for both other cases, the default is to pack structures).
>>> Nathan Sidwell <[EMAIL PROTECTED]> 07.12.05 16:58:11 >>>
>Jan Beulich wrote:
>> This test contains three invocations of Ref(), but only two of them
are
>> considered ill. What I'd like to get an explanation for is why the
third
>> (middle) instance is considered correct. After all, the u member
Steven L. Zook wrote:
When I compile this using gcc rev 3.4.5 (m68k-elf):
struct A { charB;
unsigned char & C; } __attribute__((packed));
unsigned char D;
A E = { 'F', D };
I get:
testpp.cpp:2: warning: ignoring packed attribute on unpacked non-POD
field `unsigned char&A
Gabriel Dos Reis wrote:
If we make it "static inline", would not we gain the same efficiency
and preserve the comments and all that? In general, the methodoly
seems to have a function for each non-terminal -- following a long
tradition of recursive descent parser -- and maintaining that
princip
Jan Beulich wrote:
This test contains three invocations of Ref(), but only two of them are
considered ill. What I'd like to get an explanation for is why the third
(middle) instance is considered correct. After all, the u member of
Packed is packed, and hence all the members of Unpacked in that c
On 12/7/05, Tommy Vercetti <[EMAIL PROTECTED]> wrote:
> Hi there
>
> We had funny issue here lately. Someone wanted to create table that
> had 0 elements in C++, for instance this code:
This is a gcc extension. Try g++ -pedantic
Richard.
> int main()
> {
> char a[0];
> char b[
Hi there
We had funny issue here lately. Someone wanted to create table that
had 0 elements in C++, for instance this code:
int main()
{
char a[0];
char b[0];
a[0] = 1;
b[0] = 2;
return a[0] + b[0];
}
is perfectly ok for g++, it isn't for other compi
>
> The used compile options are:
>
> ...
> -ftree-vectorize
I don't know how much vectorization takes place in your code, but
vectorization would currently greedily increase code size (i.e. without
trying to estimate when it is profitable). One way to avoid some of the
code size growth during vec
On 12/7/05, Andreas Killaitis <[EMAIL PROTECTED]> wrote:
> Hello list,
>
> I have a question concerning the size of the code generated by gcc
> 4.0.2 and 4.1.
> We talk about a C++ app with many smaller (30k) or larger (4M) C++
> libraries.
> Being happy the size of those libs decreased by about 20
>> While most of these changes appear to be correct, I see a regression
on
>> *-*-netware* (which by default uses packed structures) in
>> gcc.dg/20030321-1.c, and I believe the warning tested for cannot be
>> expected (since the code generating the warning tests
>>
>> TYPE_ALIGN (TREE_TYPE (*node
>> While most of these changes appear to be correct, I see a regression
on
>> *-*-netware* (which by default uses packed structures) in
>> gcc.dg/20030321-1.c, and I believe the warning tested for cannot be
>> expected (since the code generating the warning tests
>>
>> TYPE_ALIGN (TREE_TYPE (*node
45 matches
Mail list logo
