Hi,
On Sun, Mar 13, 2005 at 03:01:00PM +0200, Kai Henningsen wrote:
> Most of the rest of the error handling in this project is concerned with
> the absence of the feature I loved in the IBM PL/I compilers under the
> name "SNAP;" - putting out a stack backtrace (the usual idiom for abort()
On Tue, 2005-03-15 at 09:59, Clifford Wolf wrote:
> Hi,
>
> On Sun, Mar 13, 2005 at 03:01:00PM +0200, Kai Henningsen wrote:
> > Most of the rest of the error handling in this project is concerned with
> > the absence of the feature I loved in the IBM PL/I compilers under the
> > name "SNAP;" -
Hi,
On Fri, Mar 11, 2005 at 03:28:19PM -0500, Richard Stallman wrote:
> Currently, I believe, GCC combines various calls to abort in a single
> function, because it knows that none of them returns.
afaics it is more generic. It merges them because it knows that it doesn't
make any difference. Thi
Consider the following:
static inline int a() __attribute((always_inline));
static inline int b() __attribute((always_inline));
static inline int b() { a(); }
static inline int a() { }
int c() { b(); }
This compiles fine at -O2. At -O0 we get the baffling error
sorry, unimplemented: inlining fai
Dale Johannesen <[EMAIL PROTECTED]> writes:
> Consider the following:
>
> static inline int a() __attribute((always_inline));
> static inline int b() __attribute((always_inline));
>
> static inline int b() { a(); }
> static inline int a() { }
> int c() { b(); }
>
> This compiles fine at -O2. At -
With or without cross-jumping, when the developer gets a
report from a user that "the program died with an abort", he or she has to
debug from scratch, only to find out in many cases that it's a known bug,
already fixed in CVS for the next release, information that would have
On Mar 15, 2005, at 10:32 AM, Zack Weinberg wrote:
Dale Johannesen <[EMAIL PROTECTED]> writes:
Consider the following:
static inline int a() __attribute((always_inline));
static inline int b() __attribute((always_inline));
static inline int b() { a(); }
static inline int a() { }
int c() { b(); }
Th
However, the idea that users could search for previous bug reports is
new to me. That might be an additional reason for using fancy_abort.
It's not just users, but first level tech-support. There, it can help
in suggesting a workaround to the user and knowing which file the abort
is in m
Dale Johannesen <[EMAIL PROTECTED]> writes:
>>> It seems undesirable for -O options to affect which programs will
>>> compile.
>>
>> Agreed. Perhaps we should run the inliner at -O0 if we see
>> always_inline attributes, just for those functions?
>
> We do; the problem is that it makes only 1 pas
Original Message
>From: Richard Stallman
>Sent: 15 March 2005 18:39
> Nonetheless, GCC may as well still stop cross-jumping abort calls.
> There's nothing to lose
There *is* something to lose: memory space. Lots of people use gcc to
develop for deeply embedded systems, where memory res
> What we might want to do is provide an option to disable all such
> optimizations.
>
We have had enough requests for -Odebug or something like that.
Probably could be just dce, ccp, and a couple of other optimizations...
-eric
On Mar 14, 2005, Eric Christopher <[EMAIL PROTECTED]> wrote:
>> > Now, I wouldn't object to hacking GCC to avoid cross-jumping calls to
>> > abort. It's just that I don't think that the common GNU use of abort
>> > serves the users.
>> Agreed. And as someone suggested, rather than treating abort
On Sat, 2005-03-12 at 21:00, feng qiu wrote:
> Is it difficult to modify the gcc sources if I want to use the both?
The tricky part might be defining what it means. There are at least 4
interacting features here, #pragma pack, attribute ((packed)), attribute
((aligned(X)), and -fpack-struct. Cur
Sam Lauber wrote:
The gccinstall info says that `make uninstall' would open
a can of worms. I don't get it. Why?
The same paragraph gives one explanation. Gcc includes shared
libraries. If you uninstall a copy of gcc, then everything compiled
with that gcc will suddenly stop working (ignoring
Rajesh Babu wrote:
I am working with gcc-3.3.3, and I want to insert my module after
construction of AST and before RTL generation.
gcc-3.3 is not interesting for work like this. This stuff has already
been obsoleted in current gcc sources. But if you insist on using out
dated sources, look at
Rajesh Babu wrote:
I found that PRE is not done in gcc-3.3.3, though the code for doing
PRE exists in source code.
gcc-3.3 is not interesting for work like this. The PRE support in
gcc-3.3 has already been effectively obsoleted by other work in current
gcc sources, though it is still there.
BUG DETECTED==+
| 4.1.0 20050315 (experimental) (sparc-unknown-linux-gnu) internal error |
| No source file position information available|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line
This patch fixes a g++ ICE for me that depends on inlining limits. (I
have Richard's short patch to modify estimate_num_insns installed)
The file contains lots of virtual public inheritance and covariant
returns. I don't know if this patch fixes though, or just hides it,
since changing the in
邹琼 wrote:
> ../../../source/gcc-4.0-20050109/gcc/config/rs6000/darwin.md:243:
> unknown mode `V4SI'
That is a snapshot that is over two months old. Snapshots are
unsupported, and have a lifetime of less than a week, so this has been
obsolete for almost 2 months now. If there is a problem here, i
> This program should generate an error; it's illogical. If the alignment
> of the element is greater than the element size, then arrays of such a
> type should be disallowed. Otherwise, stuff in either the compiler or
> the program itself could make the justified assumption that things of
>
Hi,
in March 2004 we added to many libstdc++-v3 testcases lines similar to
#if !__GXX_WEAK__ && _MT_ALLOCATOR_H
// Explicitly instantiate for systems with no COMDAT or weak support.
template class __gnu_cxx::__mt_alloc >;
#endif
AFAIK, only in order to avoid spurious failures on darwin.
I'd like to
Steve Ellcey wrote:
Most of the gcc.dg/vect/* tests contain something like:
typedef float afloat __attribute__ ((__aligned__(16)));
afloat a[N];
It looks like what is really intended here is to apply the alignment to
the array type. The point is that the entire array has to be
ap
Paolo Carlini <[EMAIL PROTECTED]> writes:
> Hi,
>
> in March 2004 we added to many libstdc++-v3 testcases lines similar to
>
> #if !__GXX_WEAK__ && _MT_ALLOCATOR_H
> // Explicitly instantiate for systems with no COMDAT or weak support.
> template class __gnu_cxx::__mt_alloc >;
> #endif
>
> AFAI
Geoffrey Keating wrote:
Darwin now has weak/comdat support, so it doesn't need or use this any more.
Ah, great, I suspected that...
However, AIX does need them, I think.
Humpf, forgot AIX! David Edelsohn?!?
Thanks,
Paolo.
> > The gcc.dg/compat/struct-layout problems seem to stem from
> > struct-layout-1_generate.c. In generate_fields() it generates random
> > types, some of these are arrays of some base type. Then based on
> > another random number we might add an attribute like alignment. There
> > is no check t
On Tue, Mar 15, 2005 at 04:42:03PM -0800, Steve Ellcey wrote:
> The simplest solution would probably be to ignore __aligned__ attributes
> completely when we have an array. Or to do the change you suggested for
> the vector tests and have the attribute attached to the array and not
> the element t
Joe Buck wrote:
On Tue, Mar 15, 2005 at 04:42:03PM -0800, Steve Ellcey wrote:
The simplest solution would probably be to ignore __aligned__ attributes
completely when we have an array. Or to do the change you suggested for
the vector tests and have the attribute attached to the array and not
the e
On Mar 15, 2005, at 7:35 PM, Paolo Carlini wrote:
Geoffrey Keating wrote:
Darwin now has weak/comdat support, so it doesn't need or use this
any more.
Ah, great, I suspected that...
However, AIX does need them, I think.
Humpf, forgot AIX! David Edelsohn?!?
There are other targets other than aix t
Andrew Pinski wrote:
There are other targets other than aix that still need them too.
Almost all non elf targets (and there might be some elf targets too).
AIX 5.1 supports weak symbols (IIRC) and should work without the "hack"
but older AIX still should be supported.
Thanks Andrew for the info. Wh
On Mar 15, 2005, at 8:01 PM, Paolo Carlini wrote:
Andrew Pinski wrote:
There are other targets other than aix that still need them too.
Almost all non elf targets (and there might be some elf targets too).
AIX 5.1 supports weak symbols (IIRC) and should work without the
"hack"
but older AIX still
"Dave Korn" <[EMAIL PROTECTED]> writes:
> I very strongly feel that this optimisation should be placed under user
> control rather than just disabled, and that it should remain enabled by
> default at -Os; but I wouldn't go to the ropes over whether or not it's
> included in -Os as long as there'
> Paolo Carlini writes:
>> However, AIX does need them, I think.
>>
Paolo> Humpf, forgot AIX! David Edelsohn?!?
AIX probably needs this support indefinitely. If I remember
correctly, the new allocator does not work on AIX due to ELF-like
assumptions about the order of global constru
> http://gcc.gnu.org/gcc-4.1/changes.html
>
> New Languages and Language specific improvements
> C and Objective-C
>
> * The old Bison-based C and Objective-C parser has been replaced
> by a new, faster hand-written recursive-descent parser.
Hahahahaha, WRONG!!
It's one historical error
Richard Kenner <[EMAIL PROTECTED]> wrote:
> However, the idea that users could search for previous bug
> reports is new to me. That might be an additional reason for
> using fancy_abort.
>
> It's not just users, but first level tech-support. There, it can help
> in suggesting a workaroun
On Wed, Mar 16, 2005 at 02:41:12AM +0100, [EMAIL PROTECTED] wrote:
> > http://gcc.gnu.org/gcc-4.1/changes.html
> >
> > New Languages and Language specific improvements
> > C and Objective-C
> >
> > * The old Bison-based C and Objective-C parser has been replaced
> > by a new, faster hand-wri
> The best option is a clean grammar in Yacc/Bison!.
GCC had such parsers for over a decade, and yet they are being replaced.
Bison remains a good solution in many cases, especially for languages
specifically designed to be easy to parse with an LALR parser (that is,
languages
| > > http://gcc.gnu.org/gcc-4.1/changes.html
| > >
| > > New Languages and Language specific improvements
| > > C and Objective-C
| > >
| > > * The old Bison-based C and Objective-C parser has been replaced
| > > by a new, faster hand-written recursive-descent parser.
| >
| > Hahahahaha, W
On Wed, Mar 16, 2005 at 03:22:26AM +0100, [EMAIL PROTECTED] wrote:
> Do you demonstrate that "C++ is not LALR(1)"?
I'll leave that to you as a homework assignment. Actually, C++ is not
LALR(N) for any N. Get out the C++ grammar and figure it out, it's an
easy proof. Come back when you have prov
kill these bits, for a couple of reasons. One, I
don't know if they are necessary when using mt_alloc circa 20050315. I'm
thinking that they are not, just due to design changes. Two, mt_alloc is
not the default allocator for darwin, or for other platforms that are
hostile to weak symbols.
| > Do you demonstrate that "C++ is not LALR(1)"?
|
| I'll leave that to you as a homework assignment. Actually, C++ is not
| LALR(N) for any N. Get out the C++ grammar and figure it out, it's an
| easy proof. Come back when you have proved it to your own satisfaction,
| and please refrain from
i am studing RTL that is gcc front-end
insn RTX has seven elements
ex) (insn id prev next pattern code log_links reg_notes)
(insn 12 10 14 (set (reg:QI 12 A0) (reg:QI 1 R1) -1 (nil) (nil))
where i get the impormation about code, log_links,
reg_notes---
On Wed, 2005-03-16 at 04:56 +0100, [EMAIL PROTECTED]
> | > | Bison remains a good solution in many cases, especially for languages
> | > | specifically designed to be easy to parse with an LALR parser (that is,
> | > | languages that don't look like C).
> | >
> | > Why don't we develop a "LR(k) /
On Tue, 2005-03-15 at 23:41 -0500, Daniel Berlin wrote:
> On Wed, 2005-03-16 at 04:56 +0100, [EMAIL PROTECTED]
> > | > | Bison remains a good solution in many cases, especially for languages
> > | > | specifically designed to be easy to parse with an LALR parser (that
> > is,
> > | > | languages
[EMAIL PROTECTED] writes:
> | > Do you demonstrate that "C++ is not LALR(1)"?
> |
> | I'll leave that to you as a homework assignment. Actually, C++ is not
> | LALR(N) for any N.
Nor is it LR(N) nor LL(N).
> | Get out the C++ grammar and figure it out, it's an easy proof.
> | Come back when y
| > It's possible that C++ doesn't require unbounded lookahead
|
| No, it's not.
| In fact, if you'd read the language grammar definition, you'd discover
| you could pretty produce the anti-program with some work.
| That given any k, it produces a C++ program that cannot be parsed with
| an LR(k) p
| > | > Do you demonstrate that "C++ is not LALR(1)"?
| > |
| > | I'll leave that to you as a homework assignment. Actually, C++ is not
| > | LALR(N) for any N.
|
| Nor is it LR(N) nor LL(N).
|
| > | Get out the C++ grammar and figure it out, it's an easy proof.
| > | Come back when you have pro
| > | > Do you demonstrate that "C++ is not LALR(1)"?
| > |
| > | I'll leave that to you as a homework assignment. Actually, C++ is not
| > | LALR(N) for any N.
|
| Nor is it LR(N) nor LL(N).
|
| > | Get out the C++ grammar and figure it out, it's an easy proof.
| > | Come back when you have pro
The following paper provides some background on the difficulties
encountered with parsing C++:
http://citeseer.ist.psu.edu/irwin01generated.html
Abstract: C++ is an extraordinarily difficult programming language to parse.
The language cannot readily be approximated with an LL
or LR grammar (re
Hi,
I'm writing a new gcc port, and having problems making reload work.
Say I've got a mov instruction that only works via an accumulator A, and
a two-operand add instruction. "r" regclass includes regs A,X,Y, and
"a" regclass only includes reg A.
So mov has constraints like: 0 = "g,a" 1 = "
> stage1/xgcc -Bstage1/ -B/usr/local/sparc-linux/bin/ -c -g -O2
> -gnatpg -gnata -g -O1 -fno-inline \
> -I- -I. -Iada -I/usr/local/src/trunk/gcc/gcc/ada
> /usr/local/src/trunk/gcc/gcc/ada/a-except.adb -o ada/a-except.o
> unhandled expression in get_expr_operands():
>
This is fixed.
--
Eric Bo
50 matches
Mail list logo
