Although the coldfire's that I know of are able to use addq/subq to memory
operands, gcc refuses to generate those instructions.
Below is a small patch fixing that.
With it, my coldfire-compiled linux kernel shrinks by 3k IIRC.
Feel free to apply.
Best Regards
Philippe
2005-08-26 Philippe De
GCC 4.2 Stage 1 is scheduled to end on the 18th.
However, it appears that many of the GCC 4.1 projects planned for 4.1
have not yet made it in; some have been submitted, but not yet
committed. I'm particularly thinking of the IPA cleanups, which were a
requirement for certain other improvements.
GCC 4.0.3 has been a long time coming. (I postponed it in order to
focus on GCC 4.1.0, but, in retrospect, that was a mistake.)
In any case, given that we've waited this long, I plan to make the GCC
4.0.3 immediately after GCC 4.1.0. Most people are focusing more on 4.1
and mainline than one 4.0
The release of GCC 4.1 was scheduled for January 18th. Given the fact
that I've not yet built release candidates, that date is not achievable.
We have 63 regressions open against GCC 4.1, but only six are P1. Since
P1s are showstoppers, that means we're not yet ready to start building
release ca
On Sun, 2006-01-15 at 18:35 -0500, Daniel Berlin wrote:
> On Mon, 2006-01-16 at 00:24 +0100, Richard Guenther wrote:
> > On Sun, 15 Jan 2006, Daniel Berlin wrote:
> >
> > > On Sun, 2006-01-15 at 22:24 +0100, Tobias Schlüter wrote:
> > > > Richard Guenther wrote:
> > > > > I guess the fix for PR tr
Andrew Pinski wrote:
>
> On Jan 9, 2006, at 2:46 PM, Diego Novillo wrote:
>
>> On Monday 09 January 2006 14:42, Andrew Pinski wrote:
>>
>>> the only passes which do run are cfg creation, expand, and maybe a
>>> couple other simple ones.
>>>
>> I know that. It's expand the one bothering me. Are
Zdenek Dvorak wrote:
> Hello,
>
> during expansion of expressions, gimplification creates a lot of temporary
> variables. VAR_DECLs are fairly large (88 bytes on i686), and
> additionally an annotation (44 bytes on i686) are allocated for each of
> them (some of them even get names, for additiona
"John David Anglin" <[EMAIL PROTECTED]> writes:
| > > This seems pretty clear. C99 requires that storage be allocated
| > >
| > >for uninitialized objects, that an indeterminate value be stored
| > >in the object when the declarator for the object is reached in the
| > >block, that the last-stored
Steven Bosscher wrote:
It has absolutely _noting_ to do with unitialized variables or undefined
behavior. Nothing. Zilch. Zero.
Gr.
Steven
OK, I got the message!
On Mon, 2006-01-16 at 00:24 +0100, Richard Guenther wrote:
> On Sun, 15 Jan 2006, Daniel Berlin wrote:
>
> > On Sun, 2006-01-15 at 22:24 +0100, Tobias Schlüter wrote:
> > > Richard Guenther wrote:
> > > > I guess the fix for PR tree-optimization/22555 could make some
> > > > difference
> > > > if
On Sun, 15 Jan 2006, Daniel Berlin wrote:
> On Sun, 2006-01-15 at 21:49 +0100, Richard Guenther wrote:
> >
> > I guess the fix for PR tree-optimization/22555 could make some difference
> > if fortran uses a lot of structures with embedded arrays. Basically this
> > enables decomposing these stru
On Sun, 15 Jan 2006, Daniel Berlin wrote:
> On Sun, 2006-01-15 at 22:24 +0100, Tobias Schlüter wrote:
> > Richard Guenther wrote:
> > > I guess the fix for PR tree-optimization/22555 could make some difference
> > > if fortran uses a lot of structures with embedded arrays. Basically this
> > > en
On Sun, 2006-01-15 at 22:24 +0100, Tobias Schlüter wrote:
> Richard Guenther wrote:
> > I guess the fix for PR tree-optimization/22555 could make some difference
> > if fortran uses a lot of structures with embedded arrays. Basically this
> > enables decomposing these structures for aliasing purpo
On Sun, 2006-01-15 at 21:49 +0100, Richard Guenther wrote:
> On 1/15/06, Tobias Schlüter <[EMAIL PROTECTED]> wrote:
> >
> > In looking at compiles times, I missed looking at memory usage:
> >
> > Dominique Dhumieres wrote:
> > > On an AMD, the 20060105 build gives
> > >
> > > tree SSA rewrite
Zdenek Dvorak wrote:
> umm... OK. Could you please provide an example (that could perhaps also
> be added to documentation) of how TARGET_EXPRs are used, that would
> explain the rationale behind this semantics?
The canonical example is:
struct S {
S();
S(const S&);
};
S f();
vo
Hello,
> > what exactly is the semantics of the cleanup for TARGET_EXPR?
> > Documentation says:
> >
> >
> >>Often, a @code{TARGET_EXPR} occurs on the right-hand side of an
> >>assignment, or as the second operand to a comma-expression which is
> >>itself the right-hand side of an assignment, et
Zdenek Dvorak wrote:
> Hello,
>
> what exactly is the semantics of the cleanup for TARGET_EXPR?
> Documentation says:
>
>
>>Often, a @code{TARGET_EXPR} occurs on the right-hand side of an
>>assignment, or as the second operand to a comma-expression which is
>>itself the right-hand side of an ass
> >For what it's worth, it annoys me to no end that you have managed to
> >turn more than a day of hard work to understand and fix PR24626 into
> >a discussion about defining undefined behavior. I don't think I'll
> >ever look at HPPA bugs anymore if they don't affect me.
>
> Well we have to under
On Sun, 14 Jan 2006, Ian Lance Taylor wrote:
> gcc assumes that if a variable is uninitialized, it can use any value
> whatsoever for any use of the variable. gcc does not assume that all
> uses of an uninitialized variable must have the same value.
Indeed, the rulings on DR#260 are perfectly cl
John David Anglin wrote:
#include
unsigned char
T (unsigned char x)
{
static int first = 1;
static unsigned char firstx;
if (first)
{
first = 0;
firstx = x;
return ~x;
}
if (x == firstx)
printf ("Behavior is pre GCC 4.0\n");
else
printf ("Behavior is GCC 4.0 an
Steven Bosscher wrote:
On Sunday 15 January 2006 22:13, John David Anglin wrote:
#include
unsigned char
T (unsigned char x)
{
static int first = 1;
static unsigned char firstx;
if (first)
{
first = 0;
firstx = x;
return ~x;
}
if (x == firstx)
printf ("Behavior
On Sunday 15 January 2006 22:13, John David Anglin wrote:
> #include
> unsigned char
> T (unsigned char x)
> {
> static int first = 1;
> static unsigned char firstx;
>
> if (first)
> {
> first = 0;
> firstx = x;
> return ~x;
> }
>
> if (x == firstx)
> printf (
Richard Guenther wrote:
> I guess the fix for PR tree-optimization/22555 could make some difference
> if fortran uses a lot of structures with embedded arrays. Basically this
> enables decomposing these structures for aliasing purposes and should
> generate better code.
It is perhaps noteworthy t
> > This seems pretty clear. C99 requires that storage be allocated
> >
> >for uninitialized objects, that an indeterminate value be stored
> >in the object when the declarator for the object is reached in the
> >block, that the last-stored value be retained for the duration of
> >the block.
> >
> You can also try -fno-tree-salias and see if this helps compile time.
On my G5 I get:
[karma] lin/source% time gfortran -ftime-report -fno-tree-salias -O3
-ffast-math -funroll-loops induct.f90
Execution times (seconds)
garbage collection: 0.51 ( 2%) usr 0.05 ( 2%) sys 0.56 ( 2%) wa
On 1/15/06, Tobias Schlüter <[EMAIL PROTECTED]> wrote:
>
> In looking at compiles times, I missed looking at memory usage:
>
> Dominique Dhumieres wrote:
> > On an AMD, the 20060105 build gives
> >
> > tree SSA rewrite : 0.45 ( 2%) usr 0.02 ( 5%) sys 0.36 ( 2%)
> > wall 35265 kB (27%
It seems like the is a problem with cross-compilation in
the latest snapshot.
First, I configured with languages=c and run make all-gcc
on a new machine. I then installed with make install-gcc.
The next step was to use this compiler to compile newlib.
The third step then was to build libstdc++-v3
Gabriel Dos Reis wrote:
Robert,
Recently you have expressed the opinion that sounds to me that GCC is
taking too much a cavalier approach to "undefined behaviour".
However, as long as you feed that line of thought with reasoning like
above, I don't see how the current trend will change. Or di
Robert Dewar <[EMAIL PROTECTED]> writes:
| John David Anglin wrote:
|
| > This seems pretty clear. C99 requires that storage be allocated
| >
| >for uninitialized objects, that an indeterminate value be stored
| >in the object when the declarator for the object is reached in the
| >block, that th
In looking at compiles times, I missed looking at memory usage:
Dominique Dhumieres wrote:
> On an AMD, the 20060105 build gives
>
> tree SSA rewrite : 0.45 ( 2%) usr 0.02 ( 5%) sys 0.36 ( 2%) wall
> 35265 kB (27%) ggc
> tree SSA incremental : 0.71 ( 4%) usr 0.02 ( 5%) sys
Dominique Dhumieres wrote:
> On an AMD, the 20060105 build gives
> tree SSA verifier : 9.55 (50%) usr 0.09 (23%) sys 9.62 (48%) wall
> 19 kB ( 0%) ggc
> tree STMT verifier: 1.56 ( 8%) usr 0.00 ( 0%) sys 1.61 ( 8%) wall
> 0 kB ( 0%) ggc
> TOTAL : 1
In the new snapshot (20060114), there seems to be changes
to default exception handling in C++. When I tried to build libstdc++-v3
with the last configuration, the compiler complains that no
exception method is specified. This problem is solved by giving
--enable-sjlj-exceptions option to config
On an AMD, the 20060105 build gives
[scala] gfortran/2006> time irun/bin/gfortran -ftime-report -O3 -ffast-math
-funroll-loops induct.f90
Execution times (seconds)
garbage collection: 0.39 ( 2%) usr 0.01 ( 2%) sys 0.40 ( 2%) wall
0 kB ( 0%) ggc
callgraph construction: 0.09 (
John David Anglin wrote:
As far as I know, GCC doesn't support a trap representation for
"int *" types. Thus, an "indeterminate value" is simply an unspecified
value.
You can't reason this way either. The implementation may behave "as if" the
variable contained a trap representation regardl
John David Anglin wrote:
This seems pretty clear. C99 requires that storage be allocated
for uninitialized objects, that an indeterminate value be stored
in the object when the declarator for the object is reached in the
block, that the last-stored value be retained for the duration of
the bloc
> Are you building with --enable-checking (the default)?
On AMD I am using the François-Xavier's builds. On my G5 I use a patched
version of the Fink's info file, the answer is probably in
ConfigureParams: --prefix=%p/lib/gcc4
--enable-languages=c,c++,fortran,objc,java --infodir='${prefix}/share
I've looked at the draft version of C99 that I have and it's
clear that there are some significant differences between the
draft that I have and the final. So, take what I say with a
grain of salt ;)
> I believe Dave's program results in undefined behavior by implication.
> That is, even though C
On Sun, Jan 15, 2006 at 12:25:51PM -0500, Jack Howarth wrote:
> Joseph,
> Thanks for the hint. Correcting the timestamps with...
>
> contrib/gcc_update --touch
>
> ...eliminated the failure in _Pragma.c. However I am still baffled as
> to why this was necessary since I was building from a
> From: Ian Lance Taylor
>> Paul Schlie <[EMAIL PROTECTED]> writes:
>> Given that it would appear that the only time the compiler may attempt
>> to optimize the allocation/use of an un-initialized variable, is when it
>> knows for certain it hasn't been initialized; might it be preferable to
>> th
[ Added gcc@gcc.gnu.org to the CC list and included Dominique's mail in full, as
the problem might well be in the common code. ]
Quoting Dominique Dhumieres <[EMAIL PROTECTED]>:
> I have the following timing for the compilation of the polyhedron tests
> on a 1.8Ghz G5 with:
>
> gfortran -w -O3
[..snip..]
> At some stage it was decided to pad error codes so that they were equal in
> legnth(string wise). I don't know why, but perhaps it can be useful to know.
I think this will introduce problems when more messages are added
overtime or it wont if the length is large enough. Besides that
Gabriel Dos Reis wrote:
> Hi,
>
> We have the following code in decl.c:check_initializer():
>
>
> if (TREE_CODE (decl) == CONST_DECL)
> {
> gcc_assert (TREE_CODE (decl) != REFERENCE_TYPE);
>
> DECL_INITIAL (decl) = init;
>
> gcc_assert (init != NULL_TREE);
> ini
Paul Schlie wrote:
- Thank you, I'll give it a try; although may attempt to name it:
-force-deterministic-semantics
Please don't, that's a dubious term, since it is
contentious, and detracts from the useful nature of this
proposition.
presuming its longer term intent would be to warrant
> From: Michael Veksler <[EMAIL PROTECTED]>
> In theory you could be right:
> ...
> Now, consider the case where the compiler can prove that
> is_debug_enabled(i) is always zero. So `a' is never initialized.
> Why can't the compiler assume that is_debug_verbose_enabled(i) is
> zero as well? By igno
Ian Lance Taylor wrote:
It would be perfectly reasonable to have a command line option to
initialize automatic variables to zero, of course.
Ada has a pragma Normalize_Scalars that causes all scalars to be
normalized (to an out of range
value where possible).
Even more useful is the GNAT
Hi,
We have the following code in decl.c:check_initializer():
if (TREE_CODE (decl) == CONST_DECL)
{
gcc_assert (TREE_CODE (decl) != REFERENCE_TYPE);
DECL_INITIAL (decl) = init;
gcc_assert (init != NULL_TREE);
init = NULL_TREE;
}
If decl is a CONST_DECL, t
Joseph,
Thanks for the hint. Correcting the timestamps with...
contrib/gcc_update --touch
...eliminated the failure in _Pragma.c. However I am still baffled as
to why this was necessary since I was building from a clean svn pull
of the gcc 4.1 branch using svn 1.3.0. Is svn that broken th
Paul Schlie <[EMAIL PROTECTED]> writes:
> Given that it would appear that the only time the compiler may attempt
> to optimize the allocation/use of an un-initialized variable, is when it
> knows for certain it hasn't been initialized; might it be preferable to
> then assign it a deterministic che
On Sunday 15 January 2006 10:59, rubicant rubicant wrote:
> I'm trying to suggest that GCC should have error codes to describe
> errors, continue reading on if you like the idea or not ;-)
>
> THE IDEA:
> The idea is to make GCC better when it comes to error reporting. This
> will be done using so
On Jan 15, 2006, at 10:14 AM, rubicant rubicant wrote:
[..snip..]
1) What if the same warning or error message comes from two places?
Your numbering system would make this hard to identify. I would
suggest gathering up all the errors and warnings from all the files,
remove duplicates, then p
rubicant rubicant <[EMAIL PROTECTED]> writes:
[...]
| The `c' was a example for the C programming language, so the
| error/warning message gets into a category rather indicating the
| program and do you have any idea how they do it in AIX?
How is that different from the named-daignostic switch i
[..snip..]
> 1) What if the same warning or error message comes from two places?
> Your numbering system would make this hard to identify. I would
> suggest gathering up all the errors and warnings from all the files,
> remove duplicates, then proceed with the numbering.
That is the plan, only t
Perry Smith <[EMAIL PROTECTED]> writes:
> 2) AIX (yea, I know thats a ick term) attempts to have a consistent
> numbering system across the whole platform. This is done by
> splitting the number into two pieces: -bb: where is
> assigned to a particular program and bbb is th
Two comments:
1) What if the same warning or error message comes from two places?
Your numbering system would make this hard to identify. I would
suggest gathering up all the errors and warnings from all the files,
remove duplicates, then proceed with the numbering. Or... it may be
tha
Paul Schlie <[EMAIL PROTECTED]> writes:
| Thank you for the explanation.
|
| Given that it would appear that the only time the compiler may attempt
| to optimize the allocation/use of an un-initialized variable, is when it
| knows for certain it hasn't been initialized; might it be preferable to
Paul,
In theory you could be right:
Quoting Paul Schlie <[EMAIL PROTECTED]>:
[...]
> Given that it would appear that the only time the compiler may attempt
> to optimize the allocation/use of an un-initialized variable, is when it
> knows for certain it hasn't been initialized; might it be prefer
Ian Lance Taylor writes:
| Paul Schlie <[EMAIL PROTECTED]> writes:
|
| > As a simple example, although x may be indeterminate -1 < sin(x) < +1
| > is unconditionally true, as must be tan(x) = sin(x)/cos(x), and x^x = 0;
|
| No, the ISO C standard is clear that an uninitialized variable may
Andreas Schwab <[EMAIL PROTECTED]> writes:
| Steven Bosscher <[EMAIL PROTECTED]> writes:
|
| > A more explicit statement about using uninitialized variables is in
| > appendix J.2 ("Undefined behavior"):
| >
| > "The behavior is undefined in the following circumstances:
| > (...snip...)
| > - Th
Thank you for the explanation.
Given that it would appear that the only time the compiler may attempt
to optimize the allocation/use of an un-initialized variable, is when it
knows for certain it hasn't been initialized; might it be preferable to
then assign it a deterministic cheap value such as
For a mmu-less embedded target, I would like to generate code to run at
a fixed location in read-only memory, but with the data segment located
anywhere in memory. Therefore, the accesses to the data segement must go
through an indirection table (GOT).
I do not think that the option exists for my
I'm trying to suggest that GCC should have error codes to describe
errors, continue reading on if you like the idea or not ;-)
THE IDEA:
The idea is to make GCC better when it comes to error reporting. This
will be done using so called error codes which then can be looked up
in a properly
formatte
Paul Schlie wrote:
(or might it actually make substantially more sense for a compiler to
do what the code logically specified in absents of any more reliably
predictable alternative; under the premise that consistency is good.)
Paul, the semantics of C programs is given by the C standard, no
Ian Lance Taylor wrote:
Paul Schlie <[EMAIL PROTECTED]> writes:
As a simple example, although x may be indeterminate -1 < sin(x) < +1
is unconditionally true, as must be tan(x) = sin(x)/cos(x), and x^x = 0;
No, the ISO C standard is clear that an uninitialized variable may be
set t
So following through with this philosophy to its natural conclusion,
all programs which contain reachable non-portable undefined code should
have arbitrary behavior? Or should arbitrary potentially catastrophic
otherwise unexpected behavior only be invoked upon reaching such code?
(or might it act
Paul Schlie <[EMAIL PROTECTED]> writes:
> As a simple example, although x may be indeterminate -1 < sin(x) < +1
> is unconditionally true, as must be tan(x) = sin(x)/cos(x), and x^x = 0;
No, the ISO C standard is clear that an uninitialized variable may be
set to a trap representation (6.7.8,
Steven Bosscher <[EMAIL PROTECTED]> writes:
> A more explicit statement about using uninitialized variables is in
> appendix J.2 ("Undefined behavior"):
>
> "The behavior is undefined in the following circumstances:
> (...snip...)
> - The value of an object with automatic storage duration is used
Paul Schlie wrote:
tools which indiscriminately alter non-portable observable
behavior during optimization aren't doing anyone any favors.
What we want from a compiler is that it correctly executes
and interprets correct programs. What we want from
programmers is correct programs. Programmer
On Sunday 15 January 2006 10:35, Robert Dewar wrote:
> >- I believe that it is a grave mistake to conclude that a well defined
> > semantic operation on an indeterminate value, has undefined semantics.
>
> Well the standards committee made the grave mistake if it is one, so if
> you want to challe
tools which indiscriminately alter non-portable observable
behavior during optimization aren't doing anyone any favors.
conversely, tools which focus on optimizing portable behavior, while
attempting to preserve non-portable behavior, are always preferable.
> From: Robert Dewar <[EMAIL PROTECTED]
Bernd Trog wrote:
> Hello,
Hello Bernd,
> whats the status of -fstack-usage?
>
> Will it output the real or worst case stack usage?
The latter in any case, although I'm not sure what you mean by "real"
stack usage. Could you please enligthen ?
Olivier
Paul Schlie wrote:
Ian Lance Taylor writes:
gcc assumes that if a variable is uninitialized, it can use any value
whatsoever for any use of the variable. gcc does not assume that all
uses of an uninitialized variable must have the same value.
It is of course possible to write a correct progra
> Ian Lance Taylor writes:
>
> gcc assumes that if a variable is uninitialized, it can use any value
> whatsoever for any use of the variable. gcc does not assume that all
> uses of an uninitialized variable must have the same value.
>
> It is of course possible to write a correct program which us
72 matches
Mail list logo
