On Fri, 11 Jan 2008 09:59:41 -0800, Brian D. McGrew wrote:
>We're trying to move to 64-Bit now and this same code that has compiled
> for years is barking about operators cannot be overloaded.
Please stick to gcc-help, as gcc is the wrong list for such questions.
Philipp
On Sat, Jan 12, 2008 at 07:20:03AM +0100, Hans-Peter Nilsson wrote:
> Or, another attribute. Name? Maybe "always_extern", but I'm
> not sure that's as intuitive and obvious as "noinline". I don't
> like the perhaps immediately obvious "always_call", because I
> think the calls should be deleted
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> I'm inclined to approve this if -Wprecedence stays in -Wall, but I'd
> like to hear if anybody else has anything to say.
The name of the option is rather poor, IMHO. -Wparentheses warns about
precedences, so what is the difference to -Wprecedence?
(Yeah, new attributes "impure" and/or "nonconst" would solve
this, but only for IPA and there's already the existing option
and asm I mentioned. And if you say different files/compilation
units, I say LTO.)
I think the asm is your best bet.
Paolo
Andreas Schwab wrote:
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
I'm inclined to approve this if -Wprecedence stays in -Wall, but I'd
like to hear if anybody else has anything to say.
The name of the option is rather poor, IMHO. -Wparentheses warns about
precedences, so what is the differe
On Jan 12, 2008 7:20 AM, Hans-Peter Nilsson <[EMAIL PROTECTED]> wrote:
> Also known as "nooo, it's not *inlined*, it's just the call
> being removed because the called function was found to be
> pure/const". :)
>
> This happens when you try to synthesize executable test-cases
> and you need e.g. a
Adrián Bravo Navarro writes:
> I come to you looking for some light ;) We are developing an
> application that needs to link statically math.h. I've been looking
> for libm.a for Tru64 Alpha with no success at all. System comes
> with .so so but i think it's not possible converting .so into .a
On 11/01/2008, Mark Mitchell wrote:
>
> Exactly so. I think that we have two kinds of pedwarns: those that are
> pedantic in the sense we use for C (like, that there cannot be a naked
> semicolon at the top-level of a file, or that "long long" is not in
> C++98) and those that refer to semanticall
On 12/01/2008, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> On 11/01/2008, Mark Mitchell wrote:
> >
> > Exactly so. I think that we have two kinds of pedwarns: those that are
> > pedantic in the sense we use for C (like, that there cannot be a naked
> > semicolon at the top-level of a file, or tha
On 12/01/2008, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
>
> Here is an initial patch implementing some of your proposals. I used
> pederror as the name of the function. That is, it is an error unless
> fpermissive is given.
Ah, very fast! :-)
I was just starting somethign similar, I provisio
On 12/01/2008, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> On 12/01/2008, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> >
> > Here is an initial patch implementing some of your proposals. I used
> > pederror as the name of the function. That is, it is an error unless
> > fpermissive is given.
>
11 matches
Mail list logo
