Re: Merging calls to `abort'
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()
> was "SNAP; STOP;" IIRC). Now *that* would be a useful feature to have.
It is there: __builtin_return_address(n)
I have a small example of how to use that on my homepage:
http://www.clifford.at/cfun/elfstuff/backtrace.c
This example is using the ELF dladdr() function - so it can only resolve
symbols in a .so file - not in the main program. (I think it works if the
main program is compiled with -rdynamic - but I didn't check that).
I hope that helps.
yours,
- clifford
--
_ __ __ $_ = q 7nz!y="Ccv'Dpgiutvcbb'oj'Pocj'*'qqq[
/ ___/ __ \/ __ `/ | /| / / ej`q[iv`";!|=1;!y=~t%].[%nz!z=!1;gps]1..6[{
/ /__/ / / / /_/ /| |/ |/ / qsjou"!z\c";tfmfdu]voefg,voefg,voefg,0.05[;
\___/_/ /_/\__, / |__/|__/!z=~t/].[/dis]pse]!1[^!_[/fh;}qsjou !z;%fh;
CCC Wien //www.cngw.org qsjou "\o"7;s/\n//g;y/[b-za]!/)a-z($/;eval;
Unix is the answer, but only if you phrase the question very carefully.
pgpWZjTpDIdF3.pgp
Description: PGP signature
Re: Merging calls to `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;" - putting out a stack backtrace (the usual idiom for abort() > > was "SNAP; STOP;" IIRC). Now *that* would be a useful feature to have. > > It is there: __builtin_return_address(n) > > I have a small example of how to use that on my homepage: > > http://www.clifford.at/cfun/elfstuff/backtrace.c > > This example is using the ELF dladdr() function - so it can only resolve > symbols in a .so file - not in the main program. (I think it works if the > main program is compiled with -rdynamic - but I didn't check that). > > I hope that helps. I doubt it will, because most platforms don't support __builtin_return_address(n) for any value of n other than 0. On modern machines it's generally impossible to unwind the stack frame without comprehensive unwind tables. R.
Re: Merging calls to `abort'
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. This is a "problem" we always will have when debugging
optimized programs and has nothing to do with the abort() function as it
is. E.g.:
#include
int main(int argc)
{
char str[] = "Howdy!";
if (argc > 1) {
printf("Got arguments.\n");
puts(str);
} else {
printf("Got no arguments.\n");
puts(str);
}
return 0;
}
When compiled with -Os, the compiler will only generate two function calls.
In the printf-case it is possible to distinguish by looking at the
parameter, in the puts case there is no way of distinguishing if we are in
the `if' or in the `else' branch..
(when compiled with -fno-crossjumping everything is clear again)
> If the goal is simply to make the compiled code as small as possible,
> this is the way to do it.
That's what the user is telling gcc when he is calling the compiler with
-Os. One great thing of free software is it doesn't try to `patronize' its
users. Please do not let us start with that now..
As statet already, the abort information is pretty useless when the binary
is compiled without debug symbols. And usually the `production binaries'
shipped by distributors are built without debug symbols. So you would need
to rebuild with debug symbols anyways - why not just rebuilding without
optimization too when that is what one actually wants to do?
The fancy_abort() function someone suggested in the other mail always
works. And if the author of the software has developed a personal procedure
for looking into problems where a fancy_abort() isn't very helpfull (and it
looks like you did - but that doesn't mean automatically that everyone is
using this strategy for debugging software) then we are still confronted
with the problems stated above (deactiviating some optimizations doesn't
change anything because of the missing debug symbols).
> So maybe it would be better to treat abort specially in the opposite way:
> to inhibit merging two abort calls even in a situation where calls to
> some unknown function might be merged.
In my oppinion that would be pretty ugly. From the compilers point of view
the abort function is just a normal function with the __noreturn__
attribute. It's not a compiler builtin or something like that. Just
matching for a function name in the compiler and treat a function call
diffrently if it is to a function called "abort" is imo a strict no-do.
It would be possible to add a new attribute for such cases - but because of
the need-to-recompile-for-debug-symbols-anyways reason I don't see any need
for such an attribute.
yours,
- clifford
--
_ _ _ Nerds on Air - Radio for Geeks _ __ ___
| \| |___ /_\ On 1st and 3rd Friday of the month / |/ /__ / _ |
| .` / _ \/ _ \21:00-22:00 CET on Radio Orange // _ \/ __ |
|_|\_\___/_/ \_\ http://www.clifford.at/noa//_/|_/\___/_/ |_|
To understand recursion, you must first understand recursion.
pgpiOq4kxrDKC.pgp
Description: PGP signature
RFC: always-inline vs unit-at-a-time
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 failed in call to 'a': function not
considered for inlining
It seems undesirable for -O options to affect which programs will
compile.
The obvious thing to do about it is turn on -funit-at-a-time always,
but I'm
concerned about the effect on compile speed; has anybody measured it?
Re: RFC: always-inline vs unit-at-a-time
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 -O0 we get the baffling error
>sorry, unimplemented: inlining failed in call to 'a': function not
>considered for inlining
>
> 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? I think this
could be done without turning on -funit-at-a-time, even (the inliner
does work in -O2 -fno-unit-at-a-time mode, after all).
> The obvious thing to do about it is turn on -funit-at-a-time always,
> but I'm concerned about the effect on compile speed; has anybody
> measured it?
The problem is not the effect on compile speed (IIRC Honza had it down
to negligible) but the way it breaks assembly hacks such as crtstuff.c.
(I would love to see a solution to that.)
zw
Re: Merging calls to `abort'
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 been revealed immediately by the output of fancy_abort. I think this is more true in some programs than in others. For instance, it may be very true for GCC. In Emacs, when a bug is already fixed, either we can tell this from the circumstances reported (what commands the user typed, etc.), or there's simply no way to tell. Most of the bugs, most of the time, are reported by pretesters, and they do know how to send useful bug reports and to run GDB. 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. Nonetheless, GCC may as well still stop cross-jumping abort calls. There's nothing to lose, and it will be useful for those programs that call abort.
Re: RFC: always-inline vs unit-at-a-time
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(); }
This compiles fine at -O2. At -O0 we get the baffling error
sorry, unimplemented: inlining failed in call to 'a': function not
considered for inlining
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 pass, so tries to inline
"a" before it has seen the body of "a". If you interchange the
definitions
of "a" and "b" the inlining is done at all optimization levels.
I think this
could be done without turning on -funit-at-a-time, even (the inliner
does work in -O2 -fno-unit-at-a-time mode, after all).
That gets the same failure on this example.
The problem is not the effect on compile speed (IIRC Honza had it down
to negligible) but the way it breaks assembly hacks such as crtstuff.c.
(I would love to see a solution to that.)
I wasn't aware of this problem, can you give me a pointer?
Re: Merging calls to `abort'
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 may help assign the bug to the appropriate developer.
Re: RFC: always-inline vs unit-at-a-time
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 pass, so tries to inline > "a" before it has seen the body of "a". If you interchange the > definitions of "a" and "b" the inlining is done at all optimization > levels. Oh! Sorry, I should have read your example more carefully. I thought we weren't running the inliner at all at -O0 still. This is an intrinsic flaw in function-at-a-time mode. I think at this point it would be reasonable to make unit-at-a-time mode the default at -O0, while preserving -fno-unit-at-a-time for things like crtstuff (we eventually want to make that mode go away entirely, but we can't yet). Then, for the sake of people who try to use both always_inline and -fno-unit-at-a-time, we could improve the diagnostic - sorry, not implemented: inlining failed in call to 'a': function body not yet seen note: this restriction does not apply in -funit-at-a-time mode or something like that. >> The problem is not the effect on compile speed (IIRC Honza had it >> down to negligible) but the way it breaks assembly hacks such as >> crtstuff.c. (I would love to see a solution to that.) > > I wasn't aware of this problem, can you give me a pointer? I don't know a pointer, but it's easy enough to summarize ... Unit-at-a-time mode does not preserve the relative ordering of functions and top-level asm() statements. crtstuff.c uses top-level asm() statements (and asm() statements within functions) to change sections behind the compiler's back. It therefore breaks when compiled in unit-at-a-time mode. Long term I'd like to see most of the code moved from crtstuff.c to libgcc and the remainder written in assembly for each target, but other projects have done similar tricks (e.g. glibc's crt[in].o are generated similarly) and I don't think we want to unilaterally break them. zw
RE: Merging calls to `abort'
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 restrictions are hugely onerous. I think you are skating over this issue far too lightly. The only reference I could see to the memory costs associated with disabling this optimisation was way upthread, where you wrote "It saves a certain amount of space; it has no other benefit. All else being equal, there's no reason not to do it. But cross-jumping abort calls interferes with debugging. That's a good reason not to do it." Permit me to point out: that it is _precisely_ in the situations where memory *is* critical, that there is no question of having room for debugging overhead. What you casually dismiss as "no other benefit" can mean the difference between "working" and "completely broken". If you're coding for an embedded cpu, and you've already rolled a hundred thousand units off the production line, and all of a sudden the firmware won't fit, you've got a disaster on your hands, and squishing a few jumps together can save your life. You're talking about systems where "adding more memory" is not a matter of plugging in a few DIMMs, but of going back to your chip fab and spending another couple of million dollars to re-tape-out your design with another 1k of rom or whatever So whatever harm may be done to the quality of debug info is not a relevant consideration to the question of whether or not we should thread jumps in a context where we are critically short of memory; including debug info isn't an option anyway. 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's a -f that will allow me to switch it back on. cheers, DaveK -- Can't think of a witty .sigline today
Re: Merging calls to `abort'
> 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
Re: Merging calls to `abort'
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 >> specially within GCC, I think we'd be better off with a function >> attribute which prevented cross jumping to any function with >> the attribute set. > I think it makes sense to just not crossjump noreturn attribute > functions if we're going to do this. I think this is a slippery slope. Crossjumping calls to abort(), or even arbitrary noreturn functions, is just yet another technique of compiler optimization that makes debugging more difficult. Crossjumping calls to returning functions can be just as confusing if you're looking at a backtrace in a debugger, especially if a function gets called from lots of different functions that all get inlined into one that ends up being identified as the frame owner, and if they get cross-jumped, things get very confusing. Then, there's sibcalling, that can also contribute for more confusing backtraces. To sum up my point: I don't think avoiding crossjumping of calls to abort will address the underlying issue, which is that backtraces obtained from optimized programs may surprise people. Such avoidance will only paper over the issue, making the compiler behavior less consistent and thus even more confusing. If people want accurate stack traces, they shouldn't be using optimizations that can mess with backtraces. What we might want to do is provide an option to disable all such optimizations. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Question about "#pragma pack(n)" and "-fpack-struct"
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. Currently, -fpack-struct is defined
to have the same effect as attribute ((packed)) for all structures,
which in turn is equivalent to #pragma pack(1) for all structures. If
you want -fpack-struct to mean something else, then you need to define
how these features interact. This will probably mean splitting the
current TYPE_PACKED/DECL_PACKED fields into two, one which handles
pragma pack, one which handles -fpack-struct, and attribute((packed))
can perhaps go in which ever one makes more sense. Then you need to
modify all code that uses TYPE_PACKED/DECL_PACKED appropriately, which
may be messy.
It occurs to me to mention that you can get the result you want if you
use attribute ((aligned(2)) instead of pragma pack(2). That is better
than hacking up gcc.
struct TEST{
charx1;
intx2 __attribute__ ((aligned(2)));
};
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: `make uninstall' and GCC
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 -static for the moment), which is bad. There are also other possible problems. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Root Node of AST
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 expand_expr. Or start with the c_expand_body statement called from finish_function. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: PRE in GCC-3.3.3
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. You failed to specify the target. The target often makes a big difference on whether optimizations are performed. I am assuming the target is ia64-linux. Your testcase incidentally is serious flawed. The varible c is both used while uninitialized, and set using an unitialized value. It doesn't make much sense to talk about compiler optimizations when you have a testcase that invokes undefined behaviour. The testcase is also flawed in that it takes the address of both a and b, forcing them into memory, and thus making optimization of them difficult, particularly in pre-gcc-4 sources. I seem to get the same behaviour from both gcc-3.3 and gcc-3.4. In neither case is the partially redundant expression eliminated. gcc-4 does perform the optimization. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
[Ada] Can't build gcc cvs trunk 20050315 on sparc-linux: a-except.adb: unhandled expression in get_expr_operands():
Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc I (SpitFire) sun4u: binutils-2.15.92.0.2-5.sparc bison-1.875c-2.sparc dejagnu-1.4.4-2.noarch expect-5.42.1-1.sparc gcc-3.4.2-6.fc3.sparc package gcc4 is not installed glibc-2.3.3-99.sparcv9 glibc-2.3.3-99.sparc64 glibc-devel-2.3.3-99.sparc glibc-headers-2.3.3-99.sparc64 glibc-kernheaders-2.6-20sparc.sparc gmp-4.1.4-3sparc.sparc gmp-devel-4.1.4-3sparc.sparc kernel-2.6.11-1.1166sp1.sparc64 package kernel-devel is not installed package kernel-smp is not installed libgcc-3.4.2-6.fc3.sparc libstdc++-3.4.2-6.fc3.sparc libstdc++-devel-3.4.2-6.fc3.sparc make-3.80-5.sparc nptl-devel-2.3.3-99.sparcv9 tcl-8.4.7-2.sparc LAST_UPDATED: Tue Mar 15 16:27:53 UTC 2005 configure sparc-linux --enable-__cxa_atexit --enable-shared --with-gcc-version-trigger=/usr/local/src/trunk/gcc/gcc/version.c --enable-languages=c,ada,c++,f95,java,objc,treelang 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(): +===GNAT 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 meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. compilation abandoned make[2]: *** [ada/a-except.o] Error 1 make[2]: Leaving directory `/usr/local/src/trunk/objdir32/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir32/gcc' make: *** [bootstrap] Error 2 Cheers, /ChJ
Re: PR 20225
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 inlining limits can also make it go away. -BenRI
Re: a problem about cross-compile for powerpc
邹琼 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, it was probably already fixed a while ago. Try looking at more recent sources. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: PR 19893 & array_ref bug
> 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
> that type are aligned more strictly than they actually are.
>
> --
> Mark Mitchell
Interesting, I have created a patch (attached) that gives an error
whenever we try to create an array of elements and the alignment of the
elements is greater than the size of the elements.
The problem I have, and the reason I haven't sent it to gcc-patches, is
that it generates a bunch of regressions. The regressions are all due
to bad tests but I am not sure how to fix the tests so that I can check
in the patch.
The regressions are in two places, gcc.dg/compat/struct-layout* and
gcc.dg/vect/*
Most of the gcc.dg/vect/* tests contain something like:
typedef float afloat __attribute__ ((__aligned__(16)));
afloat a[N];
The question is, since this is illegal, what should we use instead?
I don't know if the alignment is an integral part of what is being
tested or not since the tests have no comments in them. So I am not
sure if we should just delete the alignment attribute or make it
smaller. If we make it smaller we need to know the size of float in
order to know if a particular alignment is legal or not.
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 to ensure that the alignment of the base type is less than or
equal to the size of the base type in those instances where we are
creating an array.
I would be interested in any advice on the best way to fix these tests
so that I can add my patch without causing regressions.
Steve Ellcey
[EMAIL PROTECTED]
Here is the patch that checks for the alignment of array elements and that
causes the regressions:
2005-03-15 Steve Ellcey <[EMAIL PROTECTED]>
PR 19893
* stor-layout.c (layout_type): Add alignment check.
*** gcc.orig/gcc/stor-layout.c Fri Mar 11 14:40:03 2005
--- gcc/gcc/stor-layout.c Tue Mar 15 15:46:02 2005
*** layout_type (tree type)
*** 1632,1637
--- 1632,1643
build_pointer_type (element);
+ if (host_integerp (TYPE_SIZE_UNIT (element), 1)
+ && tree_low_cst (TYPE_SIZE_UNIT (element), 1) > 0
+ && (HOST_WIDE_INT) TYPE_ALIGN_UNIT (element)
+ > tree_low_cst (TYPE_SIZE_UNIT (element), 1))
+ error ("alignment of array elements is greater than element size");
+
/* We need to know both bounds in order to compute the size. */
if (index && TYPE_MAX_VALUE (index) && TYPE_MIN_VALUE (index)
&& TYPE_SIZE (element))
Libstdc++-v3 vs darwin vs weak support
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 know from the maintainers (or other knowledgeable people) which is the current situation, whether those explicit instantiations are still needed. I'm asking because I mean to move from v7 to mainline a bunch of similar testcases... Paolo.
Re: PR 19893 & array_ref bug
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 appropriately aligned for the SIMD instructions to work correctly. It's certainly *not* true that the individual array elements must be so aligned. So, the right thing to write is: typedef float aligned_float_array[N] __attribute__((__aligned__((16))); aligned_float_array a; which says that the array should be 16-byte aligned. The GCC manual has some confusing language suggesting that arrays of aligned objects ought to work, contrary to my earlier statement. I think that's just broken. For example, if "sizeof (E) * N" is not the same as the sizeof an array of N elements of E, all kinds of normal invariants of C are going to break. If the above statement is going to be legal at all, then sizeof (afloat) must be equal to (at least) 16, which is surely not what the user intended, nor is what GCC actually does. 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 to ensure that the alignment of the base type is less than or equal to the size of the base type in those instances where we are creating an array. That could be fixed by adding the check you suggest, and then just discarding the attribute. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Libstdc++-v3 vs darwin vs weak support
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 > > AFAIK, only in order to avoid spurious failures on darwin. > > I'd like to know from the maintainers (or other knowledgeable people) > which is the current situation, whether those explicit instantiations > are still needed. I'm asking because I mean to move from v7 to > mainline a bunch of similar testcases... Darwin now has weak/comdat support, so it doesn't need or use this any more. However, AIX does need them, I think.
Re: Libstdc++-v3 vs darwin vs weak support
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.
Re: PR 19893 & array_ref bug
> > 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 to ensure that the alignment of the base type is less than or > > equal to the size of the base type in those instances where we are > > creating an array. > > That could be fixed by adding the check you suggest, and then just > discarding the attribute. I don't know if I have enough information to implement a test that ignores the attribute only when the alignment is greater than the size. Some of the attributes use __aligned__ with no value and that defaults to whatever the maximum alignment is for the platform you are running on and I don't know if I can determine that while running struct-layout-1_generate. 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 type. Steve Ellcey [EMAIL PROTECTED]
Re: PR 19893 & array_ref bug
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 type. Another possibility is to treat the alignment attribute as applying to the array as a whole (that is, the array is aligned to a multiple of 16 bytes, but the elements aren't), perhaps with a warning that this use is deprecated. I propose this because the tests suggest that this use is common enough that it appears in tests.
Re: PR 19893 & array_ref bug
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 element type. Another possibility is to treat the alignment attribute as applying to the array as a whole (that is, the array is aligned to a multiple of 16 bytes, but the elements aren't), perhaps with a warning that this use is deprecated. I propose this because the tests suggest that this use is common enough that it appears in tests. If there is a lot of code out there that does this, that might indeed be necessary, ugly though it would be. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Libstdc++-v3 vs darwin vs weak support
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 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. -- Pinski
Re: Libstdc++-v3 vs darwin vs weak support
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. Which targets, exactly? I mean, how many actually able to build and run correctly libstdc++-v3, anyway? I don't see much in testresults... Indeed, I gather that for now we have to keep that ugly machinery, but in 1 year, for instance? Paolo.
Re: Libstdc++-v3 vs darwin vs weak support
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 should be supported. Thanks Andrew for the info. Which targets, exactly? I mean, how many actually able to build and run correctly libstdc++-v3, anyway? I don't see much in testresults... Indeed, I gather that for now we have to keep that ugly machinery, but in 1 year, for instance? I build on i686-pc-openbsd3.1 everyday which does not use elf and does not support weak at all but I messed up the mail system so it is not sending the testresults out. I will try to fix that next week when I have time. But I know the libstdc++ results are okay, there are failures but most of them are related to wchar_t support. I think djgg does not support weak symbols either and I have not seen any test results from that target lately. -- Pinski
Re: Merging calls to `abort'
"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's a -f that will allow me to switch it back > on. I don't think there's been any argument about that -- of course it will be user-controllable. The question is what the default should be. I think that a deeply embedded system that uses abort() is not the common case for gcc, and so the defaults shouldn't cater to it; maybe you're right that the use of -Os is a reasonable hint though. -Miles -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson
Re: Libstdc++-v3 vs darwin vs weak support
> 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 constructors. David
Hand-written rec-descent parser of GCC-4.1 is WRONG!!!.
> 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 of many years of stupid engineers, developers, programmers and boss! "Hand-written recursive-descent parser" == LL(k) however, people does it as LL(1). The grammar of Pascal language can be LL(1), but the grammar of C, C++ and Objective-C together won't can be LL(1). However, they together can be LALR(1) (or impossible in worst-case) from Yacc/Bison. Writing Hand-written recursive-descent parser miss-cleans the source code and goes hardfully to maintain it!!! The best option is a clean grammar in Yacc/Bison!.
Re: Merging calls to `abort'
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 workaround to the user and knowing which file the > abort is in may help assign the bug to the appropriate developer. Absolutely true. As a GCC bugmaster, I can confirm that receiving bug reports with clear indication of the file name and the function name is incredibly useful. Not only it lets us find duplicates in seconds, or assign recent regressions to the responsible in a shot, but it also provides an immediate indication of which kind of bug it is. Otherwise, we would be forced to run GDB on the testcases just to categorize a bug. The abuse of abort() in GNU software is unfortunate. I agree with Mark when he says that a naked abort should be used only after useful information has already been printed to the user. In fact, we are in the middle of a conversion of the whole GCC codebase from abort() to assert() (even if our abort() is a fancy_abort() in disguise!). Giovanni Bajo
Re: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!.
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-written recursive-descent parser. > > Hahahahaha, WRONG!! > It's one historical error of many years of stupid engineers, developers, > programmers and boss! OK, we are all stupid, and you think that you are smart. > "Hand-written recursive-descent parser" == LL(k) > however, people does it as LL(1). > > The grammar of Pascal language can be LL(1), but the grammar of > C, C++ and Objective-C together won't can be LL(1). But yet gcc 3.4 has a hand-written recursive descent parser for C++. How can this be? The answer, of course, is that it is not LL(1). > However, they together can be LALR(1) (or impossible in worst-case) from > Yacc/Bison. Make that "impossible". C++ is not LALR(1), and in fact it requires unbounded lookahead. Back when we had a Bison parser for C++, it was made to work by putting another pass between the lexer and the parser to look ahead far enough to disambiguate some of the nasty cases. However, there were many corners of the language that it could not parse correctly. That's why we replaced it. > Writing Hand-written recursive-descent parser miss-cleans the source code > and goes hardfully to maintain it!!! Not if you know how to write one correctly. > 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 that don't look like C).
Re: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!.
> 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 that don't look like C). The biggest problem with Bison and other table-driver parsers is error messages and error recovery. There have been research projects in making this better for such parsers, but you can always do better in a hand-written parser.
Re: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!
| > > 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 of many years of stupid engineers, developers, | > programmers and boss! | | OK, we are all stupid, and you think that you are smart. It was a nice JOKE!!! I'm stupid too ;D | > "Hand-written recursive-descent parser" == LL(k) | > however, people does it as LL(1). | > | > The grammar of Pascal language can be LL(1), but the grammar of | > C, C++ and Objective-C together won't can be LL(1). | | But yet gcc 3.4 has a hand-written recursive descent parser for C++. How | can this be? The answer, of course, is that it is not LL(1). OK. | > However, they together can be LALR(1) (or impossible in worst-case) from | > Yacc/Bison. | | Make that "impossible". C++ is not LALR(1), and in fact it requires | unbounded lookahead. Back when we had a Bison parser for C++, it was | made to work by putting another pass between the lexer and the parser to | look ahead far enough to disambiguate some of the nasty cases. However, | there were many corners of the language that it could not parse correctly. | That's why we replaced it. Do you demonstrate that "C++ is not LALR(1)"? | > Writing Hand-written recursive-descent parser miss-cleans the source code | > and goes hardfully to maintain it!!! | | Not if you know how to write one correctly. However, they are many KLOCs in .c compared to few KLOCs in .y (glossary: KLOCs = Kilo Lines of Code) | > 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 that don't look like C). Why don't we develop a "LR(k) / k small" functions-written parser for this complex grammar?
Re: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!
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 proved it to your own satisfaction, and please refrain from giving advice in the meantime. > | 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) / k small" functions-written parser for this > complex grammar? Because C++ is not LR(k) for any k. It really does require unbounded lookahead.
Re: Libstdc++-v3 vs darwin vs weak support
> I'd like to know from the maintainers (or other knowledgeable people) > which is the current situation, whether those explicit instantiations > are still needed. I'm asking because I mean to move from v7 to mainline > a bunch of similar testcases... I think you should 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. For full details on Darwin and weak symbols, I recommend asking Geoff Keating. best, benjamin ps. I'm sure this is most relevant for AIX. Darwin was probably picked because, at the time, it was easier to test weak symbol support on darwin than on AIX.
Re: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!
| > 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 giving advice in the meantime. It's not an easy proof. To prove "not LALR(N)" is hard, there is not known lemma that says "there is not equivalent grammar of this grammar to be LALR(N)". People only knows LALR(1),LR(1),LL(1),LL(k),LR(k),SLR,LR(0),LL(0),LALR(0),... but the people doesn't know LALL(0),LALL(1),LALR(2),LALL(k),LALR(k),... because it is not easy to understand the unknown theory. Do you demonstrate that "C++ is not LALR(k) for any k"? Or didn't you find the "C++ grammar, LR(k) for small k"? 1. LR(k) / k small IS MORE POWERFUL THAN LR(3) 2. LR(3) IS MORE POWERFUL THAN LR(2)(and little bit slower) 3. LR(2) IS MORE POWERFUL THAN LR(1)(and little bit slower) 4. LR(1) IS MORE POWERFUL THAN LALR(1) (and little bit slower) 5. LR(1) IS EQUAL POWERFUL AS LL(1) BUT there are many differences in the aspects of programming language grammars (e.g., vertical programming of rules versus horizontal programming of rules). | > | 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) / k small" functions-written parser for this | > complex grammar? | | Because C++ is not LR(k) for any k. It really does require unbounded | lookahead. It's possible that C++ doesn't require unbounded lookahead because you did not find this confirmation "For each C++ grammar, LR(k) for small k IS IMPOSSIBLE!!!".
RTL?
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 네이버 :: 똑! 소리나게 바뀐 네이버 메일을 만나보세요. http://mail.naver.com/
Re: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!
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) / k small" functions-written parser for this > | > complex grammar? > | > | Because C++ is not LR(k) for any k. It really does require unbounded > | lookahead. > > 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) parser. Unless you are going to refute that this is possible (and it has been done before, so trying to refute it would just make you look sily), this proves that C++ is not an LR(k) language.
Re: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!
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 that don't look like C). > > | > > > | > Why don't we develop a "LR(k) / k small" functions-written parser for > > this > > | > complex grammar? > > | > > | Because C++ is not LR(k) for any k. It really does require unbounded > > | lookahead. > > > > 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) parser. s/C++ program/grammatically valid C++ program/, just so we are clear.
Re: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!
[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 you have proved it to your own satisfaction, and > | please refrain from giving advice in the meantime. > > It's not an easy proof. You are mistaken. The proof is trivial for C++. zw
Re: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!
| > 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) parser. | | Unless you are going to refute that this is possible (and it has been | done before, so trying to refute it would just make you look sily), this | proves that C++ is not an LR(k) language. Then the final solution with better compilation space-time and valid grammar is to kill the evil standard C++ and to make a new standard D++ compatible with LALR(1) or LL(1) languages. (e.g. as Delphi or Object Pascal but using the C/C++-like style) Good bye.
Re: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!
| > | > 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 proved it to your own satisfaction, and | > | please refrain from giving advice in the meantime. | > | > It's not an easy proof. | | You are mistaken. The proof is trivial for C++. | | zw Then the final solution with better compilation space-time and valid grammar is to kill the evil standard C++ and to make a new standard D++ compatible with LALR(1) or LL(1) languages. (e.g. as Delphi or Object Pascal but using the C/C++-like style) Good bye.
Re: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!
| > | > 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 proved it to your own satisfaction, and | > | please refrain from giving advice in the meantime. | > | > It's not an easy proof. | | You are mistaken. The proof is trivial for C++. | | zw Then the final solution with better compilation space-time and valid grammar is to kill the evil standard C++ and to make a new standard D++ compatible with LALR(1) or LL(1) languages. (e.g. as Delphi or Object Pascal but using the C/C++-like style) Good bye.
RE: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!
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 (regardless of lookahead size), and syntax analysis depends on semantic disambiguation. While conventional (LALR(1) and LL(k)) parser generation tools have been used to build C++ parsers, the effort involved in grammar modification and custom code development is substantial, rivaling the effort of constructing a parser manually. [...] Link to PDF: http://tinyurl.com/3remp And a related thread on the GCC mailing list back in 2002: http://gcc.gnu.org/ml/gcc/2002-08/msg00085.html
reload question
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 = "a,gi" and add3 has constraints: 0 = "r" 1 = "0"2 = "i" (say) Then if there's an insn before reload like: add3 X, Y, 1 Reload will notice this, and generate a reload to put Y into X, so you'll end up with: mov X, Y add3 X, X, 1 That seems to be happening correctly. Now, what I _expected_ to happen is that reload would then be repeated to handle the newly added mov insn, which would see that the mov insn's constraint don't match, and would then generate an additional reload to yield: mov A, Y mov X, A add3 X, X, 1 but in fact this final step doesn't seem to be happening -- it just finishes reload without changing the bogus "mov X, Y" insn and goes on to die with an "insn does not satisfy its constraints:" error in final. I've been trying to track through reload seeing what it's doing, but my mind is being twisted into little knots, and I'd really like to at least know if what I think should be happening is accurate. Any hints? Thanks, -Miles -- .Numeric stability is probably not all that important when you're guessing.
Re: [Ada] Can't build gcc cvs trunk 20050315 on sparc-linux: a-except.adb: unhandled expression in get_expr_operands():
> 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 Botcazou
