DJ Delorie <[EMAIL PROTECTED]> writes:
> How about this? Tested under mipsisa64-elf with no regressions. The
> other two I found by inspection; they're the only other two that have
> .sdata and use -G 0.
Looks good to me FWIW, although I can't approve it. I wonder if...
> +#if defined(__mips__
The pages at http://www.gnu.org/software/gcc/ are
several months old, even though the page at
http://gcc.gnu.org/about.html says:
> The pages on gcc.gnu.org are updated "live" (that
> is, directly after a change has been made);
> www.gnu.org is updated once a day at 4:00 -0700
> (PDT).
The pages
How about this? Tested under mipsisa64-elf with no regressions. The
other two I found by inspection; they're the only other two that have
.sdata and use -G 0.
2006-05-09 DJ Delorie <[EMAIL PROTECTED]>
* crtstuff.c: Ensure that __dso_handle is placed in .sdata for
mips, iq2000
In http://gcc.gnu.org/ml/gcc/2006-05/msg00254.html, Ian Lance Taylor wrote:
That said, while it makes sense to me that SECONDARY_RELOAD_CLASS and
the reload_{in,out} instruction should be in synch--that was one of
the flaws of the old scheme, really--I can't think of anything that
would go wrong
On Wednesday 10 May 2006 21:38, Shaun Jackman wrote:
> What optimisation option is needed to prod arm-elf-gcc -mthumb to
> generate a tail call? ARM works as expected.
Thumb only has very limited (256 byte) direct branch offsets, so tail calls
aren't possible/useful.
Paul
> I'd hesitate to apply patches to default_secondary_reload.
Even if it's wrong?
> If your port triggers any of the sanity checks, convert it to the
> new infrastructure, as it provides a much better interface.
In my case, I'm just trying to get the am33 port to function, because
I have some pa
On Wed, May 10, 2006 at 02:38:30PM -0600, Shaun Jackman wrote:
> What optimisation option is needed to prod arm-elf-gcc -mthumb to
> generate a tail call? ARM works as expected.
It's not yet supported. Remember, bl has a long range but clobbers lr, and
there's no long branch instruction, so you h
Ian Lance Taylor wrote:
You should run any patch past Joern, though.
I'd hesitate to apply patches to default_secondary_reload. If your port
triggers any of the sanity checks, convert it to the new infrastructure,
as it provides a much better interface.
Bernd
DJ Delorie <[EMAIL PROTECTED]> writes:
> > What reason is there to have scratch_class be something else?
>
> SECONDARY_RELOAD_CLASS has the option of limiting the reload class.
> The mn10300 has a generic SImode reload_in that allows GENERAL_REGS,
> but SECONDARY_RELOAD_CLASS specifies a smaller
What optimisation option is needed to prod arm-elf-gcc -mthumb to
generate a tail call? ARM works as expected.
Please cc me in your reply. Thanks!
Shaun
arm-elf-gcc (GCC) 4.1.0
$ cat
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Wed, 10 May 2006, Andreas Schwab wrote:
|
| > Mike Stump <[EMAIL PROTECTED]> writes:
| >
| > > Speaking of typeof, should typeof (vla) follow the same rules as for
| > > sizeof (vla)? vla, evaluate, otherwise, no eval.
| >
| > How would typeof
On Wed, 10 May 2006, Andreas Schwab wrote:
> Mike Stump <[EMAIL PROTECTED]> writes:
>
> > Speaking of typeof, should typeof (vla) follow the same rules as for
> > sizeof (vla)? vla, evaluate, otherwise, no eval.
>
> How would typeof be able to eval anything?
If you have "typeof ((int (*)[f()])
Mike Stump <[EMAIL PROTECTED]> writes:
> Speaking of typeof, should typeof (vla) follow the same rules as for
> sizeof (vla)? vla, evaluate, otherwise, no eval.
How would typeof be able to eval anything?
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfel
On Wed, 10 May 2006, Mike Stump wrote:
> On May 8, 2006, at 2:30 PM, Joseph S. Myers wrote:
> > > void foo11(typeof (int (*)(int o[*])) i);
> >
> > I think that's valid gnu99.
>
> Speaking of typeof, should typeof (vla) follow the same rules as for sizeof
> (vla)? vla, evaluate, otherwise, no e
On May 8, 2006, at 2:30 PM, Joseph S. Myers wrote:
void foo11(typeof (int (*)(int o[*])) i);
I think that's valid gnu99.
Speaking of typeof, should typeof (vla) follow the same rules as for
sizeof (vla)? vla, evaluate, otherwise, no eval.
> What reason is there to have scratch_class be something else?
SECONDARY_RELOAD_CLASS has the option of limiting the reload class.
The mn10300 has a generic SImode reload_in that allows GENERAL_REGS,
but SECONDARY_RELOAD_CLASS specifies a smaller class based on the
registers that need reloading.
On Wed, May 10, 2006 at 12:30:33PM -0400, Andrew Pinski wrote:
> > I think that the warning is useful if the comparison is *always* true for
> > any call of foo. But here, whether the test is redundant or not
> > depends on the type of bar. Possibly there's a way to determine that the
> > type of
On 10/05/06, Joe Buck <[EMAIL PROTECTED]> wrote:
But then I just thought of another case:
template
struct foo {
foo(const Container& bar) { if (bar.size() >= 0) use(bar); }
};
For any STL-compliant container the test is redundant. But if
we put in a rule saying to suppress the warning if
>
>
> Aliesha Finkel <[EMAIL PROTECTED]> writes:
> > | Hi, I'm using -Wextra (-W) to compile my code, one
> > | feature of which is throwing a warning when an
> > | unsigned type is checked for >= 0 since it's always
> > | true. In general I find this to be very helpful, but
> > | it throws this
Joe Buck <[EMAIL PROTECTED]> writes:
[...]
| class C {
| public:
| int size() const;
many people, including "dinosaure" C++ users, wish the standard containers
did not have unsigned return type for size().
-- Gaby
Joe Buck <[EMAIL PROTECTED]> writes:
| Aliesha Finkel <[EMAIL PROTECTED]> writes:
| > | Hi, I'm using -Wextra (-W) to compile my code, one
| > | feature of which is throwing a warning when an
| > | unsigned type is checked for >= 0 since it's always
| > | true. In general I find this to be very h
Aliesha Finkel <[EMAIL PROTECTED]> writes:
> | Hi, I'm using -Wextra (-W) to compile my code, one
> | feature of which is throwing a warning when an
> | unsigned type is checked for >= 0 since it's always
> | true. In general I find this to be very helpful, but
> | it throws this error even for t
On Wed, May 10, 2006 at 02:24:04PM +, sean yang wrote:
> I made some modification on GCC 4.0.2 (basically, I added a simple pass)
> and compiled it to binary.
>
> But I realized that the GCC I built does not include Fortran frontend. I
> think I followed the standard steps
> http://gcc.gnu.
I made some modification on GCC 4.0.2 (basically, I added a simple pass) and
compiled it to binary.
But I realized that the GCC I built does not include Fortran frontend. I
think I followed the standard steps
http://gcc.gnu.org/install/configure.html
Could you please guess (based on your exp
Aliesha Finkel <[EMAIL PROTECTED]> writes:
| Hi, I'm using -Wextra (-W) to compile my code, one
| feature of which is throwing a warning when an
| unsigned type is checked for >= 0 since it's always
| true. In general I find this to be very helpful, but
| it throws this error even for templated t
On Wednesday 10 May 2006 12:33, [EMAIL PROTECTED] wrote:
> Hi! I'm new of Linux and I'm not good.
>
> How can I install Gcc if I don't have any C compiler?
install rpm package for your distribution, or download gcc in binary form.
this question doesn't belong here, so please ask on SuSE related gro
Hi! I'm new of Linux and I'm not good.
How can I install Gcc if I don't have any C compiler?
On Tue, 2006-05-09 at 22:16, Richard Kenner wrote:
> Can there be two consecutive insns that use cc0 after cc0 is set?
>
> No.
Yes. But only very very late in the compilation, once all normal
re-ordering and optimization has been completed. I think it's probably
final that folds out
On 10/05/06, Aliesha Finkel <[EMAIL PROTECTED]> wrote:
template
struct foo {
foo(T bar) { if (bar >= 0) bar = 1; }
};
If foo is instantiated elsewhere then
this check could still be useful.
My opinion is that since it may be instantiated as an signed type,
then warning is pointless there.
29 matches
Mail list logo
