Russ Allbery writes:
> Yeah. But I suspect it was a mistaken statement. The subject line from
> the referenced comp.lang.c thread was:
> c99 and the lack of warnings when int operations are applied to a bool
> which I think is best caught by the conversion *to* bool when the result
> is s
Gabriel Dos Reis writes:
> I can easily see why an implicit conversion from int to bool might cause
> a problem, even if that is what the language standard mandates -- just
> look at the most common misuses of strcmp. But, that is not what the
> proposer requested, which got me scratching my hea
With GCC 4.7 and the following program:
--
struct byte
{
unsigned char _;
byte () = default;
explicit operator unsigned char () { return _; }
};
struct wyde
{
unsigned short _;
wyde () = default;
constexpr wyde (unsigned short r) : _(r) { }
};
struct foo
{
byte one;
wyde two
On Tue, Mar 27, 2012 at 9:20 PM, Russ Allbery wrote:
> Gabriel Dos Reis writes:
>
>> I am trying to understand what the real issue is here. Do you want
>> -Wimplicit-char-to-int to? -Wimplicit-short-to-int? If not, why?
>> where to stop?
>
> I think it's more about conversion *to* bool than fr
Gabriel Dos Reis writes:
> I am trying to understand what the real issue is here. Do you want
> -Wimplicit-char-to-int to? -Wimplicit-short-to-int? If not, why?
> where to stop?
I think it's more about conversion *to* bool than from bool, and it
catches places where code has been partly conve
> Hi,
>>
>> It would be nice if there was a
>>
>> -Wimplicit_bool
>>
>> that was enabled in -Wall which complained about these sorts of
>> operations. In particular
>> it would warn any time a bool was implicitly promoted to an int.
>
I am trying to understand what the real issue is here. Do yo
Hi,
It would be nice if there was a
-Wimplicit_bool
that was enabled in -Wall which complained about these sorts of
operations. In particular
it would warn any time a bool was implicitly promoted to an int.
first blush your message should be a Bugzilla PR, this way the request
doesn't ris
The C99 bool data type, and the similar type in C++, currently (v
4.5.2) do not generate
warnings for any of these sorts of operations:
bool b;
b = 3;
b++;
b += 2;
if(b == 3)
etc.
This can lead to a lot of hidden mischief because a variable declared
far away may look like
an intege
Hello all,
My name is Thibault Raffaillac, CS degree student at Kungliga Tekniska
Högskolan,
Stockholm, Sweden (in double-degree partnership with Ecole Centrale Marseille,
France).
GCC currently provides no concise way to inform the user whether it applied an
expected optimization (ie, it "unders
On Tue, Mar 27, 2012 at 8:59 PM, Mike Stump wrote:
>> and errors from the middle end are mostly for exotic
>> code (involving asm()s and the like). Bailing out after parse errors
>> is therefore IMHO the right thing to do for the common case.
>
> Some are for very exotic things, yes, but not all o
On Mar 26, 2012, at 1:56 PM, Steven Bosscher wrote:
> This patch is one way to address PR44982.
That's a great idea, I like it. There is only one problem that I know of that
prevents it from going in now. We emit errors/warnings from below finalize and
there is a feature in which we emit all t
On 2012-03-26 11:15:37 -0500, Steven Munroe wrote:
> On Mon, 2012-03-26 at 12:26 +0200, Vincent Lefevre wrote:
> > Then concerning double-double vs quad (binary128) for the "long double"
> > type, I think that quad would be more useful, in particular because
> > it has been standardized and it is a
Hi Basile,
Basile Starynkevitch skribis:
> Do we have (e.g. for plugin makers) a nice way to know if a given GCC
> distribution was
> compiled in C or in C++ mode?
I’ve written an Autoconf macro that does that:
http://gcc.gnu.org/ml/gcc/2012-03/msg00240.html
Thanks,
Ludo’.
Hi,
On Mon, Mar 26, 2012 at 10:56 PM, Steven Bosscher wrote:
Hello,
This patch is one way to address PR44982. I see no good reason to
cgraph_finalize_compilation_unit if there were parse errors. As Richi
already pointed out, GCC traditionally has proceeded after parse
errors to preserve warnin
On Tue, Mar 27, 2012 at 8:01 AM, Bin.Cheng wrote:
> On Mon, Mar 26, 2012 at 3:27 PM, Richard Guenther
> wrote:
>> On Sun, Mar 25, 2012 at 2:42 PM, Bin.Cheng wrote:
>>> Hi,
>>> In tree-complex.c's function expand_complex_comparison, gcc just
>>> expand comparison on complex
>>> operands into comp
On Mon, Mar 26, 2012 at 10:56 PM, Steven Bosscher wrote:
> Hello,
>
> This patch is one way to address PR44982. I see no good reason to
> cgraph_finalize_compilation_unit if there were parse errors. As Richi
> already pointed out, GCC traditionally has proceeded after parse
> errors to preserve wa
16 matches
Mail list logo
