Hi...
Is there something special I need to do on to run bubblestrap on the 3.4 branch?
I get into this problem:
configure: loading cache ./config.cache
configure: error: `LDFLAGS' was not set in the previous run
configure: error: changes in the environment can compromise the build
configure: err
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | AFAICT (at least according to mail logs, etc) you are the only user of
| >
| > apparently, you've to count properly.
|
| gccbug is different from what you are using.
OK.
-- Gaby
On Aug 12, 2005, at 3:45 PM, Laurent GUERBY wrote:
Isn't it possible to attach some information on a comparison
statement that tells code generation never to never
optimize away this particular comparison even if it
seems to be able to prove it is always true or false?
Cough, hack, ick.
Isn't it possible to attach some information on a comparison
statement that tells code generation never to never
optimize away this particular comparison even if it
seems to be able to prove it is always true or false?
(just like volatile does for memory read)
For code executed after this kind of
[EMAIL PROTECTED] (Richard Kenner) wrote on 12.08.05 in <[EMAIL PROTECTED]>:
> What has to happen is that we need some sort of way of indicating that it's
> not permissible to derive information through a particular conversion.
That may be the only practical solution, but it seems to me it's not
I'm porting gcc-4.0.1 to a new VLIW architecture.
I figured out that the `insn' and `jump_insn' were grouped together in the 2nd
sched pass
however there is a `structural hazard' between them.
Such as the following code which generated by gcc -O3 -dP -S code.c:
@(insn:TI 319 315 474 (set (reg/v:S
Mike Stump <[EMAIL PROTECTED]> writes:
> In general you'll want to understand how OSes allocate stack, and how
> the determine if an access is to the stack or not. The canonical
> unix way is to catch a fault, and if that fault is within X MB (8MB
> in years past) of the top of the stack, assume
On Aug 12, 2005, at 12:25 PM, Paul Koning wrote:
Mike> I think we should turn off inlining for functions > 100k stack
Mike> size. (Or maybe 500k, if you want).
Why should stack size be a consideration? Code size I understand, but
stack size doesn't seem to matter.
In general you'll want to
Richard Kenner wrote:
> compiler (specifically VRP) is *correct* in deducing that the values are
> in the valid range of the type *except* for 'Valid and range checks.
You meant "for 'Valid range checks" right? (no "and").
I meant "and". Range checks are essentially 'Valid.
no, r
> > "Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
>
> Mike> On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
> >> We had a situation come up here where things are like this
> >> (simplified, obviously):
> >>
> >> c() { char x[100]; }
>
> Mike> I think we should turn off inli
On Aug 12, 2005, at 4:00 PM, Dale Johannesen wrote:
Sometimes it matters, as in the original example:
c() { char x[100]; }
a() { b(); c(); }
b() { a(); c(); }
Actually in this case, x is removed so it does not matter at all.
This case though it does matter:
int f(int*); int g(void); in
On Aug 12, 2005, at 12:25 PM, Paul Koning wrote:
"Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
Mike> On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
We had a situation come up here where things are like this
(simplified, obviously):
c() { char x[100]; }
Mike> I think we shou
> "Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
Mike> On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
>> We had a situation come up here where things are like this
>> (simplified, obviously):
>>
>> c() { char x[100]; }
Mike> I think we should turn off inlining for functions
On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
We had a situation come up here where things are like this
(simplified, obviously):
c() { char x[100]; }
I think we should turn off inlining for functions > 100k stack size.
(Or maybe 500k, if you want).
Daniel Berlin writes:
> Fixed.
Indeed: a new resubmission just worked, thanks.
> Perl syntax is weird enough that when people update it, they sometimes
> add compile errors by accident, so the script doesn't even run enough to
> be able to issue an error message :(.
True enough: perl can easily
> compiler (specifically VRP) is *correct* in deducing that the values are
> in the valid range of the type *except* for 'Valid and range checks.
You meant "for 'Valid range checks" right? (no "and").
I meant "and". Range checks are essentially 'Valid.
> "Jim" == James E Wilson <[EMAIL PROTECTED]> writes:
Jim> I see that Nathan posted a patch last December to try to remove some
Jim> CHAR_TYPE support.
Jim> http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00689.html
Yeah, that must be what I remember.
Jim> A possible way to solve this prob
* Laurent GUERBY:
> An implementation model could be for the front-end to generate for each
> family of scalar type T a function Base_Type_Internal_Valid (X, Min,
> Max : in Base_Type_Of_T) return Boolean, generate a call to it at all
> 'Valid uses and then tell the compiler to never do any inlini
Laurent GUERBY wrote:
My understanding is that VRP (the compiler) is free to remove all other
language mandated range checks based on type min/max information but has
to keep the ones generated for 'Valid.
and any implicit validity checks, and for gnat, validity checks from
-gnatVa
An imple
On Fri, 2005-08-12 at 11:53 -0400, Richard Kenner wrote:
> I'm not saying that things aren't broken, just being very careful in the
> definition of what a "valid" value in an object is. The point is that these
> values are not "valid" (which is why 'Valid returns FALSE) and that the
> compiler (sp
The Ada front end works by doing an unchecked conversion of X to
t'Base, followed by a range check. The issue is to stop range
propagation through the unchecked conversion.
And as we discussed on the phone, the core of the problem is that Gigi
treats unchecked conversions of numeric ty
We had a situation come up here where things are like this (simplified,
obviously):
c() { char x[100]; }
a() { b(); c(); }
b() { a(); c(); }
c() is a leaf. Without inlining, no problem. WIth c() inlined into
a() and/or b(),
a few mutually recursive calls to a() and b() blow out the stack
Richard Kenner wrote:
which, contrary to your previous email, is definitely not an erroneous
situation. Precision is very important here!
Yes, and I'm sorry for the confusion. However, for the purposes of this
discussion, there's no difference between erroneous and bounded error:
the i
Richard Kenner wrote:
Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a
way which is (now) incorrect,
No, that usage is correct. What's incorrect is the way that 'Valid and
range checks are being implemented and/or optimized. Those should not be
using the bounds of
> On Aug 12, 2005, at 5:05 AM, Etienne Lorrain wrote:
> > I have added a command to the linker file to forbid reference from
> > one section to another:
> >NOCROSSREFS (.text .xcode);
>
> It sounds like this feature isn't compatible with inlining, -fno-
> inline I suspect is one of the few ways
On Aug 12, 2005, at 5:05 AM, Etienne Lorrain wrote:
I have added a command to the linker file to forbid reference from
one section to another:
NOCROSSREFS (.text .xcode);
It sounds like this feature isn't compatible with inlining, -fno-
inline I suspect is one of the few ways to `fix' it in
Giovanni Bajo wrote:
Robert Dewar <[EMAIL PROTECTED]> wrote:
Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a way
which is (now) incorrect, and this causes wrong optimizations. Of course,
this might be seen as an evolution (the exact semantics weren't as clear
before), but
which, contrary to your previous email, is definitely not an erroneous
situation. Precision is very important here!
Yes, and I'm sorry for the confusion. However, for the purposes of this
discussion, there's no difference between erroneous and bounded error:
the issue is whether it's rig
Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a
way which is (now) incorrect,
No, that usage is correct. What's incorrect is the way that 'Valid and
range checks are being implemented and/or optimized. Those should not be
using the bounds of the subtype.
I'd al
Richard Kenner wrote:
Quote from section 13.9.1 follows. Note the "but does not by itself
lead to erroneous or unpredictable execution" part.
Right, because it's a "bounded error".
which, contrary to your previous email, is
definitely not an erroneous situation.
Precision is very impo
Robert Dewar <[EMAIL PROTECTED]> wrote:
> why can't we just
> completely turn off this optimization for Ada since it is wrong!
Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a way
which is (now) incorrect, and this causes wrong optimizations. Of course,
this might be seen as
Richard Kenner wrote:
> Well sure, reading an uninitialized value is erroneous except for the use
> of 'Valid.
No, it's not, as Ada is not C.
What's "not"? My statement is based on the Ada RM.
the rm is quite clear, lack of initialization
never leads to erroneous behavior. an
Quote from section 13.9.1 follows. Note the "but does not by itself
lead to erroneous or unpredictable execution" part.
Right, because it's a "bounded error".
Richard Kenner wrote:
If this still doesn't convince you, here's an example which doesn't
use Ada.Unchecked_Conversion at all.
Well sure, reading an uninitialized value is erroneous except for the use
of 'Valid.
That is wrong, it is a bounded error. and of course validit checks must
wo
* Richard Kenner:
> > Well sure, reading an uninitialized value is erroneous except for the
> use
> > of 'Valid.
>
> No, it's not, as Ada is not C.
>
> What's "not"? My statement is based on the Ada RM.
Quote from section 13.9.1 follows. Note the "but does not by itself
lead to e
> Well sure, reading an uninitialized value is erroneous except for the use
> of 'Valid.
No, it's not, as Ada is not C.
What's "not"? My statement is based on the Ada RM.
And please note the presence of pragma Normalize_Scalars.
That doesn't affect validity or erroneousness.
* Richard Kenner:
> If this still doesn't convince you, here's an example which doesn't
> use Ada.Unchecked_Conversion at all.
>
> Well sure, reading an uninitialized value is erroneous except for the use
> of 'Valid.
No, it's not, as Ada is not C. And please not the presence of pragma
N
If this still doesn't convince you, here's an example which doesn't
use Ada.Unchecked_Conversion at all.
Well sure, reading an uninitialized value is erroneous except for the use
of 'Valid.
I'm not saying that things aren't broken, just being very careful in the
definition of what a "vali
* Robert Dewar:
> Florian Weimer wrote:
>
>> I fear that such barriers are also needed for all checks on scalars,
>> by the way, not just 'Valid.
>
> indded, and we do unchecked conversions to the base type in these
> cases. i guess we could fix the enum case by using unsigned as the
> arg type, b
Florian Weimer wrote:
I fear that such barriers are also needed for all checks on scalars,
by the way, not just 'Valid.
indded, and we do unchecked conversions to the base type in these
cases. i guess we could fix the enum case by using unsigned as the
arg type, but that would not help the gen
* Robert Dewar:
> Florian Weimer wrote:
>> If this still doesn't convince you, here's an example which doesn't
>> use Ada.Unchecked_Conversion at all.
>
> this example must print Success, that is guaranteed by the RM
Yes, I think so.
What about the first one in PR21573? IMHO, the GNAT Reference
Florian Weimer wrote:
If this still doesn't convince you, here's an example which doesn't
use Ada.Unchecked_Conversion at all.
this example must print Success, that is guaranteed by the RM
it is definitely critical that 'Valid not make "in-range"
assumptions. the actual problem is optimizatio
On Fri, 2005-08-12 at 16:52 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | AFAICT (at least according to mail logs, etc) you are the only user of
>
> apparently, you've to count properly.
What?
You do read what i wrote, right?
I said you appear to be the only us
>
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | AFAICT (at least according to mail logs, etc) you are the only user of
>
> apparently, you've to count properly.
gccbug is different from what you are using.
-- Pinski
> The other thing we could try to do is put virtual variables in loop-closed-
> form, at least just before the vectorizer, and at least just for some
> loops. Does this sound reasonabale? (By the way, why don't we keep virtual
> variables in loop-closed-form?)
We used to, nobody could come up with
Daniel Berlin <[EMAIL PROTECTED]> writes:
| AFAICT (at least according to mail logs, etc) you are the only user of
apparently, you've to count properly.
On Fri, 2005-08-12 at 11:23 +0200, Rainer Orth wrote:
> Daniel Berlin writes:
>
> > > Could you please check what's going on there? Is this a general problem
> > > with gcc-gnats processing or a problem parsing that particular message?
> >
> > Dunno. Grepping mail logs older than an hour takes
* Richard Kenner:
> Both ARM 13.9.1 and the GNAT User Guide (in Section 3.2.4 Validity
> Checking) require that such reads are NOT erroneous.
>
> It depends what "such reads" mean. 13.9.1(12) clearly says that the
> result of an Unchecked_Conversion is erroneous if it isn't a valid
> re
On Fri, 2005-08-12 at 13:24 +0200, Gabriel Dos Reis wrote:
> Rainer Orth <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | I'm using gccbug since it provides the complete template where I just need
> | to fill in the beef of the report. All I care for is the ability to handle
> | bugs completely by em
--- Richard Guenther <[EMAIL PROTECTED]> wrote:
> Please explain the problem you're seeing. I can see nothing wrong with
> inlining functions within different sections in general. If you're
> trying to do things behind the compilers back, though, be prepared to
> change workarounds with compiler
Rainer Orth <[EMAIL PROTECTED]> writes:
[...]
| I'm using gccbug since it provides the complete template where I just need
| to fill in the beef of the report. All I care for is the ability to handle
| bugs completely by email.
Amen. And it is important that one has at least a good flexibility
On 8/12/05, Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Subject says it all - I do not know if that is new. I just have a bug
> in Gujin-1.2 with this new compiler, because function:
>
> __attribute__ ((section (".xcode_start"), noreturn))
> void xcodeseg_never_call_address_zero (
Thanks to all who proposed projects and volunteered, I've informed FSF
France that the project has enough volunteers to move ahead.
I'll write a summary in the GCC wiki this week-end, feel free
to add more projects then.
The machines should appear online at the beginning of september,
script volu
Hello,
Subject says it all - I do not know if that is new. I just have a bug
in Gujin-1.2 with this new compiler, because function:
__attribute__ ((section (".xcode_start"), noreturn))
void xcodeseg_never_call_address_zero (void)
calls xcodeseg_BOOT1_putstr() generated by macro:
#define GE
Daniel Berlin writes:
> > Could you please check what's going on there? Is this a general problem
> > with gcc-gnats processing or a problem parsing that particular message?
>
> Dunno. Grepping mail logs older than an hour takes a while on
> sourceware, because they are large. Can you resend i
55 matches
Mail list logo
