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].
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 req
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_t
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 st
"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. Coul
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 i
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 ab
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 gene
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
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 ca
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-
> Seemed safer to just roll things back and sort it out later.
Understood, thanks again for the quick turn around.
--
Eric Botcazou
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 noti
> 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
14 matches
Mail list logo
