Re: Ada bootstrap broken
> Sorry, folks. I've rolled this back. Thanks, but this was not really necessary, Ada doesn't define LANG_HOOKS_EXPAND_CONSTANT, you only needed to restore lhd_return_tree. -- Eric Botcazou
Re: Ada bootstrap broken
On 9/29/07, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > Thanks, but this was not really necessary, Ada doesn't define > LANG_HOOKS_EXPAND_CONSTANT, you only needed to restore lhd_return_tree. Yes, but it was late, I had a toddler who needed putting to bed, and I had no idea why I'd failed to notice that Ada hadn't built. Seemed safer to just roll things back and sort it out later. Ollie
Re: Ada bootstrap broken
> Seemed safer to just roll things back and sort it out later. Understood, thanks again for the quick turn around. -- Eric Botcazou
outof-ssa vs. -fnon-call-exceptions: known problem?
While looking into the failure of gcc.c-torture/compile/20050113-1.c
on mipsisa32-elf, I noticed the tree-outof-ssa can move potentially-
trapping operations across what were sequence points, even when compiled
with -fnon-call-exceptions. E.g., consider the following C++ code,
compiled with -fnon-call-exceptions:
#include
void foo (int) { printf ("Bar\n"); }
int
main (void)
{
int a = 1 / 0;
printf ("Foo\n");
foo (a);
}
The tree optimisers themselves preserve the intent of the code,
but tree-outof-ssa.c propogates the division into the call to foo():
int main() ()
{
:
__builtin_puts (&"Foo"[0]);
foo (1 / 0);
return 0;
}
So the unoptimised program behaves as expected, raising the divide-by-zero
trap before printing "Foo". The optimised version prints "Foo" first.
Is this a known problem? (I tried to find it in bugzilla, but couldn't)
Richard
Re: unflattening fortran matrices
Hi, sorry for taking so long to respond. I'm cc:ing the main gcc@ list as well, in case someone more knowledgeable than me wants to set the story straight. :) Paul Thomas wrote: Before welcoming patches, perhaps you can convince the uninitiates what this would do for us. The debug side I can understand but exactly which vectorization features would we miss? Well, I'm not an expert but in general I think the problem is dependency analysis. To be able to do a lot of optimizations (vectorization and others as well) the middle end needs to be able to figure out e.g. that a(i,j) and a(i2, j2) are different memory addresses (for a loop body during any iteration of the loop or somesuch). If the array information is passed as such to the middle end this is easy; just check that (i != i2 || j != j2). This is not as easy to figure out if the middle end instead gets a 1D array reference with a non-trivial index expression. Another one, e.g. do i = 1, N do j = 1, M a(i,j) = b + c(i,j) end do end do Any Fortran user should immediately see that we're accessing a and c in the wrong order, but I suspect there's still plenty of code out there that gets it wrong. If the optimizer can figure out that there is no dependency, it can switch the loops or alternatively transpose the array by manipulating the descriptor (http://gcc.gnu.org/wiki/MatrixReorganization), and not only does the loop then vectorize, we get better memory locality as well. Yet another one, outer loop vectorization, see http://gcc.gnu.org/wiki/VectorizationTasks Another thing is that array flattening is actually a useful optimization (http://gcc.gnu.org/wiki/MatrixReorganization). Gfortran gets it "for free", but AFAICT not in a beneficial way as the benefit is in reducing the overhead in updating loop counters; in gfortran we still have the original nested loops for walking over a flattened array. Are they such that we could forego this rebuild of gfortran by signalling the multi-dimensionality of arrays to the vectorizer? Hmm, maybe. Apparently there is some work in that direction (http://gcc.gnu.org/wiki/LoopOptTasks): "Index recovery (Daniel Berlin & Richard Guenther, medium): Recover the values of the indices of multidimensional arrays represented as one-dimensional arrays (often used in C; see also the "Not flattening Fortran arrays" task), using the induction variable analysis and value range information.". If that would work I guess it could be much less work than doing major surgery on gfortran? Alternatively, can we pre-empt the necessary vectorizer steps in the front-end; cf. Toon's talk to the gcc summit? (I haven't forgotten common factor elimination, Toon:-) ). Yes, I've read Toon's paper. Though I think it's worth distinguishing between general and Fortran-specific optimizations. For the general optimizations, the middle-end is staffed by a bunch of clever people with Phd:s in compilerology working to some extent full time on gcc. Leveraging the efforts of these people where possible is, IMHO, the only sensible way. For the Fortran-specific stuff like optimizations of array expressions I suppose there's no particular value in pushing these things to the middle-end, if nobody else is going to be interested in maintaining them anyway. -- Janne Blomqvist
Is this a bug?
two c files: main.c and func.c, excute the command like this:
gcc main.c func.c -Wall -ansi -pedantic
there are two warnings, and is can generate binary file and the file
can be excuted.
//main.c
int main()
{
int a;
a = func();
printf("%d\n", a);
return a;
}
//func.c
float func(int a, int b)
{
return (float)(a + b);
}
I assume it's a bug: func in main funcion is different from the
function in func.c
My gcc version is gcc 3.2.2.
May be not this version, i have forgotten.
Re: Is this a bug?
It's not a bug. It conforms the C standard. C, unlike C++,
distinguishes functions ONLY by name, not by arguments.
C allows calling functions that are not declared by assuming they
return int. So GCC would assume that the prototype of "func" to be
"int func()" when compiling "main.c", and can generate a call to
"func", although it's defined in another file with a different
prototype. When the prototypes are different, the behavior is
undefined.
(Yes, this would be a link error in C++. But for C, it's the
programmer's responsibility to make sure arguments and return values
are passed correctly if you call undeclared functions. Therefore, it
is always encouraged that every function be declared before called,
even in C code.)
On 9/29/07, Zhang Xiaoping <[EMAIL PROTECTED]> wrote:
> two c files: main.c and func.c, excute the command like this:
>
> gcc main.c func.c -Wall -ansi -pedantic
>
> there are two warnings, and is can generate binary file and the file
> can be excuted.
>
> //main.c
>
> int main()
> {
> int a;
> a = func();
> printf("%d\n", a);
> return a;
> }
>
> //func.c
> float func(int a, int b)
> {
> return (float)(a + b);
> }
>
> I assume it's a bug: func in main funcion is different from the
> function in func.c
>
> My gcc version is gcc 3.2.2.
>
> May be not this version, i have forgotten.
>
Re: AltiVec stack boundary
On Fri, Sep 28, 2007 at 05:22:41PM -0700, Geoffrey Keating wrote: > The case where this matters is a 32-bit ELF EABI target (the only case > on powerpc that allows 8-byte stack alignment) using -maltivec but not > -mabi=no-altivec. It's not clear to me that case works. I was originally worried about powerpc-linux. I think I was fooled by the STACK_BOUNDARY definition, though. If the ABI actually mandates 16-byte alignment and GCC rounds up the size of stack frames it generates, then things will work out (barring broken startup code). So you must be right - it's just powerpc-eabi. > I don't think that in general you want to do this in an embedded > context, because of the extra code generated to align the stack; it'd > be much better to just declare that you're going to use the AltiVec > ABI, even if some parts of your embedded code won't be allowed to use > any AltiVec instructions. Well, it would be nice if it worked - since e.g. the GCC testsuite will try to use it! However, this doesn't affect me directly; I test the standard powerpc-linux ABI on AltiVec capable hardware, but I only test -mabi=altivec on our AltiVec capable EABI targets. Thanks. -- Daniel Jacobowitz CodeSourcery
Re: outof-ssa vs. -fnon-call-exceptions: known problem?
On 9/29/07, Richard Sandiford <[EMAIL PROTECTED]> wrote: > Is this a known problem? (I tried to find it in bugzilla, but couldn't) I can reproduce it on x86_64 as well. The 1/0 statement should not be considered replaceable by out-of-ssa. Could you file a bug for this? This patch should fix it. Still being tested: 2007-09-29 Diego Novillo <[EMAIL PROTECTED]> * tree-ssa-ter.c (is_replaceable_p): Return false if STMT may throw an exception. Index: tree-ssa-ter.c === --- tree-ssa-ter.c (revision 128881) +++ tree-ssa-ter.c (working copy) @@ -366,6 +366,10 @@ is_replaceable_p (tree stmt) if (TREE_CODE (stmt) != GIMPLE_MODIFY_STMT) return false; + /* If the statement may throw an exception, it cannot be replaced. */ + if (tree_could_throw_p (stmt)) +return false; + /* Punt if there is more than 1 def. */ def = SINGLE_SSA_TREE_OPERAND (stmt, SSA_OP_DEF); if (!def)
Re: outof-ssa vs. -fnon-call-exceptions: known problem?
"Diego Novillo" <[EMAIL PROTECTED]> writes: > On 9/29/07, Richard Sandiford <[EMAIL PROTECTED]> wrote: >> Is this a known problem? (I tried to find it in bugzilla, but couldn't) > > I can reproduce it on x86_64 as well. The 1/0 statement should not be > considered replaceable by out-of-ssa. Could you file a bug for this? Done as 33593. > This patch should fix it. Still being tested: Thanks for the quick fix! Richard
Re: outof-ssa vs. -fnon-call-exceptions: known problem?
On 9/29/07, Richard Sandiford <[EMAIL PROTECTED]> wrote: > "Diego Novillo" <[EMAIL PROTECTED]> writes: > > On 9/29/07, Richard Sandiford <[EMAIL PROTECTED]> wrote: > >> Is this a known problem? (I tried to find it in bugzilla, but couldn't) > > > > I can reproduce it on x86_64 as well. The 1/0 statement should not be > > considered replaceable by out-of-ssa. Could you file a bug for this? > > Done as 33593. > > > This patch should fix it. Still being tested: > > Thanks for the quick fix! Except I think it is wrong for PowerPC where dividing by 0 will never trap. -- Pinski
Re: outof-ssa vs. -fnon-call-exceptions: known problem?
On 9/29/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: > Except I think it is wrong for PowerPC where dividing by 0 will never trap. No the patch is correct. The issue that you are bringing up is orthogonal to the fix. If tree_could_trap_p(1/0) == true on ppc, and that is wrong, then tree_could_trap_p() should be fixed for PPC.
PL/I for GCC version 0.0.15 released
September 2007 This is the fifteenth code drop of the GCC front-end for the PL/I programming language. PL/I for GCC is released under the terms of the GNU Public License; version 2. With pl1gcc-0.0.15 the preprocessor do loop, %DO, has been partly implemented. Only one level is allowed. This required quite a bit of restructuring of the internal code. But now it is easy to add more preprocessor statements like %IF and preprocessor %PROCEDUREs. Expect some more releases soon. Further the internal parse tree has also been improved, so code generation should begin really soon now (tm). There is still no code generation taking place, so don't run out and deinstall your production PL/I compiler just yet :-) Changes in v0.0.15 -- * Restructuring parser stack * Improve internal interface to preprocessor * Synchronize with gcc version 4.3 (20070810) * Improved error messages with declares Changed syntax in v0.0.15 - * Non-nested %DO varname = NUM TO NUM * %NOTE can reference preprocessor variables For a complete list of changes check the CHANGELOG file. Source code contributions to pl1gcc --- If you have some PL/I code you do would like to save for the future, then consider to release the source code either under GPL or donate it to the public domain. pl1gcc can offer to host the code for you. What is pl1gcc? --- The pl1gcc project is an attempt to create a native PL/I compiler using the GNU Compiler Collection. The project is looking for more people to join development and testing, it has mostly been a one man project. There are a number of interesting tasks related to the pl1gcc project, where any help would be greatly appreciated. a) Error regression infrastructure b) Error message codes c) Case insensitive include name expansion d) Test cases e) Project web pages f) Language reference manual g) User guide h) Tutorial to PL/I i) Frequently asked questions j) Internals of pl1gcc k) Code generation For more information, comments, feedback and download, please visit http://pl1gcc.sourceforge.net Finally, remember to have some fun. Henrik Sorensen Web links mentioned: http://pl1gcc.sourceforge.net
[RFC,wwwdocs] Ditch MetaHTML and use our own Perl preprocessor
Hi, I am in the process of rewriting the Fortran part of our website (http://gcc.gnu.org/), part of which consists of adding the GCC navigation bar. To do so, I had to install localy MetaHTML, our current web preprocessor, and my experiences with it have left me less than impressed [1]. We currently use it for including headers and footer, making them depend on whether we are preprocessing HTML or XHTML, modifying in place a few tags (, , ) and adding navigation bar on files that need it. This can easily be done by a simple preprocessing script, and seeing that MetaHTML was last released 1999 and apparently unsupported since then, I suggest that we do this move right now. This patch includes the new preprocessor, changes to the script, and quite a few new files (footer, navigation bars, etc.) split from the MetaHTML file, style.mhtml. I chose to write the preprocessor script in Perl, since Perl is already used for the wwwdocs/bin/preprocess script, so I'm sure it will be available on the webserver. The preprocessor does what MetaHTML was needed, but it can be extended in the future if we need more functionality. Also, we can in the future offload some of its work, such as and modifications and part of the navigation bar to CSS, which is obviously better suited for the job. I intend to do so as a follow-up to the preprocessor change, if/when it is accepted. This change shouldn't change the website, but I can't check since I don't have MetaHTML, so I'd appreciate if someone with shell access to the webserver could check it. Oh, there is one thing that I changed: the detailled search page, http://gcc.gnu.org/search.html, currently has a "Database last updated -MM-DD" line that doesn't work (it displays "1900--"), so I removed it. Comments are highly welcome, both on the idea itself, and on the Perl script (my Perl is a bit rusty since I haven't used it for years). Thanks, FX [1] As a record, here's what my "final" status is: in addition to Gerald's patch and script provided by Joel Sherrill (thanks guys), I needed to patch of few more (~ 15) occurences of multilines strings, force the Makefiles to use the version of readline included in metahtml instead of the system one (too recent, apparently there's been an ABI change), and tweak the Makefiles for the shared modules, which aren't portable (at least, not to Mac OS). As of yesterday, I've managed to compile it, but the resulting binary acts as an endless cpu-consuming loop. At that point, I gave up. www.diff Description: Binary data
