Re: -Wextra and unsigned template parameters
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. Is this a bug?
Re: CC0 questions
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 set cc0 (compare (x y)) condjump1 set cc0 (compare (x y)) condjump2 and converts it to set cc0 (compare (x y)) condjump1 condjump2 But it only does this if the backend has support for describing which insns set cc0 implicitly. R.
install Gcc on SuSE Linux 10
Hi! I'm new of Linux and I'm not good. How can I install Gcc if I don't have any C compiler?
Re: install Gcc on SuSE Linux 10
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 group. -- GJ
Re: -Wextra and unsigned template parameters
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 types. A code
| example is included below. Does anyone know how best
| to supress this warning without resorting to removing
| the condition or turning off -Wextra? Thank you in
| advance.
|
| template
| struct foo {
| foo(T bar) { if (bar >= 0) bar = 1; }
| };
|
| If foo is instantiated elsewhere then
| this check could still be useful.
This is an issue as well for gcjx -- it can be annoying.
-- Gaby
Fortran frontend prerequisites
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 experience) what might have cause the problem? Someone experts on the gcc mailing list said something like:"the prerequisite of fortran frontend is not found on your machine". If that's the problem, how can I find the rules of prerequisites and install them? Thanks, Sean _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Fortran frontend prerequisites
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.org/install/configure.html > > Could you please guess (based on your experience) what might have cause the > problem? > > Someone experts on the gcc mailing list said something like:"the > prerequisite of fortran frontend is not found on your machine". If that's > the problem, how can I find the rules of prerequisites and install them? This is a question for gcc-help; please don't send it to [EMAIL PROTECTED] You could find the rules of prerequisites by reading the fine manual; it's step one in the installation manual, and configuration is step 3. http://gcc.gnu.org/install/prerequisites.html -- Daniel Jacobowitz CodeSourcery
Re: -Wextra and unsigned template parameters
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 types...
> |
> | template
> | struct foo {
> | foo(T bar) { if (bar >= 0) bar = 1; }
> | };
On Wed, May 10, 2006 at 01:38:29PM +0200, Gabriel Dos Reis wrote:
> This is an issue as well for gcjx -- it can be annoying.
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 bar is a template argument and suppress the warning in that case.
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 the type
depends on a template, we lose the warning in this case as well;
after all, nothing stops someone from writing
class C {
public:
int size() const;
...
};
void use(const C&);
Re: -Wextra and unsigned template parameters
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 helpful, but
| > | it throws this error even for templated types...
| > |
| > | template
| > | struct foo {
| > | foo(T bar) { if (bar >= 0) bar = 1; }
| > | };
|
| On Wed, May 10, 2006 at 01:38:29PM +0200, Gabriel Dos Reis wrote:
| > This is an issue as well for gcjx -- it can be annoying.
|
| 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.
Indeed.
| Possibly there's a way to determine that the
| type of bar is a template argument and suppress the warning in that case.
|
| 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 the type
| depends on a template, we lose the warning in this case as well;
| after all, nothing stops someone from writing
The issue is not simple, as you note. Still, part of the noise from
bulding gcjx is irritating when one looks at the source code and
realizes "oh, but the compiler should know that warning is not
interesting" :-) The tricky bit is in defining "interesting".
-- Gaby
Re: -Wextra and unsigned template parameters
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
Re: -Wextra and unsigned template parameters
>
>
> 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 types...
> > |
> > | template
> > | struct foo {
> > | foo(T bar) { if (bar >= 0) bar = 1; }
> > | };
>
> On Wed, May 10, 2006 at 01:38:29PM +0200, Gabriel Dos Reis wrote:
> > This is an issue as well for gcjx -- it can be annoying.
>
> 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 bar is a template argument and suppress the warning in that case.
Why are we talking so much in this thread and not fixing the bug?
Anyways this is PR 11856.
-- Pinski
Re: -Wextra and unsigned template parameters
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 the type
depends on a template, we lose the warning in this case as well;
after all, nothing stops someone from writing
class C {
public:
int size() const;
...
};
void use(const C&);
My STL may be a bit rusty...if you don't define size(), what is its
return type?. Also, there should be no warning in this example, am I
wrong?
Re: -Wextra and unsigned template parameters
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 bar is a template argument and suppress the warning in that case. > > Why are we talking so much in this thread and not fixing the bug? Because there is a question about what the correct fix is.
Re: default_secondary_reload: class vs scratch_class
> 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. The default hook for secondary_reload uses SECONDARY_RELOAD_CLASS but assumes it's going to return the same class as the pattern (in which case, why bother defining it?). Since we're only allowed one reload pattern per mode, this seems like an artificial limitation.
Re: VLA/VM [*] bug fixes for C
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.
Re: VLA/VM [*] bug fixes for C
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 eval. typeof should evaluate its argument iff variably modified. Thus typeof should evaluate a pointer to VLA argument, whereas sizeof only evaluates VLAs themselves. That's the conclusion I arrived at and put in a comment in gnu99-static-1.c. -- Joseph S. Myers [EMAIL PROTECTED]
Re: VLA/VM [*] bug fixes for C
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, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: VLA/VM [*] bug fixes for C
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()])g())", clearly you need to evaluate the call f() in order to know the type being referred to. As such, I think the logical conclusion is to evaluate the argument of typeof whenever of VM type (and so evaluate the call g() as well). With VLAs, type names (in declarations, sizeof, typeof, casts and compound literals) can need to be executed for their side-effects. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: VLA/VM [*] bug fixes for C
"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 be able to eval anything? | | If you have "typeof ((int (*)[f()])g())", clearly you need to evaluate the | call f() in order to know the type being referred to. As such, I think | the logical conclusion is to evaluate the argument of typeof whenever of | VM type (and so evaluate the call g() as well). | | With VLAs, type names (in declarations, sizeof, typeof, casts and compound | literals) can need to be executed for their side-effects. well, people may just switch to DML :-) C used to be simple. -- Gaby
mthumb: generate a tail-call
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
Re: default_secondary_reload: class vs scratch_class
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 class based on the
> registers that need reloading.
>
> The default hook for secondary_reload uses SECONDARY_RELOAD_CLASS but
> assumes it's going to return the same class as the pattern (in which
> case, why bother defining it?). Since we're only allowed one reload
> pattern per mode, this seems like an artificial limitation.
Well, first I should note that SECONDARY_RELOAD_CLASS is now
considered to be the old way of doing things. Have you considered
switching to TARGET_SECONDARY_RELOAD?
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 if class is a subset of scratch_class.
You should run any patch past Joern, though.
Ian
Re: default_secondary_reload: class vs scratch_class
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
Re: mthumb: generate a tail-call
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 have to convert the call to indirect. It's probably a space loss, stack usage improvement, and I'm not sure offhand about performance - may be a bit slower. -- Daniel Jacobowitz CodeSourcery
Re: default_secondary_reload: class vs scratch_class
> 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 patches I need to test. I don't currently have the resources to do that kind of change, and there are a *lot* of ports that still use the macros.
Re: mthumb: generate a tail-call
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
Re: default_secondary_reload: class vs scratch_class
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 if class is a subset of scratch_class.
I'm afraid that this is a case that the old code allowed, but cannot be
handled with default_secondary_reload.
In http://gcc.gnu.org/ml/gcc/2006-05/msg00247.html, DJ Delorie wrote:
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.
The default hook for secondary_reload uses SECONDARY_RELOAD_CLASS but
assumes it's going to return the same class as the pattern (in which
case, why bother defining it?).
When SECONDARY_RELOAD_CLASS is not a subset of the scratch class, you'll
get another reload.
Since we're only allowed one reload
pattern per mode, this seems like an artificial limitation.
The class for the temporary register is taken later from the constraint
of the scratch register in the pattern, so if you relaxed the sanity check,
you'd end up with a GENERAL_REGS reload instead of a DATA_OR_EXTENDED_REGS
one. To fix this in generic code we'd have to make a copy of the pattern
with a new icode and a patched constraint... Since no one else has
complained yet, I think it will be easier to convert the affected ports.
In http://gcc.gnu.org/ml/gcc/2006-05/msg00257.html, DJ Delorie wrote:
In my case, I'm just trying to get the am33 port to function, because
I have some patches I need to test. I don't currently have the
resources to do that kind of change, and there are a *lot* of ports
that still use the macros.
You you can't use the same class in the reload{in,out} patterns
as in SECONDARY*(_RELOAD_CLASS, this indicates that the old way of doing
things already had problems. I think you'll find that this is not
generally the case for the ports that still use SECONDARY*_RELOAD_CLASS.
A quick-and-dirty way to do the conversion is to take all the reload
patterns with overloaded scratch register classes, and split them into
patterns for one SECONDARY_RELOAD_CLASS output each
Then you make a copy of default_secondary_reload_class and modify the
bit that sets icode to pick the appropriate pattern.
* **
Re: default_secondary_reload: class vs scratch_class
You should run any patch past Joern, though.
Re: mips: -G0 vs __dso_handle
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, and m32r targets.
Index: crtstuff.c
===
--- crtstuff.c (revision 113691)
+++ crtstuff.c (working copy)
@@ -225,6 +225,9 @@
in one DSO or the main program is not used in another object. The
dynamic linker takes care of this. */
+#if defined(__mips__) || defined(__iq2000__) || defined(__m32r__)
+extern void *__dso_handle __attribute__ ((__section__ (".sdata")));
+#endif
#ifdef HAVE_GAS_HIDDEN
extern void *__dso_handle __attribute__ ((__visibility__ ("hidden")));
#endif
www pages outdated
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 on the www subdomain need to be updated or the about page needs to be changed. If the www pages are no longer updated, they should redirect to gcc.gnu.org or at least reflect that they aren't current and link to gcc.gnu.org. This could be very confusing to visitors if not corrected. - HeroreV __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: mips: -G0 vs __dso_handle
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__) || defined(__iq2000__) || defined(__m32r__)
> +extern void *__dso_handle __attribute__ ((__section__ (".sdata")));
> +#endif
...this should be handled by some tm.h macro though, like the other
conditional stuff in crtstuff.c. I'm not sure there's any precedent
for hard-coding the architectures in crtstuff.c itself. (Not insisting,
just raising the question.)
Richard
