Herman Geza [EMAIL PROTECTED] writes:
[...]
What is the correct way to do this:
void setNaN(float v) {
reinterpret_castint(v) = 0x7f81;
}
without a type-prunning warning? I cannot use the union trick here
Why? Won't the following work?
void setNaN(float v) {
union { float
Chris Lattner [EMAIL PROTECTED] writes:
On Jun 22, 2007, at 1:41 AM, Sergei Organov wrote:
Herman Geza [EMAIL PROTECTED] writes:
[...]
What is the correct way to do this:
void setNaN(float v) {
reinterpret_castint(v) = 0x7f81;
}
without a type-prunning warning? I cannot use
Manuel López-Ibáñez [EMAIL PROTECTED] writes:
On 30 May 2007 16:12:12 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Joe Buck [EMAIL PROTECTED] writes:
How about: have -Wall still set warn_strict_overflow
to 1, but to have -Wall -Wstrict-overflow *or* -Wstrict-overflow -Wall
*or* just
Hello,
$ g++ -c err.cc
err.cc:7: error: prototype for 'void Cint::foo(const int)' does not match
any in class 'Cint'
err.cc:3: error: candidate is: void CT::foo(const T) [with T = int]
err.cc:7: error: template definition of non-template 'void Cint::foo(const
int)'
$
Note that substituting
[EMAIL PROTECTED] writes:
Hi everybody,
I'm currently working in a company, as embedded developper, which use gnu
tools. I have a good experience about non gnu compiler tools and i need
help because the most disavantage of gcc compiler is the almost unexistant
support for developper.
Andrew Walrond [EMAIL PROTECTED] writes:
On Tuesday 13 March 2007 14:32:38 Andrew Haley wrote:
... a little tip. Add this to your c-mode-hook:
(set-variable 'show-trailing-whitespace t)
And you'll see all the trailing whitespace. On my system it appears
bright red.
Doesn't seem to
[EMAIL PROTECTED] (Richard Kenner) writes:
It also forbids embedded horizontal tabs for similar reasons (avoiding
junk difs).
That would be a problem with GCC, due to emacs being so heavily used,
but a similar convention *requiring* horizontal tabs would solve the
issue in question.
Emacs
Jan Hubicka [EMAIL PROTECTED] writes:
[...]
static inline void __attribute__((noreturn)) BUG(void)
{
__asm__ __volatile__(trap);
__builtin_unreached();
This is bit dificult to do in general since it introduces new kind of
control flow construct. It would be better to express such
Ian Lance Taylor [EMAIL PROTECTED] writes:
Sergei Organov [EMAIL PROTECTED] writes:
Below are two example functions foo() and boo(), that I think both are
valid from the POV of strict aliasing rules. GCC 4.2 either warns about
both (with -Wstrict-aliasing=2) or doesn't warn about any
Andrew Haley [EMAIL PROTECTED] writes:
Sergei Organov writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Sergei Organov [EMAIL PROTECTED] writes:
$ cat alias.c
typedef struct { int i; } S;
int i;
int foo()
{
S const sc = { 10 };
i = 20
Andrew Haley [EMAIL PROTECTED] writes:
Sergei Organov writes:
Andrew Haley [EMAIL PROTECTED] writes:
Sergei Organov writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Sergei Organov [EMAIL PROTECTED] writes:
int float_as_int()
{
h1.f = 1
Andrew Haley [EMAIL PROTECTED] writes:
Sergei Organov writes:
Andrew Haley [EMAIL PROTECTED] writes:
Sergei Organov writes:
Andrew Haley [EMAIL PROTECTED] writes:
Sergei Organov writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Sergei Organov
Andrew Haley [EMAIL PROTECTED] writes:
Sergei Organov writes:
If we come back to strict aliasing rules, then I will have to refer once
again to already cited place in the standard that says that I'm
permitted to access an object not only through a compatible type, but
also through
Mike Stump [EMAIL PROTECTED] writes:
On Jan 11, 2007, at 6:30 AM, Sergei Organov wrote:
So h1.f is not an object? If it is not, it brings us back to the
validity of my boo() function from the initial post, for which 2
persons
(3 including me) thought it's OK:
Would be nice for you to raise
Silvius Rus [EMAIL PROTECTED] writes:
[...]
I am about to submit a patch that implements -Wstrict-aliasing in the
backend based on flow-sensitive points-to information, which is
computed by analyzing the entire source of each function. It is not
perfect (the problem is undecidable), but it
Andrew Haley [EMAIL PROTECTED] writes:
Sergei Organov writes:
BTW, I've tried once to raise similar aliasing question in
comp.std.c++. The result was that somebody started to talk about
validity of pointers conversions that IMHO has nothing to do with
strict aliasing,
It's
Andrew Haley [EMAIL PROTECTED] writes:
Sergei Organov writes:
Andrew Haley [EMAIL PROTECTED] writes:
Sergei Organov writes:
If we come back to strict aliasing rules, then I will have to refer
once
again to already cited place in the standard that says that I'm
Laurent GUERBY [EMAIL PROTECTED] writes:
If we add a library function to handle this we might want to
add a GNU-style argument equivalent like
gcc --arguments-from-file=file
AFAIK gcc doesn't support any GNU-style arguments, isn't it?
I'd consider
gcc @file
gcc -@ file
gcc -args-from-file
Index: invoke.texi
===
RCS file: /cvsroot/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.637
diff -u -r1.637 invoke.texi
--- invoke.texi 15 Jun 2005 12:53:41 - 1.637
+++ invoke.texi 1 Jul 2005 14:52:13 -
@@ -5225,7
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
is turned on. Seems
Mike Stump [EMAIL PROTECTED] writes:
On Friday, June 17, 2005, at 07:13 AM, Sergei Organov wrote:
The first thing I'd like to get some advice on is which codebase do I
use, gcc-4_0-branch?
No, mainline. If it doesn't work there, is won't work anyplace else. :-(
Once you get it working
Hi,
Using gcc compiled from gcc-4_0-branch, in an attempt to see which
particular optimization option makes my test case to be mis-optimized, I
try to replace -O1 (which toggles on the problem) with corresponding set
of -fxxx optimization options. I first compile my code like this:
gcc -v
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 10:04 AM, Andrew Haley wrote:
How one finds out what optimization pass misbehaves?
Look at the dumps. If you use the gcc option -da you'll get a full
set of RTL dump files.
And -fdump-tree-all for the tree dumps.
The last
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 9:38 AM, Sergei Organov wrote:
2. The resulting assembly is different from what I get with -O1 and
doesn't contain the mis-optimization I'm trying to debug though it
doesn't seem to have anything to do with loops
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
is turned on. Seems
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
is turned on. Seems
Hi,
The gcc-2.95.x seems to be the last GCC version that have usable support
for small data sections (.sdata .sdata2) on PowerPC, see PRs 9571,
17337(resolved), and finally 21571.
As my embedded project heavily relies on the advantages of using small
data sections, it makes it impossible for me
27 matches
Mail list logo
